64位元
 | 此條目需要补充更多来源。 (2020年5月6日) |
 | 此条目或章节需要時常更新。有關事物或許會隨著時間而有所變化。 |
| 微處理器 |
|---|
| 字 |
| 應用 |
| 二進制浮點精度 |
| 資料大小 |
在计算机体系结构中，64位是指整数、内存地址或其他数据单元的宽度是64位元。此外，64位中央处理器 (CPU) 和算术逻辑单元 (ALU) 是基于64位大小的寄存器、地址总线或数据总线的，支持整数的64比特宽度的算术与逻辑运算。使用这种处理器的计算机是64位计算机。
原理解釋
[编辑]一個CPU，联系外部的資料匯流排与位址匯流排，可能有不同的宽度；術語「64位元」也常用於描述這些匯流排的大小。例如，目前有許多機器有着使用64位元匯流排的32位元處理器（如最初的Pentium和之後的CPU，但Intel的32位CPU的地址总线宽度最大为36位），因此有時會被稱作「64位元」。同樣的，某些16位元處理器（如MC68000）指的是16/32位元處理器具有16位元的匯流排，不過內部也有一些32位元的性能。這一術語也可能指電腦指令集的指令長度，或其它的資料項（如常見的64位元雙精度浮點數）。去掉進一步的條件，「64位元」電腦架構一般具有64位元寬的整數型暫存器，它可支援（內部和外部兩者）64位元「區塊」（chunk）的整數型資料。
處理器中的暫存器通常可分為三種：整數、浮點數、其它。在所有常見的主流處理器中，只有整數暫存器（integer register）才可存放指標值（記憶體資料的位址）。非整數暫存器不能存放指標來讀寫記憶體，因此不能用來避開任何受到整數暫存器大小所影響的記憶體限制。
幾乎所有常見的主流處理器（大部分的ARM和32位元MIPS實作是明顯的例外）整合了浮點數硬體，它有可能使用64位元暫存器保存資料，以供處理。例如，x86架構包含了x87浮點數指令，並使用8個80位元暫存器構成堆疊結構。後來的x86修改版和x86-64架構，又加入SSE指令，它使用8個128位元寬的暫存器（在x86-64中有16個暫存器）。與之相較，64位元Alpha系列處理器，除了32個64位元寬整數暫存器以外，也定義了32個64位元寬的浮點數暫存器。
上限
[编辑]理論上限
[编辑]64位元最大的記憶體上限是“16 EiB”，即1677萬7216 TiB、或171億7986萬9184 GiB。即使是目前世界最大的內存，其容量也远远低于这个上限，故64位元在現實世界中可暫時視做為無限大。
記憶體的大小的算法是“2的XX次方”，例如16位元位的內存上限是“2的16次方”即65536=64 KiB，而32位元為“2的32次方”即4,294,967,296 B=4 GiB，以此類推而64位元就是“2的64次方”即17179869184 GiB=16777216 TiB=16384 PiB=16 EiB。
超越64位元
[编辑]64位元的上限足足有171億GiB，這已經完全滿足了個人所能用到的全部儲存量；不過仍應提到，直至2007年IBM的System/370及後繼者使用128位元浮點數，且許多現代處理器也內含128位元浮點數暫存器；System/370及後繼者尤其顯著，在這方面，他們也使用多達16位元組的可變長度十進制數（即128位元）。
歷史發展
[编辑]概述
[编辑]早在1960年代，64位架构便已存在於当时的超級電腦，且早在1990年代，就有以RISC為基礎的工作站和伺服器。2003年才以x86-64和64位元PowerPC處理器架構的形式引入到（在此之前是32位元）個人電腦領域的主流。
目前大部分的CPU（截至2005年），其單個暫存器可存放虛擬記憶體中任意資料的記憶體位址（本機）。因此，虛擬記憶體（電腦在程式的工作區域中所能保留的資料總量）中可用的位址取決於暫存器的寬度。自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處理器（苹果公司稱為「G5」），並在2006年，轉向EM64T處理器，且x86-64處理器在頂級的PC中遂漸普及。64位元架構的出現，有效的將記憶體上限提升至264位址，相當於1844多京或16 EB的記憶體。從這個角度來看，在4 MB主記憶體很普遍時，最大的記憶體上限232的位址大約是一般安裝記憶體的1000倍。如今，當1GB的主記憶體很普遍時，264的位址上限大約是1百億倍。
今天市面上大部分的消費級PC存在著人為的記憶體限制，因受限於實體上的限制，而幾乎不太可能需要用到16EB的容量。舉例來說，Apple的Mac Pro最多可安裝實體記憶體至128GB，而無必要支援超過的大小。最新的Linux核心（版本3.11.2）可編譯成最高支援64GB的記憶體。
64位元的大事件革沿
[编辑]- 1961年：IBM發表IBM 7030 Stretch 超級電腦。它使用64位元資料字組，以及32或64位元的指令字組。
- 1974年：Control Data Corporation推出CDC Star-100向量超級電腦，它使用64位元字組架構（先前的CDC系統是以60位元架構為基礎）。
- 1976年：Cray Research發表第一台Cray-1超級電腦。它以64位元字組架構為基礎，它成為後來的Cray向量超級電腦的基礎。
- 1983年：Elxsi推出Elxsi 6400平行微型超級電腦。Elxsi架構具有64位元資料暫存器，不過位址空間仍是32位元。
- 1991年：MIPS科技公司生產第一台64位元微處理器，作為MIPS RISC架構R4000的第三次修訂版本。該款CPU使用於以IRIS Crimson啟動的SGI圖形工作站。然而，IRIX 作業系統並未包含對R4000的64位元支援，直到1996年釋出IRIX 6.2為止。Kendall Square Research發表他們的第一台KSR1超級電腦，以專有的執行於OSF/1的64位元RISC處理器架構為基礎。
- 1992年：Digital Equipment Corporation（DEC）引入純64位元Alpha架構，其誕生自PRISM專案。
- 1993年：DEC釋出64位元OSF/1 AXP 類Unix作業系統（後來改名為Tru64 UNIX）和OpenVMS作業系統給Alpha系統。
- 1994年：Intel宣布64位元IA-64架構的進度表（與HP共同開發）作為其32位元IA-32處理器的繼承者。以1998–1999推出時間為目標。SGI釋出IRIX 6.0，即支援64位元的R8000 CPU。
- 1995年：Sun推出64位元SPARC處理器UltraSPARC。富士通所有的HAL電腦系統推出以64位元CPU為基礎的工作站，HAL獨立設計的第一代SPARC64。IBM釋出64位元AS/400系統，能夠轉換作業系統、資料庫、應用程式的升級。DEC釋出OpenVMS Alpha 7.0，第一個全64位元版本的OpenVMS for Alpha。
- 1996年：HP釋出PA-RISC處理器架構的64位元2.0版本的實作PA-8000。任天堂引入Nintendo 64電視遊戲主機，以低成本的MIPS R4000變體所打造。
- 1997年：IBM釋出RS64全64位元PowerPC處理器。
- 1998年：IBM釋出POWER3全64位元PowerPC/POWER處理器。Sun釋出Solaris 7，以完整支援64位元UltraSPARC。
- 1999年：Intel釋出IA-64架構的指令集。AMD首次公開64位元集以擴充給IA-32，稱為x86-64（後來改名為AMD64）。
- 2000年：IBM推出他自己的第一個相容ESA/390的64位元大型電腦zSeries z900，以及新的z/OS作業系統。緊接著是64位元Linux on zSeries。
- 2001年：Intel推出64位元處理器產品線，標記為Itanium，主打頂級伺服器。但因價錢太高(Itanium 9560價錢約為4650美金)，因一再拖延IA-64市場而導致失敗。Linux是第一個可執行於該處理器的作業系統。
- 2002年：Intel引入Itanium 2作為Itanium的繼承者。
- 2003年：AMD產出他的AMD64架構Opteron以及Athlon 64處理器產品線。苹果也推出了64位元「G5」PowerPC 970 CPU courtesy of IBM，並連同升級他的Mac OS X作業系統，其增加對64位元模式的部分支援。若干Linux 發行版本釋出對AMD64的支援。微軟宣布將為AMD晶片建立新的Windows作業系統。Intel堅持Itanium晶片仍維持只有64位元的處理器。
- 2004年：Intel承認AMD在市場上的成功，並著手開發AMD64延伸的替代品，稱為IA-32e，稍後改名為EM64T。升級版本的Xeon和Pentium 4處理器家族支援了新推出的指令。Freescale宣布64位元e700 core，以繼承PowerPC G4系列。VIA Technologies宣布64位元的Isaiah處理器。[1]
- 2005年：Sun於1月31日釋出支援AMD64和EM64T處理器的Solaris 10。3月，Intel宣布他的第一個雙核心EM64T處理器Pentium Extreme Edition 840和新的Pentium D晶片將於2005第二季推出。4月30日，微軟公開釋出提供給AMD64和EM64T處理器的Windows XP Professional x64 Edition。5月，AMD引入他的第一個雙核心AMD64 Opteron伺服器CPU，並宣布其桌上型版本，稱為Athlon 64 X2。將原本的Athlon 64 X2（Toledo）處理器改為兩個核心，並為每個核心的L2配上1 MB快取記憶體，以大約2.332億個電晶體組成。它有199 mm²那麼大。7月，IBM宣布他最新的雙核心64位元PowerPC 970MP（codenamed Antares），由IBM和Apple使用。微軟釋出Xbox 360遊戲主機，其使用由IBM生產的64位元、三核心Xenon PowerPC處理器。
- 2006年：雙核心Montecito Itanium 2處理器進入生產。Sony、IBM、Toshiba開始生產用於PlayStation 3、伺服器、工作站以及其它應用的64位元Cell處理器。蘋果公司在新的Mac Pro和Intel Xserve電腦中採用64位元EM64T Xeon處理器，稍後更新iMac、MacBook、MacBook Pro使用EM64T Core 2處理器。
- 2013年：Apple推出世界上第一款64位智能手机iPhone 5s，采用ARM架构A7处理器；同年晚些时候，Apple推出iPad Air，采用同款处理器，将64位处理器带入移动设备。
- 2014年：HTC推出世界上第一款以Android系統的64位元處理器手機HTC Desire 820
64位操作系统
[编辑]64位操作系统是指特别为64位架构计算机系统而设计的操作系统。
64位操作系统的优点，在于能够利用64位处理器的优势，在处理多媒体内容时能够有更佳的表现，可以存取4GB以上的內存。
64位操作系统最早在中小型计算机上实现，主要是一些Unix系统，以及RISC平台。此后英特尔和惠普公司合作研制的Itanium 64位处理器（Itanium採用特有的IA-64架構，與x86-64不相容）推出后，出现了此平台上的64位Linux及微软Windows操作系统（即基于IA-64的Windows XP 64位版）。之后AMD推出了64位的x86-64（AMD將其稱為AMD64，隨後英特爾也採用該架構但曾一度把它命名為EM64T等等，x86-64的優點是能良好的相容32位元應用軟件和32位元作業系統）架构CPU，很快就在Linux平台得到支持，并且微软也提供了x86-64版本的Windows XP操作系统（全称Windows XP Professional x64 Edition），使得Itanium处理器日渐势微，最後Itanium只用於伺服器。最終英特尔決定推出與AMD之前推出的AMD64相容的64位CPU，称为Intel 64、EMT64、EM64T等。Apple切换到英特尔平台后也开始开发64位操作系统。早期的解决方案十分古怪：如Mac OS X Tiger和Mac OS X Leopard以32位系统为核心，支持程序以64位模式运行，导致实际执行效率并不高。而后期的系统趋于完善，如Mac OS X Snow Leopard和更新的系统本身已于64位模式运行，可运行64位程序，也可以用兼容模式运行32位程序。
32位元過渡至64位元
[编辑]32位元與64位元的區別
[编辑]從32位元到64位元架構的改變是一個根本的改變，因為大多數作業系統必須進行全面性修改，以取得新架構的優點。其它軟體也必須進行移植，以使用新的性能；較舊的軟體一般可藉由硬體相容模式（新的處理器支援較舊的32位元版本指令集）或軟體模擬進行支援。或者直接在64位元處理器裡面實作32位元處理器核心（如同Intel的Itanium處理器，其內含有x86處理器核心，用來執行32位元x86應用程式）。支援64位元架構的作業系統，一般同時支援32位元和64位元的應用程式。
明顯的例外是AS/400，其軟體執行在虛擬的指令集架構，稱為TIMI（技術獨立機器界面），它會在執行之前，以低階軟體轉換成原生機器碼。低階軟體必須全部重寫，以搬移整個OS以及所有的軟體到新的平台。例如，當IBM轉移較舊的32/48位元「IMPI」指令集到64位元PowerPC（IMPI完全不像32位元PowerPC，所以這比從32位元版本的指令集轉移到相同指令集的64位元版本的規模還要龐大）。
64位元架構無疑可應用在需要處理大量資料的應用程式，如數位視訊、科學運算、和早期的大型資料庫。在其它工作方面，其32位元相容模式是否會快過同等級的32位元系統，這部分已有很多爭論。在x86-64架構（AMD64和Intel 64）中，主要的32位元作業系統和應用程式，可平滑的執行於64位元硬體上。
Sun的64位元Java虛擬機的啟動速度比32位元虛擬機還慢，因為Sun仍假定所有的64位元機器都是伺服器，而且只有為64位元平台實作「伺服器」編譯器（C2）。[2]「客戶端」編譯器（C1）產生較慢的代碼，不過編譯較快速。所以儘管在64位元JVM的Java程式在一段很長的週期會執行的較好（一般為長時間運作的「伺服器」應用程式），它的啟動時間可能更久。對於短生命期的應用程式（如Java編譯器javac）增加啟動時間可控制執行時間，使64位元的JVM整體變慢。
應當指出，在比較32位元和64位元處理器時，速度並不是唯一的考量因素。應用程式，如多工、應力測試（stress testing）、叢集（clustering，用於HPC）可能更適合64位元架構以正確部署。為了以上原因，64位元叢集已廣泛部署於大型組織，如IBM、Vodafone、HP、微軟。
32位元和64位元的優缺點
[编辑]一個常見的誤解是：除非電腦安裝的記憶體大於4GB，否則64位元架構不會比32位元架構好。這不完全正確：
- 部分作業系統保留了一部分行程位址空間供作業系統使用，減少使用者程式可用於映射記憶體的位址空間。例如，Windows XP DLL以及userland OS元件映射到每一個行程的位址空間，即使電腦裝有4 GB的記憶體，也僅剩下2至3.8 GB（端視其設定）的可用位址空間。這個限制在64位元Windows中不會出現。
- 檔案的記憶體映射不再適合32位元架構，尤其是相對便宜的DVD燒錄技術的引入。大於4 GB的檔案不再罕見，如此大的檔案無法簡單的映射到32位元架構的記憶體，只能映射檔案的一部分範圍到位址空間，並以記憶體映射存取檔案。當有需要時，就必須將這些範圍映射進或映射出位址空間。這是一個問題，因為充裕的記憶體映射仍是從磁碟至記憶體最有效率的存取方法，如果作業系統能適當實行的話。
64位元架構主要的缺點是，相對於32位元架構，佔用相同的資料會消秏更多的記憶體空間（由於腫漲的指標，以及其它型態和對齊補白等可能）。這會增加行程對記憶體的需求，且可能會影響高效能處理器快取的使用。解決方法之一是維持一部分32位元模型，且大致合理有效。高效能導向的z/OS作業系統便採取這個方法，要求程式代碼存放在32位元位址空間的任一數字，資料物件則可（選擇性）存放在64位元區域。
目前主要的商業軟體是建立在32位元代碼，而非64位元代碼，所以不能取得在64位元處理器上較大的64位元位址空間，或較寬的64位元暫存器和資料路徑的優點。然而，免費或自由軟體作業系統的使用者已經可以使用專有的64位元運算環境。並非所有的應用程式都需要大量的位址空間或操作64位元資料項，所以這些程式不會享受到較大的位址空間或較寬的暫存器和資料路徑的好處；主要受益於64位元版本的應用程式，並不會享受到使用x86的版本，會有更多的暫存器可以使用。
軟體的可用性
[编辑]64位元系統往往缺乏對應的軟體，多數軟體均按32位元架構編寫。最嚴重的問題是不相容的驅動程式。儘管32位元相容模式（又稱作模擬模式，即微軟WoW64技術）可執行大部分軟體，但通常無法執行驅動程式（或類似軟體），因為驅動程式通常在作業系統和硬體之間執行，無法使用直接模擬。許多開放源始碼軟體封包可簡單的從源始碼編譯為可執行於64位元環境作業系統，如Linux。所需的條件是供給64位元機器的編譯器（通常是gcc）。
因為裝置的驅動程式通常執行於作業系統核心（Kernel）的內部，有可能以32位元行程執行核心，同時支援64位元的使用者行程。以在核心裡的額外消耗為代價，如此可為使用者提供受益於64位元的記憶體和效能，且不破壞現存32位元驅動程式的二進制相容性。這個機制源於OS X啟用64位元行程，同時支援32位元的驅動程式。
大多數32位元軟件都在新的64位元作業系統上執行，但是防毒軟件會有相容性問題。
64位元資料模型
[编辑]以高階語言編寫的應用軟體，從32位元架構轉換到64位元架構的各種困難。一個共同的問題是，部分程式員假定指標如同其它資料型態一樣有相同的長度。程式員假定它們可以在資料型態之間傳送數量而不遺失資訊。這些假定只在一部分32位元機器上如此（甚至是一部分16位元機器），不過在64位元機器上就不再如此。C語言及其後代C++尤其容易產生這種錯誤[1]（页面存档备份，存于互联网档案馆） 。
要在C和C++中避免這種錯誤，如果確定原始類型的大小為所需的基礎，sizeof運算子可用來確定原始類型的大小，無論是在編譯以及執行時期。此外，在C99標準中的<limits.h>表頭，以及在C++標準中的<limits>表頭的numeric_limits類別，可提供更多有用的資訊；sizeof只返回字元大小。這個用法使人產生誤解，因為一個字元（CHAR_BITS）的大小是由自身決定，在所有的C或C++實作中並未以相同方式定義。然而，除了這些編譯器目標DSP以外，「64位元 = 8字元（每一字元有8位元）」已成標準。
必須謹慎使用ptrdiff_t型態（在標準表頭<stddef.h>中）兩個指標相減的結果；太多代碼寧可不正確的使用「int」或「long」。表示一個指標（而不是指標差異）為一個整數，在此可以使用uintptr_t（它只定義在C99中，不過某些編譯器另外整合較早版本的標準以提供之，作為一個擴充）。
C和C++並未定義指標、整數型（int）、長型（long）為特定的位元數目。
在主要的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模型（包括Solaris、AIX、HP、Linux、Mac OS X、IBM z/OS原生編譯器）。微軟的VC++編譯器使用LLP64模型。其缺點是在LP64模型中將long存放到int可能會溢出。另一方面，還會使強制轉型一個指標為long可以作用；在LLP模型下，情況則剛好相反。兩者皆不應該出現在合乎C99的代碼中。
注意，程式設計模型是在預編譯器底層選擇的，且數個模型可共存於同一作業系統。然而一般由OS API選擇程式設計模型作為原始模型。
另一個考量是用於驅動程式的資料模式。在現代的作業系統中，驅動程式彌補了大多數的作業系統代碼（儘管許多代碼可能不會載入，當作業系統執行時）。許多驅動程式大量使用指標操控資料，且在某些情況下必須讀入一定大小的指標進入支援DMA的硬體。舉個例子，提供給32位元PCI裝置的驅動程式，請求裝置的DMA資料進入64位元機器記憶體的較高區域，可能無法滿足來自作業系統從裝置到大於4 GB記憶體讀入資料的要求。因為對於這些位址的指標，將不適合裝置的DMA暫存器。這個問題可如下解決，當向裝置發出DMA請求時，OS採用與裝置相符的記憶體限制，或者使用IOMMU。
目前的64位元微處理器架構
[编辑]屬於64位元的微處理器架構（2006年）有：
- DEC Alpha架構（查看Digital Alpha timeline（页面存档备份，存于互联网档案馆））
- Intel的IA-64架構（用於Intel的Itanium CPU）
- x86-64架構，64位元版本的x86架構（又稱作「x64」）
- SPARC架構（從SPARC V9開始的64位元）
- Sun的UltraSPARC架構
- Fujitsu的SPARC64架構
- IBM的POWER架構（從POWER3和RS64變體開始的64位元）
- IBM/Motorola的PowerPC架構（從PowerPC 620和PowerPC 970變體開始的64位元）
- IBM的z/Architecture，used by IBM zSeries和System z9 大型電腦，ESA/390架構的64位元版本
- MIPS科技公司的MIPS IV、MIPS V、MIPS64 架構
- HP的PA-RISC（從PA-RISC 2.0開始的64位元）
- ARMv8 Cortex-A50（包含A53, A57）架構，如Apple A7處理器
大部分64位元處理器架構可原生執行32位元版本架構的代碼，而無任何效能損失。這種支援通常稱為雙架構支援或更普遍的多架構支援。
影像
[编辑]在數位影像中，64位元為附有16位元Alpha通道的48位元影像。
參見
[编辑]參考資料
[编辑]- ^ VIA Unveils Details of Next-Generation Isaiah Processor Core. VIA Technologies, Inc. [2007-07-18]. （原始内容存档于2007-10-11）.
- ^ Frequently Asked Questions About the Java HotSpot VM. Sun Microsystems, Inc. [2007-05-03]. （原始内容存档于2007-05-10）.
本條目部分或全部内容出自以GFDL授權發佈的《自由線上電腦詞典》（FOLDOC）。