By using this site, you agree to our Privacy Policy and our Terms of Use. Close
CrashMan said:
alephnull said:
MisterBlonde said:
@alephnull

The function paramaters are accessed via offsets from ebp. There aren't enough registers to store all the parameters for a particular callstack. They are pushed and popped onto the stack. All compilers do is compile c code into assembly instructions that are executed by the CPU. At run time they are non existent (unless you are talking about a JIT compiler). The assembly code will do the pushing and popping.

Eip points to the next instruction to be executed. When a function makes a call it pushes it's return address onto the stack. There is no way during a synchronous call for the calling function to be running until the called function returns. That is what crashman was saying and that is what I was agreeing with. When the called function returns the calling function's return address is popped back into eip.

google function prologue and epilogue for more details.

 

If you don't think the compiler is involved what do you think happens when you add the keyword inline before a function definition? Would you agree with me that the compiler does not put an inline function's parameters on the call stack?

Try doing a backtrace on a piece of code compiled with -O3 in gcc. I think you will find that it inlines quite a bit. Particularly with the CBE and Xenon you have over a hundred registers per core, and if you don't think copious inlining is going on then... well, I dunno.

 

inline functions replace their function call with the actual code for the function, so you are right there, there is no pushing and popping off the stack.  There may be, however, memory read/writes since you may have more params than available registers.

However, inline functions have to be carefully.  They can increase code size dramatically.  You could eliminate all stack push/pops by making your code all one function, but that is horrible design, and would basically be what inlineing all your functions does.

inline eliminates the benefits of functions by not reusing code.  If you have:

inline int functiona(int a, int b, int c)
{
//Code Here
}

and this function is called 100 different times, the "Code Here" section is compiled in to assembly 100 times.  Ouch.

100 times is fine for simple functions like

int min(int a, int b)

{ return a < b ? a : b;

}

 

Where the function iteself is as, or at least nearly as small as calling an external function...