Re: [PATCH] add initial support for J2 core to sh target

[Oleg Endo <oleg dot endo at t-online dot de>]

[moved the discussion from gcc-patches to binutils]

On 02 Sep 2015, at 02:08, Rich Felker <dalias@libc.org> wrote:

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

The whole SH ABI (compatibility) thing is a bit messy, I think.  Instead of trying to classify the whole ISA sets (and their relations), it might be better to have a bitset in the ELF for each instruction that is used and maybe also some higher-level things like "gUSA atomics" or "passes float arguments in integer registers" etc.  Basically everything ISA and ABI related that extends SH1.  It would allow for more flexibility I believe, but it's quite a bit of work.

Adding "-Wa,--isa=<value>" as an additional option when compiling those special libraries with GCC can be used to override the --isa setting used by GCC.  Unfortunately, it seems that for --isa=any AS tries to guess the "most appropriate" ISA flag for the ELF and it seems a bit off at times.  Like compiling with -m1 -Wa,--isa=sh still shows "sh2" in readelf.  --isa=any should probably rather set the "any flag" in the ELF.  Then LD can be taught to ignore isa=any marked objects when doing the link compatibility check.  The other question is how to create that kind of über-library in the first place.  Maybe function multiversioning could be useful.

I don't know the intended use case of this kind of runtime switching, but it seems to be limited to fully statically linked applications only?

>>> 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?

Maybe try to squeeze the J2 into the exiting "family tree" somehow and provide an --isa=shj2 or --isa=sh2j?  If that doesn't work I guess the "family tree" has to go away.  Things like "arch_sh2a_or_sh3e" don't seem to make any sense.  Moreover, I still haven't figured what the "nommu" stuff is for.  Presence or absence of MMU doesn't influence the ISA, except maybe for the privileged ldtbl instruction.  Maybe the easiest and most straight forward option is to have CPU/ISA flags and define them one by one for each instruction.  This will be also easier to handle in the future I believe.

Cheers,
Oleg