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