5 ms·

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

61 points by zdw 4y ago

kens 4y ago
Author here if anyone has 8086 questions...
- bonzini 4y ago
  > Out 11 indicates instructions where bit 7 is the byte/word indicator Wouldn't that be bit 0?
  - kens 4y ago
    Thanks! I've been doing too much IBM System/360 stuff and I can't remember which way to count bits :-)
    - bonzini 4y ago
      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.
- sanqui 4y ago
  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!
  - stevekemp 4y ago
    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/ http://z80.info/, for example. (I started coding on the Z80, and nowadays tinker with a single-board machine running CP/M on one.)
    - bonzini 4y ago
      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).
- ngneer 4y ago
  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 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) ...
  - kens 4y ago
    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.
    - ngneer 4y ago
      Cool, thank you! Interesting about the encoding proximity for flows with shared microcode. I wonder if that simplified the decoder.
- agalunar 4y ago
  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?
  - userbinator 4y ago
    It was designed with the intention of being used in SMP configurations too, and I believe some industrial control systems were built that way.
    - agalunar 4y ago
      Color me surprised! That's very neat. Thanks for answering the question!
    - drmpeg 4y ago
      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.
  - monocasa 4y ago
    In addition to what was said about the viability of SMP, the lock prefix is handy for interrupt safe ops without wholesale disabling interrupts.
rietta 4y ago
@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?
- kens 4y ago
  I don't think there's any practical reason to do that unless you want to get into the retrocomputing community.
- metadat 4y ago
  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.
  - toast0 4y ago
    Temperature swings might be more of an issue, and air conditioned storage suggests less rapid temperature changes.
userbinator 4y ago
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.

61 points by zdw 4y ago

kens 4y ago

Author here if anyone has 8086 questions...

bonzini 4y ago
> Out 11 indicates instructions where bit 7 is the byte/word indicator Wouldn't that be bit 0?
- kens 4y ago
  Thanks! I've been doing too much IBM System/360 stuff and I can't remember which way to count bits :-)
  - bonzini 4y ago
    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.
sanqui 4y ago
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!
- stevekemp 4y ago
  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/ http://z80.info/, for example. (I started coding on the Z80, and nowadays tinker with a single-board machine running CP/M on one.)
  - bonzini 4y ago
    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).
ngneer 4y ago
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 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) ...
- kens 4y ago
  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.
  - ngneer 4y ago
    Cool, thank you! Interesting about the encoding proximity for flows with shared microcode. I wonder if that simplified the decoder.
agalunar 4y ago
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?
- userbinator 4y ago
  It was designed with the intention of being used in SMP configurations too, and I believe some industrial control systems were built that way.
  - agalunar 4y ago
    Color me surprised! That's very neat. Thanks for answering the question!
  - drmpeg 4y ago
    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.
- monocasa 4y ago
  In addition to what was said about the viability of SMP, the lock prefix is handy for interrupt safe ops without wholesale disabling interrupts.

rietta 4y ago

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

kens 4y ago
I don't think there's any practical reason to do that unless you want to get into the retrocomputing community.
metadat 4y ago
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.
- toast0 4y ago
  Temperature swings might be more of an issue, and air conditioned storage suggests less rapid temperature changes.

userbinator 4y ago

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.