64位计算的历史相当丰富有趣。Cray等公司在70年代就已经开始在自己的系统当中使用64位寄存器，但真正纯粹的64位计算直到90年代才真正到来。 首先是MIPS的R4000，然后是DEC的Alpha处理器。到90年代中期，英特尔和Sun都已经拥有64位设计。而对于消费者来说，真正的转折点是 AMD在2003年发布了一款兼容英特尔32位x86处理器的64位PC处理器。
再 向前快进10年，PC销量不断下滑，大部分智能手机和平板电脑都拥有了主频在1-2GHz之间的多核心处理器。但它们使用的都是32位架构，而非现代PC 和服务器所使用的64位架构。到现在为止，这都是可以接受的。智能手机并不会去和PC拼性能，这些处理器需要足够节能，以实现续航的最大化。
但是，随着设备的发展和新技术——语音识别、3D游戏和高分辨率显示屏——逐渐普及，32位处理器的能力已经渐渐被推到了极限。
ARM 看到了64位节能处理器的需求，并在正式发布ARMv8-A架构（首个包含64位指令集的ARM架构）之前就早早开始了新设计的开发，还从其他选择发展 64位技术的芯片设计厂商那里学习到了经验和教训。ARM的新款64位架构具备对于旗下32位架构的全面兼容，这意味着如果处理器运行于64位系统，它就 可以运行未修改的ARMv7 32位二进制文件。对于Android来说，这意味着一旦内核被移植到64位（多亏了Linaro，它们已经如此了），系统的其余部分，从核心库到应用再 到游戏，都是可以在32位或64位之间进行切换的。
去年，苹果凭借着iPhone 5s的全新64位A7处理器震惊了整个移动领域。A7采用了苹果设计的ARMv8双核处理器，名为Cyclone。它使用了两个64KB L1缓存（供两个核心分别使用），一个1MB L2缓存（被两个核心所分享）和一个4MB L3缓存（为整个SoC所用）。苹果拥有ARM架构授权，这意味着它可以从头开始设计自己的处理器，但前提是这些处理器必须是ARM兼容的。ARM拥有一 套测试套件，用以检查这些处理器是否具备兼容性。
在未来几个月里，我们将会看到高通、联发科和三星纷纷推出自己的64位ARM处理器。再考虑到Android在64位化的努力，用不了多久我们就将看到运行于64位Android系统的64位设备了。但对于开发者和终端用户来说，64位处理器意味着什么呢？
受益于ARM的64位架构
每 一部CPU的中心都是一套寄存器，他们都是用以存储数字和地址的内部存储插槽。当执行复杂任务时，这些插槽会被反复使用。如果所有的寄存器都处于占用状 态，那么处理的唯一方式是将其中一个寄存器存储在内存当中，使用寄存器进行下一个任务，然后再从内存当中重新载入之前的值。对于人类来说，这一切都发生在 一瞬间。但对于处理器来说，这实际上是一个非常耗时的顺序，并不十分效率。
32位ARMv7架构拥有15个通用的寄存器，每一个都有32位 宽。而ARMv8架构拥有31个通用寄存器，每一个为64位宽。这就意味着优化代码使用内部寄存器的频率应该要比内存更高，同时也可以保留更大的数字和地 址。结果就是，ARM的64位处理器在运行速度上会更快一些。
在能效上面，64位寄存器的使用并不会提升功耗。在某些情况下，64位核心执行部分任务的速度会更快一些，由于运行时间的减少，这也就会使其显得比32位核心更加节能。
寻 址（Addressing）是64位处理器的另一个层面。在PC和服务器领域，32位的局限主要在可访问的内存上。如果你想要使用超过4GB的内存，就需 要使用64位处理器。因为可以使用大物理地址拓展（LPAE），某些ARMv7处理器能够使用超过4GB内存，所以严格来讲，内存的限制并不是ARM处理 器所遭遇的问题。由于LPAE的存在，Cortex-A15处理器能够处理1024GB内存，而64位的处理能力更是高达200万TB。因此在短时间内， 任何一部智能手机都不需要完整的64位寻址。追求永远都不会被用到的寻址空间是毫无意义的，因此ARMv8架构采用了48位寻址，这已经是256TB了。
虽 然没有什么程序或游戏会用到TB级别的内存，但在另一方面，这种寻址能力又非常重要。现代3D游戏通常都带有大量的资源，当拥有超过4GB的可访问空间 时，这些资源能够被更加轻松地进行内存映射。这样一来，游戏的运行速度会得到提升，并让直接访问游戏多媒体资源成为可能。
不只是智能手机和平板
ARM 上64位计算的好处并不仅限于智能手机和平板电脑。ARM的生态系统很广阔，他们的处理器也被许多不同类型的设备所使用。服务器市场是ARM处理器影响力 有限的一个领域。信息时代的发展让维持数据中心所消耗的能源持续快速增长，而任何能够降低能源使用的技术都是对于资金和自然资源的节省。除了节能之外，在 服务器当中使用64位ARM芯片还有其他的好处。这些服务器都会被动散热，这意味着你可以将它们集中在一起，而无需担心会发生过热的情况。这样一来，用于 散热上的花费也将有所降低。
至于服务器软件，Linux这样的操作系统已经是64位的了，其主线内核当中也已经加入了对于ARMv8的支持。这也就是说，制作运行于64位Linux、ARM处理器的服务器并不会很困难。
总结
多亏了ARM，64位的移动计算时代就要到来了。这些新的处理器不仅速度更快，还为移动平台开启了更多的可能性。
从32位向64位的迁移道路已经被铺就，无论是什么操作系统，开发者从32位进入64位都不会有任何意外。
在未来几个月里，ARM的合作伙伴都将推出Cortex-A53和Cortex-A57处理器。当中有的会采用双核或四核的标准配置，也有的会选择big.LITTLE配置。但有一点是肯定的，那就是这对于ARM和普通用户来说都是一个激动人心的时刻。
来源：Android Authority/腾讯数码
引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“七液”的评论
高级CPU上都有寄存器滑动窗口，内存自然也可以，再说好多64位处理器，寻址其实都不是64位的而是40，48位。引用来自“JerryLin”的评论
寻址总线大于32位情况下，地址用几个32位表示？引用来自“七液”的评论
EM64T-AMD64号称是64位可是只使用了44位的内存寻址。你觉得怎么表示？引用来自“PegasusCpp”的评论
坐等PC换ARM处理器引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“七液”的评论
高级CPU上都有寄存器滑动窗口，内存自然也可以，再说好多64位处理器，寻址其实都不是64位的而是40，48位。引用来自“JerryLin”的评论
寻址总线大于32位情况下，地址用几个32位表示？引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“七液”的评论
高级CPU上都有寄存器滑动窗口，内存自然也可以，再说好多64位处理器，寻址其实都不是64位的而是40，48位。引用来自“JerryLin”的评论
寻址总线大于32位情况下，地址用几个32位表示？引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“七液”的评论
内存寻址是可以扩展到64位，可是科学计算就没啥必要，比如32位的处理器也可以拥有更大的寄存器，比如64位CPU可以使用AVX-512位的寄存器，32位的自然也可以，没必要为了指令集而增加这玩意。ARM32也是有NEON指令集的。所以为了多媒体升级到64位是愚蠢的行为。。。虽然apple升级到了64位架构，但是讽刺的是iphone6还是1G物理内存。这有啥意义呀！！！
估计是为了以后ARM版的Mac系列做铺垫。至于现在商业宣传意义更大一点。
引用来自“eel”的评论
仅仅对这句话而言: "虽然apple升级到了64位架构，但是讽刺的是iphone6还是1G物理内存。这有啥意义呀！！！" 64位寻址空间是虚拟地址,和物理地址是两个概念.引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“七液”的评论
内存寻址是可以扩展到64位，可是科学计算就没啥必要，比如32位的处理器也可以拥有更大的寄存器，比如64位CPU可以使用AVX-512位的寄存器，32位的自然也可以，没必要为了指令集而增加这玩意。ARM32也是有NEON指令集的。所以为了多媒体升级到64位是愚蠢的行为。。。虽然apple升级到了64位架构，但是讽刺的是iphone6还是1G物理内存。这有啥意义呀！！！
估计是为了以后ARM版的Mac系列做铺垫。至于现在商业宣传意义更大一点。
引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“七液”的评论
高级CPU上都有寄存器滑动窗口，内存自然也可以，再说好多64位处理器，寻址其实都不是64位的而是40，48位。引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“young7”的评论
同问，16位的cpu就算再怎么分段寻址，它能利用的内存也不可能超过2^16=65535个字节引用来自“Greatim”的评论
当年16位CPU怎么支持1M内存的？16位按理最多支持64K啊。做法无法就是做两个16位表示一个大数据的能事了。把内存分成每16字节一个基地址。程序开始定位了一个基地址，之后基本上就是在64位内存里面操作，当然也可以访问超过16位的，只是周折一点，改变段寄存器，所以老的程序开发，指针都分短指针和长指针两种，长指针垮段了，短指针在本段。所以32位也可以做类似的处理，而且32位做这个也是够用了，很少有这个必要，一定用大于4G的“连续内存”。
当然64位一步到位更好，只是成本高，如果不是64位还有其他各种好处的话，估计32位也会走老路，要再过几年才用上64位。
引用来自“理工小强”的评论
是的 的确可以的 32位的确能支持超过4GB内存 只是比较麻烦 效率低引用来自“founder_1”的评论
要知道16位8086访问到1M内存，人家的数据线是16位，地址线是20位。如果地址线是16位再怎么分段寻址也访问不到1M。引用来自“young7”的评论
原来如此，学习了。ps：为何楼上不是会员都能发言？
引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
虽然apple升级到了64位架构，但是讽刺的是iphone6还是1G物理内存。这有啥意义呀！！！
估计是为了以后ARM版的Mac系列做铺垫。至于现在商业宣传意义更大一点。
引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“young7”的评论
同问，16位的cpu就算再怎么分段寻址，它能利用的内存也不可能超过2^16=65535个字节引用来自“Greatim”的评论
当年16位CPU怎么支持1M内存的？16位按理最多支持64K啊。做法无法就是做两个16位表示一个大数据的能事了。把内存分成每16字节一个基地址。程序开始定位了一个基地址，之后基本上就是在64位内存里面操作，当然也可以访问超过16位的，只是周折一点，改变段寄存器，所以老的程序开发，指针都分短指针和长指针两种，长指针垮段了，短指针在本段。所以32位也可以做类似的处理，而且32位做这个也是够用了，很少有这个必要，一定用大于4G的“连续内存”。
当然64位一步到位更好，只是成本高，如果不是64位还有其他各种好处的话，估计32位也会走老路，要再过几年才用上64位。
引用来自“理工小强”的评论
是的 的确可以的 32位的确能支持超过4GB内存 只是比较麻烦 效率低引用来自“founder_1”的评论
要知道16位8086访问到1M内存，人家的数据线是16位，地址线是20位。如果地址线是16位再怎么分段寻址也访问不到1M。ps：为何楼上不是会员都能发言？
引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“young7”的评论
同问，16位的cpu就算再怎么分段寻址，它能利用的内存也不可能超过2^16=65535个字节引用来自“Greatim”的评论
当年16位CPU怎么支持1M内存的？16位按理最多支持64K啊。做法无法就是做两个16位表示一个大数据的能事了。把内存分成每16字节一个基地址。程序开始定位了一个基地址，之后基本上就是在64位内存里面操作，当然也可以访问超过16位的，只是周折一点，改变段寄存器，所以老的程序开发，指针都分短指针和长指针两种，长指针垮段了，短指针在本段。所以32位也可以做类似的处理，而且32位做这个也是够用了，很少有这个必要，一定用大于4G的“连续内存”。
当然64位一步到位更好，只是成本高，如果不是64位还有其他各种好处的话，估计32位也会走老路，要再过几年才用上64位。
引用来自“理工小强”的评论
是的 的确可以的 32位的确能支持超过4GB内存 只是比较麻烦 效率低引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“young7”的评论
同问，16位的cpu就算再怎么分段寻址，它能利用的内存也不可能超过2^16=65535个字节引用来自“Greatim”的评论
当年16位CPU怎么支持1M内存的？16位按理最多支持64K啊。做法无法就是做两个16位表示一个大数据的能事了。把内存分成每16字节一个基地址。程序开始定位了一个基地址，之后基本上就是在64位内存里面操作，当然也可以访问超过16位的，只是周折一点，改变段寄存器，所以老的程序开发，指针都分短指针和长指针两种，长指针垮段了，短指针在本段。所以32位也可以做类似的处理，而且32位做这个也是够用了，很少有这个必要，一定用大于4G的“连续内存”。
当然64位一步到位更好，只是成本高，如果不是64位还有其他各种好处的话，估计32位也会走老路，要再过几年才用上64位。
引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“中山野鬼”的评论
别的不知道哦。ac3的解码代码，我用dsp写的汇编，包括核心的fft等等。cpu是公司自己开发的，24位，之所以用24位不用32位，是为了省面积便宜，哈，主控还用z80呢。够用就好，不用16位，如你说的，累加16位不够，不过25位浪费。哈。至于视频，c版本，dsp版本，编解码大多数标准都做过（内核）外部应用系统没做过。只做8bits精度，10bits,16bits的不玩，那是专业场合应用。哈。至于整除算法？能用查表的都用查表，内部解码我影响中没有直接除法（无论浮点，定点），哈。估计你说的是3d graph的处理吧。音视频不存在。引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“young7”的评论
同问，16位的cpu就算再怎么分段寻址，它能利用的内存也不可能超过2^16=65535个字节引用来自“Greatim”的评论
当年16位CPU怎么支持1M内存的？16位按理最多支持64K啊。做法无法就是做两个16位表示一个大数据的能事了。把内存分成每16字节一个基地址。程序开始定位了一个基地址，之后基本上就是在64位内存里面操作，当然也可以访问超过16位的，只是周折一点，改变段寄存器，所以老的程序开发，指针都分短指针和长指针两种，长指针垮段了，短指针在本段。所以32位也可以做类似的处理，而且32位做这个也是够用了，很少有这个必要，一定用大于4G的“连续内存”。
当然64位一步到位更好，只是成本高，如果不是64位还有其他各种好处的话，估计32位也会走老路，要再过几年才用上64位。
引用来自“中山野鬼”的评论
哈，不针对你的个人，只是你的两篇言论都有误区，所以集中讨论一下。我请教你个问题，地址总线只有32位，怎么寻址 4g以上的物理空间？你可以参考下20位总线和16位系统的故事。哈。引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“young7”的评论
同问，16位的cpu就算再怎么分段寻址，它能利用的内存也不可能超过2^16=65535个字节引用来自“Greatim”的评论
当年16位CPU怎么支持1M内存的？16位按理最多支持64K啊。做法无法就是做两个16位表示一个大数据的能事了。把内存分成每16字节一个基地址。程序开始定位了一个基地址，之后基本上就是在64位内存里面操作，当然也可以访问超过16位的，只是周折一点，改变段寄存器，所以老的程序开发，指针都分短指针和长指针两种，长指针垮段了，短指针在本段。所以32位也可以做类似的处理，而且32位做这个也是够用了，很少有这个必要，一定用大于4G的“连续内存”。
当然64位一步到位更好，只是成本高，如果不是64位还有其他各种好处的话，估计32位也会走老路，要再过几年才用上64位。
引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
27 ;//Input Arguments
28pSrc RN 0
29pDst RN 1
30step RN 2
31
32;//Local Variables
33Return RN 0
34;// Neon Registers
35
36X0 DN D0.S8
37X1 DN D1.S8
38X2 DN D2.S8
39X3 DN D3.S8
40X4 DN D4.S8
41X5 DN D5.S8
42X6 DN D6.S8
43X7 DN D7.S8
44
45 M_START omxVCCOMM_Copy16x16
46
47
48 VLD1 {X0,X1},[pSrc@128],step ;// Load 16 bytes from 16 byte aligned pSrc and pSrc=pSrc + step after loading
49 VLD1 {X2,X3},[pSrc@128],step
50 VLD1 {X4,X5},[pSrc@128],step
51 VLD1 {X6,X7},[pSrc@128],step
52
53 VST1 {X0,X1,X2,X3},[pDst@128]! ;// Store 32 bytes to 16 byte aligned pDst
54 VST1 {X4,X5,X6,X7},[pDst@128]!
55
引用来自“PegasusCpp”的评论
坐等PC换ARM处理器引用来自“Greatim”的评论
等PC能用Arm处理器，显卡估计就贵起来了，因为复杂运算都移到显卡上了。PC处理一条指令，Arm要处理很多条，更加没有MMX SSE等等流式处理。两者根本不是一个等级的，不要光看着频率说事。引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“young7”的评论
同问，16位的cpu就算再怎么分段寻址，它能利用的内存也不可能超过2^16=65535个字节所以32位也可以做类似的处理，而且32位做这个也是够用了，很少有这个必要，一定用大于4G的“连续内存”。
当然64位一步到位更好，只是成本高，如果不是64位还有其他各种好处的话，估计32位也会走老路，要再过几年才用上64位。
Linaro项目正在致力于让Linux设备更好地运行在ARM处理器上.
引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“JerryLin”的评论
32位怎么超4G内存分段寻址？引用来自“Greatim”的评论
乱扯，为什么就32位处理器不能用100个寄存器，超过4G内存为什么不能学16位系统那样分段寻址？都没说到重点。64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
引用来自“PegasusCpp”的评论
坐等PC换ARM处理器64位的提升，除了寻址超过4G之外。最重要的是多媒体数据处理的需要。我们知道多媒体的各种算法开始构想都是浮点原型，而快速算法一般都是改写成整除算法。但是32位整数可表示的数值范围比浮点差远了。必须降低计算过程中的精度。对于这点，64位的使用可以提高精度，直接效果就是音视频更清晰了。
另一点，多媒体有很多计算，利用到了整数累加，一个16位的音频，累加没多久就整数溢出，每次都要做溢出判断，而用64位，在大多数情况下，要处理的数据量是极有限的，完全可以假设数据不会溢出。所以计算速度得到质的提升。
第三点，时间的表示。为了表达精确的时间，很早开始，各系统就已经使用64位来表示时间，但是都是用两个32位来表示，CPU计算时间很麻烦。换成64位之后，关于时间的计算更快了。一般来说，这种计算也是多媒体用得最多。
记忆中，x64 对比 x32，大多数 benchmark 性能基本不变，极少数加密或者视频编码啥的大幅上升