Thread: Functional call != stack creation?

I'm working on a tutorial on "vertex buffer objects" in GL. At the beginning, I try to explain why this method has obsoleted an older one (which uses way more function calls) and said, thoughtlessly:

As we know, every function call in C/C++ requires a stack be created, then freed at the end.

I submitted this for peer review and someone responded:

To the best of my knowledge this isn't true. A stack frame (not stack) needs to be setup but, generally, memory allocation does not occur. It really just copies some values and moves a pointer by an offset. Function call overhead can still be an issue though.

Thinking about this, I suppose all functions already have a stack at runtime, so it is just a matter of setting the ebp (?? or whatever) to it and copying in some values -- the memory is already allocated. Do I have this straight now?

BUT, I still need to say something informative (and accurate) about exactly how "Function call overhead can still be an issue". I suppose this overhead is just the copying of values and not allocation of memory?

For each thread, a stack is allocated.
So we have a stack. We don't need to create a new stack for each function.
Instead, the ebp (I believe) register keeps track of where on the stack writes and reads are done.
Due to the way the stack grows, usually an offset is added to ebp equal to the bytes needed to store the local variables.
So add an offset to ebp at the beginning of each function, then subtract the offset from at the end of the function. Some compilers also likes to take a copy of the stack pointer at each function and pop it at the end.

Function overhead could be the popping and pushing of arguments onto the stack, I believe.

Originally Posted by Elysia

For each thread, a stack is allocated.
So we have a stack. We don't need to create a new stack for each function.
Instead, the ebp (I believe) register keeps track of where on the stack writes and reads are done.
Due to the way the stack grows, usually an offset is added to ebp equal to the bytes needed to store the local variables.

Hmmm, okay. This kind of implies the stack might change size?

Out of curiousity: what about the instruction set itself? Where's that?

I'm sure I've read about this somewhere, just evidently not enough times...

The stack is fixed. It's allocated at the start of the thread. However, not all the pages of the stack needs to be mapped into memory. The entire stack is reserved, but not necessarily committed. The only thing that changes is the pointer, the offset which tells the instructions where to write and read.

What instruction set are you referring to? The x86 instructions for stack manipulation?
push [var]? pop [var]? add [reg], [off]? sub [reg], [off]?

Originally Posted by Elysia

What instruction set are you referring to? The x86 instructions for stack manipulation?
push [var]? pop [var]? add [reg], [off]? sub [reg], [off]?

Yeah, for the function itself. The only time I think about the stack in a "practical" sense is wrt to scope, ie, I know local variables get put there. But (I think) the stack is processed based on instructions tracked with the ? eip ? (instruction pointer) which where is that pointing to? Elsewhere in the stack?

I suppose I could run something thru a debugger to see this, just not sure that would clear the terms and concepts up for me.

Basically, you push stuff onto the stack with push and read with pop.
However, it is also possible to move data (read) from a memory location into a register using the mov instruction. Usually, it would look like:

mov [reg], ebp + off;

ebp is the top of the current stack frame (esp is the current position on the stack).
Basically, push would do

move [esp], data;
sub esp, 4;

And pop would do

move [reg], [esp];
add esp, 4;

Usually, when entering a function, the current position on the stack is saved in the ebp register.
When exiting the function, that value is popped back into the esp register.
In visual studio, the debugger will also try to pop variables on the stack by adding the number of bytes back to esp after the function is done and comparing it to ebp. If they don't match, you will get a debugger warning. Usually caused by bad calling convention.

@MK27
This might be of some help to you.

For most implementations there will be a stack, but neither the C or C++ standards require it. What you're asking is purely implementation defined. Most implementations will have a (call-)stack per thread...

Even if you already have the stack allocated when you call a function, there is still overhead.
1. You have to push registers that you want to keep
2. You have to preserve the current stack/frame pointer
3. You have to push copies, or pointers of arguments onto the stack
4. You have to push local variables onto the stack
... and the reverse applies once you return.

For example,

Code:

int foo(int x, int y)
{
   return x + y;
}

int main(void)
{
    int a = 4,
      b = 3;
    foo(a, b);
    return 0;
}

There is "significant overhead" with respect to what the code does (you'd want this to be inlined if you were calling it a lot). Assuming this executes in one thread... The stack frame pointers are really just a guide, you don't have to follow them, but you might be going against your calling convention if you don't. There's nothing "illegal" about smashing your own stack

If you want a simpler version, look up the MIPS architecture. CISC architectures like x86 aren't really that nice... given all the back compatibility. http://www.csl.cornell.edu/courses/e...nsXSummary.pdf gives a good example of common calling conventions. Note that the stack size is fixed.