[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150518042846.GA15416@brightrain.aerifal.cx>
Date: Mon, 18 May 2015 00:28:46 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] inline llsc atomics when compiling for sh4a
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
