RE: [avr-gcc-list] Problem with delay loop

[Eric Weddington]

> -----Original Message-----
> From: Preston Wilson [mailto:address@hidden
> 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