函数参数放在堆栈上，但编译器可以通过使用可选寄存器来优化此任务。如果只有1-2个参数，那么这个优化就会有效，而当有256个参数时（而不是那个想要拥有最大参数数量的那个），这将是有意义的。
如何确定某个编译器（如gcc）的参数限制（参数个数），以确定是否可以使用此优化？
答案 0 :(得分：4)
函数参数放在堆栈上，但编译器可以通过使用可选寄存器来优化此任务。
正如FrankH在他的评论中所说，并且我将在我的回答中说，有问题的系统的应用程序二进制接口决定了如何将参数传递给函数 - 这称为该平台的调用约定。
更复杂的是，x86 32位实际上有几个。这是历史性的，并且来自这样一个事实：当Win32位到来时，每个人都疯狂地做着不同的事情。
所以，是的，您可以通过以这种方式编写函数调用来“优化”，但不，您不应该。您应该遵循适用于您的平台的标准。因为诚实的事实是，堆栈访问的速度可能不会使您的代码速度降低到您需要与系统中的其他人二进制不兼容的程度。
为什么需要ABI /标准调用约定？好吧，在使用处理器寄存器，堆栈等方面，应用程序必须就什么意思以及在何处使用达成一致。如果一个函数决定它的所有参数都在寄存器中，另一个函数决定了堆栈中的一些参数，它们将如何互操作？此外，您可能会遇到术语暂存寄存器，以表示那些您无需还原的寄存器。如果你调用一个假设它只留下一些寄存器的函数会发生什么？
无论如何，至于你要求的内容，这里有一些ABI文档：
最后一个是我的最爱。引用它：
在旧的DOS操作系统的时代，通常可以结合开发 来自不同供应商的工具兼容性问题很少。使用32位Windows， 情况完全失控。不同的编译器使用不同的数据 表示，不同的函数调用约定和不同的目标文件格式。 虽然传统上静态链接库被认为是特定于编译器的，但是 广泛使用动态链接库（DLL）已经使功能分配 二进制形式的库更常见。
因此，无论您是通过修改函数调用方法进行优化而尝试做什么，都不要。找到另一种优化方式。描述您的代码。研究编译器优化你的编译器（-OX），如果你觉得它有帮助并转储程序集来检查，如果速度真的那么重要
答案 1 :(得分：2)
对于公开可见的功能，这在ABI标准中有记录。对于无法从外部引用的功能，无论如何都会关闭所有投注。
答案 2 :(得分：0)
您必须阅读编译器的精细手册。如果你很幸运，你会在函数调用约定的描述中找到它。否则，对于诸如gcc的OSS编译器，您可能必须阅读其源代码。