深度分析64位元x86的應用環境

究竟64位元x86環境真的成熟了嗎？

隨著時代的演進，電腦從昔日的8位元，一路進展到今日主流的32位元，而64位元指令集，更早已行之有年，成為高階運算市場的主流。我們有充分的理由可以相信，正如同昔日32位元取代16位元，64位元運算取代32位元也只是時間的問題。

自從AMD發表x86-64指令集以及Opteron處理器，讓x86指令集正式進入了64位元的世界，英特爾也隨後推出EM64T指令集延伸架構及Nocona處理器。依照目前的趨勢，明年的中低階伺服器市場將充斥著這些64位元的x86處理器，也讓經費不足的企業，得到採用64位元應用環境的機會。64位元的定義及優勢

首先，我們先釐清最基本的觀念，一顆處理器所謂的位元數，其基本定義為整數邏輯運算（ALU）暫存器或著是指令指標（IP）暫存器的寬度。所以，以x86指令集為例，從386至今，相容i386指令集的處理器都是32位元。至於浮點運算暫存器，在一般的指令集設計中，都定義有別於上述兩者的獨立暫存器群，而且寬度往往遠遠超過整數暫存器，例如雙倍精確度的64位元、雙倍延伸精確度80位元、或著是針對SIMD設計的128位元等。所以，浮點暫存器的寬度，和多少位元並無任何關聯。

那麼，更高的位元數，會帶來怎樣的好處呢？首先，更長的暫存器，代表更多的資料量或數值範圍。另外，越大的暫存器檔案，配合程式上的最佳化，也越能降低記憶體頻寬不足的壓力。不過，對於今天大多數的運算，使用64位元整數的機會並不多，會用到的多半都是特殊的應用，例如資料庫、資料解壓縮、資料加密等等。

所以，目前64位元處理器比較明顯的優勢，就在於64位元的記憶體平面定址能力，擺脫32位元所造成的4GB虛擬定址空間限制。雖然，不少既有的32位元指令集，都有擴充實體定址空間的應急方案，例如英特爾的PSE/PAE-36延伸定址模式，透過36位元的實體定址線，以及載入不同的分頁表，使處理器可以定址到相當於36位元的64GB實體記憶體，微軟也為了PAE-36推出AWE（Addressing Window Extension）API。

不過，相較於64位元平面定址，這種方法非常的沒有效率，尤其像大型資料庫、或是Web伺服器，會經常發生不規則存取大範圍記憶體的程式行為，導致記憶體存取效率不彰，降低20%左右的整體效能屢見不鮮，這對伺服器應用上會造成很大的限制。今天，高階運算及伺服器市場幾乎都已被眾多64位元化的RISC處理器產品所主宰，並不是讓人感到意外的事實。

反過來說，對於伺服器及工作站應用，記憶體定址空間加大有著立竿見影的好處，成為企業迫切的需求實無可厚非。但是，對於一般的個人電腦用戶，將現有的32位元處理器升級至64位元，究竟有沒有這個必要？畢竟，目前的個人電腦，主記憶體距離4GB上限仍有一段不小的距離。如果要說服消費者購買64位元系統，必須使其感受到64位元所帶來的效能優勢，且可以延續現有32位元的軟體應用環境。更何況，除了浮點運算普遍擁有獨立的暫存器群，且今日眾多SIMD浮點指令集更普遍支援整數運算，這也降低了64位元指令集的優勢。32位元應用程式在64位元作業系統上的表現

往往企業在部署64位元系統時，這是一個經常被忽略的問題。由於32位元及64位元的記憶體定址模型（Memory Addressing Model）有所不同，在64位元作業系統上執行32位元應用程式，自然也會因為位址轉換之故（如將32位元虛擬位址對映至64位元虛擬位址之中），降低執行效能。這種情況，就很類似昔日Win16應用程式在Win32平臺上的狀況，以64位元Windows為例，也是採用WOW64（Windows On Windows 64）模擬層以實作對32位元應用程式的相容。

此外，值得注意的是，無論是何種64位元模式，除了既有的16位元及真實模式（Real Mode）應用程式外，像會真正對映記憶體位址的API、如前述的AWE，也都無法使用。雖然在今日這些應用程式已經少之又少，但企業在轉移至64位元之前，仍需注意是否繼續使用這些類型的應用程式，或著是透過虛擬機器來延續這些應用程式的壽命，以避免造成轉移上的困難。64位元x86指令集的軟體支援現狀

