Mantorok Redgormor wrote:
6.7.3#6
An object that has volatile-qualified type may be modified in ways unknown
to the implementation or have other unknown side effects.
wouldn't this mean that an object which is volatile could even be modified
between sequence points?
Yes, but the statements in your first post don't follow from that. It's
not clear to me why you would conclude from the passage above that
'volatile' inhibits side-effects. Actually, it's not clear to me what
you mean by "inhibits side-effects", either.
The passage above is for situations such as memory-mapped I/O, when the
value at a particular memory location can change from one read to the
next, for example:
volatile char *vp = (char *)0x802a0010; /* Some device or port address */
char c1, c2;
c1 = *vp;
c2 = *vp;
Normally this could be optimized to something like this:
Get value from address vp, store in register A.
Store value from register A in c1.
Store value from register A in c2.
Because the compiler would normally assume that *vp cannot change unless
it emits code to change it. But since *vp is volatile, the compiler does
not make this assumption, and emits code to actually do two separate reads:
Get value from address vp, store in register A.
Store value from register A in c1.
Get value from address vp, store in register B.
Store value from register B in c2.
While I'm talking specifically about reading volatile objects, the write
situation is analogous. E.g., if you were to write to an object twice
without any kind of read in between, the compiler could assume the first
write is useless and eliminate it, but if the object is volatile, the
compiler won't make that assumption.
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
