News for hackers. Stuff that matters.
Re:How the 8086 processor's microcode engine works by retrac on Saturday December 03, 2022 @02:52PM (#33846665)
Most computers were microcoded from the invention of the technique early in the 1950s, until the present. Really, it would make more sense to list the exceptions that weren't microcoded.

Some small minicomputers like the PDP-8 in the 60s/70s were hardwired logic; they were so simple that microcode wasn't necessary to cheaply implement them. Along the same lines, some early microprocessors like the 6502 also weren't microcoded (though they still tended to use large ROM lookup tables driven by a custom state machine so sort of half-microcoded).

Some very large early supercomputers were also hardwired; the CDC 6000 series, Cray-1, or IBM's largest System/370 models, for example. Microcode was avoided to minimize the logic delay during a single cycle and get things running as fast as possible. The same philosophy would resurface in the 1980s with RISC. But then RISC chips started adding microcode back in to handle complex multi-step instructions, etc.

Nearly everything else has been microcoded: everything from 8-bit microcontrollers to the Motorola 68K to the VAX, later RISC designs like POWER and ARM, every iteration of x86, etc.

Re:How the 8086 processor's microcode engine works by kens on Saturday December 03, 2022 @03:00PM (#33846725)
I think you're overstating the early popularity of microcode a bit. Microcode didn't really catch on until the IBM System/360 (1964). The problem was that storage was very expensive so it wasn't cost effective. IBM had to invent weird new storage techniques (TROS, CCROS, BCROS) using transformers or capacitors to make microcode practical.

The same thing happened with microprocessors. Early microprocessors didn't have enough space for microcode so they all had hard-wired control logic. It wasn't until the 8086 generation that you could put enough transistors on a chip to make microcode practical in a microprocessor. The 8087 co-processor is an interesting example. In order to fit the microcode onto the 8087 chip, Intel had to use weird semi-analog multi-sized transistors. This let them store 2 bits per transistor in the microcode ROJM.

Re:How the 8086 processor's microcode engine works by garaetjjte on Saturday December 03, 2022 @04:17PM (#33847449)
I don't think that ARM implementations are usually microcoded.
Re:How the 8086 processor's microcode engine works by monocasa on Saturday December 03, 2022 @05:03PM (#33847887)
ARM was always a bit of a CISC/RISC hybrid. The author of this article actually went into the microprogram engine of the ARM1 in some detail previously here: https://www.righto.com/2016/02/reverse-engineering-arm1-proc...

Even today, I would be shocked if ARM designs weren't partially microcoded as well. Something like the ERET instruction is begging to be.

Re:How the 8086 processor's microcode engine works by Taniwha on Saturday December 03, 2022 @07:43PM (#33849209)
The difference here though is that the ARM1 uses a PLA to directly decode an ARM instructions into a small number of clocks worth of things to do (enables to ALU stages/etc), while the x86 decodes an instruction into the address of a bunch of microinstructions in a ROM which then get executed with a micro PC (including subroutine calls). Sure the x86 microinstructions also directly control enables to ALU stages/etc, but the difference is that they also include what are effectively opcodes in their own rights.

In short the ARFM has decode logic that makes a bunch of clocks worth of ALU controls directly, while the x86 has decode logic that makes an index into a ROM from where that information is read/generated

Re:How the 8086 processor's microcode engine works by colejohnson66 on Saturday December 03, 2022 @06:51PM (#33848830)
> Along the same lines, some early microprocessors like the 6502 also weren't microcoded (though they still tended to use large ROM lookup tables driven by a custom state machine so sort of half-microcoded).

There’s two types of microcode: vertical (the kind people think of when hearing “microcode”) and horizontal (a large PLA). So, the 6502 is not “sort of” microcoded, it is microcoded, just horizontal microcode.

Re:How the 8086 processor's microcode engine works by monocasa on Saturday December 03, 2022 @07:15PM (#33849011)
I used to think that, but as I've gotten to know vertical ucode, horizontal ucode, and large PLAs a lot better, I've come around to the idea that the 6502 isn't microcoded. Particularly, while there are the T states, there's not really a true micro instruction counter or a single micro instruction word enabled at a time. It's more like if the hundred or so control signals each have a CAM that tells them whether to be enabled or not based on the instuction register and T state. It's kind of an inverse from how you think about ucode as a logic designer.

A better example of horizontal microcode (and what I learned on) are the PDP-11s. A clear micro instruction address counter and the ability to jump around the micro instruction ROM, but very wide control words where it's clear 'these three signals go into this mux, this signal is an enable over here, etc'.

Re:How the 8086 processor's microcode engine works by kens on Saturday December 03, 2022 @07:53PM (#33849291)
I've studied the 6502 in detail and I agree with you that the 6502 is not microcoded [*], for the reasons you mention. The 6502 has "random" control logic implemented with a PLA. (Since the PLA has multiple lines active at once, it's technically not a ROM.) You can't define a micro-instruction format for the 6502. There's a lot of detail on the 6502's PLA at this link: https://www.pagetable.com/?p=39

[*] For standard definitions of microcode.

Re:How the 8086 processor's microcode engine works by colejohnson66 on Sunday December 04, 2022 @01:35PM (#33856290)
Fair enough, but where would you draw the line between a PLA and horizontal microcode?
Re:How the 8086 processor's microcode engine works by kens on Sunday December 04, 2022 @02:02PM (#33856545)
I would say that the difference is not the outputs, but how the information is stored. Microcode is "software" that is stored in a ROM, so you have one row of the ROM producing the outputs. You can point to one line of the microcode and say "here's the micro-instruction", and change one bit of it easily. (The definition of a ROM having one row active at a time while a PLA can have multiple rows active is from "The Architecture of Microprocessors".)

You could use a PLA to produce exactly the same outputs from the same inputs, but it wouldn't be microcode. The PLA is "just" an optimization. But with a PLA, you can't change a micro-instruction without ripping out some of the logic and replacing it. You have a hardware implementation rather than a software implementation, which is the hallmark of microcode. In other words, changing a control signal value in the 8086's microcode is trivial, but changing a control signal in the 6502 is considerably harder.

As a concrete example, the design of the Apollo Guidance Computer is clearly microcoded, with specific microinstructions. However, the implementation is gate logic that completely obscures the microcode design. (Not a ROM implemented with NOR gates, but highly-optimized logic.) So I consider the implementation of the AGC to not be microcode.

(This is kind of splitting hairs, and I'm not really into subtle linguistic arguments.)