Comment by userbinator
10 hours ago
No discussion of these instructions on the 386 would be complete without mentioning that early revisions had a bug in the 32-bit multiply: https://retrocomputing.stackexchange.com/questions/17803/int...
I wonder if anyone outside of Intel has discovered the actual bug in the circuitry yet.
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...
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.
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.