Re: The Pentium 90 Chip

[Sean O'Donnell-Brown <s-odonnell-brown -at- BGU -dot- EDU>]

Mike et al.:

Someone (who got it from somewhere else) posted this on a Western Illinois
University BBS this morning. I hope you Intel-ies find it helpful.

Specifically (and, perhaps, unfortunately), Mike, see no. 7.

Sean (O'Donnell-Brown)
s-odonnell-brown -at- bgu -dot- edu



Subject: Pentium Divide Bug FAQ
Date: 28 Nov 1994 17:24:39 -0800
Organization: USC Information Sciences Institute
Distribution: world

Here is a first version of a FAQ on the Pentium FDIV bug.  You can also
ftp it from: ftp://www.isi.edu/pub/carlton/pentium/FAQ

Please email me any corrections directly--comp.sys.intel is getting too
busy for me to read all articles.

cheers,
--mike carlton -at- isi -dot- edu

-------------------------------------------------------------------------------

Pentium Divide Bug FAQ
Version 1    28-Nov-94

Contents

0) Disclaimer
1) What is the bug?
2) How do I tell if my Pentium machine has the bug?
3) What do single-precision, double-precision, exponent and mantissa mean?
4) How many cases of the bug are there?
5) How often does it occur?
6) How big can the error get?
7) What chips have the bug?
8) When will it be fixed?
9) Are there any other bugs in the Pentium chip?
10) Will Intel replace my buggy chip?
11) What is the history of the bug's discovery?
12) Is there a way to deal with the bug in software?
13) Where can I get more information?
14) Where can I find more discussion of the bug?
15) Acknowledgments

0) Disclaimer

   This document summarizes what I understand about the Pentium FDIV
   bug.  It is based upon my experiments and what I have read on the
   net.  I have not yet been able to speak with Intel concerning this
   matter.

   All statements represent only what I have observed at this point in
   time or what has been reported to me.  As more information becomes
   available I will attempt to update this FAQ.

   This document does not represent the position of the University of
   Southern California or of the USC Information Sciences Institute.

   Mike Carlton
   USC Information Sciences Institute
   4676 Admiralty Way; Marina del Rey, CA  90292-6695
   carlton -at- isi -dot- edu   (310) 822-1511   FAX: (310) 823-6714

1) What is the bug?

   There are some rare cases when the Pentium chip divides two
   floating-point numbers in which it returns an answer that is
   slightly inaccurate (the precision of the result is less than
   expected).  The bug affects both single-precision and double-
   precision divides.  It does not appear to effect any other
   instruction in the processor.

   The bug occurs only for certain pairs of numbers.  It is
   repeatable--i.e. if a pair of numbers is known to be affected by
   the bug, the pair will be affected every time it is tested on every
   chip with the bug.  The bug is also independent of the speed of the
   chip and any previously executed instructions.

2) How do I tell if my Pentium machine has the bug?

   Here are two simple tests that you can try on any calculator
   program or spreadsheet running on a Pentium-based PC.

   1) Divide 5505001 by 294911
        The buggy answer is: 18.66600093
      The correct answer is: 18.66665197

   2) Divide 4195835 by 3145727
        The buggy answer is: 1.33373907
      The correct answer is: 1.33382045

   If you get the buggy answer then that Pentium chip definitely has
   the bug.  If you get the correct answer, the chip may or may not
   have the bug.  Some programs use different methods which do not use
   the floating-point divide instruction and so they are not affected.
   I've tried the cases above with the Microsoft Windows calculator
   and Microsoft Excel and they do show the bug.  If you get the
   correct answer with the Windows calculator or with Excel, then you
   have a non-buggy chip.

3) What do single-precision, double-precision, exponent and mantissa mean?

   The Pentium (along with every other major microprocessor) uses the
   IEEE 754 standard to represent floating point numbers.  A floating-
   point number stores a real number as sign*1.XXX*2^YYY, i.e. one
   plus a fraction, raised to a power of two, along with the sign.
   The XXX part is the mantissa and the YYY part is the exponent.

   The IEEE standard defines a single-precision number to have a
   23-bit mantissa.  This provides 24-bit precision (counting the
   leading one) and is equal to approximately 7 decimal digits.  A
   double precision number has a 52 bit mantissa, giving 53-bit
   precision; equal to about 15 decimal digits.

