L’erreur à 475 millions de dollars d’Intel : le problème matériel du bug de division du Pentium

• Sorti en 1993, le Pentium a adopté la méthode SRT pour effectuer des divisions en virgule flottante plus rapides que l’Intel 486, mais l’erreur de l’instruction FDIV a été rendue publique en 1994 ; Intel a accepté de remplacer toutes les puces défectueuses, pour un coût de 475 millions de dollars
• Le défaut se trouvait dans la PLA qui implémentait la table de consultation utilisée pour la division. Intel a déclaré que 5 entrées manquaient à cause d’une erreur de script, mais l’analyse du die indique 16 omissions, dont 5 provoquaient effectivement l’erreur
• La division SRT en radix 4 produit 2 bits de quotient par étape et est rapide, mais elle repose sur une structure complexe : le reste partiel et le diviseur sont mappés dans une table P-D de 2 048 entrées, puis compressés dans une PLA de 112 lignes
• La cause principale tient au fait qu’à cause du carry-save adder, l’index de consultation peut se retrouver une cellule en dessous du reste partiel réel ; Intel a appliqué une correction mathématique erronée à la borne supérieure de la zone +2, laissant certaines cellules à 0
• Le Pentium corrigé ne s’est pas contenté de remplir les 5 entrées manquantes : il a rempli toute la zone inutilisée de la table avec 2, simplifiant les limites ; l’usage de la PLA est aussi passé de 120 lignes à 74, soit environ un tiers de moins que la PLA défectueuse

---

Comment le bug FDIV a été révélé et combien il a coûté

• Intel a lancé en 1993 le processeur Pentium hautes performances, avec un algorithme de division en virgule flottante plus rapide que celui de l’Intel 486 précédent
• En mai 1994, des tests internes chez Intel ont révélé que la division en virgule flottante du Pentium donnait, très rarement, des résultats incorrects
  • Intel a estimé qu’environ une valeur sur 9 milliards seulement posait problème, et a considéré le défaut comme mineur
  • Le circuit du Pentium a néanmoins été corrigé discrètement
• En octobre 1994, le professeur Thomas Nicely a découvert un résultat de calcul erroné lors de ses recherches sur les inverses de nombres premiers jumeaux
  • Le calcul de 1/824633702441 était faux sur trois ordinateurs Pentium différents, tandis que des ordinateurs plus anciens donnaient la bonne réponse
  • N’obtenant pas de réponse suffisante du support technique d’Intel, Nicely a envoyé un e-mail à des magazines informatiques et à des particuliers
  • Cet e-mail a été publié sur un forum Compuserve, et Electronic Engineering Times a publié le 7 novembre Intel fixes a Pentium FPU glitch
• Au départ, Intel voulait ne proposer un remplacement qu’aux clients capables de convaincre un ingénieur qu’ils avaient besoin d’exactitude, et les utilisateurs ont exprimé leur mécontentement sur des groupes en ligne comme comp.sys.intel
• Après un reportage de CNN le 22 novembre, l’attention du grand public a augmenté ; la situation s’est aggravée le 12 décembre, quand IBM a annoncé suspendre les livraisons d’ordinateurs Pentium
• Le 19 décembre, Intel a annoncé qu’il remplacerait les puces défectueuses pour tous les clients
  • Le coût du rappel a été de 475 millions de dollars
  • Cela représente plus d’un milliard de dollars en valeur actuelle

La division SRT utilisée par le Pentium

• Une division binaire longue classique est lente, car elle nécessite un cycle d’horloge pour chaque bit du quotient
  • L’Intel 486 et les processeurs précédents utilisaient cette approche
• Le Pentium utilise l’algorithme SRT en radix 4, c’est-à-dire par groupes de 2 bits
  • Il génère 2 bits de quotient à chaque étape, ce qui le rend deux fois plus rapide qu’une division binaire classique
  • Chaque chiffre du quotient vaut l’une des valeurs -2, -1, 0, 1, 2
