6 ms·

A look at the die of the 8086 processor (2020)

217 points by guerrilla 5y ago

dehrmann 5y ago
How does the unused real estate compare to a modern CPU?
mysterydip 5y ago
Not dirrctly in the article, but a key change within Intel after the 4004 was removing the mandate that all chips be a 16 pin DIP. This severely limited performance of the 4004 by not having enough lines to do data etc in one clock, instead having to shift register and serialize it.
- guerrilla 5y ago
  I think it would have been impossible otherwise. It's still annoying with the multiplexed address and data pins in the DIP-40: you have to demultiplex them with latches and transcievers. And don't forget the 8088 (used in the PC) couldn't do data in one clock due to the 8-bit data bus (386SX was similar in the next step up.) Pretty cool for us that the 8086/8 are breadboardable though.
  - userbinator 5y ago
    They could've definitely put more shift registers on die and squeezed an 8086 in a DIP-16, but then the support circuitry would become even more complex. It's worth noting that the trend has been towards (high speed) serial buses in later CPUs, e.g. the Pentium 4 was the last generation to use a parallel FSB; that was replaced with the serial https://en.wikipedia.org/wiki/Direct_Media_Interface https://en.wikipedia.org/wiki/Direct_Media_Interface
    - guerrilla 5y ago
      Fair enough. I think the original Datapoint design for what became the 8008 was even entirely serial, including the memory. I guess I should have said it would have been exceptionally more annoying. It's hard enough to get a computer out of it. So it'd be impossible in the sense that they wouldn't have met the goal of getting that relatively easy kit out of it and there wouldn't have been any PC.
    - christkv 5y ago
      I think I remember that the reason we moved onto serial buses was due to the complexity of ensuring signal integrity for high speed signaling.
- retrac 5y ago
  The 8008, Intel's first 8-bit processor, direct ancestor to the 8080 and indirectly to the Z80 and 8086, also came in a far-too-small 18-pin package as well. In hindsight it seems rather inscrutable. Why were they hobbling their product like that? Well it seems just the arbitrary preference of one executive. But the seeming absurdity of it is partially an artifact of later thinking, from the era of single-chip microcontrollers. The 4004 and 8008 both needed a large amount of dedicated support electronics. Not just bus multiplexers, but clock drivers, special memory interfaces, etc. You couldn't turn an 8008 on without at least half a dozen support chips which were as much an integral part of the "computer" to the designers as the 8008 itself was. And while multiplexing brutally hindered the chip's performance, oddly enough pure performance doesn't seem to have been a major design goal for either the 4004 or 8008. Basically anything would be fast enough -- even multiplexed at 0.5 MHz -- for the industrial control and calculator-like applications envisioned.
  - ido 5y ago
    I think that's the real answer - they simply didn't think better performance mattered/would be worth the extra cost/complexity.
    - leeter 5y ago
      Looking at the 8008 wiki if the quotes are to be believed they were actually scared of performance. Believing that they would scare off customers buying intel memory (their main business at the time apparently) for their own in house processors. So it seems very deliberate. That said the 8008 was primarily intended for terminals where performance really wasn't a concern. But that didn't stop people from making proper mini-computers from it.
  - kjs3 5y ago
    According to Federico Faggin[1]: The 8008 used P-channel silicon gate MOS technology and was packaged in an 18-pin package: a very poor choice, imposed by Intel management’s aversion to high pin-count packages. [1]: http://www.intel4004.com/qa8008_8080.htm http://www.intel4004.com/qa8008_8080.htm
- kens 5y ago
  For details on how Intel was fixated on 16-pin chips, see the Oral History of Federico Faggin [1]. He describes how 16-pin packages were a completely silly requirement, but the "God-given 16 pins" was like a religion at Intel. He hated this requirement because it was throwing away performance. When Intel was forced to 18 pins by the 1103 memory chip, it "was like the sky had dropped from heaven" and he had "never seen so many long faces at Intel." [1] pages 55-56 of http://archive.computerhistory.org/resources/text/Oral_History/Faggin_Federico/Faggin_Federico_1_2_3.oral_history.2004.102658025.pdf http://archive.computerhistory.org/resources/text/Oral_Histo...
