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~
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 we
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 pre
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
lock_release
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 pa
> (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 Botca
From: Richard Henderson
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 non-embedded linux
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
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 default code
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 pair, you don't have a replacement.
> Im just con
On 11/01/2011 12:50 AM, Richard Henderson wrote:
* 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 i
11 matches
Mail list logo
