x86-64 - 为什么不使用RAX在System V AMD64 ABI中传递参数？

Question

我不明白在RAX中不传递参数有什么好处，
由于返回值在RAX中，因此无论如何被调用者都会破坏它。

有人可以解释吗？

Answer 1

x86-64 System V确实将AL用于可变参数功能：调用方传递XMM寄存器中FP arg的数量。

（这只是一个优化，允许被调用者不将所有向量regs转储到数组中；允许AL中的数字大于FP args的数目。实际上，gcc的可变参数函数的代码源只是检查是否它是非零值，并且不转储xmm0..7的任何一个或全部8。我认为ABI保证即使实际上没有任何FP args始终通过al=8是安全的，并且您不能通过传递FP args在堆栈上，而不是通过设置al=0



但是，为什么不使用r9b并使用RAX作为第六个arg？还是使用RAX来获取更早的arg？

因为RAX在x86中有很多隐式用法，并且在设计调用约定（http://web.archive.org/web/20140414124645/http://www.x86-64.org/pipermail/discuss/2000-November/001257.html）时进行的实验发现，使用RAX往往需要在调用者或被调用者中附加指令。例如因为通常需要RAX作为调用程序中计算其他arg的一部分，或者在代码使用RAX中传递的arg之前，与其他arg中的一个做某事时需要RAX。

RAX用于rep stos（gcc曾经更积极地用于内联memset），它用于div和加宽（单操作数）mul / imul，gcc用于编译除法时间常数。 （Why does GCC use multiplication by a strange number in implementing integer division?）。

其他大多数RAX特殊用途只是对其他寄存器（例如cdqe与movsxd rax, eax（或在任何其他寄存器之间））也可以进行的简短编码。或add eax,imm32（无ModRM）对比add r/m32, imm32（或大多数其他ALU指令）。看到我的答案之一
Tips for golfing in x86/x64 machine code。最初的8086缺少许多更长的非AX替代方案，但在8086和386之间，添加了imul r32,r32和movsx / movzx之类的东西。其他仅用于RAX的指令在优化速度时不值得使用（例如xlatb，lodsd），或者被P6 / AMD64扩展已废弃（lahf作为FP的一部分，被fucomi和使用SSE废弃了） / SSE2 ucomisd（用于FP数学），或者是cmpxchg或cpuid这样的专用指令，它们很少见，不会影响调用约定设计。编译器始终未使用aaa之类的BCD指令，而AMD64删除了它们。



x86-64 System V调用约定（主要是Janargička用于整数arg传递寄存器设计）的设计人员通常旨在避免使用具有许多/常见隐式用法的寄存器。 rdx按arg传递顺序排在rcx之前，因为可变移位计数（无BMI2）需要cl。这些可能比mul和div更常见，因为2操作数imul reg,reg允许正常的非扩展乘法而不会破坏RDX：RAX。

选择rdi和rsi作为前两个args显然是由于将memset或memcpy内联为rep movs（gcc早在2000年就已经采用了，尽管实际上并不是一个好选择）。在许多情况下，gcc都这样做了）。即使rep -string指令使用RCX作为计数器，他们仍然发现平均保存的指令可以通过RDX而不是RCX传递RDX中的第三个arg，因此对于memcpy为< cc> / rep stosb。

JanHubička通过使用当时最新版本的x86-64 gcc编译SpecInt来评估arg传递寄存器的多种变化。有关更多详细信息和链接，请参见我在Why does Windows64 use a different calling convention from all other OSes on x86-64?上的答案。

他评估的arg-register指令之一是ret，但他发现该指令不如其他选项好。 （请参阅上面链接的邮件列表消息）。



RISC调用约定在第一个返回值寄存器中传递第一个arg是相当普遍的。 ARM这样做（RAX, RDX, RCX, RBX, RSI, RDI），我认为PowerPC也是。其他（如MIPS）则不然。但是所有这些架构都没有对大多数整数寄存器的隐式使用，通常只是链接寄存器，也许还有堆栈指针。

x86-64 SysV和Windows对FP args执行此操作：xmm0用于传递和返回。