为什么 32 位寄存器上的 x86-64 指令会将完整 64 位寄存器的上部归零？

Question

在x86-64 Tour of Intel Manuals，我读到了

也许最令人惊讶的事实是，诸如MOV EAX, EBX 之类的指令会自动将RAX 寄存器的高32 位归零。

同一来源引用的英特尔文档（3.4.1.1 64 位模式中的通用寄存器在手册基本架构中）告诉我们：

• 64 位操作数在目标通用寄存器中生成 64 位结果。
• 32 位操作数生成 32 位结果，在目标通用寄存器中进行零扩展为 64 位结果。
• 8 位和 16 位操作数生成 8 位或 16 位结果。目标通用寄存器的高 56 位或 48 位（分别）不会被操作修改。如果 8 位或 16 位运算的结果用于 64 位地址计算，请将寄存器显式符号扩展为完整的 64 位。

在x86-32和x86-64汇编中，16位指令如

mov ax, bx

不要表现出这种eax的高位字归零的“奇怪”行为。

因此：引入这种行为的原因是什么？乍一看似乎不合逻辑（但原因可能是我习惯了 x86-32 汇编的怪癖）。

Answer 1

它只是节省了指令和指令集的空间。您可以使用现有（32 位）指令将小的立即数移动到 64 位寄存器。

当MOV EAX, 42 可以重复使用时，它还使您不必为MOV RAX, 42 编码8 字节值。

这种优化对于 8 位和 16 位操作并不重要（因为它们更小），并且更改那里的规则也会破坏旧代码。

Answer 2

我不是 AMD 或代表他们，但我会以同样的方式做。因为将高半部分归零不会产生对先前值的依赖，所以 CPU 将不得不等待。如果不这样做，register renaming 机制基本上会被击败。

通过这种方式，您可以在 64 位模式下使用 32 位值编写快速代码，而不必一直显式地破坏依赖关系。如果没有这种行为，64 位模式下的每条 32 位指令都必须等待之前发生的事情，即使几乎永远不会使用高位部分。 （使int 64 位会浪费缓存占用和内存带宽；x86-64 most efficiently supports 32 and 64-bit operand sizes）

8 位和 16 位操作数大小的行为很奇怪。依赖疯狂是现在避免使用 16 位指令的原因之一。 x86-64 从 8086 的 8 位和 386 的 16 位继承了这一点，并决定让 8 位和 16 位寄存器在 64 位模式下的工作方式与在 32 位模式下的工作方式相同。

---

另请参阅Why doesn't GCC use partial registers?，了解实际 CPU 如何处理对 8 位和 16 位部分寄存器的写入（以及随后对完整寄存器的读取）。

Answer 3

如果不将零扩展到 64 位，则意味着从 rax 读取的指令将对其 rax 操作数有 2 个依赖项（写入 eax 的指令和在其之前写入 rax 的指令)，这将导致 partial register stall，当有 3 种可能的宽度时，它开始变得棘手，所以它有助于 rax 和 eax 写入完整的寄存器，这意味着 64 位指令集不会引入任何新的部分重命名层。

mov rdx, 1
mov rax, 6
imul rax, rdx
mov rbx, rax
mov eax, 7 //retires before add rax, 6
mov rdx, rax // has to wait for both imul rax, rdx and mov eax, 7 to finish before dispatch to the execution units, even though the higher order bits are identical anyway

不进行零扩展的唯一好处是确保包含rax 的高位，例如，如果它最初包含 0xffffffffffffffff，则结果将是 0xffffffff00000007，但 ISA 几乎没有理由做出这种保证以这样的代价，并且更可能实际上需要更多的零扩展的好处，因此它节省了额外的代码行mov rax, 0。通过保证它总是零扩展到 64 位，编译器可以牢记这个公理，而在 mov rdx, rax、rax 中只需要等待它的单个依赖项，这意味着它可以更快地开始执行并退出，从而释放执行单元。此外，它还允许更有效的零习语，如 xor eax, eax 到零 rax，而不需要 REX 字节。

Answer 4

从硬件的角度来看，更新半个寄存器的能力总是有些昂贵，但在最初的 8088 上，允许手写汇编代码将 8088 视为具有两个非堆栈相关的16 位寄存器和 8 个 8 位寄存器，6 个非堆栈相关的 16 位寄存器和零个 8 位寄存器，或 16 位和 8 位寄存器的其他中间组合。这样的用处值得付出额外的代价。

当 80386 添加 32 位寄存器时，没有提供仅访问寄存器上半部分的工具，但是像 ROR ESI,16 这样的指令将足够快，因此仍然可以保存两个 16 -ESI 中的位值并在它们之间切换。

随着迁移到 x64 架构，增加的寄存器集和其他架构增强功能减少了程序员将最大数量的信息压缩到每个寄存器中的需要。此外，寄存器重命名增加了进行部分寄存器更新的成本。如果代码要执行以下操作：

    mov rax,[whatever]
    mov [something],rax
    mov rax,[somethingElse]
    mov [yetAnother],rax

寄存器重命名和相关逻辑可以让 CPU 记录从[whatever] 加载的值需要写入something，然后——只要最后两个地址不同--允许somethingElse 的加载和存储到yetAnother 的处理，而不必等待从whatever 实际读取数据。但是，如果第三条指令是 mov eax,[somethingElse，并且它被指定为不影响高位，则第四条指令在第一次加载完成之前无法存储 RAX，甚至允许发生 EAX 的加载也会发生很难，因为处理器必须跟踪这样一个事实，即虽然下半部分可用，但上半部分不可用。