avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Brown
Subject: [avr-libc-dev] Re: Inline assembler and compiler optimization
Date: Wed, 18 Mar 2009 08:05:31 +0100
User-agent: Thunderbird 2.0.0.19 (Windows/20081209)

Weddington, Eric wrote:
-----Original Message-----
From: address@hidden [mailto:address@hidden
org] On Behalf Of David Brown
Sent: Tuesday, March 17, 2009 4:19 PM
To: address@hidden
Subject: [avr-libc-dev] Re: Inline assembler and compiler optimization

Googling for "gcc memory_barrier" suggests that it is a name used in the
RTL patterns.

Hmm. Need to look more into the machine description then.
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.

Well that's certainly one route. We could perhaps add it as a gcc builtin.

Thanks for doing this research, David. :-)

Thank Google :-)

I would imagine that a builtin involves more work than just #defining __memory_barrier() as a memory clobber. It would be better, however, if gcc could have a consistent set of memory barrier builtins (including the read and write barriers used by Linux) that could be used across all targets. I don't know how much influence you have in the gcc world at large...

Either way, a "#define memory_barrier() __memory_barrier()" in one of the headers would be useful to give a slightly more friendly name to users.

mvh.,

David





reply via email to

[Prev in Thread] Current Thread [Next in Thread]