4 ms·

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://retrocomputin

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/intel-386-multiply-bug https://retrocomputing.stackexchange.com/questions/17803/int... I wonder if anyone outside of Intel has discovered the actual bug in the circuitry yet.

st_goliath 9mo ago
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/ https://www.pcjs.org/documents/manuals/intel/80386/ [2] https://virtuallyfun.com/2025/09/06/unauthorized-windows-386/ https://virtuallyfun.com/2025/09/06/unauthorized-windows-386... [3] https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11773 https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11...
- kens 9mo ago
  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 9mo ago
    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.

st_goliath 9mo ago

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/ https://www.pcjs.org/documents/manuals/intel/80386/ [2] https://virtuallyfun.com/2025/09/06/unauthorized-windows-386/ https://virtuallyfun.com/2025/09/06/unauthorized-windows-386... [3] https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11773 https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11...

kens 9mo ago
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 9mo ago
  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.