On Wed, Sep 02, 2015 at 01:24:55AM +0900, Oleg Endo wrote: > > I'm not sure what the best way to achieve multiple goals is, but the > > current behavior makes it so you need --isa=any (and a final binary > > with weird ABI tag) to have a binary that supports atomic operations > > on any SH model. musl libc already has such support (except the new J2 > > CAS instruction) and I would like to eventually provide a libatomic > > approach for GCC too so that it's possible to use __sync/C11 atomics > > and have the binary be safe to run on any model that supports the > > baseline ISA & ABI you built for (e.g. all >=SH2 if you used -m2). > > I don't know the details of your implementation. The compiler > generated atomic sequences are not really compatible. The safest > thing is not to enable any atomic model in GCC and let it emit > function calls to __atomic*.
Exactly -- but then, libatomic.a needs to contain J2-specific cas.l opcodes and SH4A-specific movli.l/movco.l opcodes and code that selects at runtime which to use (or whether to use imask or gusa) based on hwcap, etc. The point is that a mix of opcodes for different ISA levels end up being in the final binary, which might otherwise be targeted for SH-2 baseline so it can run on any of them. > > I have a patch for that part, just not expanding the > > already-very-complex SH "family-tree" of instruction support. However > > it's likely that encoding details will change (the draft encoding > > overlaps with something used by SH2A IIRC, and the intent was not to > > have such overlap) > > Yeah, it overlaps with the first 16 bit word of the 32 bit SH2A > load/store insns. > > > so I'm holding off on submitting it until the > > hardware side works out this issue. > > Sounds reasonable. In the mean time, do you have any suggestsions on how the ISA level stuff should be done to add J2 on the binutils side? Thanks for reviewing. Rich
