請更新您的瀏覽器

您使用的瀏覽器版本較舊,已不再受支援。建議您更新瀏覽器版本,以獲得最佳使用體驗。

科技

英特爾終於自己開了徹底改革 x86 指令集的第一槍,然後呢?

科技新報

更新於 2023年06月06日14:13 • 發布於 2023年06月07日07:50

「呆伯特法則」(Dilbert Principle)系列曾提到「天下任何事都有邏輯極限」,過往近半個世紀,靠「領先業界的先進半導體製程」和「x86 指令集相容性」為雙重護城河的英特爾,不但近年失去前者,看在指令集複雜度份上,研發嶄新 x86 指令集相容處理器動輒耗時三年,也終於走到不得不徹底改革後者的這步了。

x86 指令集誕生 45 年後大改革

8086 處理器問世後 45 年,今年 5 月 22 日,英特爾官方部落發表〈展望簡化後的英特爾指令集架構〉(Envisioning a Simplified Intel Architecture)一文與《x86-S 指令集技術白皮書》(檔案名稱暗示完成日期是 2023 年 4 月 17 日)。x86-S 指令集廢除昔日 16 位元和 32 位元模式,從一開機初始化就進入「純 64 位元模式」,不再從 16 位元或 32 位元切換至 64 位元,僅保留 64 位元環境執行 32 位元應用程式的相容模式(Compatibility Mode)。

▲ x86-S 重點就只有一個:留下 64 位元,和 16 / 32 位元說再見。

無獨有偶,COMPUTEX 2023 期間,Arm 發表 2023 年(TCS 23, Total Compute Solutions 23)三款基於 Arm v9.2 指令集的新 CPU 核心 IP:Cortex-X4、Cortex-A720 和 Cortex-A520,也英雄所見略同走向全面「純 64 位元」(AArch64),與轉向純 64 位元的 Android 息息相關──即使蘋果早在 2017 年 Apple A11 處理器和 iOS 11 作業系統就默默做了這件事。

現在個人電腦與資料中心最普及的「電腦最基礎語言」,從 1978 年 6 月 8 日登場的 8086 處理器為起點的 x86(iAPX86)指令集架構(ISA),公認為設計不良、疊床架屋、缺乏標準的糟糕產物,不僅無數計算機結構教科書與學術論文視為經典錯誤範例(比 x86 更慘烈的大概也只有 DEC VAX 和同樣出自英特爾的 iAPX 432),AMD 某知名架構師甚至說「毫無道理可循」,更曾被當代兩位 RISC 大師著作譏諷「只有創造它的人才會喜歡」。

x86 指令集的「位元數」(指令指標器與整數邏輯暫存器長度),主要有以下幾個里程碑,也是一步一步卸下包袱的歷程。

  • 1976 年:英特爾研發「單晶片大型主機」iAPX 432(8800,英特爾第一個 32 位元處理器)計畫的備胎。

  • 1978 年:8086 處理器,16 位元真實模式(Real Mode)、20 位元節區記憶體定址。

  • 1979 年:8088 處理器(8086 的 8 位元匯流排版),開啟個人電腦時代篇章。

  • 1982年:80286 處理器,16 位元保護模式(Protected Mode)、24 位元節區記憶體定址、四層保護權限(Ring 0 / 1 / 2 / 3)。

  • 1985 年:80386 處理器,32 位元保護模式、32 位元分頁式(Paging)記憶體定址、32 位元節區記憶體定址,與俗稱「32 位元 Ring 0 權限」的「虛擬 86 模式」(VM86,讓 x86 處理器能在 32 位元多工作業系統執行 16 位元真實模式的作業系統和應用程式)。江湖傳言當初 IBM 不太想賣 80386 個人電腦,猶豫不決,反讓 Compaq(後被 HP 併購)捷足先登,就是擔憂 80386 會影響 S/360 體系商業大型主機(Mainframe)的生意。當然,這是當時 IBM 自己太會胡思亂想。

  • 1997 年:Pentium II 導入「快速系統呼叫指令」(SYSENTER / SYSEXIT),可快速切換 Ring 0(系統模式)和 Ring 3(使用者模式),充分反應節區記憶體和 Ring 1 / 2 權限的無足輕重。但根據英特爾申請過專利,早在 Pentium Pro 就實做快速系統呼叫指令,為何遲遲沒有公佈,原因只有英特爾自己知道了。

  • 2003 年:AMD 在 1999 年帶頭發難的 x86-64,讓 x86 指令集邁進 64 位元。可使用 64 位元指令與 64 位元暫存器的「Long Mode」移除虛擬 86 模式。

  • 2005 年:Windows XP x64 專業版完全刪除 16 位元二進位執行檔相容性。從那時起,英特爾就大力推廣 64 位元 UEFI。這年透過硬體輔助虛擬化技術(Ring -1),也成為 x86 指令集的一部分。

  • 2008 年:可擠出額外 64kB 記憶體空間的微軟 HMA(高記憶體位址區域)和 HIMEM.SYS 驅動程式,所需「A20 Gate」(IBM 利用 8042 鍵盤控制器某訊號腳位為控制 A20 的開關)移除,變相放棄不少早期 8086 作業系統和應用程式相容性。

  • 2012 年:64 位元 UEFI 韌體廣泛採用。

  • 2018 年:Canonical 維護的最普及 Linux 套件 Ubuntu,從 18.04 版就只支援 64 位元。Nvidia 也在這年停止維護 32 位元驅動程式。

  • 2019 年:英特爾「Ice Lake」微架構實作五層式分頁表(5-Level Paging),虛擬記憶體位址延伸到 57 位元(128 PB)。

  • 2020 年:英特爾韌體開始不支援「非 UEFI64」與 16 位元、 32 位元作業系統。簡而言之,這時 x86 處理器平台停止原生支援 16 位元應用程式,僅保留執行 32 位元應用程式的能力。

  • 2021 年:微軟僅推出 64 位元版 Windows 11。

  • 2023 年:英特爾提出純 64 位元 x86-S 指令集架構。

