上次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
這種公司在經歷過這種事件後還會犯一樣的公關錯誤。