背景

這篇文章探討了處理器硬體設計中存在的各種缺陷，從早期的 Intel 386 到現代的 RISC-V 嵌入式晶片。討論的核心在於硬體錯誤如何影響軟體執行，以及開發者在面對這些無法輕易修正的物理缺陷時，必須採取哪些極端的軟體變通方案。

社群觀點

在 Hacker News 的討論中，最引人入勝的案例之一是 Intel 處理器中出現的「GenuineIotel」拼字錯誤。社群成員對此展開了熱烈推測，有人認為這可能是矽晶圓上的物理缺陷導致特定位元永久性錯誤，因為在 ASCII 編碼中，「n」與「o」僅差一個位元。然而，也有觀點認為這更像是邏輯合成過程中的瑕疵，或是生產線上的低級錯誤，例如操作員在手動輸入韌體參數時不慎「手滑」，將 GenuineIntel 誤植為 GenuineIotel。這種看似微小的拼字錯誤，在高度自動化的晶片製造領域顯得格外突兀。

另一個讓開發者感到崩潰的案例是 Rockchip RK808 的即時時鐘（RTC）設計缺陷。該晶片的工程師誤以為 11 月有 31 天，導致 Linux 核心至今仍需保留一段特殊的補丁，專門用來在格里曆與這套「Rockchip 曆法」之間進行轉換。這引發了關於硬體時鐘設計哲學的爭論。資深工程師指出，硬體時鐘不應試圖處理複雜的年月日邏輯，而應簡化為一個單純的 64 位元計數器，將時間轉換的工作交給經過充分測試的軟體函式庫處理。這種「硬體越簡單越好」的觀點獲得不少認同，因為一旦硬體邏輯出錯，軟體端往往需要付出巨大的代價來修補。

針對 RISC-V 晶片在執行乘法指令後需要插入空指令（NOP）的缺陷，社群出現了技術性的辯論。有意見認為，這反映了硬體廠商在管線化設計與測試上的嚴重不足，因為這種基本的指令序列錯誤理應能透過自動化測試工具輕易發現。雖然有人建議直接在編譯器層級禁用乘法指令，但更多開發者主張應透過修改編譯器後端，在特定指令後自動補上 NOP，以在維持功能完整性的前提下規避硬體缺陷。這種「軟體為硬體擦屁股」的現象在嵌入式領域屢見不鮮，例如 Intel Quark SoC 曾因 LOCK 前綴指令導致區段錯誤，開發者最終只能在二進位檔中強行抹除該指令。

此外，討論也觸及了處理器管線化設計的歷史。早期的 386 處理器雖然沒有現代意義上的分支預測器，但其內部管線狀態仍會受到分支執行歷史的影響。當多個子系統以未曾預料的方式交互作用時，就會產生極難重現的邊緣案例。社群成員一致認為，面對日益複雜的晶片架構，隨機指令流測試（Random Instruction Sequence Testing）是捕捉這類隱藏缺陷的必要手段，儘管這對硬體工程師而言是一項極具挑戰性的任務。

延伸閱讀

• RISU 工具：由社群成員開發，用於透過隨機指令序列測試來找出 QEMU 或硬體中的指令解碼錯誤。
• Rockchip RTC 核心補丁：記錄了 Linux 核心如何處理 11 月 31 天這項奇特硬體缺陷的技術細節。
• Intel 386 勘誤歷史：由微軟開發者回顧早期處理器在複雜指令序列下的設計瑕疵。
• Intel Quark Segfault Bug：維基百科上關於 Intel Quark SoC 因 LOCK 指令導致崩潰的詳細記載。