> -----Original Message----- > From: > avr-gcc-list-bounces+eweddington=cso.atmel....@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel....@nongnu. > org] On Behalf Of Vincent Trouilliez > Sent: Tuesday, February 10, 2009 7:02 PM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] memcpy() : problem when passing > destination pointer > > On Tue, 10 Feb 2009 21:56:39 +0100 (MET) > j...@uriah.heep.sax.de (Joerg Wunsch) wrote: > > As the code works as is (with the warning), I bet the volatile > > qualification wasn't needed at all in the first place, and could as > > well be omitted. > > I can't find any reference to the volatile keyboard in the > current avr-libc manual (1.6.2), but my understanding of > volatile comes > from an older avr-libc manual (somewhere in the FAQ section > IIRc) years > ago when I debuted my AVR project.
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. > IIRC it said volatile must be used to keep the compiler from > optimizing > away access to a variable that he thinks might be pointless. Like > writing a variable that is never read back. > 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. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list