|Global versus Stack variables email@example.com (shrey) (2005-11-19)|
|Re: Global versus Stack variables firstname.lastname@example.org (email@example.com) (2005-11-21)|
|Re: Global versus Stack variables firstname.lastname@example.org (glen herrmannsfeldt) (2005-11-21)|
|Re: Global versus Stack variables email@example.com (2005-11-21)|
|Re: Global versus Stack variables firstname.lastname@example.org (2005-11-21)|
|Re: Global versus Stack variables email@example.com (Jatin Bhateja) (2005-11-26)|
|Re: Global versus Stack variables firstname.lastname@example.org (2005-11-26)|
|Re: Global versus Stack variables email@example.com (Dave Thompson) (2005-12-05)|
|From:||Dave Thompson <firstname.lastname@example.org>|
|Date:||5 Dec 2005 02:54:51 -0500|
|Posted-Date:||05 Dec 2005 02:54:51 EST|
On 21 Nov 2005 22:40:47 -0500, "email@example.com"
> * Dependency and data flow analysis is more practical with local
> variables as the compiler doesn't need to worry about the contained
> values changing between function calls (same holds for concurrent
It needs to worry _less_ about hidden changes. In algolian languages
other than C's immediate family, if a routine P calls its child C, or
another descendant S of P does so, locals in P can change.
> modification of variables). C bypasses these problems by assuming
> everything is is effectively local (during dependency, etc analysis)
> unless a var is declared volatile.
If by 'effectively local' you mean unaliasable, not true. Classical C
(following BCPL) assumed a classic global memory; standard C adds only
the restriction that accesses must use the correct type (within small
variations such as unsigned versus signed integer of the same rank)
_or_ a character (which in C means byte) type. E.g. an 'int' pointer
target (or object) can be assumed nonaliased with a 'float' one.
'volatile' was originally intended for things like memory-mapped I/O,
and may also be useful for multi-threading and particularly
multi-processing, although most if not all threading schemes (now)
have their own memory controls instead.
The 99 revision adds a new type of pointer qualification 'restrict'
which explicitly promises something is not aliased, effectively like
Fortran dummies/formals but for actual variables as well.
> int b, c;
> for(int i=0; i<=10; i++) b[i]=4;
> if(c==4) //a good optimizer should probably
A barely adequate optimizer should put c in a register or elide it
entirely and _not_ print Foo. And probably b and the loop, since
there are provably no reads from it in this trivial case.
Aside: standard C allows an implementation to require (because some
platforms do) that the last output to a text file, which stdout is,
end with a newline \n. But your example wasn't a whole program, and
this is irrelevant to the point at issue.
> Although yes, things like that are *probably* an error (and exceedingly
> dependant on the order of vars on the stack) :)
And alignment. Or more generally layout.
> [Things like that are definitely an error if your program purports to be
> in ANSI C. -John]
Right. Or even just portable C, since stack layout has always been up
to the implementation and has in fact varied.
- David.Thompson1 at worldnet.att.net
Return to the
Search the comp.compilers archives again.