> However, David brings up a good point. A local variable is put on the stack, > generally not the place for hardware to modify the variable. And generally, > other parts of the program (such as ISRs) don't have access to the specific > location of the variable on the stack. Both hardware and ISRs work with > global variables. So *could* a compiler reason that local variables could > never be volatile? Or are there truly situations where hardware or ISRs > could modify local variables on the stack?
The common use of volatile automatic variables is in conjunction with setjmp/longjmp. This idiom would break if volatile locals went into registers. Also there's no reason (in principle) that interrupts cannot access stack frames of non-interrupt contexts. So anyway, I would say that regardless of what the standard actually says, it *should* specify that volatile locals behave similarly to volatile globals: loads and stores in the abstract machine must correspond one-to-one with loads and stores (to RAM, not registers) in the physical machine. John Regehr _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
