On Mon, 28 Jul 2008, Gerhard Fiedler wrote:

> sergio masci wrote:
> 
> > You may not be able to assign a value to "arr" from within C but that 
> > doesn't mean the address of "arr" is a constant at run time. The address 
> > of "arr" is set on entry to the function and may change from one 
> > invokation to another. 
> 
> Yes, of course (in a typical stack-based C implementation). But a local arr
> ceases to exist after the end of the block, and during its lifetime its
> address is constant. The next invocation of the function is a new life, so
> to speak. I'm not sure where you want to go with this... arr, as declared
> here, is defined as being constant, by the C standard.

Where do I want to go with this?

What I really want to do is get across to the average C user that although 
"arr" may seem to be a constant it is actually (usually) a runtime 
variable and has overheads associated with its use.

Comments about how easily access to an indexed array element can be 
optimised to a direct access with (implied) no runtime overhead are very 
misleading (I'm not pointing at anyone in particular here).

> > Come on you can't base a function optimisation argument on what happens
> > in "main"
> 
> FWIW, my preceding comment is valid for any function like the above
> (whether main() or further down in the call tree), with a local variable
> that is only set, never read and isn't declared volatile.

Yes but it is VERY easy to optimise some things in "main" because it is 
known to be the first function called at runtime. Trying to do similar 
optimisations for other functions requires a lot of work on the part of 
the compiler.


Regards
Sergio
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist