From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7677 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] inline llsc atomics when compiling for sh4a Date: Mon, 18 May 2015 00:28:46 -0400 Message-ID: <20150518042846.GA15416@brightrain.aerifal.cx> References: <20150517185516.GA32020@duality.lan> <20150518023402.GS17573@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1431923349 18735 80.91.229.3 (18 May 2015 04:29:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 May 2015 04:29:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7689-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 18 06:29:03 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YuCfm-000441-1J for gllmg-musl@m.gmane.org; Mon, 18 May 2015 06:29:02 +0200 Original-Received: (qmail 5322 invoked by uid 550); 18 May 2015 04:28:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5298 invoked from network); 18 May 2015 04:28:59 -0000 Content-Disposition: inline In-Reply-To: <20150518023402.GS17573@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7677 Archived-At: On Sun, May 17, 2015 at 10:34:02PM -0400, Rich Felker wrote: > Another idea is letting the compiler simplify, with something like the > following, which could actually be used cross-platform for all > llsc-type archs: > > static inline int __sh_cas_llsc(volatile int *p, int t, int s) > { > do old = llsc_start(p); > while (*p == t && !llsc_end(p, s)); > return old; > } > > Here llsc_start and llsc_end would be inline functions using asm with > appropriate constraints. Unfortunately I don't see a way to model > using the value of the truth flag "t" as the output of the asm for > llsc_end, though. I suspect this would be a problem on a number of > other archs too; the asm would have to waste an instruction (or > several) converting the flag to an integer. Unless there's a solution > to that problem, it makes an approach like this less appealing. Indeed, I can't find a way to make it work without two useless instructions. This is what I get (for an extern function a_cas based on the above approach): a_cas: .align 2 .L4: #APP synco ; mov.li @r4, r0 #NO_APP cmp/eq r0,r5 bf/s .L7 mov r0,r1 mov r6,r0 #APP mov.co r0, @r4 ; movt r2 #NO_APP tst r2,r2 bt .L4 .L7: rts mov r1,r0 Both the movt (which I had to write) and the tst (which the compiler generated) are useless. It's a shame, because otherwise this approach is really clean and elegant. Rich