Reverse-engineering the adder inside the Intel 8086 | Hacker News Reader

Reverse-engineering the adder inside the Intel 8086

righto.com

30 pointspicture18 comments

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

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.

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?

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

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.

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

Author here, if anyone has questions.

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

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.

Has enough time passed yet to acknowledge that the x86 ISA is a really bad design?

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.

Ironically, 32-bit machines were already over and done when Intel made theirs.

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.

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

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.

Itanium 2 and beyond were fast, but no argument that it failed. Even so I read that HP took final orders for Itanium systems this year.

SPEC benchmarks fom 2003:

    CINT2000
    Itanium 2 1.5 GHz - 1322
    Xeon 3.06 GHz - 1242
    Opteron 1.8 GHz - 1095

    CFP2000
    Itanium 2 1.5 GHz - 2119
    Xeon 3.06 GHz - 1173
    Opteron 1.8 GHz - 1122

Amd64 caught up and passed it when?

I understand this opinion, but don't agree with it at all.

There were two killer features of the 8086:

First was that you could translate your 8080 and Z-80 CP/M programs to it without too much work. So for example, the IBM PC immediately had WordStar, Visicalc and DBase. I found an interesting example of the process here:

https://github.com/billforsternz/retro-sargon#yet-more-detai...

(But this actually converts Z-80 to 32-bit x86.)

Second killer feature is the hated segment registers. Yes, they are annoying, but they provide a rudimentary form of built-in memory management. So for example, you can run UNIX on x86, but you can not on 68000 which has no memory management. [Well you could with extra hardware: Trs-80 model 16 could run Xenix, but had an external memory manager. Also, you could use PC-relative code, but with a performance penalty- this is how OS-9 worked even on an 8-bit 6809].

Reply on news.ycombinator.com