Is there stack associated when a executing an inline function?

[Mahesh]

Hi,
I need to know if stack frames are generated in case of a
inline function execution or
do they execute just like macros?
if they execute like macros, then what is the need for having
inline function?
where would you use macros and where inlines?

Thanks
Mahesh

[Richard Tobin]

In article <fq**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:

> if they execute like macros, then what is the need for having
inline function?

>One major advantage (and sometimes a major disadvantage) is the type
checking you get with inline functions.

You generally don't lose type checking with macros, because the
expansion gets type checked in the usual way. If getc is a macro and
you call it with something that isn't a FILE *, you'll probably
get a bunch of fatal, if unclear, errors.

The more compelling reason for inline functions is that you can't
use arbitrary constructs in macros that are used in expressions.
C's macros are just powerful enough to let you write getc and putc,
but anything that needs declarations or a loop can't be done.

-- Richard
--
:wq

[Kenny McCormack]

In article <1f**********************************@u10g2000prn. googlegroups.com>,
Mahesh <ma********@gmail.comwrote:

>Hi,
I need to know if stack frames are generated in case of a
inline function execution or
do they execute just like macros?
if they execute like macros, then what is the need for having
inline function?
where would you use macros and where inlines?

Thanks
Mahesh

Be aware that use of the word "stack" in this ng (even if the subject is
pancakes), by non-Clique members, will result in flamage.

[Morris Dovey]

Kenny McCormack wrote:

Be aware that use of the word "stack" in this ng (even if the subject is
pancakes), by non-Clique members, will result in flamage.

Good point - many newbies are unaware that not all machine
architectures include a stack mechanism.

Flames are generally reserved for intellectually conceited types
who present ignorance as virtue.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto

[Kenny McCormack]

In article <47***************@iedu.com>,
Morris Dovey <mr*****@iedu.comwrote:

>Kenny McCormack wrote:

>Be aware that use of the word "stack" in this ng (even if the subject is
pancakes), by non-Clique members, will result in flamage.

Good point - many newbies are unaware that not all machine
architectures include a stack mechanism.

Wow! Can you say 'goosestepping' ?

>Flames are generally reserved for intellectually conceited types
who present ignorance as virtue.

More goosestepping.

[Keith Thompson]

jacob navia <ja***@nospam.comwrites:

Mahesh wrote:

> I need to know if stack frames are generated in case of a
inline function execution or
do they execute just like macros?

A stack <framewill not be generated but any local
storage that the inline function uses will be added to
the local storage of the calling function.

How do you know? Can you cite the standard to support this claim?

The implementation you describe is certainly plausible, but the
standard says nothing about stack frames, either for inline functions
or for ordinary functions. See C99 6.7.4. To the original poster: a
recent draft of the C99 standard can be downloaded in PDF format from
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.

Briefly, the standard imposes some restrictions on inline functions,
but otherwise says only that they behave like ordinary functions.

[snip]

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Kaz Kylheku wrote:

In principle, blocks can allocate and deallocate individually. That
requires a small overhead, but it would be a smart implementation
strategy for blocks that contain large arrays. Or at least a code-
generation option, if not default behavior.

Care to name a SINGLE compiler system that does this kind of stuff?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Kaz Kylheku]

On Feb 29, 11:08*am, jacob navia <[e-mail]:

It would be completely weird that in an inline procedure the compiler
would save the current stack pointer and establish a new stack
frame since there is no function call.

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.

[jacob navia]

Kaz Kylheku wrote:

On Feb 29, 11:08 am, jacob navia <[e-mail]:

>It would be completely weird that in an inline procedure the compiler
would save the current stack pointer and establish a new stack
frame since there is no function call.

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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard Tobin]

In article <12**********************************@59g2000hsb.g ooglegroups.com>,
Kaz Kylheku <kk******@gmail.comwrote:

>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
--
:wq

[Morris Dovey]

Richard Tobin wrote:

>
In article <12**********************************@59g2000hsb.g ooglegroups.com>,
Kaz Kylheku <kk******@gmail.comwrote:

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?

It'd allow re-use of that memory by another (subsequent) inlined
procedure or function call. Waste not, want not.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto/Projects/Monitor/

[Richard Tobin]

In article <47***************@iedu.com>,
Morris Dovey <mr*****@iedu.comwrote:

>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?

>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

--
:wq

[CBFalconer]

jacob navia wrote:

Kaz Kylheku wrote:

>In principle, blocks can allocate and deallocate individually. That
requires a small overhead, but it would be a smart implementation
strategy for blocks that contain large arrays. Or at least a code-
generation option, if not default behavior.

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[jacob navia]

CBFalconer wrote:

jacob navia wrote:

>Kaz Kylheku wrote:

>>In principle, blocks can allocate and deallocate individually. That
requires a small overhead, but it would be a smart implementation
strategy for blocks that contain large arrays. Or at least a code-
generation option, if not default behavior.

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.

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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Kaz Kylheku]

On Feb 29, 2:20*pm, CBFalconer <[e-mail]:

jacob navia wrote:

Kaz Kylheku wrote:

In principle, blocks can allocate and deallocate individually. That
requires a small overhead, but it would be a smart implementation
strategy for blocks that contain large arrays. Or at least a code-
generation option, if not default behavior.

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.

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.

[Kaz Kylheku]

On Feb 29, 3:37*pm, jacob navia <[e-mail]:

CBFalconer wrote:

jacob navia wrote:

Kaz Kylheku wrote:

>In principle, blocks can allocate and deallocate individually. That
requires a small overhead, but it would be a smart implementation
strategy for blocks that contain large arrays. Or at least a code-
generation option, if not default behavior.
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.

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.