Function parameters are placed on the stack, but compilers can optimize this task by the use of optional registers. It would make sense that this optimization will kick in if there are only 1-2 parameters, and not when there are 256 (not that one would want to have the max number of parameters).
How can one find out the parameter limit (number of parameters) for a certain compiler (such as gcc) where one can be sure that this optimization will be used?
As FrankH says in his comments and as I’m going to say in my answer, the application binary interface for the system in question determines how arguments are passed to functions – this is called the calling convention for that platform.
To complicate matters, x86 32-bit actually has several. This is historical and comes from the fact that when
Win32bit arrived, everyone went crazy doing different things.So, yes, you can “optimise” by writing function calls in such a way, but no, you shouldn’t. You should follow the standards for your platform. Because the honest truth is, the speed of stack access probably isn’t slowing your code down to that great an extent that you need to be binary-incompatible from everyone else on your system.
Why the need for ABIs/standard calling conventions? Well, in terms of using the processor registers, stack etc, applications must agree on what means what and where it shoudl go. If one function decided all its arguments were in registers and another that some were on the stack, how would they be interoperable? Moreover, you might come across the term scratch registers to mean those registers you don’t have to restore. What happens if you call a function expecting it to leave some registers alone?
Anyway, as for what you asked for, here’s some ABI documentation:
The last one is my favourite. To quote it:
So whatever you’re trying to do with optimising via modifying the function calling method, don’t. Find another way to optimise. Profile your code. Study the compiler optimisations you’ve got for your compiler (
-OX) if you think it helps and dump the assembly to check, if the speed is really that crucial