5 ms·

Reverse-engineering the adder inside the Intel 8086

30 points by parsecs 6y ago

kens 6y ago
Author here, if anyone has questions.
- Someone 6y ago
  “While the progress of Moore's law has yielded great improvements in modern processors, the processors of the 1970s are much better for reverse engineering.” I expect future hobbyists will want to reverse engineer the hardware they used in their youth. I have the impression most of today’s reverse engineering is manual. Even if it’s already software-assisted, what would future researchers tackling much larger CPUs need most? I can imagine, for example, software that, given an image of a transistor, finds all similar transistors on the die, or software that detects adders or multipliers, or software that finds major pathways on the die (e.g. to automatically trace the route the clock signal takes)
  - kens 6y ago
    For future reverse-engineering, I think the biggest problem will be imaging. I can study processors up to about 1980 with an inexpensive microscope. But chips with two layers (or more) of metal are much harder to examine, because the metal layers block each other. And once transistors get too small for optical microscopes (1990s), you need an electron microscope, which is a much bigger investment. (Although there are hobbyists who have one.) The other factor is understanding. A chip like the Z-80 is simple enough that one person can understand it completely. I doubt any single person at Intel understands everything about the Xeon, since it is so complex. And it's much harder to understand the chip from reverse engineering. (That assumes the goal of reverse engineering is to understand the chip. Emulating the chip is a different story, since you don't need to understand what's going on. In other words, it's the difference between understanding how the 6502 works and looking at the visual 6502 simulator.) As for software, I've hacked up various tools for my reverse engineering. I draw out the chip layers manually and then feed the layers into a program that finds transistors and connected components, so I have a raw connection map. Then another program finds all the gates. From that point, it's mainly manual, tracing out the gates and trying to figure out what they are doing. I'll make one-off scripts to help with various things. For instance, when I figure out how the chip implements a latch, I'll write a program to scan for latches. One of the biggest problems is errors, since I'll miss connections, short wires together, or so forth. Even if I'm 99% accurate, the 8086 has 29,000 transistors so there are a lot of errors. So I spend a lot of time looking at circuitry that makes no sense, then realizing that I left out a wire or something.
- ncmncm 6y ago
  Has enough time passed yet to acknowledge that the x86 ISA is a really bad design?
  - kens 6y ago
    The funny thing is that the Intel 8800 (iAPX 432) was supposed to be Intel's big new thing, a 32-bit processor designed for object-oriented languages. Unfortunately, that project fell behind schedule and Intel quickly threw together a chip, the 8086, so they'd have something to sell until the iAPX 432 was ready. Unexpectedly, the 8086 took over the world and the iAPX 432 was a failure. The bad design that shipped beat the good design that was late and slow. Intel repeated this with the Itanium, their super new design that was supposed to take over in 2001. Again, the superior design was slow, late, and a market failure. I'm not sure what the moral of this is. Maybe it illustrates the "worse is better" principle.
    - rhabarba 6y ago
      Ironically, 32-bit machines were already over and done when Intel made theirs.
      - ncmncm 6y ago
        I don't understand this claim. ARM won mobile with 32 bits. The 64-bit designs existed largely because they were keeping out of Intel's way.
    - deleted 6y ago
      [deleted]
    - ncmncm 6y ago
      "Worse is better" always covers up facts that are too embarrassing to somebody to say out loud. In the case of x86, Intel's, then IBM's, then Microsoft's thumbs were firmly on the scale. It collapsed vs. amd64 because their thumbs were off.
    - jecel 6y ago
      Intel likes to pretend that the iAPX432 never happened. Some friends and I were waiting for it to be released to build a machine around it, but then the Berkeley RISC papers came out with their benchmarks. Even though the 8086 was far slower than RISC I it was still so much faster than the 432 that we dropped our plans. Intel had been proposing that the 8086 would be an i/o controller for the 432 but now this would be like having your keyboard processor be much faster than your CPU. The second version (i960) kept the good parts of the iAPX432 while making it very competitive but by then the PC had made that irrelevant.
