Reverse engineering the barrel shifter circuit on the Intel 386 processor die | Hacker News Reader

Reverse engineering the barrel shifter circuit on the Intel 386 processor die

righto.com

6 pointselpocko8 comments

Author here: what I find interesting about the 386 is that it is a complex chip (285,000 transistors), yet if you look at individual functional blocks, they can still be understood. On the other hand, looking at x86 circuitry makes me appreciate RISC more. Everything in x86 has complications and corner cases. I think I understand a circuit except for a mystery wire, which turns out to be supporting a special case in the instructions.

Another great article - though the juiciest details are probably in the microcode, hope you'll get to that :)

Were the mnemonics SLL and SLR (instead of SHL/SHR) used in some patent?

Rotate-through-carry with count > 1 seems to be a very rare operation, I'd say it was a mistake that they implemented it using the barrel shifter. The 286 could do the one bit rotation in 2 clock cycles, and 5+n for multiple bits. So the 386 ends up being slower unless the count is at least 4!

(for a left rotate by one bit, ADC could be used in most cases of course, which takes 2 clocks on both processors)

Thanks for the comments. SLL and SLR are just my error (assuming that the acronym for Shift Logical Left was SLL); I've fixed the post.

I don't know if I'll ever get to the microcode; it would be quite a project to figure it out. From the die, each micro-instruction appears to be 35 bits long, broken into fields of about 6-8 bits that are interpreted by PLAs. So perhaps it has a rational structure that could be revealed by analysis.

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.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...

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.

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.)

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.

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.

Reply on news.ycombinator.com