How the 8086 processor's microcode engine works

https://www.righto.com/2022/11/how-8086-processors-microcode-engine.html

by picture • 4 years ago

248 72 4 years ago

kens12• 4 years ago

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• 4 years ago

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.

kens12• 4 years ago

Thanks! I've fixed that.

foobiekr• 4 years ago

this was a wonderful writeup, thank you

nullifidian• 4 years ago

Ken, can you remove the country filter from your website/blog? I personally didn't do anything to deserve it.

behringer• 4 years ago

You can support the effort against a regressive government by supporting companies that offer VPN services to that countries citizens.

kens12• 4 years ago

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.

bombcar• 4 years ago

Brave browser has Tor built in.

peacepractice2• 4 years ago

https://archive.ph/xJAhi

http://web.archive.org/web/20221204144111/https://www.righto...

simmons• 4 years ago

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

theyeenzbeanz• 4 years ago

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.

addaon2• 4 years 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.

pwg2• 4 years 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".

ajross2• 4 years 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.

GeorgeTirebiter• 4 years 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• 4 years 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.

kens12• 4 years 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• 4 years ago

I don't think that ARM implementations are usually microcoded.

colejohnson662• 4 years ago

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.

formerly_proven• 4 years ago

You might be thinking about updateable/modifiable microcode.

artem_dev2• 4 years ago

It looks like a small CPU is working inside a bigger CPU :) Are there any books on this or on CPUs design?

kens12• 4 years ago

"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_dev2• 4 years ago

Thanks a lot!

pwg2• 4 years ago

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.

rasz7• 4 years ago

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.

EvanAnderson• 4 years ago

I had a laptop w/ a NEC V30 (an Ultralite PC-17-02[0]) and I recall it being a very peppy machine even compared to my father's 286. I did some assembly coding on it and I liked having the 286 PUSHA/POPA instructions. I didn't know about the 8080 emulation mode that it has, too, and it kinda makes me wish I had one to play with now.

I had absolutely no idea re: the LinnDrum being a PC. That's really cool. I've never seen one in the flesh, but now I'm wondering if anybody has done conservation of the firmware. It would be a lot of fun to look at the code.

[0] http://old.chuma.org/ultralite/index.shtml

rwmj2• 4 years ago

Back in the day I tried running a CP/M program on the V30 alternate instruction set. It didn't work and I eventually tracked it down to the program using one of the Z80-only LDI/LDR/LDIR block instructions. You're not supposed to use those with CP/M but because CP/M ran on many UK Z80 machines like the Amstrads, inevitably real world programs did. The V30 would have been a great way to run Z80 software [in the late 1980s] if only they'd implemented these :-)

sacnoradhq• 4 years ago

I guess you haven't used octopart before:

https://octopart.com/upd70136al-12-nec-10428216

https://octopart.com/upd70116hcz-16-nec-18733905

https://octopart.com/upd70116c-10-nec-2270733

rasz7• 4 years ago

Contacts octopart found for this part arent real distributors, they are bottom feeding speculators. No listed price means hundreds of dollars gouging aimed at military and government contractors I cant afford.

oso2k2• 4 years ago

There's a bunch of homebrew 8088, V20, and V40 "XT" boards out there now. I bought a few related boards plus a V20 and V40 from (https://www.homebrew8088.com/).

rasz7• 4 years ago

Yes, Im subscribed to Elijah https://www.youtube.com/@elijahmmiller/videos

tenebrisalietum• 4 years ago

Roger Linn's original LM-1 and LinnDrum were also full x86 PCs with custom cards.

Did you mean during development? LM-1 does not look like a PC, though I think I do see the NEC CPU in these screemshots: https://www.matrixsynth.com/2014/06/vintage-linndrum-lm-1-sn... - of course there's more to a vintage PC than an 8086.

rasz7• 4 years ago

I went back to my notes. https://en.wikipedia.org/wiki/Linn_9000 is 8088 PC with custom 7 slot ISA motherboard and standard ram/floppy controller cards

https://www.elektronauts.com/uploads/default/original/3X/6/8...

https://www.elektronauts.com/t/the-seminal-groovebox-linn-90...

https://www.vintage-radio.net/forum/showthread.php?t=87739

http://studiorepair.com/gallery/Linn/9000/index.html

