Transmeta 的產品設計理念奠基於「讓軟體主導一切」，負責指令轉譯的 CMS（Code Morphing Software，代碼變形軟體）自然就是決定效能的成敗關鍵，這讓 Transmeta 的處理器看起來就像「黑盒子」，裡面怎麼亂搞，外頭都管不著。
軟體搞定一切的產品設計思維
CMS 既然本質是迷你作業系統，勢必占用部分系統主記憶體空間，存放在 Flash ROM 的 CMS 映像檔體積 1MB（共有兩份，一份用來當錯誤修復的備份），解壓縮後載入記憶體 1.7MB，加上相關的資料結構與轉譯快取（Translation Cache），總計吃掉 16MB 容量，後來的 Efficeon 則加倍到 32MB。看到主記憶體被咬掉一小塊，在 2000 年 128MB 記憶體還有點小貴的年代，其實讓人感到有點小小的心痛。
事實上，Transmeta CMS 有幾個少為人知的優點：
- 身為「軟體」的 CMS 可隨時改版，除了可持續最佳化提升效能表現，易於修正產品瑕疵，蘊含了支援「未來新增 x86 指令」的潛力，並可經由軟體調節效能與功率，迎合市場需求。
- 只要確保可正確相容 x86 指令集，CMS 怎樣無視 x86 指令集的種種先天限制（如精確中斷）胡搞瞎搞都無所謂，可放手一搏，用盡一切擠出效能的手段，例如「刪減真正被執行的指令數量」。
- 這是一般比較少人提到的優勢：各位只要想想看「使用 Word 長時間寫作、然後還用不到 Word 大多數功能」的場景即可理解，大多數人操作電腦的習慣，95% 以上時間集中使用極少數的應用程式與作業系統功能，真正動用到的指令碼比例經常低於 10%、甚至低到 1% 都有可能。
CMS 可持續反覆「精鍊」轉譯這極少量的指令碼，並利用有限的記憶體暫存區保存轉譯成果，使其「越跑越快」。這是傳統純硬體處理器不可能具備的特色（具有解碼後微指令快取記憶體的特殊案例，不在討論範圍）。
但如同硬幣的正反兩面，這也讓 Transmeta 的處理器，執行混合大量不同應用程式的效能基準工具（就是我們常講的 Benchmark）時，CMS 的轉譯工作將備多力分，會特別吃虧，這也是 Transmeta 難以擺脫的原罪。
軟體手段彈性無限大，所以 CMS 可施展各式各樣怪招，一點一滴榨出極限效能。
透過軟體達成的非循序執行
筆者大學時代在計算機中心打工兼任 News 伺服器管理員前，研究如何架設 nntp 時，在某篇鉅細靡遺的 BBS 文章開頭，看到一句「你最好先準備一杯熱茶或咖啡，我相信你一定需要它」，大概就是筆者當下對各位讀者的良心建議，雖然下面的內容遠不如 nntp 艱難，請安心服用。
以下是 4 個 x86 指令組成的執行序列。
轉譯成 RISC 型態的「載入回存」（Load and Store）底層硬體指令碼，先將記憶體載入至暫存器，再進行運算。運算元格式也從 x86 的雙運算元（A＋B＝A），轉為 RISC 風格的三運算元（A＋B＝C）。
為了方便說明，裡面沿用 x86 原始暫存器名稱，3 個運算指令的預設「預測執行條件碼」（.c）在這裡不必要，可忽略不看。
接著最佳化，既然 r30 和 r31 都載入相同的資料，那就沒必要做兩次，讓第二個加法指令沿用 r30 暫存器，減少暫存器使用量。
重新排序指令，把同時讀取 r30 暫存器的兩個加法指令往後排，先完成耗時的堆疊載入 r30 暫存器。不這樣做，第一個指令包的兩個加法指令，可能就會因等待堆疊資料載入 r30，導致管線停滯。
反應回 x86 指令序列，形同最後一個減法指令，被搬到最前面。
上期文章有提及的 Crusoe VLIW 指令編排方式和指令格式如下。因為是 VLIW，沒被 CMS 填入的「原子」就只能填入什麼都不做的 NOP（No-Operation）了。
再把 5 個「原子」（Atom）打包成兩個 VLIW「分子」（Molecule）指令包，一個蘿蔔一個坑的對應 4 個執行單元，透過軟體手段實現非循序指令執行，毋需複雜的硬體實作方式。
發生中斷例外，亦可快速回復到先前的執行狀態
前面的非循序指令執行看起來很厲害，卻也造成新問題：一旦發生中斷例外，該怎麼確保符合 x86 指令集的語意規範。
x86 指令集採取「精確中斷」（Precise Interrupt），若處理器發生中斷（如外部 I/O 發出需求）或例外（像發生分頁錯誤），在「標定下一個被執行指令的記憶體位址」的程式計數器（Program Counter，PC）前面的所有指令，都將執行完畢，後面的指令則不可執行。
我們回到前面的 x86 指令序列。
假如第三個指令造成分頁錯誤（Page Fault，軟體試圖存取已對映在虛擬位址空間中，但是目前並未被載入在實體記憶體中的分頁），第四個指令根本就不該被執行，但經過 CMS 轉譯最佳化，已經被「先斬後奏」，這就不是純軟體手段即可輕鬆處理的大麻煩了。
因此 Transmeta 在既有的工作用（Working）暫存器檔案外，預備了透過 CMS 軟體控制的「影子（Shadow）暫存器」，也就是專利權的「Official Register」，存放「實際 x86 執行狀態」，等同「指令轉譯過程中，從頭到尾都沒發生任何例外，確定沒有問題，可被交付（Commit）版本」的暫存器資料。一出亂子，就用影子暫存器的「備份檔案」，將工作暫存器的內容整批回滾（Rollback）到先前的狀態，再重新轉譯 x86 指令並執行。
換言之，Crusoe 的暫存器總量非常驚人：112 整數（64 工作＋48 影子）與 48 浮點（32 工作＋16 影子）。
當發生「真正 x86 狀態的中斷例外」，關卡式記憶體回存緩衝區（Gated Store Buffer）僅清除尚未確認交付（Uncommitted）指令的資料，已交付（Committed）者仍依序寫回記憶體，無需整個砍掉重練。對 1998 年那份專利權還保有印象的話，想必不陌生。
可亡羊補牢的記憶體預測載入機制
這就是 1998 年那份 Transmeta 專利權名稱的主角，可見舉足輕重的重要性。無論任何處理器架構體系，盡其所能設法「提前」從記憶體載入資料到暫存器，早已是兵家必爭的關鍵性技術。
2006 年，英特爾的「救世主」Merom 微架構，就靠「記憶體位址相依性消歧」（Memory Disambiguation）這招，一舉扭轉 x86 處理器對 AMD K8 的性能劣勢。但平心而論，任何形式的「預測執行」，無不是潛在的資訊安全漏洞。我們也只能悲觀預期，英特爾和 AMD 的近代 x86 處理器，安全性臭蟲恐怕是永遠修不完了。
身為近代多工作業系統技術基礎的虛擬記憶體，把位址空間重新定義為「連續的虛擬記憶體位址」，藉此「欺騙」程式，使它們以為自己正在使用一大塊「連續」位址。而實際上，通常是分隔成多個實體記憶體碎片，還有部分暫時儲存在外部磁碟機，需要時資料交換（Swap）。說到虛擬記憶體的分頁表（Page Table），Crusoe 處理器內建轉譯位元緩衝區（T-Bit Buffer），追蹤需被 CMS 重新轉譯的分頁。
作業系統與應用程式眼中的「虛擬記憶體位址」和實際的「實體記憶體位址」，之間的對應關係不見得是一對一，往往虛擬記憶體空間遠數倍於實體記憶體容量，有可能產生兩個不同的虛擬位址、卻指向相同實體位址的「記憶體別名」（Alias）問題。
載入指令會從快取記憶體或主記憶體讀取資料，通常比較耗時，對效能的負面影響也比回存大的多，應盡早處理，CMS 可賭博性的「假設」載入（Load）的實體記憶體位址，和前面的回存（Store）彼此互不衝突（後面載入暫存器的記憶體資料，有可能是前面回存記憶體的資料），提前執行載入指令。
這裡先假定 [%x] 和 [%y] 的實體記憶體位址不同，CMS 交換指令順序。
但畢竟依然存在實體位址衝突的風險，Transmeta 為此追加專用硬體功能單元，協助偵測記憶體別名。一旦將載入移動到回存之前，CMS 也須更替為特殊版本的保護式載入（ldp，Load-and-Protect，額外記錄實體位址與資料載入量）與附帶檢查的回存（stam，Store-after-Alias-Mask，追加安全區域檢查）指令，提醒處理器「這是有風險的指令排序，須啟動相對應的保護機制」，當不幸「中獎」觸發例外後，亦可重新來過。
如果各位一頭霧水，可參考英特爾 IA-64 的「資料預測載入機制」（Speculative Load）。編譯器將載入指令（ld）搬移到前面，換成專用版本（ld.a）。
透過檢查指令（ld.c或chk.a）比對「預先載入位址表」（ALAT，Advanced Load Address Table）記錄的記憶體位址、資料區塊長度、目標暫存器與資料載入狀態。如確定發生衝突，就重新執行回復碼（Recovery Code），以確保載入資料的正確性。
這技術亦可應用在削減指令數量。假設先 [%x] 和 [%y] 沒有對衝，[%x] 將不會 [%y] 更動，就不必重複載入 [%x] 了，減少指令數和暫存器消耗，並縮短浪費在載入記憶體資料的時間。
兩邊一起執行，再挑選正確的結果
條件分支（Conditional Branch）一向是處理器管線化的殺手，尤其對 VLIW 處理器，分支造成的傷害特別嚴重，一卡住就是一整包指令塞車，極力減少分支數量，以提高管線效率，實乃重中之重。
身為他山之石的俄國人 Elbrus 2K 處理器，可選擇性分支預測執行，不必猜測到底是那條路徑，反正兩條指令流統統跑下去，確定條件結果，再保留正確的那一邊。與 Elbrus 略有淵源的 Transmeta 亦不遑多讓，耗盡極為貧弱的執行單元，換取管線一路暢通，亦在所不惜。
這段由 20 個 x86 指令組成的執行序列，是 Transmeta 官方技術白皮書的「集大成」範例，用上所有前述技巧，將其轉換成 10 個 VLIW「分子」指令包。
但各位別被這串「有字天書」嚇傻了，這裡面最值得注意的是，原本 x86 指令串的兩個內部條件分支，換成「從兩個結果中挑出一個」的路徑選擇（Select）指令，兩條指令流都轉譯並執行，變相徹底消除條件分支，利於指令管線化，即使代價高昂。
抄襲 IBM 的嫌疑，依舊揮之不去
在歷史上，我們經常可看到，來自不同地方的技術研發團隊，在某個特定「歷史節點」，採取殊途同歸的方向，如 1960 年代因微碼而蓬勃發展的 CISC、1980 年代因反動而突然崛起的 RISC，或 1990 年代前期想逃避複雜硬體的 VLIW 風潮。
英特爾 Pentium Pro 總工程師之一的 Robert Colwell，在回憶錄《The Pentium Chronicles》就對當時外界盛傳英特爾抄襲 Alpha 處理器、英特爾高層還願意花錢消災，付大筆專利金給 DEC 這件事深感不滿，直言「像非循序指令執行（Tomasulo 演算法）的概念與應用，早在 1967 年就存在了，並不是全新產物」。
同樣的情境也發生在 Transmeta。身為 IBM 在 1986 年 VLIW 處理器研究計畫的分支，在 1990 年代初期開始的 DAISY（Dynamically Architected Instruction Set from Yorktown，英文簡寫的意思是「雛菊」）動態編譯器技術，在 2000 年 10 月正式開源──剛剛好就是 IBM 宣布取消 Crusoe 處理器 ThinkPad 的時刻──接著在某些技術社群就引起軒然大波。
DAISY 與後繼的 BOA（The Binary-translation Optimized Architecture），將 PowerPC 指令碼轉譯成另一種 VLIW 處理器指令集，除此之外，Transmeta 的諸多技術特點，「似乎」在 DAISY 統統看得到，簡直是同一個模子刻出來的，唯一的明顯差別，只有把 x86 換成 PowerPC 而已。在 Transmeta 還存活的幾年內，不少國外技術社群網站的討論區，充滿了信誓旦旦「Transmeta 剽竊 IBM」的指控。
同場加映：在 2004 年，也是 Linus Torvalds 離開 Transmeta 之後，也有人試圖證實 Linux 作業系統抄襲 Minix（作者是大名鼎鼎的 Andrew Tanenbaum，資訊科班學生很難不讀到他的著作），但 Andrew Tanenbaum 本人很大方的否認了。
事隔多年，直到俄國人真的做出來 Elbrus 2K 處理器和相似的動態轉譯技術，才讓人恍然大悟：這些東西的技術源頭，都可追溯於 1980 年代，而且還不見得都出自美國人之手。看在 Transmeta 創辦人 David Ditzel 和那票俄國人打過交道的份上，Transmeta 受 Elbrus 團隊的影響，搞不好還比 IBM 稍微大一點。
況且 IBM 的研究目的和 Transmeta 截然不同，IBM 想透過軟體模擬，讓 Power 取代 S/360 體系 CISC 大型主機這件事，在業界早就不是祕密了。不限於 PowerPC，S/390 和 Java 也是 DAISY/BOA 計畫的相容對象。
此外，IBM 著重在指令平行化，光轉譯器就會啃掉超過 100MB 的記憶體容量，Transmeta 則是專注於電源效率，CMS 大不了就 32MB 擺平。硬說這是抄襲，實在有點牽強。但 IBM 曾公開表示「我們有注意到兩邊很像」，他們私下怎麼看待 Transmeta，外人不得而知，但可以肯定的是，IBM 絕對很清楚 Transmeta 的底細和能耐，也許這也是讓 IBM 放棄 Crusoe 的原因之一。
千萬不要以為 IBM 公司這麼大，負責 ThinkPad 研發的日本人，不會知道地球另一端部門的觀點和看法，只要出現內部詢問，不甘寂寞的研究部門，怎麼可能放棄彰顯自身價值、秀出「存在感」的大好機會？當然，我們也有充分理由相信，英特爾的「道德勸說」和威脅利誘，才是最重要的主因。
總而言之，只能說 Linus Torvalds 這個人名氣太大，加上 2000 年 11 月那場轟動股票市場的 IPO 大戲，讓 Transmeta 樹大招風。不過，揮之不去的抄襲謠言並不致命，對 Transmeta 和客戶來說，最重要的課題，莫過於以 CMS 為靈魂的 x86 處理器，能否落實 Transmeta 當初承諾的願景。更重要的是：能讓公司和投資人「發大財」。
但初代 Crusoe 上市後接連數年的市場發展歷程，血淋淋證明 Transmeta 的「網際網路世代軟體思維」，終究敵不過摩爾定律預言的電晶體數量成長曲線，再多「技術天才」，也無力抵抗英特爾和 AMD 的「研發大軍」，這真的是時代的悲劇。
（首圖來源：pixabay）
"技術" - Google 新聞
May 02, 2020 at 11:16AM
https://ift.tt/2ymyyrk
時代的眼淚》低功耗救世主的世紀末傳說Transmeta：技術核心的代碼變形（中） - 科技新報 TechNews
"技術" - Google 新聞
https://ift.tt/2vdsyzX
Shoes Man Tutorial
Pos News Update
Meme Update
Korean Entertainment News
Japan News Update
Bagikan Berita Ini
0 Response to "時代的眼淚》低功耗救世主的世紀末傳說Transmeta：技術核心的代碼變形（中） - 科技新報 TechNews"
Post a Comment