Help with C language macro stringification

[Fredderic]

If there are very many of these, it gets very hard for the compiler. It has to allocate all these arrays and not to lose the track where they are. Since the stack pointer is moving during the allocation process, it's not that easy to find storage for all the corresponding. Probably the best idea is to maintain a linked list of allocated arrays in the stack, and then when everything is done you can walk through the list, extract the pointers and store them at fixed locations relative the stack frame base. Such a PITA to implement for the compiler, and then nobody uses it anyway I don't know how GCC does multiple arrays, but you can compile and look.

Actually, pretty sure the stack pointer is pretty much irrelevant during execution of a function.  It's the base pointer that anchors the functions arguments and locals.  The compiler simply allocates ALL variables a slot on the stack at compile time, regardless of where in the function they occur, at what scope depth, etc., which includes stack-allocated arrays — they get a pointer variable up-front like any other array.  The compiler then basically does the equivalent of inlining a malloca call, to allocate the actual array.  Since the base pointer anchors the function arguments and locals, the stack pointer can do what it likes, and you simply subtract as much space as you need off the stack pointer, and use that as the base of your array.

Seriously, in the middle of a function, pick a small random number, subtract it from the stack pointer, and everything keeps working just fine.  You can do it as often as you like (as long as you don't run out of stack space, of course), and all you've done is wasted some space on your stack.

It works because the compiler does essentially the exact same thing itself to allocate a functions own local variables.  The caller basically pushes whatever it needs to save, followed by the arguments to the function it's calling, that function then pushes the current base pointer, and sets it to the current stack pointer, before subtracting the space it wants to allocate for it's own local variables.  Done.  On the way back out, it can simply ditch the current stack pointer, setting it back to the base pointer, load the previous base pointer back off the stack, and return back to the caller, which simply adds the space taken by those arguments back onto the stack pointer (rather than fiddling around with popping them off again).  No need to keep track of anything much, other than the functions own arguments and locals.

[hamster_nz]

Actually, pretty sure the stack pointer is pretty much irrelevant during execution of a function.

On modern processors it is now mostly a convention - on older ones the hardware had special instructions that maintained the base pointer for you.

Hence the following option in GCC:

-fomit-frame-pointer
        Don't keep the frame pointer in a register for functions that don't
need one. This avoids the instructions to save, set up and restore frame
pointers; it also makes an extra register available in many functions. It
also makes debugging impossible on some machines.

[John Coloccia]

"Please, just make your code look like the code around it, and otherwise just use common sense and don't make a mess," but that never seems to work.

Perhaps you hire wrong people.

Oh, it doesn't matter who you hire. I could hire 10 copies of me and I'd still need to have written standards to keep it all straight. There are too many correct ways of doing something, but only one of them is right...the one in the standard.

[legacy]

On modern processors it is now mostly a convention - on older ones the hardware had special instructions that maintained the base pointer for you.

I am thinking about the RISC way to pass parameters to a function to be called: they can use registers instead of pushing thing on the stack.

But! Since registers are limited, it only works if parameters are compliant to the model (which is based on statistics, e.g. if usually functions have no more than 4 parameters, then 4 registers are reserved), otherwise we are back to the traditional model. In this case, on MIPS, I see a lot of compilers want to save the stack pointer before pushing on the stack, and then they simple resume comping back the frame pointer into the stack pointer

save sp into fp
reserve space for the return ansers (if any)
push parameters
call the function
save fp into sp

[NorthGuy]

Actually, pretty sure the stack pointer is pretty much irrelevant during execution of a function.  It's the base pointer that anchors the functions arguments and locals.  The compiler simply allocates ALL variables a slot on the stack at compile time, regardless of where in the function they occur, at what scope depth, etc., which includes stack-allocated arrays — they get a pointer variable up-front like any other array.  The compiler then basically does the equivalent of inlining a malloca call, to allocate the actual array.  Since the base pointer anchors the function arguments and locals, the stack pointer can do what it likes, and you simply subtract as much space as you need off the stack pointer, and use that as the base of your array.

Yes, that is an easy mechanism if the compiler maintains a frame pointer which is separate from the stack pointer. I guess even if the compiler doesn't use frame pointers, it can make an exception for the functions with variable-size arrays.