5 ms·

Reverse-engineering the register codes for the 8086 processor's microcode

73 points by wglb 4y ago

jecel 4y ago
"The 68000 uses much wider microcode (85-bit microinstructions compared to 21 bits in the 8086)." is not what I remembered. Another source says "The actual internal representation is a combination of "microcode" and "nanocode". The 68000 has 544 17-bit microcode words which dispatches to 366 68-bit nanocode words." which sounds right. Somewhere around here I have a very detailed article about this which might not be available online, but it would take some time to dig it up.
- kens 4y ago
  My source is "The Architecture of Microprocessors", which has a very detailed chapter on the internals of the 68000. Each micro-instruction consists of a 17-bit sequencing field and a 68-bit action field (85 bits in total). These are stored in two separate sections of the microprogram ROM (what other sources call the "microcode" and the "nanocode"). The sequencing field specifies the next microcode address based on various branch conditions, while the action field controls the various parts of the CPU. I've seen descriptions like yours saying that the microcode dispatches to the nanocode, but I can't figure out how to make both descriptions consistent. "The Architecture of Microprocessors" is extremely detailed, describing the action of each field at the bit level, while other sources are more hand-waving, so I'm more inclined to believe it. But I haven't looked at the 68000 closely, so I could be wrong.
userbinator 4y ago
The fixed-width microcode instructions with 5-bit register fields is very reminiscent of a classic RISC. It looks like the concept of breaking down instructions into RISC-like uops into was there since the beginning, but Intel only started marketing it that way with the Pentium. It's worth noting that, had the mapping from segment registers to internal register numbers included i5, it would've been possible to access several of the other internal registers with undocumented instructions.
- ajross 4y ago
  RISC is about pipelining more than ISA, really. Yes, these are tiny instructions, but the CPU is doing only one of them at a time. In a RISC core[1], the CPU would be fetching an instruction from address X, while the instruction at address X-4 (fetched last cycle) was being presented to the decoder, at the time time the decoded instruction from X-8 was being presented to the ALU for execution (or FPU, or load/store unit, etc...), at the same time the instruction at X-12's result was being written back into the register file. You still get only one instruction per cycle[2], but the circuit depth is lower and you can run faster. The tradeoff is that you need enough hardware on the chip to do all this at one time. The microcode solution can share resources between different instructions because they don't operate at the same time. [1] This is more or less the original four-stage RISC setup. Modern CPUs have many more pipeline stages, including handling for things like L1 cache. [2] Superscalar CPUs extend this idea by having multiple execution pipelines running in parallel, fed by an instruction fetch/decode unit that can figure out and emit more than one instruction in a cycle.
  - kens 4y ago
    There's more pipelining in the 8086 than you might expect, with a micro-instruction pipelined across three clock cycles. I explain this in more detail here: https://www.righto.com/2023/01/the-8086-processors-microcode-pipeline.html https://www.righto.com/2023/01/the-8086-processors-microcode... > RISC is about pipelining more than ISA, really. I hesitate to get into a discussion about what RISC "really" is, but I'll point out that "IS" is the same in "RISC" and "ISA".
    - deleted 4y ago
      [deleted]
- snek_case 4y ago
  The concept of microcode is fairly old. It was present at least as far back as the IBM 360 (1964), so it predates microprocessors. One big motivating factor for microcode is that it insulates the Instruction Set Architecture (ISA) from its actual implementation in hardware. That makes it a lot easier to be forward/backwards compatible. Without microcode, you have a situation where every generation of processor, and even different implementations of a microprocessor will have different internal resources and circuits. You need to be able to control things inside the processor like the flow of data between registers, ALU(s) and the memory bus... But for each processor implementation, the available connections and execution units are going to be different. Microcode allows you not to expose all those underlying details to the outside. It's also more compact than having to directly control all of the connections inside of a CPU manually. An alternative would be to have circuits that implement boolean logic and go directly from instructions bits to the internal control logic, but microcode also makes it easier to execute an instruction in multiple steps instead of being tied down to the constraint that each instruction must execute in exactly one cycle.
hyperman1 4y ago
I've always thought a CPU was an almost pure digital device: Maybe some analog things at the border to interface with the world, but I assumed the internals could be represented as pure digital gates with not much extras. This reverse engineering shows a surprising amount of exceptions. Here again, the crossover mux has 'relatively large transistors' and the bootstrap drivers come up again. Is this still the case today? AFAIK, an FPGA design behaves like a pure digital device, apart from timing.
- kens 4y ago
  As Vonada said†, "Digital circuits are made from analog parts." On the one hand, you can simulate just about everything in the 8086 as digital.†† On the other hand, the transistors in the 8086 (and other processors) are carefully sized to produce the necessary current, taking into account capacitance and resistance and timing. For instance, the ALU has larger transistors because it was speed-critical. †See "Vonada's Engineering Maxims": https://twitter.com/kenshirriff/status/1633154548318732289 https://twitter.com/kenshirriff/status/1633154548318732289 ††The only "really" analog part of the 8086 is the charge pump to produce a negative voltage on the substrate.
  - Espressosaurus 4y ago
    Yeah. If you've ever had to deal with metastability and eyes in digital signals, you'd know that "digital" is frequently less 0 and 1 than we normally think about. There's a reason you can't just take a System Verilog FPGA and make an ASIC out of it that will work on the first time, and that there are entire teams and libraries to do it. And they'll still get things wrong that need to be fixed after they're discovered. edit: the only reason we can blissfully ignore the underlying analog world is through the unceasing effort of asic designers, analog engineers, verification teams, firmware teams, and as a last line of defense, some poor bastard writing the driver to work around something that can't be fixed with any other method.
    - Taniwha 4y ago
      > Yeah. If you've ever had to deal with metastability ..... I believe that's Vonada's maxim #10 .....

