From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9159 Path: news.gmane.org!not-for-mail From: Oleg Endo Newsgroups: gmane.comp.gcc.devel,gmane.linux.lib.musl.general Subject: Re: SH runtime switchable atomics - proposed design Date: Thu, 21 Jan 2016 08:08:18 +0900 Message-ID: <1453331298.3681.58.camel@t-online.de> References: <20160119202851.GA18720@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453331357 19610 80.91.229.3 (20 Jan 2016 23:09:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Jan 2016 23:09:17 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker , gcc@gcc.gnu.org Original-X-From: gcc-return-189766-gcg-devel-2=m.gmane.org@gcc.gnu.org Thu Jan 21 00:09:08 2016 Return-path: Envelope-to: gcg-devel-2@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aM1sA-0007RZ-J4 for gcg-devel-2@plane.gmane.org; Thu, 21 Jan 2016 00:09:06 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; q=dns; s= default; b=K38J1Gwt2RXCFRdabc8aqN8CGYdDrtxHHl44mflqTKaCKx3uB7CaA ZPhgzjGZSjVP5WdPwd6e+JoUkg18e4G5pJso+CYtOsBtisEDJxz5vgIbwb+73vfy Y5W/+J9sJZ5dPpnzD7qVaVVXbzgfRoWeVQKo0HncXEuLo8s+/7Cp0c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; s=default; bh=QmueQigQBWK+8M2fuEshzg+2PBI=; b=mR83RR0HZ74i+UEP6ZEm3ofAjJ5E CJ1s5Yw+Eb2kVgAlXN5h1rs8T3Hh0fhPW4oz0oG/TA3aJsyxuPpMuCQL7G8FBKaF t/kKn8UO6ypO/wMoGG3LSi0moHRk/V1Yy/waJsuDjqXHlXWPeWBun9WLAcupUAHy C05AJQRpTC/VgYU= Original-Received: (qmail 89370 invoked by alias); 20 Jan 2016 23:08:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Original-Sender: gcc-owner@gcc.gnu.org Original-Received: (qmail 88791 invoked by uid 89); 20 Jan 2016 23:08:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=excited, keen, considerations, descriptor X-HELO: mailout09.t-online.de Original-Received: from mailout09.t-online.de (HELO mailout09.t-online.de) (194.25.134.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 20 Jan 2016 23:08:27 +0000 Original-Received: from fwd14.aul.t-online.de (fwd14.aul.t-online.de [172.20.26.242]) by mailout09.t-online.de (Postfix) with SMTP id BB9364F0F7A; Thu, 21 Jan 2016 00:08:22 +0100 (CET) Original-Received: from [192.168.0.16] (TnMyZQZpohaNjiWhzOKvTEdkZvKLS0F+IsQSYv3mJ7Zzs8PcxWcSo5R86lhytEzgDj@[115.165.93.200]) by fwd14.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1aM1rR-0bv69o0; Thu, 21 Jan 2016 00:08:21 +0100 In-Reply-To: <20160119202851.GA18720@brightrain.aerifal.cx> X-IsSubscribed: yes Xref: news.gmane.org gmane.comp.gcc.devel:142272 gmane.linux.lib.musl.general:9159 Archived-At: On Tue, 2016-01-19 at 15:28 -0500, Rich Felker wrote: > I've been working on the new version of runtime-selected SH atomics > for musl, and I think what I've got might be appropriate for GCC's > generated atomics too. I know Oleg was not very excited about doing > this on the gcc side from a cost/benefit perspective I am just not keen on making this the default atomic model for SH. If you have a system built around this atomic model and want to add it to GCC, please send in patches. Just a few comments below... > Inputs: > - R0: Memory address to operate on > - R1: Address of implementation function, loaded from a global > - R2: Comparison value > - R3: Value to set on success > > Outputs: > - R3: Old value read, ==R2 iff cas succeeded. > Preserved: R0, R2. > > Clobbered: R1, PR, T. The T bit is obviously the result of the cas operation. So you could use it as an output directly instead of the implicit R3 == R2 condition. > > This call (performed from __asm__ for musl, but gcc would do it as SH > "SFUNC") is highly compact/convenient for inlining because it avoids > clobbering any of the argument registers that are likely to already > be > in use by the caller, and it preserves the important values that are > likely to be reused after the cas operation. > > For J2 and future J4, the function pointer just points to: > > rts > cas.l r2,r3,@r0 > > and the only costs vs an inline cas.l are loading the address of the > function (done in the caller; involves GOT access) and clobbering R1 > and PR. > > This is still a draft design and the version in musl is subject to > change at any time since it's not a public API/ABI, but I think it > could turn into something useful to have on the gcc side with a > -matomic-model=libfunc option or similar. Other ABI considerations > for > gcc use would be where to store the function pointer and how to > initialize it. To be reasonably efficient with FDPIC the caller needs > to be responsible for loading the function pointer (and it needs to > always point to code, not a function descriptor) so that the callee > does not need a GOT pointer passed in. Obviously the ABI has been constructed around the J-core's cas.l instruction. Do you have plans to add other atomic operations (like arithmetic)? If not, then I'd suggest to name the atomic model "libfunc-musl-cas". Cheers, Oleg