3 ms·

I won't tell you what to work on next but I would be very interested in an analysis of the 8086/8088 instruction decoding and microcode structure. TBH I watch a

I won't tell you what to work on next but I would be very interested in an analysis of the 8086/8088 instruction decoding and microcode structure. TBH I watch and read everything you do with great interest.

simmons 6y ago
I'll second this. From the original article: > This is only a piece of the 8086's complex instruction handling. Other latches hold pieces of the instruction indicating register usage and the ALU operation, while a separate circuit controls the microcode engine... I've always been amazed at how complex the 8086 instruction encoding is, especially compared to, say, the 6502 (which admittedly is a much less sophisticated microprocessor). I especially think this whenever I play around with a toy 8086 emulator I've written. :) It's never struck me as being greatly elegant from a software perspective, but I assume there are some good electrical engineering reasons. (And I'm intrigued about the mention of microcode... I always assumed that came later in the x86 series.)
- kens 6y ago
  I'm working on the instruction decoding and the microcode. (The microcode ROM takes up a large part of the chip.) The 8086 patent and some articles discuss the microcode in some detail, but not enough to understand it. So I'm figuring out the microcode encoding. As for the 8086 instruction set, it's kind of a jumble due to the need for backwards compatibility (of a sort) with the 8080. The 8086 instruction set doesn't make things easy for the chip implementation. Intel tried to make a nicer instruction set (with the i432 and then Itanium) but it didn't work out.
  - PhantomGremlin 6y ago
    The 8086 instruction set doesn't make things easy for the chip implementation. Intel tried to make a nicer instruction set (with the i432 and then Itanium) but it didn't work out. The i432 instruction set was, most emphatically, not nicer for implementation. E.g. it had bit-aligned variable-length instructions. Let me repeat that, because it's totally insane: bit-aligned variable-length instructions[1] I knew quite a few people who worked on the i432 implementation, and architectural decisions like that nearly drove them insane. Intel top management at the time didn't have people who understood what was happening, and consequently let the i432 architects "play in the sand". I always enjoyed that witty pun: "play in the sand" is what young children do in sandboxes; "sand" is mostly silicon dioxide and is often slang for what silicon chips are made of. [1] https://en.wikipedia.org/wiki/IAPX432#The_project's_failures https://en.wikipedia.org/wiki/IAPX432#The_project's_failures
    - kens 6y ago
      You are definitely correct. I meant that the instruction was nicer in a holistic sense, not better for implementation. (RISC is the way to go if you want to make the implementation easy. It's remarkable how straightforward the ARM1 chip is, for instance.) I encourage people to read about the i432 processor, to get an idea of how wildly different a processor design can be. Among other things, objects are built into the processor. Object pointers are created by the processor, so you can't make an out-of-bounds pointer. (In other words, many current security issues don't exist.) The processor includes garbage collection, in hardware.
      - nullc 6y ago
        You should checkout S390x-- I've been chasing an issue with crypto code being non-constant time because the instruction set includes the functional equivalent of memcmp and gcc emits it liberally e.g. for integer comparisons. ... and it's probably one of the least weird ultra-ciscy instructions that architecture has.
  - kps 6y ago
    Itanium seems to me a demonstration that Intel learned absolutely nothing from the i860: high theoretical peak performance, but absolutely useless in practice. (I still think BiiN / i960MX was relatively nice, and the i960CA showed that a modern implementation would work.)
- userbinator 6y ago
  I thought the opposite --- the 6502's instruction encoding is the odd one because it's constrained by what a single PLA can do, while the 8086 and its predecessors (including the Z80 and going back to the 8008) have a pretty consistent octal-based encoding: https://news.ycombinator.com/item?id=13045558 https://news.ycombinator.com/item?id=13045558 http://www.z80.info/decoding.htm http://www.z80.info/decoding.htm
  - kens 6y ago
    I'd categorize things a bit differently. The chips all have an octal encoding, although the 6502 groups the bits from the left (so the encoding is even less useful). (The strange thing is these chips are always documented in hexadecimal, which obscures most of the structure.) The Z-80, like the 6502, uses a PLA, while the 8068 uses a weird hybrid PLA-ROM for microcode. All the chips have a lot of internal structure to their opcodes, since certain bit fields specify the ALU operation, register, etc. Overall, I'd say the 6502 is the most structured, both because its instruction set is simple and because they didn't have backwards-compatibility to worry about. The 8086 has a lot of special-case instructions wedged into random spots, as well as a lot of inconsistency. For instance, sometimes bits 5-7 specify the register, sometimes bits 2-4, sometimes bits 3-4. And then there are the multi-byte "group" instructions tossed into the mix.
    - bonzini 6y ago
      The x86 encoding is fairly simple as there are only four kind of opcodes: * one byte with implicit operands, for example LOOP or RET or ADD AX,imm * one byte shortcut encoding with registers in bits 0-2 of the only opcode byte, these are 16-bit instruction only: INC/DEC, PUSH/POP, XCHG AX,rr (these instructions are also available as 2-byte encodings) * two byte with one register and one register/memory operand, both encoded in the second byte (bits 3-5 and 0-2/6-7, with bit 0 of the first byte determining the size and bit 1 of the first byte determining if the source is the register or the register/memory operand) * two byte with a single register/memory operand, in which case bits 3-5 of the second byte are part of the opcode Prefixes and immediate operands complicate things a bit but that's it. It's refreshingly simple compared to the 386 and later. An interesting tidbit is that registers are ordered AX/CX/DX/BX in the instruction set encoding because their function roughly matches AF/BC/DE/HL in the 8080 (BX comes last because like HL it can be used to address memory, even though the encoding of memory operands is completely different on the 8086)

simmons 6y ago

I'll second this. From the original article: > This is only a piece of the 8086's complex instruction handling. Other latches hold pieces of the instruction indicating register usage and the ALU operation, while a separate circuit controls the microcode engine... I've always been amazed at how complex the 8086 instruction encoding is, especially compared to, say, the 6502 (which admittedly is a much less sophisticated microprocessor). I especially think this whenever I play around with a toy 8086 emulator I've written. :) It's never struck me as being greatly elegant from a software perspective, but I assume there are some good electrical engineering reasons. (And I'm intrigued about the mention of microcode... I always assumed that came later in the x86 series.)

