On Tue, 10 Feb 2009 21:54:41 -0700 "Weddington, Eric" <ewedding...@cso.atmel.com> wrote:
> It is still in the FAQ, and still #1 in the FAQ, in the avr-libc user manual. > It's been that way for many years. Hmm let mcheck again ! ;-) Ohhhh... I can see it ! But I missed it because the FAQ entry doesn't mention the wod "volatile". Other reason is that when I asked my PDF reader to search for "volatile", it found only one occurence or so I thought initially. Pressing some more buttons revealed many more occurences indeed... So I blame poor usability/ininterface design of my PDF reader's search function ! Grr... ;-) > The way volatile was explained to me many years ago, is that a variable must > be declared as "volatile" if it's value can be changed by something outside > of the mainline code. This boils down to two use cases: > - A memory location that can be changed by hardware (i.e. a register) > - A memory location that can be changed by an interrupt service routine (ISR). > > This is why all definitions of I/O registers are marked as volatile. This is > why any variable that is "shared" between the main code and an ISR must be > marked as volatile. > > Now if you have a do-nothing spin loop, that is just being used as a crude > form of delay, then the optimizer can detect that this do-nothing loop is, > well, doing nothing (i.e. no 'side effects' like reading/writing memory) and > so it will correctly optimize it away. To stop the compiler from doing this, > we can 'abuse' the volatile keyword and declare the loop index variable as > volatile. Doing so makes the compiler not optimize the loop away, but > technically the loop index is not a volatile value: it will not be changed by > something outside of the mainline code, like hardware, or an ISR. We are just > tricking the compiler into keeping all accesses to that loop variable's > memory address, thereby keeping all the code that is dependent on the > variable. Therefore the empty loop stays. Thanks for the extra light on the subject. I think I have cleared any and all past confusion now ;-) -- Vince _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list