到底 CPU 的 64 位技術指的是什麼？64 位系統是否是指對此的支持？

---

支持64位技術的CPU是否是說，CPU的匯流排位寬為64比特？也就是每組可發送和接收的數據為64bit？如果不是的話，那麼請具體解釋一下，這裡的64位究竟是什麼意思。

並不能這麼說。根據上下文不同，對 bit width 的解釋不同。比如說，當年說 8088 是准 16 位，就是因為它的數據匯流排是 8 位。所以不要太糾結 64 位的「唯一」意義。在很多上下文中，64 位指「64 位連續地址空間」。

如果內存中有兩個位的地址是一樣的，難道不能通過其他手段來確認他們各自實際的身份嗎？

完全可以。x86 的 16 位模式（地址匯流排 20 位）就可以通過滑動窗口來完成高於 1M 的內存訪問。但是這裡有一個問題，控制滑動窗口的線路算不算「地址匯流排」？也就是說，從邏輯上說，有多少 distinguishable 的地址單元，就必須有多少「定址位寬」。至於這些「定址位寬」算不算「地址匯流排」，完全是個定義問題。再進一步，只有這些「定址位寬」統一管理，才是「連續地址空間」。否則就是更複雜的滑動窗口訪問，或者分段訪問。

那麼為什麼32位的Windows支持最多4G內存呢？

32 bit Windows 最多支持 4G 的「連續地址空間」。這和操作系統的初始化有關。x86 CPU 在某些模式下不支持 4G 以上的定址。

如果重新設計 32-bit Windows 可以支持高於 4G 內存嗎。可以，但是非常複雜。首先你必須用支持這種功能的 compiler，而這種 compiler 又有自己的困難，因為 C 語言的指針是一個 integeral 類型，所以 C 語言天然只支持「連續地址空間」。如果你要求一個 compiler 支持分段地址或者滑動窗口，就必須對 C 語言進行特殊擴展。有興趣你可以看看古老的 Turbo C 資料。在標準 C 之下，Turbo C 2.0 只能支持 64k 內存，因為 DOS 只能支持 64k 「連續地址空間」。沒有這樣的 compiler，那你只好編寫很多彙編代碼了。

當然，這是把問題 oversimplify 了。要在 32-bit Windows 上支持 4G 以上內存，還有很多細節問題。

64位的支持不僅需要硬體、系統，還需要應用軟體的支持。那麼這些應用軟體方面的支持，除了對處理器架構方面改進的支持外，相對於32位支持的軟體，主要是要對哪些問題做技術上的改進。

就如上文所說，在不同語境下，64 bit 可以指不同的東西。對於 x86 64 bit 來說，就拿編譯器來說，就有以下改進：

• 用 64-bit 整數來實現 64-bit 連續地址空間的 pointer。
• 充分使用 x86 64 新增的通用寄存器。

對於操作系統來說，需要：

• 支持 64-bit 的 application binary interface。比如，用 64-bit mode 下的指令重新實現 kernel trap（system call）。擴展 executable 文件格式，讓 global static 數據能充分利用 64-bit 連續地址空間。
• 提供支持 64-bit 連續地址空間的內存管理。在 32-bit 下，應用程序的 heap 和 stack 一般都是相對連續增長，在 64-bit 下必須採用有很多空洞的 sparse process space（注意 address space 和 process space 是有區別的）。

---

看到前面3個回答，我說下作為一個普通開發者，對64位的期待是什麼吧。

許多linux發行版為PC準備的版本是編譯為i386兼容的，也就是保證能運行在Intel 80386處理器上。

80386是Intel推出的第一款被人認為具有「32位處理器應該具有的特性」的處理器。

80386有一個問題……它不具備浮點數運算功能。浮點數運算功能雖然被80386支持，但是前提是你必須連上了80387處理器，它是一個浮點處理器，價格比80386還高。如果你在沒有安裝80387的系統上使用浮點運算指令，那麼會拋出一個異常。一般來說操作系統會捕獲這個異常，然後可能選擇終止程序或利用一個模擬運算庫來模擬80387的行為。

這是一個小例子，說明了處理器版本的問題。

如果你購買現在市面上的桌面級處理器，仍然有類似的問題，例如SSE4A和SSE4.1的差別。

而一個為普通用戶準備的程序，在沒有檢測的情況下直接應用SSE3的指令是一種冒失的做法。

Intel的x86處理器家族中，傳統的一個很嚴重的問題就是寄存器太少，這導致局部變數必須*全部*保存到棧上，而內存訪問、特別是在命中失敗的情況下性能損失很大。

