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. ;-) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
