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).

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.

Thanks! I've fixed that.

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

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

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.

Ken, did people of the countries mentioned here https://watson.brown.edu/costsofwar/figures/2021/WarDeathTol... do something to personally deserve their deaths most of which were the direct result of the US interventions there? Why don't you country-filter your own compatriots, many of whom work for the war machine that implemented this reality, and will continue to implement it across the world. Why didn't you suggest yourself to the better opportunities outside of the US, to the more peaceful countries? But it seems that you are either a hypocrite, or an unapologetic believer in the Greater Good™, i.e. a war apologist, who incidentally also doesn't shy away from anti-individualist group discrimination.

>better opportunities outside Russia.

Once you trasfer $2 mil for the investor visa (I'm a college dropout) or a cure for my ailing mother I'll move right away.

I'm not looking for a big political debate, but I'll point out that I'm not a US citizen.

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.

America's recent wars in the Middle East may not be great but they're clearly significantly more just than Russia's.

Stay neutral. Please don't get political. Your technical article are great but things like this will only cause divisiveness.

Serious question: why can't he choose who accesses his blog and use it for a small political message? Tech doesn't exist in an apolitical vacuum.

I come here to read about tech, not indulge in virtue-signaling identity politics. There's far too much of that on the Internet as it is.

Being anti-Russian is "identity politics" and "virtue signaling" now? When did geopolitics get roped in with "woke"?

"woke" is only one of the recent and prominent examples of it. I'm opposed to the war too, but there's no need to antagonise the helpless visitors of a technical blog for the actions of a government they didn't choose.

Ah yes, the helpless "good German"

anti-Russian like anti-Putin and his band of murderers or anti-Russian as nationality? If it is the latest then it is disgusting.

> I come here to read about tech, not indulge in virtue-signaling identity politics.

If you're complaining about finding politics "here" (i.e. on Hacker News), you should complain to the person posting the article, not to Ken Shirriff. Ken Shirriff can't control what you're presented here.

Nothing wrong with political messages. But I for one was surprised to see someone presumably highly intelligent who believes in collective responsibility and that it’s okay to discriminate against 130+ million people based on their country of birth.

I wasn't asked about country of birth when I viewed the web page. Certainly many people remain in the country of birth, but not all.

The overwhelming majority of the affected users aren’t immigrants I imagine and they’re punished for being born in the wrong country or for not leaving it, regardless of their political views or ability to leave the country.

>"...a suggestion that you might find better opportunities outside Russia"

This is so fucked up in multiple ways I do not know what to say. Even if person is trying to flee Putin's regime - the West is actively denying entry to those people. I would understand if you were Ukrainian but it appears you are not.

Do you also block American visitors because of the US invasions in the Middle East?

US invasions into the Middle East weren’t literal conquests and annexations of sovereign land. They’re in no way comparable, and if this war has done anything, it’s helped wash the blood from US hands and make those wars look acceptable.

For someone like me, who was staunchly against the War in Iraq and Afghanistan on a fundamental level, it’s sad that I’ve seen an invasion and conquest egregious enough to surpass those in such a short span of time.

So you’re saying the US invasions are somehow morally superior because they are resource grabs, not land grabs even though the scale of civilian casualties is similar or worse?

Back to the point though. It would never occur to me to impose my own micro-sanctions on Americans just because the US government is a serial invader and mass-murderer. Even though in popular opinion the US is a democracy, which makes its people responsible for the government actions, and Russia isn’t, which in principle should remove the collective guilt if someone subscribes to that idea.

The scale of civilian casualties from the first 6 months in Ukraine (17000 killed or injured, 1000 of whom were children; millions more in forced relocation and displacement) make the first six months of the Iraqi campaign look downright humane (~9000 total, with zero Iraqi woman and children dragged to the US to be raped/forcibly integrated into society and the vast majority of the population still in their nation throughout the campaign). That should tell you how badly Russia is seen internationally (and why random people feel the need to block you from their websites), considering the Iraqi campaign is downright villified in the West and full of inhumane tactics and scandals; so much so most Americans only speak badly of it in retrospect.

The fact that you feel they are comparable means you're either naive or politically blinded. Considering comparing Ukraine to Iraq is a common tactic in Russian national media and propaganda to justify the war, I'll assume it's the latter; but give you the benefit of the doubt.

There is no "morally superior" war. War is war and it's bad. Russia's war is one of the worst types of war. And even if the US' were equivalent, that doesn't justify Russia's.

>"make the first six months of the Iraqi campaign look downright humane "

Why first six month? To hide the real cost in human lives?

from - https://en.wikipedia.org/wiki/Casualties_of_the_Iraq_War "Population-based studies produce estimates of the number of Iraq War casualties ranging from 151,000 violent deaths as of June 2006 (per the Iraq Family Health Survey) to 1,033,000 excess deaths (per the 2007 Opinion Research Business (ORB) survey). Other survey-based studies covering different time-spans find 461,000 total deaths (over 60% of them violent) as of June 2011 (per PLOS Medicine 2013), and 655,000 total deaths (over 90% of them violent) as of June 2006 (per the 2006 Lancet study). "

This sure qualifies for Nobel Peace award.

>"There is no "morally superior" war.

Totally agree (except when fighting against aggression force)

>"And even if the US' were equivalent, that doesn't justify Russia's."

Agree again.

> Why first six month?

Because that's about as long as the Russian war has been going on. It's called comparing like to like.

Well then it is too early to compare, wars do not have to follow the same course. We know approximately what happened in Iraq. We know zilch about when and how this one will end.

Besides Iraq war was total disaster in terms of human suffering. You can't whitewash it using situation in Ukraine.

As FpUser pointed out, why cherry-pick stats for the first six months? Why only Iraq? Was the Iraqi campaign vilified domestically in the first six months too or was it a rah-rah ‘Mission accomplished’/‘We got him’ type of situation in the beginning?

I can understand the selective blindness. After all everyone wants to believe they’re on the good guys side. We invade for the good reasons, they invade because they’re imperialist. We cause collateral damage that we’re very sorry about, they just downright target civilians. And on and on the justification goes.

When you don’t have a dog in this race and treat both sides’ media as propaganda outlets, it becomes really easy to compare and see who’s worse on what time scale and why. And it’s easy to see that discriminating regular Joes (or Ivans) isn’t an act of solidarity with the victim, but a bigoted way to release misplaced anger. A little bit of self awareness goes a long way.

> Why first six month?

Because the Russian offensive hasn't been going on for 10 years.

> I can understand the selective blindness. After all everyone wants to believe they’re on the good guys side.

I don't live in the US nor represent American interests, so your strawman is useless and futile. Especially when I went to pains to paint the Iraq War as a bad thing, not a good one. Russia is simply worse.

One doesn’t have to be American to consider themselves to be in the US camp. I live in a NATO country and the pro-US propaganda here is even worse than in American outlets and much more consolidated because of the de facto media monopoly. Here, ’us’ means the US with the rest of NATO and ‘them’—Russia, China, Iran, etc.

Everyone’s entitled to their own opinion when it comes to moral judgement. My opinion is that on the global bully scale the US is much higher than any other country. Which of course doesn’t excuse the lesser bullies, but it’s puzzling to see the extent of mental gymnastics one has to go through to argue that Russia is worse than the US in the invasions department.

The country that has a history of being a serial invader with the overall (by far) higher civilian death toll is still better because the first six months of Iraq invasion were reportedly less brutal than the first six months of Ukraine invasion?

I don’t buy the idea that there can be only one Bully we should all focus on and the moment you get a worse one the previous bully can walk away scot-free. If one starts punishing people for their government’s actions (as Ken does), at least they should be consistent in their folly and treat the ally bullies the same way as the enemy ones.

>"make those wars look acceptable."

They fucking murdered directly or indirectly millions of people after WWII. I do not think any sane person can call it acceptable. I can't wrap my head how current invasion surpasses it. Either is a crime against humanity and must be punished. And I do not think victims give a flying fuck whether their country was being annexed. They care about being murdered.

This brings such an interesting moral dilemma.

Are our inherited sins worse than our committed ones? In other words, is it more disgusting to be born Russian, or to choose to work at Google?

I was going to ask some questions about the article, now I'm not so sure you're worth my time.

You, I, and everyone else here in the comments have nothing to do with the war in Ukraine.

Be better than this.

This has to be a joke, right?

Are you really claiming the moral right to tell somebody to leave their own country, and if they don't you will do what you can to punish them? That doesn't seem right. What if they have elders to take care of? One can imagine a million circumstances. It seems to me that holding someone's national origin against them is just the sort of thing that leads to wars in the first place. I love your articles and I'm sure you're a good person and just want to do something to support the victims of the war, but collective punishment is not the way. It's one of the worst things you could do to reinforce pain, resentment, and division.

Brave browser has Tor built in.

this was a wonderful writeup, thank you

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

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.

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.

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".

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.

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.)

