As Dean Camera wrote: > I concur - it makes sense to move the memory barrier to the > definitions of the cli() and sei() macros,
(where it is now) > There's no good reason why the user would want the compiler to > re-order the assembly around cli() and sei(), as that's just asking > for trouble. There's a common miscomprehension: a memory barrier ensures that all write operations are committed to memory, and memory locations will be read again (so it's actually quite a big pessimization, as if all variables were declared "volatile"), but there is currently *no* method to prevent the compiler from reordering code. Something like that is simply missing in the C language. -- 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 [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
