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

[Vincent Trouilliez]

On Tue, 10 Feb 2009 21:54:41 -0700
"Weddington, Eric" <address@hidden> 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