First off, if they made it 64-bit, it would not be a 386 or 486 anymore 😀

That said. AFAIK, the Xeon Phi "Knights corner" is based on a P54C architecture, produced on a 22nm tech, clocked at over 1 GHz with multiple cores and 512KiB L2 cache. They do a loooot for calculations at least 😀

You don't remember the Itanium? That's ok, neither does anyone else.

jmarsh wrote on 2020-11-11, 06:55:

You don't remember the Itanium? That's ok, neither does anyone else.

The Itanium is about the opposite of the 386 or 486, with completely different architecture and (unlike P6 and later) not even trying to translate that effectively into legacy x86.

The 386 and 486 are native CISC CPUs where more modern (P6 onwards) x86 CPUs are RISC with an interpreter shell around them. So a new "486" would have to be native x86 CISC. Agreed that Xeon Phi, specifically the Knights Corner, comes closest. But that wouldn't give you 64b, indeed you'd probably need a new, incompatible 64b set of instructions, which would not be supported. Also you'd hit the reason that Intel moved away from pure CISC: it didn't scale well enough. So chances are you wouldn't hit astronomical clock speeds and you'd end up with underperforming, overly complex silicon.

If it had been sensible, somebody would have done it already as the old 386 and 486 designs are very well-known and have been implemented and integrated by many companies and design teams already.

dionb wrote on 2020-11-11, 07:07:

But that wouldn't give you 64b, indeed you'd probably need a new, incompatible 64b set of instructions, which would not be supported.

Which is exactly what happened with the Itanium, and why it was a tremendous flop.

Modern x86 CPUs aren't anything close to RISC, and will not be as long as they allow operations directly on memory. Plus it's laughable to claim having a "reduced" instruction set when the maximum opcode length constantly gets increased with each new extension added...