• Comme SRT autorise des chiffres de quotient négatifs, même si l’on choisit une valeur un peu trop grande à une étape, elle peut être corrigée par un chiffre négatif à l’étape suivante
• Le chiffre du quotient n’a pas besoin d’être déterminé de manière unique, ce qui permet de le choisir rapidement via une table de consultation
  • Le reste partiel et le diviseur sont tronqués à quelques bits afin de réduire la taille de la table à un niveau pratique
• Cette méthode est rapide, mais nécessite en plus une table de consultation, des circuits pour ajouter ou soustraire des multiples de 1 ou 2, et des circuits pour convertir le résultat en une forme standard de quotient

Une table de 2 048 entrées compressée en une PLA de 112 lignes

• La table de consultation SRT du Pentium prend en entrée le reste partiel p et le diviseur d, puis renvoie le chiffre de quotient approprié
• La table comporte 2 048 entrées
  • Le diviseur est mis à l’échelle entre 1 et 2 et devient la coordonnée de l’axe X
  • Le reste partiel devient une coordonnée de l’axe Y, avec une valeur comprise entre -8 et 8
  • Pour le diviseur, on utilise les 4 bits de 1.dddd en excluant le premier bit, toujours égal à 1
  • Le reste partiel est tronqué en une valeur signée sur 7 bits pppp.ppp
  • L’index total fait 11 bits, pointant vers 2^11 = 2048 entrées
• La table comporte 5 zones correspondant aux chiffres de quotient +2, +1, 0, -1, -2
  • Certaines zones en haut et en bas ne sont pas utilisées mathématiquement par SRT
  • Dans la table défectueuse d’origine, les entrées inutilisées étaient remplies avec 0
  • Les 5 entrées rouges problématiques auraient dû valoir +2, mais étaient restées à 0
• Le Pentium implémente cette table non pas sous forme de ROM, mais avec une PLA (Programmable Logic Array)
  • Stocker toute la table en ROM aurait nécessité 2 048 lignes
  • Comme la structure de la table est régulière et comporte beaucoup de zones vides, la PLA n’utilise que 112 lignes
• Une PLA se compose d’un plan AND et d’un plan OR
  • Le plan AND génère des termes logiques à partir de combinaisons de bits d’entrée et de leurs compléments
  • Le plan OR combine ces termes pour produire les bits de sortie indiquant si le quotient vaut 1 ou 2
• En extrayant au microscope les motifs de transistors de la PLA, on peut reconstruire l’expression logique de chaque ligne de la PLA
  • Une ligne de PLA ne correspond pas à une seule case de la table : elle agit plutôt comme une zone rectangulaire couvrant plusieurs cases à la fois
  • Plus une limite de table est irrégulière, plus il faut de lignes de PLA

Les limites mathématiques et la zone +2 erronée

• L’étape clé de la division SRT consiste à choisir le chiffre de quotient q à partir du rapport p/d, où p est le reste partiel et d le diviseur
• Pour des raisons mathématiques, la plage autorisée de p/d doit rester dans [-8/3, 8/3]
  • Après avoir choisi le chiffre de quotient, on soustrait q*d puis on multiplie par 4 pour produire le reste partiel de l’étape suivante
  • Pour que ce processus puisse se répéter, la nouvelle plage doit avoir la même taille que la plage d’origine
• SRT comporte de la redondance : dans certains intervalles, il est possible de choisir l’un de deux chiffres de quotient
  • Mais si l’on choisit 0 à un endroit où q=2 est obligatoire, le reste partiel suivant sort de la plage autorisée et l’algorithme ne peut plus se rétablir
  • Le bug FDIV correspond à ce cas
• La table P-D du Pentium est une quantification, cellule par cellule, de cette limite mathématique
  • Les limites diagonales déterminent quelles cellules doivent impérativement être +2, lesquelles peuvent être +1 ou +2, lesquelles doivent impérativement être +1, etc.
