[HN Gopher] Reverse engineering the 386 processor's prefetch que...
___________________________________________________________________
Reverse engineering the 386 processor's prefetch queue circuitry
Author : todsacerdoti
Score : 97 points
Date : 2025-05-10 16:23 UTC (6 hours ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| kens wrote:
| Author here. I hope you're not tired of the 386... Let me know if
| you have any questions.
| neuroelectron wrote:
| Ok, now do 486.
| kens wrote:
| I'm not as interested in the 486; I went stright to the
| Pentium: https://www.righto.com/2025/03/pentium-multiplier-
| adder-reve...
| neuroelectron wrote:
| Fair enough. But why?
| kens wrote:
| Because I saw a Navajo weaving of a Pentium and wanted to
| compare the weaving to the real chip:
| https://www.righto.com/2024/08/pentium-navajo-fairchild-
| ship...
| neuroelectron wrote:
| I was only joking but I'm glad you have decided to take
| it seriously.
| guerrilla wrote:
| I totally agree with your methodology. Stick to the classic
| leaps.
| sitkack wrote:
| At what number of layers is it difficult to reverse engineer a
| processor from die photos? I would think at some point,
| functionality would be too obscured to able to understand the
| internal operation.
|
| Do they ever put a solid metal top layer?
| kens wrote:
| I've been able to handle the Pentium with 3 metal layers. The
| trick is that I can remove metal layers to see what is
| underneath, either chemically or with sanding. Shrinking
| feature size is a bigger problem since an optical microscope
| only goes down to about 800 nm.
|
| I haven't seen any chips with a solid metal top layer, since
| that wouldn't be very useful. Some chips have thick power and
| ground distribution on the top layer, so the top is
| essentially solid. Secure chips often cover the top layer
| with a wire that goes back and forth, so the wire will break
| if you try to get underneath for probing.
| bgnn wrote:
| Interesting! What is the reason of 800nm limit? I have
| successfully photographed my own designs down to 130nm with
| optical microscobes, though not with metal layer removal.
| The resolution isn't perfect but fearures were clearly
| visible.
| sitkack wrote:
| I'll never tire of any analysis you do. But if you are taking
| requests, I'd love two chips.
|
| The AMD 29000 series, a RISC chip with many architectural
| advances that eventually morphed into the K5.
|
| And the Inmos Transputer, a Forth like chip with built in
| scheduling and networking, designed to be networked together
| into large systems.
|
| https://en.wikipedia.org/wiki/AMD_Am29000
|
| https://en.wikipedia.org/wiki/Transputer
| kens wrote:
| Those would be interesting chips to examine, if I ever get
| through my current projects :-)
| Zeetah wrote:
| If you are doing requests, I'd love to see the M68k series
| analyzed.
| moosedev wrote:
| Another vote for the 68000 series :)
| anyfoo wrote:
| Never, the 386 is way too important.
| siliconunit wrote:
| very nice analysis! personally I'm a DEC alpha fan.. but I guess
| that's a too big endeavor.. (or maybe a selected portion?)
| kens wrote:
| So many chips, so little time :-)
| RetroTechie wrote:
| May I suggest a video chip? Yamaha V9958
|
| I hope some day the _tedious_ part of what you do, can be
| automated (AI?), so that you (or others) can spend their time
| on whatever aspect is most interesting. Vs all the grunt work
| needed to get to a point where you understand what you 're
| looking at.
|
| Btw. any 4 bit cpus/uC's in your collection? Back in the day
| I had a small databook (OKI, early '90s iirc) that had a
| bunch of those. These seem to have sort of disappeared (eg.
| never saw a pdf of that particular databook on sites like
| Bitsavers).
| shihabkhanbd wrote:
| The two extra segment registers could be LDTR and TR, both of
| which hold a 16-bit selector index from the GDT (technically bit
| 2 is always zero).
| kens wrote:
| This appears to be a bot reposting comments from an older
| article on my blog.
| lysace wrote:
| I miss those dramatic performance leaps in the 80s. 10x in 5
| years, give or take.
|
| Now we get like 2x in a decade (single core).
| rasz wrote:
| There was no performance improvement clock for clock between
| 286 and 386 when running contemporary 16 bit code
| https://www.vogons.org/viewtopic.php?t=46350
| lysace wrote:
| Ok.
|
| I'm speaking of e.g. the leap between the IBM PC in 1981 and
| the Compaq 386 five years later.
|
| Or between that and the 486 another five years later or so.
| vnorilo wrote:
| I wrote blitters in assembly back in those days for my
| teenager hobby games. When I could actually target the 386
| with its dword moves, it felt blisteringly fast. Maybe the
| 386 didn't run 286 code much faster but I recall the chip
| being one of the most mind-blowing target machine upgrades I
| experienced. Much later I recall the FPU-supported quadword
| copy in 486dx and of course P6 meeting MMX in Pentium II.
| Good times.
| lysace wrote:
| As did I :).
|
| Imagine how it felt going from an 8086 @ 8 MHz to an
| 80486SX (the cheapo version without FPU) @ 33 MHz. With
| blazingly fast REP MOVSD over some form of proto local bus
| Compaq implemented using a Tseng Labs ET4000/W32i vga chip.
| to11mtm wrote:
| You're 100% right that the 386 had a huge amount of changes
| that were pivotal in the future of x86 and the ability to
| write good/fast code.
|
| I think a bigger challenge back then was the lack of
| software that could take advantage of it. Given the nascent
| state of the industry, lots of folks wrote for the 'lowest
| common denominator' and kept it at that (i.e. expense of
| hardware to test things like changing routines used based
| on CPU sniffing.)
|
| And even then of course sometimes folks were lazy. One of
| my (least) favorite examples of this is the PC 'version'
| (It's not at all the original) of Mega Man 3. On a 486/33
| you had the option of it being almost impossible twitchy
| fast, or dog slow thanks to turbo button. Or, the fun thing
| where Turbo Pascal compiled apps could start crapping out
| if CPU was too fast...
|
| Sorry, I digress. the 386 was a seemingly small step that
| was actually a leap forward. Folks just had to catch up.
| myself248 wrote:
| I remember reading about naive circuits like ripple-carry, where
| a signal has to propagate across the whole width of a register
| before it's valid. These seem like they'd only work in systems
| with very slow clocks relative to the logic itself.
|
| In this writeup, something that jumps out at me is the use of the
| equality bus, and Manchester carry chain, and I'm sure there are
| more similar tricks to do things quickly.
|
| When did the transition happen? Or were the shortcuts always
| used, and the naive implementations exist only in textbooks?
| kens wrote:
| Well, the Manchester carry chain dates back to 1959. Even the
| 6502 uses carry skip too increment the PC. As word sizes became
| larger and transistors became cheaper, implementations became
| more complex and optimized. And mainframes have been using
| these tricks forever.
| yukIttEft wrote:
| When are you going to implement the first electron-level 386
| emulator?
___________________________________________________________________
(page generated 2025-05-10 23:00 UTC)