Loading AI tools
来自维基百科,自由的百科全书
在计算机体系结构中,64位是指整数、内存地址或其他数据单元的宽度是64位元。此外,64位中央处理器 (CPU) 和算术逻辑单元 (ALU) 是基于64位大小的寄存器、地址总线或数据总线的,支持整数的64比特宽度的算术与逻辑运算。使用这种处理器的计算机是64位计算机。
此條目需要补充更多来源。 (2020年5月6日) |
此条目或章节需要時常更新。有關事物或許會隨著時間而有所變化。 |
一個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位元的上限足足有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位操作系统是指特别为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位元處理器核心(如同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、微軟。
一個常見的誤解是:除非電腦安裝的記憶體大於4GB,否則64位元架構不會比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位元架構的各種困難。一個共同的問題是,部分程式員假定指標如同其它資料型態一樣有相同的長度。程式員假定它們可以在資料型態之間傳送數量而不遺失資訊。這些假定只在一部分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位元的微處理器架構(2006年)有:
大部分64位元處理器架構可原生執行32位元版本架構的代碼,而無任何效能損失。這種支援通常稱為雙架構支援或更普遍的多架構支援。
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.