5 ms·

Author here if anyone wants to discuss the internals of the 8086.

by kens 6y ago

abbeyj 6y ago
Do you know if NOP is really executed as `XCHG AX, AX` (as would be implied from its position in the opcode map and its cycle count) or if it is special-cased in some way? I've always been curious about the XLAT instruction. It performs an operation like `MOV AL, [BX + AL]` (if that were a valid instruction). I assume this instruction was designed to do EBCDIC <-> ASCII conversions using a simple loop consisting of `LODSB / XLAT / STOSB` which would explain why the input and output are both hardcoded to AL. But it seems like it would have been fairly easy to allow the programmer to specify different register(s) and the instruction probably would have been a lot more useful generally if that was allowed. It is the only place in the ISA that I know of where an 8-bit value is zero-extended to 16 bits before being added to another value. Short jumps use a sign-extended 8-bit value (and are a special case anyway since they deal with the instruction pointer). Other additions are always 8+8 or 16+16. Is there some special case in the processor to allow just AL to be zero-extended in this way? If so, that would go some way toward explaining why this instruction isn't more flexible. I realize this may be very difficult to determine working from a die photo, at least without completely reverse engineering the entire microcode ROM.
- kens 6y ago
  Yes, NOP is just an XCHG AX, AX. For instructions such as XCHG, the microcode doesn't know anything about the specific registers; hardcoded circuitry substitutes the registers from the instruction. This saves on microcode size. Microcode also doesn't know about 8-bit vs 16-bit instructions; that is also done in circuitry. As far as XLAT, I haven't seen anything yet to answer your question. I hope to figure out the microcode, which should provide more details.
- raphlinus 6y ago
  One theory on XLAT is that it's there to make it easier to adapt code originally written for 6502, where the "indirect indexed" addressing mode was popular. The zero-extended 8 + 16 addition is the same, and this would otherwise require a sequence. For example, to do code page translation on 6502 you'd definitely use indirect indexed at the core. But yeah, this is an oddball instruction, one of the most non-RISC-like in the set.
