在使用 gcc -s -nostdlib -nostartfiles -O3 编译的 Linux 系统上反汇编 write(1,"hi",3) 的结果为：
ba03000000 mov edx, 3 ; thanks for the correction jester!
bf01000000 mov edi, 1
31c0 xor eax, eax
e9d8ffffff jmp loc.imp.write
虽然我不是编译器开发专家，但由于这些寄存器中移动的每个值都是在编译时已知且恒定的，因此我很好奇为什么GCC不使用dl、dil和al。
有人可能会认为这个特性对性能没有任何影响，但是当我们谈论程序中数千个寄存器访问时，mov $1, %rax => b801000000与mov $1, %al => b001之间的可执行文件大小差异很大。小巧不仅是软件优雅的一部分，它确实会对性能产生影响。
有人能解释一下为什么“GCC决定”这并不重要吗？
-Os）而不是纯速度优化（-O3）。某些情况下为了正确性，需要至少写入32位寄存器，因此更好的示例是：
char foo(char *p) { return *p; }编译为movzx eax, byte ptr [rdi]
而不是mov al, [rdi]。https://godbolt.org/z/4ca9cTG9j
但是，GCC并不总是避免使用部分寄存器，有时甚至会导致部分寄存器停顿https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15533
在许多x86处理器上，写入部分寄存器会导致性能下降，因为当写入时，它们会被重命名为不同的物理寄存器，而不是与整个寄存器相同。 (有关寄存器重命名实现乱序执行的详细信息，请参见this Q&A)。
但是，当指令读取整个寄存器时，CPU必须检测到它没有单个物理寄存器中可用的正确体系结构寄存器值的事实。(这发生在发出/重命名阶段，因为CPU准备将uop发送到乱序调度器中。)
这被称为部分寄存器停顿。Agner Fog's微架构手册解释得非常好：
6.8 部分寄存器停顿 (PPro/PII/PIII和早期Pentium-M)
部分寄存器停顿是一个问题，当我们写入32位寄存器的一部分并稍后从整个寄存器或更大的一部分读取时会发生。
例如:
; Example 6.10a. Partial register stall
mov al, byte ptr [mem8]
mov ebx, eax ; Partial register stall
AL 寄存器与 AH 寄存器独立，分配了一个临时寄存器。执行单元必须等待 AL 的写入完成后才能将其与 EAX 的其余部分的值结合起来。正如@BeeOnRope的回答所指出的那样,编译器仍然可以读取部分寄存器，因为这不是问题。(在Haswell/Skylake上读取AH/BH/CH/DH可能会增加一个额外的延迟周期，但请参见有关Sandybridge系列最新成员部分寄存器的早期链接。)
write接受参数，在x86-64通常配置的GCC中需要整个32位和64位寄存器，因此无法简单地组装成mov dl, 3。大小由数据的类型而不是值决定。最后，在某些情况下，C语言需要注意默认参数提升，尽管这不是通常情况。
实际上，正如RossRidge所指出的那样，该调用可能是在没有可见原型的情况下进行的。
mov rdx, 3实际上是mov edx, 3，尽管两者具有相同的效果——即将3放入整个rdx中。MOV r32, imm32隐式清除寄存器的高32位。-O2 和 -O3 下也很容易找到编译器读写部分寄存器的示例），而是因为 x86 和 x86-64 要求 在将小于 32 位的参数传递给函数时进行零扩展或符号扩展。无论原型是什么，甚至如果没有原型在作用域内（ABI 仍然适用，基于调用形状的一些“默认”函数签名）。有趣的是，高 32 位 可以 包含垃圾数据，但不包括第 8 到 32 位。 - BeeOnRopeicc 并没有遵循它，而且关于正确的做法还存在一些争议。然而，对于 OP 的问题，关键在于 gcc 遵循了扩展到 32 位的规则。 - BeeOnRopemov edx,3 替换为 mov dl,3，那么代码就是错误的，因为对字节寄存器的写入（与对双字寄存器的写入不同）不会清零寄存器的其余部分。参数在 rdx 中的类型为 size_t，大小为 64 位，因此被调用者将读取整个寄存器，其中位 8 到 63 包含垃圾值。 部分寄存器停顿纯粹是性能问题；如果代码运行得很快但是结果错误，那也没有意义。mov dl,3 之前插入 xor edx,edx 来修复该错误。使用这种修复方法，就没有部分寄存器停顿，因为使用 xor 或 sub 清零整个寄存器，然后写入低字节，在所有具有停顿问题的 CPU 上都有特殊情况。 因此，修复后仍然与部分寄存器停顿无关。loop:
...
dec edx
jnz loop
mov dl,3是正确的。但通常情况下这是不好的，因为它可能会导致部分寄存器停顿。在这里，这并不重要，因为系统调用本来就很慢，但我认为GCC在其内部类型系统中没有“无需加速优化调用”的“慢函数”属性。
xor后跟一个字节移动，难道不是因为部分寄存器停顿吗？我不知道，但我可以猜测。r0到r3时节省空间，即使如此，它也只能节省一个字节。它增加了指令的数量，这有其自身的成本（指令解码器经常是瓶颈）。它还会破坏标志，不像标准的mov，这意味着它不能作为一种替代品。GCC必须跟踪一个单独的标志破坏寄存器初始化序列，在大多数情况下（15个可能的目标寄存器中的11个）都会明显不太高效。push 3，然后是pop rdx，无论目标寄存器是什么，都可以节省2个字节，并且不会破坏标志。但它可能要慢得多，因为它写入内存并且与rsp存在虚假的读写依赖关系，而且空间节省似乎不值得。 （它还修改了red zone，因此也不能作为一种替代品。）
movzx eax，byte ptr [rdi]来实现char foo（char * p）{return * p;}和类似的情况。或者char bar(){ return 1; } https://godbolt.org/z/4ca9cTG9j显示，在-Os（优化大小）下，GCC只写入AL而不是扩展为EAX。（而clang只写入AL，轻率地冒着部分寄存器错误依赖的风险；可以假定调用者不会读取EAX。） - Peter Cordesclang -Oz优化大小而不关心速度，并且实际上使用push/pop。 - Peter Cordeslea edx，[rax + 1]或其他东西可能很好。x86 / x64机器码高尔夫技巧。关于xor-zero和mov dl，3的想法很有趣，因为它只占用4个字节。您说得对，这两个指令和2个uop在前端可能是瓶颈，无论是解码还是发出。并且在uop缓存中占用更多的空间。在ROB中也占用更多的空间，限制了CPU寻找ILP以进行乱序执行的能力。 - Peter Cordesmov al，cl比mov eax，ecx在吞吐量和延迟方面都变慢（mov消除仅适用于32位和64位mov，或者在Intel上，对于movzx 8->32位）。例如，IvyBridge可以在每个时钟周期内执行4个32位mov（不需要后端ALU端口），但即使您使用不同的寄存器，每个时钟周期内也只能执行3个8位mov。 - Peter Cordesadd这样的2输入操作，这不是一个问题，因为您已经需要读取修改目标，因此输出依赖关系不是错误的。但是，像xor-zeroing这样的东西在8位寄存器上速度较慢，因为它们无法被消除。请参见Haswell / Skylake上的部分寄存器如何执行？写入AL似乎对RAX有误依赖性，AH不一致。还有GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15533（特别是我在末尾的评论 - 自从4.4以来，GCC会导致部分寄存器停顿，使用xor al，al / read EAX）。 - Peter Cordesmov al，whatever对RAX的旧值具有虚假依赖性。） - Peter Cordes
3和1，它们已经是signed int，仍然保持为signed int。 - Ross Ridgexor eax, eax表示该调用没有原型的范围。它不知道函数是否为可变参数，因此将 AL 设置为 0，表示未传递任何 SSE 寄存器中的参数。你的情况涉及到 ABI 的问题，“好像”规则允许任一实现，只要两端都同意即可。” - Ross Ridge