What is a stack frame?

[CBFalconer]

[...]

Basic knowledge about compiler code generation is needed if you
want to be able to understand what is going on within your
program.

[...]

What's even more important is an understanding of the difference
between a programming language (as defined by a standard) and a
particular implementation of that language. This is a
distinction that you insist in blurring.

Funny. Where (yes WHERE) in my message did I mention something
implementation specific?

Right here:

"Within a stack, each procedure builds a "stack frame", i.e. a
fixed point within the stack, where storage for local variables
is reserved."

Which showed up at the beginning of your off-topic post.

 

[Richard]

The point is that this is not suitable for c.l.c.
comp.compilers.lcc would be suitable, as would other suggestions
that have been made. The c language implementation MAY use a
stack, but does not have to. Therefore stacks (except actual code
to implement one) are off-topic on c.l.c. I believe you have had
this explained to you earlier. In fact, several times.

Stacks or the "concept" of stacks are important for programmers and give
something concrete to think of when discussing automatic variables.

Does your pedantry know no bounds?

 

[Kenny McCormack]

Stacks or the "concept" of stacks are important for programmers and give
something concrete to think of when discussing automatic variables.

Does your pedantry know no bounds?

I see what you mean.

 

[Keith Thompson]

Basic knowledge about compiler code generation is needed if you want
to be able to understand what is going on within your program.

[...]

What's even more important is an understanding of the difference
between a programming language (as defined by a standard) and a
particular implementation of that language. This is a distinction
that you insist in blurring.

Funny.

Where (yes WHERE) in my message did I mention something
implementation specific?

Seriously? Practically all of it was implementation specific. (That
doesn't mean it's specific to any one particular implementation.)

Equally to the point, apart from briefly using C to describe the
representation of a stack frame, it really had no more to do with C
than with any other compiled language.

 

[Richard Bos]

My compiler system can be freely downloaded at no charge.

Spam is related to the frequency of the advertisement, not to the
average financial proceeds thereof. By that measure alone, your posts
_would_ be spam. But IMO, your posting your URL _in your sig_ is not
spam. That (amongst others) is what sigs are for, after all. What
irritates me about this whole thread, and most others you start, is that
they're massively system-specific, and you seem too thick to (want to)
realise this.

Richard

 

[Nick Keighley]

Yes, there is. The stack pointer is implicitly the frame pointer.

As you explain later, the debug information fills the missing gaps so
that a debugger can walk the stack...

The linked list is conceptually there, no longer explicit but implicit

'Oh, that was easy' says Jacob, and for an encore goes on to prove
that black is white and gets himself killed on the next zebra
crossing.

 

[Keith Thompson]

Spam is related to the frequency of the advertisement, not to the
average financial proceeds thereof. By that measure alone, your posts
_would_ be spam. But IMO, your posting your URL _in your sig_ is not
spam. That (amongst others) is what sigs are for, after all. What
irritates me about this whole thread, and most others you start, is that
they're massively system-specific, and you seem too thick to (want to)
realise this.

There's an unfortunate tendency to use the word "spam" for "any Usenet
posting that annoys me".

The generally accepted definition of Usenet spam is substantially
identical articles posted repeatedly. There's a formula (look up
"Breidbart index") used to determine whether a given spam is bad
enough to warrant third-party cancellation.

Note that it has nothing to do with whether the content is commercial.
Content is irrelevant to the question of whether something is spam;
posting the Gettysburg Address 1000 times, and it's spam.

jacob's posts are not spam by any reasonable definition, and saying
that they are merely weakens the term. and makes the fight against
*real* spam marginally more difficult.

The problem with some of jacob's posts is that they're off-topic.

Personally, I'm not particularly bothered by any partly commercial
nature of his posts. His statement that lcc-win can be freely
downloaded is irrelevant because it's an answer to an irrelevant
charge. If lcc-win were completely free (GPLed, public domain, or
whatever flavor of "free" floats your boat), I would find his advocacy
*here* of its non-standard extensions equally annoying. And of course
he can put whatever he likes in his signature. In his off-topic post
that started this thread, I don't think he even mentioned lcc-win.

 

[Richard Heathfield]

Keith Thompson said:

In his off-topic post
that started this thread, I don't think he even mentioned lcc-win.

That's only because your eyes started to glaze over. You won't be terribly
surprised, I suspect, to discover that you are mistaken on this occasion.

 

[J. F. Lemaire]

There's an unfortunate tendency to use the word "spam" for "any Usenet
posting that annoys me".

