On Fri, 21 Mar 2008, Peter Todd wrote:

> Gotta love compilers... On SDCC 2.6.0 the following:
>
> LATC = 1 << i;
>
> Compiled to this:
>
> ;       .line   32; driver.c    LATC = 1 << i;
> MOVLW   0x01
> MOVWF   _LATC
> MOVF    r0x00, W
> BZ      _00111_DS_
> NEGF    WREG
> BCF     STATUS, 0
> _00112_DS_:
> RLCF    _LATC, F
> ADDLW
> 0x01
> BNC
> _00112_DS_
> _00111_DS_:

The standard's definition of "volatile" is somewhat vague, but I think
any reasonable person would consider the above code to violate the
volatile qualifier.  The exact definition is

"An object that has volatile-qualified type may be modified in ways
unknown to the implementation or have other unknown side effects.
Therefore any expression referring to such an object shall be
evaluated strictly according to the rules of the abstract machine, as
described in 5.1.2.3."

5.1.2.3 says,

"Accessing a volatile object, modifying an object, modifying a file,
or calling a function that does any of those operations are all side
effects which are changes in the state of the execution environment.

In the abstract machine, all expressions are evaluated as specified by
the semantics. An actual implementation need not evaluate part of an
expression if it can deduce that its value is not used and that no
needed side effects are produced (including any caused by calling a
function or accessing a volatile object)."

This clearly forbids an implementation from optimizing away an access
to a volatile object, but I can't see where it forbids "additional"
accesses to a volatile object, though I would say it's implied by the
statement that it may "have other unknown side effects."

--
John W. Temples, III
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist