RE: [avr-chat] Missed Optimisation ?

[Colin O'Flynn]

Hi All,

Perhaps if the issue comes up again, referring to the ANSI C spec might at
least have some authority? In which case the meaning of volatile is such
defined by 6.7.3-6:

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. Furthermore,
at every sequence point the value last stored in the object shall agree with
that prescribed by the abstract machine, except as modified by the unknown
factors mentioned previously (114). What constitutes an access to an object
that has volatile-qualified type is implementation-defined.

(114): A volatile declaration may be used to describe an object
corresponding to a memory-mapped input/output port or an object accessed by
an asynchronously  interrupting function. Actions on objects so declared
shall not be ''optimized out'' by an implementation or reordered except as
permitted by the rules for evaluating expressions.

Which again sounds exactly as GCC behaved.

Regards,

  -Colin

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of Graham
Davies
Sent: March 1, 2011 4:20 PM
To: address@hidden
Subject: Re: [avr-chat] Missed Optimisation ?

Erik wrote:

> Errrrr ... Bob, if "result" is in RAM, and so can't be changed by
> hardware, and interrupts have not been reenabled (we're in an ISR),
> then how can "result" be volatile?

It's volatile if Bob has declared it volatile.  The compiler doesn't know 
whether Bob is right or wrong to declare it volatile.  Bob is right to 
declare it volatile if, as well as being accessed in this ISR, it is 
accessed by non-interrupt code.  As I've already mentioned, if that is the 
case, interrupts should be disabled during the non-interrupt code access.

> If memory serves me, here "volatile" is nearly as good as beer, for
> starting a discussion. :-)

Even on the avr-gcc group, discussions about this keyword unearth all manner

of misunderstandings.  For some reason, posts by people who know what they 
are talking about are treated with no more authority than posts by people 
who are guessing or writing from incomplete knowledge or an inappropriate 
perspective.  In other words, it seems that people can't even recognize the 
right answer when it is given.  That's not beer, that's religion.

> We have too few maintainers for the avr port, and the rest of us are
> grateful to them, but not enough to compete for the job of making a good
> tool "perfect". Oh, and I wonder if there are more little corner cases
> than we would like to tackle.

In this instance, avr-gcc is working perfectly.

> It doesn't do any harm to keep one's assembler skills honed, and the
> ISRs are usually short enough to be easily done, barring surprises.

Writing in assembler because you don't properly understand the C language 
is, in my opinion, a very bad reason for taking longer to do the job and 
opening up a whole new can of worms in the C-to-assembler interface, which 
you may not properly understand either.

Graham.



_______________________________________________
AVR-chat mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-chat