The closest thing to what OP describes is the original in-order Atom CPUs (with the exception of the 7nm requirement - they can't even manage to produce current chips at that level). And unsurprisingly, they weren't much better than the early pentiums despite having multiple cores and clockspeeds over 1GHz.

C'mon now, we know Intel can't do 7nm.
No, a 14nm+++++++ 64-bit, multi-core 486 without ILP, OoOE, SIMD, and all of the other cool tricks that make today's CPUs jackrabbit fast would not come anywhere near the performance of a modern CPU.

If it was possible to run a 386 at several GHz, it would still be slow, as it would spend vast majority of time waiting for memory.
386 lacks cache, and DRAM is still relatively slow.

Also, manufacturing a 386 using 7nm technology wouldn't be enough for it to run at GHz frequencies.

dionb wrote on 2020-11-11, 07:07:

The Itanium is about the opposite of the 386 or 486, with completely different architecture and (unlike P6 and later) not even trying to translate that effectively into legacy x86.

The 386 and 486 are native CISC CPUs where more modern (P6 onwards) x86 CPUs are RISC with an interpreter shell around them. So a new "486" would have to be native x86 CISC. Agreed that Xeon Phi, specifically the Knights Corner, comes closest. But that wouldn't give you 64b, indeed you'd probably need a new, incompatible 64b set of instructions, which would not be supported. Also you'd hit the reason that Intel moved away from pure CISC: it didn't scale well enough. So chances are you wouldn't hit astronomical clock speeds and you'd end up with underperforming, overly complex silicon.

If it had been sensible, somebody would have done it already as the old 386 and 486 designs are very well-known and have been implemented and integrated by many companies and design teams already.

I didn't know that "modern" x86 CPUs were actually RISC. I knew the AMD K6 was like that though. Of course it would not be compatible with our current software, but that's outside the argument. I would think that either a native CISC or RISC CPU would be faster than something with a translator. I suspect they needed to add that because of the increasing instruction set complexity for scaling purposes. If 64-bit was added and nothing else, maybe it could be kept as a native CISC and be more efficient. Assuming that whole translation level could be removed.

The reason why I think it's possible is because people have a tendency to add add add, but less often think of going back to an earlier design and adding to that because it would be seen as regression. I don't see it that way though.

Would somebody have done it if it was a good idea? Probably not because of compatibility.

Grzyb wrote on 2020-11-11, 07:49:

If it was possible to run a 386 at several GHz, it would still be slow, as it would spend vast majority of time waiting for memory.
386 lacks cache, and DRAM is still relatively slow.

Also, manufacturing a 386 using 7nm technology wouldn't be enough for it to run at GHz frequencies.

Yeah, no on-chip cache, right? But I would think it could be added to the CPU without changing the instruction set much.

jmarsh wrote on 2020-11-11, 07:33:

dionb wrote on 2020-11-11, 07:07:

But that wouldn't give you 64b, indeed you'd probably need a new, incompatible 64b set of instructions, which would not be supported.

Which is exactly what happened with the Itanium, and why it was a tremendous flop.

No that's not exactly what happened with Itanium, its VLIW architecture is utterly different to almost anything else out there. It's most definitely nothing like a 386-with-64b-bolted-on, indeed x86-64 comes close to the latter (just taking 686 rather than 386 as the base).

Modern x86 CPUs aren't anything close to RISC, and will not be as long as they allow operations directly on memory. Plus it's laughable to claim having a "reduced" instruction set when the maximum opcode length constantly gets increased with each new extension added...

Modern x86 are heavily microcoded, with additional cruft added all the time - but the core that finally executes that stuff after microcode has a lot of RISC-characteristics, even if to the outside world it looks elaborately CISC.

The closest thing to what OP describes is the original in-order Atom CPUs (with the exception of the 7nm requirement - they can't even manage to produce current chips at that level). And unsurprisingly, they weren't much better than the early pentiums despite having multiple cores and clockspeeds over 1GHz.

Agreed.

Transistor count = die size = speed

If you properly die shrunk a traditional 1.1 million transistor 486 to 7nm and re-arranged / resized the circuitry and vias using appropriate design techniques it would be stable beyond 4ghz with minimal effort.

Less transistors following any semblance of proper design technique always allows for more clock speed PERIOD

There are examples (in a lab) of relatively low tech (simple) silicon circuits oscillating stable at around 10ghz, that is where the upper wall seems to exist until you get into 3D circuitry.

The only argument that holds water is that the architecture would not run the piss poor bloated 64bit code quickly enough.

And indeed there is no more market for a 10ghz 486 than a 10ghz 8088.

If such a thing were made it would need the ram and every other sub system integrated on die to be useful

The fact that solitaire under Windows 10 can’t run on an older 2 ghz CPU (when it is identical in appearance and functionality to older versions) is a prime example of the total failure of having minimal human created code touching the processor.

Am I the only one who thinks the whole topic is ridiculous, like close/delete ridiculous 😁

I really tought that it was somekind of spam....

Less transistors following any semblance of proper design technique always allows for more clock speed PERIOD

In terms of a complete CPU design, you also have to take pipelining into account. A longer pipeline adds complexity to the chip but allows higher clock speeds because operations can be spread out over more cycles. A 130nm Pentium 4 can run faster than a 130nm Pentium M which can run faster than a 130nm Pentium 3. And it's no coincidence that the Pentium 4 has the longest pipeline out of those, and the Pentium 3 the shortest. A 486 has maybe half the pipeline stages of a P3. If you shrunk a 486 to 130nm I highly doubt it would hit 1.5GHz let alone 3GHz.

There are many other examples of older or low-cost architectures being produced on the latest silicon fab and having lower clock speeds than the big chips. See 180nm K6-3+ vs. 180nm Athlon, 250nm Pentium MMX vs. 250nm Pentium 3, or non-x86 chips like V830, SuperH, ARM, etc.

If they did I bet it would be built on a 14nm process! 😉

Cyberdyne wrote on 2020-11-11, 12:40:

Am I the only one who thinks the whole topic is ridiculous, like close/delete ridiculous 😁

I really tought that it was somekind of spam....

Verily, though a company may make billions of dollars a year and can afford to hire the best of the best, the real money to be made lies in keeping tabs on anonymous message board posts.

rmay635703 wrote on 2020-11-11, 12:05:

Transistor count = die size = speed […]
Show full quote

Transistor count = die size = speed

If you properly die shrunk a traditional 1.1 million transistor 486 to 7nm and re-arranged / resized the circuitry and vias using appropriate design techniques it would be stable beyond 4ghz with minimal effort.

Less transistors following any semblance of proper design technique always allows for more clock speed PERIOD

There are examples (in a lab) of relatively low tech (simple) silicon circuits oscillating stable at around 10ghz, that is where the upper wall seems to exist until you get into 3D circuitry.

The only argument that holds water is that the architecture would not run the piss poor bloated 64bit code quickly enough.

And indeed there is no more market for a 10ghz 486 than a 10ghz 8088.

If such a thing were made it would need the ram and every other sub system integrated on die to be useful

The fact that solitaire under Windows 10 can’t run on an older 2 ghz CPU (when it is identical in appearance and functionality to older versions) is a prime example of the total failure of having minimal human created code touching the processor.

Transistors, transistors.. transistors.. Pah! Transistors are old fashioned. Electron tubes are new again. 😀
Sounds funny, but it's kind of true.

Solid state or semiconductory technology predated the more complex tube technology.
The detector, the predecessor of a diode (transistors are basically 2 diodes), was used for crystal radio sets before tube radios were in use.

Ergo, a tube based processor can reach higher frequencies in theory. 😁
https://www.popularmechanics.com/technology/a … rbon-nanotubes/

Edit: Here's a link to the Crystal Detector at Wikipedia.
It's worth noting that a real detector is superior to an industrial glass diode.
The curve on an oscillograph is much smoother than that of the cheap diodes we have today.
https://en.wikipedia.org/wiki/Crystal_detector

rmay635703 wrote on 2020-11-11, 12:05:

There are examples (in a lab) of relatively low tech (simple) silicon circuits oscillating stable at around 10ghz, that is wher […]
Show full quote

There are examples (in a lab) of relatively low tech (simple) silicon circuits oscillating stable at around 10ghz, that is where the upper wall seems to exist until you get into 3D circuitry.

The only argument that holds water is that the architecture would not run the piss poor bloated 64bit code quickly enough.

And indeed there is no more market for a 10ghz 486 than a 10ghz 8088.

If such a thing were made it would need the ram and every other sub system integrated on die to be useful

The fact that solitaire under Windows 10 can’t run on an older 2 ghz CPU (when it is identical in appearance and functionality to older versions) is a prime example of the total failure of having minimal human created code touching the processor.

That's interesting. I know that 486 has a 4GB limit, but it does say 64TB virtual memory. Maybe instead of 64-bit, a system could switch between different 4GB pages to give more RAM without adding 64.
Anyway, I'm not a microprocessor engineer, so I don't know.

Like you said, Windows 10 and Microsoft is a perfect comparison. They keep adding more and more instead of removing. Some people like to think that a corporation worth so many millions would make the right decisions and if it could be done, it would be done. But that's not true. The focus is always on more features.
Imagine if Microsoft went back to Windows XP 64-bit and added the minimal required changes to make it compatible with new hardware (which it almost is already). Add some security patches and whatever else is necessary and then mandate the driver manufacturers to continue making drivers for it. Imagine how much better and faster it would be. But of course, they don't do that cause it doesn't fit their corporate agenda.
That's the point. There is a certain sweet spot though. Like if they went all the way back to Windows 98, then there would be problems and it probably wouldn't be as good. I believe the same thing with CPUs. Maybe going back to 486 would be too old, but there might be a sweet spot.

Am I the only one who thinks the whole topic is ridiculous, like close/delete ridiculous 😁

I really tought that it was somekind of spam....

Someone works at Intel. Kidding.
But really, it's just a casual question.
I really respect those that didn't close it. I don't see anything wrong with it even if it's stupid.

It's a fun idea to be honest. I don't know how practical it would be but it would be fun to play around with.

chrismeyer6 wrote on 2020-11-12, 01:51:

It's a fun idea to be honest. I don't know how practical it would be but it would be fun to play around with.

My first thought was an FPGA on an adapter board that fits in a 386/486 socket.
Having a subset of AMD's x86-64 instruction set (or Intel VT/AMD-V) would be interesting to play with.

As I told a few times before, Long Mode allows 16-Bit Protected Mode instructions/code still.
Just no V86, which is great because it was such a mess.
In Legacy Mode or Compatibility Mode, all the usual and hacky 32-/16-Bit stuff can be run.

Efit: Typos dixed.

even modern 486, you cannot dare to break 32 bits software compatibility using 64bits ALU unless it is like pentium working on 32bits processing using 64bits data path instead.

Easier still, ask intel to modify one of their old 32bit Atom in-order cpu IP blocks, (230 or N270) by adding ISA and PCI compatibility and allow us to down clock as low as 10MHz and twiddle more down to reach 4.77MHz 8086 performance. Why not?

Cheers,