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

[Eric Weddington]

> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of Paulo Marques
> Sent: Monday, October 01, 2007 7:35 AM
> To: David Brown
> Cc: 'AVR-GCC'
> Subject: Re: [avr-gcc-list] Problem with delay loop
>
> David Brown wrote:
> > [...]
> > it could perhaps reason
> > that since there is no way for anything outside the program
> to find out
> > where the local volatile variable resides, there is no way
> for anything
> > else to influence or use the variable, and therefore the "volatile"
> > qualifier can be ignored.
>
> This sentence makes no sense at all. The "volatile" is
> precisely to warn
> the compiler that it should not "reason" anything about this variable.
>
> If you give a volatile qualifier to a local variable, it's
> obvious that
> you want it to behave differently from regular local variables, so I
> think gcc is doing the best it can, from the weakly defined volatile
> semantics.
>
> This makes as much sense as saying that any volatile is futile, since
> you can compile a program with "-combine -whole-program" and so the
> compiler can always "reason" that any variable will not be accessed
> outside of its control.

There is one other case for a volatile variable, and that is the case of
hardware modifying the variable, which can easily happen in registers. This
is another case of "something outside the program" modifying the variable.

I agree with the statement above that "'volatile' is precisely to warn the
compiler that it should not 'reason' anything about [the] variable".
However, David brings up a good point. A local variable is put on the stack,
generally not the place for hardware to modify the variable. And generally,
other parts of the program (such as ISRs) don't have access to the specific
location of the variable on the stack. Both hardware and ISRs work with
global variables. So *could* a compiler reason that local variables could
never be volatile? Or are there truly situations where hardware or ISRs
could modify local variables on the stack?

Its an interesting question. I'm not sure what the answer is. Perhaps a
language lawyer on comp.lang.c could explain the reasoning behind the
current standard.

Eric Weddington