RE: [avr-gcc-list] memcpy() : problem when passing destination pointer

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Vincent Trouilliez
> Sent: Tuesday, February 10, 2009 7:02 PM
> To: address@hidden
> Subject: Re: [avr-gcc-list] memcpy() : problem when passing 
> destination pointer
> 
> On Tue, 10 Feb 2009 21:56:39 +0100 (MET)
> address@hidden (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.