Stierlitz 6y ago
> multiple offset/segment combinations could address the same physical memory address. Would this have anything to do with memory exploits on the entire x86 range of processors?
supernova87a 6y ago
I'm curious to know whether (if you live in the Silicon Valley area) you have gotten access to talk to people who could share the original intent/design of the circuits you study? I.e. to see how close you got it or left out any observations? It would be interesting to learn how they actually intended the design to work and why it looks the way it does, compared to what you found! Or is the idea really more to see what can be discerned by someone receiving the chip and trying to sleuth out what connections and parts do what?
jecel 6y ago
> The 68000 had address adders, separate from the ALU. It actually had a 16 bit "complex ALU" and two 16 bit adders (or the other way around - I can't get to my old documents in my office). The ALU was for the D registers, one of the adders was for the A registers and the last one could be shared for both to add bits 16 to 31. You could do a one cycle addition of an address in parallel with a one cycle ALU operation on 16 bits of a data register (very common) or two cycles for 32 bits. You could also do a 32 bit add on a data register in a single cycle if you were not also calculating an address. So you could crunch 48 bits per clock.
jhallenworld 6y ago
I'm amazed at the large fraction of the die area that the adder takes.
- kens 6y ago
  Yes, it gives you an idea of the simple building blocks that make up the 8086. In a modern processor, the blocks on the die are a floating point unit or something. But on the 8086, the blocks are things like an adder or latch.
egsmi 6y ago
It’s surprising, to me, that the address adder and the ALU are so comparable in area. I’m guessing the adder is like 1/3 the size of the ALU even though the ALU has so much more functionality. My guess is the flip flops needed to register the operands and resultant compromise a significant chunk of the area in both and the extra 2/3 area in the ALU is the area of the combinational logic to implement all the extra math functions.

30 points by parsecs 6y ago

kens 6y ago

Author here, if anyone has questions.

Someone 6y ago
“While the progress of Moore's law has yielded great improvements in modern processors, the processors of the 1970s are much better for reverse engineering.” I expect future hobbyists will want to reverse engineer the hardware they used in their youth. I have the impression most of today’s reverse engineering is manual. Even if it’s already software-assisted, what would future researchers tackling much larger CPUs need most? I can imagine, for example, software that, given an image of a transistor, finds all similar transistors on the die, or software that detects adders or multipliers, or software that finds major pathways on the die (e.g. to automatically trace the route the clock signal takes)
- kens 6y ago
  For future reverse-engineering, I think the biggest problem will be imaging. I can study processors up to about 1980 with an inexpensive microscope. But chips with two layers (or more) of metal are much harder to examine, because the metal layers block each other. And once transistors get too small for optical microscopes (1990s), you need an electron microscope, which is a much bigger investment. (Although there are hobbyists who have one.) The other factor is understanding. A chip like the Z-80 is simple enough that one person can understand it completely. I doubt any single person at Intel understands everything about the Xeon, since it is so complex. And it's much harder to understand the chip from reverse engineering. (That assumes the goal of reverse engineering is to understand the chip. Emulating the chip is a different story, since you don't need to understand what's going on. In other words, it's the difference between understanding how the 6502 works and looking at the visual 6502 simulator.) As for software, I've hacked up various tools for my reverse engineering. I draw out the chip layers manually and then feed the layers into a program that finds transistors and connected components, so I have a raw connection map. Then another program finds all the gates. From that point, it's mainly manual, tracing out the gates and trying to figure out what they are doing. I'll make one-off scripts to help with various things. For instance, when I figure out how the chip implements a latch, I'll write a program to scan for latches. One of the biggest problems is errors, since I'll miss connections, short wires together, or so forth. Even if I'm 99% accurate, the 8086 has 29,000 transistors so there are a lot of errors. So I spend a lot of time looking at circuitry that makes no sense, then realizing that I left out a wire or something.
ncmncm 6y ago
Has enough time passed yet to acknowledge that the x86 ISA is a really bad design?
- kens 6y ago
  The funny thing is that the Intel 8800 (iAPX 432) was supposed to be Intel's big new thing, a 32-bit processor designed for object-oriented languages. Unfortunately, that project fell behind schedule and Intel quickly threw together a chip, the 8086, so they'd have something to sell until the iAPX 432 was ready. Unexpectedly, the 8086 took over the world and the iAPX 432 was a failure. The bad design that shipped beat the good design that was late and slow. Intel repeated this with the Itanium, their super new design that was supposed to take over in 2001. Again, the superior design was slow, late, and a market failure. I'm not sure what the moral of this is. Maybe it illustrates the "worse is better" principle.
  - rhabarba 6y ago
    Ironically, 32-bit machines were already over and done when Intel made theirs.
    - ncmncm 6y ago
      I don't understand this claim. ARM won mobile with 32 bits. The 64-bit designs existed largely because they were keeping out of Intel's way.
  - deleted 6y ago
    [deleted]
  - ncmncm 6y ago
    "Worse is better" always covers up facts that are too embarrassing to somebody to say out loud. In the case of x86, Intel's, then IBM's, then Microsoft's thumbs were firmly on the scale. It collapsed vs. amd64 because their thumbs were off.
  - jecel 6y ago
    Intel likes to pretend that the iAPX432 never happened. Some friends and I were waiting for it to be released to build a machine around it, but then the Berkeley RISC papers came out with their benchmarks. Even though the 8086 was far slower than RISC I it was still so much faster than the 432 that we dropped our plans. Intel had been proposing that the 8086 would be an i/o controller for the 432 but now this would be like having your keyboard processor be much faster than your CPU. The second version (i960) kept the good parts of the iAPX432 while making it very competitive but by then the PC had made that irrelevant.

Stierlitz 6y ago

> multiple offset/segment combinations could address the same physical memory address. Would this have anything to do with memory exploits on the entire x86 range of processors?

supernova87a 6y ago

I'm curious to know whether (if you live in the Silicon Valley area) you have gotten access to talk to people who could share the original intent/design of the circuits you study? I.e. to see how close you got it or left out any observations? It would be interesting to learn how they actually intended the design to work and why it looks the way it does, compared to what you found! Or is the idea really more to see what can be discerned by someone receiving the chip and trying to sleuth out what connections and parts do what?

jecel 6y ago

> The 68000 had address adders, separate from the ALU. It actually had a 16 bit "complex ALU" and two 16 bit adders (or the other way around - I can't get to my old documents in my office). The ALU was for the D registers, one of the adders was for the A registers and the last one could be shared for both to add bits 16 to 31. You could do a one cycle addition of an address in parallel with a one cycle ALU operation on 16 bits of a data register (very common) or two cycles for 32 bits. You could also do a 32 bit add on a data register in a single cycle if you were not also calculating an address. So you could crunch 48 bits per clock.

jhallenworld 6y ago

I'm amazed at the large fraction of the die area that the adder takes.

kens 6y ago
Yes, it gives you an idea of the simple building blocks that make up the 8086. In a modern processor, the blocks on the die are a floating point unit or something. But on the 8086, the blocks are things like an adder or latch.

egsmi 6y ago

It’s surprising, to me, that the address adder and the ALU are so comparable in area. I’m guessing the adder is like 1/3 the size of the ALU even though the ALU has so much more functionality. My guess is the flip flops needed to register the operands and resultant compromise a significant chunk of the area in both and the extra 2/3 area in the ALU is the area of the combinational logic to implement all the extra math functions.