Some early models of Intel 80386 processors had a bug with 32-bit integer multiplication. Those which were found to have the bug were marked "16-bit S/W ONLY" (not sure what S/W is supposed to mean), while the clean ones were marked with ΣΣ. How could software detect if it's running on a buggy CPU? Because not detecting this could lead to some serious erroneous results, even within the OS (unlike the Pentium FDIV bug, which was minor).
-
12‘S/W’ – software.– user3840170Feb 1, 2021 at 13:40
-
1Chris Lueders’ IAPX purports to detect such buggy 386s (although he never came across one himself), and refers to an IAPX.DAT file which is supposed to have more information (but I don’t have it, and can’t find it).– Stephen KittFeb 1, 2021 at 15:27
-
2As a side note, the double sigma CPUs fixed some other bugs as well, such as a lockup that occurred in conjunction with an 80387.– Jerry CoffinFeb 1, 2021 at 19:03
-
Yeah, I recall reading of this back when it happened. Early 386 software used multiply subroutines rather than the built-in microcode.– Hot LicksFeb 1, 2021 at 23:41
Add a comment
|
2 Answers
Software can identify those early steppings on the 386 by checking whether the XBTS and/or IBTS instruction can be executed, since these instructions were dropped in later chip revisions.
Software must, however, first check whether the CPU is really an 80386 and not 486, because the some early steppings of the 486 temporarily re-used the opcodes of these two instructions for the CMPXCHG instruction (what wonderful design decisions ;) ).
Other than that, it is only possible to check by actually multiplying and seeing if you get a proper result. Windows installers apparently did that by computing and verifying the result of 0x81 × 0x0417A000. I cannot verify whether that is a 100% accurate check, but doubt it, because the bug actually seems to be a on-chip power supply problem that might also depend on environmental conditions.
-
1Not all early CPUs had the bug. By this method you rule out those bug-free early CPUs which had the same exact instructions as the buggy ones.– DarkAtomFeb 1, 2021 at 13:58
-
So the only 100% accurate check is to multiply all 32-bit numbers by all 32-bit numbers (2^64 multiplications!!) and see if any result is wrong? That seems quite ridiculous. If it is a power supply problem, that means it is also non-deterministic (unlike the FDIV bug which had broken lookup tables), so there could be a case where any multiplication works on a buggy CPU, but next day it doesn't.– DarkAtomFeb 1, 2021 at 14:18
-
@DarkAtom - not only is it ridiculous to exhaustively check, it's mentioned as infeasible in a famous paper (top of page 4) - though hardware has got faster than when the paper was written, we have more bits. On the other hand, if it's known that one particular multiplication gives a bad result on the bad chips, that's all you need to execute to decide if it's a good or bad chip. Feb 1, 2021 at 17:08
-
1Yes, but if the bug indeed manifests in a non-deterministic way, it may be undetectable.– DarkAtomFeb 1, 2021 at 20:11
-
1True, but that's independent of the need to exhaustively try all combinations of multiplier and multiplicand. Though the ~600 years it would take you (at about 1 billion multiplications/second) might increase your chances of the glitch happening. Or maybe not, if it still only fails on some operands. Feb 2, 2021 at 2:12
It can be tested by performing various multiplication operations and verifying the result. List of such code that performs ten tests with various memory and register based operands is available for example at pcjs.org, but as others have already pointed out, the problem may only manifest under certain conditions and can depend on e.g. CPU supply voltage, so it is possible that these tests will not necessarily detect a buggy CPU even if all tests pass.
-
11
-
6
-
1I think it already containes enough info to leave, but adding more content would really help a lot.– peterhFeb 4, 2021 at 12:14