4) How many cases of the bug are there?

   The total number of cases (i.e. pairs of numbers) isn't known yet.
   If we limit our scope to cases involving single-precision numbers
   and where the accuracy of the result is less than single-precision
   then there are at least 1738 unique cases.  Of these, 87 have only
   14-bit accuracy (approximately 4 decimal digits).

   Due to the nature of the bug, either number of a pair can be
   multiplied (or divided) by any power of 2 and/or have its sign
   changed and still be affected by the bug in the same way.  This is
   because the bug is due to bit patterns in the mantissas of the
   numbers and these operations do not change the mantissas.  All
   numbers with the same mantissa are considered just one unique case.
   For convenience, examples of the bug usually refer to a mantissa in
   the canonical form of the smallest positive integer that, as a
   floating-point number, has that mantissa.  Note that this will be
   an odd number.

   Every unique single-precision dividend mantissa for each single-
   precision divisor mantissa believed susceptible to the bug has been
   checked.  Assuming Tim Coe's model of the divider bug is correct,
   then the 1738 cases mentioned above are all the single-precision
   pairs of numbers which are affected by the bug.

   In double-precision there are many more cases that exhibit less
   than single-precision accuracy.  Note that the single-precision
   numbers are a subset of the double-precision numbers, so the cases
   above all fail when treated as double-precision.  Additionally, in
   many cases the dividend or divisor can be slightly changed (adding
   or subtracting a small fraction) and still be affected.  This
   merely changes the least significant bits of the mantissa, while the
   most significant bits, which are causing the bug, are the same.
   This has the effect that a range of numbers can exhibit the bug.

   If we expand our scope to double-precision cases with less than
   double-precision accuracy (but more than single-precision), the
   number of cases grows drastically.  However, these errors are quite
   small (at least 7 digits are correct) and will concern fewer users.

5) How often does it occur?

   That is a hard question to answer.  Intel's statement (see below
   for information on how to get this via automated fax) claims that
   one in nine billion divides will exhibited reduced precision.

   Here is a simple, back-of-the-envelope calculation which tends to
   agree with Intel's statement.  There are 2^23 unique single-
   precision mantissas.  Thus, if you pick 2 single-precision numbers
   at random there are 2^46 (64 trillion) possibilities.

   There are 1738 cases where two single-precision numbers produce
   less than single-precision accuracy (thus there are at least this
   many bug cases).  1738 is a little less than 2^11, so this implies
   that there is about a 2^11/2^46 = one in 2^35 chance of hitting the
   bug.  2^35 = 32 billion, so this is close to Intel's claim.  The
   actual odds could be higher than this (e.g. if there are more bug
   cases yet to be discovered or if the odds for double-precision
   numbers are higher).

   An important consideration is that a single division with reduced
   accuracy is unlikely to affect a final result.  Thus the chances of
   the bug affecting a final result are very dependent upon the
   problem being solved and the methods used by a program.

   Another important consideration is that the numbers people use in
   practice are not necessarily random.  Depending on the distribution
   of the numbers a particular problem and program uses, the results
   could be more likely or less likely to be affected by the bug.

6) How big can the error get?

   The worst cases found yet have just 14-bit accuracy (both of the
   simple examples above have just 14-bit accuracy).  This is roughly
   4 decimal digits.

   Another way to look at this question is to consider the relative
   error (i.e. the amount of error divided by the correct result).
   The 14-bit accurate cases range from a relative error of
   approximately 1 part in 32000 to the largest relative error found:
   1 part in 16000.  There are just 8 cases (out of 64 trillion random
   pairs of single-precision numbers) with this largest relative
   error.

   Additionally, when the bug affects a division, the magnitude of the
   result returned is always slightly less than the correct result.
   This reflects the fact that when the bug occurs one or two bits
   which should be set to one are instead set to zero.

7) What chips have the bug?

   The bug has only been reported in Pentium chips.  As of the time of
   this writing there had not yet been a reported case of a Pentium-
   based machine without the bug.  It has been reported in both the
   60MHz and 90MHz versions.  I have not heard of any tests of 75MHz
   or 100MHz Pentiums.

8) When will it be fixed?

   It has been reported on the net and in a New York Times article
   that Intel states that they have fixed the bug in June.  The
   November 7 EE Times also reports that it was fixed mid-year.  The
   New York Times article states that Intel has only recently begun
   providing the fixed chips to their largest customers.

9) Are there any other bugs in the Pentium chip?

   There are no other publicly known bugs.

10) Will Intel replace my buggy chip?

   At this time it is not clear what their policy on replacing chips
   is.  They appear to be handling replacements on an individual
   basis.  You can call Intel Technical Support at (800) 628-8686 and
   speak to them directly.