• L’analyse du die montre que, dans la table défectueuse, la limite magenta supérieure devait impérativement rester au-dessus de la limite mathématique noire, mais la franchissait à plusieurs reprises
  • En conséquence, certaines cellules qui devaient impérativement valoir +2 sont restées à 0
  • Ce sont ces cellules qui constituent les entrées manquantes à l’origine du bug FDIV

Comment le carry-save adder a rendu l’erreur rare, mais décisive

• Le circuit de division du Pentium utilise un carry-save adder pour accélérer les additions et soustractions
  • Un carry-save adder ne propage pas immédiatement les retenues : il les stocke dans un mot séparé, ce qui est avantageux pour la division, qui exige de nombreuses additions
  • À la fin, une addition plus lente est nécessaire pour combiner les retenues stockées
• L’index de la table de consultation a besoin du reste partiel, mais le carry-save adder conserve ce reste partiel séparé en bits de somme et bits de retenue
• Le Pentium utilise un carry-lookahead adder pour calculer rapidement les 7 bits nécessaires à l’index de la table
  • Ce circuit calcule les retenues de chaque position en parallèle
  • Sa complexité le rend inadapté aux grands mots, mais il est pratique pour une valeur de 7 bits
• Le problème est que le reste partiel fait 64 bits, tandis que le calcul de l’index de la table n’en utilise que 7
  • Lorsque les bits restants sont tronqués avant l’addition, le reste partiel utilisé pour l’index peut devenir légèrement inférieur à la valeur réelle
  • Concrètement, cela peut créer un décalage d’une cellule vers le bas par rapport à la bonne cellule, soit un offset de 1/8
• À cause de cet effet, certaines limites doivent être déplacées vers le bas de 1/8, mais pas toutes
  • La limite supérieure +2 ne doit pas être déplacée vers le bas, or Intel a généré une table qui la déplaçait à tort
  • Cet effet lié au carry-save était un effet connu, déjà mentionné dans les articles sur la division SRT de l’époque

Là où l’explication d’Intel diverge de l’analyse du die

• Le livre blanc d’Intel explique que quelques entrées ont été omises de la PLA à cause d’un problème dans le script qui y insérait la table
  • Intel appelait cela une Programmable Lookup Array, mais la structure réelle est une Programmable Logic Array
• L’analyse du die estime que les entrées manquantes correspondent mieux à une erreur de limite mathématique qu’à une simple erreur de copie
  • Il est possible que le programme de génération de la table ait mal défini les conditions aux limites
  • Le terme « script » peut être techniquement correct s’il désigne un programme C générant la table, mais l’interprétation est que le cœur du problème était une limite mathématique erronée
• The Pentium Chronicles de Robert Colwell propose une autre explication
  • Selon lui, la conception du Pentium utilisait à l’origine la même table de consultation que le 486, puis une erreur serait apparue lors d’une optimisation de dernière minute visant à économiser de la surface sur le die
• Cette explication présente des incohérences
  • Le Pentium utilisait dès le départ un algorithme de division différent de celui du 486
  • Le Pentium emploie SRT en radix 4, tandis que le 486 utilise une division binaire standard
  • Le 486 ne possède pas cette table de consultation
  • La PLA défectueuse contenait 8 lignes inutilisées ; si l’objectif avait simplement été de réduire le circuit, ces lignes auraient pu être retirées en premier

Pourquoi la PLA corrigée est devenue plus petite

• Les articles de l’époque indiquaient qu’Intel avait ajouté quelques dizaines de transistors ou une séquence de portes supplémentaire à la PLA pour corriger le défaut
• La PLA corrigée observée sur le die montre exactement l’inverse
  • La taille de la PLA est restée la même
  • Environ un tiers des termes a été supprimé
  • Seules 74 lignes sur 120 sont utilisées, les 46 autres étant vides
  • La PLA défectueuse d’origine ne comptait que 8 lignes vides
