Re: Global versus Stack variables

On 21 Nov 2005 22:40:47 -0500, "oliverhunt@gmail.com"
<oliverhunt@gmail.com> wrote:


> * 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.


<snip>
> int b[10], c;
> c=5;
> for(int i=0; i<=10; i++) b[i]=4;
> if(c==4) //a good optimizer should probably
> printf("Foo!");


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.


> --Oliver
> [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 comp.compilers page.
Search the comp.compilers archives again.