asm as "memory barrier"

asm as "memory barrier"

[Paul Koning]

I have a two-CPU setup with some shared data structures.  One CPU is
"active", the other is "standby".  The active is the source of a lot
of data, which the standby is accepting.

For things to work right, I need to make sure that there's a partial
order of the writes that the standby CPU sees.

The obvious answer is to sprinkle "volatile" everywhere, and indeed
that's what we currently do.  But that's very much overkill, because
we don't need every read and write of the variables to be a memory
reference, and we don't need total order, only partial order.

What I really need is the GCC analog of a "memory barrier", i.e., a
marker in the source code that says "make sure that all the stores
that were coded before this point are seen before any of the stores
coded after this point".

The obvious answer is:
    asm volatile ("" : : : "memory");

and indeed that appears to do the job.  It forces the code generator
to emit all the stores for data that's currently in registers but
needs to go to variables.  That's what I want.

But it also (as documented) causes the compiler to assume that memory
has changed since then, i.e., anything it loaded before is no longer
valid.  That's NOT what I want.

I also tried:
    asm volatile ("");

That did what I wanted -- forces the stores but doesn't invalidate the
registers (in gcc 3.0.1 for mips at least).  The trouble is that I
don't see any documentation that tells me this, so I am loath to rely
on this property.

Is this indeed something I can count on?  (I.e., should this be
documented?)  If not, any other suggestions?

BTW, I don't need to generate any actual machine code here; the
machine I'm using has the right ordering properties in the hardware,
so, for example,
    asm volatile ("sync");
is overkill.

Thanks,
	paul

Re: asm as "memory barrier"

[Richard Henderson]

On Wed, Apr 23, 2003 at 03:55:57PM -0400, Paul Koning wrote:
> But it also (as documented) causes the compiler to assume that memory
> has changed since then, i.e., anything it loaded before is no longer
> valid.  That's NOT what I want.

There doesn't appear to be any way to do this.  I'd have expected

  int x;
  int foo()
  {
    int r = x;
    {
      char *p;
      asm ("" : "=X"(p));
      asm volatile ("" : : "X"(*p));
    }
    return x + r;
  }

to work (as an observed read from a pointer with unknown value),
but it would seem that CSE doesn't want to combine the two loads
across the volatile asm.


r~

Re: asm as "memory barrier"

[Paul Koning]

> From: Richard Henderson <rth@redhat.com>
>>On Wed, Apr 23, 2003 at 03:55:57PM -0400, Paul Koning wrote:
>> But it also (as documented) causes the compiler to assume that memory
>> has changed since then, i.e., anything it loaded before is no longer
>> valid.  That's NOT what I want.
> 
> There doesn't appear to be any way to do this.  I'd have expected
> 
>   int x;
>   int foo()
>   {
>     int r = x;
>     {
>       char *p;
>       asm ("" : "=X"(p));
>       asm volatile ("" : : "X"(*p));
>     }
>     return x + r;
>   }
> 
> to work (as an observed read from a pointer with unknown value),
> but it would seem that CSE doesn't want to combine the two loads
> across the volatile asm.

Perhaps because of the aliasing rules?

I observed that simply asm volatile (""), i.e., "old style asm" *does*
do what I want.  My concern wasn't that -- it was the fact that there
isn't any documented property of old style asm.  Or at least, only
very little, and part of that has traditionally been wrong.

     paul

Re: asm as "memory barrier"

[Richard Henderson]

On Thu, Apr 24, 2003 at 02:47:47PM -0400, Paul Koning wrote:
> I observed that simply asm volatile (""), i.e., "old style asm" *does*
> do what I want.

That seems wrong to me.  In any case, you definitely shouldn't
rely on this.


r~