On Sep 28, 2007, at 8:58 PM, Graham Davies wrote:
David Kelly wrote:
... because it was volatile it *had* to
be fetched and stored each time.
Oh boy. That's a really interesting statement (to me anyway, but I
have a volatile fetish). You're saying that having chosen to put
the variable in memory, the compiler is obliged to fetch it prior
to and store it after each increment. I can't disagree with that.
But, does it explain the "horrid code"? Does the compiler *have*
to put the variable in memory?
I guess it doesn't really have to if it can assure that the variable
has not been passed by address reference to another routine such as
an interrupt. Thats pretty much the definition of volatile in the
first place, that one is telling the compiler that it can be changed
somewhere somehow outside of the compiler's control.
It is declared as an automatic variable, right? That means that
the compiler has complete freedom in deciding where to put it and a
register is a perfectly good choice. The scope is local, so the
variable can't be accessed outside the function.
It could be passed to another function by address.
It isn't static, so its value isn't preserved when execution
leaves the function. Is there a body of opinion that the volatile
modifier obliges the compiler to put a variable in memory? I'm
just interested. If this is too off-topic, feel free to ignore
me. Actually, feel free to ignore me at any time.
I think there is room for other variations on "volatile" as much of
what Graham says applies nicely in interrupt service routines. No
need to treat most application volatile variables with kid gloves
when interrupts are masked. Many variables mapped to a peripheral
device needs volatile no matter what. Not for an ouput port, but an
input port for sure, and hardware timers, etc. But not for my example
software timer, at least not in the interrupt routine where it gets
decremented:
if( timer_serial_cmd )
timer_serial_cmd--;
timer_serial_cmd above only needs to be volatile outside of the
interrupt routine.
It is a stretch to say that any code intended to cause a deliberate
delay is horrible. The code provided in <util/delay_basic.h> is about
as painless as anything can be, no matter that it is assembly in a C
function wrapper.
I wrote earlier, if an Output Compare is not being used elsewhere,
they make excellent delay timers without tying up the CPU in a busy
loop. My example tied the CPU up, but thats not the way I generally
use them. Software timers implemented in my tick interrupt for longer
events, OCR's for precise short periods, and more complex use of the
OCR hardware for repetitive events such as PWM motor control.
--
David Kelly N4HHE, [EMAIL PROTECTED]
========================================================================
Whom computers would destroy, they must first drive mad.
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
