3 ms·

Total amateur here: does a 386 have “cleverness” or optimizations or does it just quite literally chug through a stream of instructions, adjusting registers and

Total amateur here: does a 386 have “cleverness” or optimizations or does it just quite literally chug through a stream of instructions, adjusting registers and memory? I guess by this I am thinking about how newer processors do all kinds of stuff at the microcode level that mean you cannot anticipate precisely what instructions are being executed in what order.

bonzini 3y ago
Out of order execution was introduced in the Pentium Pro, the Pentium was already able to execute two instructions per cycle but was still in-order. Note that this "magic" is mostly implemented not in microcode, but rather in hardwired logic.
kens 3y ago
Well, yes and no. The 386 is chugging through the stream of instructions sequentially, unlike modern processors. There are various clever optimizations, though. First, there is some pipelining, so the microcode for the next instruction can execute while the previous one is finishing. Second, the CPU has 16 bytes of prefetching, so instructions are fetched from memory asynchronously from their execution. So you know what instructions are executed and in what order, but the timing is fairly unpredictable. I should mention that microcode in the 386 is pretty different from micro-ops that modern processors run. They both break machine instructions down into smaller steps. But microcode runs sequentially, while micro-ops are sort of tossed into the CPU and run independently through a dataflow engine, with everything sorted out at the end to look sequential. Confusingly, modern processors use "microcode" to hold the micro-ops for complicated instructions that can't be handled by the regular instruction decoder; this is sort of like old-style microcode, but not exactly.
- nxobject 3y ago
  That's really cool: having learned most of my digital design from an era where interpreted microcode was the norm, and the PDP-11 or early 68k was the pinnacle of hardware design worth teaching, I've always wanted to learn about the transitional designs from old-style microcode, to how shrunk forms of microcoding lived in superscalar CISC designs. (I'm still trying for lack of resources.)
chasil 3y ago
One of the assertions of RISC is that microcode is a performance penalty, to be avoided. And many have. "To provide this rich set of instructions, CPUs used microcode to decode the user-visible instruction into a series of internal operations. This microcode represented perhaps 1⁄4 to 1⁄3 of the transistors of the overall design. If... the majority of these opcodes would never be used in practice, then this significant resource was being wasted." https://en.m.wikipedia.org/wiki/Berkeley_RISC https://en.m.wikipedia.org/wiki/Berkeley_RISC
rasz 3y ago
386 is actually somewhat slower clock for clock than 286 for same 16bit code. So no, no optimizations. For example https://web.itu.edu.tr/kesgin/mul06/intel/instr/movs.html https://web.itu.edu.tr/kesgin/mul06/intel/instr/movs.html, 486 was only slightly optimized, it was Pentium where they finally started working on IPC.
- vikingerik 3y ago
  Right, the 486 was only slightly optimized for IPC. Most of the 486's performance over the 386DX was from its L1 cache (or just called CPU cache at the time, there weren't different cache levels yet.) You can turn the cache off in a 486's BIOS and it will be barely any faster than a 386 of the same clock speed.

bonzini 3y ago

Out of order execution was introduced in the Pentium Pro, the Pentium was already able to execute two instructions per cycle but was still in-order. Note that this "magic" is mostly implemented not in microcode, but rather in hardwired logic.

kens 3y ago

Well, yes and no. The 386 is chugging through the stream of instructions sequentially, unlike modern processors. There are various clever optimizations, though. First, there is some pipelining, so the microcode for the next instruction can execute while the previous one is finishing. Second, the CPU has 16 bytes of prefetching, so instructions are fetched from memory asynchronously from their execution. So you know what instructions are executed and in what order, but the timing is fairly unpredictable. I should mention that microcode in the 386 is pretty different from micro-ops that modern processors run. They both break machine instructions down into smaller steps. But microcode runs sequentially, while micro-ops are sort of tossed into the CPU and run independently through a dataflow engine, with everything sorted out at the end to look sequential. Confusingly, modern processors use "microcode" to hold the micro-ops for complicated instructions that can't be handled by the regular instruction decoder; this is sort of like old-style microcode, but not exactly.

nxobject 3y ago
That's really cool: having learned most of my digital design from an era where interpreted microcode was the norm, and the PDP-11 or early 68k was the pinnacle of hardware design worth teaching, I've always wanted to learn about the transitional designs from old-style microcode, to how shrunk forms of microcoding lived in superscalar CISC designs. (I'm still trying for lack of resources.)

chasil 3y ago

One of the assertions of RISC is that microcode is a performance penalty, to be avoided. And many have. "To provide this rich set of instructions, CPUs used microcode to decode the user-visible instruction into a series of internal operations. This microcode represented perhaps 1⁄4 to 1⁄3 of the transistors of the overall design. If... the majority of these opcodes would never be used in practice, then this significant resource was being wasted." https://en.m.wikipedia.org/wiki/Berkeley_RISC https://en.m.wikipedia.org/wiki/Berkeley_RISC

rasz 3y ago

386 is actually somewhat slower clock for clock than 286 for same 16bit code. So no, no optimizations. For example https://web.itu.edu.tr/kesgin/mul06/intel/instr/movs.html https://web.itu.edu.tr/kesgin/mul06/intel/instr/movs.html, 486 was only slightly optimized, it was Pentium where they finally started working on IPC.

vikingerik 3y ago
Right, the 486 was only slightly optimized for IPC. Most of the 486's performance over the 386DX was from its L1 cache (or just called CPU cache at the time, there weren't different cache levels yet.) You can turn the cache off in a 486's BIOS and it will be barely any faster than a 386 of the same clock speed.