AVR-Chat

I've been following this discussion with some amusement and even some interest at times.  :-)

Some folks have said that volatile is not a good keyword choice for what it instructs the compiler to do, but I think it is a great word, because it accurately describes the nature of the storage that it qualifies.  A quick look in the dictionary shows several definitions:

vol·a·tile   [vol-uh-tl, -til or, especially Brit., -tahyl]  Show IPA
adjective
1. evaporating rapidly; passing off readily in the form ofvapor: Acetone is a volatile solvent.
2. tending or threatening to break out into open violence;explosive: a volatile political situation.
3. changeable; mercurial; flighty: a volatile disposition.
4. (of prices, values, etc.) tending to fluctuate sharply andregularly: volatile market conditions.
5. fleeting; transient: volatile beauty.

Ignoring definitions 1 and 2, it's not a liquid, and it's not going to explode. :-)  But definitions 3, 4, and 5 are all relevant and applicable.

The essence of it is that it instructs the compiler that this "storage area", is, as the name implies, volatile.  Meaning, the content may change outside of the compiler's compile-time knowledge, or, in the case of some hardware ports/registers, accesses to said storage have side effects hardware related side-effects (clearing of certain bits after a read, and things like that).  Therefore, the compiler will not read a volatile storage area and save it in a register or other location for more rapid use later (an optimization).  It also must not change the order of execution of other operations before or after a volatile storage area is read or written.  Quite simply, a storage area declared with the volatile attribute, is volatile and can change "out of band", or have side-effects, and therefore it's value can never be saved or assumed by the compiler, it must always be accessed directly each and every time as directed by the programmer.

Therefore, I think the writers of the C standard chose a good name for the volatile type qualifier.  And it's usage is really pretty straightforward.  Yes, it sometimes trips up newcomers to embedded programming, low level OS programming, and so forth.  But that's just the learning curve that we all went through.  Hopefully when newcomers ask those questions, which usually start out saying that the compiler has a bug, haha, we are nice and can direct them to the FAQ, cut and paste the standard answer, etc.  We were all there at one time.  :-)

-Brian
-- 
Brian Dean
BDMICRO LLC
http://www.bdmicro.com/


On Apr 20, 2012, at 7:11 PM, R E Purcella wrote:

> I think you are nit picking words.
> 
> Optimized value was explained by Gregory N.
> 
> Many C, C++ code lines are directives to the compiler: include, define . 
> . . Apparently volatile is as well.
> 
> I suppose that volatile is indeed far more complex in execution. But, 
> hardly needed in order to type in "volatile int speed;" So long as I do 
> understand that speed might be changed in unexpected ways by the 
> compiler when it optimizes my code. I therefore protect my code, and 
> variable, by saying VOLATILE. Use volatile variables in ISR routines or 
> strange things happen.
> 
> I see it then as an optimization switch. Namely, optimization gets 
> turned off for the code where a volatile variable occurs.
> 
> And that has been the gobblegook point of several writers all along.
> 
> rep
> 
> 
> 
> On 4/20/2012 7:04 AM, bayramdavies wrote:
>> 
>> 
>> 
>> R E Purcella wrote:
>> 
>>> ... "the complete reference C++" by Herbert
>>> Schildt, third edition ... [says] ... "The
>>> modifier volatile tells the compiler that a
>>> variable's value may be changed in ways not
>>> explicitly specified by the program."
>> 
>> You see, this isn't actually correct. I think the author is trying to 
>> make a compromise between telling us what the volatile type qualifier 
>> (not "modifier", there's the first mistake) actually is and when to 
>> use it. Sentences involving what you "tell the compiler" are always 
>> going to be tricky. If you're "telling" the compiler anything with the 
>> volatile qualifier, you're telling it that accesses to the qualified 
>> object (not variable, second mistake) must be done in strict 
>> conformity with the abstract machine used to define the semantics of 
>> the C language in the specification. You're not telling the compiler 
>> why you're asking for this (third mistake) and the "value may be 
>> changed in ways not explicitly specified by the program" is only one 
>> of the reasons you might want strict conformance (fourth mistake).
>> 
>>> My friend says "... you need to declare that
>>> variable as volatile, to tell the compiler
>>> to not use the optimized value ..."
>> 
>> What the heck is "the optimized value"? This is nonsense. If you think 
>> you understand it, then that's because you think you already 
>> understand volatile and you're able to map this gobbledygook onto your 
>> understanding.
>> 
>>> So I understand him to be saying Volatile
>>> tells the compiler 1) not to use an optimized
>>> value 2) not to assume that the value hasn't
>>> changed
>> 
>> This is a poor description of volatile for reasons presented above.
>> 
>> I have yet to come across a description of volatile that conforms to 
>> what is written in the standard, is complete, correct and is in all 
>> situations helpful to people who do not fully understand the 
>> terminology of the standard, compilation and software engineering in 
>> general. I am starting to think that nobody would read such a 
>> description as it would necessarily be quite long and people's 
>> preference is for short over complete and correct.
>> 
>> You might think, for example, that Keil (part of ARM) could get this 
>> right. But, they gave the job of writing this description of the 
>> volatile type qualifier:
>> 
>> http://www.keil.com/support/man/docs/c51/c51_le_volatile.htm
>> 
>> to someone who has a pretty good understanding of the C language but 
>> no understanding of hardware. Can you spot the glaring problem?
>> 
>> Graham Davies
>> ECROS Technology
>> www.ecrostech.com
>> 
>> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>