在x86-64 Intel手册之旅中，我读到：
也许最令人惊讶的事实是，例如
MOV EAX, EBX这样的指令会自动清零RAX寄存器的高32位。
在同一来源引用的Intel文档（基本架构手册中的64位模式下通用寄存器3.4.1.1）告诉我们：
在x86-32和x86-64汇编中，16位指令如下：
- 64位操作数在目标通用寄存器中生成64位结果。
- 32位操作数在目标通用寄存器中生成32位结果，并将其扩展为64位结果。
- 8位和16位操作数生成8位或16位结果。目标通用寄存器的上56位或48位（分别）不会被操作修改。如果8位或16位操作的结果用于64位地址计算，请显式地将寄存器符号扩展到完整的64位。
mov ax, bx
不要展示这种“奇怪”的行为，即将eax的上半部分清零。
因此：这种行为被引入的原因是什么？乍一看似乎不合逻辑（但原因可能是我已经习惯了x86-32汇编的怪癖）。
int变为64位会浪费缓存占用和内存带宽;x86-64最有效地支持32位和64位的操作数大小)
8位和16位操作数的行为是奇怪的。依赖关系混乱是16位指令现在被避免的原因之一。x86-64从8086（8位）和386（16位）继承了这个问题，并决定在64位模式下使8位和16位寄存器的工作方式与32位模式下相同。
请参阅为什么GCC不使用部分寄存器？，了解实际处理8位和16位部分寄存器写入（以及后续对完整寄存器的读取）的CPU细节。
这只是在指令和指令集中节省空间。您可以使用现有的（32位）指令将小的立即值移动到64位寄存器中。
当您需要将8字节值编码为MOV RAX, 42时，它也可以避免这种情况，而可以重复使用MOV EAX, 42。
对于8位和16位操作，这种优化并不那么重要（因为它们更小），在那里改变规则也会破坏旧代码。
XOR EAX，EAX ，因为 XOR RAX，RAX 需要一个 REX 前缀。 - Neil[rsi + edx]是不允许的）。当然，避免错误依赖/部分寄存器停顿（另一个答案）也是另一个主要原因。 - Peter Cordes如果不将0扩展到64位，那么从rax读取的指令将有2个操作数依赖项（写入eax和它之前写入rax的指令），这会导致部分寄存器停顿，当存在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的高位bit包含在内，比如，如果它最初包含0xffffffffffffffff，则结果将是0xffffffff00000007，但ISA为此作出代价更大的保证的原因很少，而且更有可能需要零扩展的好处，因此可以省略掉额外的代码行mov rax, 0。通过保证它总是被零扩展到64位，编译器可以在mov rdx, rax中以此为前提进行工作，rax只需要等待其单个依赖项，这意味着它可以更快地开始执行并退役，释放执行单元。此外，它还允许更有效的零习语，例如xor eax，eax来将rax归零，而不需要REX字节。cmovbe是2个uop，但cmovb是1个）。 但是，没有任何进行任何部分寄存器重命名的CPU会按照您建议的方式执行。 相反，如果将部分寄存器与完整寄存器分别重命名（即“脏”），则会插入合并uop。 请参见为什么GCC不使用部分寄存器？和Haswell / Skylake上的部分寄存器如何执行？ 写入AL似乎对RAX有错误依赖性，AH不一致。 - Peter Cordesmov eax，7是一个5字节的指令，而mov rax，7是一个7字节的指令。（额外的REX和ModRM，尽管如果AMD没有进行隐式零扩展，他们可能会对mov reg，imm32 no-modrm操作码的REX版本做出其他事情，并使它们符号扩展32位立即数，并将64位立即数放在某些其他操作码上。可能有一个modrm。） - Peter Cordes从硬件的角度来看，更新寄存器的一半始终是比较昂贵的。但在原始的8088上，它可以让手写汇编代码将8088视为具有两个非堆栈相关的16位寄存器和八个8位寄存器，六个非堆栈相关的16位寄存器和零个8位寄存器，或其他16位和8位寄存器的中间组合。这种实用性值得额外的成本。
当80386添加32位寄存器时，并未提供访问寄存器顶部一半的功能，但是像 ROR ESI,16 这样的指令速度足够快，使得能够在ESI中存储两个16位值并在它们之间切换仍然具有价值。
随着迁移到x64架构，增加了寄存器集和其他架构增强功能，减少了程序员需要将尽可能多的信息挤入每个寄存器的需求。此外，寄存器重命名增加了进行局部寄存器更新的成本。如果代码执行如下操作：
mov rax,[whatever]
mov [something],rax
mov rax,[somethingElse]
mov [yetAnother],rax
寄存器重命名以及相关逻辑可以让CPU记录从[whatever]加载的值需要写入something，只要最后两个地址不同，就允许加载somethingElse并将其存储到yetAnother而无需等待数据实际从whatever读取。如果第三条指令是mov eax，[somethingElse]，并且它被指定为不影响上半部分位，则第四条指令无法在第一次加载完成之前存储RAX，即使允许加载EAX也会很困难，因为处理器必须跟踪下半部分可用但上半部分不可用的事实。
mov eax, 1(操作码+imm32)作为设置完整64位寄存器的一种方式，而不需要7字节的mov rax, sign_extended_imm32(REX+操作码+modrm+imm32)或10字节的mov rax, imm64(rex+操作码+imm64)。在许多其他情况下，免费进行零扩展也是有用的，例如在使用无符号32位整数作为数组索引(地址模式的一部分)或已知为非负的有符号整数时。 - Peter Cordesimul这样的指令在K8上变慢（64位乘法不如32位快），除非它还设置了操作数大小并将结果从32位截断/扩展以填充寄存器。）但是这里的评论不是讨论的地方 :/ - Peter Cordes
r32目标操作数的指令都会将高32位清零，而不是合并。例如，一些汇编器将使用pmovmskb r32，xmm替换pmovmskb r64，xmm，以节省REX，因为64位目标版本的行为完全相同。即使手册的操作部分单独列出了所有6种32/64位目标和64/128/256位源的组合，r32形式的隐式零扩展也会复制r64形式的显式零扩展。我对硬件实现很感兴趣... - Peter Cordesxor eax，eax或xor r8d，r8d是将RAX或R8清零的最佳方法（为RAX节省REX前缀，64位XOR在Silvermont上甚至没有特殊处理）。 相关：[Haswell / Skylake上的部分寄存器如何执行？ 写入AL似乎对RAX有错误依赖性，并且AH不一致。] - Peter Cordes