|
From: | David Brown |
Subject: | [avr-libc-dev] Re: Inline assembler and compiler optimization |
Date: | Tue, 17 Mar 2009 23:18:31 +0100 |
User-agent: | Thunderbird 2.0.0.19 (Windows/20081209) |
Weddington, Eric wrote:
As Weddington, Eric wrote:If we do that, we might as well make it a public symbol, yes?: #define memory_barrier() __asm__ __volatile__(""::"memory")Anyway, it might make sense to provide an additional macro like__memory_barrier() that expands to __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, aslong 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
[Prev in Thread] | Current Thread | [Next in Thread] |