[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Graham Davies
Subject: Re: [avr-gcc-list] memcpy() : problem when passing destination pointer
Date: Wed, 11 Feb 2009 08:33:20 -0500

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]