Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

[John Regehr]

> Well, isn't the net effect of volatile simply a more fine-grained clobbering 
> lock?

Almost but not quite:

- volatile says nothing about the atomicity of any given access

- volatile does not suppress reordering (except with other volatiles)

- volatile has no effect on caches and out-of-order memory subsystems (not 
an issue for AVR obviously)

Basically volatile has the effect of sucking in programmers and then 
leaving them high and dry as system complexity increases.

Also volatile is usually too fine-grained, ensuring consistency-always 
instead of what you want (consistency on lock release) and this can easily 
lead to inefficiencies.

> That's a counter-intuitive result. The "No idea why." part makes me a little 
> squinty-eyed.  It certainly *could* be a generalizable result, but then again 
> it might be an artifact of your code structure.

Yep.

My off-the-wall guess was that the clobbers reduced register pressure.  I 
could not think of an easy way to test that hypothesis.

Finally I'll just add a random plug for a piece of work that a colleague 
and I recently completed where we found that most compilers have problems 
implementing the volatile qualifier:

  http://www.cs.utah.edu/~regehr/papers/emsoft08_submit.pdf

This is indeed bad news since (as we have seen so many times on this list) 
programmers have trouble with volatile too.

Section 2 of our paper gives a fairly concise introduction to the 
semantics of volatile.

John