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

Boehm, Hans hans.boehm at hp.com
Thu Jul 3 15:55:30 PDT 2008

Thanks for testing.

> -----Original Message-----
> From: Thiemo Seufer [mailto:ths at networkno.de]
> /*
>  * 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.
Is there now an official specification?  If so, I fully agree that we should make only assumptions stated there.  Last I looked, things seemed unclear, which is why I suggested considering multiple options.

> 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.
AO_t is defined to match the size of pointers.

> > 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.
I think that, at least for this package, they were always intended to be automatically generated, though there may have been issues there.

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

If nobody objects soon, I'll rip that one out, since I think it actually breaks something.  Admittedly, I don't know how many multiprocessor M68K systems are in existence.

> Thiemo

More information about the Gc mailing list