kens 6y ago
I'm working on the instruction decoding and the microcode. (The microcode ROM takes up a large part of the chip.) The 8086 patent and some articles discuss the microcode in some detail, but not enough to understand it. So I'm figuring out the microcode encoding. As for the 8086 instruction set, it's kind of a jumble due to the need for backwards compatibility (of a sort) with the 8080. The 8086 instruction set doesn't make things easy for the chip implementation. Intel tried to make a nicer instruction set (with the i432 and then Itanium) but it didn't work out.
- PhantomGremlin 6y ago
  The 8086 instruction set doesn't make things easy for the chip implementation. Intel tried to make a nicer instruction set (with the i432 and then Itanium) but it didn't work out. The i432 instruction set was, most emphatically, not nicer for implementation. E.g. it had bit-aligned variable-length instructions. Let me repeat that, because it's totally insane: bit-aligned variable-length instructions[1] I knew quite a few people who worked on the i432 implementation, and architectural decisions like that nearly drove them insane. Intel top management at the time didn't have people who understood what was happening, and consequently let the i432 architects "play in the sand". I always enjoyed that witty pun: "play in the sand" is what young children do in sandboxes; "sand" is mostly silicon dioxide and is often slang for what silicon chips are made of. [1] https://en.wikipedia.org/wiki/IAPX432#The_project's_failures https://en.wikipedia.org/wiki/IAPX432#The_project's_failures
  - kens 6y ago
    You are definitely correct. I meant that the instruction was nicer in a holistic sense, not better for implementation. (RISC is the way to go if you want to make the implementation easy. It's remarkable how straightforward the ARM1 chip is, for instance.) I encourage people to read about the i432 processor, to get an idea of how wildly different a processor design can be. Among other things, objects are built into the processor. Object pointers are created by the processor, so you can't make an out-of-bounds pointer. (In other words, many current security issues don't exist.) The processor includes garbage collection, in hardware.
    - nullc 6y ago
      You should checkout S390x-- I've been chasing an issue with crypto code being non-constant time because the instruction set includes the functional equivalent of memcmp and gcc emits it liberally e.g. for integer comparisons. ... and it's probably one of the least weird ultra-ciscy instructions that architecture has.
- kps 6y ago
  Itanium seems to me a demonstration that Intel learned absolutely nothing from the i860: high theoretical peak performance, but absolutely useless in practice. (I still think BiiN / i960MX was relatively nice, and the i960CA showed that a modern implementation would work.)
userbinator 6y ago
I thought the opposite --- the 6502's instruction encoding is the odd one because it's constrained by what a single PLA can do, while the 8086 and its predecessors (including the Z80 and going back to the 8008) have a pretty consistent octal-based encoding: https://news.ycombinator.com/item?id=13045558 https://news.ycombinator.com/item?id=13045558 http://www.z80.info/decoding.htm http://www.z80.info/decoding.htm
- kens 6y ago
  I'd categorize things a bit differently. The chips all have an octal encoding, although the 6502 groups the bits from the left (so the encoding is even less useful). (The strange thing is these chips are always documented in hexadecimal, which obscures most of the structure.) The Z-80, like the 6502, uses a PLA, while the 8068 uses a weird hybrid PLA-ROM for microcode. All the chips have a lot of internal structure to their opcodes, since certain bit fields specify the ALU operation, register, etc. Overall, I'd say the 6502 is the most structured, both because its instruction set is simple and because they didn't have backwards-compatibility to worry about. The 8086 has a lot of special-case instructions wedged into random spots, as well as a lot of inconsistency. For instance, sometimes bits 5-7 specify the register, sometimes bits 2-4, sometimes bits 3-4. And then there are the multi-byte "group" instructions tossed into the mix.
  - bonzini 6y ago
    The x86 encoding is fairly simple as there are only four kind of opcodes: * one byte with implicit operands, for example LOOP or RET or ADD AX,imm * one byte shortcut encoding with registers in bits 0-2 of the only opcode byte, these are 16-bit instruction only: INC/DEC, PUSH/POP, XCHG AX,rr (these instructions are also available as 2-byte encodings) * two byte with one register and one register/memory operand, both encoded in the second byte (bits 3-5 and 0-2/6-7, with bit 0 of the first byte determining the size and bit 1 of the first byte determining if the source is the register or the register/memory operand) * two byte with a single register/memory operand, in which case bits 3-5 of the second byte are part of the opcode Prefixes and immediate operands complicate things a bit but that's it. It's refreshingly simple compared to the 386 and later. An interesting tidbit is that registers are ordered AX/CX/DX/BX in the instruction set encoding because their function roughly matches AF/BC/DE/HL in the 8080 (BX comes last because like HL it can be used to address memory, even though the encoding of memory operands is completely different on the 8086)