deleted 5y ago
[deleted]
mrlonglong 5y ago
I think Ken should take a look at the NEC V30, see how that stacks up against the venerable 8086. I'm already running a V30 as a coprocessor on my raspberry pi.
misnome 5y ago
(2020). Previous discussion: https://news.ycombinator.com/item?id=23553974 https://news.ycombinator.com/item?id=23553974
guerrilla 5y ago
This is part of a series [1] by the way. I really liked the one about the latches [2] and the die shrink photos are pretty cool. We always hear about it but here you get to see it. [3] 1. http://www.righto.com/search/label/8086 http://www.righto.com/search/label/8086 (Click Older Posts at the bottom to make sure you see all of them) 2. http://www.righto.com/2020/08/latches-inside-reverse-engineering.html http://www.righto.com/2020/08/latches-inside-reverse-enginee... 3. http://www.righto.com/2020/06/die-shrink-how-intel-scaled-down-8086.html http://www.righto.com/2020/06/die-shrink-how-intel-scaled-do...
the-dude 5y ago
If you squint a bit, it could be a castle.
tralarpa 5y ago
The article linked in the footnotes is well written. Also the comment of the editor on page 31. https://ieeexplore.ieee.org/document/6367944 https://ieeexplore.ieee.org/document/6367944
Koshkin 5y ago
> early microprocessors such as the 6502 and Z-80 didn't use microcode If you look at a die shot of the 6502, for example, you will see an area that looks confusingly similar to where microcode would be stored. Turns out, this is a PLA, not a microcode store. The best quick intro to microcoding that I have encountered is https://people.cs.clemson.edu/~mark/uprog.html https://people.cs.clemson.edu/~mark/uprog.html.
- guerrilla 5y ago
  The 8086's microcode has been disassembled (and is mostly documented) by the way [1] 1. https://www.reenigne.org/blog/8086-microcode-disassembled/ https://www.reenigne.org/blog/8086-microcode-disassembled/
- myself248 5y ago
  So where's the line drawn between instruction decoding, and microcoding? It sounds like microcoding is when a single instruction in the program resolves to a _sequence_ of operations that the processor executes?
  - pm215 5y ago
    It's a bit fuzzy and I don't think there's a single universally agreed on line. See the discussion in the "Microcode in RISC?" section of Ken's analysis of the ARM1 at http://www.righto.com/2016/02/reverse-engineering-arm1-processors.html?m=1 http://www.righto.com/2016/02/reverse-engineering-arm1-proce... -- Ken thinks that it makes sense to think of it as microcode or perhaps hybrid/partially microcoded, but the designers of this CPU didn't think of it like that and viewed it as a non-microcoded design...
  - Koshkin 5y ago
    Indeed, the difference is somewhat subtle, as explained here: https://retrocomputing.stackexchange.com/questions/15227/why-did-later-cpus-use-microcode-instead-of-plas https://retrocomputing.stackexchange.com/questions/15227/why...
  - adrian_b 5y ago
jcims 5y ago
Just a tangentially related plug for a youtube channel called Micrographia. It's from the same guy that does the Breaking Taps channel (also a great watch), but he did a tour of the 80486 with optical and SEM scopes. https://www.youtube.com/watch?v=OtA_9eYnj8U https://www.youtube.com/watch?v=OtA_9eYnj8U Not much content yet, but the other ones uploaded are also intrested if small details is your thing.
renox 5y ago
29000 transistors? But it's the same as an ARM2 which apparently was full 32bit and had an integer multiplier.
- fstrthnscnd 5y ago
  > 29000 transistors? But it's the same as an ARM2 which apparently was full 32bit and had an integer multiplier. It's a very good point. I think it's worth to ask a few questions in return. How many years separated the two designs? Does ARM2 support an equivalent ISA, in terms of features (not encoding)? For instance, the 8086 has support for BCD integers, specialized instructions for loops, the ability to use its registers as 16 bits or 8bits (doubling the register count in the later case).
  - nereye 5y ago
    Conversely, ARM2 had, for example, a barrel shifter, immediate constants, every instruction being conditional, etc., all of which are absent from 8086.
    - fstrthnscnd 5y ago
      My point exactly. They have different ISA, and as such cannot be compared on the transistor count alone. They each correspond to a different era, with different needs, as BCD clearly tells. If today's HW engineers had a chance to implement a small cpu core with the same tr count, would they come up with the same ISA as the ARM1 or 8086? Would they choose to implement integer division (DIV and IDIV in x86), or not and leave it to software (ARM)? Would they pick CISC, RISC, VLIW, or something else?
