[Top][All Lists]

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

Re: [avr-libc-dev] Should cli() imply a memory barrier?

From: Jan Waclawek
Subject: Re: [avr-libc-dev] Should cli() imply a memory barrier?
Date: Tue, 8 Jun 2010 23:27:20 +0200

> 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. 

I propose to add this as a warning to your new macro, to not to raise false 

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.
and also started to work on a set of known atomic macros (unfortunately had no 
time to move on really on this)

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

reply via email to

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