> -----Original Message----- > From: Preston Wilson [mailto:[EMAIL PROTECTED] > Sent: Monday, October 01, 2007 8:13 AM > To: Eric Weddington; 'Paulo Marques'; 'David Brown' > Cc: AVR-GCC-LIST > Subject: Re: [avr-gcc-list] Problem with delay loop > > "Eric Weddington" wrote: > > > ... > > > I agree with the statement above that "'volatile' is > precisely to warn the > > compiler that it should not 'reason' anything about [the] variable". > > 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? > > Yes, ISRs and hardware can modify variables on the stack. > > uint8_t *g1; > > ISR1() > { > *g1 = 1; > } > > main() > { > volatile uint8_t v = 0; > > g1 = &v; > > // configure ISRs and enable interrupts > ... > }
Sure, but only indirectly, through a global variable as I pointed out above. I should have been more specific. We were discussing the possibility of the compiler being smarter about 'volatile' and local automatic variables. I would definitely say that if the local variable's address is taken, then all bets are off. Eric _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