11) What is the history of the bug's discovery?

   The bug was first found by Dr. Thomas R. Nicely of Lynchburg
   College (nicely -at- acavax -dot- lynchburg -dot- edu).  He posted a message to
   Compuserve on October 30, 1994 describing the case he had found.
   His example was 1/824633702441.  He had had an unexpected result in
   one of his experiments and eventually tracked it down to a bug in
   the Pentium divider, which Intel confirmed.  It was first reported
   in the print media in the November 7 issue of EE Times.

   Some early reports on the net, using random searches of
   double-precision numbers, found a couple dozen more cases of the
   bug.  Around November 10, Andreas Kaiser (ak -at- ananke -dot- s -dot- bawue -dot- de)
   posted, in comp.sys.intel, a list of 23 cases where a number of the
   form 1/x failed.  The smallest of these was 1/12884897291.

   Tim Coe of Vitesse Semiconductor (coe -at- vitsemi -dot- com) developed a
   model of how the divider was working and why it was failing.  He
   posted a message to comp.sys.intel on November 16 describing his
   model.  He included the case 4195835/3145727 which his model had
   predicted would fail.  This was the first known case which had less
   than single-precision accuracy.  It is equal to the least accuracy
   (14 bit) and largest relative error (6.1*10^-05) found yet.

   On November 21 Tim Coe posted another message to comp.sys.intel
   with a refined model of the divider and pointed out that the bug
   affected both single- and double-precision divides.  He included
   the prediction that between 50 and 2000 single-precision pairs
   would have less than single-precision accuracy.

   Mike Carlton of USC/ISI (carlton -at- isi -dot- edu), posted a program to
   comp.sys.intel on November 21 which generates 819 more examples
   with less than single-precision accuracy, 66 of which have just 14
   bit accuracy.  This program performed an exhaustive search limited
   to single-precision dividends and divisors of a forms generally
   matching Tim Coe's model.  This post included the example
   5505001/294911.

   More recent searching (independently by Coe and Carlton) has
   expanded this to 1738 single-precision cases and 87 with just
   14-bit accuracy.

12) Is there a way to deal with the bug in software?

   Yes, the developers of MATLAB have devised a simple software
   workaround so that programs running on a buggy Pentium can still
   come up with the correct answer when dividing.  In essence, each
   time they have to calculate a division they first perform the
   divide and then check to see if there is an error in the result.
   If there is, they scale the numbers so that they do not cause the
   bug (but do return the intended answer) and then divide again.

   This is a simple and efficient software solution.  It is estimated
   to make a divide instruction take about twice as long as it would
   without having to compensate for the bug.  The total effect on the
   speed of a program will be minor unless the program is doing a very
   large number of divides.  Of course, only the vendor of a piece of
   software can incorporate such a fix.

   A copy of Cleve Moler's post to comp.sys.intel, complete with
   source code and a detailed explanation, is on the MathWorks' WWW
   server:
        http://www.mathworks.com/
   Thanks to Cleve Moler and The MathWorks, Inc. for making this method
   publicly available.

13) Where can I get more information?

   Intel's WWW server is at:
        http://www.intel.com/

   Intel also has an automated fax back service.  You can call them at
   (800) 525-3019 and request document #9788 for a statement regarding
   the bug.   Their technical support can be reached at (800) 628-8686
   or (916) 356-3551.

   Information the author of this FAQ has collected (including lists
   of the known bug cases and programs to generate them) is available
   for anonymous ftp at:
        ftp://www.isi.edu/pub/carlton/pentium/

   The latest version of this FAQ is available at:
        ftp://www.isi.edu/pub/carlton/pentium/FAQ

   Bill Broadley of UC Davis has also collected information about the
   bug and made it available for anonymous ftp at:
        ftp://math.ucdavis.edu/fdiv/

   The MathWorks, Inc. has several documents related to the Pentium
   available on the WWW:
        http://www.mathworks.com/Pentium/README.html

   EE Times is on the WWW at:
      http://www.wais.com/techweb/eet/current/hr.html

   Edward Vielmetti of Msen Inc. has some documents available at:
      http://www.msen.com/~emv/pentium/

14) Where can I find more discussion of the bug?

   It is beginning to be widely reported in the mass media.  It has
   been covered on CNN and several major newspapers.

   The principal discussion of the bug on the Internet has taken place
   in the newsgroup comp.sys.intel.  This will likely remain the
   center of discussion for a while.

15) Acknowledgments

   Thanks to the following people for their efforts in finding, tracking
   down, documenting and understanding the bug:
        Dr. Thomas R. Nicely (nicely -at- acavax -dot- lynchburg -dot- edu)
        Andreas Kaiser (ak -at- ananke -dot- s -dot- bawue -dot- de)
        Tim Coe (coe -at- vitsemi -dot- com)
        Cleve Moler (cleve -at- mathworks -dot- com)
        Edward Vielmetti (emv -at- Msen -dot- com)
        and the many readers of comp.sys.intel



--
Dave Sill (de5 -at- ornl -dot- gov)
Martin Marietta Energy Systems, Workstation Support
URL http://www.digital.com/info/dsill.html