- retrac 5y ago
  ARM code is a fair bit bigger than 16 bit 8086 code, so there is that to consider. It makes total cost of ownership much higher when we're talking about systems with RAM measured in hundreds of kilobytes or single digit megabytes. But basically what you noticed is exactly why RISC swept everything else away in the late 80s to early 90s. If you have a 50,000 or 100,000 transistor budget and RAM is relatively cheap and fast, then complex microcoded designs really are a bad idea. You can get so, so much more performance out of a design like MIPS or ARM rather than an 80186, etc. Hindsight is 20/20. If you sent me back to 1976 - 77 in a time machine, I would propose not something like the 68000 or 8086, but something very much like MIPS, or Berkeley RISC (minus the register windows). It could have been done in the late 70s. It would have been easily 3 - 5x as fast per MHz, and could probably be clocked faster. Doing so just wasn't obvious until later. Everyone was trying to pack as much sophistication into the instruction set and architecture, to ease assembly language programming, as possible.
easton_s 5y ago
Many of the early software innovators names are known. Who was the team behind the 8086? Superficial googling gives all credit to "Intel" never listing any individuals who designed this thing.
- jecel 5y ago
  searching for "8086 design team" seems to get good results, including the Wikipedia article for the processor which lists names.
- andrewf 5y ago
  The Computer History Museum has some oral histories from folks who worked in this era. They don't have the 8086 design team, but they have different panels featuring people from the 8080, Z80, and 680x0 design teams. (Some from an 8086 marketing team too)
