[HN Gopher] Z8086: Rebuilding the 8086 from Original Microcode
___________________________________________________________________
Z8086: Rebuilding the 8086 from Original Microcode
Author : nand2mario
Score : 39 points
Date : 2025-12-13 15:04 UTC (7 hours ago)
(HTM) web link (nand2mario.github.io)
(TXT) w3m dump (nand2mario.github.io)
| tasty_freeze wrote:
| Despite what the article says, the 68000 was microcoded too.
| Another difference is that the 68K was a 32b architecture, not
| 16b, and that required investing more transistors for the
| register file and datapath.
| retrac wrote:
| Not for the data path; the 68000 operates on 32 bit values 16
| bits at a time, both through its external 16 bit bus and
| internal 16 bit ALU. Most 32 bit operations take more cycles.
| But yes, it has a 32 bit programming model.
| jecel wrote:
| Actually, the 68000 had one full (all operations) 16 bit ALU
| and two more simple (add/subtract, so AU might be a better
| name) 16 bit ALUs so in the best case it could crunch 48 bits
| per clock cycle. The 8086 had one full 16 bit ALU and one
| simple 16 bit ALU (the ancestor of todays AGUs - address
| generator units).
| jecel wrote:
| The 68000 actually had both microcode and nanocode, so it was
| even further from hardwired control logic than the 8086. In
| terms of performance the 68000 was slightly faster than the 286
| and way faster than the 8088 (I never used an 8086 machine).
| tom_ wrote:
| The 286 looks like it ought to be usefully quicker in
| general? Motorola did a good job on the programming model,
| but you can tell that the 68000 is from the 1970s. Nearly all
| the 68000 instructions take like 8+ cycles, and addressing
| modes can cost extra. On the 286, on the other hand, pretty
| much everything is like 2-4 cycles, or maybe 5-7 if there's a
| memory operand. (The manual seems to imply that every
| addressing mode has the same cost, which feels a bit
| surprising to me, but maybe it's true.) 286 ordinary call/ret
| round trip time is also shorter, as are conditional branches
| and stack push/pop.
| raphlinus wrote:
| My reading is that there aren't really a lot of addressing
| modes on 286, as there are on 68000 and friends, rather
| every address is generated by summing an optional immediate
| 8 or 16 bit value and from zero to two registers. There
| aren't modes where you do one memory fetch, then use that
| as the base address for a second fetch, which is arguably a
| vaguely RISC flavored choice. There is a one cycle penalty
| for summing 3 elements ("based indexed mode").
| ErroneousBosh wrote:
| Not only was it microcoded, but it was sufficiently divorced
| from the assumptions of the 68000 instruction set that IBM were
| able to have Motorola make custom "68000-based" chips that ran
| S/370 code directly.
|
| Want a different architecture? Sure, just draw it with a
| different ROM. Simple (if you've got IBM money to throw
| around).
| tasty_freeze wrote:
| I read (30 years ago) the book "Microprocessor Design" by
| Nick Tredennick. He was the architect and wrote the microcode
| for both the 68K and the S/370. The S/370 was based on his
| recent design experience with the 68K, but it wasn't just a
| microcode swap. In the book he describes his process where he
| would write the ucode for each instruction on a 3"x5" card
| (or was a 4"x7"). At times he'd find sequences that were too
| clunky and then go back to the circuit design folks and ask
| for them to add some extra logic for that corner case to make
| the ucode more efficient.
|
| The book also had a glossary section in the back and a number
| of the entries were funny. One I recall was his definition
| for "methodology", which was something like "A word people
| use when 99% of the time they mean 'method'."
| ErroneousBosh wrote:
| Oh right, nerdsniped into hunting that book down.
| MarkusQ wrote:
| Did anyone else read the headline and think....Zilog? WTF?
| CodeWriter23 wrote:
| "Oddball string instructions", as an assembler coder bitd, they
| were a welcome feature as opposed to running out of registers
| and/or crashing the stack with a Z-80.
| tasty_freeze wrote:
| The Z80 had LDIR which was a string copy instructions. The byte
| at (HL) would be read from memory, then written to (DE), HL and
| DE would be incremented, and BC decremented and then repeated
| until BC became zero.
|
| LDDR was the same but decremented HL and DE on each iteration
| instead.
|
| There were versions for doing IN and OUT as well, and there was
| an instruction for finding a given byte value in a string, but
| I never used those so I don't recall the details.
___________________________________________________________________
(page generated 2025-12-13 23:01 UTC)