• La correction d’Intel ne s’est pas limitée à remplir avec 2 les 5 entrées manquantes
  • Toutes les entrées de table inutilisées ont été remplies avec 2
  • Cela supprimait la possibilité d’accéder par erreur à une entrée vide
• Remplir les zones inutilisées avec 2 a simplifié les limites de la table
  • Des limites irrégulières nécessitent de nombreux termes de PLA
  • Une grande zone rectangulaire peut être couverte par un seul terme de PLA
  • Ainsi, même si davantage de cellules de la table ont été remplies, l’expression de la PLA est devenue plus simple
• Les termes logiques de la PLA corrigée étant complètement différents de ceux de la PLA d’origine, il est difficile de désigner quelques transistors précis comme ayant corrigé le bug

Impact réel et controverse

• Dans des divisions aléatoires, la probabilité que le défaut survienne est très faible, d’environ 1 sur 9 milliards
  • Les résultats de division erronés ne diffèrent généralement qu’à la 9e ou 10e décimale
  • Dans de rares pires cas, l’erreur apparaît au 4e chiffre significatif
• Le livre blanc d’Intel estimait qu’un utilisateur ordinaire avait une chance de rencontrer le problème une fois tous les 27 000 ans
  • Intel indiquait que ce n’était pas un problème pour la plupart des utilisateurs, mais que certains usages scientifiques, d’ingénierie et de finance quantitative pouvaient nécessiter un processeur corrigé ou un contournement logiciel
• IBM, dans sa propre analyse, a estimé que ses clients pouvaient rencontrer le problème tous les quelques jours et a interrompu les ventes de Pentium
  • IBM disposait aussi à l’époque du processeur concurrent PowerPC
• Certaines évaluations estiment que, dans l’usage réel, la seule personne ayant effectivement découvert le bug était le professeur Nicely
  • L’analyse d’IBM est jugée avoir en partie choisi des nombres susceptibles de déclencher l’erreur
  • La plupart des utilisateurs ne rencontreraient pas le bug et, même si cela arrivait, une faible dégradation de la précision en virgule flottante ne poserait probablement pas problème
• Mais le bug FDIV est reproductible de façon déterministe
  • Si un dividend et un divisor précis déclenchent le problème, le résultat sera incorrect dans 100 % des cas
  • Comme les clients pouvaient le reproduire facilement sur leur ordinateur, Intel pouvait difficilement soutenir qu’il s’agissait d’un problème qu’ils ne rencontreraient jamais

Bugs processeur ultérieurs et microcode patchable

• Le bug FDIV est l’un des bugs de processeur les plus célèbres, mais Intel a connu d’autres défauts importants
• Certains premiers processeurs 386 avaient un problème de multiplication 32 bits
  • Sous certaines conditions de température, de tension et de fréquence, ils donnaient des résultats erronés de manière imprévisible
  • La cause était un problème de layout avec une marge électrique insuffisante
  • Intel a limité la vente des puces défectueuses au marché 16 bits et les a marquées « 16 BIT S/W ONLY »
• Un autre problème du Pentium, le bug F00F, a été découvert en 1997
  • Une séquence d’instructions particulière commençant par F0 0F pouvait bloquer le processeur jusqu’au redémarrage
  • Il a été résolu par une mise à jour du système d’exploitation
• Dans le Pentium, le microcode était codé en dur dans une ROM, il était donc impossible de corriger le bug FDIV par une mise à jour de microcode
• Intel a ajouté un microcode patchable au Pentium Pro en 1995
  • À l’origine, c’était destiné au débogage et aux tests de la puce
  • Après le bug FDIV, sa valeur pour corriger des bugs est devenue évidente
  • Le Pentium Pro comportait, en plus du microcode en ROM, une SRAM pouvant contenir jusqu’à 60 micro-instructions, et le BIOS pouvait charger un correctif au démarrage