73 points by wglb 4y ago

"The 68000 uses much wider microcode (85-bit microinstructions compared to 21 bits in the 8086)." is not what I remembered. Another source says "The actual internal representation is a combination of "microcode" and "nanocode". The 68000 has 544 17-bit microcode words which dispatches to 366 68-bit nanocode words." which sounds right. Somewhere around here I have a very detailed article about this which might not be available online, but it would take some time to dig it up.

kens 4y ago
My source is "The Architecture of Microprocessors", which has a very detailed chapter on the internals of the 68000. Each micro-instruction consists of a 17-bit sequencing field and a 68-bit action field (85 bits in total). These are stored in two separate sections of the microprogram ROM (what other sources call the "microcode" and the "nanocode"). The sequencing field specifies the next microcode address based on various branch conditions, while the action field controls the various parts of the CPU. I've seen descriptions like yours saying that the microcode dispatches to the nanocode, but I can't figure out how to make both descriptions consistent. "The Architecture of Microprocessors" is extremely detailed, describing the action of each field at the bit level, while other sources are more hand-waving, so I'm more inclined to believe it. But I haven't looked at the 68000 closely, so I could be wrong.

userbinator 4y ago

The fixed-width microcode instructions with 5-bit register fields is very reminiscent of a classic RISC. It looks like the concept of breaking down instructions into RISC-like uops into was there since the beginning, but Intel only started marketing it that way with the Pentium. It's worth noting that, had the mapping from segment registers to internal register numbers included i5, it would've been possible to access several of the other internal registers with undocumented instructions.

ajross 4y ago
RISC is about pipelining more than ISA, really. Yes, these are tiny instructions, but the CPU is doing only one of them at a time. In a RISC core[1], the CPU would be fetching an instruction from address X, while the instruction at address X-4 (fetched last cycle) was being presented to the decoder, at the time time the decoded instruction from X-8 was being presented to the ALU for execution (or FPU, or load/store unit, etc...), at the same time the instruction at X-12's result was being written back into the register file. You still get only one instruction per cycle[2], but the circuit depth is lower and you can run faster. The tradeoff is that you need enough hardware on the chip to do all this at one time. The microcode solution can share resources between different instructions because they don't operate at the same time. [1] This is more or less the original four-stage RISC setup. Modern CPUs have many more pipeline stages, including handling for things like L1 cache. [2] Superscalar CPUs extend this idea by having multiple execution pipelines running in parallel, fed by an instruction fetch/decode unit that can figure out and emit more than one instruction in a cycle.
- kens 4y ago
  There's more pipelining in the 8086 than you might expect, with a micro-instruction pipelined across three clock cycles. I explain this in more detail here: https://www.righto.com/2023/01/the-8086-processors-microcode-pipeline.html https://www.righto.com/2023/01/the-8086-processors-microcode... > RISC is about pipelining more than ISA, really. I hesitate to get into a discussion about what RISC "really" is, but I'll point out that "IS" is the same in "RISC" and "ISA".
  - deleted 4y ago
    [deleted]
snek_case 4y ago
The concept of microcode is fairly old. It was present at least as far back as the IBM 360 (1964), so it predates microprocessors. One big motivating factor for microcode is that it insulates the Instruction Set Architecture (ISA) from its actual implementation in hardware. That makes it a lot easier to be forward/backwards compatible. Without microcode, you have a situation where every generation of processor, and even different implementations of a microprocessor will have different internal resources and circuits. You need to be able to control things inside the processor like the flow of data between registers, ALU(s) and the memory bus... But for each processor implementation, the available connections and execution units are going to be different. Microcode allows you not to expose all those underlying details to the outside. It's also more compact than having to directly control all of the connections inside of a CPU manually. An alternative would be to have circuits that implement boolean logic and go directly from instructions bits to the internal control logic, but microcode also makes it easier to execute an instruction in multiple steps instead of being tied down to the constraint that each instruction must execute in exactly one cycle.

hyperman1 4y ago

I've always thought a CPU was an almost pure digital device: Maybe some analog things at the border to interface with the world, but I assumed the internals could be represented as pure digital gates with not much extras. This reverse engineering shows a surprising amount of exceptions. Here again, the crossover mux has 'relatively large transistors' and the bootstrap drivers come up again. Is this still the case today? AFAIK, an FPGA design behaves like a pure digital device, apart from timing.

kens 4y ago
As Vonada said†, "Digital circuits are made from analog parts." On the one hand, you can simulate just about everything in the 8086 as digital.†† On the other hand, the transistors in the 8086 (and other processors) are carefully sized to produce the necessary current, taking into account capacitance and resistance and timing. For instance, the ALU has larger transistors because it was speed-critical. †See "Vonada's Engineering Maxims": https://twitter.com/kenshirriff/status/1633154548318732289 https://twitter.com/kenshirriff/status/1633154548318732289 ††The only "really" analog part of the 8086 is the charge pump to produce a negative voltage on the substrate.
- Espressosaurus 4y ago
  Yeah. If you've ever had to deal with metastability and eyes in digital signals, you'd know that "digital" is frequently less 0 and 1 than we normally think about. There's a reason you can't just take a System Verilog FPGA and make an ASIC out of it that will work on the first time, and that there are entire teams and libraries to do it. And they'll still get things wrong that need to be fixed after they're discovered. edit: the only reason we can blissfully ignore the underlying analog world is through the unceasing effort of asic designers, analog engineers, verification teams, firmware teams, and as a last line of defense, some poor bastard writing the driver to work around something that can't be fixed with any other method.
  - Taniwha 4y ago
    > Yeah. If you've ever had to deal with metastability ..... I believe that's Vonada's maxim #10 .....