而寄存器較多的處理器，例如MIPS和ARM，一般把局部變數保存在寄存器中，如果一個CC++的函數沒有緩衝區，那麼可能整個函數根本不需要去訪問內存，只有在調用子過程的時候需要保護一些寄存器時才把局部變數保存到棧上。

在IA32e或者長模式的64位模式下，Windows和Linux都一改之前非常依賴函數調用棧的情況，修改了調用約定（這主要依靠他們對編譯器的控制來實現，畢竟Linux下的GNU gcc編譯套件一統天下，而Windows下，微軟的VC++是主要的編譯工具）。對Windows來說，就算編譯自己的CC++函數時仍然墨守成規、至少在調用Windows API時必須改變了。

新模式下有了16個通用寄存器、MMX寄存器也成標配了、實際上多了不止一倍的寄存器。在x86-64 Windows的約定下，RBX、RBP、RDI、RSI、R12、R13、R14 和 R15都是子過程需要保留的、也就是說完全釋放出來可以存儲局部變數了，而前4個整數參數通過寄存器來訪問，多餘的參數才通過棧來傳遞。從前如果函數參數中有浮點數，函數要做的第一步就是把浮點數從棧上存入X87浮點堆棧中。如今，浮點數參數直接通過MMX寄存器傳遞。而Windows下（儘管從前MinGW就採用這種做法了），拋棄了32位時代Windows NT為兼容OS/2所設計的stdcall調用約定，函數調用的時候不需要為棧平衡指針了，也減少了內存訪問的需求。

簡單來說，由於新模式下不需要兼容舊代碼（舊的二進位代碼已經不能直接與64位代碼在同一進程合作了，它們只能在隔離開的進程運行），所以可以直接修改以前的陳舊的約定，一切為高性能服務。現在的這種改變下，函數調用的開銷已經被降到最低，這是64位代碼能比32位代碼跑的更快的決定性因素（這裡主要是對Windows程序來說的，因為為AMD64構架編譯的linux下文件描述符都變64位了，但x86-64的Windows下句柄仍然是32位的）。

========================

最後回到下樓主最關心的問題：為啥說是64位？

簡單說，因為寄存器，比如EAX,EBX,ECX,EDX,ESI,EDI,ESP,EBP,EIP,EFLAGS本來是32位的，全部升級了，變成了64位的RAX,RBX,RCX,RDX,RSI,RDI,RSP,RBP,RIP,RFLAGS幾個寄存器了。新增的8個通用寄存器也是64位的。而指令也支持64位的地址了（從前沒有這樣的指令，現在頁表項變大了才使得64位地址的設計成為了可能）

需要強調的是，這與匯流排、北橋或者內存控制器的設計沒有很直接的關係。從前奔騰Pro的時候匯流排就是以64位為單位存取了。

「（ 如果內存中有兩個位的地址是一樣的，難道不能通過其他手段來確認他們各自實際的身份嗎？ ）」

這個問題容易回答：因為微軟不希望它的代碼由於x86系列CPU而做太大的變動、它希望為所有平台維持一個代碼，而64位的內存地址就是一個唯一的方案了。舉例來說，Windows NT支持的第一款非x86的處理器，Alpha就是64位內存地址的。

不能用其他手段來確認身份嗎？當然可以，實際上Intel處理器的確有這個能力，被稱為內存分段。但微軟的聰明人不喜歡這個點子、而且我也認為他們是對的。

---

計算機體系結構學的不好，瞎扯一下... 如果說錯了請摺疊我...

我個人覺得64位處理器理解成通用寄存器是64bit比較合理...

現在的Intel處理器(我只知道XEON)已經不用地址匯流排數據匯流排了，內部是Ring Bus連接Core/Cache Agent/Home Agent(Memory Controller)/QPI Agent等等，處理器之間是Intel Quick Path Interconnect。上面走的都是事物消息。支持多大地址空間(就是原來的地址匯流排大小)沒太大關係了，最多是事物消息內帶的地址多幾位唄。而且現在就算是最高端的XEON E7系列，地址空間也才46位，最多支持2^46... (Intel: 要64位幹嘛嘛，你見多辣么多內存的嘛)

當處理器在Protect Mode下的時候(32位模式)，它能訪問的地址大小就是32位啊，不要問我為什麼。處理器邏輯就是這麼造的，我怎麼造為什麼... (#瞎說的# 給你的配置寄存器就辣么大，你寫個64位的地址沒處寫啊親，瞎寫分分鐘報個異常你信不信)

系統能帶多少內存取決於 「內存控制器能帶多少內存」 和 「處理器支持訪問多大地址空間」 里少的那個就好理解了嘛。32位模式下，一根8G的內存條妥妥的就可以撐爆CPU了... 64位模式下處理器妥妥的鄙視內存系統了，2^46，這得插多少內存才能爆...

---

推薦閱讀：