
A look at the die of the 8086 processor - magnat
http://www.righto.com/2020/06/a-look-at-die-of-8086-processor.html
======
miohtama
Do we have any hope for garbage collecting CPUs 40 years later or are they a
doomed venture?

> In 1975, Intel's next big plan was the 8800 processor designed to be Intel's
> chief architecture for the 1980s. This processor was called a
> "micromainframe" because of its planned high performance. It had an entirely
> new instruction set designed for high-level languages such as Ada, and
> supported object-oriented programming and garbage collection at the hardware
> level.

~~~
nullc
I'd much rather have a security-oriented processor with tagged bounds checked
pointers... such a facility could _also_ make garbage collecting more
efficient, but what it could do for security would be wonderful.

~~~
kens
The 8800 (iAPX 432) provided bounds checking too. Every object reference
wasn't a pointer but an "Access Descriptor" that included permissions. So you
couldn't access anything out of bounds. I should emphasize that this isn't
like a JVM, but was implemented at the machine instruction level. It's hard to
understand how strange and radical this processor was.

[https://en.wikipedia.org/wiki/Intel_iAPX_432#Object-
oriented...](https://en.wikipedia.org/wiki/Intel_iAPX_432#Object-
oriented_memory_and_capabilities)

~~~
Icathian
Every time I hear about abandoned "improved" tech like this, I always wonder
why the idea was shelved. The link kinda handwaves it away. Any good resources
on why the idea didn't take off?

~~~
pwg
You'd probably have to find an Intel insider to know the real truth.

But the most likely possibility is that the plan was too grand for the time
(note, this was 197x to ~ 1984ish, the IBM PC with its 8088 had only been on
the market about three or so years) and therefore much too expensive for any
market to bear.

Additionally, the iAPX432 was being worked upon during the same time that the
IBM PC suddenly brought the x86 chips to _significant_ popularity.

Combine the concepts of pouring money into an arch. that was too big and
grandiose for the integration tech. at the time, with a sudden influx of
profit from the x86 chip line, and it seems that a likely reason was simply to
devote resources to the chip line that was suddenly producing those same
resources.

The Wikipedia page
([https://en.wikipedia.org/wiki/IAPX432](https://en.wikipedia.org/wiki/IAPX432))
also says this about the '432:

"Using the semiconductor technology of its day, Intel's engineers weren't able
to translate the design into a very efficient first implementation. Along with
the lack of optimization in a premature Ada compiler, this contributed to
rather slow but expensive computer systems, performing typical benchmarks at
roughly 1/4 the speed of the new 80286 chip at the same clock frequency (in
early 1982).[7] This initial performance gap to the rather low-profile and
low-priced 8086 line was probably the main reason why Intel's plan to replace
the latter (later known as x86) with the iAPX 432 failed. Although engineers
saw ways to improve a next generation design, the iAPX 432 capability
architecture had now started to be regarded more as an implementation overhead
rather than as the simplifying support it was intended to be."

~~~
Gibbon1
That makes sense. I remember absolutely huge data sheets and reference manuals
for the IAPX432. So it's very possible that Intel didn't think hard about re-
licensing the somewhat janky 0x86 design because they expected it to be a dead
end.

~~~
csharptwdec19
Historically speaking, I'm not sure if Intel ever -wanted- to license x86.

The main reason that AMD (and others) manufactured x86 CPUs early on was
because IBM had a 'second source' requirement; i.e. there had to be another
vendor who could provide the same part.

So an AMD 286 was no different from an Intel 286.

By the time of the 386, IBM had relaxed/dropped the second-source requirement.
Thus the Am386 isn't the same design as the i386 (and there was a court battle
to try to keep the AMD part out of the market.)

tl;dr - Intel never wanted to license at all.

~~~
rasz
Am386 was reverse engineered design, but microcode was 1:1 Intel copy :).
There was no court battle over this chip. Intel was forced into arbitration
due to second source agreements, and lost.

Court battle was over 287 and later Am486. AMD announced clean-room design ...
and gave their clean room engineers 386 microcode copy :]

