Jan 152018
Full Description of File
Test program for buggy P5 NPU's
This program will test the Intel
Pentium chip's for the bug in the
NPU.
This program will test the Intel
Pentium chip's for the bug in the
NPU.
Illustrates the Pentium divide bug. Note that the same number can be entered in the Windows Scientific calculator to replicate the error. | |||
---|---|---|---|
File Name | File Size | Zip Size | Zip Type |
FILE_ID.DIZ | 108 | 92 | deflated |
P87TEST.ASM | 9172 | 2571 | deflated |
P87TEST.COM | 1424 | 955 | deflated |
README.TXT | 2136 | 1134 | deflated |
Download File P87TEST.ZIP Here
Contents of the README.TXT file
Test program for buggy P5 NPU's
This program will test the Intel
Pentium chip's for the bug in the
NPU.
Since I started this thread, I'd like to summarize my current views
on this bug:
- *If* Intel have know about this problem for several months, and *decided*
not to warn users about it, those responsible for that decision should
be fired. There is no excuse for knowing about a silent bug like this,
and not tell about it.
- An error that results in a hardware crash is much less serious than this
one which returns wrong answers.
- Since the bit-pattern that fails seems to be about 18 bits long
(..11110111000001...), the odds of hitting it should be about 1/2^18,
or 1/6E7. With 8 significant digits in the answer, this means that the
average (for truly random data) precision on a Pentium is less than 16
digits.
- I have nothing against x86 cpu's, rather the opposite, since I love
writing asm code for them. The company I work for will still buy new
Pentium machines, but as soon as I first heard and verified the problem,
I specified that new machines would only be aquired from dealers who
promized to exchange the cpus as soon as Intel makes the fixed p5s
available.
Since I first posted p87test, I've gotten email from people who tell me that
it thinks their Pentium-90 is a 386. This will happen if you are running
under a V86 monitor which virtualizes the eflags register and disallow
toggling the AlignmentControl (bit #18) and/or CPUID (bit #21).
The new version will perform the test for FDIV precision independently of
cpu version, as long as a numeric coprocessor seems to be present.
I have also found a bug in the program, where I demanded that the result
after FDIV/FMUL should be identical to 1.0. I have changed this to
allow a small ulp error.
To make the program more useful, it will now also report (and document) the
'secret' CPUID feature bits, on a Pentium or new-model 486.
-Terje Mathisen (include std disclaimer)
"almost all programming can be viewed as an exercise in caching"
PS. I someone wants to make p87test.zip available on an ftp site, that
would probably be the best solution.
This program will test the Intel
Pentium chip's for the bug in the
NPU.
Since I started this thread, I'd like to summarize my current views
on this bug:
- *If* Intel have know about this problem for several months, and *decided*
not to warn users about it, those responsible for that decision should
be fired. There is no excuse for knowing about a silent bug like this,
and not tell about it.
- An error that results in a hardware crash is much less serious than this
one which returns wrong answers.
- Since the bit-pattern that fails seems to be about 18 bits long
(..11110111000001...), the odds of hitting it should be about 1/2^18,
or 1/6E7. With 8 significant digits in the answer, this means that the
average (for truly random data) precision on a Pentium is less than 16
digits.
- I have nothing against x86 cpu's, rather the opposite, since I love
writing asm code for them. The company I work for will still buy new
Pentium machines, but as soon as I first heard and verified the problem,
I specified that new machines would only be aquired from dealers who
promized to exchange the cpus as soon as Intel makes the fixed p5s
available.
Since I first posted p87test, I've gotten email from people who tell me that
it thinks their Pentium-90 is a 386. This will happen if you are running
under a V86 monitor which virtualizes the eflags register and disallow
toggling the AlignmentControl (bit #18) and/or CPUID (bit #21).
The new version will perform the test for FDIV precision independently of
cpu version, as long as a numeric coprocessor seems to be present.
I have also found a bug in the program, where I demanded that the result
after FDIV/FMUL should be identical to 1.0. I have changed this to
allow a small ulp error.
To make the program more useful, it will now also report (and document) the
'secret' CPUID feature bits, on a Pentium or new-model 486.
-Terje Mathisen (include std disclaimer)
"almost all programming can be viewed as an exercise in caching"
PS. I someone wants to make p87test.zip available on an ftp site, that
would probably be the best solution.
January 15, 2018
Add comments