6 ms·

I always thought microcode was feature that started with cyrix and pentium processors. Not once did I think it was a thing on the 8086.

addaon 4y ago
Microcode goes back to the PDP-11 and beyond; in a CISC mindset ("our job as ISA designers is to make it easier for assembly programmers to express their programs") it's a pretty obvious tool for increasing instruction set richness without proportionally increasing transistor budget.
- pwg 4y ago
  It goes further back than that. Quoting from Ken's article: "In 1951, Maurice Wilkes came up with the idea of microcode: instead of building the control circuitry from complex logic gates, the control logic could be replaced with another layer of code (i. e. microcode) stored in a special memory called a control store. To execute a machine instruction, the computer internally executes several simpler micro-instructions, specified by the microcode. In other words, microcode forms another layer between the machine instructions and the hardware." Note the "1951".
- ajross 4y ago
  IMHO that's a little backwards. I mean, yes, in its ultimate expression in systems like VAX that's how it ended up. But the "goal" of processor designers was never programmer comfort, and I think expressing it that way makes the whole thing seem like a mistake when in fact microcode was a critically important innovation. What microcode really does is make it possible to share hardware resources inside the execution of the same instruction. Hardware is really (really) expensive, and a naive implementation of a CPU needs a lot of it that you can't really afford. Take adders. You need adders everywhere in a CPU. You need to compute the result of an ADD instruction, sure, but you also need to compute the destination of a relative branch, or for that matter just compute the address of the next instruction to fetch. You might have segment registers like the 8086 that require an addition be performed implicitly. You might have a stack engine for interrupts that needs to pop stuff off during return. That's a lot of adders! But wait, how about if you put just one adder on the chip, and share it serially by having each instruction run a little state machine program in "micro" code! Now you can have a cheap CPU, at the cost of an extra ROM. ROMs are, technically, a lot of transistors; but they're dense and cheap (both in dollars for discrete logic designs and in chip area for VLSI CPUs). That is, microcode started as a size optimization for severely constrained devices. It was only much later that it was used to implement features that couldn't be pipelines. Only the last bit was a mistake.
  - kens 4y ago
    I'm not really following that explanation. You can get the same sharing of hardware resources with hardwired control circuitry as with microcode. (In fact, probably more with hardwired control circuitry since micro-instructions put some limits on what you can do.) It's just a matter of how you implement the state machine. (As an aside, the 8086 has a separate adder for address computations, independent of the ALU. You can see this in the upper left of the die photo.)
    - ajross 4y ago
      > You can get the same sharing of hardware resources with hardwired control circuitry as with microcode. Only with some other kind of state machine, though. I was maybe being a little loose with my definition for "microcode" vs. other state paradigms. Maybe the converse point makes more sense: "RISC", as a design philosophy, only makes sense once there's enough hardware on the chip to execute and retire every piece of an entire instruction in one cycle (not all in the same cycle, of course, and there were always instructions that broke the rules and required a stall). Lots and lots of successful CPUs (including the 8086!) were shipped without this property. My point was just that that having 50k+ transistor budgets was a comparatively late innovation and that given the constraints of the time, microcode made a ton of sense. It's not a mistake even if it seems like it in hindsight.
      - addaon 4y ago
        There's another implicit assumption here, though, which is that code size optimization is important. Which is obviously true given the era we're discussing, but it makes it clear why the implicit third possibility between "microcoded CISC" and "fully pipelined RISC" wasn't an option. Microinstructions themselves tend, especially with earlier designs, to be "simple" in the RISC sense (even if not pipelined, they're usually a fixed number of cycles/phases each). Why, then, are developers writing instructions that are then decoded into microinstructions, instead of writing microinstructions directly in an early equivalent of VLIW? Initially, as a code size optimization so essential as to go beyond an optimization; but then, once the cost of a the microcode decoder and state machine are already paid for, because the chosen ISA, now isolated from the micro-ISA, is a better and more pleasant ISA to develop for.
- GeorgeTirebiter 4y ago
  The 1st pdp-11, the pdp-11/20 did not use microcode. I believe every other pdp-11 was microcoded. ALSO: these days, assy lang makes it easy for compiler writers to express programs written in a high-level language! It's software, all the way down..... almost.
retrac 4y ago
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.
- kens 4y ago
  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.
- garaetjjte 4y ago
  I don't think that ARM implementations are usually microcoded.
  - deleted 4y ago
    [deleted]
