64位元

64位元CPU是指CPU內部的通用暫存器的寬度為64位元，支援整數的64-{zh-hans:位元; zh-hant:位元}-寬度的算術與邏輯運算。原理解釋.一個CPU，聯絡外部的資料匯流排與位址匯流排，可能有不同的寬度；術語「64位元」也常用於描述這些匯流排的大小。例如，目前有許多機器有著使用64位元匯流排的32位元處理器的整數型資料。處理器中的暫存器通常可分為三種：整數、浮點數、其它。在所有常見的主流處理器中，只有整數暫存器。非整數暫存器不能存放指標來讀寫記憶體，因此不能用來避開任何受到整數暫存器大小所影響的記憶體限制。幾乎所有常見的主流處理器。與之相較，64位元Alpha系列處理器，除了32個64位元寬整數暫存器以外，也定義了32個64位元寬的浮點數暫存器。上限.理論上限.64位元最大的記憶體上限是“16EB”，即“1677萬7216TB”、“171億7986萬9184GB”。既使是目前世界最大的記憶體，其容量也遠遠低於這個上限，故64位元在現實世界中可暫時視做為無限大。記憶體的大小的演算法是“2的XX次方”，例如16位元位的記憶體上限是“2的16次方”即65536=64KB，而32位元為“2的32次方”即4,294,967,296B=4GB，以此類推而64位元就是“2的64次方”即17179869184GB=16777216TB=16384PB=16EB。超越64位元.64位元的上限足足有171億GB，這已經完全滿足了個人所能用到的全部儲存量；不過仍應提到，直至2007年IBM的System/370及後繼者使用128位元浮點數，且許多現代處理器也內含128位元浮點數暫存器；System/370及後繼者尤其顯著，在這方面，他們也使用多達16位元組的可變長度十進位制數。歷史發展.概述.早在1960年代，64位架構便已存在於當時的超級電腦，且早在1990年代，就有以RISC為基礎的工作站和伺服器。2003年才以x86-64和64位元PowerPC處理器架構的形式引入到個人電腦領域的主流。目前大部分的CPU中可用的位址取決於暫存器的寬度。自1960年的IBM System/360起，然後1970年的 DEC VAX微型電腦，以及1980年中期的Intel 80386，在事實上一致開發合用的32位元大小的暫存器。32位元暫存器意味著232的位址，或可使用4 GB的記憶體。當時在設計這些架構時，4GB的記憶體遠遠超過一般所安裝的可用量，而認為已足夠用於定址。認為4GB位址為合適的大小，還有其它重要的理由：在應用程式中，如資料庫，42億多的整數已足夠對大部分可計算的實體分配唯一的參考引用。然而在1990年初，成本不斷降低的記憶體，使安裝的記憶體數量逼近4GB，且在處理某些型別的問題時，可以想像虛擬記憶體的使用空間將超過4GB上限。而64位元系統的記憶體上限非常高，因此一些公司開始釋出新的64位元架構晶片家族，最初是提供給超級電腦、頂級工作站和伺服器機器。64位元運算逐漸流向個人電腦，在2003年，某些型號的蘋果公司Macintosh產生線轉向PowerPC 970處理器，並在2006年，轉向EM64T處理器，且x86-64處理器在頂級的PC中遂漸普及。64位元架構的出現，有效的將記憶體上限提升至264位址，相當於1844多京或16 EB的記憶體。從這個角度來看，在4 MB主記憶體很普遍時，最大的記憶體上限232的位址大約是一般安裝記憶體的1000倍。如今，當1GB的主記憶體很普遍時，264的位址上限大約是1百億倍。今天市面上大部分的消費級PC存在著人為的記憶體限制，因受限於實體上的限制，而幾乎不太可能需要用到16EB的容量。舉例來說，Apple的Mac Pro最多可安裝實體記憶體至128GB，而無必要支援超過的大小。最新的Linux核心可編譯成最高支援64GB的記憶體。32位元過渡至64位元.32位元與64位元的區別.從32位元到64位元架構的改變是一個根本的改變，因為大多數作業系統必須進行全面性修改，以取得新架構的優點。其它軟體也必須進行移植，以使用新的效能；較舊的軟體一般可藉由硬體相容模式。支援64位元架構的作業系統，一般同時支援32位元和64位元的應用程式。明顯的例外是AS/400，其軟體執行在虛擬的指令集架構，稱為TIMI。64位元架構無疑可應用在需要處理大量資料的應用程式，如數位視訊、科學運算、和早期的大型資料庫。在其它工作方面，其32位元相容模式是否會快過同等級的32位元系統，這部分已有很多爭論。在x86-64架構中，主要的32位元作業系統和應用程式，可平滑的執行於64位元硬體上。Sun的64位元Java虛擬機器的啟動速度比32位元虛擬機器還慢，因為Sun仍假定所有的64位元機器都是伺服器，而且只有為64位元平臺實作「伺服器」編譯器增加啟動時間可控制執行時間，使64位元的JVM整體變慢。應當指出，在比較32位元和64位元處理器時，速度並不是唯一的考量因素。應用程式，如多工、應力測試可能更適合64位元架構以正確部署。為了以上原因，64位元叢集已廣泛部署於大型組織，如IBM、Vodafone、HP、微軟。32位元和64位元的優缺點.一個常見的誤解是：除非電腦安裝的記憶體大於4GB，否則64位元架構不會比32位元架構好。這不完全正確：64位元架構主要的缺點是，相對於32位元架構，佔用相同的資料會消秏更多的記憶體空間存放在64位元區域。目前主要的商業軟體是建立在32位元程式碼，而非64位元程式碼，所以不能取得在64位元處理器上較大的64位元位址空間，或較寬的64位元暫存器和資料路徑的優點。然而，免費或自由軟體作業系統的使用者已經可以使用專有的64位元運算環境。並非所有的應用程式都需要大量的位址空間或操作64位元資料項，所以這些程式不會享受到較大的位址空間或較寬的暫存器和資料路徑的好處；主要受益於64位元版本的應用程式，並不會享受到使用x86的版本，會有更多的暫存器可以使用。軟體的可用性.64位元系統往往缺乏對應的軟體，多數軟體均按32位元架構編寫。最嚴重的問題是不相容的驅動程式。儘管32位元相容模式。因為裝置的驅動程式通常執行於作業系統核心的內部，有可能以32位元行程執行核心，同時支援64位元的使用者行程。以在核心裡的額外消耗為代價，如此可為使用者提供受益於64位元的記憶體和效能，且不破壞現存32位元驅動程式的二進位制相容性。這個機制源於OS X啟用64位元行程，同時支援32位元的驅動程式。大多數32位元軟體都在新的64位元作業系統上執行，但是防毒軟體會有相容性問題。64位元資料模型.以高階語言編寫的應用軟體，從32位元架構轉換到64位元架構的各種困難。一個共同的問題是，部分程式員假定指標如同其它資料型態一樣有相同的長度。程式員假定它們可以在資料型態之間傳送數量而不遺失資訊。這些假定只在一部分32位元機器上如此 。要在C和C++中避免這種錯誤，如果確定原始型別的大小為所需的基礎，codice_1運運算元可用來確定原始型別的大小，無論是在編譯以及執行時期。此外，在C99標準中的表頭的numeric_limits類別，可提供更多有用的資訊；sizeof只返回字元大小。這個用法使人產生誤解，因為一個字元」已成標準。必須謹慎使用codice_3型態。C和C++並未定義指標、整數型為特定的位元數目。在主要的32位元機器程式設計環境中，指標、「int」變數、「long」變數全部都是32位元長。然而，在64位元機器下的許多程式設計環境，「int」變數仍然是32位元寬，不過「long」和指標是64位元寬，上述內容稱為LP64 資料模型。另一個選擇是ILP64資料模型，三種資料型態都是64位元寬，甚至SILP64連「short」變數也是64位元寬。然而，大多數情況下所需的修改是相對次要且簡單，而且許多編寫良好的程式可以簡單的重新編譯給新的環境，而無須修改。另一個選擇是LLP64模型，其維持32位元程式碼的相容性，使int和long為32位元。「LL」指「long long」型態，其在所有平臺下至少是64位元，包括32位元環境。今天有許多64位元編譯器使用LP64模型。微軟的VC++編譯器使用LLP64模型。其缺點是在LP64模型中將long存放到int可能會溢位。另一方面，還會使強制轉型一個指標為long可以作用；在LLP模型下，情況則剛好相反。兩者皆不應該出現在合乎C99的程式碼中。注意，程式設計模型是在預編譯器底層選擇的，且數個模型可共存於同一作業系統。然而一般由OS API選擇程式設計模型作為原始模型。另一個考量是用於驅動程式的資料模式。在現代的作業系統中，驅動程式彌補了大多數的作業系統程式碼。許多驅動程式大量使用指標操控資料，且在某些情況下必須讀入一定大小的指標進入支援DMA的硬體。舉個例子，提供給32位元PCI裝置的驅動程式，請求裝置的DMA資料進入64位元機器記憶體的較高區域，可能無法滿足來自作業系統從裝置到大於4 GB記憶體讀入資料的要求。因為對於這些位址的指標，將不適合裝置的DMA暫存器。這個問題可如下解決，當向裝置發出DMA請求時，OS採用與裝置相符的記憶體限制，或者使用IOMMU。目前的64位元微處理器架構.屬於64位元的微處理器架構有：大部分64位元處理器架構可原生執行32位元版本架構的程式碼，而無任何效能損失。這種支援通常稱為雙架構支援或更普遍的多架構支援。影像.在數位影像中，64位元為附有16位元Alpha通道的48位元影像。本條目部分或全部內容出自以GFDL授權釋出的《自由線上電腦詞典》。