Silicon Sleuthing: Finding a ancient bugfix on the 8086

-

Few CPUs have had the long-lasting influence that the 8086 did. It is hard to believe that when your modern desktop computer boots, it probably thinks it is an 8086 from 1978 until some software gooses it into a more modern state. When [Ken] was examining an 8086 die, however, he noticed that part of the die didn’t look like the rest. Turns out, Intel had a bug in the original version of the 8086. In those days you couldn’t patch the microcode. It was more like a PC board — you had to change the layout and make a new one to fix it.

The affected area is the Group Decode ROM. The area is responsible for categorizing instructions based on the type of decoding they require. While it is marked as a ROM, it is more of a programmable logic array. The bug was pretty intense. If an interrupt followed either a MOV SS or POP SS instruction, havoc ensues.

The bug was a simple mistake for a designer to make. Suppose you want to change the stack pointer register entirely. You have to load the stack segment register (SS) and the stack pointer (SP). The problem is, loading both of these isn’t an atomic operation. That is, it takes two different instructions, one for each register. If an interrupt occurs after loading SS but before loading SP, then the interrupt context will wind up at some incorrect memory location.

You could fix this in several ways. The way Intel did it was to make the two instructions that could modify SS hold off interrupts for one more instruction cycle. This would allow you to load SP before an interrupt could occur. Essentially, it makes the MOV SS or POP SS instructions protect the next instruction so you can code an atomic operation. The truth is, the “fix” stalls interrupts for any segment register load. [Ken] notes that this wasn’t necessary and later implementations on newer processors only stall the interrupt for SS.

You might think you could have pushed this off to the programmer. You could, for example, insist that stack pointer changes occur with interrupts disabled. The problem is the 8086 has a nonmaskable interrupt that uses the stack, and software can’t stop it.

Failure analysis back the 1970s and 1980s was fun. An optical microscope would do most of it. If you had a SEM with an EDS attachment, you could do nearly everything. An Auger and a SIMS would put you in the world-class lab status. These days with device geometry several orders of magnitude smaller, dice upside down in the package, and dozens of layers — we aren’t sure how you’d do all this on a modern chip.

We love [Ken’s] CPU teardowns. He works on bigger things, too.



from Blog – Hackaday https://ift.tt/WFJjNSZ

Comments

Post a Comment

Popular posts from this blog

Modern Radio Receiver Architecture: From Regenerative to Direct Conversion

-
Image
Modern radio receivers have a distinct advantage over the common early designs which I covered in my previous article . Most of the receivers you will have worked with over the past couple decades are designs by Edwin Armstrong ; regenerative, superregenerative, or most commonly superheterodyne. These are distinguished by a few fascinating key traits that bring both benefits and drawbacks. Today let’s dive into Mr. Armstrong’s receivers. I’ll also talk about DC receivers which, despite the name, are not made to listen to batteries. These are receivers you are much more likely to encounter in modern equipment. Regenerative and Superregenerative The regenerative receiver is all about doing more with less. You still see some of these in simple applications like RF remote controls. The idea derives from how an oscillator works. In a simple way of thinking, an oscillator is an amplifier with enough positive feedback that any tiny signal at the right frequency will amplify and then, throu...
Get this one»

Hackaday Links: May 31, 2020

-
We begin with sad news indeed as we mark the passing of Marcel van Kervinck on Monday. The name might not ring a bell, but his project, the Gigatron TTL computer , certainly will. We did a deep dive on the microprocessor-less computer a while back, and Marcel was a regular at conferences and on the Gigatron forums, supporting users and extending what the computer can do. He was pretty candid about his health issues, and I’ll add that when I approached him a few weeks ago out of the blue about perhaps doing a Hack Chat about Gigatron, he was brutally honest about how little time he had left and that he wouldn’t make it that long. I was blown away by the grace and courage he displayed. His co-conspirator Walter Belger will carry on the Gigatron mission, including joining us for a Hack Chat on June 24. In the meantime, this might be a great time to pick up a Gigatron kit before they’re all sold out and get busy soldering all those delicious through-hole TTL chips. May of 2020 is the mo...
Get this one»

Homebrew 68K Micro-ATX Computer Runs Its Own OS

-
Image
We’re no stranger to home built Motorola 68000 computers here at Hackaday, but more often than not, they tend to be an experiment in retro minimalism. The venerable processor is usually joined by only a handful of components, and there’s an excellent chance they’ll have taken up residence on a piece of perfboard. Then [NotArtyom] sent in his Blitz , and launched the bar into the stratosphere. Make no mistake, the Blitz isn’t just some simple demo of classic chips. The open hardware motherboard has onboard floppy, IDE, and PS/2 interfaces, with a trio of 8-bit ISA expansion slots for good measure. The  Motorola 68030 CPU is humming along at 50 MHz, with 4 MB of RAM and 512 KB of ROM along for the ride. Designed to fit the Micro-ATX motherboard standard, you can even mount the Blitz in a contemporary PC case and run it on a standard ATX power supply. An earlier prototype of the Blitz motherboard. As if the hardware wasn’t impressive enough, [NotArtyom] went ahead and created hi...
Get this one»