經過 20 年演化,64 位元環境從此成為 x86 處理器平台的「既定標準」(de facto standard)。因此 x86-S 指令集支援的運作模式總結如下:

英特爾「官方認證」的 x86 指令集缺陷,究竟有哪些?

Pentium Pro 總工程師之一 Robert Colwell 回憶錄提到一個重點:開發 x86 指令集相容處理器,最艱鉅挑戰在「確保相容目前所有應用程式」,特別某些應用程式還「利用」長年累積的臭蟲和沒有遮蔽(Masked)的未定義運算碼(Undefined Opcode)。所謂「資產」與「包袱」是一枚硬幣的兩面,大概就是這麼回事。筆者偶爾會在網路看到某些大作宣稱「x86 優於 Arm 的強項,在於無與倫比的軟體相容性」,心裡就會碎碎念「你真的知道你在寫什麼嗎?」

▲ 儘管英特爾曾企圖謀殺 x86 指令集,但也只敢承認「暫存器不足」。諷刺的是,後來 Itanium 處理器還因暫存器實在太多,難以提高時脈,變成教科書寫的「只是時脈拉不上去、整數運算效能很平庸的處理器。」。

筆者〈從 Pentium 回顧 x86 處理器到底哪裡難做〉一文,分別從技術和商業角度,粗略分析 x86 指令集的弊病。雖然英特爾 1990 年代末期企圖推動全新 IA-64 指令集和 Itanium 處理器,以高階伺服器為起點,逐步向下滲透個人電腦市場,以實現「消滅 80x86」歷史大業,但那時也僅提到 64 位元的先天優勢與 x86 指令集暫存器太少的宿疾。英特爾這份定位成「提案」(Proposal)的 x86-S 技術白皮書,洋洋灑灑列出一大串看似遲來多年的改革項目,可視為「以身為 x86 指令集創造者的身分,願意公開承認的缺陷」,值得細細品味,這也是複習計算機概論的好機會。

「節區」記憶體管理和無謂的保護權限

80386 提供分頁表(Paging)虛擬記憶體之前, 記憶體保護是採「節區」(Segmentation)定址記憶體管理模式,作業系統需隨時改變節區暫存器內容,以存取散亂於記憶體各處的資料,基本上屬於「記憶體容量像黃金珍貴,必須錙銖必較」的歷史遺跡,今天沒什麼好批評,但也成為英特爾 x86-S 拿掉 16 位元後,首當其衝的動刀對象。

80386 以後,近代 x86 作業系統基於改善效能及「程式設計者不需為配置記憶體傷腦筋」,全面採用「平面記憶體定址模型」(Flat Memory Model),架空節區暫存器,將基底值(Base)統統設為 0,毋須改變內容,只靠一個來自 32 位元暫存器的偏移值(Offset)即可標定 4GB 虛擬定址空間任何一處。如 PAE/PSE-36 這種邁向 64 位元前的 36 位元定址(64GB)過渡期解決方案,在此不論。

x86-S 將記憶體管理限制在分頁(Paging,四層或五層分頁表)模式,對節區支援度精簡到「相容 32 位元應用程式」的最低限度。將虛擬記憶體位址從 x86-64 的 48 位元(256TB)四層式分頁表延伸至 57 位元(128PB)五層式分頁表(5-Level Paging),首度現身「Ice Lake」微架構,但切換到此模式前,需先轉換到未啟動分頁狀態,x86-S 可直接從四層切換至五層。此外,x86-S 也砍掉現在軟體幾乎沒用到的 Ring 1 / 2 權限,以及像「Gate」(不知「權限描述器」這翻譯是否精確?)之類的節區相關功能。

CPU 執行專屬指令的 I/O 存取

