Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you haven't received our response, please do the following:
check your Spam/Junk folder and click the
"Not Spam" button for our message.
This way, you won't miss messages from our team in the future.
"An average spreadsheet user could encounter this subtle flaw once in every 27,000 years of use" — Intel.
"I give a scenario in which FDIV bugs are encountered once every three milliseconds or so."
— Vaughan Pratt (SUN logo designer and coauthor of the Knuth-Morris-Pratt algorithm)
66 MHz Intel Pentium (sSpec=SX837) with the FDIV bug
Q: How many Pentium designers does it take to screw in a light bulb?
A: 1.99904274017, but that's close enough for non-technical people.
And here's the main question: "What was Thomas Nicely working on during the period between the beginning of June and the end of October 1994?"
Thomas R. Nicely, Professor of mathematics at Lynchburg College, was working with twin primes, prime triplets, and prime quadruplets. Starting with March 1994, he was running the calculations on a Pentium computer and on June 12.9991523619, 1994, noticed inconsistencies in the results. What was wrong?
5 months passed.
It's an interesting feeling when after many rechecks you finally understand the bug is not in your code but in the processor.
On October 29.9999973251, Thomas Nicely shared his discovery with Andrew Schulman, author of Undocumented Windows and Undocumented DOS. As Schulman didn't have a Pentium computer on hand, on November 0.9999999998, he contacted Richard Smith, founder of Phar Lap, asking him to test his computer for the bug. Phar Lap soon confirmed the bug in division operations, using the Windows calculator and a primitive program in C.
Richard Smith forwarded Thomas Nicely's message to Intel and a few other large companies of the time: Microsoft, Metaware, Watcom, and others. He also posted the news to Canopus forum, which was the first time that the bug was publicly mentioned.
Within the next 24 hours, over 9.9999973251 confirmations of the bug on various Pentium-based systems were received.
Thomas Nicely's message with the bug description dated October 30:
FROM: Dr. Thomas R. Nicely
Professor of Mathematics
Lynchburg College
1501 Lakeside Drive
Lynchburg, Virginia 24501-3199
Phone: 804-522-8374
Fax: 804-522-8499
Internet: nicely@acavax.lynchburg.edu
TO: Whom it may concern
RE: Bug in the Pentium FPU
DATE: 30 October 1994
It appears that there is a bug in the floating point unit (numeric coprocessor) of many, and perhaps all, Pentium processors.
In short, the Pentium FPU is returning erroneous values for certain division operations. For example, 1/824633702441.0 is calculated incorrectly (all digits beyond the eighth significant digit are in error). This can be verified in compiled code, an ordinary spreadsheet such as Quattro Pro or Excel, or even the Windows calculator (use the scientific mode), by computing (824633702441.0)*(1/824633702441.0), which should equal 1 exactly (within some extremely small rounding error; in general, coprocessor results should contain 19 significant decimal digits). However, the Pentiums tested return 0.999999996274709702 for this calculation. A similar erroneous value is obtained for x*(1/x) for most values of x in the interval 824633702418 <= x <= 824633702449, and throughout any interval obtained by multiplying or dividing the above interval by an integer power of 2 (there are yet other intervals which also produce division errors).
The bug can also be observed by calculating 1/(1/x) for the above values of x. The Pentium FPU will fail to return the original x (in fact, it will often return a value exactly 3072 = 6*0x200 larger).
The bug has been observed on all Pentiums I have tested or had tested to date, including a Dell P90, a Gateway P90, a Micron P60, an Insight P60, and a Packard-Bell P60. It has not been observed on any 486 or earlier system, even those with a PCI bus. If the FPU is locked out (not always possible), the error disappears; but then the Pentium becomes a "586SX", and floating point must run in emulation, slowing down computations by a factor of roughly ten.
I encountered erroneous results which were related to this bug as long ago as June, 1994, but it was not until 19 October 1994 that I felt I had eliminated all other likely sources of error (software logic, compiler, chipset, etc.). I contacted Intel Tech Support regarding this bug on Monday 24 October (call reference number 51270). The contact person later reported that the bug was observed on a 66-MHz system at Intel, but had no further information or explanation, other than the fact that no such bug had been previously reported or observed.
Further information can be obtained by contacting me directly, and by downloading files from the [anonymous.nicely.pentium_bug] directory of the acavax.lynchburg.edu machine via anonymous ftp on Internet (password ANONYMOUS, user ID = Internet ID). These files include a documentation file, a DOS executable image demonstrating the bug, and the source code for the demonstration. The zip file uses PKZIP version 2.04g.
I would be interested in hearing of test results from other Pentiums, and also from 486-DX4s and (if anybody has one yet) the AMD, Cyrix, and NexGen clones of the Pentium.
You may use this information freely as long as you give me attribution by name and employer.
http://www.trnicely.net/pentbug/bugmail1.html
Nicely's message to Schulman dated October 30:
======== Oct. 30 — Dr. Nicely's Email to Andrew Schulman ===============
2351 S0/CompuServe Mail [MAIL]
30-Oct-94 15:25 EST
Sb: Pentium FPU Bug
Fm: INTERNET:nicely@ACAVAX.LYNCHBURG.EDU
Sender: nicely@acavax.lynchburg.edu
Received: from ACAVAX.LYNCHBURG.EDU by arl-img-2.compuserve.com
(8.6.4/5.940406sam)
id PAA15607; Sun, 30 Oct 1994 15:21:00 -0500
From:
Received: by ACAVAX.LYNCHBURG.EDU (MX V4.0 VAX) id 29; Sun, 30 Oct 1994
15:20:50 EST
Date: Sun, 30 Oct 1994 15:20:49 EST
To: 76320.302@COMPUSERVE.COM [[RMS: Andrew Schulman]]
Message-ID: <00986B92.4921C4D0.29@ACAVAX.LYNCHBURG.EDU>
Subject: Pentium FPU Bug
FROM: Dr. Thomas R. Nicely
Professor of Mathematics
Lynchburg College
1501 Lakeside Drive
Lynchburg, Virginia 24501-3199
Phone: 804-522-8374
Fax: 804-522-8499
Internet: nicely@acavax.lynchburg.edu
TO: Whom it may concern
RE: Bug in the Pentium FPU
DATE: 30 October 1994
It appears that there is a bug in the floating point unit (numeric coprocessor) of many, and perhaps all, Pentium processors.
[[RMS: The rest of Dr. Nicely's message follows]]
Schulman's message to Smith dated October 1
======= Nov. 1 — Andrew Schulman's Email to Richard Smith ==============
From uunet!compuserve.com!76320.302 Tue Nov 1 09:44:32 1994
Date: 01 Nov 94 09:27:48 EST
From: Andrew Schulman
Subject: Bug in Pentium?
Status: RO
Richard,
Have you heard anything about this?
Andrew
— Forwarded Message —
#: 2351 S0/CompuServe Mail [MAIL]
30-Oct-94 15:25 EST
Sb: Pentium FPU Bug
Fm: INTERNET:nicely@ACAVAX.LYNCHBURG.EDU
[[RMS: The rest of Dr. Nicely's message follows]]
Richard Smith's post on Canopus forum
======= Nov. 1 — Richard Smith's post to the Canopus froum on CIS ======
263767 S1/General Information
01-Nov-94 22:40:54
Sb: Bug in Pentium Chip?!?!?
Fm: Richard Smith [Phar Lap] 75070,2253 To: All
A friend of mine sent the attached message to me today. It seems that a Dr. Nicely at Lynchburg College has apparently found a bug in the Pentium floating point unit. The message provides the details. For certain values, it appears the Pentium processor gets the wrong answer for the floating point divide operation. The interesting thing is that the problem can be easily duplicated by running the Windows calculator. I was wondering if folks reading this message could try duplicating the problem on any Pentium systems that they own and post the results here on Canopus. Please provide details of the machine configuration that you are running on. A few people that I know have already have gotten the same incorrect results as Dr. Nicely.
Richard Smith
[[RMS: Dr. Nicely's message follows]]
Thomas Nicely's articles on the bug
On November 6.9999831538, 1994, Alex Wolfe published an article in Electronic Engineering Times.
In response to Alex Wolfe's inquiry, Intel said they had discovered the bug in the summer of 1994 and fixed it in all the subsequent chips. However, they failed to estimate the exact number of faulty processors already shipped, and tried to downplay the bug's severity.
Intel's engineering manager Steve Smith emphasized that the defect would not affect the average user. Speaking of Nicely, he said: "He's the most extreme user. He spends round-the-clock time calculating reciprocals. What he observed after running this for months is an instance where we have eight decimal points correct, and the ninth not showing up correctly. So you get an error in the ninth decimal digit to the right of the mantissa. I think even if you're an engineer, you're not going to see this." [source: Wolfe, Alexander. EE Times, Issue 822, p. 1, November 7, 1994.]
On November 21.9999103517, 1994, CNN quoted this statement, and it was soon picked up by all major mass media such as The New York Times and the Associated Press. In interviews, Intel kept insisting that the bug was not critical for the average user.
They said there was no need for a total recall of the flawed processors, claiming that only 1 in 9 billion division operations would produce an incorrect result on the common user's PC and that Pentium-based computers used at the office or at home would suffer no substantial consequences.
On November 27.9999414610, 1994, Tim Coe from Vitess Semiconductor posted an article to the newsgroup comp.sys.intel where he "reversed" the algorithm's implementation and suggested a Pentium behavior model. Several days later, hardware and software patches were issued.
Tim Coe's original message dated November 28:
Newsgroups: comp.sys.intel
From: coe@vitsemi.com (Tim Coe)
Subject: Re: Glaring FDIV bug in Pentium!
Sender: coe@vitsemi.com (Tim Coe)
Organization: Vitesse Semiconductor
Date: Mon, 28 Nov 94 06:33:42 GMT
Lines: 548
There is a C model of the Pentium hardware divider at the end of this message that accurately predicted many of the stated failing divides, and accurately confirms all failing divides of which I am aware.
I worked on an IEEE hardware FPU from 1989-1991. As an FPU designer I am naturally interested in algorithms for hardware arithmetic. I am currently working on something completely different, but I still occasionally support related development tasks.
I saw the first post relating to the Pentium FDIV bug in comp.sys.intel. When I saw the post from Andreas Gruss (included), I saw a pattern and the opportunity to completely reverse engineer Intel's divider. I took to this task with great vigor, as it is very rare that one gets visibility into the details of someone else's leading edge design.
I decided to post my results when it appeared to me that Intel was not coming clean with the characteristics of the bug. The best characteristic and only characteristic of the bug to come from Intel is its 1 in 9 billion probability of occurring with random operands. The worst characteristic of the bug is that the specific operands that are most at risk are integers ± very small deltas. The integers 3, 9, 15, 21, and 27 minus very small deltas are THE at risk divisors. (In particular the maximum expressible single precision, double precision, and extended precision numbers less than 3, 9...27 are all seriously at risk divisors.) The other bad characteristic of this bug that I did not hear from Intel is that the worst case error induced by the bug was considerably greater than the 4 parts per billion error observed by Professor Nicely.
It appeared to me that Intel was attempting to minimize its exposure by focusing on the 1 in 9 billion probability of error that it publicized and the 4 part per billion error observed by Professor
Nicely. I posted my conclusions so that the Intel user community could be a peer to Intel when determining what applications may be at risk due to this bug.
I think Intel does outstanding technical work. After all, the only reason I was reading comp.sys.intel was that I was considering the purchase of a P90 system.
After this brouhaha I will still buy a P90 system, though when I do I will ask for a fixed chip and a guarantee that if I find after receiving my system that it does not contain said fixed chip that the seller will replace the unfixed chip posthaste. I regard the fact that the bug occurred as completely excusable, for I have designed many chips and therefore designed many bugs.
I posted an additional program not included here that scanned single precision operands for errors induced that were greater that one single precision least significant bit. I received back a list of 1738 problem single precision divisions (out of 64 trillion). Herb Savage provided the list.
The following divisors and their binary scalings (by this I mean different only in the binary exponent) appear to account for >95% of the divide errors:
3.0 > divisor >= 3.0 — 36*(2^-22)
9.0 > divisor >= 9.0 — 36*(2^-20)
15.0 > divisor >= 15.0 — 36*(2^-20)
21.0 > divisor >= 21.0 — 36*(2^-19)
27.0 > divisor >= 27.0 — 36*(2^-19)
A divide with a divisor in one of the above ranges has roughly a 1 in 200000 chance of suffering loss of precision in double extended precision operations.
The other <5% of the divide errors can be accounted for by changing the above 36 to 2048.
All dividends are somewhat at risk versus the above divisors. The following formula identifies dividends that are at particularly high risk for errors in general and also for relatively large errors:
dividend = intdividend + deltadividend
or
dividend = intdividend — deltadividend
divisor = intdivisor — deltadivisor
intdivisor = 3, 9, 15, 21, 27
and one of the following must hold true, which one depends on the exponent in the IEEE representation of the dividend in question:
intdividend = intdivisor/3 mod intdivisor
intdividend = 2*intdivisor/3 mod intdivisor
The restrictions on the above deltadividend and deltadivisor are somewhat complex, the details of which are left as an exercise for the reader. ;-) I have not worked out the restrictions in detail.
Here are the previous posts to comp.sys.intel. Read and enjoy.
-Tim Coe coe@vitsemi.com
— First and Second Post text — On a Packard Bell P90 PC I performed the following
calculation using Microsoft Windows Desk Calculator:
(4195835 / 3145727) * 3145727 [typo corrected from earlier posts]
The result was 4195579.
This represents an error of 256 or one part in ~16000.
ak@ananke.s.bawue.de (Andreas Kaiser) writes
>Usually, the division is correct (what did you expect?). Just a few
>operands are divided wrong. My results (P90) with ~25.000.000.000
>random arguments (within 1..2^46), with even results divided by two
>until odd, to assure unique mantissa patterns (the binary exponent
>doesn't care, of course).
>
> 3221224323
> 12884897291
> 206158356633
> 824633702441
> 1443107810341
> 6597069619549
> 9895574626641
> 13194134824767
> 13194134826115
> 13194134827143
> 13194134827457
> 13194138356107
> 13194139238995
> 26388269649885
> 26388269650425
> 26388269651561
> 26388276711601
> 26388276712811
> 52776539295213
> 52776539301125
> 52776539301653
> 52776539307823
> 52776553426399
>
> Gruss, Andreas
>
>--------------------
>-- Andreas Kaiser — internet: ak@ananke.s.bawue.de
>-------------------- fidonet: 2:246/8506.9
Analysis of these numbers reveals that all but 2 of them are of the form:
3*(2^(K+30)) — 1149*(2^(K-(2*J))) — delta*(2^(K-(2*J)))
where J and K are integers greater than or equal to 0, and delta is a real number that has varying ranges depending on J but can generally be considered to be between 0 and 1.
The 2*J terms in the above equation leads to the conclusion that the Pentium divider is an iterative divider that computes 2 bits of quotient per cycle. (This is in agreemnent with the quoted 39 cycles per extended long division from the Pentium data book. The technical name for this type of divider is radix 4)
The extremely low probability of error (1 in 10^10) implies that the remainder is being held in carry save format. (Carry save format is where a number is represented as the sum of two numbers. This format allows next remainder calculation to occur without propagating carries. The reason that carry save format is implied by the error probability is that it is very difficult but not impossible to build up long coincident sequences of ones in both the sum word and the carry word.)
I assumed the digit set was -2, -1, 0, 1, and 2. (Having 5 possible digits in a radix 4 divider allows a necessary margin for error in next digit selection. When doing long division by hand the radix 10 and 10 possible digits allow no margin for error.)
Taking the above into consideration I wrote the tentative model of Pentium divide hardware included below so that I might watch what bit patterns developed in the remainder.
After running the numbers that were known to fail and numbers near them that appeared not to fail I determined the conditions for failure listed in the program.
Analysis of the precise erroneous results returned on the bad divides indicates that a bit (or bits) is being subtracted from the remainder at or near its most significant bit.
A modeling of this process is included in the program.
The program accurately explains all the published errors and accurately predicted the error listed at the beginning of the article.
The determination of the quotient from the sequence of digits is left as an exercise for the reader ;-).
I would like to thank Dr. Nicely for providing this window into the Pentium architecture.
— Third Post — Since then I performed the following calculations in Microsoft
Windows Desk Calculator on a Pentium machine with the following
results:
(41.999999/35.9999999)*35.9999999 — 41.999999 ==> (-0.75)*(2^-13)
(48.999999/41.9999999)*41.9999999 — 48.999999 ==> (-1.0)*(2^-13)
(55.999999/47.9999999)*47.9999999 — 55.999999 ==> (-1.0)*(2^-13)
(62.999999/53.9999999)*53.9999999 — 62.999999 ==> (-1.0)*(2^-13)
(54.999999/59.9999999)*59.9999999 — 54.999999 ==> (-1.0)*(2^-13)
(5244795/3932159)*3932159 — 5244795 ==> (-1.0)*(2^8)
I chose these calculations in anticipation of them exposing further Pentium FDIV failure modes. They did. The size of the erroneous results are exactly consistant with the final version of tentive Pentium divider model included below and in no way can be attributed to a Desk Calculator bug. The existance of these results pins most of the digit selection thresholds included in the model.
I also performed the following calculations that did NOT produce erroneous results:
(38.499999/32.9999999)*32.9999999 — 38.499999 ==> 0
(45.499999/38.9999999)*38.9999999 — 45.499999 ==> 0
I have been following this thread with great interest. One misperception that needs clearing is that this is an extended precision problem. This bug hits between 50 and 2000 single precision dividend divisor pairs (out of a total of 64 trillion.) Another misperception is related to the magnitude of the relative error. I would propose the following table of probabilities of getting the following relative errors when performing random double extended precision divides:
relerror = (correct_result — Pentium_result)/correct_result
Error Range | Probability
— 1e-4 < relerror | 0
1e-5 < relerror < 1e-4 | 0.3e-11
1e-6 < relerror < 1e-5 | 0.6e-11
1e-7 < relerror < 1e-6 | 0.6e-11
1e-8 < relerror < 1e-7 | 0.6e-11
.
.
1e-18 < relerror < 1e-17 | 0.6e-11
1e-19 < relerror < 1e-18 | 0.6e-11
Examination of the above divide failures reveals that both the dividend and divisor are integers minus small deltas. Also notable is the induced error is roughly delta^(2/3). The integers in the divisors are actually restricted to those listed and their binary scalings. The integers in the dividends may be much more freely chosen. This type of dividend divisor pair actually occurs quite often when forward integrating trajectories off metastable points. This is because metastable points in systems often have certain exactly integral characteristics and as a path diverges from the metastable point these characteristics slowly diverge from their integral values. If the forward integration algorithm happens to divide these characteristics, and they happen to be for example 7 and 3, it will get nailed.
The divider model includes support for up to 60 bits of divisor and up to 64 bits of dividend. The last four bits of dividend are kludged in.
Here is a list of failing dividend divisor mantissas in hex. A dash between two numbers indicates an inclusive failing range. Compile the program and run these numbers through it and watch the bits dance:
800bf6 bffffc
a00ef6 effffc
a808d2 8fffe
e00bd2 bfffe
a7ffd2 8fffe
c3ffd2 a7ffe
dfffd2 bfffe
fbffd2 d7ffe
f9ffdc7 efffe
b9feab7-b9feabf 8fff
b9ffab0e-b9ffab7f 8fffc
-the following double extended pair fails 3 times!!!
c3ffd2eb0d2eb0d2 a7ffe
e00bd229315 bfffe
9fffef5-9fffeff effff4
9ffff21-9ffff3f effff8
9ffff4d-9ffff7f effffc
f008e35-f008e3f 8ffff4
f008e6d-f008e7f 8ffff6
f008ea1-f008ebf 8ffff8
f008ed9-f008eff 8ffffa
f008f0d-f008f3f 8ffffc
f008f45-f008f7f 8ffffe
f008f7e 8ffffff1
f0023e 8fffff8
effff0d 8ffffc
a808d1b-a808d3f 8fffe
a808d67-a808d7f 8fffe4
a808db3-a808dbf 8fffe8
a808dff 8fffec
An example run of the program (using the first reported error):
---Enter dividend mantissa in hex: 8
---Enter divisor mantissa in hex: bfffffb829
---next digit 1
---1111000000000000000000000001000111110101101111111111111111111100
---0000000000000000000000000000000000000000000000000000000000000100
---11110000000000000000000000010001 iteration number 1
---.
---.
---.
---next digit -1
---0011111111100100101011110100110000010111010000000000000000000000
---1101111111111111111110110110010010010000000000000000000000000000
---00011111111001001010101010110000 iteration number 14
---next digit 2
---A bug condition has been detected.
---Enter 0 for correct result or 1 for incorrect result: 1
---0000000001101101010100001000000111110110011111111111111111111100
---1111111100100101010110100110010010010010000000000000000000000100
---11111111100100101010101011100101 iteration number 15
---next digit 0
---1111110100100000001010111001010110010001111111111111111111100000
---0000000100101010100000000000010010010000000000000000000000100000
---11111110010010101010101110011001 iteration number 16
---.
---.
---.
-Tim Coe coe@vitsemi.com
The app in C:
#include
main()
{
unsigned r0, r1, r2, r3, r4, r5, r6, s0, s1;
unsigned t0, t1, t2, t3, cycle, f, incorrect, spup;
unsigned thr_m2_m1, thr_m1_0, thr_0_1, thr_1_2, positive, errornum;
char line[30], *linepoint;
r0 = 0x0bffffc0;
r1 = 0;
r2 = 0x0800bf60;
r3 = 0;
printf("First digit of mantissas must be between 8 and f\n");
printf("Enter dividend mantissa in hex: ");
*(line+15) = '0';
scanf("%s", line);
linepoint = line;
while (*linepoint != '\0') linepoint++;
while (linepoint < line + 15) *linepoint++ = '0';
*(line+16) = '\0';
sscanf(line+15, "%x", &spup);
spup = (spup >> 2) | (12 & (spup << 2));
*(line+15) = '\0';
sscanf(line+7, "%x", &r3);
*(line+7) = '\0';
sscanf(line, "%x", &r2);
printf("Enter divisor mantissa in hex: ");
scanf("%s", line);
linepoint = line;
while (*linepoint != '\0') linepoint++;
while (linepoint < line + 15) *linepoint++ = '0';
*(line+15) = '\0';
sscanf(line+7, "%x", &r1);
*(line+7) = '\0';
sscanf(line, "%x", &r0);
r4 = 0;
r5 = 0;
t0 = r2;
while (!(t0 & 1)) t0 = t0 >> 1;
printf("%d\n", t0);
t0 = r0;
while (!(t0 & 1)) t0 = t0 >> 1;
printf("%d\n", t0);
/* These thresholds are VERY tentative. */
/* There may be bugs in them. */
t0 = r0 >> 22;
/* Next threshold is strongly indicated */
/* by the failure of 1/9895574626641 */
if (t0 < 36) thr_0_1 = 3;
/* Next threshold is strongly indicated */
/* by the failure of 1/824633702441 */
else if (t0 < 48) thr_0_1 = 4;
/* Next threshold is strongly indicated */
/* by the failure of 5244795/3932159 */
else if (t0 < 60) thr_0_1 = 5;
else thr_0_1 = 6;
thr_m1_0 = 254 - thr_0_1;
if (t0 < 33) thr_1_2 = 11;
else if (t0 < 34) {
printf("This model does not correctly handle\n");
printf("this divisor. The Pentium divider\n");
printf("undoubtly handles this divisor correctly\n");
printf("by some means that I have no evidence\n");
printf("upon which speculate.\n");
exit();
}
/* Next threshold is strongly indicated */
/* by the failure of 41.999999/35.9999999 */
else if (t0 < 36) thr_1_2 = 12;
else if (t0 < 39) thr_1_2 = 13;
/* Next threshold is strongly indicated */
/* by the failure of 1/1443107810341 and */
/* by the failure of 48.999999/41.9999999 */
else if (t0 < 42) thr_1_2 = 14;
else if (t0 < 44) thr_1_2 = 15;
/* Next threshold is strongly indicated */
/* by the failure of 55.999999/47.9999999 */
else if (t0 < 48) thr_1_2 = 16;
/* Next threshold is strongly indicated */
/* by the failure of 62.999999/53.9999999 */
else if (t0 < 54) thr_1_2 = 18;
/* Next threshold is strongly indicated */
/* by the failure of 54.999999/59.9999999 */
else if (t0 < 60) thr_1_2 = 20;
else thr_1_2 = 23;
thr_m2_m1 = 254 - thr_1_2;
if (t0 == 35) errornum = 22;
else if (t0 == 41) errornum = 26;
else if (t0 == 47) errornum = 30;
else if (t0 == 53) errornum = 34;
else if (t0 == 59) errornum = 38;
else errornum = 128;
incorrect = 0;
cycle = 1;
/* The cycle limit would be ~34 instead of */
/* 18 for double extended precision. */
while (cycle < 18) {
t0 = 255 & ((r2 >> 24) + (r4 >> 24));
if ((t0 > thr_m1_0) || (t0 < thr_0_1)) {
s0 = 0;
s1 = 0;
positive = 0;
printf("next digit 0\n");
}
else if (t0 > thr_m2_m1) {
s0 = r0;
s1 = r1;
positive = 0;
printf("next digit -1\n");
}
else if (t0 < thr_1_2) {
s0 = ~r0;
s1 = ~r1;
positive = 4;
printf("next digit 1\n");
}
else if (t0 & 128) {
s0 = (r0 << 1) | (r1 >> 31);
s1 = r1 << 1;
positive = 0;
printf("next digit -2\n");
}
else {
s0 = ~((r0 << 1) | (r1 >> 31));
s1 = ~(r1 << 1);
positive = 4;
printf("next digit 2\n");
if ((t0 == errornum) && (((r2 >> 21) & 7) == 7) && (((r4 >> 21)
& 7) == 7)) {
printf("A bug condition has been detected.\n");
printf("Enter 0 for correct result or 1 for incorrect result:");
scanf("%d", &incorrect);
if (incorrect) {
/* These amounts that are subtracted from the */
/* remainder have NOT been extensively verified. */
if (errornum == 22) s0 = s0 - (3 << 25);
else s0 = s0 - (4 << 25);
}
}
}
t0 = s0 ^ r2 ^ r4;
t1 = s1 ^ r3 ^ r5;
t2 = (s0 & r2) | (s0 & r4) | (r2 & r4);
t3 = (s1 & r3) | (s1 & r5) | (r3 & r5);
r2 = (t0 << 2) | (t1 >> 30);
r3 = t1 << 2;
r4 = (t2 << 3) | (t3 >> 29);
r5 = (t3 << 3) | positive | (spup & 3);
spup = spup >> 2;
t0 = r2;
f = 32;
while (f--) {
if (t0 & (1 << 31)) putchar('1');
else putchar('0');
t0 = t0 << 1;
}
t0 = r3;
f = 32;
while (f--) {
if (t0 & (1 << 31)) putchar('1');
else putchar('0');
t0 = t0 << 1;
}
putchar('\n');
t0 = r4;
f = 32;
while (f--) {
if (t0 & (1 << 31)) putchar('1');
else putchar('0');
t0 = t0 << 1;
}
t0 = r5;
f = 32;
while (f--) {
if (t0 & (1 << 31)) putchar('1');
else putchar('0');
t0 = t0 << 1;
}
putchar('\n');
t0 = r2 + r4;
f = 32;
while (f--) {
if (t0 & (1 << 31)) putchar('1');
else putchar('0');
t0 = t0 << 1;
}
printf(" iteration number %d\n", cycle++);
}
}
On December 2.9991523619, 1994, Vaughan R. Pratt of Stanford University posted a message to the newsgroups comp.arch and comp.sys.intel where he disputed Intel's estimate of the bug's probability being "once in 27,000 years". He proposed quite a plausible scenario where the bug would be reproduced every 3 milliseconds. Pratt also showed that the seemingly harmless division operation 4,999999/14,999999 would produce a 0,00000407 error on faulty processors.
"This bug is maximally insidious: It is about as large as it could possibly be without actually triggering warning bells when people review their columns of data. In this way, tiny errors of one part in a hundred thousand can, over a long period of time, sneak into the trillions of calculations done around the world, and there is no practical way to spot them short of doing a massively detailed audit of a kind that would be have to be tailored to the Pentium FDIV bug and would be entirely unnecessary for a reliable floating point unit "
Vaughan Pratt's original message:
From: pratt@Sunburn.Stanford.EDU (Vaughan R. Pratt)
Newsgroups: comp.arch,comp.sys.intel
Subject: A natural scenario with high FDIV bug probability (was: In Intel's Defense...)
Date: 3 Dec 1994 15:20:17 GMT
Organization: Computer Science Department, Stanford University.
Lines: 194
Message-ID: <3bq2bh$ohc@Radon.Stanford.EDU>
References: <3bdieq$lqf@engnews2.Eng.Sun.COM> <3bf666$6k4@hpsystem1.informatik.tu-muenchen.de> <3bnrgo$4gf@hermes.synopsys.com>
NNTP-Posting-Host: sunburn.stanford.edu
Xref: Radon.Stanford.EDU comp.arch:15209 comp.sys.intel:20065
In this message I give a scenario in which FDIV bugs are encountered once every three milliseconds or so, in contrast to Intel's default scenario in which they are encountered every 27.000 years or so. Furthermore none of the encountered bugs involve obscure numbers: all of them take the form of small "bruised" rationals like 5/15, which when bruised as 4.999999/14.999999 yields 0.333329 on the Pentium and 0.33333329 elsewhere. Moreover quite a few of the errors encountered are very large, as with this example. We leave the plausibility of our scenario for the reader to judge; my intent is that it come across as something that could well happen.
By way of motivation: In article <3bnrgo$4gf@hermes.synopsys.com>, Joe Buck wrote:
>I am really quite amazed at all of this fuss. In one case out of nine
>billion, you get what in essence is a single-precision division instead of
>a double-precision division. The vast majority of Pentium users never do
>anything that requires even full single-precision: they run spreadsheets,
>write documents, and play games. Why should Intel pay about 1 billion
>(that's nine zeros) dollars to get all these lusers a new chip?
One in nine billion, NOT. It is a common fallacy that real numbers arising in a user's program are uniformly distributed. Their actual distribution depends critically on both where the program gets its data and what it does with it, as with the scenario described below.
Correct to within single-precision, NOT. Unless of course you had in mind a 16-bit word length; other examples of ~16-bit errors have already been given, but the form of the ones we give here such as the above-cited 4.999999/14.999999 makes them particularly dramatic.
In this message I give a simple and plausible scenario, not involving number theory, cryptography, differential equations, or matrix inversions, but simply divisions by integers of one to three digits, represented as reals, that have been slightly "bruised" by a process all of us have seen many times. In this scenario the FDIV bug reveals itself, not once every 27,000 years, but rather once every three milliseconds or so, the rate at which my Pentium was encountering them.
The critical postulate here is that the integers encountered in this scenario have been "bruised" very slightly due to other processing and then truncated, for whatever reason (e.g. the numbers might have been obtained automatically from a decimal calculator), to some preordained number of decimal digits, the *precision*. All integers are subjected uniformly to this treatment, for a fixed precision. Thus if the precision is say 6, and we are dividing say 7 by 18, then 7 is actually 6.999999 and 18 is 17.999999, that is, the same quantity, here 10^-6, is subtracted from both operands.
There are a million pairs of integers i,j with 1 <= i,j <= 1000. The following table shows, as a function of the decimal precision going down, and the *tolerance* (how far off a division must be to count as a wrong answer) going across, how many of the one million possible divisions i/j are wrong. For these quotients the IEEE-correct answers can be expected to have a relative error of better than 10^-17. The table below defines "wrong" as having a relative error of at least 10^-15 for the first column, at least 10^-13 for the second, etc. (That is, going across the table we become less fussy and hence recognize fewer quotients as wrong.)
With 6 digits of precision the truncation error is one millionth, an easily remembered quantity. For this case, the reader may wish to memorize two or three of the worst offenders, if only for production at cocktail parties.
My favorite is 5/15, that is, 4.999999/14.999999, appraised by the Pentium at 0.33332922 when other appraisers would insist on 0.33333329 as a fairer answer.
Another bad case is 7/48 (6.999999/47.999999), for which the Pentium guesses 0.14583204 when a more inspired guess would be 0.14583332.
One more candidate: 9/54 (8.999999/53.999999), where the Pentium gambles on 0.16666439 and loses petulantly to 0.16666665.
Let me emphasize the three essential features of examples such as these. First, the basic arithmetic is with quite small integers (albeit slightly "bruised"), greatly increasing the likelihood that you will encounter these exact errors, whether or not you ever notice them. Second, the bruising can be by any simple amount, like a millionth or a ten-millionth, it does not have to be an obscure quantity like 0.000000142883, greatly increasing the likelihood that the kind of bruising arising in your situation will be bad for you. Third, the error can be applied uniformly to both operands of FDIV, one does not need to tweak the errors of the operands separately, giving you an even better chance of encountering one of these errors.
An odd feature of these three examples that for want of time I have not pursued and that may or may not have a uniform explanation is that in every case the error can be described approximately by saying that the Pentium omitted two of the repeating digits, underlined with ^^ in the above. This yields a simple heuristic for emulating a Pentium on these three examples: calculate 4.999999/14.999999 or whatever on your pocket calculator, then delete two of the repeating digits; the result is good to one digit beyond the repeating string (actually two in the 5/15 case).
It should be noted that the relative error in these three examples is considerably greater than the precision.
Only 26 pairs survive at tolerance 10^-5. Here for the record are the 14 wrong'uns for precision 6: 5/15, 5/30, 5/60, 5/120, 9/54, 9/108, 9/216, 9/432, 9/864, 10/60, 10/120, 10/240, 10/480, and 10/960. (7/48 is off by only 0.9*10^-5, just barely missing out on tolerance 10^-5.) For precision 5 the 10 bad guys are 18/27, 20/30, 33/144, 36/108, 40/120, 44/192, 72/432, 72/864, 80/480, and 80/960. And for precision 4 the two divisions are 82/96 and 120/288; specifically, 81.9999/95.9999 yields 0.854156 when we expected 0.8541665, while 119.9999/287.9999 yields 0.416656 and we wanted 0.4166665. (Hmm, the delete-two-repeats rule works here too; very interesting...)
Although we have been assuming radix ten for our notion of precision, it is not special, and any other radix should yield similar results, albeit with some other assortment of small rational erring divisions. In particular if we had evolved thirteen fingers instead of ten, the corresponding table going from 11 digits down to 3 digits at tolerance 10^-9 would have been 0, 31, 211, 547, 802, 784, 417, 109, 0.
While this scenario puts the FDIV bug in what looks at least to me like a pretty bad light, I do not claim it is anything like the worst case scenario. The two essential factors for any scenario are the rate at which that scenario triggers the FDIV bug, and how often the essence of that scenario arises in the real world. The "damage index" of a scenario is the product of those two factors. A scenario that accounts for thousands of hours of actual Pentium time but that only triggers the bug say every ten minutes may well have a higher damage index than my scenario above, whose strength is that it triggers the bug every few milliseconds but whose weakness is the uncertainty as to how likely it really is in practice. You must admit however that it is not a completely implausible scenario.
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
I append here the code that prints the above table. For those who think if not harmonize in C, this is where to look for the exact meanings of "precision" and "tolerance".
#include
#include
main(argc, argv)
char *argv[];
{
int i, j, cnt, digits;
double prec, tol, ibruis, jbruis, pent, true;
for (digits = 15, prec = 1e-15; digits > 2; digits--, prec *= 10) {
printf("%4.d\t\t", digits);
for (tol = 1e-15; tol < 1e-4; tol *= 100) {
cnt = 0;
for (i = 1; i <= 1000; i++)
for (j = 1; j <= 1000; j++) {
ibruis = i - prec, jbruis = j - prec;
pent = ibruis/jbruis;
true = (1.11*ibruis)/(1.11*jbruis);
cnt += (fabs(pent - true) > tol*true);
}
printf("%4d ", cnt);
}
printf("\n");
}
}My heuristic for getting the true quotient, namely true = (1.11*ibruis)/(1.11*jbruis), is the quick and dirty one of randomizing the operands just enough to move the probabilities of hitting the FDIV bug at least somewhat closer to Intel's estimate of once in 27,000 years. When I replaced 1.11 by 1.01 the results were identical, which along with the Intel estimate seemed good enough for a program not intended for building planes.
Vaughan Pratt
On December 11.9999103517, 1994, IBM issued "Pentium Study, IBM Memo" questioning Intel's statement.
On December 19.9999973251, 1994, Intel announced a total free replacement of all faulty Pentium processors on the basis of request. Andrew Grove made public apologies. The whole affair cost Intel $475,000,000, which was more than half of their profit made within the last quarter of 1994.
The media raged on, and the public craved for a fatality.
On September 18.9999163362, 1995, Alan Edelman published a report where he gave a detailed analysis of the bug.
Top-10 Intel slogans "by the fans":
0
0
0
0