20 Jahre FDIV-Bug: Die Hintergründe

Inhaltsverzeichnis

Mit seiner E-Mail vom 30.Oktober 1994, in der er den FDIV-Bug des Pentium-Prozessors enthüllte, hatte Professor Dr. Thomas R. Nicely geradezu einen Sturm ausgelöst, vor allem einen Sturm der Entrüstung. Auch Nicely war entrüstet, hatte er den bei zahlentheoretischen Berechnungen aufgefallenen Fehler doch schon früher an den Intel-Support gemeldet. Die taten dort sehr überrascht, dabei war Intel der Fehler bereits spätestens seit Juni bekannt. Ansonsten kam keine Reaktion.

Nicely schickte seine Mail am 30. Oktober daher nicht nur an Intel, sondern auch an bekannte Autoren und Journalisten wie Andrew Schulman und stellte sie ins Canopus Forum von Compuserve. Von überall wurde der Fehler bestätigt; dann nahm die Lawine ihren Lauf.

Bei Nicelys Beispiel 1/824633702441.0 lag der relative Fehler nur bei 10^-9, es gab aber noch schlimmere Zahlenpaare mit Divisionsfehler im Bereich von über 10^-5. Das war dann viele Milliarden Mal höher als nach der IEEE-754-Vorschrift für doppelt genaue Gleitkommaoperationen erlaubt.

Intel musste dann den Fehler zugeben und erklärte, dass beim Übertragen einer Tabelle für die Division nach dem SRT-Algorithmus fünf von insgesamt 1066 Werten vergessen worden waren. Der Fehler betraf nicht nur FDIV, sondern viele weitere FPU-Befehle, die intern FDIV verwenden, etwa FPTAN, FPATAN, FPREM ...

Neue fehlerbereinigte Steppings waren bereits in Arbeit. Man wollte den kleinen Lapsus möglichst leise unter den Teppich kehren, aber das ging nun nicht mehr.

Weltweit wurde darüber berichtet, c't ging im Prozessorgeflüster 1/1995 unter "Der Bug von Intels Flaggschiff" erstmals auf den peinlichen Fehler ein. Nach den zahlreichen öffentlichen Protesten entschuldigte sich Intel-Chef Andrew Grove dann, versprach Besserung und hinfort rechtzeitige Unterrichtung über Fehler. Zudem sprach er eine kostenlose, lebenslange Umtauschgarantie aus.

SRT-Algorithmus

Die der Division zugrunde liegende Implementierung des SRT-Algorithmus mit Radix 4 fußt auf einer Master-Arbeit von David E. Atkins III an der Universität Illinois, die man schön auf openLibrary.org nachlesen kann. Er liefert pro Rechenschritt jeweils zwei Bits des Quotienten. Bei jedem Rechenschritt verwendet der Prozessor die sogenannte PD-Lookup-Table und schaut anhand der oberen Mantissenbits des jeweils verbleibenden Restes (6 Bits) und des Divisors (5 Bits) nach, wie der Quotient weitergeht.

Nur wenn der Divisor eines der fünf betroffenen Muster aufweist, kann sich überhaupt ein Fehler ergeben, und auch nur dann, wenn im Verlaufe der weiteren Rechenschritte der verbleibende Rest auch auf die fehlerhaften Einträge verweist.

Clevere Programmierer wie Tim Coe von Vitesse Semiconductors konnten allein anhand von 20 ihm zugeschickten Fehlerpaare die Probleme weitgehend in einem Emulatorprogramm nachstellen, bevor Intel Details dazu bekanntgab. Denn zur Schadensbegrenzung verfasste Intel am 30. November das White Paper "Statistical Analysis of Floating Point Flaw of the Pentium Processor", das neben der Fehlerursache eine statistische Einschätzung zur Auswirkung des Fehlers enthielt.

Gleitkommaberechnungen, erklärte Intel, spielen bei einem Normalbürger hauptsächlich bei Tabellenkalkulationen eine Rolle. Und da wird ohnehin zumeist großzügig gerundet, sodass sich selbst ein (seltener) relativer Fehler von 10^-5 nicht weiter auswirkt. Intel schätzte für den Normalbürger, dass er lediglich auf täglich 15 Minuten Rechenzeit käme. Das wären nur 1500 FDIV-Operationen, sodass sich ein relevanter Fehler erst alle 27.000 Jahre auswirken sollte, weit weniger als die anderen Fehlerquellen im PC. Bei denen ragen vor allem DRAMs ohne ECC heraus, so wie sie auch heute eingesetzt werden und wo Intel damals die Fehlerquote auf einen Fehler alle sieben Jahre abschätzte.