LM-1 and LM-2 were Z-80 based. Damn, cant edit my first post :( Thank you for correction.

bogomipz2• 4 years ago

Another really amazing article!

I had a few questions:

Does a CPU's decoder circuit connect directly to this ROM then? If so is it connection to the translation ROM?

The second question I had was regarding the the image used to demonstrate the CORD routine. What are the microinstructions that don't have an address or a source and destination such as NCY, LRCY and RCY?

Lastly the author states:

"Surprisingly, there's no specific "microcode decoder" circuit. Instead, the logic is scattered across the chip, looking for various microcode bit patterns to generate control signals where they are needed."

Could you elaborate on this? What is meant by "looking for various microcode bit patterns to generate control signals where they are needed"? What exactly is the thing that is doing the looking here? I feel like this is an important point but I am unable to understand it.

kens12• 4 years ago

Does a CPU's decoder circuit connect directly to this ROM then? If so is it connection to the translation ROM?

The microcode address register loads the instruction opcode directly as the microcode address. For a microcode long jump or subroutine call, the microcode address is loaded from the Translation ROM. So you can think of the Translation ROM as a table of addresses for special cases.

The second question I had was regarding the the image used to demonstrate the CORD routine. What are the microinstructions that don't have an address or a source and destination such as NCY, LRCY and RCY?

I wanted to focus on the hardware for this post, so I didn't go into a lot of detail on the micro-instructions. NCY is "jump if not carry" (i.e. the carry flag is not set). "NCY 7" does a jump to line 7. "LRCY tmpc" is "left rotate through carry the value in temporary register c". RCY is "reset carry". You can sort of see how it's performing a divide through a loop of shifts and subtracts.

What is meant by "looking for various microcode bit patterns to generate control signals where they are needed"? What exactly is the thing that is doing the looking here? I feel like this is an important point but I am unable to understand it.

Well, I'm not sure if it is important, but I found it interesting :-) My point was that you might expect the micro-instructions to go through a block of decoding circuitry that generates the control signals for the processor. Instead, various bits from the micro-instruction go all over the processor. There are gates scattered all over that match on patterns such as if bit 3 is set AND bit 4 is clear AND bit 5 is set then do something like load a register. So the decoding logic is ad hoc and extremely distributed. There are some decoding blocks that are more structured, such a turning the micro-instruction's ALU bits into ALU control lines, but these blocks are also scattered across the chip.

Hopefully this all makes sense. Let me know if you'd like me to elaborate.

bogomipz2• 4 years ago

Thanks for the clarifications. I think I may have articulated my first question poorly. What I mean to ask is how does the CPU's decoder circuit interface with the Microcode ROM? It sounds as though the opcode bits are basically an index into the microcode ROM?

"I wanted to focus on the hardware for this post, so I didn't go into a lot of detail on the micro-instructions."

Understood. I hope this means we can look forward to a part 2 then! There is really a lot fascinating things here.

moloch-hai2• 4 years ago

What always strikes me about these expositions of x86 and its predecessors is how neutral the language is.

All these piled-on complications are, first and foremost, seriously wacky, and are not found in well-conceived designs as illustrated by ARM and 6502 that perform much better per unit die area than coeval Intel products.

The designers must have been congratulating themselves on how clever they were being, while painting themselves into corners that ultimately made performance worse than a simpler, more regular design could have been.

This gratuitous complexity spilled out into the ISA, imposing a tax on programmers and, later, compiler writers, that we are still paying today.

kens12• 4 years ago

What always strikes me about these expositions of x86 and its predecessors is how neutral the language is.

Well, I mention that the 8086 is convoluted, complex, and full of corner cases, so I think there's enough editorial :-)

As far as "seriously wacky", there are much stranger systems. For instance, the Honeywell 1800 mainframe has two program counters, and they can go forward or backward. The Intel iAPX 432 has instructions with arbitrary bit lengths, so they have no connection with byte boundaries. The AGC doesn't have shift instructions but special memory locations that shift values you store there. In comparison, the 8086 is a pretty middle-of-the-road processor.

moloch-hai2• 4 years ago

I should have been clearer. The convoluted, complex corner cases might have been justified if they made the product better for its intended users, but the user experience of Intel products has always been much worse than of its competitors.

subsequent• 4 years ago

http://web.archive.org/web/20221204144111/https://www.righto...

https://archive.ph/xJAhi

How the 8086 processor's microcode engine works

Related Stories