bob wrote:
In the construct <load value> < OR > <save value>, it just doesn't make
sense to me to cheat on the OR'ing but not on the load/save part.
OK, that's fine, but the problem is in what makes sense to you, not in what
the compiler is doing. Please read over more carefully what I wrote in my
previous reply. Again, when loading and storing, the compiler is
constrained by the use of the volatile storage qualifier to do exactly what
the programmer writes, i.e. fetch a 32-bit value from a variable and later
write back a 32-bit variable. In between, we tell the compiler to modify
the value in a fixed way (known at compile time). The *value* is not
volatile, it's just a pattern of bits. The compiler can use any tricks it
wants to perform the modification as long as the result is always the same
as doing it the stupid and obvious way. Modifying the value (performing the
OR operation) has no effect on the variable until it is written back. So
the volatile storage qualifier has no effect on how the compiler contrives
to perform the modification, only on how it gets written back.
Your thread argument is true but would be broken by the current compiler
action ...
The compiler does not know about threads or any form of concurrent access to
a variable. The compiler only knows what you tell it in a single
translation unit (C file and included header files). The compiler does not
know what is memory and what is a special function register. You have to
look after all this with a) the volatile storage qualifier (which disables
certain optimizations) and b) tricks to ensure that multi-access variables
are changed in an atomic fashion. These two are separate. The volatile
declaration will not make the compiler ensure atomic access.
Graham.
P.S. The use and effect of the volatile storage qualifier is one of the
most misunderstood aspects of the C language. So, with due respect to all
concerned, those who know (or suspect) that they are *not experts* would do
better to stay out of this discussion thread.
_______________________________________________
AVR-chat mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-chat
