From Wikipedia, the free encyclopedia
66 MHz Intel Pentium (sSpec=SX837) with the FDIV bug
The Pentium FDIV bug is a hardware bug affecting the floating-point unit (FPU) of the early Intel Pentium processors. Because of the bug, the processor would return incorrect binary floating point results when dividing certain pairs of high-precision numbers. The bug was discovered in 1994 by Thomas R. Nicely, a professor of mathematics at Lynchburg College.[1] Missing values in a lookup table used by the FPU’s floating-point division algorithm led to calculations acquiring small errors. While these errors would in most use-cases only occur rarely and result in small deviations from the correct output values, in certain circumstances the errors can occur frequently and lead to more significant deviations.[2]
The severity of the FDIV bug is debated. Though rarely encountered by most users (Byte magazine estimated that 1 in 9 billion floating point divides with random parameters would produce inaccurate results),[3] both the flaw and Intel’s initial handling of the matter were heavily criticized by the tech community.
In December 1994, Intel recalled the defective processors in what was the first full recall of a computer chip.[4] In its 1994 annual report, Intel said it incurred «a $475 million pre-tax charge … to recover replacement and write-off of these microprocessors.»[5]
Description[edit]
Graph showing one manifestation of the FDIV bug. Each data point should be ~3.1789 x 10−8 higher on the y-axis than its predecessor to the left, but in the region 4195834.4 < x < 4195835.9 the result differs from the expected value by ~8.14 x 10−5.
In order to improve the speed of floating-point division calculations on the Pentium chip over the 486DX, Intel opted to replace the shift-and-subtract division algorithm with the Sweeney, Robertson, and Tocher (SRT) algorithm. The SRT algorithm can generate two bits of the division result per clock cycle, whereas the 486’s algorithm could only generate one. It is implemented using a programmable logic array with 2,048 cells, of which 1,066 cells should have been populated with one of five values: −2, −1, 0, +1, +2. When the original array for the Pentium was compiled, five values were not correctly downloaded into the equipment that etches the arrays into the chips – thus five of the array cells contained zero when they should have contained +2.[6]
As a result, calculations that rely on these five cells acquire errors; these errors can accumulate repeatedly owing to the recursive nature of the SRT algorithm. In pathological cases the error can reach the fourth significant digit of the result, although this is rare. The error is usually confined to the ninth or tenth significant digit.[3]
Only certain combinations of numerator and denominator trigger the bug. One commonly-reported example is dividing 4,195,835 by 3,145,727. Performing this calculation in any software that used the floating-point coprocessor, such as Windows Calculator, would allow users to discover whether their Pentium chip was affected.[7]
The correct value of the calculation is:
When converted to the hexadecimal value used by the processor, 4,195,835 = 0x4005FB and 3,145,727 = 0x2FFFFF. The ‘5’ in 0x4005FB triggers the access to the ’empty’ array cells. As a result, the value returned by a flawed Pentium processor is incorrect at or beyond four digits:[8]
Discovery and response[edit]
Thomas Nicely, a professor of mathematics at Lynchburg College, had written code to enumerate primes, twin primes, prime triplets, and prime quadruplets. Nicely noticed some inconsistencies in the calculations on June 13, 1994, shortly after adding a Pentium system to his group of computers, but was unable to eliminate other factors (such as programming errors, motherboard chipsets, etc.) until October 19, 1994.[1] On October 24, 1994, he reported the issue to Intel.[9] Intel had reportedly become aware of the issue independently by June 1994, and had begun fixing it at this point, but chose not to publicly disclose any details or recall affected CPUs.[10]
On October 30, 1994, Nicely sent an email describing the bug to various academic contacts, requesting reports of testing for the flaw on 486-DX4s, Pentiums and Pentium clones.[9] The bug was quickly verified by others, and news of it spread quickly on the Internet. The bug acquired the name «Pentium FDIV bug» from the x86 assembly language mnemonic for floating-point division, the most frequently used instruction affected.[9]
The story first appeared in the press on November 7, 1994, in an article in Electronic Engineering Times, «Intel fixes a Pentium FPU glitch» by Alexander Wolfe,[11] and was subsequently picked up by CNN in a segment aired on November 22. It was also reported on by the New York Times and the Boston Globe, making the front page in the latter.[10][12]
At this point, Intel acknowledged the floating-point flaw, but claimed that it was not serious and would not affect most users. Intel offered to replace processors to users who could prove that they were affected. However, although most independent estimates found that the bug would have a very limited impact on most users, it caused significant negative press for the company. IBM paused the sale of PCs containing Intel CPUs, and Intel’s stock price decreased significantly.[13] The motive behind IBM’s decision was questioned by some in the industry; IBM produced the PowerPC CPUs at the time, and potentially stood to benefit from any reputational damage to the Pentium or Intel as a company. However, the decision led to corporate buyers of PC equipment demanding replacements of existing Pentium CPUs, and soon afterwards other PC manufacturers began offering «no questions asked» replacements of flawed Pentium chips.[4]
The growing dissatisfaction with Intel’s response led to the company offering to replace all flawed Pentium processors on request on December 20.[14] On January 17, 1995, Intel announced «a pre-tax charge of $475 million against earnings, ostensibly the total cost associated with replacement of the flawed processors.»[9] This is equivalent to $783 million in 2021.[15] Intel was criticised for barring resellers and OEMs from participating in the recall program, requiring end-users to replace chips themselves. Intel’s justification for this, posted on its support web page, was that «it is the individual decision of the end user to determine if the flaw is affecting their application accuracy».[13]
A 1995 article in Science describes the value of number theory problems in discovering computer bugs and gives the mathematical background and history of Brun’s constant, the problem Nicely was working on when he discovered the bug.[16]
Intel’s response to the FDIV bug has been cited as a case of the public relations impact of a problem eclipsing the practical impact of said problem on customers.[17] While most users were unlikely to encounter the flaw in their day-to-day computing, the company’s initial reaction to not replace chips unless customers could guarantee they were affected caused pushback from a vocal minority of industry experts. The subsequent publicity generated shook consumer confidence in the CPUs, and led to a demand for action even from people unlikely to be affected by the issue. Andrew Grove, Intel’s CEO at the time was quoted in The Wall Street Journal as saying «I think the kernel of the issue we missed … was that we presumed to tell somebody what they should or shouldn’t worry about, or should or shouldn’t do».[4]
In the aftermath of the bug and subsequent recall, there was a marked increase in the use of formal verification of hardware floating point operations across the semiconductor industry. Prompted by the discovery of the bug, a technique applicable to the SRT algorithm called «word-level model checking» was developed in 1996.[18] Intel went on to use formal verification extensively in the development of later CPU architectures. In the development of the Pentium 4, symbolic trajectory evaluation and theorem proving were used to find a number of bugs that could have led to a similar recall incident had they gone undetected.[19] The first Intel microarchitecture to use formal verification as the primary method of validation was Nehalem, developed in 2008.[20]
Affected models[edit]
The FDIV bug affects the 60 and 66 MHz Pentium P5 800 in stepping levels prior to D1, and the 75, 90, and 100 MHz Pentium P54C 600 in steppings prior to B5. The 120 MHz P54C and P54CQS CPUs are unaffected.[21][22]
Software patches[edit]
Various software patches were produced by manufacturers to work around the bug. One specific algorithm, outlined in a paper in IEEE Computational Science & Engineering, is to check for divisors that can trigger the access to the programmable logic array cells that erroneously contain zero, and if found, multiply both numerator and denominator by 15/16. This takes them out of the ‘buggy’ range. This fix does carry a measurable speed penalty — worst case for a program doing nothing but FDIV operations with bad divisors the running time would double since each FDIV would take about 80 instead of 40 clock cycles. With more random divisors the average time per FDIV was approximately 50 clock cycles, i.e. 10 cycles added to check the divisor: Only 5 out of 1024 random divisors would trigger the scaling fixup. Since FDIV is a rare operation in most programs, the normal slowdown with the fix installed was typically a percent or less. [8]
The main challenge faced by software companies was implementing the fix in pre-existing software, much of which relied on libraries outside their control. Some companies, such as Wolfram Research, opted to directly patch the machine code of existing executables to replace the FDIV opcode with an illegal instruction. This would then trigger an exception that an exception handler (also patched in) would catch. From here, arbitrary code could be executed to work around the bug.[2]
Microsoft offered operating system level workarounds in versions of Windows up to Windows XP. Utilities were included with the operating system to check for the presence of the bug and disable the FPU if found.[23][24]
See also[edit]
- Pentium F00F bug
- MOS Technology 6502 bugs and quirks
- Accuracy problems in floating point operations
- MaverickCrunch
References[edit]
- ^ a b Edelman, Alan (January 1, 1997). «The Mathematics of the Pentium Division Bug» (PDF). SIAM Review. 39 (1): 54–67. Bibcode:1997SIAMR..39…54E. doi:10.1137/S0036144595293959. Retrieved April 11, 2021.
- ^ a b «‘A Discussion of and Fix for the Pentium FDIV Bug’ from the Notebook Archive (2002)». notebookarchive.org. Wolfram Research, Inc. Retrieved April 11, 2021.
- ^ a b Tom R. Halfhill (March 1995). «An error in a lookup table created the infamous bug in Intel’s latest processor». BYTE. No. March 1995. Archived from the original on February 9, 2006. Retrieved December 19, 2006.
- ^ a b c Carlton, Jim; Yoder, Stephen K. (December 21, 1994). «Computers: Humble Pie: Intel to Replace its Pentium Chips». The Wall Street Journal (Eastern ed.). p. B1.
- ^ «1994 — Annual Report». Intel. June 20, 2020. Archived from the original on February 26, 2017. Retrieved June 20, 2020.
- ^ Sharangpani, H. P.; Barton, M. L. (November 30, 1994). Statistical Analysis of Floating Point Flaw in the Pentium Processor (1994) (PDF) (Report). Intel Corporation. Retrieved April 11, 2021.
- ^ «Pentium FDIV bug – a Picture». Kansas University Institute for Policy and Social Research. November 30, 1994. Retrieved November 3, 2010.
- ^ a b Coe, T.; Mathisen, T.; Moler, C.; Pratt, V. (1995). «Computational aspects of the Pentium affair» (PDF). IEEE Computational Science and Engineering. 2 (1): 18–30. doi:10.1109/99.372929. Retrieved April 13, 2021.
- ^ a b c d Nicely, Thomas (August 19, 2011). «Pentium FDIV flaw FAQ». trnicely.net. Archived from the original on June 18, 2019. Retrieved June 18, 2019.
- ^ a b Markoff, John (November 24, 1994). «COMPANY NEWS; Flaw Undermines Accuracy of Pentium Chips». The New York Times. Retrieved April 11, 2021.
- ^ Alexander Wolfe (November 9, 1994). «Intel fixes a Pentium FPU glitch». Electronic Engineering Times.
- ^ Moler, Cleve (Winter 1995). «A Tale of Two Numbers» (PDF). MATLAB News and Notes. MathWorks. Retrieved April 21, 2021.
- ^ a b Yeraswork, Zewde (March 30, 2011). «Lessons Learned: Pentium Flaws Aid Intel In Sandy Bridge Chipset Recall». CRN. Retrieved April 11, 2021.
- ^ «Intel adopts upon-request replacement policy on Pentium processors with floating point flaw; Will take Q4 charge against earnings». Business Wire. December 20, 1994. Archived from the original on July 10, 2012. Retrieved December 24, 2006.
- ^ Johnston, Louis; Williamson, Samuel H. (2023). «What Was the U.S. GDP Then?». MeasuringWorth. Retrieved January 1, 2023. United States Gross Domestic Product deflator figures follow the Measuring Worth series.
- ^ Cipra, Barry Arthur (January 13, 1995). «How number theory got the best of the Pentium chip». Science. 267 (5195): 175. Bibcode:1995Sci…267..175C. doi:10.1126/science.267.5195.175. PMID 17791336. S2CID 19898103.
- ^ Price, D. (April 1995). «Pentium FDIV flaw-lessons learned». IEEE Micro. 15 (2): 86–88. doi:10.1109/40.372360.
- ^ Clarke, E. M.; Khaira, M.; Zhao, X. (1996). «Word level model checking—avoiding the Pentium FDIV error». Proceedings of the 33rd Annual Conference on Design Automation Conference – DAC ’96. Dac ’96: 645–648. doi:10.1145/240518.240640. ISBN 0897917790. S2CID 2500033. Retrieved April 29, 2021.
- ^ O’Leary, J. (2004). «Formal verification in intel cpu design». Proceedings. Second ACM and IEEE International Conference on Formal Methods and Models for Co-Design, 2004. MEMOCODE ’04.: 152. doi:10.1109/MEMCOD.2004.1459841. ISBN 0-7803-8509-8. Retrieved April 29, 2021.
- ^ Kaivola, Roope; Ghughal, Rajnish; Narasimhan, Naren; Telfer, Amber; Whittemore, Jesse; Pandav, Sudhindra; Slobodová, Anna; Taylor, Christopher; Frolov, Vladimir; Reeber, Erik; Naik, Armaghan (2009). «Replacing Testing with Formal Verification in Intel® Core™ i7 Processor Execution Engine Validation». Computer Aided Verification. 5643: 414–429. doi:10.1007/978-3-642-02658-4_32.
- ^ «P5 (586) Fifth-Generation Processors | Microprocessor Types and Specifications | InformIT». www.informit.com. June 8, 2001. Retrieved April 13, 2021.
- ^ «FDIV Replacement Program: Frequently asked questions». Intel. March 20, 2009. Solution ID CS-012748. Archived from the original on May 11, 2009. Retrieved November 10, 2009.
- ^ Slob, Arie. «Windows 95 Troubleshooting: How to Check for a Faulty Math Coprocessor». www.helpwithwindows.com. Retrieved April 23, 2019.
- ^ «Pentnt». Microsoft TechNet. Microsoft. September 11, 2009. Retrieved April 23, 2019.
External links[edit]
- Personal website of Dr. Nicely, who discovered the bug
- A page with precise information, also about the cause
- ZIP-file containing more details (See ZIP file format for details on the file)
- Archive of Intel’s official information page about the bug
- Unopened Intel CPU box from the FDIV replacement program
Время на прочтение
23 мин
Количество просмотров 26K
«Ошибка в Pentium настолько специфичная, что обычный пользователь столкнется с ней раз в 27000 лет»
— руководство Intel
«Вот вам правдоподобный сценарий, когда пользователь будет сталкиваться с ошибкой каждые 3 миллисекунды»
— Воэн Пратт (дизайнер логотипа SUN и соавтор алгоритма Кнута-Морриса-Пратта)
66 MHz Intel Pentium (sSpec=SX837) with the FDIV bug
Вопрос: Сколько нужно разработчиков Pentium чтобы вкрутить лампочку?
Ответ: 1.99904274017, такой ответ должен удовлетворить людей без технического образования.
А теперь главный вопрос: «Чем занимался Томас Найсли с начала июня до конца октября 1994 года?»
Томасом Найсли (Thomas Nicely)
В университете профессор Найсли исследовал пары, триплеты и квадраплеты простых чисел. В марте 1994 математик подключил к вычислениям Pentium, а 12.9991523619 июня 1994 года засек несоответствия в циферках. Где же ошибка?
Прошло 5 месяцев.
Это интересное чувство, когда много-много раз все перепроверил и понимаешь, что баг не в твоем коде, а в процессоре.
29.9999973251 октября Томас Найсли сообщил о находке Andrew Schulman, автору «Undocumented Windows», «Undocumented DOS». Так как у Шультмана не было своего Pentium, 0.9999999998 ноября он обратился к Richard Smith, основателю Phar Lap, чтобы тот протестировал свой комп на наличие бага. В Phar Lap они быстренько подтвердили наличие ошибки при делении, с помощью Windows calculator и простенькой проги на С.
Richard Smith переслал сообщение Томаса Найсли в Intel и еще несколько крупнейших компаний того времени: Microsoft, Metaware, Watcom, и пр. Richard Smith так же опубликовал новость на форуме Canopus и это было первым публичным упоминанием о баге.
За 24 часа поступили более 9.9999973251 подтверждений наличия бага в различных Pentium-системах.
Письмо Томаса Найсли 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.
www.trnicely.net/pentbug/bugmail1.html
Письмо от 30 октября Nicely — Schulman
======== 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]]
Письмо от 1 ноября Schulman — Smith
======= 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
To:
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 на форуме Canopus
======= 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]]
Публикации Томаса Найсли по поводу бага
- A personal FAQ regarding the Pentium division flaw. Bibliography attached. Last updated 0900 GMT 19 August 2011.
- Original e-mail message announcing the discovery of the Pentium division flaw, 30 October 1994.
- An account by Richard M. Smith, President of Phar Lap Software, Inc., of the spread of the Pentium flaw announcement across the Internet during the first few days.
- pentbug.zip, a zipfile containing the C source code (pentbug.c) and corresponding DOS executables (pentbug.exe and bug16bit.exe) for a program which will check for the flaw.
- The Pentium division flaw. Thomas R. Nicely. Virginia Scientists Newsletter, Volume 1 (April, 1995), p. 3.
- Untitled article concerning the Pentium division flaw. Thomas R. Nicely. San Francisco Examiner (18 December 1994), p. B-5.
Пресса
6.9999831538 ноября 1994 года Alex Wolfe публикует статью в Electronic Engineering Times.
Отвечая на запрос Alex Wolfe, Intel заявила, что они обнаружили эту ошибку летом 1994 года, и она была исправлена в процессорах, выпущенных позднее. Однако Intel не смогла определить число выпущенных дефектных процессоров, и они попытались сгладить важность этой ошибки.
Представитель Intel, подчеркнул, что этот дефект не повлияет на среднего пользователя. Говоря о Найсели, Смит сказал: «Это исключительный пользователь. Он круглосуточно проводит вычисления обратных величин. То, что он обнаружил после многих месяцев вычислений, является примером того, что восемь десятичных чисел правильны и только девятая отображается неверно. То есть ошибка у вас будет только в девятом знаке справа от точки. Я думаю, что, даже если вы инженер, вы этого не заметите». [источник]
21.9999103517 ноября 1994 года CNN распространила это заявление и вскоре оно было во всех главных средствах массовой информации, таких, как New York Times и Associated Press. В других интервью Intel повторяла свое раннее заявление о том, что ошибка несущественна для среднего пользователя.
Intel заявила, что они не считают необходимым отзывать процессор, утверждая, что обычный пользователь имеет только один шанс из девяти миллиардов получить неверный результат из-за этой ошибки и таким образом не будет никаких заметных последствий для компьютеров дома и в офисе.
Tim Coe
27.9999414610 ноября 1994 года Тим Коу (Tim Coe) из компании Vitess Semiconductor опубликовал статью в группе новостей comp.sys.intel, в которой он «реверснул» реализацию алгоритма и предложил модель поведения процессора Pentium. Через несколько дней появились аппаратные и программные «заплатки» для ошибки.
Оригинал письма Тима Коу 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 necessarry
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
прога на С
#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 fn");
printf("Enter dividend mantissa in hex: ");
*(line+15) = '0';
scanf("%s", line);
linepoint = line;
while (*linepoint != '') linepoint++;
while (linepoint < line + 15) *linepoint++ = '0';
*(line+16) = '';
sscanf(line+15, "%x", &spup);
spup = (spup >> 2) | (12 & (spup << 2));
*(line+15) = '';
sscanf(line+7, "%x", &r3);
*(line+7) = '';
sscanf(line, "%x", &r2);
printf("Enter divisor mantissa in hex: ");
scanf("%s", line);
linepoint = line;
while (*linepoint != '') linepoint++;
while (linepoint < line + 15) *linepoint++ = '0';
*(line+15) = '';
sscanf(line+7, "%x", &r1);
*(line+7) = '';
sscanf(line, "%x", &r0);
r4 = 0;
r5 = 0;
t0 = r2;
while (!(t0 & 1)) t0 = t0 >> 1;
printf("%dn", t0);
t0 = r0;
while (!(t0 & 1)) t0 = t0 >> 1;
printf("%dn", 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 handlen");
printf("this divisor. The Pentium dividern");
printf("undoubtly handles this divisor correctlyn");
printf("by some means that I have no evidencen");
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 0n");
}
else if (t0 > thr_m2_m1) {
s0 = r0;
s1 = r1;
positive = 0;
printf("next digit -1n");
}
else if (t0 < thr_1_2) {
s0 = ~r0;
s1 = ~r1;
positive = 4;
printf("next digit 1n");
}
else if (t0 & 128) {
s0 = (r0 << 1) | (r1 >> 31);
s1 = r1 << 1;
positive = 0;
printf("next digit -2n");
}
else {
s0 = ~((r0 << 1) | (r1 >> 31));
s1 = ~(r1 << 1);
positive = 4;
printf("next digit 2n");
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 %dn", cycle++);
}
}
Воэн Пратт (Vaughan R. Pratt)
2.9991523619 декабря 1994 года Воэн Пратт (Vaughan R. Pratt) из Стэндфордского университета опубликовал письмо в группах новостей comp.arch и comp.sys.intel, в котором оспаривал точку зрения Intel о том, что вероятность встречи с ошибкой составляет «один раз в 27 000 лет». Он смог продемонстрировать возможность активации ошибки один раз в каждые 3 миллисекунды в достаточно правдоподобном сценарии. А также он продемонстрировал, что достаточно безобидно выглядящее деление 4,999999/14,999999 приводило к отклонению от правильного результата на 0,00000407 при использовании дефектного процессора.
«Эта ошибка наиболее коварна: она почти столь же коварна, как если бы вовсе не вызывала тревоги у людей при просмотре ими колонок своих данных. Таким образом, крошечные ошибки в одну стотысячную могут в течение долгого времени проникать в триллионы вычислений, совершаемых по всему миру, и практически нет способа определить их, кроме как осуществляя массированную проверку на ошибку в FPU, которая совершенно не является необходимой для надежно работающего процессора.»
Оригинал письма Воэна Пратта
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.dtt", 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
[источник]
11.9999103517 декабря 1994 года IBM выпустила «Pentium Study, IBM Memo» где подвергла сомнению заявление Intel.
19.9999973251 декабря 1994 года фирма Intel объявила, что она начинает заменять процессоры Pentium по требованию. Энди Гроув принес публичные извинения. История стоила Intel более половины прибыли за последний квартал 1994 года — $475 000 000.
Пресса не утихала, а народ хотел фаталити.
Алан Эдельман (Alan Edelman)
18.9999163362 сентября 1995 года Алан Эдельман опубликовал отчет, в котором провел детальный анализ этой ошибки.
Читать еще
- Statistical Analysis of Floating Point Flaw: Intel White Paper
- Pentium Bug Revisited
- A Tale of Two Numbers
- «United we stand, divided we fall»
- Wikipedia: Pentium FDIV bug
- «Наука отладки»
P.S.
Топ-10 слоганов Intel «от фанатов»
- 9.9999973251 It’s a FLAW, Dammit, not a Bug
- 8.9999163362 It’s Close Enough, We Say So
- 7.9999414610 Nearly 300 Correct Opcodes
- 6.9999831538 You Don’t Need to Know What’s Inside
- 5.9999835137 Redefining the PC—and Mathematics As Well
- 4.9999999021 We Fixed It, Really
- 3.9998245917 Division Considered Harmful
- 2.9991523619 Why Do You Think They Call It *Floating* Point?
- 1.9999103517 We’re Looking for a Few Good Flaws
- 0.9999999998 The Errata Inside
Ранние варианты процессоров Pentium с частотами 60—100 МГц (ядра P5 и P54C) имели ошибку в модуле FPU (математический сопроцессор), которая в редких случаях приводила к уменьшению точности операции деления. Этот дефект был обнаружен в 1994 году и стал известен как «Pentium FDIV bug».
Несмотря на небольшую возможность столкнуться с ошибкой, сам факт ее наличия больно ударил по репутации Intel. Продажи встали. Производство процессоров было приостановлено до выпуска новой версии.
Когда все было позади, каждый инженер Intel получил вот такой брелок с настоятельной рекомендацией не расставаться с ним. В брелок впаян кристалл Pentium, содержащий ошибку. На нем также написаны слова Энди Гроува, руководителя корпорации.
«Кризисы разрушают плохие компании. Хорошие компании переживают их. Великие компании от кризисов становятся лучше».
Или, проще говоря, нас reboot, а мы крепчаем 
Ошибка Pentium FDIV — это ошибка в модуле операций с плавающей запятой в оригинальных процессорах Pentium, выпускавшихся фирмой Intel в 1994 году. Ошибка выражалась в том, что при проведении деления над числами с плавающей запятой при помощи команды процессора FDIV в некоторых случаях результат мог быть некорректным.
Данная ошибка была впервые обнаружена и опубликована профессором Линчбургского колледжа Томасом Найсли в октябре 1994 года[1].
Согласно заявлению Intel причиной проблемы послужили неточности в таблице поиска, используемой при проведении операции деления[2].
Как оказалось, в Intel знали об этой проблеме, но молчали. К тому же в Intel считали, что поскольку этот дефект существенен лишь для узкого круга пользователей (математиков и других ученых), то пользователи, которые хотят заменить процессор, должны обратиться в компанию и доказать, что именно им эта замена необходима.
Стремление производителя утаить проблему и реакция на её обнаружение вызвали недовольство потребителей и обширную критику в СМИ, в том числе жесткий репортаж CNN.
В результате компания изменила позицию и объявила, что будет свободно обменивать дефектные процессоры всем желающим. Энди Гроув принес публичные извинения. История стоила Intel более половины прибыли за последний квартал 1994 г. — $475 млнШаблон:Sfn.
Воспроизведение ошибки[]
Воспроизвести ошибку можно самостоятельно в приложениях, которые используют математический сопроцессор при работе с числами с плавающей запятой.
4195835.0/3145727.0 = 1.333 820 449 136 241 002 (Правильное значение)
4195835.0/3145727.0 = 1.333 739 068 902 037 589 (Ошибочное значение, возвращаемое процессором, содержащим дефект)
Более наглядный способ воспроизведения:
4195835*3145727/3145727 = 4195835 (При умножении и делении на одно и то же число получаем исходное число)
4195835*3145727/3145727 = 4195579 (Ошибочное значение, возвращаемое процессором, содержащим дефект)
Методы защиты[]
- В компиляторе Delphi предусмотрена опция Pentium Safe FDIV, заставляющая компилятор вместо использования ассемблерной команды FDIV в коде программы, применять вызов специальной процедуры, которая при первом вызове производит проверку наличия ошибки, и в зависимости от результата при этом и последующих вызовах, либо выполняет простой FDIV, либо производит коррекцию результата.
- В компиляторе Visual Basic предусмотрена проверка наличия данной ошибки, которая включена по умолчанию. Однако она отключается специальной опцией компилятора — Remove Safe Pentium™ FDIV Checks. В случае её включения, компилятор не генерирует дополнительный код, и в некоторых случаях скорость вычислений возрастает.
Ссылки[]
- ↑ Шаблон:Cite web
- ↑ Шаблон:Cite web
Литература[]
- Шаблон:Книга
La Forge писал(а):Собственно, согласно Вике, обнаружена она в октябре 94-го.
Я давно заинтересовался этим вопросом и составил список Пеньков содержащих данную ошибку.
Итак, среди процессоров Pentium на ядре Р54 FDIV-bug содержали степпинги B1 и C1 — это следующие спеки:
SX753 — SX835 — SZ949 — SX926 — SX754 — SX837 — SZ950 и инженерники: Q0352, Q0412, Q0353, Q0413, Q0466 и Q0467
— а вот в камнях со степпингом D1 ошибку уже исправили.
Так вот, встречается ли этот баг в процессорах под Socket 5,7?
У ядра P54C ошибка среди степпингов B1 и B3, больше всего успели выпустить с ней на 90MHz:
SX874 — SX879 — SX885 — SX909 — SX921 — SX922 — SX923 — SX942 — SX943 — SX944 — SZ951 — все они в корпусе Goldcap
Были ещё инженерники: Q0542, Q0613, Q0543, Q0628, Q0611, Q0612 — но их в рассчёт не беру, они и так сами по себе редки.
Из модей на 100MHz это: SX886 — SX910 — SX960 — и ES: Q0563, Q0587, Q0614, Q0677 — так-же все в корпусе Goldcap
Появившиеся позже них Пентиумы на 75MHz со степпингом B1 выпустили только пару инженерников Q0540 и Q0541
а так-же мобильные в корпусе TCP-320, FDIV-bug имеется у спека: SX951 и пары ES: Q0601 и Q0606
Ну и попутно… Socket 5 процессоры в корпусе Goldcap, чем-то отличаются от своих чисто керамических собратьев?
И много ли таких было выпущено?
В работе — вряд-ли, но ведь надо было как-то оправдать цену в $850 за 90MHz и $995 за 100MHz модели Pentium 
Выпускали их с марта 94-го по февраль 95-го, позднее не встречал. Если очень интересно количество, то нужно найти
где-то по-месячную статистику выпуска. Серийные спеки без ошибки встречаются с января 95-го, но Интел знала о ней
до публикации Т. Найсли в октябре 1994 года, хоть они и уверяют что для них тот звонок в октябре 94 в техподдержку
Фолсомы был неожиданностью 
Ниже привожу фото инженерников P54 Q0436 и даже P54C Q0654 без FDIV-bug
выпущеных на 27-й (конец июня — начало июля) и 42-й неделе 94-го года (с 10 по 16 число) — это значит что работы
по устранению ошибки уже велись, просто она не афишировалась.
И бывают ли Socket 7 в Goldcap?
Нет. Разъём Socket 7 внедрили с появлением ядра P54CS с поддержкой двойного напряжения на само ядро и линии I/O
и эти процессоры (от 133MHz) в Goldcap уже не выпускались.
Психологическая зрелость — это понимание того, как много вещей в мире не нуждается ни в твоих комментариях, ни в твоем мнении.