RE: [avr-gcc-list] About context saving in Vectors

[Stu Bell]

Jim Brain wrote:

> > Which is why there is the <util/atomic.h> macros.  Check out:
> > 
> > ATOMIC_BLOCK( ATOMIC_RESTORESTATE )
>
> Can someone clarify why these macros are preferred over doing 
> cli()/sei()/SREG=sreg in code?  I'm not trying to troll, but 
> wonder if there is something I am missing.

Jim:  I'm cc'ing this response to the list.  If you have the question,
perhaps someone else does, too.

I'm sure someone else will be far better at answering this, but I'll
take a stab.

The quick answer to your questions is, "not much."  From a functional
point of view I think that the educated programmer can avoid (and *has*
avoided!) the use of the ATOMIC_BLOCK.  The key phrase in that previous
sentence is "educated programmer".

ATOMIC_BLOCK allows you to explicity declare a section of code as
"atomic" rather than hinting at it by the use of the "cli(); ... sei();"
sequence.

More important, in my mind, is that the macros are written in such a way
that the enclosed code is guaranteed not to be optimized out of the
block.

Finally, the simple "cli(); ... sei();" that newbies were using would
enable interrupts even if they were not enabled on entering the
sequence.  With the ATOMIC_BLOCK( ATOMIC_RESTORESTATE ) call you're
explicitly telling everyone that you want the state restored to whatever
it was when you entered the block.

I use it mostly for readability and documentation purposes.  It nice to
think that some other poor slob maintaining my code will be notified of
the importance of the atomicity of the section I mark.  Plus, with the
separate commands it's easy to accidently remove one of the key
statements without any whining from the compiler.  ATOMIC_BLOCK prevents
that kind of fumble-fingered mistake for which I am so famous. ;-)

Hope this helps!

Best regards, 

Stu Bell 
DataPlay (DPHI, Inc.)