Fwd: [RFC] Rework mem_barrier() definitions in compiler.h

[Michael]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Aug 4, 2009, at 10:20 AM, Matt Turner wrote:

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

If the barrier instructions are simple _asm statements I don't see a  
reason to keep different versions for different operating systems.

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

It does on NetBSD, with a few extra homegrown drivers.

> The barrier code in the Linux kernel has
>
> #define mb()    __asm__ __volatile__ ("" : : : "memory")
>
> so it's easy to add if it is needed.

I don't think any of the sparc-specific drivers actually use the  
barrier macros.

> 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"); \

That makes sure all stores are committed before the next load happens,  
sparc v8's stbar is equivalent to membar #StoreStore. If you're  
concerned about the license NetBSD's kernel code uses membar  
#StoreStore for a write barrier and membar #Lookaside for a read  
barrier.

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

In theory it could - NetBSD supports a few of these machines ( like  
SGI's IP1x ) but I have no idea if we actually support any of their  
graphics devices. Probably not. IIRC the only other machines we  
support with this kind of CPUs are old MIPS-based DECstations which  
used to have their own Xserver and I seriously doubt they share any  
driver with any other class of machines.

> If not, just use sync. If it does, how to check for sync support?

I think there's a compiler macro which is defined when compiling for  
MIPS-III or newer, NetBSD's kernel code has a bunch of #ifdef MIPS3 /  
#ifdef MIPS1 to select which sync instructions to use.
Not sure if these are set by gcc or something else, I suspect gcc  
though.

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

On NetBSD it's academic - the two relevant accelerated drivers we have  
are for graphics chips that only occur on machines with at least MIPS- 
III CPUs. There is a driver for IMPACT boards which likewise only fit  
into machines with MIPS-IV CPUs. And we don't ( and aren't likely to )  
support Xorg on any non-SGI MIPS box that could use pre-MIPS-III CPUs  
anyway. As far as I can tell old SGI boxes are the only halfway  
significant case and even these are quite obscure already and of  
rather limited use these days. So, assuming that any remotely  
interesting hardware is at least MIPS-III is fine with me.

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

That was cargo-culted from the kernel code, the nop probably isn't  
necessary. A load barrier would be the same. In this driver I've been  
a bit paranoid regarding store order - the R5k CPU will reorder stores  
even on uncached mappings which will screw you over, especially when  
you're trying to make a barely documented chip do tricks.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSniC+8pnzkX8Yg2nAQI4dwf/T0Vs90k0gPt0Qtk8YHkjm9TjHwqcXYUD
xK24GxNh/Y/vfh65dam9gTY/OzLlo9n54k4KPlSGma7TMYffZRAjpFYjRjluDtiq
dBD8Dsi6bT8OpSZV2Xnj+NnvBx4SEM2QRg/Y8YytzxR4PXju+LvH2iz2WM9WriSu
sbqRJjmmUXH3n2QASzKPJfr0CtDzi5iorVsb7HNtyBiGMSzs8Xy1VAcuCHYs7oum
+/55K0USSF5c3d3iBlFr2KZRcU6HyfnxReBu0yba8d1tGoAKE/dOmgoUVzHi/Kq8
5ZAt048DkTLbwrPoI0Joizekhi4/74ELv70yl5EiXYDBcvSMTs7RUg==
=81Pu
-----END PGP SIGNATURE-----