上次Microcode那篇简单的跟大家回顾了FDIV Bug的问题
今天看到Intel受访的文章，有种熟悉的既视感，来跟大家干个古
Intel出包是不太意外，现在电路、芯片设计的规模比以前大很多了
很多细节“人”没注意到很正常，讲这些不是要护航我个人也是受灾户，超频用平台加上
主力工作站，我手上13~14th gen平台有很多组
讲这个是因为Intel技术出包我能谅解，但在当年事件后公关处理居然还能那么糟糕
目前Intel出过最大包的位置应该要让给目前的事件了，规模看起来是这样，实际商誉损失
和财务损失就不得而知了。
1. Bug的发现与背景
FDIV Bug是由University of Lynchburg(以前叫Lynchburg College)的数学系教授
Thomas Nicely在1994年进行prime(质数)相关研究时发现的，教授写了一系列包含了
twin primes、prime triplet、prime quadruplet的程式码，其中有计算Brun's
constant的程式(所有twin primes的倒数和会趋近一个constant)，教授在计算Brun's
constant的时候发现不管怎么算都结果都是错误的，研究是在6月进行的，一直到10月
底左右教授才排除其他bug发现是CPU的问题。
教授用的CPU是Pentium(P5)，是当年世界上最先进的处理器之一，教授发现在计算
824,633,702,441和824,633,702,443
这两个数字的倒数时，小数后10位会计算错误，为了确定是软件还是硬件错误，他还使
用了前一代CPU i486进行计算，最后才确认是Pentium CPU的问题，并向Intel回报该
Bug
2. FDIV Bug的技术细节
Intel当年为了加速floating point除法的速度，使用了SRT algorithm取代了先前在
486上使用的shift-and-subtract algorithm，SRT在一个Clock cycle可以算出2 bits
的结果，后者只能算出一个，改用SRT algorithm也并不是错误的决定。
错误在哪里呢? SRT algorithm使用了2048 cells的PLA(programmable logic array)来
implement，SRT的计算仰赖一张lookup table，这张lookup table要被填入PLA里，其
中1066个cells应该填入-2、-1、0、+1、+2，原始的array在compile的时候出错了5个
值应该要是+2但是变成了0，这个错误一路传到到了蚀刻PLA进入chip的设备里。
SRT的特性之一是recursive(递回)，所以误差会不断累积，最糟的状况会到第四有效位
数，大部分的错误只到第9、10有效位数而已。这边给大家一个实例4,195,835除以3,14
5,727，正确答案是1.333820449136241002。
这两个数字在运算的时候要转换成hexadecimal(16进制)，前者是0x4005FB，后者是
0x2FFFFF，0x4005FB的5会需要access前面提到错误的array cells，这导致结果是
1.333"739068902037589"
3. Intel的回应与处理
其实这个Bug在一般使用的情况下不太会遇到，统计是90亿个长除法才会遇到一个错误
，而且也并不是所有的除法运算都会遇到这个bug，因此Intel在最初的回应中是“这
是个微不足道的错误，并不影响大多数的使用者，Intel愿意向那些提出证据受到影响
的用户更换CPU。”
10/24 教授向Intel报告
10/30 教授向学术界的其他人发了有关FDIV bug的报告，这个消息很快就透过网络传开
了
11/7 该Bug首次出现在媒体上，发表在EE times上的一篇文章
11/22 被CNN报导，同时也被New York Times和the Boston Globe报导
12/20 Intel正式宣布召回所有有Bug的Pentium CPU
1995/1/17 Intel的年度报告中指出处理FDIV bug的成本是4.75亿美元(应该相当于现在
的8.多亿美元)
这件事件的影响很大，半导体业界使用formal verification的数量明显增加
1996有一种针对SRT的技术问世，叫做"word-level model checking"，Intel在开发
Pentium 4的时候用了STE等方式也发现了很多错误，这些没被发现很可能是规模更大的
召回。但一直到2008年Intel才有架构使用了formal verification作为主要验证方式
(Nehalem)。
这整件事件除了财务上的损失，公关处理得更是糟糕，Intel是禁止OEM和经销商进行召
回的，理由是应该由end user决定该bug是否影响他们的使用。
John Romero(雷神之槌 Quake的开发者)曾经在一次的演讲说他们当年也因为这个Bug花
费了许多时间在追踪问题。
商业的部分IBM甚至宣布停卖Intel CPU的产品，当然IBM这个决策是有点争议的(因为当
时IBM有PowerPC)。
回到一般消费者上，Intel一开始怎么说呢? “这件事情影响不大日常不可能受到影响
，除非你能证明你有被影响，才会更换你的CPU”，Intel的回应引起了不少业界人士的
反弹，到后来媒体和舆论开始发酵后，甚至平常用电脑都不会进行计算的人这类族群也
想采取行动，Intel才终于发现事情不对劲宣布全面召回，消费者对于Intel的信心明显
是被动摇的。忘了写补充一下，后续报导证明Intel在1994年6月就发现了问题，但选择
不披露细节也不召回秘密修补，但最后还是被发现了。
相信看完的你也能明白为什么我会想起FDIV的事件，也回应我开头所讲，我很难相信Intel
这种公司在经历过这种事件后还会犯一样的公关错误。