• Les correctifs de microcode des processeurs Intel modernes sont utilisés pour divers problèmes, des vulnérabilités Spectre aux problèmes de tension

Une erreur née de circuits devenus plus complexes

• Avec l’augmentation du nombre de transistors dans les processeurs selon la loi de Moore, les circuits et les algorithmes sont devenus plus complexes
• L’évolution de la prise en charge de la division l’illustre bien
  • L’Intel 8080 de 1974 utilisait 6 000 transistors et ne prenait pas en charge la division matérielle ni l’arithmétique en virgule flottante
  • L’Intel 8086 de 1978 utilisait 29 000 transistors ; la division entière était implémentée en microcode, mais la virgule flottante nécessitait le coprocesseur 8087
  • L’Intel 486 de 1989 intégrait la prise en charge de la virgule flottante sur la puce, avec 1,2 million de transistors
  • Le Pentium de 1993 comptait 3,1 millions de transistors et adoptait un algorithme de division SRT plus rapide, mais plus complexe
• À elle seule, la PLA de division du Pentium comporte environ 4 900 emplacements de transistors
  • C’est plus que l’ensemble du processeur MOS Technology 6502
  • Un seul composant du circuit de division du Pentium utilisait donc plus de transistors qu’un processeur entier de 1975
• L’impact à long terme du bug FDIV fait débat
  • Des concurrents comme AMD en ont profité avec des publicités se moquant du problème du Pentium
  • Robert Colwell estime que le bug FDIV a fortement accru la notoriété du nom Pentium et montré qu’Intel soutenait sa marque, si bien que son effet net a pu être positif
• Intel a survécu au bug FDIV, mais ce défaut a montré qu’une combinaison de mathématiques complexes, de compression de circuits et de limites de validation pouvait transformer une erreur extrêmement rare en un grave problème de confiance

[GN⁺]

Commentaires sur Hacker News

• C’est l’auteur. Je peux répondre aux questions sur le Pentium :-)
  Un fil Mastodon sur ce bug a été publié sur HN il y a quelques semaines, donc cela vous est peut-être familier, mais j’ai maintenant terminé le billet de blog détaillé. Il y a aussi pas mal de commentaires sur le précédent post HN : https://news.ycombinator.com/item?id=42391079

  • Ces 475 millions de dollars ont peut-être été, du point de vue d’Intel, la meilleure dépense marketing possible. Grâce au bug et au rappel, même des gens extérieurs à l’industrie tech ont découvert Intel, et à un moment où l’on s’attendait à voir arriver 586 ou 686 après le 486, le nom Pentium est apparu soudainement ; à mon avis, cet épisode a construit une notoriété et une bonne volonté qui ont perduré jusqu’au Pentium MMX
  • Comme toujours, l’article et l’analyse sont excellents. Avec le recul, c’est assez étrange qu’un problème qu’on pourrait considérer comme une erreur mineure de CPU ait fait les gros titres dans le monde entier
    Il y avait des erreurs plus graves chez Intel, et d’autres dans d’autres entreprises, mais elles ont été complètement oubliées. Je suis curieux au sujet de la pile de valeurs de l’unité en virgule flottante du Pentium — je ne connais pas le nom exact — et de la refonte correspondante. Cela remonte à longtemps, mais est-ce qu’il n’y avait pas une sorte de première forme de register renaming qui obligeait à gérer manuellement fxchg avec précaution ?
  • Le passage « le bug se trouve probablement dans l’énorme microcode du Pentium. Le microcode est trop complexe à analyser, donc n’attendez pas de billet de blog détaillé sur le sujet » m’intrigue
    À quel point est-il difficile de « dumper » le microcode sous forme de bitstream ? Est-ce faisable par programme à partir de photos haute résolution du die ? Bien sûr, cela reste peut-être la partie facile comparée au travail de rétro-ingénierie nécessaire pour comprendre ce que signifie le bitstream
    Le passage « j’ai examiné attentivement le PLA au microscope » m’intrigue aussi. J’aimerais savoir si ce genre de travail se fait chez soi, quel équipement il y a dans le labo, et comment on acquiert ce type de compétences
  • J’allais demander si l’usage du nombre d’Avogadro dans l’explication des nombres à virgule flottante était volontaire, puis j’ai réalisé que l’autre nombre était la constante de Planck
  • C’est la première fois que j’apprends qu’une division en virgule flottante peut être implémentée de cette façon. C’est presque drôle de me rendre compte que, pour implémenter réellement une division en virgule flottante, il faut plusieurs étapes de division entière
    Avec le recul, on se demande pourquoi les parties inutilisées de la table de consultation n’ont pas été remplies dès le départ avec 2 et -2

