[HN Gopher] Reverse engineering the Intel 386 processor's regist...
___________________________________________________________________
Reverse engineering the Intel 386 processor's register cell
Author : picture
Score : 87 points
Date : 2023-11-09 17:11 UTC (5 hours ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| kens wrote:
| Author here if anyone has 386 questions. The 386 is very
| complicated, probably too much for me to fully reverse engineer.
| But I find it interesting to look at small circuits on the die.
| mobilio wrote:
| I always wish to say that to you:
|
| THANK YOU!
| raverbashing wrote:
| Very nice writeup!
|
| I understand that these memory cells needs both bit and #bit,
| but how are both provided to the cell? Seems like you'd need a
| lot of inverters around for those
| kens wrote:
| The trick is that the drivers that supply bit and #bit are
| shared by all the registers. At the top of the register file
| you have 64 drivers for the bit lines and then these signals
| feed all the cells.
| accrual wrote:
| Thank you, Ken! This is especially cool to me after reading a
| recent article [0] posted here on hn [1], titled "Intel 80386,
| a revolutionary CPU". It gave me a new appreciation for how
| advanced the 386 was and how it formed the foundation of modern
| x86 architecture.
|
| [0] https://www.xtof.info/intel80386.html
|
| [1] https://news.ycombinator.com/item?id=38156486
| anyfoo wrote:
| If you can, see if there is any trace of the CR1 control
| register in the 386. It's fully marked as reserved, faults on
| access, and has never been used even with any successors.
| (Later, CR4 was added, and then for new things it was mostly
| dedicated MSRs.)
|
| I have been wondering for literally decades now.
|
| The best theory I've read so far came from Michal (os2museum)
| when I talked to him: The 386 was supposed to have an on-die
| cache, but that was stripped out late. There are surviving pre-
| release data sheets documenting that. The idea is then that CR1
| controlled that cache, but got ripped out with the rest of it.
|
| If that is the case, there likely isn't an actual CR1 register
| at all, and only the opcode encoding survived. But if there
| should be an actual register, that would be massive news.
| colejohnson66 wrote:
| Interesting. Do you have a link to said datasheet?
| ajross wrote:
| I doubt any traces would exist at the mask level if that were
| the case. The decoding is just a 3-bit field in the ModR/M,
| there have "always" been CR{1,5,6,7} in the encoding, but
| those don't take transistors to recognize; you only decode
| what you want to connect.
|
| But the theory sounds totally plausible: they'd have written
| up the ISA spec long before they started designing the
| circuits. So if CR1 got dropped early all the existing
| designs would still be targetting 0/2/3 explicitly.
|
| But FWIW: the "why wasn't it ever used" question is easier to
| answer: the window was extremely short. The MOVCR
| instructions only supported 8 32 bit registers, and when the
| Pentium shipped that was already too small and all future CPU
| state extensions were done using the new CPUID and MSR
| mechanisms.
| bell-cot wrote:
| Typo? I'd guess 's/is a /is more /'.
|
| > physical implementation is a complicated than the theoretical
| kens wrote:
| Fixed :-)
| bell-cot wrote:
| > Since there are six 16-bit segment registers in the 386, I
| suspect these are the segment registers and two mystery
| registers.
|
| I'm no expert...but I'd guess the 2 mystery registers are for
| scratch use by the microcode. When executing CALL, INT, etc. in
| protected mode, a '386 chip can easily burn 200-300 clocks on
| just that one assembly instruction. Lord knows how many corner
| cases there might be, when various things go wrong mid-
| instruction.
| kens wrote:
| Yes, that's very possible that the mystery registers are
| scratch registers. But there are lots of other possibilities
| too.
| bell-cot wrote:
| A related idea - if the circuitry around all 8 (16-bit
| registers) is the same...I'd wonder if the '386 might
| actually have 8 segment registers - 6 user-accessible, and 2
| more reserved for the microcode. The latter mostly used when
| navigating some of the more "interesting" states transitions
| which the '386's paging / protection / segmentation
| architecture allows.
| bonzini wrote:
| I would put my bet on LDTR and TR. They are read and written
| with different instructions but they are 16 bit and closely
| related to segment registers (they index into the GDT).
| jewillco wrote:
| The descriptor cache is 96 bits per segment register
| (http://www.rcollins.org/ddj/Aug98/Aug98.html) so the 12
| registers might be the bases and limits with the extra metadata
| stored somewhere else. It might also be that each limit is fewer
| than 32 bits since the encoding for segment limits uses 21 bits
| in memory.
| forinti wrote:
| And I thought I was on the metal for programming in assembly.
| Mikado001 wrote:
| Next step, emulate this processor with a FPGA
| kens wrote:
| I think there are a few missing steps there :-)
___________________________________________________________________
(page generated 2023-11-09 23:00 UTC)