不久前，我需要且有機會重新熟悉 8086/8088 機器上軟體模擬 8087 FPU 的機制。
如其他地方所述，8086 CPU（1978 年）有一個通用的輔助處理器介面，最初稱為數值處理器擴充 (Numeric Processor Extension, NPX)，由 Intel 8087 FPU（1980 年）使用。雖然這個介面是通用的，但 8087 可能是唯一能實際使用的晶片。
8087 是一個昂貴的附加元件，前提是系統必須有插槽可以安裝 8087（IBM PC 有，但其他 8086/8088 系統不一定有）。有一大類軟體（例如試算表）可以從 8087 獲得顯著的效能提升，但在盒裝軟體的時代，有很大的誘因去發行能夠在有 8087 時使用它，但在僅有 8086/8088 機器的情況下仍能運行的軟體。
同時，也存在著開發和測試浮點軟體的需求，而無需在每台系統上都安裝 8087。鑑於 8087 晶片最初的供應有限，Intel 為了讓開發者能夠在沒有 8087 硬體的情況下編寫 8087 軟體，提供了相應的解決方案，這符合 Intel 的最佳利益。
Intel 在發布 8087 晶片時，同時提供了 E8087 軟體模擬套件。這可以從 1980 年 7 月的《8086 系列使用者手冊數值補充》 (Numerics Supplement to The 8086 Family User’s Manual) 中得到證明，訂單號為 121586-001。《數值補充》概述了 E8087 套件的工作原理。實際上，有兩個套件：完整的 E8087 函式庫，以及一個「部分」的 PE8087 函式庫，它僅實現了 Intel PL/M 語言工具所需的最少功能。Intel 的 PL/M 編譯器是第一款能夠利用 8087 的高級語言翻譯器。
由於 8086 沒有模擬 FPU 的內建機制（與 80286 及之後的處理器不同），模擬機制相當複雜，需要組譯器/編譯器、連結器和執行時期函式庫之間緊密合作。
組譯器或編譯器會產生「可模擬」的 8087 程式碼。實際上，翻譯器會產生標準的 8086/8087 程式碼，但物件模組會包含針對每個 8087 ESC 指令以及 (F)WAIT 的特殊修正。
早期，Intel 確立了一個慣例，即 WAIT 指令直接翻譯為 WAIT 操作碼，而 FWAIT 指令則可以被模擬。
一個關鍵事實是，語言翻譯器不會直接產生 8087 模擬程式碼。它僅準備好用於模擬的物件模組，同時發出常規的 8087 指令，而實際決定是否模擬是在連結時期做出的。
在連結過程中，會做出是否模擬的決定。使用者可以連結一個無模擬的函式庫 (8087.LIB)，此時連結器會保持物件程式碼不變。
當連結模擬函式庫 (E8087.LIB 或 PE8087.LIB) 時，會發生更有趣的事情。在這種情況下，特殊的修正會導致連結器將 90/Dx (NOP/ESC) 或 98/Dx (WAIT/ESC) 序列替換為軟體 INT 指令。
在 Intel 的原始實作中，ESC 操作碼 D8h-DFh 被替換為 INT 18h-1Fh，如 Intel ASM86 參考手冊 (Intel ASM86 Reference Manual)，訂單號 121703-003 (1983) 所示。
請注意，需要八個獨立的中斷向量來替換八個可能的 ESC 操作碼位元組。模擬器可能會（也很可能）使用單一例程來處理所有八個中斷向量，但需要這 8 個向量來保留 ESC 指令中 FPU 操作碼資訊的 3 位元。
Microsoft 採用了 Intel 的 8087 模擬機制，並對其 DOS 開發工具進行了一些修改。其他 DOS 開發工具供應商（Borland、Watcom 等）也使用了該機制。
出於顯而易見的原因，Microsoft 需要更改 8087 模擬器使用的軟體中斷範圍。DOS 模擬器使用向量 34h-3Dh，而不是中斷 18h-1Fh。是的，這是 10 個向量而不是 8 個。雖然 Intel 用 NOP 替換 WAIT 指令進行模擬，但 Microsoft 也模擬了 WAIT 指令，並且 Microsoft 還提供了使用 ES 區段覆蓋來模擬 FPU 指令的選項。
與 Intel 的原始模擬器相比，Microsoft 增加了一項重要的改進。如果帶有內建模擬器的程式在具有 8087 的系統上運行，模擬器會在啟動時檢測到這一點。每當執行一個模擬指令（透過 INT 34h-3Dh）時，模擬器會將軟體 INT 指令替換為原始的 NOP 或 WAIT 以及對應的 ESC 操作碼，然後返回執行真正的浮點指令。
這種機制對效能的影響最小（模擬指令在第一次執行時被替換為真正的 8087 指令），並確保帶有模擬器的程式在有 8087 的系統上以接近 100% 的速度運行，同時相同的二進位檔仍然可以在沒有 FPU 的系統上運行。
這通常用於發布給終端使用者的二進位檔，因為程式可以利用 8087 的優勢，但又不需要它。
我找到的最早的 Microsoft FPU 模擬機制實作是在 1983 年的 MASM 1.12 和 1.25 版本中（不，我不理解版本號，也不確定哪個更早）。請注意，這些組譯器還不支持 .8087 指令，並且默認情況下不接受 8087 指令，這與 Intel 的 ASM86 不同。要組譯 FPU 指令，必須使用 /R 開關。要產生模擬就緒的程式碼，還必須使用 /E 開關。
我準備了以下小型測試模組：
然後我使用 EMU2 模擬器（設定 EMU2_LOWMEM=1，以便早期 MASM 版本不會掛起）組譯了該模組，使用的是 MASM 1.25：
然後我使用 Watcom 反組譯器反組譯了結果，顯示了組譯器發出的物件程式碼，以及組譯器由於 /E 開關而添加的修正：
/R /E 開關組合使 MASM 產生與單獨使用 /R 時幾乎相同的物件程式碼，但為所有 FPU 指令和 FWAIT 添加了修正。
嘗試組譯註釋掉的指令會導致以下錯誤：
請注意，舊版 MASM 版本實際上也無法處理 FSTSW DS:[BP] 指令，儘管它沒有報告錯誤。它只是有效地丟棄了 DS: 前綴，這將導致執行不正確，因為通過 BP 的定址默認使用 SS 區段暫存器。
這些問題在 Microsoft MASM 3.0 (1984) 中得到了明顯的解決和修復，它可以處理為舊組譯器註釋掉的行（而且，Microsoft 的 MASM 2.0 沒有 8087 支持，因為版本號完全是一團糟）：
反組譯 MASM 3.0 的輸出，我們現在看到以下內容：
我們現在可以看到六種不同的修正：
修正的名稱看起來確實很奇怪。儘管它們是標準的符號名稱，但普通程式不太可能使用它們。
Microsoft（與 Intel 不同）從未為 MASM 提供獨立的 8087 模擬器；只有 Microsoft 的高級語言函式庫附帶了模擬器。最早支持 8087 的 Microsoft 產品之一是 Microsoft Pascal 3.04 版本（1983 年 2 月）。至少自 1981 年以來，MS Pascal 就使用以 QQ 結尾的符號名稱作為內部實現細節——這使用了古老的約定，符號僅限於 6 個有效字元，並且雙底線尚未用於保留符號。我不確定其他 Microsoft 語言是否使用了相同的約定，但這些修正名稱肯定與 Microsoft Pascal 的內部實現非常吻合。
至少在 Microsoft 的初始實作中，連結器不需要任何特殊的浮點模擬支持。所有的魔法都是透過語言翻譯器和執行時期函式庫之間精心協調的合作實現的。
它是如何工作的？修正指向函式庫符號。這些是具有精心選擇值的絕對符號。例如，FIWRQQ (FWAIT 修正) 的值是 0A23Dh。為什麼是這樣？
組譯器將 FWAIT 組譯為 NOP/WAIT，操作碼序列為 90 9B。當解釋為小端 16 位值時，它是 9B90h。
高位元組被丟棄，物件檔案中的位元組序列 90 9B 在最終的可執行檔中被替換為 CD 3D。當然，這就是 INT 3Dh。
對於標準浮點指令也使用了相同的方法。例如，FINIT 在物件檔案中組譯為 9B DB E3，並帶有 FIDRQQ 修正。FIDRQQ 的值是 05C32h，結果如下計算：
當然，CD 37 操作碼實際上是 INT 37h。請注意，操作碼序列 9B D8-DF 變為 INT 34h-3Bh。
當存在區段覆蓋時，情況會變得更複雜。例如，FSTSW CS:[BX] 發出以下位元組序列：9B 2E DD 3F。組譯器發出一個而不是兩個修正；FICRQQ 對應於指令的第一個位元組，FJCRQQ 對應於第二個位元組。現在，FICRQQ 的值是 00E32h，FJCRQQ 是 0C000h。
應用 FICRQQ 修正如下：
我們得到 INT 3Ch，它表示帶有區段覆蓋的 FPU 指令。
作為比較，帶有 SS 區段覆蓋的指令使用 FISRQQ 修正（值 00632h）與 FJSRQQ（值 08000h）結合使用。例如，FSTSW SS:[BX] 發出為 9B 36 DD 3F，計算如下：
請注意，CS 和 SS 區段覆蓋都導致 INT 3Ch。ES 區段覆蓋（顯然是 Microsoft 最先實現，然後是其他公司）使用 FIERQQ 修正，沒有相應的 FJxRQQ 伴隨，同樣產生 INT 3Ch。
模擬器如何知道是哪種覆蓋？這就是第二個修正的作用。
請注意，單一中斷向量足以處理 ES 覆蓋，因為它不是替換 WAIT/ESC 對，而是替換 WAIT 指令和區段覆蓋，保留 ESC 操作碼。
當添加對 CS/DS/SS 覆蓋的支持時，Microsoft 利用了 INT 3Ch 後面的指令始終是 ESC 操作碼這一事實，其高 4 位（實際上是 5 位）是固定的。為了支持 ES 以外的區段覆蓋，連結器會將指示區段暫存器的值添加到 ESC 操作碼。然後模擬器從中提取資訊。
對於 CS 區段覆蓋，FJCRQQ 修正會將 0C0h 添加到 ESC 操作碼，例如，DD 操作碼變為 9D。對於 SS 區段覆蓋，DD 操作碼變為 5D，對於 DS 區段覆蓋，DD 變為 1D。對於 ES 區段覆蓋，DD 操作碼保持不變。因此，模擬器可以解碼存在的區段覆蓋。
這裡可以找到一個可能有用且具啟發性的解釋，說明修正值是如何得出的。簡單來說，修正值是期望的兩位元組操作碼序列（INT xx）與語言翻譯器放置在物件檔案中的兩位元組操作碼序列（例如 WAIT/ESC）之間的差值。
一旦模擬機制到位，就可以將其支持擴展到其他工具，例如除錯器。例如，Microsoft 的 SYMDEB 識別軟體中斷，並為模擬指令提供特殊的解碼。以下是它的樣子：
上面的範例顯示了連結器應用的修正如何轉換浮點指令。SYMDEB 識別模擬浮點指令的能力非常方便，因為除錯器不會嘗試反組譯 INT 3xh 指令後面的「垃圾位元組」；這些位元組將由模擬器使用但從未執行。顯然，FSTSW [BX] 比 INT 39h 後跟一個 3Fh 位元組更容易理解。
較新的除錯器可能會反轉邏輯，並像處理真實浮點指令一樣反組譯模擬指令，也許會在註釋中顯示它們實際上是軟體中斷的事實。
如果物件程式碼已準備好進行模擬但不需要模擬，該怎麼辦？無模擬函式庫定義了相同的 FIDRQQ、FIWRQQ 等符號，但它們的值為零。當連結器應用修正時，物件程式碼保持不變。
這非常方便，因為函式庫可以準備好進行模擬，並且可以選擇使用或不使用 FPU 模擬。
請注意，產生模擬就緒程式碼會帶來輕微的效能損失。對於 FWAIT，語言翻譯器必須發出 NOP 指令，以便為軟體中斷留出足夠的空間。不需要模擬的 8087 程式碼可以省略這些 NOP。對於典型的浮點程式碼，這可能差異很小，因為大多數浮點指令都必須由 WAIT 指令預先處理。
現在讓我們回到 Microsoft 在兩三年後複製的原始實作。
據我所能找到的，Intel 第一個支持 8087 的組譯器是 1980 年基於 8080 的 ASM86 V3.0（8087 引入的年份）。ASM86 V3.0 的工作原理原則上與 Microsoft 1983 年的 MASM 版本相同。
早在 1980 年，Intel 是一家友善且樂於助人的公司（與後來變成一個沒有靈魂的龐然大物不同），並且模擬機制得到了部分文件記錄。儘管文件記錄實際上具有誤導性——也許它反映了實作的早期變體，其中語言翻譯器模擬零（或接近零）操作碼位元組，而修正將它們轉換為 FPU 指令或軟體 INT 指令。
1980 年的實際 ASM86 V3.0 的工作方式與 1984 年的 Microsoft MASM 3.0 非常相似，儘管修正名稱大不相同，實作也不完全相同。以下是 Microsoft 名稱及其 Intel 對應項的表格：
Intel 提到帶有冒號的符號名稱無法由常規語言翻譯器產生，因此它們是保留符號，保證不會與使用者選擇的符號名稱衝突。
在 Intel 的實作中，M:_WST 是 Microsoft 的 FIDRQQ 的確切對應項，但實際值不同，因為 Intel 使用了不同的中斷範圍。M:_WST 產生 INT 18h-1Fh。M:_WT 將 WAIT 轉換為 NOP，並且不使用軟體中斷。
與 Microsoft 不同，Intel 使用獨立的中斷向量（14h-17h）來分別指示區段覆蓋 ES、CS、SS 和 DS。因此，Intel 不需要兩個修正來處理帶有區段覆蓋的指令，但需要更多的中斷向量來進行模擬。
Intel 還實施了五個額外的修正：M:_NST、M:_NCS、M:_NDS、M:_NES、M:_NSS。這些用於指令的無等待形式，例如 FNSTSW 或 FNINIT。請注意，Microsoft 從未支持這些，甚至例如 MASM 5.1 在組譯模擬就緒程式碼時也無法處理 FNSTSW（MASM 6.x 假裝可以，但只是直接模擬 FPU 指令，沒有模擬修正）。
另一個細微的差異是，Intel 的 ASM86 V3.0 在不需要使用者提示的情況下接受 8087 指令，並且始終產生 FPU 模擬所需的修正。
可以公平地說，Intel 最初的 1980 年實作比 Microsoft 1983 年的複製版本（無法處理區段覆蓋或無等待指令）甚至改進的 1984 年 Microsoft 版本（可以處理區段覆蓋但不能處理無等待指令）都更完整。
8087 模擬機制是一件藝術品。語言翻譯器在產生浮點指令時只需要發出少量特殊修正。簡單的連結器根本不需要特殊支持，只需要應用函式庫提供的修正。是否應模擬 8087 指令的決定被推遲到連結時期。
幾乎所有的魔法都包含在模擬函式庫中，它提供了特殊的修正，最重要的是，它提供了模擬 8087 浮點指令的程式碼，這是一項遠非微不足道的工作。
Intel 在 1980 年首次實施了 8087 模擬。Microsoft 在 1982-1983 年左右實施了自己的變體。Microsoft 的實作顯然基於 Intel 的原始版本，儘管它並不完全相同，並且具有不同的缺陷和優勢。
感謝您的分析。我第一次遇到這個問題是在 1987 年上大學的時候。我們得到了一份 Microsoft FORTRAN 的副本，安裝程式提示我創建各種函式庫。我們可以選擇 8087 專用、模擬 8087（如果可用，將使用 8087 晶片）和「alt math」（與 8087 晶片無關，準確性較低，但速度快得多）。
我一直以為模擬 8087 的函式庫只是在兩個不同的函數調用之間切換，因此會帶來巨大的效能損失。現在（我認為）我知道不是這樣的。
「通用輔助處理器介面，最初由 Intel 8089 I/O 處理器使用」 8089 並未使用 8086 輔助處理器介面。它通常與 CPU 共享位址空間，但除此之外完全獨立。
由於 8086 沒有模擬 FPU 的機制（與 80286 及之後的處理器不同）
我檢查了一下，發現 8086 沒有非法操作碼例外。Intel 做了一個糟糕的設計決策，但 Intel 的銀行帳戶不在乎。
有人確切知道 80286 如何檢測 20287 是否存在嗎？
一個有趣的相關錯誤（或者至少可以說是一個錯誤）：在 QuickBASIC 編譯的可執行檔中使用的 FPU 模擬程式碼中，FWAIT / INT 3Dh 的處理器不會像 INT 34h-3Ch 的處理器那樣實際修補調用點；它只是執行 STI、FWAIT、IRET 並將原始的 INT 3Dh 留在原處。這導致在 Windows (V86 模式) 下運行大量浮點運算的 QB 程式時效能顯著下降。
這是由 v1ctor 發現並在 FFIX 中修補的（請參閱 phatcode 獲取副本）；問題的原始記錄在 TSRFFIX.ASM 中。
（我不知道該時代的其他 Microsoft 工具鏈是否也是如此，但我並不驚訝於更多產品共享相同的程式碼。）
這非常有趣。看來 Microsoft 以某種方式使用了 INT 3Dh 作為數學故障處理的一部分，因此他們只需要修補一些 INT 3Dh 實例。也許在某些情況下這並不起作用。我可以看到，如果 INT 3Dh 處理器不斷觸發 #GP 故障，這可能會在 V86 模式下造成嚴重的效能損失。
Intel 完全繞過了這一點，因為他們沒有任何運行時修補程式碼的機制。如果你連結了模擬函式庫，FWAIT 就變成了 NOP 並完全消失了，所以只能安全地運行模擬器（或者可能使用真實的 FPU，但在從 INT xx 處理器返回之前執行 WAIT）。
8086 是一個非常非常老的設計。Intel 早期處理器如 8080 或 8085 沒有非法操作碼的概念。直到 80186/80286 才引入了這一點。當時，人們認為確保不會執行無效操作碼是程式設計師的責任。
8086 只是執行所有指令，這意味著某些操作碼會產生奇怪的結果，許多未定義的操作碼只是已定義操作碼的別名，因為指令解碼會忽略某些位元。
請參閱 http://www.os2museum.com/wp/undocumented-8086-opcodes-part-i/ 關於未記錄的 8086 操作碼。
還有 http://www.os2museum.com/wp/learn-something-old-every-day-part-xviii-how-does-fpu-detection-work 關於檢測 287 的方法——該技術非常相似，但需要一些技巧來編寫適用於所有 CPU/FPU 組合的檢測例程。
你是對的，大部分情況下。8089 使用（或可以在本地模式下使用）與 8087 相同的「本地匯流排」介面，使用 RQ/GT 信號，但未使用 ESC 指令機制。所以我想除了 x87 之外，沒有其他東西使用 ESC 操作碼了。或者至少沒有官方發布的產品。
不，模擬函式庫非常聰明，可以在存在 8087 的情況下利用它，效能損失很小。在 FPU 的存在遠非保證的時代分發軟體非常有用。
我認為「替代」數學與此非常不同，它速度更快，因為它沒有實現 IEEE 754 語義。
> SYMDEB 識別模擬浮點指令的能力非常方便，因為除錯器不會嘗試反組譯 INT 3xh 指令後面的「垃圾位元組」；這些位元組將由模擬器使用但從未執行。顯然，FSTSW [BX] 比 INT 39h 後跟一個 3Fh 位元組更容易理解。
唉。用「笨拙」的反組譯器逆向編譯舊的 Fortran 程式非常痛苦。我不得不編寫一個後處理器。這就是我學習 awk 的方式。順便問一下，您能否為所有這些「學點老東西」的文章加上標籤？已經有 20 篇了，要全部找到需要一些努力。
感謝 Michal 提供 os2museum 頁面的連結，它們很有趣，這個網站提供了極好的資訊。我相信 PDP-11 是一款 16 位處理器，於 1970 年發布，它在遇到未定義操作碼時會引發異常。Intel 在 1976 年製造 8086 16 位 CPU 時很懶惰，它應該像 PDP-11 一樣具有未定義操作碼異常。但歷史表明，Intel 當時專注於他們的 iAPX 432，結果卻是一場災難。
Intel 確實為無法使用的指令處理預留了中斷向量。然而，IBM 顯然沒有閱讀 Intel 的文件，並為其 BIOS 使用了多個 Intel 保留向量，這阻礙了 Intel 在所有 IBM PC 克隆機上的某些硬體規劃。你可以在其他 x86 機器上（即使是 MSDOS，因為 Microsoft 似乎意識到 Intel 的規則）透明地使用 8087 指令模擬，但由於 IBM 的錯誤，這在 PC 上被排除了。IBM 在實施 8087 時也搞砸了中斷接線，PC 的設計相當粗心。但市場並不在乎，IBM PC 成為了主導的機型。IBM BIOS 的另一個犧牲品是 Intel 80186 晶片，這是一款用於 8086 的成本降低產品，集成了當時一些最常見的支援晶片，但該集成晶片使用了 IBM 踩踏的 Intel 保留中斷。這是一款不錯的晶片，但銷量不高。
PDP-11 的價格範圍完全不同。8086 的價格不到 100 美元。PDP-11 在 1980 年的價格高達 10,000 美元以上，當時它已經有 10 年的歷史了。舊 x86 處理器的設計受到 Intel 製造能力的顯著限制，這極大地影響了功能選擇。從現代角度來看，8086 完全是荒謬的，沒有人應該費心為它編寫軟體。但 1980 年並非如此。
是的，iAPX-432 應該是 Intel 的未來，而不是 x86。但事情並沒有按照計劃進行。就像大約 20 年後的 Itanium 一樣。
IBM 閱讀了文件，但 IBM PC 是為 8088 設計的，而不是為 80186 或 286 或任何類似的東西。這是一個簡單、便宜、一次性的設計。但隨後商業現實的力量改變了事情。
關於 8087，一個主要困難是，當 IBM PC 設計時，8087 幾乎不存在。這就是為什麼原始的 IBM PC 有一個神秘的「插槽」，但文件從未提及任何關於 8087 的內容。我不認為 IBM 搞砸了接線，他們顯然不希望數學故障像 Intel 所設想的那樣觸發 NMI。從某種意義上說，如果 Intel 想設計完整的 PC，他們應該設計完整的 PC，而不是賣一堆晶片給 PC 設計者。我認為 IBM 所做的更改在當時的行業中並不少見，只有當 IBM PC 設計的壽命遠遠超出預期時，它才成為一個問題。
是的，可以說 80186 是 IBM PC 的犧牲品。但如果沒有預見未來的能力，就很難避免。
現在有一個新的 LSOED 類別。我不確定它有多大用處，因為主題相當隨機……但它就在那裡。
PDP-11 擁有一系列處理器，包括低端的 LSI-11。LSI-11 (PDP-11/03) 在 1978 年由 Heathkit 包裝成 H-11，組裝價格為 1,600 美元，與當時可用的 S100 匯流排機器相比，價格並不算太離譜。與更新的 IBM PC 相比，甚至不算太差。
* 請注意，PDP-11 的用途之一是作為鑽井頭的控制機制。晶片需要相當便宜，因為使用時經常會導致損壞。處理器可以按最大記憶體分類，型號最大為 64KB、256KB 或 4MB，再加上最初的 VAXen，它具有 PDP-11 模式，便於部署大記憶體。與當前主題相關的是 FP-11，這是一個早期的數學輔助處理器，由於它是可選的，DEC 必須在 Intel 嘗試之前幾年就解決這些問題。
> 現在有一個新的 LSOED 類別。謝謝。> 我不確定它有多大用處，因為主題相當隨機……但它就在那裡。嗯，這些文章有一個共同的前綴並且有編號，所以作為一個系列閱讀它們不會有壞處 :)
有趣的是，關於 H11 的維基百科文章聲稱它賣得非常差，部分原因是它被當時的 x86 處理器性能超越。
H11 對 Heathkit 來說是一個不錯的銷售產品，儘管不是專業電腦公司的期望。H11 被取消時，LSI-11 已經是七年前的設計了。許多 PDP-11 的粉絲希望看到主流的 J-11 設計。J-11 的速度大約是 LSI-11 的 20 倍，但製造成本相似。
LSI-11 佔 PDP-11 總銷量的約 20%。（600,000 台 PDP-11 中有 100,000 多台）PDP-11 標準軟體設計類似於 8086 多任務小型模型程式。記憶體管理和 8K 頁面的優勢以及實時響應能力對於大眾市場來說並不奏效。靈活的 I/O 連接埠設計可能阻礙了商業軟體，因為很少有 PDP-11 能夠保證擁有相同設備並放置在相同位置。
DEC 決定迴避高端 PC 和工作站市場，直到其他公司已經佔據一席之地。DEC 想要廉價的主機市場，但 IBM 可以通過降低利潤率使其成為一個虧損的提議。
如果你看看 righto.com，你會發現 Intel 花費了大量的電晶體並增加了大量的複雜性，以便更容易地將 CP/M 軟體移植到 8086，而不是製造一個漂亮、乾淨的架構。有沒有選擇讓它不那麼奇怪，更正交和清晰？哦，絕對有。然後它就會被列入類似 NS32000 和 Z8000 的失敗名單中。
銀行帳戶能很好地反映「正確的決策」——除了「正確的決策」很少與「乾淨高效」的架構一致。更多時候，最佳決策是一種帶有許多瑕疵的妥協。
Intel 在這方面有點奇怪：它花費了大量的時間和精力試圖生產「架構上乾淨」的東西——不可避免地失敗了，而「應急產品」拯救了它。
在 90 年代初期，我在一家銷售 PC 克隆的公司工作。由於業務性質，老闆/買家會購買成本最低的主機板。我記得有一次銷售了三台電腦，它們工作正常，直到客戶開始運行他們的 QuickBasic 程式。數學結果反覆出現錯誤。我們更換了另一款主機板，一切都恢復正常。
現在 35 年後，我想知道它是否檢測到了數學輔助處理器。我不記得這是一個 XT 還是 286 克隆機。Lotus 123 工作正常。如果是 XT，我想知道我是否設置了錯誤的開關，但根據文件是正確的。
您的電子郵件地址不會被公開。必填欄位標記為 *
此網站使用 Akismet 減少垃圾郵件。了解您的評論數據如何被處理。