[Gc] mips support broken in gc-7.x (and other pending patches)

Thiemo Seufer ths at networkno.de
Thu Jul 3 15:41:57 PDT 2008


Boehm, Hans wrote:
> My apologies.  There was apparently a merge accident related to the
> mips.h file.  I fixed that, and checked in the other two small
> patches.  Things should be OK now.

I can confirm it builds and passes the testsuite on (big-endian)
Linux/MIPS. I notice you added a comment:

/*
 * FIXME:  This should probably make finer distinctions.  SGI MIPS is
 * much more strongly ordered, and in fact closer to sequentially
 * consistent.  This is really aimed at modern embedded implementations.
 * It looks to me like this assumes a 32-bit ABI.  -HB
 */

The MIPS architecture specification allows for weaker ordering than
what SGI used to implement. Since most modern MIPS SMP implementations
use a weak ordering variant, with "sync" being the only common barrier
operation, I implemented the variant which works on all MIPS systems.

As long as AO_t is a 32-bit quantity the code should also work on
N32/N64 ABIs, although I haven't tested this.

> I noticed that in a couple of places, the atomic_ops patches don't
> seem to take advantage of the structure of the package.  If you omit
> operations, it tries to synthesize them from the exisiting ones.
> Mips.h seems to supply implementations for things like
> AO_compare_and_swap_acquire that look like they should be equivalent
> to the automatically generated ones.  Is there a reason not to take
> those out?

IIRC I carried those forward from an earlier version of libatomic_ops,
where they weren't automatically generated. If that changed now then
the versions in mips.h are redundant.

> The m68k patch seems to supply a non-thread-safe or operation, where
> I think the synthesized one should correctly use compare-and-swap.
> I would really like to take that one out.

AFAICS this was also written for an earlier libatomic_ops, I figure
the same rationale applies as for MIPS. That said, I don't know m68k
enough to do more than guesswork. :-)


Thiemo


More information about the Gc mailing list