> 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.

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.

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.

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.

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.

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.

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

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.

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

> 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.

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'.

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.

Fair enough, but where would you draw the line between a PLA and horizontal microcode?

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.)

You might be thinking about updateable/modifiable microcode.

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

"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.

Thanks a lot!

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.

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.

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

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 :-)

Wouldnt undefined instruction trap take care of that?

Good question! Did V30 trap on undefined instructions?

8086 didn't according to https://retrocomputing.stackexchange.com/questions/11327/wha..., but V30 was more like an 80186 which did trap, but then 8080 emulation mode might have worked differently again.

Also I don't recall how I worked out that the extended Z80 instructions were causing the problem. Debugging was a lot more complicated in those days, although programs were also much smaller.

I took a look at the V30 manual and it doesn't have an undefined instruction trap. It's an interesting chip, a superset of the 8086 as well as 8080 emulation. It includes bit manipulation instructions kind of like the Z80, along with multidigit BCD arithmetic.

https://www.ceibo.com/eng/datasheets/NEC-V20-V30-Users-Manua...

V33/V53 and V33A/V53A do have them, with non A variants as non standard exception 122 http://elm-chan.org/docs/dev/v53_e.html mentions it. They build a cute board around it in 1998 http://elm-chan.org/works/cpu_v53/report.html

