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 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.

Whom computers would destroy, they must first drive mad.

AVR-GCC-list mailing list

Reply via email to