• Le bug en lui-même est intéressant, mais la réponse d’Intel l’est tout autant. Il ne me semble pas qu’ils aient remplacé le processeur par un exemplaire sans défaut pour tous ceux qui le souhaitaient, et ils ont reçu d’énormes critiques pour cela
  Par comparaison, cela me fait beaucoup penser au lancement de l’Amazon Colorsoft. Certains appareils — le mien compris — avaient un problème graphique de bande jaune ; Amazon a vérifié les faits pendant un ou deux jours, l’a reconnu, puis a discrètement remplacé tous les exemplaires. Pas de rappel, ils envoient simplement un nouveau produit sur demande. Mon remplacement arrive vendredi ; j’espère que ce sera réglé. Quand un lancement se passe mal, disposer d’un système de retours/support très solide semble clairement être un avantage bien plus important que ce qu’une analyse laisserait prévoir
  De la même façon, le problème de bruit des Apple AirPods Pro, il y a quelques années, n’a pas non plus fait tant de bruit que ça récemment. J’ai dû faire remplacer mes AirPods deux fois, mais Apple l’a fait discrètement, et j’ai eu l’impression que leur capacité de support, peu visible en surface, fonctionnait en réalité de façon très efficace
  Colorsoft : https://www.tomsguide.com/tablets/e-readers/amazon-kindle-co...
  AirPods Pro : https://support.apple.com/airpods-pro-service-program-sound-...

  • Les cas Kindle et AirPod ne collent pas très bien au Pentium, car il s’agit de produits relativement mineurs pour chacune de ces entreprises
    Côté Apple, l’Antennagate de l’iPhone 4 serait une meilleure comparaison. Dans ce cas, la solution équivalente aurait été de remplacer gratuitement un produit phare essentiel au chiffre d’affaires, mais Apple ne l’a pas fait
    En revanche, Intel a fini par offrir un remplacement gratuit à toute personne qui en faisait la demande, en acceptant un gros choc financier
  • J’utilisais un MacBook blanc de première génération, et à cause du mécanisme de fermeture magnétique, le boîtier supérieur s’est fissuré et décoloré. On me l’a remplacé gratuitement trois ou quatre fois pendant la durée de vie de l’ordinateur, et même après la fin des 3 ans d’AppleCare
    Cette façon qu’a Apple d’assumer ses produits mérite vraiment le respect
  • J’ai toujours pensé que la réponse d’Intel avait été, pendant un temps, d’investir fortement dans la précision. Puis ils ont estimé qu’AMD n’était pas pénalisé malgré un taux de défauts plus élevé, et récemment ils semblent avoir investi dans d’autres domaines pour concurrencer AMD plutôt que sur le critère du faible nombre de bugs CPU
  • Globalement, ce n’était pas vraiment un problème de consommateurs individuels. Les entreprises achetaient des ordinateurs Pentium assez chers via des distributeurs, et selon les contrats de support, c’était le fournisseur qui procédait au remplacement
    Je vois ce que vous voulez dire, pour avoir connu la situation de « garantie implicite » côté Apple grand public, mais à mon avis c’était très différent de la crise IT à laquelle Intel faisait face. À l’époque, le simple fait que « IBM l’ait dit » avait un poids énorme dans l’IT
  • C’est la méthode Amazon de base. On peut renvoyer presque n’importe quoi sans difficulté, pour quasiment n’importe quelle raison

