Re: [avr-gcc-list] Problem with delay loop

[David Brown]

Graham Davies wrote:
> Eric Weddington wrote:
> > ... We were discussing the possibility of the compiler being
> > smarter about 'volatile' and local automatic variables. I would
> > definitely say that if the local variable's address is taken, then
> > all bets are off.
>
> Second point first.  If the address of a variable is taken then the 
> compiler cannot put it in a register.  If it is declared automatic,
> it goes on the stack, if there is one, or somewhere else in memory if
> there

Actually, you're slightly wrong on both accounts here.  On the AVR, the
registers are available in the memory map, so it is possible to take
their addresses (it's not commonly done, except perhaps on the old
RAM-less Tiny's, but it's possible).  Secondly, "automatic" variables
can be allocated in registers - they don't have to go on the stack (or
in memory).

> isn't.  We put the address of variables on the stack into globals at
> our peril, but get away with it if we know what we're doing.  Nobody
>  disagreed with any of this, but I thought it worth saying.

> First point second.  I think I agree with you about the possibility
> of the compiler being really smart and figuring out that no way could
> a variable be seen outside of the local scope so to hell with it.
> But, the standard doesn't take that approach so such a compiler would
> be non-standard.  I disagree with the people saying that the standard
> isn't very clear about what volatile means.  I think it's very clear.
> A conforming compiler will never optimize away any access to a
> volatile variable.  Nor will it perform additional accesses, for
> example by using it to store intermediate values in a calculation.  I
> think the idea that the standard isn't clear comes from
> non-conforming compilers.

There are a few things regarding "volatile" that are not well specified
in the standards, and there are a few differences between the keyword in
C and C++ (just to add to the possible confusion).  As with many such
cases, these have little impact on well-written code in practice, but
they are still issues to consider:

http://gcc.gnu.org/onlinedocs/gcc/Volatiles.html

And to quote from
http://gcc.gnu.org/onlinedocs/gcc/Qualifiers-implementation.html:

> However, if the volatile storage is not being modified, and the value
> of the volatile storage is not used, then the situation is less
> obvious. For example
>
> volatile int *src = somevalue; *src;
>
>
> According to the C standard, such an expression is an rvalue whose
> type is the unqualified version of its original type, i.e. int.
> Whether GCC interprets this as a read of the volatile object being
> pointed to or only as a request to evaluate the expression for its
> side-effects depends on this type.
>
> If it is a scalar type, or on most targets an aggregate type whose
> only member object is of a scalar type, or a union type whose member
> objects are of scalar types, the expression is interpreted by GCC as
> a read of the volatile object; in the other cases, the expression is
> only evaluated for its side-effects.

mvh.,

David