dehrmann 5y ago
Is there enough information in those pictures to reconstruct the circuits?
- kens 5y ago
  Yes, for the most part you can reconstruct the circuits from the photos. (Which I'm doing.) A key thing that doesn't show up is which transistors are enhancement and which are depletion; this depends on the doping. It's straightforward to figure this out from the layout, though. Except in the Z80 processor: the designers famously used some depletion transistors in unexpected places as "traps", so anyone who tried to clone the chip visually would encounter subtle failures. I'm pretty sure that 8086 didn't do that, though. The other aspect of your question is there's a lot of implicit manufacturing knowledge that you'd need if you tried to reconstruct the chip. Things like the resistance of the lines and the characteristics of the transistors that you'd need to get right for the chip to work reliably.
fstrthnscnd 5y ago
> Does the microcode contain any "junk code" that doesn't do anything? > It seems to! While most of the unused parts of the ROM (64 instructions) are filled with zeroes, there are a few parts which aren't. The following instructions appear right at the end of the ROM Could it be the signature of the microcode implementor?

217 points by guerrilla 5y ago

How does the unused real estate compare to a modern CPU?

Not dirrctly in the article, but a key change within Intel after the 4004 was removing the mandate that all chips be a 16 pin DIP. This severely limited performance of the 4004 by not having enough lines to do data etc in one clock, instead having to shift register and serialize it.

guerrilla 5y ago
I think it would have been impossible otherwise. It's still annoying with the multiplexed address and data pins in the DIP-40: you have to demultiplex them with latches and transcievers. And don't forget the 8088 (used in the PC) couldn't do data in one clock due to the 8-bit data bus (386SX was similar in the next step up.) Pretty cool for us that the 8086/8 are breadboardable though.
- userbinator 5y ago
  They could've definitely put more shift registers on die and squeezed an 8086 in a DIP-16, but then the support circuitry would become even more complex. It's worth noting that the trend has been towards (high speed) serial buses in later CPUs, e.g. the Pentium 4 was the last generation to use a parallel FSB; that was replaced with the serial https://en.wikipedia.org/wiki/Direct_Media_Interface https://en.wikipedia.org/wiki/Direct_Media_Interface
  - guerrilla 5y ago
    Fair enough. I think the original Datapoint design for what became the 8008 was even entirely serial, including the memory. I guess I should have said it would have been exceptionally more annoying. It's hard enough to get a computer out of it. So it'd be impossible in the sense that they wouldn't have met the goal of getting that relatively easy kit out of it and there wouldn't have been any PC.
  - christkv 5y ago
    I think I remember that the reason we moved onto serial buses was due to the complexity of ensuring signal integrity for high speed signaling.
retrac 5y ago
The 8008, Intel's first 8-bit processor, direct ancestor to the 8080 and indirectly to the Z80 and 8086, also came in a far-too-small 18-pin package as well. In hindsight it seems rather inscrutable. Why were they hobbling their product like that? Well it seems just the arbitrary preference of one executive. But the seeming absurdity of it is partially an artifact of later thinking, from the era of single-chip microcontrollers. The 4004 and 8008 both needed a large amount of dedicated support electronics. Not just bus multiplexers, but clock drivers, special memory interfaces, etc. You couldn't turn an 8008 on without at least half a dozen support chips which were as much an integral part of the "computer" to the designers as the 8008 itself was. And while multiplexing brutally hindered the chip's performance, oddly enough pure performance doesn't seem to have been a major design goal for either the 4004 or 8008. Basically anything would be fast enough -- even multiplexed at 0.5 MHz -- for the industrial control and calculator-like applications envisioned.
- ido 5y ago
  I think that's the real answer - they simply didn't think better performance mattered/would be worth the extra cost/complexity.
  - leeter 5y ago
    Looking at the 8008 wiki if the quotes are to be believed they were actually scared of performance. Believing that they would scare off customers buying intel memory (their main business at the time apparently) for their own in house processors. So it seems very deliberate. That said the 8008 was primarily intended for terminals where performance really wasn't a concern. But that didn't stop people from making proper mini-computers from it.
- kjs3 5y ago
  According to Federico Faggin[1]: The 8008 used P-channel silicon gate MOS technology and was packaged in an 18-pin package: a very poor choice, imposed by Intel management’s aversion to high pin-count packages. [1]: http://www.intel4004.com/qa8008_8080.htm http://www.intel4004.com/qa8008_8080.htm
kens 5y ago
For details on how Intel was fixated on 16-pin chips, see the Oral History of Federico Faggin [1]. He describes how 16-pin packages were a completely silly requirement, but the "God-given 16 pins" was like a religion at Intel. He hated this requirement because it was throwing away performance. When Intel was forced to 18 pins by the 1103 memory chip, it "was like the sky had dropped from heaven" and he had "never seen so many long faces at Intel." [1] pages 55-56 of http://archive.computerhistory.org/resources/text/Oral_History/Faggin_Federico/Faggin_Federico_1_2_3.oral_history.2004.102658025.pdf http://archive.computerhistory.org/resources/text/Oral_Histo...

deleted 5y ago

[deleted]

mrlonglong 5y ago

I think Ken should take a look at the NEC V30, see how that stacks up against the venerable 8086. I'm already running a V30 as a coprocessor on my raspberry pi.

misnome 5y ago

(2020). Previous discussion: https://news.ycombinator.com/item?id=23553974 https://news.ycombinator.com/item?id=23553974

guerrilla 5y ago

This is part of a series [1] by the way. I really liked the one about the latches [2] and the die shrink photos are pretty cool. We always hear about it but here you get to see it. [3] 1. http://www.righto.com/search/label/8086 http://www.righto.com/search/label/8086 (Click Older Posts at the bottom to make sure you see all of them) 2. http://www.righto.com/2020/08/latches-inside-reverse-engineering.html http://www.righto.com/2020/08/latches-inside-reverse-enginee... 3. http://www.righto.com/2020/06/die-shrink-how-intel-scaled-down-8086.html http://www.righto.com/2020/06/die-shrink-how-intel-scaled-do...

the-dude 5y ago

If you squint a bit, it could be a castle.

tralarpa 5y ago

The article linked in the footnotes is well written. Also the comment of the editor on page 31. https://ieeexplore.ieee.org/document/6367944 https://ieeexplore.ieee.org/document/6367944

Koshkin 5y ago

> early microprocessors such as the 6502 and Z-80 didn't use microcode If you look at a die shot of the 6502, for example, you will see an area that looks confusingly similar to where microcode would be stored. Turns out, this is a PLA, not a microcode store. The best quick intro to microcoding that I have encountered is https://people.cs.clemson.edu/~mark/uprog.html https://people.cs.clemson.edu/~mark/uprog.html.

guerrilla 5y ago
The 8086's microcode has been disassembled (and is mostly documented) by the way [1] 1. https://www.reenigne.org/blog/8086-microcode-disassembled/ https://www.reenigne.org/blog/8086-microcode-disassembled/
myself248 5y ago
So where's the line drawn between instruction decoding, and microcoding? It sounds like microcoding is when a single instruction in the program resolves to a _sequence_ of operations that the processor executes?
- pm215 5y ago
  It's a bit fuzzy and I don't think there's a single universally agreed on line. See the discussion in the "Microcode in RISC?" section of Ken's analysis of the ARM1 at http://www.righto.com/2016/02/reverse-engineering-arm1-processors.html?m=1 http://www.righto.com/2016/02/reverse-engineering-arm1-proce... -- Ken thinks that it makes sense to think of it as microcode or perhaps hybrid/partially microcoded, but the designers of this CPU didn't think of it like that and viewed it as a non-microcoded design...
- Koshkin 5y ago
  Indeed, the difference is somewhat subtle, as explained here: https://retrocomputing.stackexchange.com/questions/15227/why-did-later-cpus-use-microcode-instead-of-plas https://retrocomputing.stackexchange.com/questions/15227/why...
- adrian_b 5y ago

jcims 5y ago

Just a tangentially related plug for a youtube channel called Micrographia. It's from the same guy that does the Breaking Taps channel (also a great watch), but he did a tour of the 80486 with optical and SEM scopes. https://www.youtube.com/watch?v=OtA_9eYnj8U https://www.youtube.com/watch?v=OtA_9eYnj8U Not much content yet, but the other ones uploaded are also intrested if small details is your thing.

renox 5y ago

29000 transistors? But it's the same as an ARM2 which apparently was full 32bit and had an integer multiplier.

fstrthnscnd 5y ago
> 29000 transistors? But it's the same as an ARM2 which apparently was full 32bit and had an integer multiplier. It's a very good point. I think it's worth to ask a few questions in return. How many years separated the two designs? Does ARM2 support an equivalent ISA, in terms of features (not encoding)? For instance, the 8086 has support for BCD integers, specialized instructions for loops, the ability to use its registers as 16 bits or 8bits (doubling the register count in the later case).
- nereye 5y ago
  Conversely, ARM2 had, for example, a barrel shifter, immediate constants, every instruction being conditional, etc., all of which are absent from 8086.
  - fstrthnscnd 5y ago
    My point exactly. They have different ISA, and as such cannot be compared on the transistor count alone. They each correspond to a different era, with different needs, as BCD clearly tells. If today's HW engineers had a chance to implement a small cpu core with the same tr count, would they come up with the same ISA as the ARM1 or 8086? Would they choose to implement integer division (DIV and IDIV in x86), or not and leave it to software (ARM)? Would they pick CISC, RISC, VLIW, or something else?
retrac 5y ago
ARM code is a fair bit bigger than 16 bit 8086 code, so there is that to consider. It makes total cost of ownership much higher when we're talking about systems with RAM measured in hundreds of kilobytes or single digit megabytes. But basically what you noticed is exactly why RISC swept everything else away in the late 80s to early 90s. If you have a 50,000 or 100,000 transistor budget and RAM is relatively cheap and fast, then complex microcoded designs really are a bad idea. You can get so, so much more performance out of a design like MIPS or ARM rather than an 80186, etc. Hindsight is 20/20. If you sent me back to 1976 - 77 in a time machine, I would propose not something like the 68000 or 8086, but something very much like MIPS, or Berkeley RISC (minus the register windows). It could have been done in the late 70s. It would have been easily 3 - 5x as fast per MHz, and could probably be clocked faster. Doing so just wasn't obvious until later. Everyone was trying to pack as much sophistication into the instruction set and architecture, to ease assembly language programming, as possible.

easton_s 5y ago

Many of the early software innovators names are known. Who was the team behind the 8086? Superficial googling gives all credit to "Intel" never listing any individuals who designed this thing.

jecel 5y ago
searching for "8086 design team" seems to get good results, including the Wikipedia article for the processor which lists names.
andrewf 5y ago
The Computer History Museum has some oral histories from folks who worked in this era. They don't have the 8086 design team, but they have different panels featuring people from the 8080, Z80, and 680x0 design teams. (Some from an 8086 marketing team too)

dehrmann 5y ago

Is there enough information in those pictures to reconstruct the circuits?

kens 5y ago
Yes, for the most part you can reconstruct the circuits from the photos. (Which I'm doing.) A key thing that doesn't show up is which transistors are enhancement and which are depletion; this depends on the doping. It's straightforward to figure this out from the layout, though. Except in the Z80 processor: the designers famously used some depletion transistors in unexpected places as "traps", so anyone who tried to clone the chip visually would encounter subtle failures. I'm pretty sure that 8086 didn't do that, though. The other aspect of your question is there's a lot of implicit manufacturing knowledge that you'd need if you tried to reconstruct the chip. Things like the resistance of the lines and the characteristics of the transistors that you'd need to get right for the chip to work reliably.

fstrthnscnd 5y ago

> Does the microcode contain any "junk code" that doesn't do anything? > It seems to! While most of the unused parts of the ROM (64 instructions) are filled with zeroes, there are a few parts which aren't. The following instructions appear right at the end of the ROM Could it be the signature of the microcode implementor?