- 1993’te çıkan Pentium, Intel 486’dan daha hızlı kayan nokta bölmesi için SRT yöntemini benimsedi; ancak 1994’te FDIV komut hatası ortaya çıkınca Intel tüm hatalı çipleri değiştirmeyi kabul etti ve bunun maliyeti 475 milyon dolar oldu
- Hata, bölme için kullanılan lookup table’ı uygulayan PLA’daydı; Intel bir betik hatası nedeniyle 5 girdinin eksik kaldığını açıkladı, ancak die analizi 16 eksik girdiye ve bunlardan 5’inin gerçek hatayı tetiklediğine işaret ediyor
- Radix-4 SRT bölmesi her adımda bölümün 2 bitini ürettiği için hızlıdır; ancak kısmi kalan ve böleni 2048 girdili P-D tablosuna eşleyip bunu 112 satırlık PLA’ya sıkıştıran karmaşık bir yapıya sahiptir
- Temel neden, carry-save adder yüzünden lookup indeksinin gerçek kısmi kalandan bir hücre düşük olabilmesi; Intel’in +2 bölgesinin üst sınırına yanlış matematiksel düzeltme uygulayarak bazı hücreleri 0 olarak bırakmasıdır
- Düzeltilmiş Pentium yalnızca eksik 5 girdiyi doldurmakla kalmadı, kullanılmayan tablo bölgelerinin tamamını 2 ile doldurarak sınırları basitleştirdi; PLA’da kullanılan satır sayısı da 120’den 74’e düştü ve hatalı PLA’dan yaklaşık 1/3 daha küçük hale geldi
FDIV hatasının ortaya çıkışı ve maliyeti
- Intel, 1993’te yüksek performanslı Pentium işlemcisini piyasaya sürdü ve önceki Intel 486’dan daha hızlı bir kayan nokta bölme algoritması ekledi
- Mayıs 1994’te Intel’in iç testlerinde Pentium’un kayan nokta bölmesinin çok nadiren hatalı olduğu keşfedildi
- Intel, 9 milyar değerden yalnızca yaklaşık 1’inin sorun çıkardığını düşündü ve bunu küçük bir problem olarak değerlendirdi
- Buna rağmen Pentium devresi sessizce düzeltildi
- Ekim 1994’te Profesör Thomas Nicely, ikiz asal sayıların tersleri üzerine çalışırken yanlış hesaplama sonuçları fark etti
1/824633702441hesabı üç farklı Pentium bilgisayarda hatalıydı; önceki bilgisayarlar ise doğru sonucu veriyordu- Intel teknik destekten yeterli yanıt alamayınca Nicely, bilgisayar dergilerine ve kişilere e-posta gönderdi
- Bu e-posta Compuserve forumuna kondu ve Electronic Engineering Times 7 Kasım’da Intel fixes a Pentium FPU glitch yazısını yayımladı
- Intel başlangıçta yalnızca doğruluğa ihtiyaç duyduğunu bir mühendisi ikna eden müşterilere değişim sunmak istedi; kullanıcılar comp.sys.intel gibi çevrimiçi gruplarda şikâyetlerini dile getirdi
- 22 Kasım’daki CNN haberinden sonra kamu ilgisi büyüdü; 12 Aralık’ta IBM’in Pentium bilgisayar sevkiyatını durdurduğunu açıklamasıyla durum daha da kötüleşti
- Intel, 19 Aralık’ta tüm müşterilerin hatalı çiplerini değiştireceğini duyurdu
- Geri çağırmanın maliyeti 475 milyon dolar
- Günümüz değeriyle 1 milyar doların üzerinde bir tutar
Pentium’un kullandığı SRT bölmesi
- Tipik ikili uzun bölme, bölümün her biti için bir saat çevrimi gerektirdiğinden yavaştır
- Intel 486 ve önceki işlemciler bu yaklaşımı kullanıyordu
- Pentium, SRT algoritmasını radix-4, yani 2 bitlik birimler halinde kullandı
- Her adımda bölümün 2 bitini üreterek sıradan ikili bölmeden iki kat hızlıdır
- Her bölüm basamağı
-2,-1,0,1,2değerlerinden biridir
- SRT negatif bölüm basamaklarına izin verdiği için, bir adımda biraz büyük bir değer seçilse bile sonraki adımda negatif basamakla düzeltilebilir
- Bölüm basamağının kesin olarak tek bir değere belirlenmesi gerekmediğinden, lookup table ile hızlıca seçilebilir
- Kısmi kalan ve bölenin bazı bitleri kesilerek tablo boyutu pratik seviyeye indirilir
- Bu yöntem hızlıdır; ancak lookup table,
1veya2katlarını ekleyip çıkaran devreler ve sonucu standart bölüm biçimine dönüştüren devreler ayrıca gerekir
2048 girdili tabloyu 112 satırlık PLA’ya sıkıştıran yapı
- Pentium’un SRT lookup table’ı kısmi kalan
pile bölend’yi girdi olarak alır ve uygun bölüm basamağını çıktı olarak verir - Tablo 2048 girdiden oluşur
- Bölen 1 ile 2 arasına ölçeklenir ve X ekseni koordinatı olur
- Kısmi kalan -8 ile 8 arasındaki bir değer olarak Y ekseni koordinatı olur
- Bölen için
1.ddddbiçiminde, baştaki her zaman 1 olan bit dışındaki 4 bit kullanılır - Kısmi kalan, 7 bitlik signed değer
pppp.pppolarak kesilir - Toplam 11 bitlik indeks
2^11 = 2048girdiden birini gösterir
- Tabloda bölüm basamakları
+2,+1,0,-1,-2ye karşılık gelen 5 bölge vardır- Üst ve alt kısımlardaki bazı bölgeler SRT matematiği gereği kullanılmaz
- Özgün hatalı tabloda kullanılmayan girdiler 0 ile doldurulmuştu
- Sorunlu 5 kırmızı girdi
+2olmalıydı, ancak 0 olarak kalmıştı
- Pentium bu tabloyu ROM olarak değil, PLA (Programmable Logic Array) olarak uyguladı
- Tablonun tamamını ROM’da saklamak 2048 satır gerektirirdi
- Tablo yapısı düzenli ve boş bölge çok olduğundan PLA ile yalnızca 112 satır kullanıldı
- PLA, AND plane ve OR plane’den oluşur
- AND plane, giriş bitleri ve tümleyen bitlerin kombinasyonlarıyla mantık terimleri üretir
- OR plane, bu terimleri birleştirerek bölümün
1mi yoksa2mi olduğunu gösteren çıkış bitlerini oluşturur
- PLA transistör desenleri mikroskopla çıkarıldığında her PLA satırının mantık ifadesi yeniden oluşturulabilir
- PLA satırı tablonun tek bir hücresi değil, aynı anda birden çok hücreyi kapsayan dikdörtgen bir bölge gibi çalışır
- Belirli bir tablo sınırı ne kadar girintili çıkıntılıysa o kadar çok PLA satırı gerekir
Matematiksel sınır ve hatalı +2 bölgesi
- SRT bölmesinin temel adımı, kısmi kalan
p’yi bölend’ye bölme oranıp/düzerinden bölüm basamağıq’yu seçmektir p/diçin izin verilen aralık matematiksel nedenlerle[-8/3, 8/3]içinde olmalıdır- Bölüm basamağı seçildikten sonra
q*dçıkarılır ve 4 ile çarpılarak sonraki adımın kısmi kalanı üretilir - Bu sürecin tekrarlanabilir olması için yeni aralığın özgün aralıkla aynı büyüklükte olması gerekir
- Bölüm basamağı seçildikten sonra
- SRT’de yedeklilik vardır; bazı aralıklarda iki bölüm basamağından biri seçilebilir
- Ancak
q=2olması gereken yerde0seçilirse sonraki kısmi kalan izin verilen aralığın dışına çıkar ve algoritma toparlanamaz - FDIV hatası tam olarak bu duruma karşılık gelir
- Ancak
- Pentium’un P-D tablosu, bu matematiksel sınırın hücreler düzeyinde nicemlenmiş halidir
- Çapraz sınır, hangi hücrenin mutlaka
+2, hangisinin+1veya+2olabileceğini, hangisinin mutlaka+1olacağını vb. belirler
- Çapraz sınır, hangi hücrenin mutlaka
- Die analizi, hatalı tablonun üstteki magenta sınır çizgisinin mutlaka siyah matematiksel sınır çizgisinin üzerinde olması gerekirken tekrar tekrar bu çizgiyi kestiğini gösterdi
- Sonuç olarak mutlaka
+2olması gereken bazı hücreler 0 olarak kaldı - FDIV hatasını tetikleyen eksik girdiler bu hücrelerdi
- Sonuç olarak mutlaka
Carry-save adder’ın hatayı nadir ama belirleyici hale getirmesi
- Pentium’un bölme devresi toplama ve çıkarmayı hızlandırmak için carry-save adder kullanır
- Carry-save adder, eldeyi hemen yaymak yerine ayrı bir sözcükte saklar; bu da çok sayıda toplama gerektiren bölme için avantajlıdır
- En sonda saklanan eldeyi birleştirmek için yavaş bir toplama gerekir
- Lookup table indeksi için kısmi kalan gerekir; ancak carry-save adder kısmi kalanı sum bitleri ve carry bitleri olarak ikiye ayırıp saklar
- Pentium, tablo indeksi için gereken yalnızca 7 biti hızlı hesaplamak üzere carry-lookahead adder kullandı
- Bu devre her basamağın carry değerini paralel hesaplar
- Büyük sözcükler için karmaşıklığı yüksek olduğundan uygun değildir, ancak 7 bitlik değerler için pratiktir
- Sorun, kısmi kalanın 64 bit olmasına karşın tablo indeksi hesabının yalnızca 7 bit kullanmasıdır
- Kalan bitler toplama öncesi kesildiğinden, indeks için kullanılan kısmi kalan gerçek değerden biraz düşük olabilir
- Somut olarak doğru hücrenin bir hücre altı, yani
1/8’lik bir ofset oluşabilir
- Bu etki nedeniyle bazı sınır çizgilerinin
1/8aşağı kaydırılması gerekir, ancak tüm sınır çizgileri kaydırılmamalıdır- Üst
+2sınırı aşağı kaydırılmamalıyken Intel bu sınırı yanlış kaydıran bir tablo üretti - Bu carry-save etkisi, o dönemdeki SRT bölmesi makalelerinde de bahsedilen bilinen bir etkidir
- Üst
Intel’in açıklaması ile die analizinin ayrıldığı nokta
- Intel white paper’ı, tabloyu PLA’ya yerleştiren betikte sorun olduğu için birkaç girdinin PLA’dan eksik kaldığını açıkladı
- Intel buna Programmable Lookup Array adını verdi, ancak gerçek yapı Programmable Logic Array’di
- Die analizi, eksik girdilerin basit bir kopyalama hatasından çok matematiksel sınır hatasıyla daha iyi örtüştüğünü düşünüyor
- Tablo üretme programının sınır koşullarını yanlış tanımlamış olması olasıdır
- “Betik” ifadesi, tablonun bir C programıyla üretildiği anlamında teknik olarak doğru olabilir; ancak yorum, sorunun özünün yanlış matematiksel sınır olduğu yönündedir
- Robert Colwell’in The Pentium Chronicles kitabı farklı bir açıklama sunar
- Buna göre Pentium tasarımı başlangıçta 486 ile aynı lookup table’ı kullanıyordu ve lansmana kısa süre kala die alanı tasarrufu baskısıyla optimizasyon yapılırken hata oluştu
- Bu açıklamada uyuşmayan noktalar vardır
- Pentium en başından 486’dan farklı bir bölme algoritması kullanır
- Pentium radix-4 SRT kullanırken 486 standart ikili bölme kullanır
- 486’da böyle bir lookup table yoktur
- Hatalı PLA’da kullanılmayan 8 satır kalmıştı; eğer amaç yalnızca devreyi küçültmek olsaydı önce bu satırlar kaldırılabilirdi
Düzeltilmiş PLA’nın neden daha küçük hale geldiği
- Dönemin haberleri, Intel’in hatayı gidermek için PLA’ya birkaç düzine transistör veya ek gate sequence eklediğini aktardı
- Die üzerinde doğrulanan düzeltilmiş PLA ise bunun tam tersini gösterir
- PLA boyutu aynı kaldı
- Terimlerin yaklaşık 1/3’ü kaldırıldı
- 120 satırın yalnızca 74’ü kullanıldı, kalan 46 satır boştur
- Özgün hatalı PLA’da boş satır sayısı 8’di
- Intel’in düzeltmesi yalnızca eksik 5 girdiyi
2ile doldurmak değildi- Kullanılmayan tablo girdilerinin tamamı 2 ile dolduruldu
- Böylece yanlışlıkla boş bir girdiye erişme olasılığı ortadan kalktı
- Kullanılmayan bölgeler 2 ile doldurulunca tablo sınırları basitleşti
- Girintili çıkıntılı sınırlar çok sayıda PLA terimi gerektirir
- Büyük dikdörtgen bölgeler tek bir PLA terimiyle kapsanabilir
- Bu yüzden daha fazla tablo hücresi doldurulmasına rağmen PLA ifadesi daha basit hale geldi
- Düzeltilmiş PLA’nın mantık terimleri özgün PLA’dan tamamen farklılaştığı için, belirli birkaç transistörün hatayı düzelttiğini söylemek zordur
Gerçek etki ve tartışma
- Rastgele bölmelerde hatanın oluşma olasılığı yaklaşık 9 milyarda 1 gibi çok düşüktür
- Hatalı bölme sonucu da genellikle 9. veya 10. ondalık basamakta farklılaşır
- Nadir en kötü durumda 4. anlamlı basamakta hata oluşur
- Intel white paper’ı, sıradan bir kullanıcının sorunla karşılaşma olasılığını 27.000 yılda bir olarak değerlendirdi
- Çoğu kullanıcı için bunun sorun olmadığını; bilim/mühendislik ve finans mühendisliği alanlarındaki bazı kullanıcıların düzeltilmiş işlemciye veya yazılımsal geçici çözüme ihtiyaç duyabileceğini belirtti
- IBM kendi analizinde müşterilerin birkaç günde bir sorun yaşayabileceğini değerlendirerek Pentium satışını durdurdu
- IBM’in o dönemde rakip PowerPC işlemcisi de vardı
- Analizlere göre gerçek kullanımda hatayı bulan kişinin Profesör Nicely’den ibaret göründüğünü belirten değerlendirmeler de vardır
- IBM analizinin, hatayı tetiklemesi kolay sayılara göre ayarlanmış gibi yönleri olduğu değerlendirildi
- Çoğu kullanıcı hatayla karşılaşmaz; karşılaşsa bile küçük kayan nokta doğruluk kaybı muhtemelen sorun olmaz
- Ancak FDIV hatası deterministik olarak yeniden üretilebiliyordu
- Belirli bir dividend ve divisor sorunu tetiklediğinde sonuç %100 hatalı çıkıyordu
- Müşteriler kendi bilgisayarlarında bunu kolayca yeniden üretebildiği için Intel’in “asla karşılaşmayacağınız bir sorun” demesi zordu
Sonraki işlemci hataları ve yamalanabilir mikrokod
- FDIV hatası en ünlü işlemci hatalarından biridir, ancak Intel’in başka önemli hataları da vardı
- İlk 386 işlemcilerin bazılarında 32 bit çarpma sorunu vardı
- Belirli sıcaklık, voltaj ve frekans koşullarında öngörülemez şekilde yanlış sonuç üretiyordu
- Nedeni, elektriksel payı yetersiz bir layout sorunuydu
- Intel hatalı çipleri 16 bit pazarla sınırlı şekilde sattı ve üzerlerine “16 BIT S/W ONLY” işareti koydu
- Pentium’un bir başka sorunu 1997’de keşfedilen F00F bug idi
F0 0File başlayan belirli bir komut dizisi, işlemciyi yeniden başlatmaya kadar kilitliyordu- İşletim sistemi güncellemesiyle çözüldü
- Pentium’da mikrokod ROM’a sabit kodlandığı için FDIV hatası mikrokod güncellemesiyle düzeltilemiyordu
- Intel, 1995’te Pentium Pro’ya yamalanabilir mikrokod ekledi
- Başlangıçta çip hata ayıklama ve test amacı taşıyordu
- FDIV hatasından sonra hata düzeltmede de değerli olduğu ortaya çıktı
- Pentium Pro, ROM mikrokodun yanında en fazla 60 mikrokomut barındıran SRAM’e sahipti ve BIOS açılış sırasında yamayı yükleyebiliyordu
- Modern Intel işlemcilerde mikrokod yamaları Spectre açıklarından voltaj sorunlarına kadar çeşitli problemlerde kullanılıyor
Karmaşıklaşan devrelerin yol açtığı hata
- Moore Yasası doğrultusunda işlemcilerdeki transistör sayısı arttıkça devreler ve algoritmalar da karmaşıklaştı
- Bölme desteğindeki değişim bunu iyi gösterir
- Intel 8080, 1974’te 6000 transistör kullanıyordu ve donanımsal bölmeyi veya kayan nokta aritmetiğini desteklemiyordu
- Intel 8086, 1978’de 29.000 transistör kullanıyordu; tamsayı bölmesi mikrokodla uygulanmıştı, ancak kayan nokta için 8087 yardımcı işlemcisi gerekiyordu
- Intel 486, 1989’da 1,2 milyon transistörle kayan nokta desteğini çipe entegre etti
- Pentium, 1993’te 3,1 milyon transistörle daha hızlı ama karmaşık SRT bölme algoritmasını benimsedi
- Yalnızca Pentium’un bölme PLA’sı yaklaşık 4900 transistör sitesi içerir
- Bu, MOS Technology 6502 işlemcisinin tamamından fazladır
- Başka bir deyişle Pentium bölme devresinin tek bir bileşeni, 1975 tarihli bütün bir işlemciden daha fazla transistör kullanıyordu
- FDIV hatasının uzun vadeli etkisi tartışmalıdır
- AMD gibi rakipler Pentium sorunuyla alay eden reklamlardan fayda sağladı
- Robert Colwell, FDIV hatasının Pentium adının bilinirliğini büyük ölçüde artırdığını ve Intel’in markasının arkasında durduğunu gösterdiğini, bu yüzden net etkinin olumlu bile olmuş olabileceğini düşünüyor
- Intel FDIV hatasını atlattı; ancak o dönemdeki kusur, karmaşık matematik, devre sıkıştırma ve doğrulama sınırları birleştiğinde son derece nadir hataların bile büyük güven sorunlarına dönüşebileceğini gösterdi
1 yorum
Hacker News yorumları
Yazarı benim. Pentium ile ilgili sorular varsa yanıtlayabilirim :-)
Bu hatayla ilgili Mastodon dizisi birkaç hafta önce HN'de paylaşılmıştı, o yüzden tanıdık gelebilir; ama artık ayrıntılı blog yazısını tamamladım. Önceki HN gönderisinde de epey yorum var: https://news.ycombinator.com/item?id=42391079
Intel içinde daha kötü hatalar da vardı, başka şirketlerde de oldu; ama onlar tamamen unutuldu. Pentium'un kayan nokta biriminin değer yığını, tam adını bilmiyorum ama onun yeniden işlenişi ilgimi çekiyor. Çok eski bir konu ama erken bir register renaming biçimi gibi bir şey yapıp
fxchg'yi dikkatle elle yönetmek zorunda kalmıyor muydunuz?Mikrokodu bir bit akışı olarak “dump” etmek ne kadar zor olurdu? Yüksek çözünürlüklü kalıp fotoğraflarından bunu programatik olarak yapmak mümkün mü? Tabii bit akışının ne anlama geldiğini tersine mühendislikle çözmeye kıyasla bu daha kolay kısım olabilir
“PLA'yı mikroskopla dikkatlice inceledim” kısmı da ilgimi çekti. Bunu evde mi yapıyorsunuz, laboratuvarda ne tür ekipman var, bu tür becerileri nasıl öğrendiniz bilmek isterim
Geriye dönüp bakınca, arama tablosunun kullanılmayan bölümlerini en baştan 2 ve -2 ile neden doldurmadıkları merak uyandırıyor
Hatanın kendisi ilginç ama Intel'in tepkisi de başlı başına dikkat çekici. İsteyen herkese hatasız işlemciyle değişim yapmamış gibi görünüyor ve bunun sonucunda çok büyük kötü tanıtım aldı
Karşılaştırma olarak bana en çok Amazon Colorsoft'un çıkışı hatırlatıyor. Bazı cihazlarda, benimki de dahil, sarı bantlı grafik sorunu vardı; Amazon bir iki gün içinde durumu doğrulayıp kabul etti ve sonra sessizce hepsini değiştirdi. Resmî bir geri çağırma bile değildi; isterseniz yenisini yolluyorlardı. Benim değişim cihazım cuma geliyor, umarım düzelmiştir. Bir lansman kötü gittiğinde iade/destek sisteminin çok sağlam olmasının, analizlerde tahmin edilenden çok daha büyük bir avantaj olduğu açıkça görülüyor
Benzer şekilde, birkaç yıl önce Apple AirPods Pro'daki gürültü sorunu da son dönemde pek büyük haber olmadı. Benim AirPods'larımın iki kez değişmesi gerekti ama Apple onları da sessizce değiştirdi; destek kapasitesinin dışarıdan çok görünmese de oldukça güçlü çalıştığı hissini veriyordu
Colorsoft: https://www.tomsguide.com/tablets/e-readers/amazon-kindle-co...
AirPods Pro: https://support.apple.com/airpods-pro-service-program-sound-...
Apple tarafında daha iyi bir karşılaştırma iPhone 4 antennagate olurdu. Oradaki denk çözüm, gelir açısından kritik olan amiral gemisi ürünü ücretsiz değiştirmek olurdu; ama Apple bunu yapmadı
Buna karşılık Intel sonunda talep eden herkese ücretsiz değişim sundu ve büyük bir finansal darbe almayı göze aldı
Apple'ın ürüne bu şekilde sahip çıkma tavrı gerçekten saygıyı hak ediyordu
Tüketici Apple'ın “gölge garantisi” durumunu yaşamış biri olarak ne demek istediğinizi anlıyorum; ama bunun Intel'in karşı karşıya kaldığı BT krizinden çok farklı olduğunu düşünüyorum. O dönemde IT dünyasında “IBM böyle dedi” cümlesi inanılmaz ağırlık taşıyordu
Intel'in teknik notunda sıradan bir kullanıcının bu sorunla 27.000 yılda bir karşılaşacağı ve DRAM bit flip gibi diğer hata nedenleriyle kıyaslandığında bunun ihmal edilebilir olduğu söyleniyordu. Buna karşılık IBM kendi analizinde müşterilerin bununla birkaç günde bir karşılaşabileceğini düşünüyordu.
Bu iki sayı göründüğü kadar uzak olmayabilir. Intel muhtemelen tek bir kullanıcıyı temel aldı; IBM ise muhtemelen destek başvuruları açısından düşünüyordu.
İşte benzer bir sorunu yaşadım. Günde 100 milyon isteği işliyorsanız, milyarda bir görülen bir sorun bile ayda birkaç kez patlar. Müşterinin ya da daha kötüsü yöneticinin fark edeceği türdense, insanlar paydayı görmezden gelir ve herkesin beceriksiz olduğundan şüphelenir. Ayda dört kez, insan deneyimindeki önyargı içinde “hep” diye çevrilebilir. Haftada üç kezlik istatistiksel bir kümelenme iki kez yaşanırsa birileri patlar.
Ayrıca insanların kullandığı sayıların, Intel'in eşit dağılım varsayımındaki sayılara göre hata üretme olasılığının 90 kat daha yüksek olduğunu düşünüyordu. Sonuç olarak tek bir kullanıcının 24 günde bir hatayla karşılaşacağı sonucuna vardı.
“Bu bug'ı gerçek kullanım sırasında fark eden tek kişi Profesör Nicely gibi görünüyor” deniyor.
Bu, yıllar önce öğrencilere matematik dersi için hesap makineleri dağıtılan bir araştırmayı hatırlatıyor. Hesap makineleri yanlış sonuç verecek şekilde ayarlanmıştı ve araştırmacılar öğrencilerin bir tuhaflık fark etmesi için hesap makinesinin ne kadar yanlış olması gerektiğini öğrenmek istiyordu.
Cevap 2 kat idi.
Bir hatayı fark etmekle ondan etkilenmek tamamen farklı şeylerdir. Bilgisayar çıktısının doğru olup olmadığını gerçekten kaç kişi kontrol eder? Bence çok, çok, çok az. Ben de Boeing'de mühendislik hesapları yaparken, çıktının girdilerle tutarlı olduğunu kontrol etmek için denklemi tersten çözdüğüm bir durum dışında bunu yapmadım.
Sonuçta bu büyük ölçüde bağlama ve hesabı yapan kişinin konuyu ne kadar anladığına bağlı.
Pentium'da FDIV kullanımının ne kadarı multimedya yerine sayısal olarak kritik çıktı içindi?
O bug'ı hatırlıyorum. Müşterinin hangi CPU'da çalıştıracağını kontrol edemediğimiz için, kütüphaneye kusurlu FPU algılama kodu ekleyip bir geçici çözüm çalıştırmak zorunda kalmıştık. Bu kod Intel tarafından sağlanmıştı.
Yani Intel'in sorunu benim sorunum oldu, üf.
O dönemde dolaşan bir şakayı hatırladım. 90'ların havasını iyi yakalıyordu:
I AM PENTIUM OF BORG.
DIVISION IS FUTILE.
YOU WILL BE APPROXIMATED.
Ken'den yine harika bir yazı. Özellikle aklımda kalmasının nedeni, kendi paramla aldığım ilk PC'de etkilenen CPU'nun bulunmasıydı. Ondan önce PC'lere pek ilgi duymuyordum, çünkü “gerçek” yazılımları çalıştıramıyorlardı.
Ama Windows NT bunu değiştirdi; Cutler'a teşekkürler. Tayvan yapımı ucuz anakartlar sayesinde kendi makinenizi toplamak da gerçekçi hale geldi ve bugün hâlâ birçok kişi bunu yapıyor. Ken, kullanıcının kendi CPU'sunun etkilenip etkilenmediğini kontrol etmesinin kolay olduğuna dikkat çekmiş. Excel'e sihirli sayılar içeren bir bölme formülü yazmak kadar kolay olduğunu hatırlıyorum. Microsoft, bug'ı dolaşan bir Excel sürümü çıkarsaydı, değişim talep eden kullanıcı sayısı daha az olurdu gibi geliyor.
İlgi çekici ve gerçekten inatçı bir analiz. Silikonu inceleyip sonuçları paylaşmak için harcanan emek etkileyici. Özellikle Intel'in PR tarafı gerçek nedeni önemsiz bir eksiklik gibi göstermeye çalışırken, yazının asıl kök nedeni işaret etmesi çok iyi olmuş.
Aslında mesele çok daha az bağışlanabilir ve çok daha fazla eleştiriyi hak eden bir şeydi. Çünkü bozulan şey tablo üretim algoritmasıydı.
“Smith bu e-postayı 1990'ların sosyal medya versiyonu olan Compuserve forumlarına gönderdi” cümlesi beni tuhaf hissettirdi.
Düzeltilmiş tablo, aralık dışı değerler için 0 döndüren bir devre eklemek yerine doğrudan 2 dönecek şekilde yapıldığı için çok daha basit hale gelmiş. O zaman neden baştan böyle yapılmadığını merak ediyorum.
Tabloyu üreten kişi, aralık dışı yerleri 2 ile doldurmanın daha basit bir PLA oluşturacağını bilmiyor olabilir; tabloyu PLA'ya aktaran kişi de 0'ın bir önemsiz değer (don't care) olduğunu bilmiyor ve korunması gerektiğini varsayıyor olabilir.
Ya da gerekli olduğunu düşündükleri kadar küçülen PLA'yı görünce optimizasyonu bırakmış olabilirler. Yerleşim planı zaten tamamlandıysa, PLA'yı daha da küçültmek tüm çipi küçültmeyecekti; mühendislik zamanını başka yerde harcamak daha mantıklı olurdu.
Çoğu yazılımda olduğu gibi, zamanında kimsenin düşünmediği için geride kalmış bir optimizasyon vardı. Ve o dönemin CPU'ları yamalanamıyordu.