AVR-Chat

On Apr 21, 2012, at 10:02 AM, Robert Adsett wrote:

> On 4/20/2012 9:49 PM, Brian Dean wrote:
> > 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,
> 
> Actually it doesn't. If it did
> 
> const volatile int f;
> 
> would be invalid, rather than being useful.

Not at all.  Const merely instructs the compiler that the storage that it qualifies is read-only.  It can still be volatile.  The two terms neither conflict nor are inconsistent when used together.  For example, if the hardware implements flags in a register such that a bit is automatically cleared when it is read, and that status register is also read-only, i.e., the programmer cannot write to the status register, then it is both const and volatile.  There is no inconsistency here, and the term volatile certainly applies.  I.e., by it's very nature, just using the dictionary definition of volatile, if simply "looking" at something (reading it) causes it to change, most reasonable people would call that volatile.  To me, that meets the very definition of volatile.  The nature of the status register that it cannot be written to, makes it 'const'.


> Note also that const does not mean constant.

We agree.  But I don't recall saying that it did.


> > 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).
> 
> That extends the dictionary definition beyond recognition. The 
> comparison to the standard english meaning of volatile breaks down here.

Not at all.  See explanation above.  As stated above, when dealing with hardware registers as opposed to memory, one does not have actually write to a location for it to change.  We have all dealt with hardware where reading a location's value causes it to change, a fairly common case being status registers where the hardware implementors implicitly clear status bits when the register is read.


> As far as volatile being misnamed it's not the first time programming 
> languages have taken a general term and given it a definition that isn't 
> strongly related to it's usual definition and it won't be the last. I 
> haven't heard a better suggestion and it's too late in any case.

I respectfully disagree.  I have tried to make the case for it above, I think it is a highly accurate keyword that accurately describes the nature of the storage to which it is applied.


> Actually the definitions of const and volatile leave a gaping hole in 
> the qualifications needed for I/O register access. They provide no way 
> to define a write only variable. There no way to inform the compiler 
> that a particular variable may not be read.

This is true, but it is not the fault of 'volatile' or 'const'.  They accurately describe the nature of the storage to which they are applied.  If there is a gap, it is the lack of an additional type qualifier, not the fault of the existing one's because they serve their intended purpose concisely and accurately.  The fact that the C language doesn't have a qualifier for specifying storage that is write-only is unrelated to any deficiency in 'volatile' or 'const'.

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