formerly_proven 4y ago
You might be thinking about updateable/modifiable microcode.

addaon 4y ago

Microcode goes back to the PDP-11 and beyond; in a CISC mindset ("our job as ISA designers is to make it easier for assembly programmers to express their programs") it's a pretty obvious tool for increasing instruction set richness without proportionally increasing transistor budget.

pwg 4y ago
It goes further back than that. Quoting from Ken's article: "In 1951, Maurice Wilkes came up with the idea of microcode: instead of building the control circuitry from complex logic gates, the control logic could be replaced with another layer of code (i. e. microcode) stored in a special memory called a control store. To execute a machine instruction, the computer internally executes several simpler micro-instructions, specified by the microcode. In other words, microcode forms another layer between the machine instructions and the hardware." Note the "1951".
ajross 4y ago
IMHO that's a little backwards. I mean, yes, in its ultimate expression in systems like VAX that's how it ended up. But the "goal" of processor designers was never programmer comfort, and I think expressing it that way makes the whole thing seem like a mistake when in fact microcode was a critically important innovation. What microcode really does is make it possible to share hardware resources inside the execution of the same instruction. Hardware is really (really) expensive, and a naive implementation of a CPU needs a lot of it that you can't really afford. Take adders. You need adders everywhere in a CPU. You need to compute the result of an ADD instruction, sure, but you also need to compute the destination of a relative branch, or for that matter just compute the address of the next instruction to fetch. You might have segment registers like the 8086 that require an addition be performed implicitly. You might have a stack engine for interrupts that needs to pop stuff off during return. That's a lot of adders! But wait, how about if you put just one adder on the chip, and share it serially by having each instruction run a little state machine program in "micro" code! Now you can have a cheap CPU, at the cost of an extra ROM. ROMs are, technically, a lot of transistors; but they're dense and cheap (both in dollars for discrete logic designs and in chip area for VLSI CPUs). That is, microcode started as a size optimization for severely constrained devices. It was only much later that it was used to implement features that couldn't be pipelines. Only the last bit was a mistake.
- kens 4y ago
  I'm not really following that explanation. You can get the same sharing of hardware resources with hardwired control circuitry as with microcode. (In fact, probably more with hardwired control circuitry since micro-instructions put some limits on what you can do.) It's just a matter of how you implement the state machine. (As an aside, the 8086 has a separate adder for address computations, independent of the ALU. You can see this in the upper left of the die photo.)
  - ajross 4y ago
    > You can get the same sharing of hardware resources with hardwired control circuitry as with microcode. Only with some other kind of state machine, though. I was maybe being a little loose with my definition for "microcode" vs. other state paradigms. Maybe the converse point makes more sense: "RISC", as a design philosophy, only makes sense once there's enough hardware on the chip to execute and retire every piece of an entire instruction in one cycle (not all in the same cycle, of course, and there were always instructions that broke the rules and required a stall). Lots and lots of successful CPUs (including the 8086!) were shipped without this property. My point was just that that having 50k+ transistor budgets was a comparatively late innovation and that given the constraints of the time, microcode made a ton of sense. It's not a mistake even if it seems like it in hindsight.
    - addaon 4y ago
      There's another implicit assumption here, though, which is that code size optimization is important. Which is obviously true given the era we're discussing, but it makes it clear why the implicit third possibility between "microcoded CISC" and "fully pipelined RISC" wasn't an option. Microinstructions themselves tend, especially with earlier designs, to be "simple" in the RISC sense (even if not pipelined, they're usually a fixed number of cycles/phases each). Why, then, are developers writing instructions that are then decoded into microinstructions, instead of writing microinstructions directly in an early equivalent of VLIW? Initially, as a code size optimization so essential as to go beyond an optimization; but then, once the cost of a the microcode decoder and state machine are already paid for, because the chosen ISA, now isolated from the micro-ISA, is a better and more pleasant ISA to develop for.
GeorgeTirebiter 4y ago
The 1st pdp-11, the pdp-11/20 did not use microcode. I believe every other pdp-11 was microcoded. ALSO: these days, assy lang makes it easy for compiler writers to express programs written in a high-level language! It's software, all the way down..... almost.

retrac 4y ago

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.

kens 4y ago
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.
garaetjjte 4y ago
I don't think that ARM implementations are usually microcoded.
- deleted 4y ago
  [deleted]

formerly_proven 4y ago

You might be thinking about updateable/modifiable microcode.