I should probably not have used that term in the first place. However, I
suppose the real question is *why* jacob is posting in this newsgroup.
Some may think that he is posting messages to participate in
discussions of some aspects of C. I don't. I think he is posting merely
as a means to attract attention to his commercial software, either
through his signature, which may be acceptable or, which is more
hypocritical, by making more or less subtle mentions of the said
software "just in passing".

And, you are right, this can not be called spam -- even though it is
certainly unwanted and tends to come in bulk. I personally call this
advertisement and, if I'm not mistaken, advertisement is only accepted
on Usenet if it is both nonintrusive and announced as such.

I am personally not annoyed by jacob's messages since I killfiled him
months ago. But I am annoyed by intelligent and knowledgeable people
who keep following him in his nonsensical rants, giving him credit in
the process, and unknowingly helping him maintain his advertisement
enterprise.

 

[santosh]

J. F. Lemaire wrote:

I should probably not have used that term in the first place. However,
I suppose the real question is *why* jacob is posting in this
newsgroup. Some may think that he is posting messages to participate
in discussions of some aspects of C. I don't. I think he is posting
merely as a means to attract attention to his commercial software,
either through his signature, which may be acceptable or, which is
more hypocritical, by making more or less subtle mentions of the said
software "just in passing".

And, you are right, this can not be called spam -- even though it is
certainly unwanted and tends to come in bulk. I personally call this
advertisement and, if I'm not mistaken, advertisement is only accepted
on Usenet if it is both nonintrusive and announced as such.

I am personally not annoyed by jacob's messages since I killfiled him
months ago. But I am annoyed by intelligent and knowledgeable people
who keep following him in his nonsensical rants, giving him credit in
the process, and unknowingly helping him maintain his advertisement
enterprise.

Well, IMO, Jacob's messages may be frequently off-topic (which is their
main objection, from nearly all who respond to him), but are not
nonsensical rants.

Also I personally don't mind his "just in passing" advertisement of his
compiler. Many posters advertise their products too via their
signatures. As long as he doesn't repeatedly mention lcc-win32 it is
fine, IMO.

I would hope that everyone who participates in this group are mature
enough to try out and choose whatever compiler that best suits them,
advertisements notwithstanding.

 

[Keith Thompson]

Keith Thompson said:



That's only because your eyes started to glaze over. You won't be terribly
surprised, I suspect, to discover that you are mistaken on this occasion.

You're right, but he mentions it only briefly as a concrete example of
a more general concept. If the article as a whole had been topical,
his mention of lcc-win wouldn't have been a problem (at least not for
me).

 

[Richard]

J. F. Lemaire wrote:



Well, IMO, Jacob's messages may be frequently off-topic (which is their
main objection, from nearly all who respond to him), but are not
nonsensical rants.

Of course they are not, as any "non clique member" knows. It's just
Heathfield being Heathfield and his unhealthy disposition towards
Jacob. Any why? Because Jacob puts Heathfield in his place. Heathfield
is interested in one opinion - and that is his own. A shame as his
knowledge of C coupled with a less big headed and preposterously huge
self regard would be much more useful to all. The recent thread about
rounding numbers really did it for me. RH purposely misrepresented
everything in order to put Jacob down and elevate himself. It happens
too much.

The group is comp.lang.c and is therefore open to C programmers. And C
programmers in the real world rarely need "ISO C" : they are looking for
like minded folk to chew the cud with and this is the only place for
that on usenet. I for one am glad to see people like Jacob stick up for
common sense. Why shouldnt someone ask here what C programmers prefer to
use as an editor? Why shouldn't they ask for opinions on compilers? Who
are these self appointed guardians? And then we have guys saying "try
google". FFS? Why are they here? What is the line between asking
sentient human beings a question and using google? Who makes these
limits? I await the "we voted on it" rubbish. The only people who voted
were the groups self appointed Gods. Nearly everyone else more moderate
has gone away. The difference between c.l.c is palpable. I for one am
glad to see Kenny haunt these arrogant fools because they are guilty of
taking themselves far too seriously. Just look at the amount of times
they slag someone off only to find they were wrong. They just can not
wait to shout "Off topic!!!!!!!!". Does that "Default User" Brian do
anything but that? All he seems to do is kiss Heathfield's arse and tell
people off for top posting or posting OT. How sad can one individual be?

Half the big dogs in this group either have no social life or they
haven't worked out the basics of killfiles or thread scoring. Not
interested? Don't read it. It really is that simple.

Also I personally don't mind his "just in passing" advertisement of his
compiler. Many posters advertise their products too via their
signatures. As long as he doesn't repeatedly mention lcc-win32 it is
fine, IMO.

