[HN Gopher] How the 8086 processor's microcode engine works
       ___________________________________________________________________
        
       How the 8086 processor's microcode engine works
        
       Author : picture
       Score  : 144 points
       Date   : 2022-12-03 18:29 UTC (4 hours ago)
        
 (HTM) web link (www.righto.com)
 (TXT) w3m dump (www.righto.com)
        
       | artem_dev wrote:
       | It looks like a small CPU is working inside a bigger CPU :) Are
       | there any books on this or on CPUs design?
        
         | kens wrote:
         | "Computer Architecture: A Quantitative Approach" is the
         | standard text. I like "Modern Processor Design: Fundamentals of
         | Superscalar Processors" for an explanation of how superscalar
         | processors work.
        
           | artem_dev wrote:
           | Thanks a lot!
        
         | pwg wrote:
         | If you can find a copy, "Computer Organization" by V. Carl
         | Hamacher, Zvonko G. Vranesic and Safwat G. Zaky, published by
         | Mcgraw-Hill has, at least in my copy of the 2nd edition, a nice
         | chapter on microcode control units.
         | 
         | If you can find a copy, reading the prior chapter on hardwired
         | control units might be reasonable as it is somewhat
         | "background" for following the microcode chapter.
        
       | kens wrote:
       | Author here if anyone has questions. I've been doing a lot of
       | 8086 stuff lately, so this article is different from last week's
       | 8086 article (in case anyone thinks they have deja vu).
        
         | johndoe0815 wrote:
         | The annotation in the die photo
         | (https://static.righto.com/images/8086-mc-overview/mc-die.jpg)
         | seems to have a mistake - it reads "128x48" instead of 128x84
         | as mentioned in the text.
        
           | kens wrote:
           | Thanks! I've fixed that.
        
         | foobiekr wrote:
         | this was a wonderful writeup, thank you
        
         | simmons wrote:
         | I've been eagerly awaiting this article since your teaser
         | comment a couple of years ago [1], and really look forward to
         | reading it!
         | 
         | [1] https://news.ycombinator.com/item?id=24094024
        
         | nullifidian wrote:
         | Ken, can you remove the country filter from your website/blog?
         | I personally didn't do anything to deserve it.
        
           | bombcar wrote:
           | Brave browser has Tor built in.
        
           | behringer wrote:
           | You can support the effort against a regressive government by
           | supporting companies that offer VPN services to that
           | countries citizens.
        
           | kens wrote:
           | Unfortunately there are also many people in Ukraine who
           | didn't personally do anything to deserve what's happening.
           | Consider the country filter a small reminder of the ongoing
           | war and a suggestion that you might find better opportunities
           | outside Russia.
        
             | nullifidian wrote:
        
               | kens wrote:
               | I'm not looking for a big political debate, but I'll
               | point out that I'm not a US citizen.
        
               | nullifidian wrote:
               | That doesn't change much. You pay taxes in the US, you
               | don't country filter the US.(And never did, I think) Your
               | position is indefensible, unless you outright say that
               | American wars are just wars, and the casualties are
               | justified. But ok.
        
               | IshKebab wrote:
               | America's recent wars in the Middle East may not be great
               | but they're clearly significantly _more_ just than Russia
               | 's.
        
       | rasz wrote:
       | NEC did their own independent line of x86 clones. Apparently NEC
       | V33 is 8086 with "instruction decode done by hardwired logic
       | rather than a microprogrammed control store. Throughput is twice
       | as high as a V30" (datasheet claims four times faster). V30 was
       | their clean room RE 8086 clone and was already 10-30% faster than
       | original.
       | 
       | V33 was used in PC-98 DO+, and in SOC form (NEC V53) in legendary
       | Akai MPC3000, probably because Roger Linn's original LM-1 and
       | LinnDrum were also full x86 PCs with custom cards.
       | 
       | Sadly I cant find any place that sells V33/V53, maybe could be
       | sourced in Japan.
        
       | theyeenzbeanz wrote:
       | 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 wrote:
         | 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.
        
           | GeorgeTirebiter wrote:
           | 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.
        
           | pwg wrote:
           | 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 wrote:
           | 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 wrote:
             | 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 wrote:
               | > 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 wrote:
               | 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.
        
               | wk_end wrote:
               | Not just better and more pleasant, but also because
               | having an abstraction layer between the code and the
               | microarch is nice: it lets Intel modify their CPU's
               | internals as they see fit without worrying about
               | backwards compatibility; it allows Intel to make CPUs of
               | many different speeds/complexities and, regardless of
               | their insides, they all get to be compatible; and, as
               | Intel builds more sophisticated microarchitectures, it
               | allows old code to see speed improvements via faster
               | microcode that has more resources to operate with.
        
         | retrac wrote:
         | 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.
        
           | garaetjjte wrote:
           | I don't think that ARM implementations are usually
           | microcoded.
        
             | monocasa wrote:
             | 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.
        
             | [deleted]
        
             | [deleted]
        
           | kens wrote:
           | 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.
        
         | formerly_proven wrote:
         | You might be thinking about updateable/modifiable microcode.
        
       ___________________________________________________________________
       (page generated 2022-12-03 23:00 UTC)