AMD x86-64的產品已經出現在市場上長達一年餘，但作業系統及應用軟體的支援程度依然相當不足，尤其在微軟Windows平臺上，除了今年二月發布AMD x86-64版本的Windows XP及Windows Server 2003測試版，以及8月19 日公開的英特爾EM64T測試版本外，一切付之闕如，支援x86-64的軟體仍以開放原始碼的Unix環境為主，像Linux和FreeBSD很早就推出x86-64的對應版本，MySQL等諸多開放原始碼的應用程式亦同。以開發環境而言，GCC、PathScale、PGI及NAG等都已經支援x86-64。Sun預定今年內推出的Solaris 10，也確定將會推出x86-64版本，將對x86-64的推廣有所助益。

不過，Windows平臺上的開發環境，才是決定64位元x86普及速度的關鍵因素。微軟也曾表示，如其延續舊有的32位元應用軟體，不如重新發展64位元版本才是正本清源之道。微軟預定同時支援英特爾EM64T和AMD x86-64的新版Visual Studio .NET「Whidbey」，預定明年上半年才會上市，而且可能會受到64位元x86版本Windows推出時程的影響而延後。此外，英特爾雖然將會推出支援EM64T的編譯器，但基於指令集上的差異性及市場策略考量，可能無法與AMD x86-64完全相容。隱而不現的是，英特爾的編譯器，無論在語法相容性、處理器最佳化及效能上，在業界均頗有盛名、首屈一指，這對AMD將造成相當程度的打擊。EM64T與x86-64之間的相容性問題，將會對軟體廠商造成相當程度的困擾。英特爾是否企圖干擾64位元x86的發展，進而確保IA-64指令集的生存，這就相當令人玩味了。

最後，支援64位元作業系統的硬體驅動程式，在今天仍屬少數，如果硬體設備廠商不儘快推出64位元化的驅動程式，就算有64位元的作業系統、開發環境及應用程式，依然英雄無用武之地。Bill Gates在WinHEC疾呼業界應盡速進行64位元驅動程式的開發，並不是沒有理由的。

萬事皆備，只欠Longhorn？

基於上述的諸多理由，64位元x86應用環境的成熟與普及，並不會如外界所想像的如此樂觀（尤其英特爾同時擁有兩條64位元處理器產品線）。整體而言，整個大環境要成熟，二至三年可能還是一個保守的估計。換言之，Longhorn推出之際，才是64位元x86應用環境開始成熟之時，這可能也是2006年以後的事情了。

人電腦市場，在32位元的386處理器推出後的十年，才出現第一個普及的32位元個人作業系統Windows95及殺手級應用程式Office。就算是很早就全面64位元化的高階Unix伺服器市場，至今依然也有不少32位元應用程式。雖然，我們有充分的理由相信，從32位元轉移至64位元，這是不變的長期趨勢，但64位元徹底取代32位元，也絕非一朝一夕之功。AMD x86-64與英特爾EM64T系統的相容性

雖然EM64T與x86-64乍看之下相當相似，但實際上兩套指令集仍有相當多的相異之處。首先，EM64T少了分頁表的NX（No Execute）位元（Prescott E-0核心才提供），以及較x86-64多出一個指令CMPXCHG16B：CMPXCHG8B的16位元版本。其次，系統呼叫以及浮點運算狀態的儲存/回覆指令所能執行的環境有所差別，Bit Scan指令（BSF/BSR）和近程分支（Near Branch）有著些微的差異，EM64T支援和32位元模式相同的微碼更新模式。除此之外，目前EM64T沒有支援AMD的3DNow!，而x86-64則沒有支援SSE3。

更大的麻煩在後面：目前英特爾的Nocona系統並未提供IO MMU（Memory Management Unit）功能，換言之，如果系統採用32位元定址的周邊IO裝置，這些裝置的DMA模式將無法使用到超過4GB以上的實體記憶體空間。唯一的解決方式，就是將這些IO的記憶體存取範圍限制在4GB以內，目前Red Hat Linux就是實作軟體IO TLB（Translation Look-aside Buffer）來修正，但這樣就會降低系統IO的效能，因為無法利用更大的記憶體空間作IO緩衝區之用。後來，Red Hat特別為EM64T推出專屬的Linux版本，微軟日前也另外發表支援EM64T的Windows XP及Windows Server 2003測試版，並且命名為「x64」版本。

在英特爾的官方說法以及技術文件中，從來就沒有保證過EM64T將會與x86-64相容。這些差異，所造成的後繼影響，以及英特爾背後的策略考量，將非常的值得觀察。文⊙劉人豪