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: [email protected] [mailto:[email protected]] On Behalf Of Graham Davies Sent: March 1, 2011 4:20 PM To: [email protected] 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 [email protected] http://lists.nongnu.org/mailman/listinfo/avr-chat _______________________________________________ AVR-chat mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-chat
