Is there stack associated when a executing an inline function?

J

jacob navia

Kaz said:
However, it wouldn't be weird at all if the inlined procedure simply
moves the stack pointer by some delta to enlarge the current frame,
then references all of its locals with respect to the current frame,
and then moves the stack pointer back by the same delta upon
termination to release the storage.

That is normal, but that is not a stack frame!

That is just increasing the stack, like when you use
alloca().

That function (alloca()) doesn't create a stack frame.
 
R

Richard Tobin

Kaz Kylheku said:
However, it wouldn't be weird at all if the inlined procedure simply
moves the stack pointer by some delta to enlarge the current frame,
then references all of its locals with respect to the current frame,
and then moves the stack pointer back by the same delta upon
termination to release the storage.

But what would be the point?

-- Richard
 
K

Keith Thompson

jacob navia said:
That is normal, but that is not a stack frame!

That is just increasing the stack, like when you use
alloca().

That function (alloca()) doesn't create a stack frame.

So you have some specific definition of the term "stack frame" in
mind, one that includes the storage reserved by an ordinary function
call, but that excludes the storage that might be reserved in other
circumstances, such as a call to an inline function or a call to the
non-standard alloca() function.

Perhaps you can tell us what this definition is, preferably by citing
the standard.

There are a number of ways that inline functions, and calls to them,
could be implemented. For that matter, I understand that not
generating a new stack frame is a fairly common optimization for calls
to some ordinary functions. I see no particular reason why allocating
a stack frame and executing a call instruction must be tied together;
either could be done without the other if it's convenient.

The gory details would, of course, be perfectly topical in some
system-specific newsgroup.
 
K

Keith Thompson

Paul Hsieh said:
The implicit call stack retains all its behaviors as normal regardless
of function call decorations like "inline".

The only thing the standard can say about "inline" is that it prevents
an function's address be stored in a function pointer. For many
cases, this can already be established by the compiler, but this is
useful for compilers that don't. (Its essentially, a new keyword,
helpful for old compilers that will not be updated to the new
standard. Don't ask me; I had no hand in this.)

No, the standard doesn't prohibit taking the address of an inline
function. (Perhaps you're thinking of "register".)

I'm not sure what you mean when you say this is "helpful for old
compilers that will not be updated to the new standard". Compilers
that don't support C99 (more specifically, compilers that conform to
C90) don't support the "inline" keyword.
macros just perform text substitutions, and cannot call themselves
recursively.


You use macros to avoid call overhead and when text substitution is
sufficient. Macros also have certain compile-time capabilities that
you don't get from function calls: stringification with # x and text
concatenation via: x ## y.

Macros can also be dangerous when used carelessly. My favorite
example of macro abuse is:

#include <stdio.h>

#define SIX 1+5
#define NINE 8+1

int main(void)
{
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}

That's not to say that macros can't be used safely, but they're one of
the sharper tools in the C toolbox, and more elaborate precautions are
necessary to avoid cutting yourself.
 
R

Richard Tobin

Keith Thompson said:
So you have some specific definition of the term "stack frame" in
mind, one that includes the storage reserved by an ordinary function
call, but that excludes the storage that might be reserved in other
circumstances, such as a call to an inline function or a call to the
non-standard alloca() function.

Perhaps you can tell us what this definition is, preferably by citing
the standard.

You know it's not in the standard, but it is in fact the normal
definition, even if he didn't cover all the edge cases.

Jacob's answers are often ones that will help a beginner, even if
they're not 100% precise.

-- Richard
 
C

CBFalconer

Micah said:
None of which goes even close to validating your assertion that a
stack frame will _not_ be generated.

Hey, lets not pick. The above shows a great advance. It proves
Jacob has actually read at least some portion of the C standard.
He deserves congratulation.
 
R

Richard Tobin

But what would be the point?
[/QUOTE]
It'd allow re-use of that memory by another (subsequent) inlined
procedure or function call. Waste not, want not.

Multiple inlined functions can use the same stack space without
adjusting the stack pointer. It's not significantly different from:

void foo(int a)
{
...
{
int b;
...
}
...
{
double c;
...
}
...
}

But actually I'd misread the article; it is indeed quite reasonable to
adjust the stack pointer during the execution of a function, and it
can be done even when there are no inline function calls or nested
blocks, at the end of some variable's useful life. I don't know if
any C implementations do that, but some implementations of other
languages do.

-- Richard
 
C

CBFalconer

jacob said:
Care to name a SINGLE compiler system that does this kind of stuff?

Most. They allocate a stack block for their local storage, and
then let the push/pop mechanism handle the temporaries during
expression evaluation, for example. That is why extending local
storage (from an inline function) requires special care and timing.

Other things that can grow on top of allocated stack storage are
saves and returns to handle interrupts.
 
J

jacob navia

CBFalconer said:
Most. They allocate a stack block for their local storage, and
then let the push/pop mechanism handle the temporaries during
expression evaluation, for example.


Yes. But I was asking for the hypothetical compiler that
Mr Kylheku proposed, that allocates not from the stack but from
the heap.

I know that most compilers allocate from the stack, thats what I was
saying.

That is why extending local
storage (from an inline function) requires special care and timing.

Correct, that is why I said that in my first message to this thread.
 
K

Kaz Kylheku

Most.  They allocate a stack block for their local storage, and
then let the push/pop mechanism handle the temporaries during
expression evaluation, for example.  That is why extending local
storage (from an inline function) requires special care and timing.

You'd never pop a temporary within the inlined block that was pushed
outside of it. Everything just has to be properly nested. That would
be the extent of the special care and timing.
 
K

Kaz Kylheku

Yes. But I was asking for the hypothetical compiler that
Mr Kylheku proposed, that allocates not from the stack but from
the heap.

But I didn't write anything about any heap. I'm only writing about
stack allocation: moving the stack pointer to obtain extra automatic
storage for a block, which is then released when the block terminates.
That ``small overhead'' I'm referring to is moving the stack pointer
back and forth.
 
R

Richard Bos

jacob navia said:
Yes. See the definition of local variables and local storage...

6.2.4.4
An object whose identifier is declared with no linkage and without the
storage-class specifier static has automatic storage duration

Normally, objects with automatic storage duration are implemented
in the stack. Of course, regulars do not accept the fact that 99%
of all machines around use a stack but I really do not care.

Even if we assume your definition of a stack, what is there in the
Standard that forces us to assume your (and, one must believe, since
you're obviously clairvoyant and can read his mind, the OP's) definition
of a stack _frame_?

Richard
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top