64位元

title: 架构影响.
content: 处理器中的暂存器通常可分为三种:整数、浮点数、其它。在所有常见的主流处理器中,只有整数暂存器(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位元宽的浮点数暂存器。
title: 内存限制.
content: "内存的大小是依据可寻址的内存元件大小而变,例如 16位元位址总线其寻址能力有 2的 16次方 = 65,536 = 64 KB 的内存空间,而 32位元位址总线其寻址能力有 2的 32次方 = 4,294,967,296 = 4 GB的内存空间"  然而在1990年初,成本不断降低的内存,使安装的内存数量逼近4 GB,且在处理某些类型的问题时,可以想像虚拟内存的使用空间将超过4 GB上限。为此,一些公司开始释出新的64位元架构芯片家族,最初是提供给超级电脑、顶级工作站和服务器机器。64位元运算逐渐流向个人电脑,在2003年,某些型号的苹果公司Macintosh产生线转向PowerPC 970处理器(苹果公司称为「G5」),并在2006年,转向EM64T处理器,且x86-64处理器在顶级的PC中遂渐普及。64位元架构的出现,有效的将内存上限提升至2位址,相当于1844多京或16 EB的内存。从这个角度来看,在4 MB主内存很普遍时,最大的内存上限2的位址大约是一般安装内存的1000倍。如今,当1 GB的主内存很普遍时,2的位址上限大约是1百亿倍。  今天市面上大部分的消费级PC存在着人为的内存限制,因受限于实体上的限制,而几乎不太可能需要完整支援16 EB容量。举例来说,Apple的Mac Pro最多可安装实体内存至128 GB,而无必要支援超过的大小。最新的Linux核心(版本3.11.2)可编译成最高支援64 GB的内存。
title: 32与64位元.
content: 从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)。「客户端」编译器(C1)产生较慢的代码,不过编译较快速。所以尽管在64位元JVM的Java程序在一段很长的周期会执行的较好(一般为长时间运作的「服务器」应用程序),它的启动时间可能更久。对于短生命期的应用程序(如Java编译器javac)增加启动时间可控制执行时间,使64位元的JVM整体变慢。  应当指出,在比较32位元和64位元处理器时,速度并不是唯一的考量因素。应用程序,如多工、应力测试(stress testing)、丛集(clustering,用于HPC)可能更适合64位元架构以正确部署。为了以上原因,64位元丛集已广泛部署于大型组织,如IBM、Vodafone、HP、微软。
title: 优缺点.
content: 一个常见的误解是:除非电脑安装的内存大于4GB,否则64位元架构不会比32位元架构好。这不完全正确:  64位元架构主要的缺点是,相对于32位元架构,占用相同的资料会消秏更多的内存空间(由于肿涨的指标,以及其它型态和对齐补白等可能)。这会增加行程对内存的需求,且可能会影响高效能处理器快取的使用。解决方法之一是维持一部分32位元模型,且大致合理有效。高效能导向的z/OS操作系统便采取这个方法,要求程序代码存放在32位元位址空间的任一数字,资料物件则可(选择性)存放在64位元区域。  目前主要的商业软件是建立在32位元代码,而非64位元代码,所以不能取得在64位元处理器上较大的64位元位址空间,或较宽的64位元暂存器和资料路径的优点。然而,免费或自由软件操作系统的使用者已经可以使用专有的64位元运算环境。并非所有的应用程序都需要大量的位址空间或操作64位元资料项,所以这些程序不会享受到较大的位址空间或较宽的暂存器和资料路径的好处;主要受益于64位元版本的应用程序,并不会享受到使用x86的版本,会有更多的暂存器可以使用。
title: 软件的可用性.
content: 64位元系统往往缺乏对应的软件,多数软件均按32位元架构编写。最严重的问题是不相容的驱动程序。尽管32位元相容模式(又称作模拟模式,即微软WoW64技术)可执行大部分软件,但通常无法执行驱动程序(或类似软件),因为驱动程序通常在操作系统和硬件之间执行,无法使用直接模拟。许多开放源始码软件封包可简单的从源始码编译为可执行于64位元环境操作系统,如Linux。所需的条件是供给64位元机器的编译器(通常是gcc)。  因为装置的驱动程序通常执行于操作系统核心(Kernel)的内部,有可能以32位元行程执行核心,同时支援64位元的使用者行程。以在核心里的额外消耗为代价,如此可为使用者提供受益于64位元的内存和效能,且不破坏现存32位元驱动程序的二进制相容性。这个机制源于OS X启用64位元行程,同时支援32位元的驱动程序。  大多数32位元软件都在新的64位元操作系统上执行,但是防毒软件会有相容性问题。
title: 64位元资料模型.
content: 以高阶语言编写的应用软件,从32位元架构转换到64位元架构的各种困难。一个共同的问题是,部分程序员假定指标如同其它资料型态一样有相同的长度。程序员假定他们可以在资料型态之间传送数量而不遗失资讯。这些假定只在一部分32位元机器上如此(甚至是一部分16位元机器),不过在64位元机器上就不再如此。C语言及其后代C++尤其容易产生这种错误 。  要在C和C++中避免这种错误,如果确定原始类型的大小为所需的基础,codice_1运算子可用来确定原始类型的大小,无论是在编译以及执行时期。此外,在C99标准中的<limits.h>表头,以及在C++标准中的<limits>表头的numeric_limits类别,可提供更多有用的资讯;sizeof只返回字符大小。这个用法使人产生误解,因为一个字符(codice_2)的大小是由自身决定,在所有的C或C++实作中并未以相同方式定义。然而,除了这些编译器目标DSP以外,「64位元 = 8字符(每一字符有8位元)」已成标准。  必须谨慎使用codice_3型态(在标准表头codice_4中)两个指标相减的结果;太多代码宁可不正确的使用「int」或「long」。表示一个指标(而不是指标差异)为一个整数,在此可以使用codice_5(它只定义在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。
title: 目前的64位元微处理器架构.
content: 属于64位元的微处理器架构(2006年)有: 大部分64位元处理器架构可原生执行32位元版本架构的代码,而无任何效能损失。这种支援通常称为双架构支援或更普遍的多架构支援。
title: 超越64位元.
content: 直至2007年,64位元字组似乎已满足大部分的运用。不过仍应提到,IBM的System/370及后继者使用128位元浮点数,且许多现代处理器也内含128位元浮点数暂存器。System/370及后继者尤其显著,在这方面,他们也使用多达16字节的可变长度十进制数(即128位元)。
title: 影像.
content: 在数码影像中,64位元为附有16位元Alpha通道的48位元影像。

Summary: 64位元CPU是指CPU内部的通用暂存器的宽度为64位元,支持整数的64比特宽度的算术与逻辑运算。早在1960年代,64位架构便已存在于当时的超级电脑,且早在1990年代,就有以RISC为基础的工作站和服务器。2003年才以x86-64和64位元PowerPC处理器架构的形式引入到(在此之前是32位元)个人电脑领域的主流。

64-Bit-Architektur: Unter 64-Bit-Architektur versteht man in der EDV eine Prozessorarchitektur, deren Verarbeitungsbreite 64 Bit beträgt. Durch 64 Bit große Adressregister sind solche Prozessoren in der Lage, einzelnen Prozessen größere (nicht segmentierte) Adressräume als 4 GByte zur Verfügung zu stellen.