[U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush

[Albert ARIBAUD]

Hi Scott,

On Thu, 11 Oct 2012 13:03:13 -0500, Scott Wood
<scottwood at freescale.com> wrote:

> On 10/11/2012 12:31:46 AM, Albert ARIBAUD wrote:
> > Hi Marek,
> > 
> > On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut <marex at denx.de> wrote:
> > 
> > > Add memory barrier to cache invalidate and flush calls.
> > 
> > Memory barrier...
> > 
> > "You keep using that word. I do not think it means what you think it
> > means." :)
> 
> Could we wait on the condescension until your assertion of what a  
> memory clobber does and does not do is resolved?

Scott, I think you should not mistake as condescension what is just
humo(u)r. What I wrote above is a quotation from a (light, quite
humorous and above all, self-mocking) movie, meant to be read by, but in
no way directed against, Marex. Besides, since you followed the IRC
discussion, you knew the actual exact meanings of "memory barrier" and
of the "memory" clobber are not that easy to grasp, which makes the
quotation quite appropriate without necessarily.

> > A memory barrier's effect is only that all of the volatile accesses
> > placed before it in the source code finish when the barrier executes,
> > and that none of the volatile accesses placed after it in the source
> > code starts before the barrier has executed.
> 
> Cite from official GCC documentation please, or example code that shows  
> a problem.

http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm

"If your assembler instructions access memory in an unpredictable
fashion, add `memory' to the list of clobbered registers. This will
cause GCC to not keep memory values cached in registers across the
assembler instruction and not optimize stores or loads to that memory.
You will also want to add the volatile keyword if the memory affected
is not listed in the inputs or outputs of the asm, as the `memory'
clobber does not count as a side-effect of the asm".

> We've use memory barriers like this all the time.  It works and is  
> standard practice.  If it doesn't work like that it needs to be fixed.

I have used memory barriers too, and I've already seen some weird
things happening because they were used in ways that did not match
their effects. Particularly, we did not use memory clobbers on cache
flush or invalidate operations, we used them on actual barrier
operations -- dsb, dmb and their cp15 incarnations.

> That AVR/ARM example you showed on IRC is special because it's calling  
> a libgcc function and GCC knows that the function doesn't access memory  
> (loading constant data for the argument doesn't count).  I couldn't get  
> the same thing to happen with a normal function, even when declared  
> with __attribute__((const)).  Yes, it's a problem for ordering code in  
> general and thus keeping slow stuff out of critical sections, but it  
> shouldn't be a problem for ordering memory accesses.

Can you *guarantee* that no valid C code will ever let a non-volatile
write slip across a memory clobber?

Memory clobbers do not guarantee this, at least not explicitly in their
description, whereas C sequence points do. For instance, the call to a
function is a sequence point, reached only after its arguments have
been evaluated.

> -Scott

Amicalement,
-- 
Albert.