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

在x86-64英特尔手册之旅中，我阅读了

也许最令人惊讶的事实是诸如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程序的怪癖）。

我不是AMD也不代表他们说话，但是我会以同样的方式做到这一点。因为将高半部分置零不会对先前的值产生依赖性，所以CPU必须等待。该寄存器重命名，如果它没有这样做这样的机制将基本上被击败。

这样，您可以在64位模式下使用32位值编写快速代码，而不必始终显式破坏依赖关系。如果没有这种行为，即使64位模式下的每条32位指令几乎都不会使用，也将不得不等待之前发生的事情。（使用int64位将浪费缓存占用空间和内存带宽；x86-64最有效地支持32和64位操作数大小）

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

另请参见为什么GCC不使用部分寄存器？有关实际CPU如何处理8位和16位部分寄存器（以及随后的全寄存器读取）的实用细节。

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

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

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

如果没有零扩展到64位，则意味着从中读取一条指令rax对其rax操作数（写到eax该指令的指令和写rax在其之前的指令）具有2个依赖项，这意味着1）ROB必须具有用于一个操作数具有多个依赖关系，这意味着ROB将需要更多的逻辑和晶体管，并占用更多的空间，并且等待不必要的第二个依赖关系（可能会花费很多时间来执行）时，执行速度会变慢；或替代2），我猜这是16位指令发生的情况，分配阶段可能会停顿（即，如果RAT具有用于ax写的有效分配，并且eax出现了读取，则停顿直到ax写退休）。

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，例如，如果它最初包含0xffffffffffffffffff，结果将为0xffffffff00000007，但是ISA很少有理由为此付出保证，并且实际上更可能需要零扩展的好处，因此它节省了额外的代码行mov rax, 0。通过确保将其始终零扩展为64位，编译器可以牢记此公理，而in中mov rdx, rax，则rax仅需等待其单个依赖关系即可，这意味着它可以更快地开始执行并退出，从而释放执行单元。此外，它还允许更高效的零成语，例如xor eax, eax零，rax而无需REX字节。