[avr-libc-dev] Should cli() imply a memory barrier?

[Joerg Wunsch]

I'm about to commit a new header file, <avr/cpufunc.h> which will
include access to CPU (and compiler) functions that don't fit into any
other header file.  First candidates are _NOP() (has been requested as
an enhancement) and _MemoryBarrier() (can sometimes be useful).

This raises the question: Some years ago, a discussion about whether
cli() should include a memory barrier ended with an agreement that
it's not needed.  Meanwhile, this has been requested occasionally
(like, on avrfreaks.net) as an implied memory barrier appears to be
what most users of cli() eventually have in mind when using that
macro, even at the cost of having it block more optimizations than
would actually be needed in some cases.

Are there any objections against adding it to cli(), or should we
instead point out in the documentation that an explicit
_MemoryBarrier() might be needed in order to get the expected results?

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)