2012-02-10 67 views
10

x86-64指令集增加了更多寄存器和其他改进以帮助简化可执行代码。但是,在许多应用中,增加的指针大小是一种负担。每个指针中额外的,未使用的字节堵塞了缓存,甚至可能导致RAM溢出。例如,GCC使用-m32标志建立,我认为这是原因。32位指针与x86-64 ISA:为什么不呢?

可以加载一个32位值并将其视为指针。这不需要额外的指令,只需加载/计算32位并从结果地址加载即可。但是,这个技巧不会便携,因为平台具有不同的内存映射。在Mac OS X上,整个地址空间的低4 GiB被保留。尽管如此,对于我写的一个程序,在使用与真正的64位地址相比更好的性能或者使用-m32进行编译之前,先将0x100000000L添加到32位“地址”中。

使用32位x86-64平台有什么根本障碍吗?我认为支持这样一个嵌合体会给任何操作系统增加复杂性,任何想要最后20%的人都应该只是让它工作,但它似乎仍然最适合各种计算密集型程序。

+0

大多数应用程序中的分析数据表明由于指针大小增加而没有显着的损失。 – Puppy 2012-02-10 19:09:02

+0

英特尔编译器有['Qauto-ilp32']选项(http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/copts/ccpp_options/option_qauto_ilp32 .htm)“尝试”使用32位指针 - 即使在x64模式下也是如此。 – Mysticial 2012-02-10 19:10:31

+0

@Mysticial,但更像是老式的“近”和“远”指针,对吧?我想这个解决方案是可以的,但它并不像我指的那么干净。 – Potatoswatter 2012-02-10 19:12:41

回答

10

在开发中有一个名为“x32”的linux版本。它是x86_64和ia32之间的混合,类似于您所描述的 - 使用完整64位寄存器集时的32位地址空间。它需要一个定制的内核,binutils和gcc。

某些SPEC运行表明某些基准测试的性能提高了约30%。在https://sites.google.com/site/x32abi/

+0

这真的是一个很好的信息。我对这个问题有些不确定,因为它的措辞可能排除了任何好的答案。但即使只有一个平台支持嵌合体,以防万一差异足够大,也会改变游戏场。 – Potatoswatter 2012-02-11 09:59:11

-4

它被称为“x86-32仿真”,或Windows上的WOW64(大概是其他操作系统上的其他东西),它是处理器中的硬件标志。这里不需要任何用户模式的技巧。

+0

这是一个用户可访问的标志吗?所以操作系统需要保存/恢复和支持它? – Potatoswatter 2012-02-10 19:11:35

+0

啊,查看它 - http://en.wikipedia.org/wiki/WOW64。不,这只是在64位操作系统上运行标准x86代码,即只有8个寄存器的旧ISA。和'-m32'一样。我不认为其他操作系统打扰给这个“功能”一个名字。 – Potatoswatter 2012-02-10 19:15:31

+0

@Patatoswatter:这与你所描述的完全不同,究竟是什么?处理器不是通过用户模式来实现目标,而是通过硬件实现。这总是会更快。没有编译器标志可以实现这一点,它是一个硬件处理器功能。 – Puppy 2012-02-10 19:17:16

0

查看更多信息我不指望它很难在操作系统中支持这样的模型。关于此模型中唯一需要更改的进程是页面管理,页面必须分配在4 GB点以下。如果内核将它们传递给应用程序,内核也应该从虚拟地址空间的前4个GB分配缓冲区。这同样适用于加载和启动应用程序的加载程序。除此之外,64位内核应该能够处理这种无重大修改的应用程序。

编译器支持不应该是一个大问题。这主要是生成代码的问题,可以使用额外的CPU寄存器及其全部64位,并在需要时添加适当的REX前缀。