RE: [avr-libc-dev] [RFC] Sleeping BOD API

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Joerg Wunsch
> Sent: Friday, February 06, 2009 2:08 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] [RFC] Sleeping BOD API
> 
> As Weddington, Eric wrote:
> 
> > > > > > +#define sleep_bod_disable()  \
> > > > > > +(__extension__({             \
> 
> That complicated __extension__ gimmick is not needed here.  It's only
> needed in one situation (the PSTR macro) where a braced group yields a
> "return" value.

That's fine. I'll take it out.

> > > Is there any disadvantage to including the OUT instructions
> > > directly instead of breaking up the macro into two asm statements?
> 
> > Yes. I would then have to specify the exact register to use.
> 
> Nope.  You could create a local variable within the brace group
> (you've already got anyway), and pass that variable with the correct
> constraint into the inline asm statements.  That's the usual way this
> kind of job is implemented, and IMHO the best compromise between
> readability of the code (well, this always sucks as soon as the word
> "__asm__" enters the scene :) and not getting into the optimizer's
> way.

Nope. I already tried that and it doesn't do what I need to do.

I created a temporary variable, and gave it the "d" constraint. The compiler 
then created assembly code to initialize that variable (register) to 0, and 
then the next line overwrote that register with the value read in from the I/O 
register. Very strange.

Besides why would I need to create a temporary, named "variable" when that 
variable doesn't really do anything. In other inline assembly snippets in 
avr-libc, we use the temp variable as a return value from the macro. But in 
this case, I'm not returning anything. I just need a scratch register to do the 
"modify" portion of a read-modify-write action.

Eric