Re: Global versus Stack variables
- From: Dave Thompson <david.thompson1@xxxxxxxxxxxxxxxx>
- Date: 5 Dec 2005 02:54:51 -0500
On 21 Nov 2005 22:40:47 -0500, "oliverhunt@xxxxxxxxx"
<oliverhunt@xxxxxxxxx> 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
.
- Prev by Date: Re: Assembler using Lex/Yacc
- Next by Date: Re: lex question
- Previous by thread: Re: array bounds checking
- Next by thread: WANTED: One good retargettable compiler back end
- Index(es):
Relevant Pages
|
|