- kiwidrew 6y ago
  The 8086/88 does in fact execute 90h (the NOP opcode) as XCHG AX, AX. It does not generate any change in the user-visible architectural state, however, and so it appears to be a NOP. [Internally the CPU uses the "TMP" register as a temporary storage location during execution of the XCHG operation, and so the NOP will clobber whatever value was previously held there.] One can observe two of the internal registers ("TMP" and "IND") using an invalid JMP FAR m32 opcode. Normally this is encoded as opcode FF/5 with a mod-rm byte that specifies a memory location (mod=00, mod=01, or mod=10) from which to fetch a doubleword CS:IP pointer. Specifying a mod-rm byte with mod=11 (register) - which is an undefined encoding - skips the "load doubleword from memory" microcode subroutine and causes the CPU to jump directly to the location IND:TMP instead, allowing one to observe the values held in these internal registers. At some point I'll get around to writing this up in more detail, as I don't think anyone else has ever described the behaviour of this particular invalid 8086 opcode.
  - userbinator 6y ago
    At some point I'll get around to writing this up in more detail, as I don't think anyone else has ever described the behaviour of this particular invalid 8086 opcode. I'd love to see more about that --- there has been plenty of documentation on "first-byte" undocumented opcodes, but far less research and information on undocumented operand combinations/groups and such. In particular, the infamous FF FF (that gets disassembled by DEBUG and a few other assemblers as "??? DI" ) falls in that area, as does LEA with a register operand ("LEA AX, AX") and several others that don't immediately come to mind. If I remember correctly, on the Z80 some of the hidden architectural registers' state was also visible as undefined flags. What you've described sounds very similar to that.
    - kiwidrew 6y ago
      > LEA with a register operand ("LEA AX, AX") Yep, reading about this (from a post that I can't find at the moment) was one of the things that inspired me to try illegal/undefined mod-rm byte encodings.
  - kens 6y ago
McGlockenshire 6y ago
Thank you very much for this series of articles. Please continue with them! One thing that I would love to see eventually is a series of comparisons with the 8088.
- kens 6y ago
  I've looked briefly at the 8088. As you know, the 8088 is a modification of the 8086 with an 8-bit bus instead of the 16-bit bus. Here's a quick summary of the differences: Looking at the dies, the 8086 and 8088 are completely identical over most of the die. For the most part, I can look at the 8088 die if something is unclear in my 8086 photo. The biggest difference is the bus control logic, which is entirely different (as you'd expect). This is in the upper-right corner. The 8088 has a 4-byte instruction queue instead of a 6-byte instruction queue, so there's a bit of wasted space in the register file there. The queue registers and control circuitry are slightly different because the 8088 needs to access half of the word at a time. I saw a couple of microcode differences, but I don't know if they are related to 8086 vs 8088 or are bug fixes. Some of the pin driving circuitry is different, as you'd expect, since only 8 pins are used for data. To summarize: is the 8088 a completely redone chip? No. Are they the same chip with a jumper? No. Most parts of the 8086 and the 8088 are the same, but some parts were completely redesigned.
tomcam 6y ago
Have you discovered any new opcodes?
- kens 6y ago
  No, but see kiwidrew's comments that discuss undocumented opcodes.
ido 6y ago
If the 8086 uses microcode to implement its ISA using simpler operations, could a CPU that does away with the translation layer theoretically be made & if so what would the simpler underlying language or microcode look like? What portion of the chip handled the translation?
- kens 6y ago
  The 8086 uses "traditional" microcode, where microcode is executed to implement the instruction. Modern x86 processors are a bit different, translating an instruction into micro-ops which go into the instruction pipeline. So the 8086 may not be translating in the way you're thinking. In any case, look elsewhere in these comments for a discussion of the NEC V33 processor, which replaced the 8086's microcode with hardwired control. As for the 8086's microcode, each micro-instruction is 21 bits: 5 bits for a source register, 5 bits for a destination register, 3 bits for a "type" field, 7 bits for two more fields, and 1 bit to control the flags. The microcode ROM is the big rectangle in the lower-right of the die photos.
bogomipz 6y ago
I had a couple of questions. The first was about the blown up region on the right in this photo: http://static.righto.com/images/8086-alu/die-labeled-alu.jpg http://static.righto.com/images/8086-alu/die-labeled-alu.jpg Those silicon shapes are pretty fascinating and each seem unique with respect to the other? How do they come up with these? Are these just the product of signal routing and minimal surface area needed for the circuit? Almost like a reverse puzzle? My second question was about the right side of this photo: http://static.righto.com/images/8086-alu/inverter-diagram.jpg http://static.righto.com/images/8086-alu/inverter-diagram.jp... What are the purple lines and green regions here?
- abbeyj 6y ago
  For your second question, I believe those lines are explained a bit further down the page: "The reddish horizontal lines are remnants of the metal layer, which was removed for this photo. These lines carried the control signals, power, and ground."
  - bogomipz 6y ago
    Thank you! I'm not sure how I missed this other than there's a lot of detail to absorb in this post. Cheers

Author here if anyone wants to discuss the internals of the 8086.

by kens 6y ago

Author here if anyone wants to discuss the internals of the 8086.

Do you know if NOP is really executed as `XCHG AX, AX` (as would be implied from its position in the opcode map and its cycle count) or if it is special-cased in some way? I've always been curious about the XLAT instruction. It performs an operation like `MOV AL, [BX + AL]` (if that were a valid instruction). I assume this instruction was designed to do EBCDIC <-> ASCII conversions using a simple loop consisting of `LODSB / XLAT / STOSB` which would explain why the input and output are both hardcoded to AL. But it seems like it would have been fairly easy to allow the programmer to specify different register(s) and the instruction probably would have been a lot more useful generally if that was allowed. It is the only place in the ISA that I know of where an 8-bit value is zero-extended to 16 bits before being added to another value. Short jumps use a sign-extended 8-bit value (and are a special case anyway since they deal with the instruction pointer). Other additions are always 8+8 or 16+16. Is there some special case in the processor to allow just AL to be zero-extended in this way? If so, that would go some way toward explaining why this instruction isn't more flexible. I realize this may be very difficult to determine working from a die photo, at least without completely reverse engineering the entire microcode ROM.

kens 6y ago
Yes, NOP is just an XCHG AX, AX. For instructions such as XCHG, the microcode doesn't know anything about the specific registers; hardcoded circuitry substitutes the registers from the instruction. This saves on microcode size. Microcode also doesn't know about 8-bit vs 16-bit instructions; that is also done in circuitry. As far as XLAT, I haven't seen anything yet to answer your question. I hope to figure out the microcode, which should provide more details.
raphlinus 6y ago
One theory on XLAT is that it's there to make it easier to adapt code originally written for 6502, where the "indirect indexed" addressing mode was popular. The zero-extended 8 + 16 addition is the same, and this would otherwise require a sequence. For example, to do code page translation on 6502 you'd definitely use indirect indexed at the core. But yeah, this is an oddball instruction, one of the most non-RISC-like in the set.
kiwidrew 6y ago
The 8086/88 does in fact execute 90h (the NOP opcode) as XCHG AX, AX. It does not generate any change in the user-visible architectural state, however, and so it appears to be a NOP. [Internally the CPU uses the "TMP" register as a temporary storage location during execution of the XCHG operation, and so the NOP will clobber whatever value was previously held there.] One can observe two of the internal registers ("TMP" and "IND") using an invalid JMP FAR m32 opcode. Normally this is encoded as opcode FF/5 with a mod-rm byte that specifies a memory location (mod=00, mod=01, or mod=10) from which to fetch a doubleword CS:IP pointer. Specifying a mod-rm byte with mod=11 (register) - which is an undefined encoding - skips the "load doubleword from memory" microcode subroutine and causes the CPU to jump directly to the location IND:TMP instead, allowing one to observe the values held in these internal registers. At some point I'll get around to writing this up in more detail, as I don't think anyone else has ever described the behaviour of this particular invalid 8086 opcode.
- userbinator 6y ago
  At some point I'll get around to writing this up in more detail, as I don't think anyone else has ever described the behaviour of this particular invalid 8086 opcode. I'd love to see more about that --- there has been plenty of documentation on "first-byte" undocumented opcodes, but far less research and information on undocumented operand combinations/groups and such. In particular, the infamous FF FF (that gets disassembled by DEBUG and a few other assemblers as "??? DI" ) falls in that area, as does LEA with a register operand ("LEA AX, AX") and several others that don't immediately come to mind. If I remember correctly, on the Z80 some of the hidden architectural registers' state was also visible as undefined flags. What you've described sounds very similar to that.
  - kiwidrew 6y ago
    > LEA with a register operand ("LEA AX, AX") Yep, reading about this (from a post that I can't find at the moment) was one of the things that inspired me to try illegal/undefined mod-rm byte encodings.
- kens 6y ago

McGlockenshire 6y ago

Thank you very much for this series of articles. Please continue with them! One thing that I would love to see eventually is a series of comparisons with the 8088.

kens 6y ago
I've looked briefly at the 8088. As you know, the 8088 is a modification of the 8086 with an 8-bit bus instead of the 16-bit bus. Here's a quick summary of the differences: Looking at the dies, the 8086 and 8088 are completely identical over most of the die. For the most part, I can look at the 8088 die if something is unclear in my 8086 photo. The biggest difference is the bus control logic, which is entirely different (as you'd expect). This is in the upper-right corner. The 8088 has a 4-byte instruction queue instead of a 6-byte instruction queue, so there's a bit of wasted space in the register file there. The queue registers and control circuitry are slightly different because the 8088 needs to access half of the word at a time. I saw a couple of microcode differences, but I don't know if they are related to 8086 vs 8088 or are bug fixes. Some of the pin driving circuitry is different, as you'd expect, since only 8 pins are used for data. To summarize: is the 8088 a completely redone chip? No. Are they the same chip with a jumper? No. Most parts of the 8086 and the 8088 are the same, but some parts were completely redesigned.

tomcam 6y ago

Have you discovered any new opcodes?

kens 6y ago
No, but see kiwidrew's comments that discuss undocumented opcodes.

ido 6y ago

If the 8086 uses microcode to implement its ISA using simpler operations, could a CPU that does away with the translation layer theoretically be made & if so what would the simpler underlying language or microcode look like? What portion of the chip handled the translation?

kens 6y ago
The 8086 uses "traditional" microcode, where microcode is executed to implement the instruction. Modern x86 processors are a bit different, translating an instruction into micro-ops which go into the instruction pipeline. So the 8086 may not be translating in the way you're thinking. In any case, look elsewhere in these comments for a discussion of the NEC V33 processor, which replaced the 8086's microcode with hardwired control. As for the 8086's microcode, each micro-instruction is 21 bits: 5 bits for a source register, 5 bits for a destination register, 3 bits for a "type" field, 7 bits for two more fields, and 1 bit to control the flags. The microcode ROM is the big rectangle in the lower-right of the die photos.

bogomipz 6y ago

I had a couple of questions. The first was about the blown up region on the right in this photo: http://static.righto.com/images/8086-alu/die-labeled-alu.jpg http://static.righto.com/images/8086-alu/die-labeled-alu.jpg Those silicon shapes are pretty fascinating and each seem unique with respect to the other? How do they come up with these? Are these just the product of signal routing and minimal surface area needed for the circuit? Almost like a reverse puzzle? My second question was about the right side of this photo: http://static.righto.com/images/8086-alu/inverter-diagram.jpg http://static.righto.com/images/8086-alu/inverter-diagram.jp... What are the purple lines and green regions here?

abbeyj 6y ago
For your second question, I believe those lines are explained a bit further down the page: "The reddish horizontal lines are remnants of the metal layer, which was removed for this photo. These lines carried the control signals, power, and ground."
- bogomipz 6y ago
  Thank you! I'm not sure how I missed this other than there's a lot of detail to absorb in this post. Cheers