Mil*_*lan 3 c c++ optimization function cpu-registers
函数参数放置在堆栈上，但编译器可以通过使用可选寄存器来优化此任务。如果只有 1-2 个参数，而不是当有 256 个参数时（不是那个人想要拥有最大数量的参数），则这种优化将启动是有道理的。
如何找出某个编译器（例如 gcc）的参数限制（参数数量），从而确定将使用此优化？
小智 5
函数参数放置在堆栈上，但编译器可以通过使用可选寄存器来优化此任务。
正如 FrankH 在他的评论中所说的，正如我将在我的回答中所说的那样，相关系统的应用程序二进制接口决定了如何将参数传递给函数——这被称为该平台的调用约定。
更复杂的是，x86 32 位实际上有几个。这是历史性的，因为当Win32比特到来时，每个人都疯狂地做不同的事情。
所以，是的，您可以通过以这种方式编写函数调用来“优化”，但不，您不应该这样做。您应该遵循平台的标准。因为诚实的事实是，堆栈访问的速度可能不会在很大程度上减慢您的代码，以至于您需要与系统上的其他人保持二进制不兼容。
为什么需要 ABI/标准调用约定？好吧，在使用处理器寄存器、堆栈等方面，应用程序必须就什么意思以及它应该去哪里达成一致。如果一个函数决定它的所有参数都在寄存器中，而另一个函数确定一些参数在堆栈中，它们将如何互操作？此外，您可能会遇到术语临时寄存器，意思是那些您不必恢复的寄存器。如果你调用一个函数，期望它留下一些寄存器，会发生什么？
无论如何，至于您的要求，这里有一些 ABI 文档：
最后一个是我最喜欢的。引用它：
在旧的 DOS 操作系统时代，通常可以将来自不同供应商的开发工具结合起来，几乎没有兼容性问题。对于 32 位 Windows，情况已经完全失控。不同的编译器使用不同的数据表示、不同的函数调用约定和不同的目标文件格式。虽然静态链接库传统上被认为是特定于编译器的，但动态链接库 (DLL) 的广泛使用使得以二进制形式分发函数库更为普遍。
因此，无论您尝试通过修改函数调用方法进行优化，都不要这样做。寻找另一种优化方法。分析您的代码。-OX如果您认为有帮助，请研究您为编译器 ( )获得的编译器优化并转储程序集以检查速度是否真的那么重要