如果有的話，intel 和 amd 的 ISA 之間究竟有什么區別？

Question

我知道以前有人問過類似的問題，但是有太多相互矛盾的信息，我真的想嘗試一勞永逸地解決它。 我將通過明確區分指令集架構 (ISA) 和實際硬件實現來嘗試這樣做。 首先我試圖澄清：

1.) 目前有 intel64 和 amd64 CPU（其中包括但這些是重點）

2.) 鑒於 ISA 是 1 個或多個 CPU 指令的二進制表示，這意味着 ISA 與其實際的硬件實現完全分開。

我的問題：

intel 64 和 amd64 CPU 之間的差異是否與不同或擴展的 x86-64 ISA 有關？ 或者 x86-64 ISA 的不同硬件實現？ 還是兩者兼而有之？

Answer 1

是的，ISA 是一個文檔/規范，而不是硬件。 正確實現所有這些是使某些東西成為 x86 CPU 的原因，而不僅僅是與 x86 相似的東西。

有關官方文檔（英特爾手冊）的鏈接，請參閱x86標簽 wiki。

Intel 和 AMD 的x86 ISA 實現的不同主要在於性能以及它們支持的指令集擴展。 軟件可以使用CPUID指令查詢支持的內容。

也存在非性能差異，例如指令語義的偶爾細微差異，尤其是操作系統需要使用的特權指令：

• Intel 和 AMD x86-64 實現的兼容子集是什么？
• https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64

---

這里的主要分歧之一是英特爾、AMD 和威盛都有自己的硬件虛擬化擴展，它們甚至不嘗試兼容。 因此，像 Xen 這樣的 VM 需要為這些擴展中的每一個單獨的“驅動程序”或“后端”代碼。 但這些仍然是擴展，不是基線 x86 的一部分。

供用戶空間程序使用的 SIMD 擴展最終在兩者上都可用，通常會延遲，這要歸功於英特爾通過反競爭做法來顛覆 AMD 的努力。 這會花費其他人的時間，並且通常不利於整個 x86 生態系統（例如，SSSE3 現在可以被假定為更多軟件的基准），但有助於英特爾的底線。 一個很好的例子：AMD Bulldozer 支持 FMA4，但英特爾在最后一刻改變了主意，在 Haswell 中實現了 FMA3。 AMD 直到他們的下一個微架構（Piledriver）才支持這一點。

---

鑒於 ISA 是 1 個或多個 CPU 指令的二進制表示。

不，ISA 遠不止於此。 Intel 記錄為在所有 x86 CPU 上得到保證的所有內容都是 ISA 的一部分。 這不僅僅是每條指令的詳細行為，還包括哪個控制寄存器做什么以及內存排序規則之類的東西。 基本上，英特爾和 AMD 出版的手冊中的所有內容都沒有以“關於某某特定型號的 CPU”開頭。

我預計在某些情況下，Intel 和 AMD 的系統編程指南在 x86 的工作方式上有所不同。 （如果他們為他們的 x86 CPU 發布他們自己的 VIA 的話）。 我沒有檢查過，但我很確定用戶空間不會受此影響：如果存在差異，它們僅限於特權指令，只有在內核運行它們時才有效。 無論如何，在那種情況下，我想您可以說 x86 ISA 是 Intel 和 AMD 文檔的通用子集。

---

請注意，嘗試找出實際硬件在實踐中的作用對於理解文檔很有用，但不能替代閱讀它們。 您不希望您的代碼依賴於一條指令在您測試的 CPU 上的行為方式。

然而，英特爾確實使用真實軟件測試了他們的新設計，因為無法運行現有版本的 Windows 將是商業上的一個缺點。 例如， Windows9x 不會使只能憑推測填充的 TLB 條目無效（本示例的其余部分只是對那篇非常詳細的博客文章的總結和推斷）。 這要么是基於它是安全的（並且當時在硬件上是安全的）假設的性能黑客，要么是一個未被注意到的錯誤。 當時無法通過硬件測試檢測到它。

現代英特爾 CPU 會進行推測性頁面遍歷，但即使在最近 Haswell 檢測和擊落錯誤推測時，假設這種情況不會發生的代碼仍然可以工作。

這意味着真正的硬件提供了比 ISA 更強的排序保證，它說：

處理器可以緩存預取和作為推測執行結果的訪問所需的轉換，這些預測執行在執行的代碼路徑中永遠不會實際發生。

盡管如此，依賴這種更強的行為將是一個錯誤，除非您只在已知的微體系結構上這樣做。 AMD K8/K10 類似於 Intel，但推土機系列推測沒有任何檢測+回滾機制來提供一致性，因此 Win9x 內核代碼在該硬件上是不安全的。 未來的英特爾硬件也可能會放棄檢測+回滾機制。

TL:DR：所有 uarches 都實現了 x86 ISA 所說的內容，但有些提供了更強的保證。 如果您和 Microsoft 一樣大，Intel 和 AMD 將設計 CPU 來重現您的代碼所依賴的非 ISA 保證行為。 至少在該軟件長期過時之前。 無法真正保證未來的英特爾 uarch 將保留回滾機制。 如果英特爾從頭開始進行另一次重新設計（比如 P4 / NetBurst，而不是僅僅建立在他們現有的 Sandybridge uarch 系列上），那么他們可能會改變一些東西。

---

一個不同的例子：根據英特爾 insn ref 手冊中的論文規范，輸入為零的bsf指令使其輸出未定義。

但是對於任何特定的 CPU，都會有一些行為模式，例如將輸出設置為零，或保持不變。 在紙面上，由於不同的微體系結構狀態，亂序執行 CPU 真正給出對於相同輸入不同的不可預測的結果是有效的。

但是英特爾選擇在芯片中實現的行為是在bsf或bsr輸入為零時始終保持目的地不變。 AMD 也這樣做，甚至記錄了行為。 它基本上是mov eax,32 / bsf eax, ebx將完全像tzcnt一樣工作的非官方保證（標志設置除外，例如基於輸入為 0 而不是輸出的 ZF）。

這就是popcnt / lzcnt / tzcnt對 Intel CPU 中的輸出寄存器有錯誤依賴的原因！ .

CPU 供應商通常會超越紙質 ISA 規范，以避免破壞某些依賴於這種行為的現有代碼（例如，如果該代碼是 Windows 的一部分，或者英特爾 / AMD 在其新 CPU 上測試的其他主要軟件部分）設計）。

正如 Andy Glew 在有關上述連貫頁面遍歷以及自修改代碼的評論線程中所說的那樣：

一個特定的實現必須實現與架構聲明兼容但比架構聲明更強的規則，這是很常見的。 但並非所有實現都必須以相同的方式執行此操作。