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

[Graham Davies]

Weddington, Eric wrote:

"The way volatile was explained to me ... 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 too simplistic.  Other cases where a variable can change 
"unexpectedly" are 1) variables shared between threads under a preemptive 
scheduler that are not protected by software interlocks (mutexes, 
semaphores, critical sections, etc.) and 2) variables in memory accessed by 
multiple CPUs in a multi-processor system.  There is also a whole other 
reason for using volatile, which is that an access to a variable has 
side-effects.  Use cases here include 1) hardware control registers, 2) 
mailbox and doorbell registers in multiprocessor systems, 3) writes to 
shared memory and 4) registers that do something other than take on the 
value written (for example, write-to-increment registers).

and also wrote:

"... technically the loop index is not a volatile value ... We are just 
tricking the compiler ..."

I think it is important to keep separate what we (the programmers) know and 
what the compiler "knows".  We are the ones that know why we are using the 
volatile qualifier., i.e. whether it is a register, a variable shared with 
an interrupt or just a counter in a delay loop.  If we correctly identify 
the need for a variable to be volatile, then it is volatile however 
"technical" you want to get.  All the compiler "knows" is that it must treat 
the variable differently and ensure that accesses to the variable occur 
exactly as written, plus some other restrictions, which we typically refer 
to as the inhibiting of certain optimizations.  This is not "tricking" the 
compiler; it is telling the compiler what you want it to do.

Graham.