• Dans son livre blanc, Intel affirmait qu’un utilisateur ordinaire ne rencontrerait le problème qu’une fois tous les 27 000 ans, et que c’était négligeable comparé à d’autres sources d’erreur comme les flips de bits en DRAM. IBM, à l’inverse, estimait dans sa propre analyse qu’un client pouvait y être confronté tous les quelques jours
  Ces chiffres ne sont probablement pas aussi éloignés qu’ils en ont l’air. Intel semble avoir raisonné à l’échelle d’un utilisateur individuel, tandis qu’IBM a peut-être réfléchi du point de vue des demandes au support
  J’ai connu un problème similaire au travail. Quand on traite 100 millions de requêtes par jour, un problème à une chance sur un milliard finit par se produire quelques fois par mois. Si c’est le genre de chose que le client, ou pire encore un administrateur, remarque, les gens ignorent le dénominateur et soupçonnent tout le monde d’incompétence. Quatre fois par mois peuvent se traduire par « tout le temps » dans les biais de l’expérience humaine. Si un regroupement statistique de trois fois par semaine se produit deux fois, quelqu’un finit par exploser

  • Non. L’estimation d’IBM est elle aussi basée sur un utilisateur individuel. IBM calculait qu’un utilisateur typique de tableur effectuait 5 000 divisions par seconde pendant un recalcul, et passait 15 minutes par jour à recalculer
    IBM considérait aussi que les nombres utilisés par les gens avaient 90 fois plus de chances de provoquer l’erreur que les nombres à distribution uniforme pris par Intel. On arrivait donc à un résultat d’une erreur tous les 24 jours pour un utilisateur

• Il y a ce passage : « Il semble que la seule personne à avoir remarqué ce bug en usage réel ait été le professeur Nicely »
  Cela me rappelle une vieille étude où l’on avait distribué à des étudiants des calculatrices pour les cours de maths. Les calculatrices avaient été trafiquées pour produire des résultats erronés, et les chercheurs voulaient savoir à quel point elles devaient se tromper pour que les étudiants remarquent l’anomalie
  La réponse était un facteur 2
  Remarquer une erreur et subir les conséquences d’une erreur sont deux choses complètement différentes. Combien de gens vérifient que la sortie d’un ordinateur est correcte ? À mon avis, très, très, très peu. Moi non plus, sauf une fois chez Boeing où, pour un calcul d’ingénierie, j’ai refait l’équation à l’envers pour vérifier que la sortie correspondait à l’entrée

  • Je donnais des cours particuliers de physique à l’université. Quand des étudiants me montraient un problème résolu et demandaient un retour, je leur disais parfois qu’ils avaient calculé qu’un grand huit faisait 23 000 miles de haut, donc qu’il y avait clairement une erreur quelque part
    Au final, cela dépend beaucoup du contexte et du degré de compréhension du sujet par la personne qui fait le calcul
  • La phrase « remarquer une erreur et subir les conséquences d’une erreur sont deux choses complètement différentes » n’est vraie que jusqu’à un certain point. Pour prendre un exemple grand public, si un résultat erroné se produit pendant une partie, mais qu’au final personne ne s’en aperçoit, a-t-on vraiment été affecté ?
    Dans quelle mesure l’usage de FDIV sur Pentium servait-il à produire des sorties numériquement importantes, plutôt qu’à du multimédia ?

• Je me souviens de ce bug. Comme je ne pouvais pas contrôler sur quel CPU tournaient mes clients, j’ai dû ajouter à la bibliothèque un code de détection du FPU défectueux et exécuter un contournement. Ce code était fourni par Intel
  Autrement dit, le problème d’Intel était devenu mon problème, beurk

