Thread: Managing Stack space?

Hi

I am trying to find out how a compiler manages the stack space. Does it only allocate the stack memory once on program startup or does it allocate stack memory on every function call/startup? I am specifically interested in how it manages to keep local variables from colliding in memory when for ex: a function is calling it self.

Thanks in advance

>I am specifically interested in how it manages to keep local variables from colliding in memory for ex: a function is calling it self.
When a function calls itself a new activation record is pushed onto the stack[*]. The activation record has new memory to allocate local variables, so there will be no collisions. When the function returns, the activation record is popped off of the stack and memory reclaimed for other purposes. The control flow returns to the calling function. It helps to remember that even though a function appears to call itself, it really creates a copy of iteself and calls that[&].

>Does it only allocate the stack memory once on program startup or does it allocate stack memory on every function call/startup?
Typically a new program will be allocated a large chunk of memory that it splits up into blocks for static variables, stack space, and heap space. As functions are called and return they use this memory. To my knowledge, most implementations do not allocate and release memory every time a function is called and returns. At least not in the way you're thinking.
[*] I say stack for the sake of explanation, there may not really be one.

[&] Once again, for the sake of explanation. Actual implementations may do something different.

Hi,

I'm interested in learning all these things about what's really going on behind the scenes. Can you recommend any websites etc. that have more about the lower level stuff?

Thanks.

Yes thanks, I would I also appreciate such information.

You can google it and see, but the inner workings of compilers and operating systems is hard to find on the net. I got most of what I know from books and source code, not to mention a few knowledgeable friends.