> It's always been there: it's an empty inline asm instruction with a > "memory" clobber.
> > Maybe this sounds trivial, but what about an exact definition of > > what the MemoryBarrier() is supposed to mean, first? > > http://en.wikipedia.org/wiki/Memory_barrier > > (The explanation there is a little CPU-centric, but similar aspects > also apply to the compiler.) I don't know what are "similar aspects". The meaning of "memory barrier" in the "big CPU" world is quite specifically bound to out-of-order execution and caching effects, none of which is pertinent here. The documentation you've provided at the moment talks about flushing/restoring variables from/to registers; however, for atomicity and similar issues it's also important to prevent code reordering. We've been discussing this before, and I see no shift in this issue - there is no clear and concise documenttion on effects of "volatile" keyword on "asm", nor the memory clobber; and I assume you did not dig deep into gcc to gain more insight in this issue (nor did I nor anybody I know of). Moreover, the memory clobber alone is empirically known not preventing code reordering (together with "some" "volatility" it is empirically found to achieve this but with no knowledge of the exact mechanism how this happens), which is what I believe most people will expect from the "memory barrier" buzzword. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=89990 I propose to add this as a warning to your new macro, to not to raise false hopes. And IMHO it's also a bad decision to have this macro in a new header. Why not keeping it together with the existing and related macros in atomic.h or interrupt.h (which is already a bad thing that there are two such related headers)? It only adds to the confusion of the users. As for cli()/sei(), I've already expressed my views (strongly opposed by you back then), even proposed changes in the macros and the documentation. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=674693#674693 and also started to work on a set of known atomic macros (unfortunately had no time to move on really on this) http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=90149 You might also want to notify the audience on the avr-gcc forum on avrfreaks.net on the major changes you've just made - there appears to be a higher attendance there than here. Jan Waclawek _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
