Fixing a Bug in the Intel 8086 Processor Silicon

Ken Shirriff has been reverse-engineering the Intel 8086 microprocessor, ancestor of the x86 architecture so widely used today. While scrutinising the decoder for the 8086’s already-baroque instruction set (see “How Many Intel x86 Instructions Are There?”, posted here in November 2021), he noticed some distinctly odd logic circuitry that looked nothing like its surroundings.

Digging deeper revealed that this logic recognises instructions that load (MOV) or POP a value into a segment register. The output is used to defer processing of a queued interrupt until the next instruction completes. This allows loading the stack segment and pointer as an atomic operation, avoiding the memory corruption which would occur if an interrupt were to be processed with the new stack segment address and old stack pointer still in effect.

Today’s processors allow updating their microcode at boot time, but in the 1970s, you had to patch the silicon and that’s what Intel did, as described in Ken’s analysis, “A bug fix in the 8086 microprocessor, revealed in the die’s silicon”.

Actually, Intel’s patch did more than it needed to. It delayed interrupt processing after a change to any segment register, while the problem occurred only after a load of SS. I wondered about this when learning the 8086 instruction set, and never guessed it was a bug fix whose complexity was limited by what could fit within the existing silicon.

As it happens, the dreaded “plotter bug” in AutoCAD 2.1 years later was due to this programmer forgetting the order you had to load SS and SP and doing it backwards, which made the code vulnerable to an interrupt after the load of SP.


Since I began using computers beginning around 1986 with an early Mac (I made it “portable” with a large gym bag) in law school, I have tried to better understand how they work. My test for understanding has always been: “can I clearly explain this to someone else”? Alas, reading this post reminds me how far I have yet to go. As I read John’s exquisitely clear and concise descriptions of a wide variety of topics, when it comes to computers and ancillary devices, I get the sense it was necessary - but not sufficient - to acquire the depth of knowledge on display here; one must have been there - to have lived through and participated in every step (and likely many missteps) of computer evolution. Thank you for the ongoing history lesson and tutorial.


Interestingly, we are still learning things about computers we used decades ago. In this case, I’m sure thousands or tens of thousands of programmers wondered why the interrupt lockout after segment register load affected all registers and not just the stack. I would probably have guessed it was to simplify the logic design at the cost of a little performance. Although it wasn’t a secret and if you knew the right person at Intel at the time you might have heard the real reason, it was only in 2022 that Ken’s peering through a microscope revealed the story to everybody. This kind of discovery is the reward for engaging in reverse engineering.


Ken Shirriff’s done incredible work with his hardware reverse engineering series. This is mind blowing.


Would add – it is a good idea to save a file BEFORE a memory intensive process like plotting – ONLY THE PARANOID SURVIVE.