Paulo Marques wrote:
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.
I think the standards are pretty vague regarding exactly what "volatile"
means. There is nothing (that I know of) in the standards saying where
a volatile variable must be allocated.
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.
It may be obvious to *you*, as the author, that you mean "volatile" to
work like this. It certainly works like that on avr-gcc at the moment.
But what appears "obvious" to programmers (even expert experienced
programmers), and what the standards say, what the compiler does, and
how it all works on the target in question, can be very different
things. When working with bigger cpus with caches and instruction
re-ordering, for example, "volatile" is not nearly strong enough to give
you the kind of guarantees we take for granted on avr-gcc.
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.
No, it's not quite the same. In particular, if the variable's address
is known outside the code (for example, if it is given a fixed address,
such as by the definition of the port I/O registers), then there is no
way the compiler could make guarantees about the safety of removing the
"volatile". Similarly, if different globally accessible functions (such
as interrupt functions) accessed the variable, it could not remove the
"volatile". But for local variables within a function, it is much more
straightforward to see how such variables could be accessed or addressed.
Note that I'm not disputing that the compiler could in theory use a
register instead. I personally don't think that would be a good idea,
but it might be allowed by the specs. What I'm disputing is that the
compiler _can not_ ignore the volatile and optimize the loop away
entirely. That would be a compiler bug, for sure.
It would certainly be a surprise to many (including me) if it *did*
remove the volatile variable in practice. But I'm not 100% sure that
the standards disallow such optimisations - that's all I'm saying.
mvh.,
David
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
