4 ms·

I've read that the 286 and 386 microarchitectures are actually very similar. The microcode for the 286 is 35 bits wide as well, and while the format isn't publi

I've read that the 286 and 386 microarchitectures are actually very similar. The microcode for the 286 is 35 bits wide as well, and while the format isn't public, US patent 4442484 has a very complete diagram of the processor's internals (Fig. 3) that gives a little information: - entry point PLA maps opcode to address in control ROM - three 6-bit fields to select which registers go on the internal buses (MD, RS, MS) - a few other field names The entry point PLA for the 286 is below the ROM in this image: http://visual6502.org/images/pages/Intel_80286_die_shots.html http://visual6502.org/images/pages/Intel_80286_die_shots.htm... With a lot of guesswork I could make out some of it, in addition to the 8 opcode bits there are 4 other inputs which likely have these meanings: - is sub-opcode using ModRM byte - has 0F prefix - has REP prefix - protected mode active The first two are tested for every opcode, while the latter are ignored for instructions where they aren't relevant. For the ModRM-extended opcodes, there is an entry for the "base" opcode and others for the sub-opcodes, but I couldn't figure out how these are encoded...

kens 3y ago
Very interesting. The 386 patents (e.g. 4972338) don't have any useful details. I wonder if that's related to Intel's decision not to second-source the 386; maybe they decided to keep as much secret as possible.
kens 3y ago
rep_lodsb: Do you know what various undocumented things are in the 286 patent? In particular, the block diagram shows PHAM and LCM signals from the microcode, but they don't explain what these are. Maybe PHAM is physical memory? COREQ is coprocessor request? (I don't know if you're still following this comment thread; maybe you can email me.)
- rep_lodsb 3y ago
  I'm not entirely sure, but "physical memory" is a good guess - "PHAM XFER" and "BUS REQ" go to the BIU control logic, and "PHAM INPUT" to the EA latches. The boxes around the edge of the diagram represent the pins, COREQ being one of them. A few are normally left unconnected and only exist as test pads on the die. Mostly these are for ICE mode (what became System Management Mode on 386SLC and later CPUs). - ICES0# / ICES1# are used for bus control like S0# and S1# are outside of ICE mode. This is why the CPU appears to halt after executing opcode 0F 04 ("STOREALL", which enters ICE mode) - ICEBP# is the hardware signal to enter ICE mode, acting much like RESET# except that the state is saved to physical address 000800H (in the separate ICE memory space) - ICE31 / ICE20 are used to output a 4-bit length for the current instruction (on alternating clock cycles, since every instruction takes at least two) In addition to the diagram, there is the "detailed description of preferred embodiment" in the text, which doesn't explain what PHAM means, but documents for example how opcodes are decoded from the byte queue into a CROM entry point and fields for immediate operands etc. - this should be very similar on the 386, except for the byte queue being longer (16 instead of 6 bytes). The decoded queue ("INSTRUCTION FIFO CONTROL") is 3 instructions long on both chips, and the diagram shows the various fields with their bit lengths to the right of that box. For some reason the displacement is 17 bits, if that's not a typo then probably 33 on the 386? My guesses about the 5 single-bit flags grouped together: - W: byte/word access - LOCK: lock prefix - RPZ: REPZ/REPNZ - DIR: direction (from/to memory)? - USER: undocumented F1h prefix on 286? (not applicable to 386, which uses UMOV opcode for that purpose) For the 386 there are obviously going to be flags for 32-bit address and operand size in there. It also mentions that the microcode can notify the BIU to suspend prefetching before a memory access occurs, "LCN" and "WAIT" might have something to do with that.
  - kens 3y ago
    Looking at the 386 die, I think the decoded instruction queue consists of three parts widely separated on the die: the 32-bit immediate value stored in the datapath, the instruction fields in the middle of the chip, and the microcode start address stored above the microcode ROM. I find it interesting that the queue sounds like one physical thing, but it is distributed.

kens 3y ago

Very interesting. The 386 patents (e.g. 4972338) don't have any useful details. I wonder if that's related to Intel's decision not to second-source the 386; maybe they decided to keep as much secret as possible.

kens 3y ago

rep_lodsb: Do you know what various undocumented things are in the 286 patent? In particular, the block diagram shows PHAM and LCM signals from the microcode, but they don't explain what these are. Maybe PHAM is physical memory? COREQ is coprocessor request? (I don't know if you're still following this comment thread; maybe you can email me.)

rep_lodsb 3y ago
I'm not entirely sure, but "physical memory" is a good guess - "PHAM XFER" and "BUS REQ" go to the BIU control logic, and "PHAM INPUT" to the EA latches. The boxes around the edge of the diagram represent the pins, COREQ being one of them. A few are normally left unconnected and only exist as test pads on the die. Mostly these are for ICE mode (what became System Management Mode on 386SLC and later CPUs). - ICES0# / ICES1# are used for bus control like S0# and S1# are outside of ICE mode. This is why the CPU appears to halt after executing opcode 0F 04 ("STOREALL", which enters ICE mode) - ICEBP# is the hardware signal to enter ICE mode, acting much like RESET# except that the state is saved to physical address 000800H (in the separate ICE memory space) - ICE31 / ICE20 are used to output a 4-bit length for the current instruction (on alternating clock cycles, since every instruction takes at least two) In addition to the diagram, there is the "detailed description of preferred embodiment" in the text, which doesn't explain what PHAM means, but documents for example how opcodes are decoded from the byte queue into a CROM entry point and fields for immediate operands etc. - this should be very similar on the 386, except for the byte queue being longer (16 instead of 6 bytes). The decoded queue ("INSTRUCTION FIFO CONTROL") is 3 instructions long on both chips, and the diagram shows the various fields with their bit lengths to the right of that box. For some reason the displacement is 17 bits, if that's not a typo then probably 33 on the 386? My guesses about the 5 single-bit flags grouped together: - W: byte/word access - LOCK: lock prefix - RPZ: REPZ/REPNZ - DIR: direction (from/to memory)? - USER: undocumented F1h prefix on 286? (not applicable to 386, which uses UMOV opcode for that purpose) For the 386 there are obviously going to be flags for 32-bit address and operand size in there. It also mentions that the microcode can notify the BIU to suspend prefetching before a memory access occurs, "LCN" and "WAIT" might have something to do with that.
- kens 3y ago
  Looking at the 386 die, I think the decoded instruction queue consists of three parts widely separated on the die: the 32-bit immediate value stored in the datapath, the instruction fields in the middle of the chip, and the microcode start address stored above the microcode ROM. I find it interesting that the queue sounds like one physical thing, but it is distributed.