[HN Gopher] A look at the die of the 8086 processor
___________________________________________________________________
A look at the die of the 8086 processor
Author : magnat
Score : 132 points
Date : 2020-06-17 17:18 UTC (5 hours ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| mmastrac wrote:
| I'm excited for someone to actually reverse engineer that 8086
| microcode. Curious what might come out of that.
| kens wrote:
| 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
| samstave wrote:
| 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?"
| mobilio wrote:
| And what about 8088? Because it become more popular due 8 bit I/O
| data channel.
| kens wrote:
| 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.
| mobilio wrote:
| Yes, i know.
|
| Will wait for this article!
| Taniwha wrote:
| 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
| bogomipz wrote:
| 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?
| jecel wrote:
| You can divide a processor into two blocks connected to each
| other: the control and the data path. A 1970s book illustrated
| this as a puppet controlled by strings, with the puppet being
| the data path and the hands at the other end of the strings as
| the control. How many strings do you need?
|
| The data path has a bunch of registers, things like an ALU,
| busses and multiplexers. You need a "write enable" wire for
| each register (or a single enable plus a small number of
| address bits), select signals for the multiplexers and some
| control bits for the ALU. 21 bits is as reasonable a number as
| any other. A slightly different data path might require fewer
| or more control signals even when used to execute the exact
| same instructions.
|
| The metal layer is deposited on the whole wafer, but then
| everything is etched away except where you want wires. So the
| "wires" and the "metal layer" are indeed the same thing. The
| vias are just little wells in the oxide beneath the metal
| layer. So when you deposited metal on the whole wafer some of
| that filled in the little well making a vertical connection
| between the wire and what was under the oxide.
| marcosdumay wrote:
| You create the microcode exactly as wide as necessary to
| control all the hardware. Any extra bit would double the size
| of that storage area, and it's already one of the largest
| things on the chip.
| Taniwha wrote:
| you're thinking of address bits - going from 21-bits to
| 22-bits of microcode increases the area by 1/21th
| drmpeg wrote:
| 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).
| Koshkin wrote:
| > _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
| [deleted]
| kens wrote:
| 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.
| ajross wrote:
| I've always wondered why that is, given the space-constraints
| that affected the other areas of those parts' architecture. I
| assume it was just for development speed, given that the
| array was easier to lay out (and maybe even had some kind of
| primitive EDA tooling)?
| kens wrote:
| A PLA is reasonably space-efficient if you need gates with
| a fixed set of inputs and outputs. Even the 8008 used one
| for instruction decoding. In addition to the microcode ROM,
| the 8086 has several PLAs of various sizes. For instance,
| one PLA converts the ALU operation into the necessary ALU
| control lines.
| NortySpock wrote:
| It would also be fast, right? You would only need to
| worry about transistor switching speed, not decoding
| microcode...
|
| Disclaimer: just a software engineer, I've only ever
| heard of microcode, never seen it or written it.
| Koshkin wrote:
| Here's what I think is an excellent introduction to the
| subject (although it leaves unclear the distinction, if
| any, between microcode and PLA):
|
| https://people.cs.clemson.edu/~mark/uprog.html
| kens wrote:
| A key distinction is that in a ROM, only one row is
| active at a time. But in a PLA, multiple rows can be
| active simultaneously.(This is from "The Architecture of
| Microprocessors".)
| Koshkin wrote:
| Makes sense, thanks.
| rwmj wrote:
| 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
| pwg wrote:
| > 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
| jepler wrote:
| A consequence of this is the so-called "undocumented"
| opcodes of the 6502. Extra instructions such as LAX (load
| A and X from the same value) "work" because the
| instruction activates two different blobs of logic (the
| one for LDA plus the one for LDX). From my experience,
| it's less clear that microcode would function this way
| when confronted with an illegal opcode.
| a1369209993 wrote:
| > No, a PLA [1] and a microcode ROM are two very
| different animals.
|
| Technically a microcode ROM (or any ROM, really) _is_ a
| (degenerate case of a) PLA. Hence the visual
| similarities, since that type of grid pattern will be
| observed with any PLA, whether ROM or general-logic.
| duskwuff wrote:
| The difference is less clearcut than you're assuming. A
| PLA and a ROM are both types of lookup tables, after all,
| and in this application they're both being used to
| control the next state of a FSM.
| monocasa wrote:
| The PLAs on the Z80 and 6502 aren't user programmable,
| but had their functions fixed in the mask just like
| regular logic or a mask ROM would be.
|
| Talking about the PLAs in these processors versus ucode
| ROM, the big difference is that in a PLA, typically
| several lines are enabled at a time. In contrast a ROM
| will only have one line active at a time with an address
| decoder sitting in front of it.
|
| You absolutely could use a microcode ROM in the place of
| how these chips use their PLAs, it'd just take more die
| area.
|
| You can see this logic/data equivalence in other places
| of hardware design too. For instance how FPGAs are a sea
| of SRAM, but are equivalent to standard cell chips. FPGAs
| are just slower, larger, and easier to modify.
| pwg wrote:
| > The PLAs on the Z80 and 6502 aren't user programmable,
|
| I never said they were.
|
| I said: "and in the form that gave it the name, it is end
| user programmable (the P stands for Programmable)" which
| is in the context of generic PLA's, not the specific PLA
| in a Z80 or 6502.
| Taniwha wrote:
| 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 wrote:
| Is 8086 microcode reverse engineered or released today
| for studying?
| pwg wrote:
| In the context of IC chip layouts, the determining factor
| is almost always die area. Some functions will be smaller
| on the die in PLA form, other functions will be smaller
| on the die in microcode form. Since die area is almost
| always a scarce resource, the chip designer will usually
| pick the design that reduces die area consumption for any
| given function.
| [deleted]
| Taniwha wrote:
| (puts on chip designer hat) yes and no, as I said
| upstream the copyright laws of the time did not protect
| designs, chip copying (stealing) was rampant.
|
| I can imagine that some CPU designers from a particular
| world view (especially in the 70s) might only design in
| terms of microcode - but also design tools were pretty
| minimal, I can imagine that it might have been far easier
| to design things in terms of microcode rather than as
| PLAs - what you might be seeing here is the differences
| between different teams' in house custom tooling
| kens wrote:
| The Z-80 has an interesting way of executing instructions,
| but it's different from microcode. The first step is the
| PLA, which basically pattern-matches instructions into
| related categories, e.g. generating a signal for bit
| pattern 01XX100X, which might be instructions that read a
| value from the accumulator for instance.
|
| There are two ways this is different from microcode. First,
| one instruction can trigger multiple "categories". Second,
| time is not an input here, so there is no stepping through
| operations.
|
| The next part of the Z-80 instruction decoding is a big
| pile of AND-OR gates that generate the control signals
| based on the PLA outputs and the timing signals. For
| example, a gate might trigger the read-from-A-register
| signal for PLA-output-1 and time-1 or PLA-output-3 and
| time-1 or PLA output-1 and time-4. (These gates are all
| complex and were hand-drawn.)
|
| The point of this is that both microcode and discrete logic
| generate particular control signals based on the
| instruction and time step, but they use very different ways
| to do this. With microcode, you can point to each micro-
| instruction as it executed, but in the Z-80, things are
| happening all over the place seemingly randomly.
| the_af wrote:
| 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.
| mrlonglong wrote:
| 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.
| chihuahua wrote:
| I wish Intel had just added some address lines and increased
| the price by $10 or whatever.
|
| I remember writing 68k assembly code and it was very pleasant
| to work with. 8 address registers, 8 data registers, if you
| want to access memory, you just put a 32-bit address into an
| address register.
|
| Then I read a book about 80286 assembly and though "ugh this is
| horrible" and never wrote a single line of x86 assembly code.
| Worrying about segments and memory models (tiny, small, medium,
| compact, large, huge) seemed like such a drag on programmer
| productivity.
| microcolonel wrote:
| > _I wish Intel had just added some address lines and
| increased the price by $10 or whatever._
|
| It was at a magic price point though, ten dollars literally
| could have broken the whole product.
| kabdib wrote:
| It probably would have tipped IBM over to using the 68K.
| IIRC it was a near thing anyway.
| AnimalMuppet wrote:
| I have heard that IBM chose the 8088 because Intel sowed
| some FUD about Motorola's ability to supply the 68000 in
| sufficient quantity for IBM. The decades of insanity we
| could have saved if IBM had chosen differently...
| a1369209993 wrote:
| It's not a matter of address lines; registers are 16-bit (can
| addresss only 64 kilobytes), so you need segmentation
| regardless of whether your segements are mapped into 1MB,
| 16MB, or 4GB. (For Abus = Areg + Sreg << 4, 8, or 16
| respectively.)
| pkaye wrote:
| I think the idea of the segment registers is to create isolated
| memory ranges for multi tasking. These segments are at the
| granularity of 16 bytes and have a starting offset and length
| within 1MB of RAM. There are multiple segments so the code
| segment can be shared between processes and have separate stack
| and data segments. When you imagine it as one big 1MB address
| space this memory model looks wierd.
| andrewf wrote:
| Intel leaned into this with the 286's protected mode -
| segments became references to "selectors" so the OS could
| place your 64k chunks of code/data wherever it wanted within
| 16M.
|
| I think the existing base of 8080 software (including CP/M
| software) was on their minds. You see the same thing in the
| 386/486, they have the large flat virtual address space
| software devs wanted, but until the early 90s their
| commercial value was running 8088 software really fast.
| WalterBright wrote:
| You grow to love it, though, sort of like Stockholm Syndrome.
| kabdib wrote:
| 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.
| cesarb wrote:
| > if Intel had decided to make the x86 segment paragraph size
| 256 bytes (8 bits) instead of the useless 4 bits
|
| It would also have increased memory fragmentation. Many
| memory allocations were aligned to a segment boundary, so
| you'd be wasting up to 255 bytes instead of up to 15 bytes on
| each allocation.
| Someone wrote:
| _"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)).
|
| 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 224, 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 wrote:
| I meant 16MB, of course. Duh.
|
| Argument still stands.
| miohtama wrote:
| 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.
___________________________________________________________________
(page generated 2020-06-17 23:00 UTC)