Re: [avr-gcc-list] "Volatile"

[Graham Davies]

Dean Hall wrote:

> With respect, Graham, I think you may
> have misunderstood the "cached"
> terminology here.

Well, no, in the incident I referred to, we were working on a StrongARM and
the cache in question was the 16 Kbyte, 32-way, set-associative data cache.
Although I know it's hard to believe, several engineers has been hired to
work on this project and had no idea what the static and voltatile storage
qualifiers do, let alone how to set up the MMU to control which memory areas
are cached.  My point being that the OP should not feel bad about tripping
up where he did.

> *****
> Using volatile is a directive to the compiler to always load/store that
> variable from/to memory every time it is referenced in the source code.
> *****

Or, it is a directive to produce code that nit-pickingly follows the
operation of the virtual machine that is at the core of the C language
definition.  Which, I think, amounts to the same thing, but may be more
complete.

> volatile v = 42;
> v = ((v=12) | (~v) | (!v));
> ...  Is v equal to twelve or forty two when ~v is executed?

I'm not sure that this issue is influenced by the volatile qualifier.  Even
without it, I don't think the language standard makes any guarantees about
the order in which sub-expressions are evaluated in a single statement.  So,
your advice is good always, not only when volatile is used.  Or, you could
avoid sub-expressions with side effects and not be constrained to simple
statements.

> Also be aware that the compiler is within its right to convert the line
> "v = 42;" into two, three, or N identical store instructions, even
> though it is redundant.

Er, my point was that this is not allowed if v is declared volatile.

> No compiler I know would do this ...

A better example would be v &= 0x03; which a compiler might consider mapping
to two set bit instructions if they are present and particularly efficient.
This is not permitted if v is volatile - v must be read into temporary
store, the two bits set and the result written back to v.  One read and one
write.

> ... one must not rely on optimal C-to-ASM translation,
> only on logical behavior.  If one needs exact assembly
> instructions, one should write in assembly.

Well, this is exactly where we went before.  We ended up, however, with
actual quotes from the standard and, although we could wish it to be
clearer, concluded that the language does give us the right to expect
certain well defined behaviors for volatile variables, including that one
assignment results in exactly one write.  The issue of what you should
actually do in practice turns into one of how much trust you should place in
the conformance of your compiler.

Again, the OP should take heart that volatile is much misunderstood.  I
stand ready to learn more about it myself.

Graham.