[RFC] Rework mem_barrier() definitions in compiler.h
Matt Turner
mattst88 at gmail.com
Tue Aug 4 07:20:53 PDT 2009
In the cases of the missing checks for *BSD, do you think it'd be
cleaner to only check for the architecture? Seems silly to have a list
of supported operating systems on which the barrier instruction works.
>> o what is the appropriate SPARC barrier instruction? Surely we can
>> write it better than ".word 0x8143e00a"
>
> it's stbar ( as in STore BARrier ) on 32bit, V9 has a more flexible membar
> instruction.
Does X.Org run on sparc-32? Maybe on some BSDs?
The barrier code in the Linux kernel has
#define mb() __asm__ __volatile__ ("" : : : "memory")
so it's easy to add if it is needed.
For 64-bit, the Linux kernel has
> #define membar_safe(type) \
> do { __asm__ __volatile__("ba,pt %%xcc, 1f\n\t" \
> " membar " type "\n" \
> "1:\n" \
> : : : "memory"); \
> } while (0)
>
> #define mb() membar_safe("#StoreLoad")
with a long associated comment. What of this can I safely copy without
GPL problems? Should the comment be moved as well? What about
#define mb() __asm__ __volatile__("ba,pt %%xcc, 1f\n\t" \
"membar #StoreLoad\n" \
"1:\n" \
: : : "memory"); \
>> o as with {s,m}fence, how to check for MIPS III 'sync' instruction?
>
> If we're building with -march=mips3 or newer it's available, otherwise gas
> will complain. IIRC the equivalent on older MIPS archs is a dummy read. If
> you want to check at runtime - only a handful archaic CPUs don't have sync (
> like MIPS R2x and R3k families ) as far as I remember.
I guess the question should be, does X.Org run on any MIPS I or II
systems? If not, just use sync. If it does, how to check for sync
support? A check in autotools would be easy, but I'd bet packagers
would like a runtime check. But if MIPS I and II aren't supported
anyway, this is all academic.
Looking in your -crime driver, you have
#define WBFLUSH __asm__ ("nop; sync;")
Why is the nop necessary (Linux doesn't have a nop preceeding the
sync)? Is a read barrier identical to this?
Thanks,
Matt
More information about the xorg-devel
mailing list