3 ms·

Yeah, reverse-engineering a 386 is way beyond what I can do. The 6502 has about 3500 transistors, the 8086 has about 29,000, and the 80386 has about 275,000 tra

by kens 5y ago

Yeah, reverse-engineering a 386 is way beyond what I can do. The 6502 has about 3500 transistors, the 8086 has about 29,000, and the 80386 has about 275,000 transistors. So it's almost an order of magnitude of complexity each time. Not to mention that the 80386 has two metal layers, which makes it a whole lot harder to see what's going on.

anyfoo 5y ago
Thanks for the confirmation! Maybe instead some day the 80386 is considered so old and historic that Intel makes some design documents available, but that practice does not seem terribly common...
- rasz 5y ago
  286 was an RTL model hand converted module by module to transistor/gate level schematic. Afair 386 was the first Intel CPU where they fully used synthesis (work out of UC Berkeley https://vcresearch.berkeley.edu/faculty/alberto-sangiovanni-vincentelli https://vcresearch.berkeley.edu/faculty/alberto-sangiovanni-...) instead of manual routing. Everything went thru logic optimizers (multi-level logic synthesis) and will most likely be unrecognizable.
  - anyfoo 5y ago
    That’s indeed interesting. Assuming detailed pictures, it sounds then that finding the original purpose might only be feasible if there are any very significant remnants of the registers purpose… (And then it seems much harder, but not impossible, a bit akin to reading very optimized compiler generated machine code).
    - rasz 5y ago
      I found a paper on this 'Coping with the Complexity of Microprocessor Design at Intel – A CAD History' https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.222.8896&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22... There was another one dedicated to 386, but I dont remember the title :( on the other hand there are insane people able to RE Playstation CPU/GTE back from standard cell array chip http://www.psxdev.net/forum/viewtopic.php?t=551&start=60 http://www.psxdev.net/forum/viewtopic.php?t=551&start=60
rep_lodsb 5y ago
386 may be a bit too far, but there was a high resolution shot of an 80286 on the visual6502.org wiki (now sadly offline), were you could almost read the microcode ROM visually. I spent a lot of time staring at that and got at least a good part of the opcode pattern PLA. Many bits were so blurry that I could only guess what they are, based on what other opcodes I already had. The actual microcode is 53760 bits with a very high density, where the difference between a 0/1 comes down to a fraction of a pixel. I think with a better image, it might be possible to read those bits and even automate it. Not sure if there are any mysteries left to solve though. In the PLA there are patterns with "don't care" bits to match opcodes 64-67 and 0F 07 to 0F FF, so all of these must be invalid (they go to the same address in microcode). Some time ago I found out what the last undocumented opcode 0F 04 - and the F1 prefix - do by experimenting[1]. One slightly odd thing about that instruction is that the CPU seems to grant bus requests for DMA/refresh, but then completely ignore it and write at the same time. On the first machine I tested this on, this caused some crashes and spurious I/O that I didn't notice at first, but on another one it did absolutely not work unless DRAM refresh was disabled. Maybe there is something in the microcode that explains this, but more likely it has to do with other parts of the hardware? [1] https://www.vcfed.org/forum/forum/technical-support/vintage-computer-programming/71519-i-found-the-saveall-opcode https://www.vcfed.org/forum/forum/technical-support/vintage-...

by kens 5y ago

anyfoo 5y ago

Thanks for the confirmation! Maybe instead some day the 80386 is considered so old and historic that Intel makes some design documents available, but that practice does not seem terribly common...

rasz 5y ago
286 was an RTL model hand converted module by module to transistor/gate level schematic. Afair 386 was the first Intel CPU where they fully used synthesis (work out of UC Berkeley https://vcresearch.berkeley.edu/faculty/alberto-sangiovanni-vincentelli https://vcresearch.berkeley.edu/faculty/alberto-sangiovanni-...) instead of manual routing. Everything went thru logic optimizers (multi-level logic synthesis) and will most likely be unrecognizable.
- anyfoo 5y ago
  That’s indeed interesting. Assuming detailed pictures, it sounds then that finding the original purpose might only be feasible if there are any very significant remnants of the registers purpose… (And then it seems much harder, but not impossible, a bit akin to reading very optimized compiler generated machine code).
  - rasz 5y ago
    I found a paper on this 'Coping with the Complexity of Microprocessor Design at Intel – A CAD History' https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.222.8896&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22... There was another one dedicated to 386, but I dont remember the title :( on the other hand there are insane people able to RE Playstation CPU/GTE back from standard cell array chip http://www.psxdev.net/forum/viewtopic.php?t=551&start=60 http://www.psxdev.net/forum/viewtopic.php?t=551&start=60

rep_lodsb 5y ago

386 may be a bit too far, but there was a high resolution shot of an 80286 on the visual6502.org wiki (now sadly offline), were you could almost read the microcode ROM visually. I spent a lot of time staring at that and got at least a good part of the opcode pattern PLA. Many bits were so blurry that I could only guess what they are, based on what other opcodes I already had. The actual microcode is 53760 bits with a very high density, where the difference between a 0/1 comes down to a fraction of a pixel. I think with a better image, it might be possible to read those bits and even automate it. Not sure if there are any mysteries left to solve though. In the PLA there are patterns with "don't care" bits to match opcodes 64-67 and 0F 07 to 0F FF, so all of these must be invalid (they go to the same address in microcode). Some time ago I found out what the last undocumented opcode 0F 04 - and the F1 prefix - do by experimenting[1]. One slightly odd thing about that instruction is that the CPU seems to grant bus requests for DMA/refresh, but then completely ignore it and write at the same time. On the first machine I tested this on, this caused some crashes and spurious I/O that I didn't notice at first, but on another one it did absolutely not work unless DRAM refresh was disabled. Maybe there is something in the microcode that explains this, but more likely it has to do with other parts of the hardware? [1] https://www.vcfed.org/forum/forum/technical-support/vintage-computer-programming/71519-i-found-the-saveall-opcode https://www.vcfed.org/forum/forum/technical-support/vintage-...