- Pentium ra mắt năm 1993 đã áp dụng phương pháp SRT để tăng tốc phép chia số thực dấu chấm động so với Intel 486, nhưng khi lỗi lệnh FDIV bị công khai năm 1994, Intel đã đồng ý thay toàn bộ chip lỗi với chi phí 475 triệu USD
- Lỗi nằm trong PLA triển khai bảng tra cứu cho phép chia; Intel nói rằng 5 mục bị thiếu do lỗi script, nhưng phân tích die cho thấy thiếu 16 mục và trong đó có 5 mục thực sự gây ra lỗi
- Phép chia SRT radix-4 tạo ra 2 bit thương ở mỗi bước nên nhanh hơn, nhưng có cấu trúc phức tạp: ánh xạ phần dư tạm thời và số chia vào bảng P-D 2048 mục rồi nén lại thành PLA 112 hàng
- Nguyên nhân cốt lõi là do carry-save adder có thể khiến chỉ số tra cứu thấp hơn một ô so với phần dư thực tế, trong khi Intel áp dụng sai hiệu chỉnh toán học ở biên trên của vùng
+2, khiến một số ô bị để lại thành 0 - Pentium đã sửa không chỉ điền lại 5 mục bị thiếu mà còn điền toàn bộ vùng bảng không dùng thành 2 để đơn giản hóa ranh giới; số hàng PLA được dùng cũng giảm từ 120 xuống 74, nhỏ hơn khoảng 1/3 so với PLA lỗi
Con đường công khai lỗi FDIV và cái giá phải trả
- Intel phát hành bộ xử lý Pentium hiệu năng cao vào năm 1993 và đưa vào thuật toán chia số thực dấu chấm động nhanh hơn Intel 486 trước đó
- Tháng 5/1994, trong quá trình thử nghiệm nội bộ, Intel phát hiện phép chia số thực dấu chấm động trên Pentium trong những trường hợp cực hiếm có thể cho kết quả không chính xác
- Intel cho rằng chỉ khoảng 1 trên 9 tỷ giá trị gây ra vấn đề nên đánh giá đây là lỗi nhỏ
- Dù vậy, mạch Pentium vẫn được sửa một cách âm thầm
- Tháng 10/1994, giáo sư Thomas Nicely phát hiện kết quả tính toán sai khi nghiên cứu nghịch đảo của các cặp số nguyên tố sinh đôi
- Phép tính
1/824633702441cho kết quả sai trên 3 máy Pentium khác nhau, trong khi các máy đời trước cho đáp án đúng - Không nhận được phản hồi thỏa đáng từ bộ phận hỗ trợ kỹ thuật của Intel, Nicely đã gửi email cho các tạp chí máy tính và nhiều cá nhân
- Email này được đăng lên diễn đàn Compuserve, và Electronic Engineering Times đã đăng bài Intel fixes a Pentium FPU glitch vào ngày 7/11
- Phép tính
- Ban đầu Intel chỉ định thay chip cho những khách hàng có thể thuyết phục kỹ sư rằng họ thực sự cần độ chính xác cao, và người dùng đã phàn nàn trên các nhóm trực tuyến như comp.sys.intel
- Sau bản tin của CNN ngày 22/11, sự chú ý từ công chúng tăng mạnh, và tình hình xấu thêm khi IBM thông báo ngừng xuất xưởng máy tính Pentium vào ngày 12/12
- Ngày 19/12, Intel tuyên bố sẽ thay chip lỗi cho mọi khách hàng
- Chi phí thu hồi là 475 triệu USD
- Tính theo giá trị hiện nay, con số này vượt quá 1 tỷ USD
Phép chia SRT mà Pentium sử dụng
- Phép chia dài nhị phân thông thường cần một xung nhịp cho mỗi bit của thương nên khá chậm
- Intel 486 và các bộ xử lý trước đó dùng cách tiếp cận này
- Pentium sử dụng thuật toán SRT theo radix-4, tức xử lý theo đơn vị 2 bit
- Mỗi bước tạo ra 2 bit thương nên nhanh gấp đôi phép chia nhị phân thông thường
- Mỗi chữ số thương có thể là một trong các giá trị
-2,-1,0,1,2
- SRT cho phép chữ số thương âm, vì vậy dù ở một bước chọn giá trị hơi lớn thì vẫn có thể hiệu chỉnh bằng chữ số âm ở bước sau
- Không cần xác định chính xác duy nhất một chữ số thương, nên có thể chọn nhanh bằng bảng tra cứu
- Chỉ lấy một số bit của phần dư tạm thời và số chia để giữ kích thước bảng ở mức thực dụng
- Cách này nhanh nhưng cần thêm bảng tra cứu, mạch cộng hoặc trừ bội số
1hay2, và mạch chuyển đổi về dạng thương chuẩn
Cấu trúc nén 2048 mục bảng thành PLA 112 hàng
- Bảng tra cứu SRT của Pentium nhận phần dư tạm thời
pvà số chiadlàm đầu vào rồi xuất ra chữ số thương thích hợp - Bảng gồm 2048 mục
- Số chia được scale vào khoảng từ 1 đến 2 và dùng làm tọa độ trục X
- Phần dư tạm thời nằm trong khoảng từ -8 đến 8 và dùng làm tọa độ trục Y
- Với số chia, dùng 4 bit sau
1.dddd, bỏ bit1đầu vì luôn cố định - Phần dư tạm thời được cắt thành giá trị signed 7 bit
pppp.ppp - Tổng cộng thành chỉ số 11 bit, trỏ tới
2^11 = 2048mục
- Bảng có 5 vùng tương ứng với các chữ số thương
+2,+1,0,-1,-2- Một số vùng trên và dưới không được dùng theo toán học của SRT
- Trong bảng lỗi ban đầu, các mục không dùng được điền bằng 0
- 5 mục màu đỏ gây sự cố lẽ ra phải là
+2nhưng lại bị để thành 0
- Pentium không triển khai bảng này bằng ROM mà bằng PLA(Programmable Logic Array)
- Nếu lưu cả bảng dưới dạng ROM sẽ cần 2048 hàng
- Vì cấu trúc bảng có quy luật và nhiều vùng trống, PLA chỉ cần 112 hàng
- PLA gồm AND plane và OR plane
- AND plane tạo các hạng logic từ tổ hợp bit đầu vào và bit bù
- OR plane cộng các hạng đó lại để tạo các bit đầu ra cho biết thương là
1hay2
- Khi trích xuất mẫu transistor của PLA dưới kính hiển vi, có thể khôi phục biểu thức logic của từng hàng PLA
- Một hàng PLA không phủ một ô đơn lẻ trong bảng mà hoạt động như một vùng hình chữ nhật phủ nhiều ô cùng lúc
- Biên của bảng càng lởm chởm thì càng cần nhiều hàng PLA
Biên toán học và vùng +2 bị sai
- Bước cốt lõi của phép chia SRT là chọn chữ số thương
qdựa trên tỷ lệp/dgiữa phần dư tạm thờipvà số chiad - Vì lý do toán học, miền cho phép của
p/dphải nằm trong[-8/3, 8/3]- Sau khi chọn chữ số thương, hệ thống trừ
q*drồi nhân 4 để tạo phần dư tạm thời cho bước tiếp theo - Để lặp được quá trình này, miền mới phải có kích thước bằng miền ban đầu
- Sau khi chọn chữ số thương, hệ thống trừ
- SRT có tính dư thừa nên trong một số khoảng có thể chọn một trong hai chữ số thương
- Nhưng nếu tại nơi bắt buộc phải chọn
q=2mà lại chọn0, phần dư tạm thời kế tiếp sẽ đi ra ngoài miền cho phép và thuật toán không thể phục hồi - Lỗi FDIV rơi đúng vào trường hợp này
- Nhưng nếu tại nơi bắt buộc phải chọn
- Bảng P-D của Pentium là phiên bản lượng tử hóa theo từng ô của các biên toán học đó
- Biên chéo quyết định ô nào bắt buộc phải là
+2, ô nào có thể là+1hoặc+2, ô nào bắt buộc là+1, v.v.
- Biên chéo quyết định ô nào bắt buộc phải là
- Kết quả phân tích die cho thấy đường biên magenta phía trên trong bảng lỗi lẽ ra phải luôn nằm trên đường biên toán học màu đen, nhưng lại nhiều lần cắt qua đường đó
- Kết quả là một số ô lẽ ra chắc chắn phải là
+2lại bị để thành 0 - Chính các ô này là các mục bị thiếu gây ra lỗi FDIV
- Kết quả là một số ô lẽ ra chắc chắn phải là
Cách carry-save adder khiến lỗi hiếm nhưng chí mạng
- Mạch chia của Pentium dùng carry-save adder để tăng tốc cộng và trừ
- Carry-save adder không truyền carry ngay lập tức mà lưu nó trong một từ riêng, phù hợp với phép chia cần nhiều lần cộng
- Ở bước cuối cùng vẫn cần một phép cộng chậm để gộp carry đã lưu
- Chỉ số của bảng tra cứu cần phần dư tạm thời, nhưng carry-save adder lưu phần dư này dưới dạng các bit sum và carry riêng biệt
- Pentium dùng carry-lookahead adder để tính nhanh 7 bit cần cho chỉ số bảng
- Mạch này tính carry của từng vị trí theo kiểu song song
- Với từ lớn thì quá phức tạp, nhưng với giá trị 7 bit thì khả thi
- Vấn đề là phần dư tạm thời có 64 bit, trong khi tính chỉ số bảng chỉ dùng 7 bit
- Các bit còn lại bị cắt bỏ trước khi cộng xong nên phần dư dùng làm chỉ số có thể thấp hơn một chút so với giá trị thực
- Cụ thể, nó có thể lệch xuống một ô so với ô đúng, tức offset
1/8
- Vì hiệu ứng này, một số đường biên phải được dịch xuống
1/8, nhưng không phải mọi đường biên đều được dịch- Biên trên của vùng
+2không được phép dịch xuống, nhưng Intel đã tạo ra bảng với đường biên bị dịch sai - Hiệu ứng carry-save này đã được nêu trong các bài báo về phép chia SRT từ thời điểm đó
- Biên trên của vùng
Điểm Intel giải thích khác với phân tích die
- Whitepaper của Intel nói rằng có vấn đề trong script đưa bảng vào PLA, khiến một vài mục bị bỏ sót khỏi PLA
- Intel gọi nó là Programmable Lookup Array, nhưng cấu trúc thực tế là Programmable Logic Array
- Phân tích die cho rằng các mục bị thiếu phù hợp với lỗi biên toán học hơn là lỗi sao chép đơn thuần
- Có thể chương trình sinh bảng đã định nghĩa sai điều kiện biên
- Cách gọi là “script” có thể vẫn đúng về mặt kỹ thuật nếu đó là chương trình C tạo bảng, nhưng bản chất vấn đề được hiểu là biên toán học bị sai
- The Pentium Chronicles của Robert Colwell đưa ra một cách giải thích khác
- Theo đó, thiết kế Pentium ban đầu dùng bảng tra cứu giống 486, rồi trong giai đoạn sát ngày phát hành, do áp lực tiết kiệm diện tích die mà tối ưu hóa dẫn đến lỗi
- Cách giải thích này có những điểm không khớp
- Pentium ngay từ đầu đã dùng thuật toán chia khác với 486
- Pentium dùng SRT radix-4, còn 486 dùng phép chia nhị phân chuẩn
- 486 không có bảng tra cứu kiểu đó
- PLA lỗi vẫn còn 8 hàng không dùng, nên nếu chỉ đơn giản muốn thu nhỏ mạch thì có thể bỏ các hàng này trước
Vì sao PLA đã sửa lại còn nhỏ hơn
- Các bản tin thời đó nói rằng Intel đã thêm vài chục transistor hoặc thêm gate sequence để sửa lỗi
- PLA đã sửa được xác nhận trên die lại cho thấy điều ngược lại
- Kích thước PLA giữ nguyên
- Khoảng 1/3 số hạng đã bị loại bỏ
- Chỉ dùng 74 trong 120 hàng, còn 46 hàng để trống
- PLA lỗi ban đầu chỉ có 8 hàng trống
- Bản sửa của Intel không chỉ đơn giản điền 5 mục bị thiếu bằng
2- Toàn bộ các mục bảng trước đây không dùng đều được điền bằng 2
- Nhờ vậy không còn khả năng vô tình truy cập vào mục trống
- Khi điền vùng không dùng bằng 2, biên của bảng trở nên đơn giản hơn
- Biên lởm chởm cần nhiều hạng PLA
- Vùng hình chữ nhật lớn có thể được bao phủ chỉ bằng một hạng PLA
- Vì thế dù nhiều ô hơn được điền giá trị, biểu thức PLA lại đơn giản hơn
- Các hạng logic của PLA sửa đổi hoàn toàn khác PLA gốc, nên rất khó chỉ ra rằng chỉ một vài transistor cụ thể đã sửa được lỗi
Ảnh hưởng thực tế và tranh cãi
- Xác suất lỗi xuất hiện trong các phép chia ngẫu nhiên là khoảng 1 trên 9 tỷ, cực kỳ thấp
- Kết quả chia sai thường chỉ lệch ở chữ số thập phân thứ 9 hoặc thứ 10
- Trong trường hợp xấu hiếm gặp nhất, lỗi có thể xuất hiện từ chữ số có nghĩa thứ 4
- Whitepaper của Intel cho rằng người dùng thông thường chỉ gặp vấn đề khoảng một lần trong 27.000 năm
- Intel nói rằng đây không phải vấn đề với đa số người dùng, nhưng một số người trong khoa học, kỹ thuật và tài chính định lượng có thể cần bộ xử lý đã sửa hoặc cách обход bằng phần mềm
- IBM trong phân tích riêng cho rằng khách hàng có thể gặp vấn đề vài ngày một lần, và đã ngừng bán Pentium
- Khi đó IBM cũng có bộ xử lý cạnh tranh là PowerPC
- Theo một số đánh giá, trong thực tế chỉ có giáo sư Nicely là người thật sự phát hiện lỗi trong lúc sử dụng
- Phân tích của IBM bị cho là đã chọn các con số dễ kích hoạt lỗi
- Phần lớn người dùng có thể sẽ không bao giờ gặp lỗi, và ngay cả khi gặp thì độ sai lệch nhỏ của số thực dấu chấm động cũng có thể không thành vấn đề
- Tuy vậy, lỗi FDIV có tính tái hiện tất định
- Nếu một cặp dividend và divisor cụ thể gây lỗi thì kết quả sẽ sai 100% mỗi lần
- Vì khách hàng có thể dễ dàng tái hiện lỗi trên máy của mình, Intel khó có thể khẳng định đây là vấn đề “không bao giờ gặp phải”
Các lỗi bộ xử lý về sau và microcode có thể vá
- FDIV là một trong những lỗi bộ xử lý nổi tiếng nhất, nhưng Intel còn gặp nhiều lỗi quan trọng khác
- Một số bộ xử lý 386 đời đầu có lỗi nhân 32 bit
- Trong những điều kiện nhiệt độ, điện áp và tần số nhất định, chúng cho kết quả sai một cách khó đoán
- Nguyên nhân là bố trí layout thiếu biên độ điện học an toàn
- Intel giới hạn việc bán các chip lỗi này vào thị trường 16 bit và gắn nhãn “16 BIT S/W ONLY”
- Một vấn đề khác của Pentium là F00F bug được phát hiện năm 1997
- Một chuỗi lệnh cụ thể bắt đầu bằng
F0 0Fcó thể làm bộ xử lý treo cho tới khi khởi động lại - Vấn đề được khắc phục bằng bản cập nhật hệ điều hành
- Một chuỗi lệnh cụ thể bắt đầu bằng
- Pentium có microcode được hard-code trong ROM nên không thể sửa lỗi FDIV bằng cập nhật microcode
- Năm 1995, Intel thêm microcode có thể vá vào Pentium Pro
- Ban đầu mục đích là để debug và thử nghiệm chip
- Sau lỗi FDIV, giá trị của nó cho việc sửa lỗi cũng trở nên rõ ràng
- Pentium Pro có ROM microcode cùng với SRAM chứa tối đa 60 vi lệnh, và BIOS có thể nạp bản vá trong lúc khởi động
- Các bản vá microcode trên bộ xử lý Intel hiện đại được dùng cho nhiều loại vấn đề, từ lỗ hổng Spectre tới sự cố điện áp
Sai sót do mạch ngày càng phức tạp
- Theo định luật Moore, số lượng transistor trong bộ xử lý tăng lên kéo theo mạch và thuật toán cũng ngày càng phức tạp
- Những thay đổi trong hỗ trợ phép chia cho thấy điều đó rất rõ
- Intel 8080 năm 1974 dùng 6000 transistor và không hỗ trợ phép chia phần cứng hay số học dấu chấm động
- Intel 8086 năm 1978 dùng 29.000 transistor, triển khai phép chia số nguyên bằng microcode nhưng cần đồng xử lý 8087 cho số thực dấu chấm động
- Intel 486 năm 1989 với 1,2 triệu transistor đã tích hợp hỗ trợ số thực dấu chấm động lên chip
- Pentium năm 1993 với 3,1 triệu transistor nhanh hơn nhưng dùng thuật toán chia SRT phức tạp hơn
- Riêng PLA cho phép chia của Pentium đã có khoảng 4900 vị trí transistor
- Nhiều hơn toàn bộ bộ xử lý MOS Technology 6502
- Tức chỉ một thành phần của mạch chia Pentium đã dùng nhiều transistor hơn cả một bộ xử lý hoàn chỉnh năm 1975
- Tác động dài hạn của lỗi FDIV vẫn còn gây tranh cãi
- Các đối thủ như AMD hưởng lợi nhờ quảng cáo chế giễu sự cố Pentium
- Robert Colwell cho rằng lỗi FDIV có thể lại giúp tên tuổi Pentium được nhận biết rộng rãi hơn và cho thấy Intel sẵn sàng đứng ra bảo vệ thương hiệu, nên hiệu ứng ròng có thể là tích cực
- Intel đã vượt qua lỗi FDIV, nhưng sự cố này cho thấy khi toán học phức tạp, nén mạch và giới hạn xác minh kết hợp với nhau, ngay cả lỗi cực hiếm cũng có thể phình thành khủng hoảng niềm tin lớn
1 bình luận
Ý kiến trên Hacker News
Tôi là tác giả. Nếu có câu hỏi nào liên quan đến Pentium thì tôi có thể trả lời :-)
Một thread Mastodon về lỗi này đã được đăng lên HN vài tuần trước nên có thể bạn thấy quen, nhưng giờ tôi đã hoàn tất bài blog chi tiết. Bài HN trước đó cũng có khá nhiều bình luận: https://news.ycombinator.com/item?id=42391079
Ngay trong Intel cũng từng có những lỗi nghiêm trọng hơn, và các công ty khác cũng vậy, nhưng chúng đã bị quên hoàn toàn. Tôi tò mò về việc làm lại value stack của đơn vị dấu phẩy động trong Pentium, không chắc tên chính xác là gì. Chuyện đã lâu rồi, nhưng có phải họ đã làm thứ gì đó giống dạng sơ khai của đổi tên thanh ghi (register renaming), khiến
fxchgphải được quản lý thủ công một cách cẩn thận không?Việc “dump” microcode thành bitstream khó đến mức nào? Liệu có thể làm bằng chương trình từ ảnh die độ phân giải cao không? Dĩ nhiên việc đó có thể vẫn dễ hơn so với đảo ngược để hiểu bitstream đó có nghĩa là gì
Tôi cũng tò mò về đoạn “đã cẩn thận khảo sát PLA bằng kính hiển vi”. Những việc như vậy được làm ở nhà hay trong phòng thí nghiệm, có những thiết bị gì, và anh đã học các kỹ thuật này như thế nào?
Nhìn lại thì tôi thắc mắc vì sao ngay từ đầu họ không điền các phần không dùng đến của bảng tra cứu bằng 2 và -2
Bản thân lỗi đã thú vị, nhưng cách Intel phản ứng cũng thú vị không kém. Có vẻ họ đã không thay bằng bộ xử lý không lỗi cho mọi người muốn đổi, và kết quả là hứng chịu rất nhiều tiếng xấu
Để so sánh, tôi liên tưởng nhiều đến đợt ra mắt Amazon Colorsoft. Một số thiết bị, gồm cả thiết bị của tôi, có vấn đề đồ họa dạng dải màu vàng; Amazon mất khoảng một hoặc hai ngày để xác minh sự việc rồi thừa nhận, sau đó lặng lẽ thay toàn bộ. Không phải thu hồi, chỉ cần yêu cầu là họ gửi sản phẩm mới. Máy thay thế của tôi sẽ đến vào thứ Sáu, hy vọng vấn đề được giải quyết. Rõ ràng khi một đợt ra mắt bị trục trặc, hệ thống trả hàng/hỗ trợ cực kỳ vững chắc là lợi thế lớn hơn nhiều so với những gì phân tích dự đoán
Tương tự, vấn đề tiếng ồn của Apple AirPods Pro vài năm trước gần đây cũng không còn được đưa tin rầm rộ. AirPods của tôi phải thay hai lần, nhưng Apple cũng lặng lẽ đổi cho, và tôi có cảm giác năng lực hỗ trợ tuy không lộ rõ bên ngoài nhưng vận hành khá mạnh mẽ
Colorsoft: https://www.tomsguide.com/tablets/e-readers/amazon-kindle-co...
AirPods Pro: https://support.apple.com/airpods-pro-service-program-sound-...
Về phía Apple, iPhone 4 Antennagate sẽ là đối tượng so sánh tốt hơn. Giải pháp tương đương khi đó lẽ ra là thay miễn phí sản phẩm flagship cốt lõi về doanh thu, nhưng Apple đã không làm vậy
Ngược lại, cuối cùng Intel đã cung cấp đổi miễn phí cho bất kỳ ai yêu cầu, chấp nhận một cú đánh tài chính lớn
Cách Apple chịu trách nhiệm với sản phẩm như vậy thật sự đáng tôn trọng
Tôi hiểu ý bạn vì từng trải qua kiểu “bảo hành ngầm” của Apple dành cho người tiêu dùng, nhưng tôi nghĩ nó rất khác với khủng hoảng IT mà Intel đối mặt. Khi đó, câu “IBM đã nói vậy” có sức nặng khổng lồ trong giới IT
Trong sách trắng của Intel, họ nói rằng người dùng thông thường sẽ gặp vấn đề này mỗi 27.000 năm một lần, và so với các nguyên nhân lỗi khác như lật bit DRAM thì có thể bỏ qua. Ngược lại, IBM trong phân tích riêng cho rằng khách hàng có thể gặp nó vài ngày một lần.
Có lẽ hai con số đó không cách xa nhau như vẻ ngoài. Có vẻ Intel nhìn theo tiêu chí một người dùng đơn lẻ, còn IBM có thể đã nghĩ từ góc độ yêu cầu hỗ trợ.
Tôi từng gặp vấn đề tương tự ở chỗ làm. Nếu xử lý 100 triệu request mỗi ngày, một vấn đề xác suất 1 trên 1 tỷ sẽ xảy ra vài lần mỗi tháng. Nếu đó là loại lỗi mà khách hàng, hoặc tệ hơn là quản lý, nhận ra được, mọi người sẽ bỏ qua mẫu số và nghi ngờ rằng tất cả đều bất tài. Bốn lần một tháng có thể được dịch thành “lúc nào cũng vậy” trong thiên kiến trải nghiệm của con người. Nếu hai lần xuất hiện cụm thống kê ba lần trong một tuần, sẽ có người bùng nổ.
Họ cũng cho rằng các con số mọi người dùng có khả năng gây lỗi cao hơn 90 lần so với các con số phân bố đều của Intel. Vì vậy mới ra kết quả là một người dùng sẽ gặp lỗi mỗi 24 ngày.
Có đoạn nói rằng “dường như chỉ có một người nhận ra lỗi này trong sử dụng thực tế, Giáo sư Nicely”.
Tôi nhớ đến một nghiên cứu từ lâu, trong đó người ta phát máy tính bỏ túi cho học sinh dùng trong giờ toán. Máy tính đã bị chỉnh để cho ra kết quả sai, và các nhà nghiên cứu muốn biết máy tính phải sai đến mức nào thì học sinh mới nhận ra điều bất thường.
Câu trả lời là gấp 2 lần.
Nhận ra lỗi và bị ảnh hưởng bởi lỗi là hai chuyện hoàn toàn khác nhau. Có bao nhiêu người kiểm tra xem đầu ra của máy tính có đúng không? Tôi nghĩ là rất, rất, rất ít. Ngay cả tôi cũng không làm, trừ một lần khi làm tính toán kỹ thuật ở Boeing, tôi chạy ngược phương trình để kiểm tra đầu ra có khớp với đầu vào hay không.
Cuối cùng, điều này phụ thuộc rất nhiều vào ngữ cảnh và việc người tính hiểu nội dung đến đâu.
Trong quá trình dùng FDIV trên Pentium, bao nhiêu phần là dành cho đầu ra quan trọng về mặt số học, chứ không phải đa phương tiện?
Tôi nhớ lỗi đó. Vì không thể kiểm soát khách hàng chạy trên CPU nào, chúng tôi phải đưa mã phát hiện FPU bị lỗi vào thư viện và chạy mã обход. Mã này do Intel cung cấp.
Nói cách khác, vấn đề của Intel trở thành vấn đề của tôi, ôi trời.
Tôi nhớ một câu đùa lan truyền hồi đó. Nó nắm bắt khá tốt nhiều sắc thái của thập niên 90:
I AM PENTIUM OF BORG.
DIVISION IS FUTILE.
YOU WILL BE APPROXIMATED.
Lại là một bài viết xuất sắc khác của Ken. Tôi đặc biệt nhớ vụ này vì chiếc PC đầu tiên tôi mua bằng tiền của mình có CPU bị ảnh hưởng. Trước đó tôi không mấy quan tâm đến PC vì chúng không chạy được phần mềm “thật sự”.
Nhưng Windows NT đã thay đổi điều đó, cảm ơn Cutler. Nhờ bo mạch chủ giá rẻ từ Đài Loan, việc tự lắp máy cũng trở nên khả thi, và đến nay vẫn có nhiều người làm vậy. Ken chỉ ra rằng người dùng khá dễ kiểm tra CPU của mình có bị ảnh hưởng hay không. Tôi nhớ việc đó dễ đến mức chỉ cần nhập vào Excel một công thức chia có các con số ma thuật. Nếu Microsoft phát hành phiên bản Excel обход lỗi này, có lẽ số người yêu cầu đổi CPU đã ít hơn.
Một phân tích thú vị và thật sự bền bỉ. Công sức phân tích silicon rồi chia sẻ kết quả thật đáng nể. Tôi đặc biệt thích điểm bài viết chỉ ra nguyên nhân gốc rễ thật sự, trong khi PR của Intel khiến nguyên nhân thực tế nghe như một thiếu sót nhỏ nhặt.
Thực ra đó là một vấn đề khó tha thứ hơn nhiều và đáng bị chỉ trích hơn. Vì họ đã làm hỏng thuật toán tạo bảng.
Câu “Smith đã đăng email đó lên diễn đàn Compuserve, phiên bản mạng xã hội của thập niên 1990” làm tôi có cảm giác kỳ lạ.
Bảng đã sửa trở nên đơn giản hơn nhiều bằng cách chỉ trả về 2, thay vì thêm mạch để trả về 0 cho các giá trị ngoài phạm vi. Vậy tôi tự hỏi tại sao họ không làm vậy ngay từ đầu.
Người tạo bảng có thể không biết rằng điền 2 cho các giá trị ngoài phạm vi sẽ tạo ra PLA đơn giản hơn, còn người nhét bảng vào PLA có thể không biết rằng 0 là giá trị không quan trọng (don't care) nên đã giả định phải bảo toàn nó.
Hoặc họ có thể đã dừng tối ưu hóa ngay khi cảm thấy PLA đủ nhỏ theo yêu cầu. Nếu kế hoạch bố trí đã xong, làm PLA nhỏ hơn nữa cũng không khiến toàn bộ chip nhỏ hơn, và thời gian kỹ thuật tốt hơn nên dùng cho chỗ khác.
Như hầu hết phần mềm, có một tối ưu hóa bị bỏ lại vì không ai nghĩ ra đúng lúc. Và CPU thời đó không thể vá được.