[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1453331298.3681.58.camel@t-online.de>
Date: Thu, 21 Jan 2016 08:08:18 +0900
From: Oleg Endo <oleg.endo@...nline.de>
To: Rich Felker <dalias@...c.org>, gcc@....gnu.org
Cc: musl@...ts.openwall.com
Subject: Re: SH runtime switchable atomics - proposed design
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
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.
