Date: Thu, 7 Aug 2003 15:10:15 -0400 From: "Portante, Peter" <peter.portante@hp.com> To: <deischen@freebsd.org> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: RE: Atomic swap Message-ID: <B24FABB430F7C94D942D6386447C93DC0512B561@tayexc17.americas.cpqcorp.net>
next in thread | raw e-mail | index | archive | help
Dan,
> ----------
> From: Daniel Eischen
> Reply To: deischen@freebsd.org
> Sent: Thursday, August 7, 2003 3:05 PM
> To: Marcel Moolenaar
> Cc: Portante, Peter; alpha@freebsd.org; deischen@freebsd.org
> Subject: Re: Atomic swap
>=20
> On Thu, 7 Aug 2003, Marcel Moolenaar wrote:
>=20
> > On Thu, Aug 07, 2003 at 01:44:18PM -0400, Daniel Eischen wrote:
> > > How about this?
> > >=20
> > > static __inline void
> > > atomic_swap_long(volatile long *dst, long val, long *res)
> > > {
> > > u_int64_t result, temp;
> > >=20
> > > __asm __volatile (
> > > "1:\tldq %1, %3\n\t" /* load value to store */
> > > "ldq_l %0, %2\n\t" /* load current value, asserting lock */
> > > "stq_c %1, %2\n\t" /* attempt to store */
> > > "beq %1, 2f\n\t" /* if the store failed, spin */
> > > "br 3f\n" /* it worked, exit */
> > > "2:\tbr 1b\n" /* *dst not updated, loop */
> > > "3:\n" /* it worked */
> > > : "=3D&r" (result), "=3D&r" (temp)
> > > : "m" (*dst), "m" (val)
> > > : "memory");
> > >=20
> > > *res =3D result;
> > > }
> >=20
> > The first instruction is wrong. "val" isn't memory. Also,
> > forget about the branch prediction optimization. It just
> > makes the code unreadable and we don't even know if it
> > makes a difference.
> >=20
> > The following has been written down without testing (I
> > dropped the cosmetic \t and instead indented by hand to
> > make the source code readable, not what is given to the
> > assembler (per se):
> >=20
> > static __inline void
> > atomic_swap_long(volatile long *dst, long val, long *res)
> > {
> > __asm ( "1: ldq_l t0,%0\n"
> > " mov %1,t1\n"
>=20
> If I swap the first 2 instructions:
>=20
> __asm ( "1: mov %1,t1\n"
> ldq_l t0,%0\n"
>=20
> that eliminates 1 instruction from between the locked
> instructions. Is there anything wrong with doing that?
>=20
Actually, the processor has a chance to do something while waiting for =
memory, so it does not hurt to have the mov inside the ldq_l/stq_c pair.
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B24FABB430F7C94D942D6386447C93DC0512B561>