according to MAME V40 has it as standard exception 6? https://github.com/lesbird/MAME4apple-037b5/blob/master/MAME... Then again https://forum.vcfed.org/index.php?threads/nec-v20-and-cp-m.7... says no.

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

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.

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/).

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

Don’t forget the discord either.

F discord, like facebook its invisible to the outside world until you join the borg and register. Never crawled, never archived, unsearchable, undiscoverable proprietary garbage.

> 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.

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.

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.

> 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.

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.

The ROM has 13 address bits: 8 from the opcode, an extra one that is clear for normal opcodes and set for internal subroutines, and 4 bits for the microcode instruction counter.

However some of the address bits are ignored, for example anything that matches the bit pattern 00xxx0xx is some kind of ALU operation, either between two registers, or a register and memory. The 3 bits in the middle select the operation, the low bit the operand size (byte or word), and the second one the direction (which operand is in memory, if any - with two register operands both encodings can be used).

All of this extra information is decoded by random logic. The microcode for this class of opcodes looks like this (in one representation anyway, not necessarily the most easy to understand but based on the patent):

    M     -> tmpa      1   XI    tmpa
    R     -> tmpb      4   none  WB,NX                     
    SIGMA -> M         4   none  RNI      F                
                       6   W     DD,P0                     

On the left are the register moves: M is the first/destination operand, and R the second one. SIGMA (Σ in the patent) is the output from the ALU.

The first line of code on the right sets up the ALU ("type 1 instruction" XI: select ALU operation from opcode bits; first operand in tmpa, second one is always tmpb). The next one prepares to write back the result and decode the next instruction. If the result goes to a register, the third line will be the last one executed ("type 4", RNI: run next instruction; F: update flag register). If it goes to memory, the store happens on the fourth line ("type 6", write, default data segment, no auto-increment).

You can find more information in the linked patent (US4449184) and blog post (https://www.reenigne.org/blog/8086-microcode-disassembled)

Yes. The logic is (slightly simplified): if the first cycle of an instruction then load opcode directly into the microcode address else if short jump then update 4 low bits of the microcode address else if long jump or subroutine call then load microcode address from translation ROM else if subroutine return then load microcode address from pushed address else increment the microcode address to the next instruction.

(This is implemented in hardware with a multiplexer, not as sequential if-then-else instructions.)

There's no decoding logic between the opcode in the instruction register and the microcode address. So yes, the opcode bits are the index into the microcode ROM.

rep_lodsb covered a lot of the instruction handling in the sibling comment.

I hope to write a part 2 before too long.

What always strikes me about these expositions of x86 and it 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.

> 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.

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.