From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86138 invoked by alias); 2 Sep 2015 15:17:00 -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 86127 invoked by uid 89); 2 Sep 2015 15:16:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.3 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; Wed, 02 Sep 2015 15:16:58 +0000 Received: from fwd35.aul.t-online.de (fwd35.aul.t-online.de [172.20.27.145]) by mailout02.t-online.de (Postfix) with SMTP id 639D2591E7A; Wed, 2 Sep 2015 17:16:54 +0200 (CEST) Received: from [192.168.0.10] (ECVOPMZfghaCLvdk5vTFFT6QV0fU9o9VACH2ewpXpkiYkth+QciXK1ne-6oxdFAZkA@[219.110.29.36]) by fwd35.t-online.de with (TLSv1:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1ZX9mK-3Rx9I80; Wed, 2 Sep 2015 17:16:48 +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: <20150901170858.GB17773@brightrain.aerifal.cx> Date: Wed, 02 Sep 2015 15:17:00 -0000 Cc: gcc-patches@gcc.gnu.org Content-Transfer-Encoding: 7bit Message-Id: <04F1E366-C3CF-4DC5-8E36-7FB43DEE917D@t-online.de> References: <20150831174909.GA6317@brightrain.aerifal.cx> <1E36CED7-DB4B-4381-998D-01181D40F4FD@t-online.de> <20150901141848.GA17773@brightrain.aerifal.cx> <17DE61A8-E592-444C-A578-72BF3F16EF2F@t-online.de> <20150901170858.GB17773@brightrain.aerifal.cx> To: Rich Felker X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00171.txt.bz2 On 02 Sep 2015, at 02:08, Rich Felker 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. > >>> 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? Let's continue this topic on the binutils list ( https://sourceware.org/ml/binutils/2015-09/msg00031.html )