I tried to send this earlier from another account, but it doesn't seem
to have made it to the list. Sorry if it turns up twice.
Weddington, Eric wrote:
As Weddington, Eric wrote:
Anyway, it might make sense to provide an additional macro like
__memory_barrier() that expands to __asm__
__volatile__(""::"memory").
If we do that, we might as well make it a public symbol, yes?:
#define memory_barrier() __asm__ __volatile__(""::"memory")
If we document it, it /is/ public. ;-)
The point is that user programs might already use the identifier
memory_barrier so we'd better avoid redefining it (at least, as
long as it goes into one of the existing header files).
Hmm. I really hate having to explain the two leading underscores all
over again.
First, we should do some research to see if there is already a gcc
builtin, available to the AVR, that does the same thing.
There is __sync_synchronize() in
<http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html>
I have no idea about the implementation of this, or its suitability for
avr-gcc. It's a horrible name, so a #define memory_barrier() would be
nice anyway - but if the builtin does the job it's probably better to
#define memory_barrier() as __sync_synchronize() rather than an inline asm.
Googling for "gcc memory_barrier" suggests that it is a name used in the
RTL patterns.
The linux kernel uses names such as mb(), rmb() and wmb(), which are a
bit too short. On the architectures I looked at, these are defined to
be "barrier()", which for gcc is in turn defined as a volatile memory
clobber and for the intel compiler it is defined as the
__memory_barrier() builtin.
mvh.,
David
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