[https://www.sec.gov/litigation/admin/3437730.txt](https://www.sec.gov/litigation/admin/3437730.txt)

------
drmpeg
I used the CONV-86 8080 to 8086 converter tool mentioned in the article on a
project back in 1983. It really worked quite well, with hardly any fixup
required on a fairly large (at that time) code base.

I remember thinking that the 8088 (in the IBM PC) was a speed demon compared
to the 8080 (in the CP/M system I was converting from).

~~~
billforsternz
I tried to track down that converter for a retro computing project about 10
years ago and failed; [https://stackoverflow.com/questions/2038929/where-can-
i-find...](https://stackoverflow.com/questions/2038929/where-can-i-
find-a-8080-to-x86-assembler-conversion-tool)

A few months ago I returned to the project and completed it this time;
[https://github.com/billforsternz/retro-
sargon](https://github.com/billforsternz/retro-sargon)

As I should have realised the first time, you can write your own converter in
an afternoon or two :-)

~~~
drmpeg
CONV-86 came on 8" floppy disk for the ISIS-II operating system on Intel MDS
development boxes. Even if you found a copy, you'd need an MDS-80 to run it
on.

After the IBM PC came out, everyone tossed their MDS-80 systems when Intel
started to provide their tools on MS-DOS.

With the current interest in retro computing, I wish I had saved more stuff
from back then. I kick myself for not saving an Intel i960CA evaluation board
that I used in 1992. I loved the i960 architecture and developed quite a few
products with it.

However, I still have the processor from that board because I replaced it with
an i960CF.

[http://www.w6rz.net/IMG_0035.JPG](http://www.w6rz.net/IMG_0035.JPG)

~~~
billforsternz
The funny thing is, back in the day I wrote a 8080 emulator that could run
CP/M programs on MS-DOS, and then I went the extra mile and adapted it to run
ISIS-II programs for the Intel blue boxes we had. There were some 8051 Dev
tools I thought were worth bringing over. But that would have been in the 80s,
and the 8 inch drives went to the landfill decades ago. So yeah.

~~~
rwmj
Of course if you had a NEC V20/V30 (pin-compatible 8086 clone), it had a
special mode for running 8080 code! It couldn't run Z80 code because it lacked
the extensions like LDIR.

~~~
billforsternz
If you read the GitHub page I linked to earlier you'll see I digress as far as
a discussion of the NEC V20 :)

------
mrlonglong
You gotta love that weird segmented memory model though, to allow it to
address up to 1MB of RAM using 20 lines, combining a pair of 16 bit registers
to generate the 20 bit address. The Motorola 680x0 was a bit saner.

~~~
kabdib
I think that the face of computing would have changed quite dramatically if
Intel had decided to make the x86 segment paragraph size 256 bytes (8 bits)
instead of the useless 4 bits. Imagine not having a 640K (or 1MB) ceiling
(without hacks like "expanded" or "extended" memory). It would not have been a
big deal for Intel to do this; I'm pretty sure they could have multiplexed
four more pins worth of address lines.

It would have given the x86 a native 24MB address space, equal to the 68000's
physically provisioned 24 bits (which is all most 68K systems supported
anyway, certainly the Atari ST and the Mac).

For instance, in the mid 80s, VisiCorp was trying really, really hard to fit
their products into 640K. They had some whizzy stuff, but the address space
problem pretty much killed them. Later, Microsoft and IBM came along, did the
disgusting memory-space hacks that plagued users for a decade or more, and
VisiCorp foundered.

~~~
Someone
_“It would have given the x86 a native 24MB address space, equal to the 68000
's physically provisioned 24 bit”_

That would be 16MB (plus possibly 65,536-256 bytes, depending on whether they
added a bug on address wraparound
([https://en.wikipedia.org/wiki/A20_line)](https://en.wikipedia.org/wiki/A20_line\))).

Also, the 68000 would still have the clearer upgrade path, as the 24 address
lines restriction was in the design of the chip, not in its architecture. As
long as code didn’t assume addresses were modulo 2²⁴, code would run
unmodified on a CPU with over 16MB memory, and use all of it.

Also, the idea with the 8086 was that programs would actually use 16-bit
pointers for objects, not 20-bit ones. That would be wasteful of memory if the
granularity of such addresses were 256 bytes.

~~~
kabdib
I meant 16MB, of course. Duh.

Argument still stands.

------
the_af
This is a fascinating article!

I remember back in my early CS courses where the teacher explained "microcode
is this or that" and it sounded so _dry_. He could have explained microcode
was magical goblins for all I cared. It didn't help that I knew nothing (and
still don't) about circuitry.

But actually seeing _registers_ and _microcode_ there in the photo is amazing.
All this stuff I was taught about actually has a physical form that can be
seen!

The lowly 8086 really went a long way from its humble origins.

~~~
Koshkin
Yeah... Almost like a cute cub to a carnivorous monster.

~~~
the_af
Or from mogwai to gremlin ;)

------
Koshkin
> _the 6502... didn 't use microcode_

Hmm, the top part of the die shot looks like microcode to me:

[http://visual6502.org/images/6502/6502_top_op10x_BF_4677.png](http://visual6502.org/images/6502/6502_top_op10x_BF_4677.png)

~~~
kens
The 6502 has a PLA, as do many other early microprocessors such as the 6800,
8080, and Z-80. The PLA is a structured arrangement of logic gates, rather
than a microcode ROM. But they both have a similar grid-like appearance.

~~~
rwmj
Of course you're the expert here, but isn't this a little nitpicking? The
decode logic of the Z80 (from your site[1]) works in much the same way as
microcode by stepping through a set of fixed "instructions".

[1]
[http://static.righto.com/images/z80/z80_labeled_bus_addr.png](http://static.righto.com/images/z80/z80_labeled_bus_addr.png)

~~~
pwg
> Of course you're the expert here, but isn't this a little nitpicking?

No, a PLA [1] and a microcode ROM are two very different animals.

A PLA is a way of compactly specifying combinatorial logic circuits
(arrangements of and/or/etc. gates) and in the form that gave it the name, it
is end user programmable (the P stands for Programmable). But at its heart, a
PLA is just a big arrangement of logic gates. A signal goes in, and after the
necessary gate delays settle, the result signal comes out.

Microcode is literally a "program" and is 'executed' in the same way that all
other programs are executed, one instruction at a time, addressed by a program
counter. There are also often branching instructions that generate new program
counter values to use to sequence through the various steps. None of which
exists in a PLA.

The appearance of similarity arises because both look similar in a silicon die
photo (rows and columns of transistors), but they are very different and
perform quite different functions on the chip.

[1]
[https://en.wikipedia.org/wiki/Programmable_logic_array](https://en.wikipedia.org/wiki/Programmable_logic_array)

~~~
Taniwha
I suspect that at the time microcode was copyrightable while masks (and
therefore PLAs) were not (note the actual (C) message on the die explicitly
calling out the microcode)

~~~
miohtama
Is 8086 microcode reverse engineered or released today for studying?

~~~
kiwidrew
Not yet, but with these new high-resolution die photos it is only a matter of
time.

Meanwhile the US4449184 patent [1] referenced in the post's footnotes has a
lot of information about how the microcode works (and the meaning of the 21
instruction bits) and, in Tables 7-12, shows the microcode listings for some
of the microcoded 8086 instructions.

[1]
[https://patents.google.com/patent/US4449184](https://patents.google.com/patent/US4449184)

------
bogomipz
Wow another great post!

I had a question about the following passage:

>"The photo above shows part of the microcode ROM. Under a microscope, the
contents of the microcode ROM are visible, and the bits can be read out, based
on the presence or absence of transistors in each position. The ROM consists
of 512 micro-instructions, each 21 bits wide."

I was curious why 21 bits? I would have expected this would have been a
multiple or instruction size or perhaps also 16 bits. Or is there really no
correlation between size of an instruction and it's underlying micro-ops?

One other question I had was in regards to the "Closeup of some transistors in
the 8086" photo where the author states:

>"The circles are connections (called vias) between the silicon layer and the
metal wiring, while the small squares are connections between the silicon
layer and the polysilicon."

Vias are alway vertical correct? So are we looking at the chip from the top
looking downward then? Why don't we see the metal layers then? Or do the metal
wires themselves constitute the metal layer?

~~~
kens
Why 21 bits? The first factor is there is absolutely no need for an
instruction to be 8, 16, or 32 bits. Modern processors use these sizes to be
compatible with the 8-bit byte, but older processors used whatever word size
was convenient: 12 bits, 13 bits, 17 bits, 27 bits, or pretty much anything.

The second factor is that (as you suspect) there isn't any connection between
the size of the machine instructions and the size of the micro-instructions.

Finally, the width of a micro-instruction depends on how much you want to
control at once. You can have a micro-instruction that is 100 bits wide,
letting the processor do different things in parallel (e.g. IBM 360
mainframe), or a very short micro-instruction that doesn't do very much. The
choice of 21 bits is enough for each micro-instruction to do two things (a
data transfer and an operation). Having a 100-bit wide micro-instruction would
improve performance but make the ROM too large, so it is a tradeoff. (Lookup
vertical and horizontal microcode for more information.)

For your second question, the photos are all looking downward onto the chip
through a microscope. In the first die photo, you're looking at the metal
layer. But in the closeup photo, I've removed the metal and polysilicon layers
with acid, so you see the silicon layer. It's tricky to show how all the
overlapping layers are connected, so I didn't do that in this post. But I have
another post that shows how the layers work together in the 6502:
[http://www.righto.com/2013/01/a-small-part-of-6502-chip-
expl...](http://www.righto.com/2013/01/a-small-part-of-6502-chip-
explained.html)

~~~
bogomipz
>"Modern processors use these sizes to be compatible with the 8-bit byte, but
older processors used whatever word size was convenient: 12 bits, 13 bits, 17
bits, 27 bits, or pretty much anything."

Indeed. I guess it's easy to forget that processor in the 1950s up until
1970's or really before the microprocessor era were all over the map with word
sizes.

Thanks for the clarification of the die photo. That makes sense.

By the way I really enjoy these posts and the discussions. Keep up the great
work. Cheers.

------
samstave
You can get exposed chip dies on keychains from the intel merch store, which
when i worked there i believe was in SC5 building.

We had hige prints of the designs of many chips on the wall in our lab.

They were super cool looking.

I always regretted not taking some home.

Before multi-cores existed, i recall asking some colleagues there, “why cant
we just stack multiple cpus on top of eachother?”

~~~
rwmj
_> Before multi-cores existed, i recall asking some colleagues there, “why
cant we just stack multiple cpus on top of eachother?”_

I guess you know this already, but the answer is you were right. You can, but
heat dissipation is a real problem. The technique is called 3D ICs.
[https://semiengineering.com/stacked-die-
changes/](https://semiengineering.com/stacked-die-changes/)
[https://en.wikipedia.org/wiki/Three-
dimensional_integrated_c...](https://en.wikipedia.org/wiki/Three-
dimensional_integrated_circuit)

~~~
samstave
Yeah - basically, a (like a couple years, that first comment was made in
~1998) while after that comment I went on a hike with a guy in research and we
were talking about then secret research that was happening - and he stated
they had a 64 core version (yes, 64 cores - but I do not know how functional
this test chip was - just that the number of cores was 64) on a test chip that
could function.

This was in ~2002 or so? I cant recall.

But the compute power was low - it was more about the interconnects, IIRC?

Anyway -- I ran the gaming lab and was responsible for testing games with SIMD
instruction optimizations against games on the first celeron and pentium based
CPUS to determine if they passed a subjective muster, as intel would give a
company $1MM in marketing funding if they advertised their games as being opt
for intel procs...

My greatest claims from intel was:

I never once sat in my cube.

I had the same pee schedule as Andy Grove and for some reason, like every
single time I went pee... he was there also and we peed "together"

The most I ever said to the Titan was "Hi How Are You" GOTO 10 "Oh Shit, He Is
Here Again"

------
mmastrac
I'm excited for someone to actually reverse engineer that 8086 microcode.
Curious what might come out of that.

~~~
kens
Yes, it will be interesting to look at the microcode. Intel's 8086 patent
discusses the microcode in some detail and gives examples of the microcode for
a few instructions. So I'm not expecting any huge surprises.

[https://patents.google.com/patent/US4449184](https://patents.google.com/patent/US4449184)

~~~
saagarjha
Do you have any sort of automated technique to extract microcode from a
picture, or do you do it all by hand?

~~~
rasz
[http://caps0ff.blogspot.com/](http://caps0ff.blogspot.com/) guys have a
collaboration tool and they often ask people to help with filling/validating
mask image to bits conversion

------
mobilio
And what about 8088? Because it become more popular due 8 bit I/O data
channel.

~~~
kens
I've ordered an 8088 so I can compare the internal circuitry of the chips.
They should be mostly the same, except that the 8088 has an 8-bit data bus
externally and has 4 bytes of prefetch buffer instead of 6.

~~~
Taniwha
remember that the address and data pins are multiplexed - the 8088 and 8086
have the same number of pins

My guess is that the prefetch buffer is always 6 bytes but the 8088 fetches
instructions more slowly and never fills it past 4 instructions

I think they're probably the same die, the thing to look for is whether
there's a bonding difference

~~~
robocat
> I think they're probably the same die

Very unlikely. The 8088 was developed after the 8086, and there are more pin
differences including m/io inverting to io/m.

~~~
mrlonglong
Now I really want to get a 8086 on a bread board and see if I can do things
with it! What else do I need to put on the breadboard to build a minimum
computer?

~~~
mlaux
Probably just a voltage regulator, a clock source, reset pin logic, a couple
ROM chips (2 8-bit wide chips or 1 16-bit wide), some static RAM, a
PAL/GAL/74xx logic for address decoding and chip select pins, stuff to deal
with the multiplexing, and whatever input/output you want (bus buffers for
parallel I/O, off the shelf UART chips, etc)

I’ve only done it with the 6502 and Z80, but the 8086 shouldn’t be too much
harder. There are plenty of resources available online for those two chips
that you could adapt!

------
haecceity
How can you tell what section is the adder by the shape of wirings?

~~~
kens
The registers are made of small repeated blocks, one per bit, so they form a
grid. The adder (and ALU) is also repeated for each bit, but each unit is much
larger and more complex. It also helps that the block diagrams and patent
diagrams roughly match the die layout.

------
anonymousiam
I was current on every other processor of this era, but I avoided 8086 because
of the crappy addressing scheme. They (apparently) wanted to keep some sort of
connection to 16-bit addressing, so they came up with the "segment registers",
which were a real kludge. I guess I was wrong, and once they graduated from
"real mode", it got better.

