[HN Gopher] Reverse-engineering the register codes for the 8086 ...
___________________________________________________________________
Reverse-engineering the register codes for the 8086 processor's
microcode
Author : wglb
Score : 40 points
Date : 2023-03-12 18:24 UTC (4 hours ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| userbinator wrote:
| 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.
| snek_case wrote:
| 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.
| msla wrote:
| It would be more reasonable to say that classic RISC has some
| features in common with the microcode CISC designs had long
| used and, in the case of x86, still use. RISC designs like MIPS
| even exposed things like the various delay slots which, in a
| CISC design, would have been hidden by microcode.
| ajross wrote:
| 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 wrote:
| 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...
|
| > 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]
| hyperman1 wrote:
| 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 wrote:
| 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
|
| ++The only "really" analog part of the 8086 is the charge pump
| to produce a negative voltage on the substrate.
| Espressosaurus wrote:
| 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.
___________________________________________________________________
(page generated 2023-03-12 23:00 UTC)