[avr-libc-dev] Re: Inline assembler and compiler optimization

[David Brown]

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