Re: [avr-gcc-list] Re: Optimisation of bit set/clear in uint32_t

[Graham Davies]

Dale Whitfield wrote:

> ... volatile is poorly defined to start with.

This just isn't true.  Volatile is as well defined as most other advanced 
features of the language.  The problem is that it is poorly understood and 
unevenly implemented.

I know what Linus said about volatile and this statement is typical of him. 
There is some truth burried in there, but he goes to far and on the whole it 
is best to ignore him.  Listening to Linus is a great way to stay 
closed-minded and not learn anything.  You also have to bear in mind the 
context in which he is working.

Linus is correct that "volatile ... doesn't inform the compiler enough about 
what the effect of an access could be under various different situations." 
Nobody ever said it does (or, I should say, nobody who understands the 
issues).  The set of synchronization problems that volatile solves is well 
known.  For the others, we have atomic access, semaphores, cache flush 
instructions, snooping, etc.  These operate outside of the language and must 
be understood by the programmer *in addition* to mastering the language. 
This is kind-of what Linus was getting at.  Some people working with the 
Linux kernel incorrectly assumed that volatile would solve all their 
problems.  (I have worked with people who thought that volatile prevented a 
processor from caching the data.)  He is trying to set these people right, 
but rather than explain volatile properly, he just fires his blunderbuss of 
words at it and says that it's "weak and useless".  Many advanced techniques 
look weak and useless if you don't take the trouble to understand them.  So, 
the rest of the quote is just rubbish.

Graham.