From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125622 invoked by alias); 1 Sep 2015 16:25:13 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 125611 invoked by uid 89); 1 Sep 2015 16:25:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.7 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD,URIBL_BLACK autolearn=no version=3.3.2 X-HELO: mailout02.t-online.de Received: from mailout02.t-online.de (HELO mailout02.t-online.de) (194.25.134.17) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 01 Sep 2015 16:25:11 +0000 Received: from fwd30.aul.t-online.de (fwd30.aul.t-online.de [172.20.26.135]) by mailout02.t-online.de (Postfix) with SMTP id 0E67D441A5D; Tue, 1 Sep 2015 18:25:06 +0200 (CEST) Received: from [192.168.0.10] (G59WMoZfrhHOuYBrEbTi84ZGYe4vCYym9F-UCE45PVwO-uoAQPKlt-Aelg-MnIEQwL@[219.110.29.36]) by fwd30.t-online.de with (TLSv1:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1ZWoMn-14LBYW0; Tue, 1 Sep 2015 18:25:01 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH] add initial support for J2 core to sh target From: Oleg Endo In-Reply-To: <20150901141848.GA17773@brightrain.aerifal.cx> Date: Tue, 01 Sep 2015 16:25:00 -0000 Cc: gcc-patches@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <17DE61A8-E592-444C-A578-72BF3F16EF2F@t-online.de> References: <20150831174909.GA6317@brightrain.aerifal.cx> <1E36CED7-DB4B-4381-998D-01181D40F4FD@t-online.de> <20150901141848.GA17773@brightrain.aerifal.cx> To: Rich Felker X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00084.txt.bz2 On 01 Sep 2015, at 23:18, Rich Felker 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. >=20 > 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 gues= s 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? >=20 > 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. >=20 > 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 sh= ould 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=3Dany (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 >=3DSH2 if you used -m2). I don't know the details of your implementation. The compiler generated at= omic sequences are not really compatible. The safest thing is not to enabl= e any atomic model in GCC and let it emit function calls to __atomic*.=20 > 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: >=20 > https://github.com/richfelker/musl-cross-make/tree/master/patches Thanks for sharing. Cheers, Oleg