avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os


From: Mark Litwack
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
Date: Fri, 16 May 2008 13:25:19 -0400
User-agent: KMail/1.9.9

On Friday 16 May 2008 11:32:48 am Weddington, Eric wrote:
> > Wow.  I think the cli()/sei() construct is used fairly
> > universally, and it's also in the avr-libc docs.
>
> Acutally it's not. What is more appropriate is this:
>
> uint8_t old_sreg = SREG;
> cli();
> // code
> SREG = old_sreg;
>
> You don't want to blindly set the interrupts after they have been
> cleared. You want to *restore the interrupts to its previous state*.
> This is why the status register (SREG) is saved and restored as it
> contains the 'I' flag, which is the global interrupts flag. Restoring
> SREG restores the previous state of the globabl interrupts flag.
>
> Really the only time that one should see cli()...sei() is in the
> initialization of the chip, and generally there is a lot more code than
> one line between the two.
>
> Eric

Actually, I had considered your example to be included when
I said cli()/sei().  Clearly you would want to save SREG in
almost every situation.

Are you saying your construct above protects "// code" in
all cases?  Or is "// code" still subject to being
re-ordered to outside of the protection if there are no
dependencies?

If ATOMIC_BLOCK() is *the* way to do it, perhaps the docs
could be improved a little by emphasizing the use of
ATOMIC_BLOCK() as a necessity rather than as a convenience.

-mark




reply via email to

[Prev in Thread] Current Thread [Next in Thread]