5 ms·
Yes, imagine that a function looks like this in memory: +-----------------+ | return address | +-----------------+ | executable code | +------------
by Stratoscope 7y ago
Yes, imagine that a function looks like this in memory:
+-----------------+
| return address |
+-----------------+
| executable code |
+-----------------+
The way you call a function is to store your desired return address in the first slot, and jump to the code in the second slot. The function jumps to the saved return address when it's done.
We did it this way for years.
Now given that mindset, how could you even contemplate recursion? Where would you put all the return addresses?
- mark-r 7y agoThat's the way the Control Data Cybers worked, except that it wasn't just a return address - it was a complete jump instruction. You needed to start your function with a no-op of the correct length, and it was overwritten by the caller. Then to return from your function you simply jumped back to the beginning.
- zozbot234 7y agoNice. Basically, the caller uses self-modifying code to set up the correct continuation ("self-modifying code" and "continuation" being somewhat closely-related concepts, after all), and then has the callee jump to it. Makes a lot of sense.
- Sniffnoy 7y agoWhat's a little confusing here is that they talk about "static allocation" vs "dynamic allocation"; but these days, use of the stack is referred to as static allocation! Even if it's not as fully static as the old way. The shift in terminology makes the old debate opaque for the modern reader, and without your comment (and some similar ones) I wouldn't have known what was going on.
- gumby 7y agoI have never seen that usage — in what community is it common? Thanks!
- deleted 7y ago[deleted]
- kragen 7y agoI haven't seen that usage anywhere.
- deleted 7y ago[deleted]
- gowld 7y agoSniffjoy is referring to static allocation of local variables on the stack (vs dynamically on the heap), not static allocation of the stack itself.
- kragen 7y agoReferring to stack allocation as "static allocation" is just not something I've seen before. I suspect you're simply in error; maybe you misheard someone saying the phrase "stack allocation", or you've been talking to somebody who misheard it that way. You can statically allocate a local variable in C, for example: static char *err = NULL; But that specifically does not allocate it on the stack. Both heap allocation and stack allocation are dynamic, not static. There are things that are a bit more of a gray area in C and Unix and Win32/64 — are "statically allocated" variables of a shared library really statically allocated if they aren't there when the program starts up and they may be at some unexpected address? — but this is not one of them.
- Someone 7y agoNitpick: you also stored the function’s arguments there (if the language supported function arguments. I think most did, but am not sure about COBOL) On the plus side, languages at the time (FORTRAN, COBOL) also required array sizes to be known at compile time, and memory allocators didn’t exist, so programs never ran out of memory (but would abort if an input file was larger than expected, even if the machine had plenty of memory available) Consequently, CPU support for stacks was weak, because languages had no good use for them. In theory, optimizers could do away with (part of) the activation record in cases where a function was called from only one place, or where arguments always were the same. I don’t know whether compilers that did that existed.