On 11/01/2011 04:48 PM, Richard Henderson wrote:
On 11/01/2011 01:20 PM, David Miller wrote:
Unfortunately, this is not true.
Otherwise we could change the 32-bit default code generation to
v9 from v7 under Linux.
For v7, pa-risc, and sh, we originally allowed the test_and_set and
On 11/02/2011 07:18 AM, Andrew MacLeod wrote:
OK, I think i need to revert my position and introduce
__atomic_test_and_set() and __atomic_clear(). bah. I'll work on
that today.
I don't think you do. We already have the __sync functions,
and we should just use those.
What we need is a
On 11/02/2011 11:25 AM, Richard Henderson wrote:
On 11/02/2011 07:18 AM, Andrew MacLeod wrote:
OK, I think i need to revert my position and introduce
__atomic_test_and_set() and __atomic_clear(). bah. I'll work on
that today.
I don't think you do. We already have the __sync functions,
and
On 11/02/2011 08:44 AM, Andrew MacLeod wrote:
that should work shouldnt it?
Yes, so long as the atomic_flag object only wants one memory model.
Which I suppose it does for implementing a mutex.
r~
From: Richard Henderson r...@redhat.com
Date: Tue, 01 Nov 2011 08:15:51 -0700
Given that I believe that essentially all Sparcs still running
are actually v9 and have native CAS, I think we can ignore this
problem entirely.
Unfortunately, this is not true.
Otherwise we could change the 32-bit
On 11/01/2011 01:20 PM, David Miller wrote:
Unfortunately, this is not true.
Otherwise we could change the 32-bit default code generation to
v9 from v7 under Linux.
For v7, pa-risc, and sh, we originally allowed the test_and_set and
lock_release patterns to do non-obvious things with 0/1
From: Richard Henderson r...@redhat.com
Date: Tue, 01 Nov 2011 13:48:26 -0700
(2) Can we have the kernel implement some {SWAP,CAS}{4,8} primitives (possibly
via a special trap) that we can export from libgcc, as we do for ARM, PA,
SH?
I believe that would allow all of the
(1) Are there really live v7 still around?
At least with v8 we have SWAP, with which we can implement the full
__atomic_exchange pattern sans hackery. We can't do that with just
LDSTUB.
I think that we can drop v7 support at this point but not v8 because of Leon.
--
Eric Botcazou
On 11/01/2011 11:15 AM, Richard Henderson wrote:
On 11/01/2011 04:56 AM, Andrew MacLeod wrote:
well, the reason for it was so that __atomic_store can be used as a
replacement for sync_lock_release on such targets...
And what was your replacement for sync_test_and_set?
If you don't have that
* optabs.c (expand_atomic_store): Use create_fixed_operand for
atomic_store optab. Don't try to fall back to sync_lock_release.
---
The create_fixed_operand thinko is obvious. The sync_lock_release is
more subtle. The target is allowed to support only storing 0/1 with
the
10 matches
Mail list logo
