为什么 x86-32 架构没有在 x86-64 之前获得更多通用寄存器？

Question

x86-32 架构确实有 8 x 32 位通用寄存器。它们是 EAX、EBX、ECX、EDX、ESI、EDI、ESP 和 EBP。

但为什么直到 x86-64 架构出现之后这个数字才翻倍呢？

如果你看看从 i386 到 Pentium 4 的 32 位 CPU 和软件世界，那么在 32 位时代，软件不再支持较旧的 32 位 CPU，因为使用了一些功能，只有较新的 32 位 CPU 才能使用这些功能。 CPU确实有。因此，问题是为什么不简单地提前增加通用寄存器的数量呢？

难道是因为Intel想要推动安腾架构，因此对x86架构的更多GPR不感兴趣？如果是这样，为什么 AMD 在 2003 年推出 AMD64 之前没有自己尝试呢？

Answer 1

它需要一个主要的 ISA 扩展来为指令中的寄存器编号添加更多位（通过 REX 前缀），并且解码对于那个时代的 CPU 来说已经是一个大问题。（吞吐量瓶颈和位功耗。）Sandybridge 和 Zen 系列中的 Uop 缓存对此提供了很大帮助，但直到 2010 年才实现。（P4 的跟踪缓存在工作时也会有所帮助，但它很小并且是一个跟踪缓存导致其使用冗余。）

32 位模式完全超出了新前缀的操作码编码空间；VEX 和 EVEX 仅在 32 位模式下工作，因为现有指令的编码无效，并且这种程度的重载对于解码器来说可能更困难。

（但现在 CPU 确实分别支持 AVX 和 AVX-512 的 VEx 和 EVEX 前缀，它们可以将其用于 BMI1/2 等标量内容。在 64 位模式下，对于即将推出的APX 扩展，该扩展将 GPR 的数量增加一倍32 带有 REX2 和 EVEX 前缀，并给出现有整数指令的 3 操作数版本，例如xor.)

对于大多数操作系统来说，想要支持新的执行模式，更重要的是，支持新的 ABI 和另一个版本的库，只是为了获得大约 15% 的加速，这没有足够的吸引力。只有像更多地址空间这样的基本东西才真正证明在多架构系统方面进行大量短期努力是合理的。

inc r32AMD64 中的 REX 前缀重新利用了/的 1 字节编码dec r32。任何执行类似操作的模式都无法运行现有的 32 位代码，即为此模式编译的新代码无法调用现有的库，除非它使用包装器调用它们call far以切换到遗留代码段。（也许一些特殊的返回地址格式允许它们的普通近端ret返回到0x4?字节是REX前缀而不是inc/dec指令的模式？就像CPL = 3中设置的高位意味着它是一个特殊的返回地址？）通常远调用/ret是速度不快，但也许包括解码器在内的 CPU 可以支持在模式之间切换的一些特殊魔法。

因此，无论如何，它仍然会破坏与现有二进制库的兼容性，除非使用一些相当黑客的技巧，因此在您谈论的时代，如果不将寄存器扩展到 64 位，那么这样做将是非常愚蠢的。Intel PPro 在 1995 年支持 PAE 以获得更宽的物理地址，而无需更宽的虚拟地址，因为这只需要页表更改：只有内核需要知道这一点。到 90 年代末，4 GiB 物理 RAM 已经成为服务器的必需品，甚至家庭台式机也开始使用。

英特尔向 x86（SSE 和 SSE2）添加了 SIMD 扩展，但并不是像添加新 GPR 那样需要大量工具链和操作系统开发工作才能使用的主要新扩展。正如您所说，他们希望操作系统和编译器开发人员将时间花在安腾支持上，而不是 x86 的新模式上。

AMD64 是一种相当保守的设计，保留了许多x86的缺点，例如setcc r/m8仍然只写入寄存器的低字节，因此要获得int0 或 1，您需要在比较之前对目标进行异或清零。如果计数恰好为 0，奇怪的部分标志语义旋转和移位使它们保持不变。这些东西最大限度地减少了 AMD K8 和更高版本的 AMD CPU 中额外晶体管的数量，这些晶体管在大多数运行 32 位的家用计算机中会被浪费Windows，因为他们知道它不会在像 Windows 这样的二进制生态系统中迅速流行起来。从长远来看，编译器开发人员做一些额外的短期工作将使所有 x86-64 程序更加高效，但资本主义更倾向于短期考虑。

（英特尔同样犯了短视的设计选择，例如 SSE2cvtsi2sd xmm0, eax具有输出依赖性，因为它将新的低半部分合并到 16 字节 XMM0 中。因为这就是 SSE1 的做法cvtsi2ss，因为 PIII 只有 64 位宽的 SIMD执行单元，因此它节省了一个微指令，不必将高半部分写为零，这又是一个短期考虑；SSE2 版本只是保持一致，以损害乱序执行。但 SSE2 是新的P4，具有 128 位宽向量执行单元；写入向量的上半部分不会产生额外成本并避免输出依赖性。）