11

x86-64 指令集增加了更多寄存器和其他改进,以帮助简化可执行代码。然而,在许多应用程序中,增加的指针大小是一种负担。每个指针中多余的未使用字节会阻塞缓存,甚至可能溢出 RAM。例如,GCC 使用-m32标志构建,我认为这就是原因。

可以加载 32 位值并将其视为指针。这不需要额外的指令,只需加载/计算 32 位并从结果地址加载。然而,这个技巧不会是可移植的,因为平台有不同的内存映射。在 Mac OS X 上,保留整个低 4 GiB 地址空间。尽管如此,对于我编写的一个程序,在使用之前将其添加0x100000000L到 32 位“地址”中会大大超过真正的 64 位地址,或者使用-m32.

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

4

4 回答 4

11

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

一些 SPEC 运行表明在某些基准测试中性能提高了约 30%。在https://sites.google.com/site/x32abi/上查看更多信息

于 2012-02-11T00:19:10.677 回答
3

正如上面Mysticial 所评论的,ICC 有-auto-ilp32//Qauto-ilp32选项可以在 64 位模式下使用 32 位指针:

指示编译器分析程序以确定是否有 64 位指针可以安全地收缩为 32 位指针,以及是否有 64 位 long(在 Linux* 系统上)可以安全地收缩为 32 位 long .


在 Windows 上没有像 Linux 上那样的x32abi/LARGEADDRESSAWARE ,但您仍然可以通过禁用默认为 64 位二进制文​​件启用的标志来使用 32 位指针

默认情况下,基于 Microsoft Windows 的 64 位应用程序具有数 TB 的用户模式地址空间。有关精确值,请参阅Windows 和 Windows Server 版本的内存限制。但是,应用程序可以指定系统应为应用程序分配低于 2 GB 的所有内存。如果满足以下条件,则此功能对 64 位应用程序有益:

  • 2 GB 地址空间就足够了。
  • 该代码有许多指针截断警告。
  • 指针和整数可以自由混合。
  • 该代码具有使用 32 位数据类型的多态性。

所有指针仍然是 64 位指针,但系统确保每次内存分配都低于 2 GB 限制,因此如果应用程序截断指针,不会丢失任何重要数据。指针可以被截断为 32 位值,然后通过符号扩展零扩展扩展为 64 位值。

虚拟地址空间

当然,没有直接的编译器支持,因此每次存储指向内存的指针或取消引用它时都需要手动处理指针。最简单的解决方案是编写一个包装 32 位指针的类来处理它


Google 的 V8 引擎使用不同的方式将指针压缩为 32 位,以节省内存并提高性能。在此处查看内存和性能改进的比较

另请参阅V8 中的压缩指针实现与 JVM 的压缩 Oops 有何不同?


阅读更多

于 2020-10-23T16:38:00.247 回答
0

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

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

于 2012-02-11T02:09:36.713 回答
-5

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

于 2012-02-10T19:10:10.417 回答