On 21/09/2011 20:50, Georg-Johann Lay wrote:
David Brown schrieb:
On 21/09/2011 15:57, Ian Lance Taylor wrote:
David Brown<da...@westcontrol.com> writes:
On 21/09/2011 10:21, Paulo J. Matos wrote:
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change the nature of "foo" - the compiler can still implement it as a
compile-time constant.
But since I am accessing the data through the pointer and the pointer
qualifies the data as volatile, shouldn't the compiler avoid this kind
of optimization for reads through the pointer?
My thought is that the nature of "foo" is independent of how it is
accessed. On the other hand, some uses of a variable will affect its
implementation - if you take the address of "foo" and pass that on to
an external function or data, then the compiler would have to generate
"foo" in memory (but in read-only memory, and it can still assume its
value does not change). So I am not sure what the "correct" behaviour
is here - I merely ask the question.
Fortunately, this situation is not going to occur in real code.
I think your description is supported by the standard. However, I also
think that gcc should endeavor to fully honor the volatile qualifier in
all cases, because that is least surprising to the programmer. This is
not a case where we should let optimization override the programmer's
desire; by using volatile, the programmer has explicitly told us that
they do not want any optimization to occur.
ACK.
That makes sense - the principle of least surprise. And since this
situation would not occur in real code (at least, not code that is
expected to do something useful other than test the compiler's code
generation), there is no harm in making sub-optimal object code.
Are there any warning flags for "programmer doing something
technically legal but logically daft", that could be triggered by such
cases? :-)
The combination of const and volatile can be reasonable in real world code.
One example is a special function register (SFR) that is read-only but
can be altered by hardware.
That is /very/ different - you are talking about an "extern volatile
const uint8_t readOnlySFR" declaration, or something effectively like:
#define readOnlySFR (*(volatile const uint8_t *) 0x1234)
Either way, what you are telling the compiler is that this item is
"volatile", and may change it's value unbeknownst to the compiler, and
that is "const", meaning that /your/ code may not change its value.
That's fine, and consistent. It might sound strange at first - many
people think "const" means the data is constant and cannot change, when
in fact C has its one peculiar meaning for "const".
What can't make sense is a /static/ "volatile const" which is /defined/
locally, rather than just declared.
Second example is a lookup table that can be changed after building the
software, e.g. you have some calibration data that has to be drawn from
the environment (drift of sensors, inductivity of motor windings, offset
of actors, etc). In such a case you want to read the data from the
lookup table in, say, .rodata. By no means you want the compiler to
insert/propagate known values from the lookup table to immediate
operands in instructions. That's exacly what "const volatile" does.
Again, you are talking about a "volatile const" declaration of data that
is defined externally, and that's okay.
Also note that in this case the local static const data is not volatile
- it is only accessed as a volatile through a pointer cast.
