64位
架构影响
处理器中的寄存器通常可分为三种:整数、浮点数、其它。在所有常见的主流处理器中,只有整数寄存器(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位宽的浮点数寄存器。
内存限制
目前大部分的CPU(截至2005年),其单个寄存器可存放虚拟内存中任意数据的内存地址(本机)。因此,虚拟内存(电脑在程序的工作区域中所能保留的数据总量)中可用的地址取决于寄存器的宽度。自1960年的IBMSystem/360起,然后1970年的DECVAX微型电脑,以及1980年中期的Intel 80386,在 事实上 一致开发合用的32位大小的寄存器。32位寄存器意味着2 的地址,或可使用4GB的内存。当时在设计这些架构时,4 GB的内存远远超过一般所安装的可用量,而认为已足够用于定址。认为4 GB地址为合适的大小,还有其它重要的理由:在应用程序中,如数据库,42亿多的整数已足够对大部分可计算的实体分配唯一的参考引用。
以上是网络上最为流传对于32位CPU定址的错误描述。倘若为真,那么,16位的80286 CPU定址能力不就只有2^16=65535 bytes = 64KB? 决定可用内存的是“定址线”而不是“比特数”。
然而在1990年初,成本不断降低的内存,使安装的内存数量逼近4 GB,且在处理某些类型的问题时,可以想像虚拟内存的使用空间将超过4 GB上限。为此,一些公司开始发布新的64位架构芯片家族,最初是提供给超级电脑、顶级工作站和服务器机器。64位运算逐渐流向个人电脑,在2003年,某些型号的苹果公司Macintosh产生线转向PowerPC 970处理器(苹果公司称为“G5”),并在2006年,转向EM64T处理器,且x86-64处理器在顶级的PC中遂渐普及。64位架构的出现,有效的将内存上限提升至2 地址,相当于1844多京或16EB的内存。从这个角度来看,在4 MB主存很普遍时,最大的内存上限2 的地址大约是一般安装内存的1000倍。如今,当1 GB的主存很普遍时,2 的地址上限大约是1百亿倍。
今天市面上大部分的消费级PC存在着人为的内存限制,因受限于实体上的限制,而几乎不太可能需要完整支持16 EB容量。举例来说,Apple的Mac Pro最多可安装物理内存至128 GB,而无必要支持超过的大小。最新的Linux核心(版本3.11.2)可编译成最高支持64 GB的内存。
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)。 “客户端”编译器(C1)产生较慢的代码,不过编译较快速。所以尽管在64位JVM的Java程序在一段很长的周期会运行的较好(一般为长时间运作的“服务器”应用程序),它的引导时间可能更久。对于短生命期的应用程序(如Java编译器javac)增加引导时间可控制运行时间,使64位的JVM整体变慢。
应当指出,在比较32位和64位处理器时,速度并不是唯一的考量因素。应用程序,如多任务、应力测试(stress testing)、簇(clustering,用于HPC)可能更适合64位架构以正确部署。为了以上原因,64位簇已广泛部署于大型组织,如IBM、Vodafone、HP、微软。
优缺点
一个常见的误解是:除非电脑安装的内存大于4 GB,否则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标准中的 表头,以及在C++标准中的 表头的numeric_limits类别,可提供更多有用的信息;sizeof只返回字符大小。这个用法使人产生误解,因为一个字符( CHAR_BITS )的大小是由自身决定,在所有的C或C++实现中并未以相同方式定义。然而,除了这些编译器目标DSP以外,“64位 = 8字符(每一字符有8位)”已成标准。
必须谨慎使用 ptrdiff_t 类型(在标准表头 中)两个指针相减的结果;太多代码宁可不正确的使用“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位处理器时间表
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位微处理器,作为MIPSRISC架构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发布OpenVMSAlpha 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,主打顶级服务器。它无法满足人们的期待,因一再拖延IA-64市场而导致失败。Linux是第一个可运行于该处理器的操作系统。
2002年:Intel引入Itanium 2作为Itanium的继承者。
2003年:AMD产出他的AMD64架构Opteron以及Athlon 64处理器产品线。苹果也推出了64位“G5”PowerPC 970 CPU courtesy ofIBM,并连同升级他的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处理器。
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引入他的第一个双核心AMD64Opteron服务器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和IntelXserve电脑中采用64位EM64TXeon处理器,稍后更新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位的微处理器架构(2006年)有:
DEC Alpha架构(查看Digital Alpha timeline)
Intel的IA-64架构(用于Intel的ItaniumCPU)
x86-64架构,64位版本的x86架构(又称作“x64”)
SPARC架构(从SPARC V9开始的64位)
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 family(从PA-RISC 2.0开始的64位)
ARMv8 Cortex-A50(包含A53, A57)架构,如Apple A7处理器
大部分64位处理器架构可原生运行32位版本架构的代码,而无任何性能损失。这种支持通常称为 双架构支持 或更普遍的 多架构支持 。
超越64位
直至2007年,64位字组似乎已满足大部分的运用。不过仍应提到,IBM的System/370及后继者使用128位浮点数,且许多现代处理器也内含128位浮点数寄存器。System/370及后继者尤其显著,在这方面,他们也使用多达16位组的可变长度十进制数(即128位)。
视频
在数字视频中,64位为附有16位Alpha通道的48位视频。
参见
主存
32位
32位应用程序
16位
16位应用程序
参考资料
x86和x64到底有什么差异?
64-bit的认定:通用寄存器宽度
本条目部分或全部内容出自以GFDL授权发布的《自由在线电脑词典》(FOLDOC)。
免责声明:以上内容版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。感谢每一位辛勤著写的作者,感谢每一位的分享。
- 有价值
- 一般般
- 没价值