Date: Mon, 21 Jan 2002 08:28:27 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Terry Lambert <tlambert2@mindspring.com> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, mime@traveller.cz, arch@FreeBSD.ORG Subject: Re: 64 bit counters again Message-ID: <20020121082826.Z72285@gsmx07.alcatel.com.au> In-Reply-To: <3C48FCEF.9190CA08@mindspring.com>; from tlambert2@mindspring.com on Fri, Jan 18, 2002 at 08:58:23PM -0800 References: <mit.lcs.mail.freebsd-arch/3C48A0E7.F97BC01@mindspring.com> <200201190350.g0J3oNN08944@khavrinen.lcs.mit.edu> <3C48FCEF.9190CA08@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-Jan-18 20:58:23 -0800, Terry Lambert <tlambert2@mindspring.com> wrote:
>Garrett Wollman wrote:
>> >> Yes. IA64. SPARC 9b (SPARC64) and Alpha, which are 64
>> >> bits, require locks, since they don't have the ability to
>> >> do an atomic "lock; cmpxchg8b".
>> >
>> >Can they do "lock; add const,(mem)" in 32 or 64 bit?
>>
>> Terry is talking out of his ear again.
>>
>> Alpha most definitely does have 64-bit load-linked/store-conditional,
>> which is entirely equivalent to i386's 64-bit compare-exchange. (For
>> some reason in the Alpha ARM it's called ``load locked'' instead.) If
>> we cared about running on MIPS architectures, they have LL/SC as well.
>> SPARC v9 has 64-bit compare-and-swap (although unlike in IA32 a memory
>> barrier is also required); see the SPARC v9 Architecture Reference
>> Manual. IA64 has 64-bit compare-exchange as well; see the Itanium
>> Architecture Software Developer's Manual, volume 2 (Intel document
>> number 245318-003), where there's a whole section on implementing
>> synchronization primitives on IA84; it also has an atomic FETCHADD
>> instruction which I didn't bother to look more closely at.
>
>John Baldwin said:
>
>| Well, SMP on Pentium's maybe, but not on Alpha, sparc64, or ia64, all of which
>| support OOE and looser memory models than x86, meaning that you really need
>| locks unless you are going to have 386-specific code all over the place. I
>| suppose you can wrap it behind an MI API but that seems like a lot of work for
>| fairly small gain that can end up making the code uglier.
>
>So you can argue it out with him, Garrett.
I think that we are suffering from an excessively vague definition of
"lock". John is correct in saying that there is no equivalent of the
IA32 "lock" prefix. Terry is correct that there is no atomic "lock;
cmpxchg8b" _instruction_ - the equivalent needs an sequence of
instructions - but that sequence includes locking - there's no need
for separate mutex-style locks. John's comment is in response to an
(incorrect) claim I made, and relates more to the need to include
memory barriers than atomic locks - I think it is taken out of
context here.
On the IA32, it is possible to perform 32-bit atomic memory operations
with very simple code sequences, eg "lock; addl reg,mem". None of the
RISC architectures support memory RMW instructions, instead they all
need a code sequence.
64-bit equivalents to the above IA32 instruction are:
IA32:
movl mem,%eax
movl 4+mem,%edx
1: movl reg_lo,%ebx
movl reg_hi,%ecx
addl %eax,%ebx
adcl %edx,%ecx
lock cmpxchg8b mem
jnz 1b
Alpha (this is functionally correct but the branch is sub-optimal):
1: ldq_l r1,mem
addq r1,reg,r1
stq_c r1,mem
bne r1,1b
I don't know SPARCv9 or IA64, so can't comment on those, but from
Garrett's comments, the IA64 code is similar to the IA32 code and
the SPARCv9 code is similar to the Alpha code.
>Meanwhile, with a 32 bit cmpxchg, I don't need locks at all,
>unless I want 64 bit counters so I can measure the wrong
>thing.
In a UP environment you don't need locks for either 32 or 64-bit
operations. For an SMP environment, you need locks on both.
Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020121082826.Z72285>