- 1993 में आया Pentium Intel 486 से तेज़ floating-point division के लिए SRT पद्धति अपनाता था, लेकिन 1994 में FDIV instruction की गलती सार्वजनिक होने के बाद Intel ने सभी खराब chips बदलने पर सहमति दी, जिसकी लागत 475 मिलियन डॉलर रही
- खराबी division के लिए lookup table लागू करने वाले PLA में थी; Intel ने कहा कि script error के कारण 5 entries छूट गई थीं, लेकिन die analysis 16 missing entries और उनमें से 5 के असल में error पैदा करने की ओर इशारा करता है
- radix-4 SRT division हर step में quotient के 2 bits बनाकर तेज़ है, लेकिन partial remainder और divisor को 2048-entry P-D table में map करने और फिर 112-row PLA में compress करने वाली जटिल संरचना रखता है
- मुख्य कारण यह था कि carry-save adder की वजह से lookup index वास्तविक partial remainder से एक cell कम हो सकता था, और Intel ने +2 region की upper boundary पर गलत mathematical correction लागू कर दी, जिससे कुछ cells 0 रह गए
- सुधारे गए Pentium ने सिर्फ missing 5 entries नहीं भरीं, बल्कि unused table area को पूरा 2 से भरकर boundary को सरल बनाया; PLA में इस्तेमाल rows भी 120 में से 74 रह गईं, जिससे यह defective PLA से करीब 1/3 छोटा हो गया
FDIV bug कैसे सार्वजनिक हुआ और लागत कितनी पड़ी
- Intel ने 1993 में high-performance Pentium processor लॉन्च किया और पिछले Intel 486 से तेज़ floating-point division algorithm शामिल किया
- मई 1994 में Intel की internal testing में पता चला कि Pentium का floating-point division बहुत दुर्लभ मामलों में गलत होता है
- Intel ने माना कि लगभग 9 अरब values में से 1 ही समस्या पैदा करती है और इसे मामूली issue समझा
- फिर भी Pentium circuit को चुपचाप ठीक कर दिया गया
- अक्टूबर 1994 में Professor Thomas Nicely ने twin prime reciprocals पर research करते समय गलत calculation result पाया
1/824633702441की calculation तीन अलग-अलग Pentium computers पर गलत थी, जबकि पुराने computers सही answer दे रहे थे- Intel technical support से पर्याप्त response न मिलने पर Nicely ने computer magazines और व्यक्तियों को email भेजे
- यह email Compuserve forum पर पोस्ट हुआ, और Electronic Engineering Times ने 7 नवंबर को Intel fixes a Pentium FPU glitch प्रकाशित किया
- शुरुआत में Intel सिर्फ उन customers को replacement देना चाहता था जो engineers को समझा सकें कि उन्हें accuracy की जरूरत है; users ने comp.sys.intel जैसे online groups में शिकायतें कीं
- 22 नवंबर को CNN की report के बाद public attention बढ़ी, और 12 दिसंबर को IBM ने Pentium computers की shipment रोकने की घोषणा की, जिससे हालात और बिगड़ गए
- Intel ने 19 दिसंबर को घोषणा की कि वह सभी customers के defective chips बदलेगा
- recall cost 475 मिलियन डॉलर थी
- आज के मूल्य में यह 1 अरब डॉलर से अधिक है
Pentium में इस्तेमाल SRT division
- सामान्य binary long division में quotient के हर bit के लिए एक clock लगता है, इसलिए यह धीमा है
- Intel 486 और उससे पहले के processors यही approach इस्तेमाल करते थे
- Pentium ने SRT algorithm को radix-4, यानी 2-bit units में इस्तेमाल किया
- यह एक step में quotient के 2 bits बनाता है, इसलिए सामान्य binary division से दोगुना तेज़ है
- हर quotient digit
-2,-1,0,1,2में से एक होता है
- SRT negative quotient digits की अनुमति देता है, इसलिए अगर किसी step में थोड़ा बड़ा value चुन लिया जाए तो अगले step में negative digit से correction किया जा सकता है
- quotient digit का बिल्कुल unique रूप से तय होना जरूरी नहीं, इसलिए lookup table से तेज़ selection संभव है
- partial remainder और divisor को कुछ bits तक truncate करके table size को practical स्तर तक घटाया जाता है
- यह method तेज़ है, लेकिन lookup table,
1या2multiples को जोड़ने या घटाने वाली circuitry, और standard quotient form में convert करने वाली circuitry अतिरिक्त चाहिए
2048-entry table को 112-row PLA में compress करने वाली संरचना
- Pentium की SRT lookup table partial remainder
pऔर divisordको input लेकर उपयुक्त quotient digit output करती है - table में 2048 entries हैं
- divisor को 1 और 2 के बीच scale किया जाता है और वह X-axis coordinate बनता है
- partial remainder -8 से 8 के बीच value के रूप में Y-axis coordinate बनता है
- divisor में
1.ddddसे आगे का हमेशा-1 bit छोड़कर 4 bits इस्तेमाल होते हैं - partial remainder को 7-bit signed value
pppp.pppमें truncate किया जाता है - कुल 11-bit index से
2^11 = 2048entries address होती हैं
- table में quotient digit
+2,+1,0,-1,-2के अनुरूप 5 regions हैं- ऊपर-नीचे के कुछ regions SRT math के अनुसार इस्तेमाल नहीं होते
- मूल defective table में unused entries 0 से भरी गई थीं
- problem वाली 5 red entries को
+2होना चाहिए था, लेकिन वे 0 रह गई थीं
- Pentium ने इस table को ROM के बजाय PLA(Programmable Logic Array) के रूप में implement किया
- पूरी table को ROM में store करने पर 2048 rows चाहिए होतीं
- table structure regular था और खाली regions बहुत थे, इसलिए PLA में केवल 112 rows इस्तेमाल हुईं
- PLA AND plane और OR plane से बना होता है
- AND plane input bits और complement bits के combinations से logic terms बनाता है
- OR plane उन terms को जोड़कर output bits बनाता है जो बताते हैं कि quotient
1है या2
- microscope से PLA transistor pattern extract करने पर हर PLA row की logic expression reconstruct की जा सकती है
- PLA row table के एक cell की तरह नहीं, बल्कि कई cells को एक साथ cover करने वाले rectangular region की तरह काम करती है
- कोई table boundary जितनी ज्यादा jagged होती है, उतनी ज्यादा PLA rows चाहिए होती हैं
mathematical boundaries और गलत +2 region
- SRT division का core step partial remainder
pको divisordसे divide करने के ratiop/dके आधार पर quotient digitqचुनना है p/dकी allowed range mathematical कारणों से[-8/3, 8/3]के भीतर होनी चाहिए- quotient digit चुनने के बाद
q*dघटाया जाता है और 4 से multiply करके अगले step का partial remainder बनाया जाता है - यह process repeat हो सके, इसके लिए नई range मूल range जितनी ही बड़ी होनी चाहिए
- quotient digit चुनने के बाद
- SRT में redundancy होती है, इसलिए कुछ intervals में दो quotient digits में से एक चुना जा सकता है
- लेकिन जहाँ
q=2होना चाहिए वहाँ0चुनने पर अगला partial remainder allowed interval से बाहर चला जाता है और algorithm recover नहीं कर पाता - FDIV bug इसी case से संबंधित है
- लेकिन जहाँ
- Pentium की P-D table इन mathematical boundaries का cell-level quantization है
- diagonal boundary तय करती है कि कौन-सा cell अनिवार्य रूप से
+2होगा, कौन-सा+1या+2भी हो सकता है, कौन-सा अनिवार्य रूप से+1होगा, आदि
- diagonal boundary तय करती है कि कौन-सा cell अनिवार्य रूप से
- die analysis के अनुसार defective table की ऊपर वाली magenta boundary line अनिवार्य रूप से black mathematical boundary line के ऊपर होनी चाहिए थी, लेकिन वह बार-बार उसे cross करती है
- इसके परिणामस्वरूप कुछ cells जिन्हें अनिवार्य रूप से
+2होना चाहिए था, 0 रह गए - यही cells FDIV bug पैदा करने वाली missing entries हैं
- इसके परिणामस्वरूप कुछ cells जिन्हें अनिवार्य रूप से
carry-save adder ने error को दुर्लभ लेकिन निर्णायक कैसे बनाया
- Pentium का division circuit addition और subtraction तेज़ करने के लिए carry-save adder इस्तेमाल करता है
- carry-save adder carry को तुरंत propagate नहीं करता, बल्कि अलग word में store करता है, इसलिए कई additions की जरूरत वाले division में उपयोगी है
- अंत में stored carry को combine करने के लिए धीमा addition चाहिए होता है
- lookup table index के लिए partial remainder चाहिए, लेकिन carry-save adder partial remainder को sum bits और carry bits में बांटकर रखता है
- Pentium ने table index के लिए जरूरी 7 bits तेज़ी से calculate करने के लिए carry-lookahead adder इस्तेमाल किया
- यह circuit हर position के carry को parallel में calculate करता है
- बड़े words के लिए complexity ज्यादा होती है, इसलिए अनुपयुक्त है, लेकिन 7-bit value के लिए practical है
- समस्या यह थी कि partial remainder 64-bit है, जबकि table index calculation सिर्फ 7 bits इस्तेमाल करती है
- बाकी bits sum होने से पहले truncate हो जाते हैं, जिससे index के लिए partial remainder actual value से थोड़ा कम हो सकता है
- specifically, correct cell से एक cell नीचे, यानी
1/8offset पैदा हो सकता है
- इस effect के कारण कुछ boundaries को
1/8नीचे shift करना चाहिए, लेकिन सभी boundaries को नहीं- upper
+2boundary को नीचे shift नहीं करना चाहिए था, लेकिन Intel ने ऐसी table generate कर दी जिसमें यह गलत shift था - यह carry-save effect उस समय के SRT division papers में भी documented known effect था
- upper
Intel की explanation और die analysis कहाँ अलग हो जाते हैं
- Intel whitepaper ने समझाया कि table को PLA में डालने वाली script में समस्या थी, जिससे कुछ entries PLA से छूट गईं
- Intel ने इसे Programmable Lookup Array कहा, लेकिन वास्तविक structure Programmable Logic Array है
- die analysis के मुताबिक missing entries simple copy mistake की तुलना में mathematical boundary error से ज्यादा मेल खाती हैं
- संभव है कि table generation program ने boundary conditions गलत define किए हों
- “script” शब्द technically सही हो सकता है अगर मतलब C program से table generate करना था, लेकिन issue का सार गलत mathematical boundary है
- Robert Colwell की The Pentium Chronicles अलग explanation देती है
- इसके अनुसार Pentium design मूल रूप से 486 जैसी lookup table इस्तेमाल करता था, और launch से ठीक पहले die space बचाने के दबाव में optimization करते समय error आया
- इस explanation में कुछ बातें फिट नहीं बैठतीं
- Pentium ने शुरुआत से ही 486 से अलग division algorithm इस्तेमाल किया
- Pentium radix-4 SRT इस्तेमाल करता है, जबकि 486 standard binary division इस्तेमाल करता है
- 486 में ऐसी lookup table नहीं है
- defective PLA में 8 unused rows बची थीं; अगर मकसद सिर्फ circuit घटाना था, तो इन्हीं rows को पहले हटाया जा सकता था
corrected PLA छोटा क्यों हो गया
- उस समय की reports में कहा गया कि Intel ने defect fix करने के लिए PLA में कुछ दर्जन transistors या अतिरिक्त gate sequence जोड़े
- die में देखा गया corrected PLA इसके ठीक उलट दिखता है
- PLA size मूल जैसा ही है
- लगभग 1/3 terms हटाए गए
- 120 rows में से सिर्फ 74 rows इस्तेमाल हुईं और बाकी 46 rows खाली हैं
- मूल defective PLA में खाली rows 8 थीं
- Intel का fix सिर्फ missing 5 entries को
2से भरना नहीं था- उसने पूरी unused table entries को 2 से भर दिया
- इससे गलती से किसी empty entry तक पहुंचने की संभावना खत्म हो गई
- unused regions को 2 से भरने पर table boundaries सरल हो गईं
- jagged boundaries के लिए बहुत PLA terms चाहिए होते हैं
- बड़े rectangular regions को एक PLA term से cover किया जा सकता है
- इसलिए ज्यादा table cells भरने के बावजूद PLA expressions सरल हो गईं
- corrected PLA के logic terms मूल PLA से पूरी तरह अलग हो गए, इसलिए यह बताना मुश्किल है कि कुछ खास transistors ने bug fix किया
वास्तविक प्रभाव और विवाद
- random division में defect होने की संभावना लगभग 9 अरब में 1 है, यानी बहुत कम
- गलत division result भी आमतौर पर 9th या 10th decimal place पर अलग होता है
- दुर्लभ worst case में 4th significant digit पर error हो सकता है
- Intel whitepaper ने माना कि सामान्य user के लिए problem का सामना करने की संभावना 27,000 साल में एक बार है
- उसने कहा कि ज्यादातर users के लिए यह problem नहीं है, और science/engineering तथा financial engineering के कुछ users को corrected processor या software workaround की जरूरत हो सकती है
- IBM ने अपनी analysis में कहा कि customers को हर कुछ दिनों में problem हो सकती है और Pentium sales रोक दी
- उस समय IBM के पास competing processor PowerPC भी था
- कुछ आकलनों के अनुसार real-world use में bug खोजने वाले व्यक्ति शायद केवल Professor Nicely ही थे
- IBM analysis में ऐसे numbers चुनने जैसा पहलू माना गया जो error trigger करने में आसान थे
- ज्यादातर users bug से नहीं टकराते, और टकराने पर भी small floating-point accuracy loss संभवतः problem नहीं बनता
- लेकिन FDIV bug deterministically reproduce होता था
- अगर कोई specific dividend और divisor problem trigger करते, तो 100% गलत result मिलता
- customers इसे अपने computer पर आसानी से reproduce कर सकते थे, इसलिए Intel के लिए यह कहना मुश्किल था कि यह “कभी न मिलने वाली problem” है
बाद के processor bugs और patchable microcode
- FDIV bug सबसे प्रसिद्ध processor bugs में से एक है, लेकिन Intel में अन्य महत्वपूर्ण bugs भी थे
- शुरुआती 386 के कुछ processors में 32-bit multiplication problem थी
- विशेष temperature, voltage, frequency conditions में unpredictable रूप से गलत result देते थे
- इसका कारण insufficient electrical margin वाला layout issue था
- Intel ने defective chips को 16-bit market तक सीमित करके बेचा और उन्हें “16 BIT S/W ONLY” से mark किया
- Pentium की एक और problem 1997 में खोजा गया F00F bug था
F0 0Fसे शुरू होने वाला specific instruction sequence processor को reboot तक hang कर देता था- इसे operating system update से solve किया गया
- Pentium में microcode ROM में hardcoded था, इसलिए FDIV bug को microcode update से fix नहीं किया जा सकता था
- Intel ने 1995 में Pentium Pro में patchable microcode जोड़ा
- मूल उद्देश्य chip debugging और testing था
- FDIV bug के बाद bug fixing में भी इसकी value सामने आई
- Pentium Pro में ROM microcode के साथ 60 microinstructions तक रखने वाली SRAM थी, और boot के दौरान BIOS patch load कर सकता था
- आधुनिक Intel processors में microcode patches Spectre vulnerability से लेकर voltage issues तक कई problems के लिए इस्तेमाल होते हैं
जटिल circuits से बनी गलती
- Moore’s Law के अनुसार processor transistor count बढ़ने के साथ circuits और algorithms भी जटिल होते गए
- division support में बदलाव इसे अच्छी तरह दिखाता है
- Intel 8080 ने 1974 में 6000 transistors इस्तेमाल किए और hardware division या floating-point arithmetic support नहीं करता था
- Intel 8086 ने 1978 में 29,000 transistors इस्तेमाल किए और integer division microcode से implement किया, लेकिन floating-point के लिए 8087 coprocessor चाहिए था
- Intel 486 ने 1989 में 1.2 million transistors के साथ floating-point support को chip में integrate किया
- Pentium ने 1993 में 3.1 million transistors के साथ तेज़ लेकिन जटिल SRT division algorithm अपनाया
- सिर्फ Pentium के division PLA में ही लगभग 4900 transistor sites थे
- यह पूरे MOS Technology 6502 processor से ज्यादा है
- यानी Pentium division circuit का एक component 1975 के पूरे processor से ज्यादा transistors इस्तेमाल कर रहा था
- FDIV bug का long-term impact विवादास्पद है
- AMD जैसे competitors ने Pentium problem का मजाक उड़ाने वाले ads से फायदा उठाया
- Robert Colwell मानते हैं कि FDIV bug ने Pentium name recognition काफी बढ़ाई और दिखाया कि Intel अपने brand के पीछे खड़ा रहता है, इसलिए net effect positive भी हो सकता था
- Intel ने FDIV bug झेल लिया, लेकिन उस समय की defect ने दिखाया कि complex math, circuit compression और verification limits के मिलने पर बेहद rare error भी बड़ा trust issue बन सकता है
1 टिप्पणियां
Hacker News की रायें
मैं लेखक हूं। Pentium से जुड़े सवाल हों तो जवाब दे सकता हूं :-)
इस bug पर Mastodon thread कुछ हफ्ते पहले HN पर आया था, इसलिए यह परिचित लग सकता है, लेकिन अब मैंने विस्तृत blog post पूरा कर लिया है। पिछले HN post पर भी काफी comments हैं: https://news.ycombinator.com/item?id=42391079
Intel के अंदर भी इससे ज्यादा गंभीर errors थे और दूसरी कंपनियों में भी थे, लेकिन वे पूरी तरह भुला दिए गए। Pentium के floating-point unit value stack—सटीक नाम नहीं पता—की वह rework मुझे जिज्ञासु बनाती है। बहुत पुरानी बात है, लेकिन क्या उन्होंने शुरुआती रूप की register renaming जैसी कोई चीज की थी, जिससे
fxchgको सावधानी से manually manage करना पड़ता था?microcode को bitstream के रूप में “dump” करना कितना मुश्किल होगा? क्या high-resolution die photos से programmatically यह संभव है? बेशक bitstream का मतलब reverse engineer करने की तुलना में यह शायद आसान हिस्सा हो सकता है
“microscope से PLA की सावधानी से जांच की” वाला हिस्सा भी मुझे जिज्ञासु लगा। क्या ऐसा काम घर पर किया जाता है, lab में कौन-से equipment होते हैं, और ऐसी skills कैसे सीखी जाती हैं—यह जानना चाहूंगा
पीछे मुड़कर देखें तो सोचता हूं कि lookup table के unused हिस्सों को शुरुआत से ही 2 और -2 से क्यों नहीं भरा गया
bug खुद भी दिलचस्प है, लेकिन Intel की प्रतिक्रिया अपने आप में रोचक है। लगता है उन्होंने चाहने वाले हर व्यक्ति को defect-free processor से replace नहीं किया, और नतीजे में उन्हें जबरदस्त bad press मिली
तुलना के लिए Amazon Colorsoft launch बहुत याद आता है। कुछ devices में—मेरी device भी शामिल थी—yellow stripe graphics issue था, और Amazon ने एक-दो दिन facts verify करने के बाद इसे स्वीकार किया, फिर चुपचाप सभी को replace कर दिया। recall भी नहीं; request करो तो नया product भेज देते हैं। मेरा replacement शुक्रवार को आ रहा है, उम्मीद है issue solve होगा। launch लड़खड़ाने पर return/support system का बहुत मजबूत होना, analysis से जितना अनुमान लगता है उससे कहीं बड़ा फायदा है—यह साफ दिखता है
इसी तरह कुछ साल पहले Apple AirPods Pro noise issue भी हाल में बहुत ज्यादा highlight नहीं हुआ। मेरे AirPods दो बार replace करने पड़े, लेकिन Apple ने भी चुपचाप replace कर दिए, और support capability भले बाहर से बहुत नजर न आए, पर काफी मजबूती से काम करती है—ऐसा लगा
Colorsoft: https://www.tomsguide.com/tablets/e-readers/amazon-kindle-co...
AirPods Pro: https://support.apple.com/airpods-pro-service-program-sound-...
Apple की तरफ से iPhone 4 Antennagate बेहतर comparison है। वहां बराबर का solution होता—revenue के लिहाज से core flagship product को मुफ्त replace करना—लेकिन Apple ने ऐसा नहीं किया
दूसरी ओर Intel ने आखिरकार request करने वाले किसी भी व्यक्ति को free replacement दिया, और बड़ा financial hit सहा
इस तरह product की जिम्मेदारी लेने वाला Apple का रवैया सच में सम्मान के काबिल था
consumer Apple की “shadow warranty” वाली स्थिति मैंने देखी है, इसलिए बात समझता हूं, लेकिन यह Intel के सामने आई IT crisis से बहुत अलग थी। उस समय “IBM ने ऐसा कहा” का IT में बहुत ज्यादा वजन था
Intel के whitepaper में कहा गया था कि सामान्य यूज़र को यह समस्या 27,000 साल में एक बार मिलेगी, और DRAM bit flip जैसी दूसरी error causes की तुलना में इसे नज़रअंदाज़ किया जा सकता है। वहीं IBM ने अपने analysis में माना कि ग्राहक इसे हर कुछ दिनों में झेल सकते हैं।
मुझे लगता है ये दोनों आंकड़े जितने दूर दिखते हैं, शायद उतने दूर नहीं हैं। Intel ने शायद single user को आधार बनाया था, और IBM ने शायद support inquiry के नज़रिए से सोचा था।
काम पर मैंने ऐसी ही समस्या झेली है। अगर आप दिन में 100 मिलियन requests process करते हैं, तो एक-in-a-billion वाली समस्या भी महीने में कुछ बार हो जाती है। अगर यह ऐसी चीज़ हो जिसे ग्राहक, या उससे भी बुरा, manager नोटिस कर ले, तो लोग denominator को अनदेखा कर देते हैं और सबको अक्षम समझने लगते हैं। महीने में चार बार इंसानी experience bias में “हमेशा” बन सकता है। अगर हफ्ते में तीन बार वाली statistical clustering दो बार हो जाए, तो कोई न कोई फट पड़ेगा।
उन्होंने यह भी माना कि लोग जिन numbers का उपयोग करते हैं, वे Intel के uniform-distribution numbers की तुलना में error पैदा करने की 90 गुना ज्यादा संभावना रखते हैं। इसलिए नतीजा निकला कि एक user को हर 24 दिन में error झेलनी पड़ेगी।
एक जगह लिखा है, “लगता है असल इस्तेमाल में इस bug को नोटिस करने वाला सिर्फ एक व्यक्ति था, Professor Nicely।”
मुझे बहुत पहले का एक study याद आता है जिसमें छात्रों को math class के लिए calculators दिए गए थे। Calculators को गलत results देने के लिए manipulate किया गया था, और researchers जानना चाहते थे कि छात्रों को गड़बड़ी महसूस कराने के लिए calculator को कितना गलत होना पड़ेगा।
जवाब था 2 गुना।
error को notice करना और error से प्रभावित होना पूरी तरह अलग बातें हैं। कंप्यूटर का output सही है या नहीं, यह कितने लोग check करते हैं? मुझे लगता है बहुत, बहुत, बहुत कम। मैंने भी Boeing में engineering calculations करते समय सिर्फ एक मामले को छोड़कर ऐसा नहीं किया, जहां output input से मेल खाता है या नहीं देखने के लिए equation को उल्टा चलाया था।
आखिरकार यह context और calculation करने वाले व्यक्ति की subject understanding पर बहुत निर्भर करता है।
Pentium पर FDIV use का कितना हिस्सा multimedia नहीं बल्कि numerically important output के लिए था?
मुझे वह bug याद है। हम control नहीं कर सकते थे कि customer किस CPU पर run करेगा, इसलिए library में defective FPU detection code डालना पड़ा और workaround code चलाना पड़ा। यह code Intel ने दिया था।
यानी Intel की समस्या मेरी समस्या बन गई, उफ़।
उस समय चलने वाला एक मज़ाक याद आता है। उसमें 90s के कई mood अच्छी तरह कैद थे:
I AM PENTIUM OF BORG.
DIVISION IS FUTILE.
YOU WILL BE APPROXIMATED.
Ken का एक और शानदार लेख। यह खास तौर पर इसलिए याद है क्योंकि मेरे अपने पैसों से खरीदे गए पहले PC में प्रभावित CPU था। उससे पहले PC में मेरी खास दिलचस्पी नहीं थी क्योंकि वे “real” software चला नहीं सकते थे।
लेकिन Windows NT ने यह बदल दिया, और इसके लिए Cutler का शुक्रिया। Taiwan के cheap motherboards की वजह से अपनी machine खुद assemble करना भी practical हो गया, और आज भी बहुत लोग ऐसा करते हैं। Ken ने यह point किया कि users के लिए यह check करना आसान था कि उनका CPU प्रभावित है या नहीं। मुझे याद है Excel में magic numbers वाली division formula type करना ही काफी था। अगर Microsoft ने bug को workaround करने वाला Excel version निकाला होता, तो शायद replacement मांगने वाले users कम होते।
दिलचस्प और सच में बेहद thorough analysis है। silicon का analysis करके results share करने की मेहनत कमाल की है। खासकर Intel की PR ने असली वजह को किसी मामूली omission जैसा सुनाया था, लेकिन लेख ने असली root cause पकड़ लिया, यह अच्छा लगा।
असल में यह कहीं कम माफ़ करने लायक और ज्यादा दोष देने लायक समस्या थी। क्योंकि यह table generation algorithm को खराब कर देने का मामला था।
“Smith ने वह email 1990s version of social media, Compuserve forum, पर पोस्ट किया” यह वाक्य मुझे अजीब महसूस कराता है।
corrected table में out-of-range values के लिए 0 return करने वाला circuit जोड़ने के बजाय बस 2 return करा दिया गया, जिससे यह काफी simple हो गया। तो सोचता हूं कि शुरुआत से ही ऐसा क्यों नहीं किया गया।
जिसने table generate की, उसे शायद नहीं पता था कि out-of-range को 2 से भरने पर simpler PLA बनता है, और जिसने table को PLA में डाला, उसे शायद नहीं पता था कि 0 don't care value है, इसलिए उसने मान लिया कि इसे preserve करना है।
या हो सकता है जिस पल PLA जरूरी size तक छोटा लगने लगा, optimization रोक दी गई। अगर placement planning पहले ही खत्म हो चुकी थी, तो PLA को और छोटा करने से पूरा chip छोटा नहीं होता, और engineering time कहीं और लगाना बेहतर होता।
ज्यादातर software की तरह, एक optimization छूट गई क्योंकि समय पर किसी के दिमाग में नहीं आई। और उस दौर के CPUs patch नहीं किए जा सकते थे।