CBF is even asking for jobs in his! Well, in ONE of his two signatures
anyway.

I would hope that everyone who participates in this group are mature
enough to try out and choose whatever compiler that best suits them,
advertisements notwithstanding.

Exactly.

Or should I say "Indeed".

 

[Chris Torek]

There is no need for a separate "this frame" pointer [within an

activation record].

And I'm not convinced there's a need for a Previous frame pointer.

Indeed, *if* all activation records are recorded in a single
contiguous array, the "previous" for any given entry is simply
"just before the current entry":

Given a contiguous hardware-managed stack of the kind jacob assumes
(and to which he only barely acknowledges any possible alternatives),
a stack frame could simply keep track of its size. On exit from the
function, the value of the stack pointer is simply adjusted by that
size.

This is in fact what is done on a number of systems.

Access to the contents of the previous stack frame is not
needed, since C doesn't have nested functions and cannot access local
objects in anything other than the current function. (Other
languages, such as Pascal, can do this, and therefore require somewhat
more elaborate stack layouts; in some environments it might make sense
to use such layouts for all compiled languages.)

Right -- and this is probably the main reason why the general
"activation record" data structure, as used in compiler circles,
includes a "previous" pointer. (In addition, "pointer" is just
another abstraction here: even if activation records are not
contiguous, one can use an array index instead of a pointer, if
they are all stored in a single array.)

[example of large arrays with block scope, where a total of

5000 bytes is all that is needed, even though several
compilers use 7000 bytes and thus keep both objects "live"
at all times within the function, even though one or the
other *could* "go dead" at any time outside its block.]

I can't think of any good reason not to perform the simpler
[scope based] optimization (the 5000-byte activation record).

There is one (not so good) reason having to do with debugging,
particularly if the debugger is not able to deal with overlapping
storage (which would give it problems with unions too, but perhaps
the debug format allows overlap *only* for union data types, and
the compiler-writer was unwilling to construct an "internal union
purely to keep the debugger happy).

Allocating storage for each block only when the block is entered
(in effect treating each block as an inline function) imposes
some overhead, but could easily be worthwhile if it saves
substantial space.

Yes. I assume some compilers have flags to control this sort of
thing, though I have not personally used one.

 

[jacob navia]

I should probably not have used that term in the first place. However, I
suppose the real question is *why* jacob is posting in this newsgroup.
Some may think that he is posting messages to participate in
discussions of some aspects of C.

Well, that is obviously my intention. The messages I post are for
discussion and I respect other people's views even if I do not
agree with them.

I don't. I think he is posting merely
as a means to attract attention to his commercial software, either
through his signature, which may be acceptable or, which is more
hypocritical, by making more or less subtle mentions of the said
software "just in passing".

Yes. Sure. My software is SO commercial that you can download it
for free. Can't you see how ridiculous this is?

You can't post something related to the discussion? You think that
a stack frame is a useless concept?

SAY IT!

Argue, discuss. Stop your speculation about my ulterior motives.

And, you are right, this can not be called spam -- even though it is
certainly unwanted and tends to come in bulk. I personally call this
advertisement and, if I'm not mistaken, advertisement is only accepted
on Usenet if it is both nonintrusive and announced as such.

Advertisements of stack frames?

You need to go to a doctor.

I am personally not annoyed by jacob's messages since I killfiled him
months ago.

Well you have a bug in your killfile then. Unable to do anything
correctly, you can't even setup a kill file.

 

[Dik T. Winter]

> But the activation record for a function needn't be a single
> fixed-size chunk, even ignoring VLAs. Local objects exist at block
> scope, not at function scope. Given:
>
> void func(void)
> {
> int x[1000];
> {
> int y[2000];
> }
> {
> int z[4000];
> }
> } ....
> A naive compiler might allocate a single 7000-byte activation record,
> with separate storage for x, y, and z. <OT>gcc does this; oh,
> well.</OT> A slightly more clever compiler might allocate a 5000-byte
> activation record, with storage for y and z overlapped. A more
> ambitious compiler might allocate just a 1000-byte activation record,
> and allocate space for y and z only when their respective blocks are
> entered.

But there may be good reasons to go with the allocation of 5000 bytes.
One reason might be that there are no simple methods to manipulate the
stack pointer directly, e.g., when it is only manipulated by an "enter"
instruction that manipulates both stack and frame pointer that are
invisible for the program.

 

[Keith Thompson]

But the activation record for a function needn't be a single
fixed-size chunk, even ignoring VLAs. Local objects exist at block
scope, not at function scope. Given:

