Run-time execution for recursive functions.

Hi,
I actually dont know how CPU (or the compiled run-time code) handles recursive functions. Is the code of the function copied “a-la memcpy” to make a new instance? Or only the local vars are copied for the new instance?
Does the size of the function influence on the speed of the recursive function? If so, are long-inline macros be counter-productive, and better to have as normal function calls?
I ask all this because I don’t know exactly how run-time execution handles subroutines (above all in recursive funcs.).
Thanks.

The code isn't "copied" at all, there is only one instance of it in memory, the program counter just moves around. Each call to the function results in new instances of the local variables (local to that specific instance of the function [unless they are static]) pushed onto the stack. As far as the code itself goes, each time the function is called again, the program counter gets reset to point to the beginning of the function's code (the address of instruction we made the recursive call from is saved to jump back to after the current instance of the function ends). When the function ends, the current instances' local variables are popped off the stack and the program counter gets set back to the last saved value so we can pick up where we last let off.

... at least that's how I imagine it happens in my head.

Which is why you can overflow the stack with recursion that goes too deep (push, push, push, push....).

The main point being the compiler does absolutely nothing special to make a recursive call. It is exactly like any other call.

Quote:

---

Originally Posted by hk_mp5kpdw

The code isn't "copied" at all, there is only one instance of it in memory, the program counter just moves around. Each call to the function results in new instances of the local variables (local to that specific instance of the function [unless they are static]) pushed onto the stack. As far as the code itself goes, each time the function is called again, the program counter gets reset to point to the beginning of the function's code (the address of instruction we made the recursive call from is saved to jump back to after the current instance of the function ends). When the function ends, the current instances' local variables are popped off the stack and the program counter gets set back to the last saved value so we can pick up where we last let off.

... at least that's how I imagine it happens in my head.

---

I see, so as more local vars means more stack load to work with.
Does non-recursive function copy its local vars also in stack?

Quote:

---

Originally Posted by Kempelen

I see, so as more local vars means more stack load to work with.
Does non-recursive function copy its local vars also in stack?

---

function does not know if it recursive or not.

Local vars are on the stack, yes.

Quote:

---

Originally Posted by nonoob

Local vars are on the stack, yes.

---

So the bigger the function and the more local vars you use, the bigger the work load of the stack. For speed purposes (and also for methodology) it is better to have a few small function that one that do all.no?

Using one large funciton or several small ones is a compromise. If all functions are one long chain of calls (func1 calls func2 that calls func3), then the stack overhead is (a tiny bit) larger than if you put all the code for func1..func3 in one function - because each function call itself must also use some stack-space to store where to return to.

The general rules are:
1. Keep functions reasonably small - it makes them possible to read, and the compiler often optimizes small functions better than large ones.
2. A function should do one thing, and do it well.
3. If something is repeated several times in the code, make it a function.

--
Mats