• Ça me rappelle une blague qui circulait à l’époque. Elle capturait bien plusieurs ambiances des années 90 :
  I AM PENTIUM OF BORG.
  DIVISION IS FUTILE.
  YOU WILL BE APPROXIMATED.

  • Je crois que c’était peut-être dans mon générateur de signature

• Encore un excellent article de Ken. Je m’en souviens particulièrement parce que le premier PC que j’ai acheté avec mon propre argent contenait un CPU concerné. Avant ça, les PC m’intéressaient peu, parce qu’ils ne pouvaient pas faire tourner de « vrais » logiciels
  Mais Windows NT a changé ça, merci à Cutler. Grâce aussi aux cartes mères taïwanaises bon marché, assembler soi-même sa machine est devenu réaliste, et beaucoup de gens le font encore aujourd’hui. Ken souligne qu’il était facile pour un utilisateur de vérifier si son CPU était concerné. Dans mon souvenir, il suffisait d’entrer dans Excel une formule de division avec des nombres magiques. Si Microsoft avait publié une version d’Excel contournant le bug, il y aurait sans doute eu moins de demandes de remplacement

  • Ces PC ne pouvaient pas faire tourner 386BSD ?

• Analyse intéressante et vraiment tenace. L’effort fourni pour analyser le silicium et partager les résultats est impressionnant. J’ai particulièrement apprécié le fait que, là où la communication d’Intel donnait l’impression que la cause réelle était quelque chose de mineur, comme une simple omission, l’article mette en évidence la véritable cause racine
  En réalité, c’était un problème bien moins excusable et bien plus blâmable : ils avaient raté l’algorithme de génération de la table

• La phrase « Smith a posté cet e-mail sur les forums Compuserve, la version des réseaux sociaux des années 1990 » me fait une drôle d’impression

  • Moi, j’aime parler des années 1900 plutôt que des années 1990
  • Ma première pensée a été que ces données ont probablement disparu sans même avoir été exploitées. Les veinards !
  • Il l’a envoyé depuis un ordinateur personnel, précurseur du smartphone

• La table corrigée était bien plus simple, car elle renvoyait simplement 2 pour les valeurs hors plage au lieu d’ajouter un circuit renvoyant 0 pour les valeurs hors plage. Du coup, on se demande pourquoi ils n’ont pas fait ça dès le départ

  • On dirait une optimisation manquée parce que le travail était réparti entre plusieurs personnes et que personne n’avait une vision complète du problème
    La personne qui a généré la table ne savait peut-être pas que remplir les valeurs hors plage avec 2 aurait produit un PLA plus simple, et la personne qui a injecté la table dans le PLA a peut-être ignoré que 0 était une valeur indifférente (don't care) et a supposé qu’il fallait la préserver
    Ou alors ils ont peut-être arrêté d’optimiser au moment où le PLA leur a semblé assez petit. Si le plan de placement était déjà terminé, réduire encore le PLA n’aurait sans doute pas réduit la taille totale de la puce, et le temps d’ingénierie aurait mieux valu être utilisé ailleurs
  • Cela me rappelle le dicton : « Fais d’abord en sorte que ça marche, ensuite rends-le rapide ». Fondamentalement, c’est un problème logiciel résolu par une technique logicielle
    Comme pour la plupart des logiciels, il y avait une optimisation restante à faire, à laquelle personne n’a pensé à temps. Et les CPU de cette époque ne pouvaient pas être patchés
  • Renvoyer 0 pour des entrées de table non définies est le choix le plus évident. Régler ces entrées sur 2 demande un petit saut conceptuel. Même si cela aurait évité l’erreur FDIV et simplifié le PLA, il est difficile d’en vouloir à Intel pour ça
  • Cela dit, ça a dû être une correction extrêmement satisfaisante pour les ingénieurs
  • En consacrant plus de temps d’ingénierie, ils ont fini par trouver une solution plus efficace