x86-64 指令集增加了更多寄存器和其他改进，以帮助简化可执行代码。然而，在许多应用程序中，增加的指针大小是一种负担。每个指针中多余的未使用字节会阻塞缓存，甚至可能溢出 RAM。例如，GCC 使用-m32标志构建，我认为这就是原因。
可以加载 32 位值并将其视为指针。这不需要额外的指令，只需加载/计算 32 位并从结果地址加载。然而，这个技巧不会是可移植的，因为平台有不同的内存映射。在 Mac OS X 上，保留整个低 4 GiB 地址空间。尽管如此，对于我编写的一个程序，在使用之前将其添加0x100000000L到 32 位“地址”中会大大超过真正的 64 位地址，或者使用-m32.
拥有 32 位 x86-64 平台是否存在任何根本障碍？我想支持这样的嵌合体会增加任何操作系统的复杂性，任何想要最后 20% 的人都应该让它工作™，但它似乎仍然最适合各种计算密集型程序。
正在开发中的 linux 有一个名为“x32”的 ABI。它是 x86_64 和 ia32 之间的混合，类似于您所描述的 - 32 位地址空间，同时使用完整的 64 位寄存器集。它需要一个自定义内核、binutils 和 gcc。
一些 SPEC 运行表明在某些基准测试中性能提高了约 30%。在https://sites.google.com/site/x32abi/上查看更多信息
正如上面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 有何不同？
阅读更多
我不认为在操作系统中支持这样的模型非常困难。在此模型中，进程唯一需要更改的是页面管理，页面必须分配在 4 GB 点以下。如果内核将缓冲区传递给应用程序，它也应该从虚拟地址空间的前 4 GB 分配缓冲区。这同样适用于加载和启动应用程序的加载程序。除此之外，64 位内核应该能够处理此类应用程序而无需进行重大修改。
编译器支持也不应该是一个大问题。这主要是生成可以使用额外 CPU 寄存器及其完整 64 位的代码并在需要时添加适当的 REX 前缀的问题。
它在 Windows 上称为“x86-32 仿真”或 WOW64（可能在其他操作系统上是其他东西），它是处理器中的硬件标志。这里不需要任何用户模式技巧。