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

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

On 01 Sep 2015, at 23:18, Rich Felker <dalias@libc.org> wrote:

> On Tue, Sep 01, 2015 at 10:45:10PM +0900, Oleg Endo wrote:
>> It seems that this J2 atomic instruction(s ?) is not available to
>> the public. I've skimmed through the currently available J2 hardware
>> sources, but couldn't find anything about it. So it's just
>> speculation, but probably you'll require a copyright assignment for
>> the atomics parts.
> 
> It's still under development and I'm not closely following the
> hardware side of things. I'll hold off on submitting the atomic
> support until it's in the public release and tested. My hope was to
> get the basic support upstream first (having -mj2 is very helpful for
> building the kernel since it makes the libgcc issue we were dealing
> with go away) and add the atomic part later.

Sounds reasonable.

> From the copyright side, though, IMO it's not a matter of whether the
> feature is public but the non-triviality of the patch that would make
> it require an assignment.

Yes, that's what I meant.  Looking at your cas.l patch for binutils, I guess the patch for GCC will be non-trivial.

> My work on this is under contract with SE
> Instruments and our arrangement is such that they're responsible for
> copyright/assignment on the work I do on FSF projects. AFAIK they
> don't yet have any assignment paperwork on file for this so I'll need
> some guidance from whoever handles that for GCC.

Sorry, I don't what's the best option in this particular situation.  Maybe somebody else can jump in.

>> But then, why do you add "shj2" in config.gcc?
> 
> Because the code it's added to just did s/m/sh/ as part of its text
> processing. ;-) It's slightly ugly shell script but I'm just working
> with what's there.

(*)

> Yes, I agree it could be odd from the GCC side. That's actually why I
> omitted tuples for now and just wanted to use -mj2 or --with-cpu: I
> was concerned configure scripts would blow up on seeing a cpu family
> name they don't know.
> 
> If you want to just follow the existing naming pattern for tuples, I
> think "sh2j" might make more sense than "shj2". It would both be
> easier to match (there's probably a lot of software that accepts
> sh[:digit:] but not sh[:alnum:]) and it's sufficiently different from
> the actual name of the cpu so as not to give the impression that "J2"
> is short for "SH J2" or something.

SH2J is also OK.  But then that thing above (*) should be fixed and sh2j should be used consistently.

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

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

> This draft patch and all the
> others I currently need for a working toolchain are available here:
> 
> https://github.com/richfelker/musl-cross-make/tree/master/patches

Thanks for sharing.

Cheers,
Oleg