Vor allem IBM protestierte energisch, berechnete eine geringfügig höhere Fehlerquote von einem Fehler alle 6 Rechenstunden und stellte daraufhin den Verkauf von Pentium-Systemen ein. Das muss man wohl auch vor dem Hintergrund der gerade anlaufenden PowerPC-Prozessoren sehen. IBM stellte dabei fest, dass die Gleitkommazahlen in Tabellenkalkulationen nicht wie bei Intels Abschätzung gleichmäßig verteilt sind, sondern gerade die Risikokandidaten mit betroffenen Bitmustern weit häufiger vorkommen, Zahlen etwa wie 1,9999 ... statt 2 mit vielen Einsen in der binären Mantisse.

Umgerechnet auf obigen Normalbürger à la Intel mit gerade mal 15 Minuten Rechenzeit pro Tag käme dann etwa ein relevanter Fehler alle 24 Tage heraus. c't machte ihre eigene Abschätzung, die letztlich mit einem Fehler pro 60 Tage etwas dichter an IBMs Wert als an Intels 27.000 Jahre herankam. Später dann haben sich Mathematiker des Fehlers angenommen und präzisere Abschätzungen über die Häufigkeiten und Größenordnungen vorgenommen, etwa von der Stanford University zufällig genau zeitgleich mit der Analyse von "Mr. Mathworks" Cleve Moler.

Schadensbegrenzung

Der Fehler ließ sich softwaremäßig auf Kosten von Performance verhältnismäßig einfach umschiffen. Es reichte, Zähler und Nenner vor der Division mit einem passenden Wert zu multiplizieren, sodass die Fehlermuster nicht mehr auftreten. Einige der damals empfohlenen Multiplikatoren waren aber völlig ungeeignet, weil sie nicht immer falsche Bitmuster vermieden. c't hatte als besten und kleinsten Wert damals 1.0001 ausgemacht.

Es gab aber auch trickreiche Programme, die sich prahlerisch als "Pentium-Optimierer" bezeichneten. Dabei schalteten sie nur den Coprozessor ganz ab. Andere klinkten sich in den Emulationsinterrupt 7 ein, was aber ebenfalls sehr viel Zeit kostete. c't bot eine effiziente Lösung für die damaligen DOS-Compiler, die beim ersten Aufruf eines FPU-Befehls üblicherweise einen Emulator aufriefen und den Aufruf anschließend durch den echten Coprozessorbefehl ersetzten. Hier konnte sich ein residenter Handler einklinken und gezielt FDIV-Befehle herausfiltern. Spätere Compiler haben die FDIV-Spezialbehandlung dann als Option bereitgestellt. Der Support wurde meist erst in den letzten Jahren eingestellt.

Umtausch

Intel hat seinerzeit das FDIV Replacement Programm mit einer speziellen Online-Seite ins Leben gerufen. Seit einigen Jahren ist der Online-Support aber eingestellt.

c't hat im Laufe der Zeit zweimal die lebenslang garantierte Umtauschgarantie auf die Probe gestellt, beide Male natürlich verdeckt und nicht unter der Redaktionsadresse. Der erste Versuch fand 2003 statt. Man musste eine spezielle Supportnummer anrufen und irgendwie nachweisen, etwa durch einen Screenshot, dass der Prozessor betroffen ist. Dann bekam man per DHL einen Austauschprozessor (leider keinen Overdrive) zugeschickt und musste unbedingt den alten retournieren.

Beim zweiten Versuch 2008 war die Sache schon deutlich komplizierter. Der Support glaubte uns zunächst nicht, doch wir beharrten. Allerdings wollte UPS für den "kostenlosen" Umtausch 100 Euro kassieren. Wir wiesen das ab, legten Protest ein und bekamen danach einige Wochen später tatsächlich eine kostenlose Lieferung. Der dritte Versuch steht noch aus, aber eigentlich mögen wir uns gar nicht von dem Pentium mit FDIV-Bug trennen ... (as)