AMD推土機最大的祕密：Decoupled Front-end Architecture

三期零利率方案實施中

這不是購物台商品促銷廣告，而有鑑於「AMD推土機最大的祕密」這主題牽連甚廣，包含諸多非常基本的電腦概念，與相關歷史文獻的考證工作，若是貿然單刀直入、亂塞一堆圖解，恐怕屆時讀者腦中只會殘留著「躺著輕鬆吸收」的恐怖幻覺，和編輯部討論後，毅然決定以三期連載來九淺一深…呃，深入淺出、抽絲剝繭，以竟全功，一心一德，貫徹始終。

無敵大哉問：電腦為何物？

越看似想當然耳的簡單問題，越難以獲得言簡意賅般的精確答覆，在此複習「計算機（Computer，或叫電腦）」與「計算器（Calculator）」最大的相異點：「進行條件判斷」與「變更執行流程」的能力，可依據不同的條件，執行不同的指令，作為人類用來處理訊息的工具。

好比天底下的男人都有自己獨樹一幟的審美觀，靈魂之窗內建的過濾器會自動分辨參加聯誼的對象是「正妹」還是「恐龍」，身體再決定要上前搭訕還是拔腿烙跑，毋需冒險承擔從大閒者轉職勇者的風險。

當代主流架構：儲存程式型電腦

但「電腦」不限於此，你想用電腦「泛用化（General Purpose）」，不限定於固定的用途，讓機器更有彈性，你就需要創造一組「指令集架構（ISA，Instruction Set Architecture）」作為電腦最基礎的「語言」，並將所謂的「運算」轉化成一連串指令的執行細節。講的抽象一點，指令集在電腦內扮演的角色，不外乎軟體和硬體之間的「介面（Interface）」。

一套完整的指令集架構，需定義運算性質（加減乘除資料搬移）的運算子、中斷例外規則、執行權限層級、系統呼叫程序、記憶體保護等，也必須包含進行條件判斷與變更執行流程的規則，以及標定運算目標的運算元（主記憶體、暫存器）之定址模式。

▲進階觀念：作為硬體與軟體之間介面的「指令集架構」與結合作業系統特性的「應用程式二進位執行檔介面」 

Q1：為何同樣採用x86指令集架構的Windows和Linux，卻無法直接相互執行應用程式？

Q2：同樣Windows作業系統，為何無法直接在32位元OS執行x64應用程式？

Q3：為何32位元Windows作業系統能執行Win32應用程式？無須重新編譯？

A：ABI（Application Binary Interface）結合處理器指令集與作業系統的服務呼叫等雙重特性，讓編譯好的目的碼（Object Code）可直接運行，無須修改。不同的作業系統有其相異的ABI規範，所以Windows無法直接執行Linux應用程式，反之亦同。 

Q：和「應用程式介面」API（Application Programming Interface）有何不同？

A：API的功能在於「讓程式碼可在支援相同API的環境中編譯」，定義的是「程式碼與作業系統/函式庫之間的抽象介面」，提高應用程式的維護性和擴展性。中國那邊譯作「應用編程介面」其實比較貼切。 

這些指令是一種特殊型態的靜態資料（基本上是唯讀的，但x86有SMC這種例外），以被編碼的形式，存放在與CPU分開的「主記憶體」內，可讓使用者依據不同的用途、更替不同的程式，也可讓程式執行時，自我修改程式的運算內容。這就是我們今日耳熟能詳的「范紐曼型架構（Von Neumann Architecture）」。

而「范紐曼瓶頸」：記憶體速度跟不上CPU，也是近代高效能處理器的最明顯侷限，多層化的高效能快取記憶體、高效率的系統匯流排、非循序記憶體存取（Memory Disambiguation）、決定多處理器及多核心效能延展性的快取資料一致性協定（Cache Coherence Protocol）等，均為紓解此瓶頸而生，但並非擁有無止盡的記憶體頻寬和無限低的記憶體延遲就此高枕無憂，因為考慮到程式執行的行為模式，廣義的范紐曼瓶頸還有「控制指令執行流程」這一關。

▲這簡單的一張圖足以解釋今日主流電腦架構的效能瓶頸。

資料和指令分開存放的「哈佛架構」

哈佛架構（Harvard Architecture）將程式指令和資料儲存分而治之，可同時存取資料和指令，理論上有較高的執行效率，但資料與指令記憶體的存放空間不能互通有無，缺乏記憶體容量的使用彈性，所以在今日多數存在於特殊應用的小型微控制器與數位信號處理器。

哈佛架構也偶爾被引申為分離式指令快取和資料快取（特別是L1），這在今日多數高效能處理器算是常態了。唯一可以肯定的是，哈佛架構和林書豪沒有任何關連。（編輯部：你嫌氣溫不夠低嘛？）

「指令集架構」vs「核心微架構」

近年來拜ARM此類授權IP商務模式的影響之所賜，似乎越來越多人搞不清楚「指令集架構」和「核心微架構（Micro-Architecture）」的差別，舉統治個人電腦市場的80x86為例，前者說穿了是「電腦的基本語言（x86指令集的歷代沿革，i386、x86-64、SSE、AVX等）」，後者是「執行語言的載具（Intel和AMD一大票微架構code name）」，不能混為一談。

無獨有偶，現在是智慧型手機征服地球的時代，那支配該市場的ARM又是怎麼一回事呢？現行主流ARMv7-A指令集，總計有ARM本家賣IP授權給別人的Cortex-A5/A7/A9/A12/A15/A17這幾種核心微架構，而Qualcomm自行開發Scorpio/Krait，Apple併購PA Semi後也關起門來搞出A6「Swift」。

只要作業系統相同（如版本Android或iOS），這些核心微架構應當正確執行使用ARMv7-A指令集撰寫或編譯出來的軟體，講的更專業一點，它們擁有相同的應用程式二進位執行檔介面（ABI，Application Binary Interface），如同Intel與AMD的x86處理器都可正確安裝Windows作業系統，理所當然地執行Office等應用軟體和Battlefield等套裝遊戲。

x86指令集缺乏統一標準和公定版本

這其實並不需要浪費篇幅多加解釋，誰叫所有x86處理器廠商都喜歡各搞各的，而Intel又總是「造成既成事實」逼迫大家相容，懶得出面制定標準，「幸好」現在市場只剩下兩間廠商，AMD又放棄SSE5依循Intel AVX（還是搞一些XOP延伸指令），情況應該會慢慢改善，結局不是只剩下Intel一家獨霸就功德圓滿了。

▲eClipz計畫的結局固然壯志未酬、未能一舉悲願成就藍色巨人兩大高階伺服器的「統一大業」，但也夠讓搬折凳吃零食看好戲的鄉民們津津樂道了。圖片來源：IBM。

截然不同的微架構可相容同樣的指令集，Intel和AMD的x86處理器「原則上」都可正確執行相同的軟體，但性能特徵卻大相逕庭。反之，就算是不同的指令集，透過良好的共通微指令（Micro-Instruction，在處理器內構成指令控制訊號的微碼）及控制單元，也可實作出「部分共享」的微架構，IBM近年來為了節約處理器研發支出、曾嘗試統合Power與System z的處理器微架構，殷鑑不遠，而AMD的K5身為x86處理器的一員，浮點運算器卻原封不動的沿用自家RISC處理器AM29000的相同功能單元，更是一絕。

下一頁：藍色巨人功敗垂成的eCLipz計畫