void func(void)
{
int x[1000];
{
int y[2000];
}
{
int z[4000];
}
} ...
A naive compiler might allocate a single 7000-byte activation record,
with separate storage for x, y, and z. <OT>gcc does this; oh,
well.</OT> A slightly more clever compiler might allocate a 5000-byte
activation record, with storage for y and z overlapped. A more
ambitious compiler might allocate just a 1000-byte activation record,
and allocate space for y and z only when their respective blocks are
entered.

But there may be good reasons to go with the allocation of 5000 bytes.
One reason might be that there are no simple methods to manipulate the
stack pointer directly, e.g., when it is only manipulated by an "enter"
instruction that manipulates both stack and frame pointer that are
invisible for the program.

Hmm. Manipulating the stack would have to be impossible, not just to
the C program, but to the machine code generated by the compiler.
That seems implausibly strict, and it would make VLAs impossible to
implement other than by using malloc or some near equivalent.

Such an architecture is certainly possible, but I'd be surprised if it
actually existed.

To get back to terms relevant to standard C, suppose there's a
function call in the block that declares y. I'd be surprised to see
an implementation where, for fundamental architectural reasons, space
has to be allocated for z while that function call is being executed.
This could be *extremely* wasteful in the case of deep recursion,
where you could have multiple useless copies of z.

On the other hand, some compilers probably do allocate space for z
just because it's easier, or because allocating and deallocating
block-local objects carries some overhead. And there's probably not a
whole lot of code that would benefit greatly from the optimization of
delaying the allocation; most programmers probably don't declare large
block-local variables in the expectation that it will save space
outside the block.

There's probably something of a vicious circle between compilers not
doing the optimization and programmers not writing code that could
take advantage of it.

 

[Neil]

Basic knowledge about compiler code generation is needed if you want
to be able to understand what is going on within your program.

[...]

What's even more important is an understanding of the difference
between a programming language (as defined by a standard) and a
particular implementation of that language. This is a distinction
that you insist in blurring.

Funny.

Where (yes WHERE) in my message did I mention something
implementation specific?

This would assume the CPUs with no Frame pointers or Parameter Stack
could not run C. But they can, and do. While what you show is widely
used on larger CPUs it is not a requirement to do it that way. The C
spec does not care.

 

[Antoninus Twink]

Of course they are not, as any "non clique member" knows. It's just
Heathfield being Heathfield and his unhealthy disposition towards
Jacob. Any why? Because Jacob puts Heathfield in his place. Heathfield
is interested in one opinion - and that is his own. A shame as his
knowledge of C coupled with a less big headed and preposterously huge
self regard would be much more useful to all. The recent thread about
rounding numbers really did it for me. RH purposely misrepresented
everything in order to put Jacob down and elevate himself. It happens
too much.

The group is comp.lang.c and is therefore open to C programmers. And C
programmers in the real world rarely need "ISO C" : they are looking for
like minded folk to chew the cud with and this is the only place for
that on usenet. I for one am glad to see people like Jacob stick up for
common sense. Why shouldnt someone ask here what C programmers prefer to
use as an editor? Why shouldn't they ask for opinions on compilers? Who
are these self appointed guardians? And then we have guys saying "try
google". FFS? Why are they here? What is the line between asking
sentient human beings a question and using google? Who makes these
limits? I await the "we voted on it" rubbish. The only people who voted
were the groups self appointed Gods. Nearly everyone else more moderate
has gone away. The difference between c.l.c is palpable. I for one am
glad to see Kenny haunt these arrogant fools because they are guilty of
taking themselves far too seriously. Just look at the amount of times
they slag someone off only to find they were wrong. They just can not
wait to shout "Off topic!!!!!!!!". Does that "Default User" Brian do
anything but that? All he seems to do is kiss Heathfield's arse and tell
people off for top posting or posting OT. How sad can one individual be?

Half the big dogs in this group either have no social life or they
haven't worked out the basics of killfiles or thread scoring. Not
interested? Don't read it. It really is that simple.

A great post that says it all, really.

It should be added to the CLC FAQ:
Q. What the hell's up with CLC?
A. As above.

 

[Dik T. Winter]

>
> Hmm. Manipulating the stack would have to be impossible, not just to
> the C program, but to the machine code generated by the compiler.
> That seems implausibly strict, and it would make VLAs impossible to
> implement other than by using malloc or some near equivalent.

I have used an Algol 68 compiler that did put nearly everything on the
heap for efficiency. So it is not so very bad.

> Such an architecture is certainly possible, but I'd be surprised if it
> actually existed.

If I remember right, the NS 32000.

 

[Keith Thompson]

If I remember right, the NS 32000.

I am duly surprised.