這也是屬於「記憶體容量屬於稀疏資源,加上盡其所能降低硬體成本」的時代眼淚。x86-S 取消「使用者模式(Ring 3)的 I/O 指令」與「區塊(String)搬移 I/O 指令」,直接否定「處理器驅動 I/O 模式」(CPU-driven I/O Model)的價值。

向古老 8259 中斷控制器說再見

不意外的是,決定處理器核心/執行緒上限的 APIC(先進可程式化中斷控制器),x86-S 捨棄老舊 8259 中斷控制器(PIC),僅支援最新 x2APIC。

x86-S 指令集沒有解決的疑難雜症

同時試圖丟棄 16 位元和 32 位元包袱的 x86 和 Arm,看似南轅北轍,卻有個有趣的共通點:指令集架構演化史,同樣繼承大量嵌入式(Embedded)應用遺產,這些都成為發展高效能微架構的障礙(你沒看錯,Arm AArch32 其實不怎麼乾淨,到 AArch64 才煥然一新)。過去丟掉 16 位元甚至 32 位元相容性的 x86 處理器,微架構究竟可「瘦身」到什麼程度,一直是高度假設性的大哉問,也許我們很快就會看到英特爾給世人的答案。

但回過頭來,相較真正 RISC 指令集架構,CISC x86-S 也沒有克服指令編碼長度與格式不固定、定址模式過於繁瑣等缺點,最起碼控制單元和快取記憶體還是比較難搞,AMD 制定 x86-64 時,也沒有選擇比較簡潔(如英特爾為了 AVX / AVX-512 新增的 VEX / EVEX Prefix)的擴充手段。

事後回顧本世紀初期爆發的 64 位元 x86 戰爭,支持 AMD 之外,微軟卻沒有主動跳出來主導「x64」規格,是滿可惜的事。總之,我們仍有充分理由相信,x86-S 指令集相容處理器還是「較 RISC 難做」的產品。

▲ 英特爾新增 AVX 指令集時,手段其實非常簡潔俐落,反觀 AMD x86-64 並沒有這麼漂亮,英特爾還被微軟硬逼不得不放棄自家「Yamhill」相容 AMD。

英特爾推動 x86-S 指令集的潛在商業風險

當「砍掉重練」的 Windows 12 作業系統,傳出 32 位元應用程式將經虛擬機器執行,英特爾又宣稱「預定兩年後誕生的 Lunar Lake(第 16 代 Core)將是能耗比超越 Apple Silicon 的全新產物」,筆者就心裡有譜:「英特爾大概私下跟微軟講好要幹啥大事了」,結果還真的歪打正著。

但軟體回溯相容性對某些真實世界的實際應用來說,依舊是重中之重關鍵,尤其還在跑大量老舊軟體的工控環境(到現在還有工業自動化產線在用 DOS)。所以當英特爾提出 x86-S 時,不乏「英特爾雙手奉上物聯網商機給 Arm 和 RISC-V 陣營」等觀點。照常理判斷,早就高度 64 位元化、虛擬化和容器化的資料中心伺服器,將是 x86-S 的出發點,之後個人電腦,最後才輪到嵌入式系統,這轉型過程涉及整個軟體生態系統,勢必曠日費時,不可能一蹴可及。

再來就是商業競爭現實,英特爾自廢武功 AVX-512 後就吃了大虧,將「最佳 x86 指令集相容性」桂冠平白送給 AMD Zen 4 世代產品線,除非 x86-S 證明能讓 x86 處理器效能和功耗有巨大飛躍性突破,或確實大幅縮短產品研發與驗證時程,加速推陳出新腳步,否則貿然放棄相容性,恐怕只會爽到老對手 AMD 和 DMP(源自 Rise mP6 的 Vortex86)等嵌入式 x86 處理器廠商。

▲ 新款 x86 處理器研發,因指令集架構高複雜度與缺乏標準,通常極度曠日費時,動輒四至五年實乃司空見慣,不僅嚴重限制同時開發多種市場定位不同產品的可能性,也嚴重傷害快速應付市場新興需求的敏捷度。英特爾這次提出 x86-S,最終目的多半還是想克服這個困擾(或也得算上 AMD)多年的老問題。

先不提藏在背後的動機,若現在英特爾依然手握半導體製程技術的領先優勢,還會「膽敢」拋出 x86-S 這顆風向球嗎?就有待各位慢慢思考了。

(首圖來源:Intel

立刻加入《科技新報》LINE 官方帳號,全方位科技產業新知一手掌握!

查看原始文章

更多科技相關文章

01

從 Microsoft 365 裝置碼釣魚攻擊,看企業資安治理盲點

科技新報
02

換補SIM卡竟要報案!NCC防詐新制挨批擾民

卡優新聞網
03

輝達Vera Rubin晶片全面量產 AI運算效能顯著提升

路透社
04

拉斯維加斯消費性電子展 英特爾發表次世代電腦晶片

路透社
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

留言 7

留言功能已停止提供服務。試試全新的「引用」功能來留下你的想法。

Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...