Yes, one can only hope Ken Shirriff eventually happens to come across one of those models, but I guess they are probably very rare these days.

Besides the multiplication, the 386 had quite a number of teething problems[1], including occasionally broken addressing modes, unrecoverable exceptions, virtual address resolution bugs around the 2G mark, etc...

A while ago, there was also an article posted here that analyzed the inner workings of the Windows/386 loader[2]. Interestingly, Windows simply checks a pair of instruction (XBTS/IBTS) that early 386 steppings had, but was later removed, raising an invalid opcode exception instead.

Raymond Chen also wrote a blog post describing a few workarounds that Windows 95 had implemented[3].

[1] https://www.pcjs.org/documents/manuals/intel/80386/

[2] https://virtuallyfun.com/2025/09/06/unauthorized-windows-386...

[3] https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11...

▲

kens 10 hours ago | parent [-]

From what I've read, the 386 multiplication bug was a semi-analog problem, so the fix was probably making a transistor larger. As a result, it would probably be hard to find the fix on the die and wouldn't be as interesting as, say, the Pentium division bug.

	▲	FarmerPotato 9 hours ago \| parent [-]
		This reminds me of a problem from undergrad computer architecture: how can you validate the multiplier without checking all possible N squared inputs? (Which would take forever.) I read later in a TI DRAM report about which bit pairs to exercise, based on proximity in silicon layout, to verify the part. I suppose something like that to stress-test the ALU.