[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: Re: [avr-gcc-list] Problem with delay loop
Date: Tue, 02 Oct 2007 10:47:38 +0200
User-agent: Thunderbird (Windows/20070728)

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

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:


And to quote from

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]