The Group Decode ROM: The 8086 processor's first step of instruction decoding | Hacker News Reader

The Group Decode ROM: The 8086 processor's first step of instruction decoding

righto.com

61 pointszdw20 comments

Open articleView on HN

Author here if anyone has 8086 questions...

> Out 11 indicates instructions where bit 7 is the byte/word indicator

Wouldn't that be bit 0?

Thanks! I've been doing too much IBM System/360 stuff and I can't remember which way to count bits :-)

I did want to put an IBM joke in there ;) though I'm more familiar with PPC's big-endian bit counting than S/360.

This is tangential, but seeing the 8086 opcode table organized in octal groups made me realize the same applies for the instruction set of the Z80 (my home CPU). Your articles are always very insightful, thank you!

Zilog and Intel have a lot of crossover in that regard, due to engineers moving from one to the other.

There's a whole lot of documentation on decoding instructions for the z80 which makes these octal relationships clear.

One good site is http://z80.info/, for example.

(I started coding on the Z80, and nowadays tinker with a single-board machine running CP/M on one.)

The 8080 has 7 registers and a single addressing mode for accumulator-based instructions (which is most of them), therefore base-8 organization is pretty natural. Likewise for 8086 which has 8 registers and 8 ways to use registers to form an addressing mode (with absolute addressing and three different displacement modes, there would be 8*3+1=25, but they sacrificed [BP] to fit everything in MOD={00,01,10}). Of course one wonders if the choice of 8 registers and 8 addressing mode was due to some kind of fixation with base 8, or vice versa.

Compared to the 6809, the 6502 or the 68000, the biggest reminiscence of the Z80 is the difference between AX/CX/DX/BX having 8-bit parts and SI/DI/SP/BP not having them. Though the low/high parts of IX and IY were accessible on the Z80 via undocumented opcodes (maybe even SP? I don't remember).

Any insight into how CALL/RET opcodes were decided or why they are in different groups? Is it merely that these would have been free opcodes?

Digging up some stack history: https://en.wikichip.org/wiki/intel/mcs-4/4004 4004 - 4-level stack using PCx registers, with JMS/BBL to transition to/from subroutine, causing return address pushes/pops (deepest ones lost); 4040 – 8-level stack using PCx registers; 8008 – 8-level stack using AS call levels; 8080 – stack pointer register (SP) ...

I think CALL/RET are mostly arbitrary, where there were free opcodes. But RET iw and RETF iw share the microcode, using bit 3 of the instruction to distinguish them. So they need to have opcodes differing only in bit 3.

Cool, thank you! Interesting about the encoding proximity for flows with shared microcode. I wonder if that simplified the decoder.

Why did the 8086 have the LOCK prefix? I think of it as being mostly useful in parallel contexts, e.g. lock cmpxchg for an atomic compare and swap. But the 8086 was a single core, single thread processor, and I'd be surprised if it were used in multiprocessor machines. Oh! did it have anything to do with the 8087?

It was designed with the intention of being used in SMP configurations too, and I believe some industrial control systems were built that way.

Color me surprised! That's very neat. Thanks for answering the question!

Yes, Intel even had their own bus for this called Multibus. The processor lock signal was connected to the Multibus so that a bus master could lock another boards shared memory for an atomic access.

In addition to what was said about the viability of SMP, the lock prefix is handy for interrupt safe ops without wholesale disabling interrupts.

This illustrates how a complex instruction format impacts performance.

I'm not sure how much simpler it could be? The propagation delays are intrinsic to the process.

Even 32-bit ARM isn't particularly easy to decode, and there are plenty of special cases there as well. 64-bit ARM is even more complex, like they tried to cram as many operations as they could in 32 bits of instruction.

Maybe MIPS is simpler to decode, but I remember seeing lots of odd gaps in the opcode map, and it's not really an example of high performance either.

@kens Off the wall question, i may have a working 8088 that has been stored in an air conditioned basement at my parents. I learned to program on this in the 90s. Is there a practical benefit of getting it running again?

I don't think there's any practical reason to do that unless you want to get into the retrocomputing community.

Are processors themselves typically sensitive to storage temperature? I know motherboards are (lol, ask me how 0...):, but given the operating conditions, I'm struggling to see how anything other than corrosion or +/-100c would damage a stored processor.

Temperature swings might be more of an issue, and air conditioned storage suggests less rapid temperature changes.

Reply on news.ycombinator.com