Re: x86 instructions reordering

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Mar 24, 2005 at 11:12:40AM -0500, Christos Zoulas wrote:
> In article <20050324152233.GA18782%antioche.lip6.fr@localhost>,
> Manuel Bouyer  <bouyer%antioche.lip6.fr@localhost> wrote:
> >Hi,
> >can newer x86 CPUs (hyperthreaded p4 in my case) reorder instructions,
> >or memory writes ? If so, how can we impose barriers ? I didn't find
> >anything obvious in the x86 SMP code, beside bit atomic operations (which
> >don't work in my case).
> >
> >Basically I have these 2 pieces of code in xen (NetBSD and linux), one sender
> >and one receiver, using a piece of shared memory.
> >The receiver:                          |     The sender:
> >                                       |
> >handle_event()                         |     send()
> >{                                      |     {
> >                                       |             a = shared_memory->a;
> >again:                                 |             do_something;
> >        a = shared_memory->a;          |             wmb();
> >        __insn_barrier();              |             shared_memory->a = a + 
> > 1;
> >        b = shared_memory->b;          |             mb()
> >        while (b < a) {                |             if (shared_memory->b == 
> > a)
> >                /* do something */     |                     send_event();
> >                did_something = 1;     |     }
> >                b++;                   |
> >        }                              |
> >        __insn_barrier();              |
> >        shared_memory->b = b;          |
> >        __insn_barrier();              |
> >        if (did_something)             |
> >                goto again;            |
> >}                                      |
> >
> >The sender is a piece of linux code, mb() and wmb() are both
> >__asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory")
> >which is the same as our x86_lfence(). I tried remplacing __insn_barrier
> >with x86_lfence but the assembly produced by gcc didn't change.
> 
> It did not put:
> 
> #APP
>         lock; addl $0, 0(%esp)
> #NO_APP

Yes, it did. I used gcc -s instead of gcc -S, and so was looking at an older
result :(
sorry everyone for wasting your time.

And remplacing __insn_barrier() with x86_lfence() didn't fix my problem :(

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--