[Gc] mips support broken in gc-7.x (and other pending patches)
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
> * 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
> > 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.
More information about the Gc