public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] SH: atomic.h fixes
@ 2003-03-29  1:23 kaz Kojima
  2003-03-29  2:06 ` Ulrich Drepper
  0 siblings, 1 reply; 11+ messages in thread
From: kaz Kojima @ 2003-03-29  1:23 UTC (permalink / raw)
  To: libc-hacker

Hi,

This is a patch for sh specific atomic.h. It's corresponding to
the similar change on the other architectures and also fixes
a problem when the macro is used with constant arguments.

BTW, the atomic operations in sh's atomic.h suppose a special
kernel support. Should it be moved to sysdeps/unix/sysv/linux/sh/bits?

Regards,
	kaz
--
2003-03-28  Kaz Kojima  <kkojima@rr.iij4u.or.jp>

	* sysdeps/sh/bits/atomic.h (__arch_compare_and_exchange_val_8_acq):
	Return old value. Make asm output reg constraint earlyclobber.
	Renamed from...
	(__arch_compare_and_exchange_8_acq): ... this.
	(__arch_compare_and_exchange_val_16_acq):
	Return old value. Make asm output reg constraint earlyclobber.
	Renamed from...
	(__arch_compare_and_exchange_16_acq): ... this.
	(__arch_compare_and_exchange_val_32_acq):
	Return old value. Make asm output reg constraint earlyclobber.
	Renamed from...
	(__arch_compare_and_exchange_32_acq): ... this.
	(__arch_compare_and_exchange_val_64_acq):
	Renamed from...
	(__arch_compare_and_exchange_64_acq): ... this.
	(atomic_exchange_and_add): Use local variables and
	__arch_compare_and_exchange_val_64_acq.
	(atomic_add): Likewise.
	(atomic_add_negative, atomic_add_zero): Use local variables.

diff -u3prN ORIG/libc/sysdeps/sh/bits/atomic.h LOCAL/libc/sysdeps/sh/bits/atomic.h
--- ORIG/libc/sysdeps/sh/bits/atomic.h	Thu Mar 20 15:48:57 2003
+++ LOCAL/libc/sysdeps/sh/bits/atomic.h	Fri Mar 28 09:32:21 2003
@@ -45,61 +45,55 @@ typedef intmax_t atomic_max_t;
 typedef uintmax_t uatomic_max_t;
 
 
-#define __arch_compare_and_exchange_8_acq(mem, newval, oldval) \
-  ({ unsigned char __result; \
+#define __arch_compare_and_exchange_val_8_acq(mem, newval, oldval) \
+  ({ __typeof (*mem) __result; \
      __asm __volatile ("\
 	.align 2\n\
 	mova 1f,r0\n\
 	nop\n\
 	mov r15,r1\n\
 	mov #-8,r15\n\
-     0: mov.b @%1,r2\n\
-	cmp/eq r2,%3\n\
+     0: mov.b @%1,%0\n\
+	cmp/eq %0,%3\n\
 	bf 1f\n\
 	mov.b %2,@%1\n\
-     1: mov r1,r15\n\
-	mov #-1,%0\n\
-	negc %0,%0"\
-	: "=r" (__result) : "r" (mem), "r" (newval), "r" (oldval) \
-	: "r0", "r1", "r2", "t", "memory"); \
+     1: mov r1,r15"\
+	: "=&r" (__result) : "r" (mem), "r" (newval), "r" (oldval) \
+	: "r0", "r1", "t", "memory"); \
      __result; })
 
-#define __arch_compare_and_exchange_16_acq(mem, newval, oldval) \
-  ({ unsigned char __result; \
+#define __arch_compare_and_exchange_val_16_acq(mem, newval, oldval) \
+  ({ __typeof (*mem) __result; \
      __asm __volatile ("\
 	.align 2\n\
 	mova 1f,r0\n\
 	nop\n\
 	mov r15,r1\n\
 	mov #-8,r15\n\
-     0: mov.w @%1,r2\n\
-	cmp/eq r2,%3\n\
+     0: mov.w @%1,%0\n\
+	cmp/eq %0,%3\n\
 	bf 1f\n\
 	mov.w %2,@%1\n\
-     1: mov r1,r15\n\
-	mov #-1,%0\n\
-	negc %0,%0"\
-	: "=r" (__result) : "r" (mem), "r" (newval), "r" (oldval) \
-	: "r0", "r1", "r2", "t", "memory"); \
+     1: mov r1,r15"\
+	: "=&r" (__result) : "r" (mem), "r" (newval), "r" (oldval) \
+	: "r0", "r1", "t", "memory"); \
      __result; })
 
-#define __arch_compare_and_exchange_32_acq(mem, newval, oldval) \
-  ({ unsigned char __result; \
+#define __arch_compare_and_exchange_val_32_acq(mem, newval, oldval) \
+  ({ __typeof (*mem) __result; \
      __asm __volatile ("\
 	.align 2\n\
 	mova 1f,r0\n\
 	nop\n\
 	mov r15,r1\n\
 	mov #-8,r15\n\
-     0: mov.l @%1,r2\n\
-	cmp/eq r2,%3\n\
+     0: mov.l @%1,%0\n\
+	cmp/eq %0,%3\n\
 	bf 1f\n\
 	mov.l %2,@%1\n\
-     1: mov r1,r15\n\
-	mov #-1,%0\n\
-	negc %0,%0"\
-	: "=r" (__result) : "r" (mem), "r" (newval), "r" (oldval) \
-	: "r0", "r1", "r2", "t", "memory"); \
+     1: mov r1,r15"\
+	: "=&r" (__result) : "r" (mem), "r" (newval), "r" (oldval) \
+	: "r0", "r1", "t", "memory"); \
      __result; })
 
 /* XXX We do not really need 64-bit compare-and-exchange.  At least
@@ -107,11 +101,12 @@ typedef uintmax_t uatomic_max_t;
    problems since not many other 32-bit architectures have support for
    such an operation.  So don't define any code for now.  */
 
-# define __arch_compare_and_exchange_64_acq(mem, newval, oldval) \
+# define __arch_compare_and_exchange_val_64_acq(mem, newval, oldval) \
   (abort (), 0)
 
 #define atomic_exchange_and_add(mem, value) \
   ({ __typeof (*mem) __result; \
+     __typeof (value) __value; \
      if (sizeof (*mem) == 1) \
        __asm __volatile ("\
 	  .align 2\n\
@@ -122,7 +117,7 @@ typedef uintmax_t uatomic_max_t;
 	  add %0,%1\n\
 	  mov.b %1,@%2\n\
        1: mov r1,r15"\
-	: "=&r" (__result), "=&r" (value) : "r" (mem), "1" (value) \
+	: "=&r" (__result), "=&r" (__value) : "r" (mem), "1" (value) \
 	: "r0", "r1", "memory"); \
      else if (sizeof (*mem) == 2) \
        __asm __volatile ("\
@@ -134,7 +129,7 @@ typedef uintmax_t uatomic_max_t;
 	  add %0,%1\n\
 	  mov.w %1,@%2\n\
        1: mov r1,r15"\
-	: "=&r" (__result), "=&r" (value) : "r" (mem), "1" (value) \
+	: "=&r" (__result), "=&r" (__value) : "r" (mem), "1" (value) \
 	: "r0", "r1", "memory"); \
      else if (sizeof (*mem) == 4) \
        __asm __volatile ("\
@@ -146,22 +141,23 @@ typedef uintmax_t uatomic_max_t;
 	  add %0,%1\n\
 	  mov.l %1,@%2\n\
        1: mov r1,r15"\
-	: "=&r" (__result), "=&r" (value) : "r" (mem), "1" (value) \
+	: "=&r" (__result), "=&r" (__value) : "r" (mem), "1" (value) \
 	: "r0", "r1", "memory"); \
      else \
        { \
 	 __typeof (value) addval = (value); \
-	 __typeof (*mem) oldval; \
 	 __typeof (mem) memp = (mem); \
 	 do \
-	   __result = (oldval = *memp) + addval; \
-	 while (!__arch_compare_and_exchange_64_acq (memp, __result, oldval));\
+	   __result = *memp; \
+	 while (__arch_compare_and_exchange_val_64_acq \
+		 (memp,	__result + addval, __result) == __result); \
 	 (void) addval; \
        } \
      __result; })
 
 #define atomic_add(mem, value) \
-  (void) ({ if (sizeof (*mem) == 1) \
+  (void) ({ __typeof (value) __value; \
+	    if (sizeof (*mem) == 1) \
 	      __asm __volatile ("\
 		.align 2\n\
 		mova 1f,r0\n\
@@ -171,7 +167,7 @@ typedef uintmax_t uatomic_max_t;
 		add r2,%0\n\
 		mov.b %0,@%1\n\
 	     1: mov r1,r15"\
-		: "=&r" (value) : "r" (mem), "0" (value) \
+		: "=&r" (__value) : "r" (mem), "0" (value) \
 		: "r0", "r1", "r2", "memory"); \
 	    else if (sizeof (*mem) == 2) \
 	      __asm __volatile ("\
@@ -183,7 +179,7 @@ typedef uintmax_t uatomic_max_t;
 		add r2,%0\n\
 		mov.w %0,@%1\n\
 	     1: mov r1,r15"\
-		: "=&r" (value) : "r" (mem), "0" (value) \
+		: "=&r" (__value) : "r" (mem), "0" (value) \
 		: "r0", "r1", "r2", "memory"); \
 	    else if (sizeof (*mem) == 4) \
 	      __asm __volatile ("\
@@ -195,7 +191,7 @@ typedef uintmax_t uatomic_max_t;
 		add r2,%0\n\
 		mov.l %0,@%1\n\
 	     1: mov r1,r15"\
-		: "=&r" (value) : "r" (mem), "0" (value) \
+		: "=&r" (__value) : "r" (mem), "0" (value) \
 		: "r0", "r1", "r2", "memory"); \
 	    else \
 	      { \
@@ -204,15 +200,15 @@ typedef uintmax_t uatomic_max_t;
 		__typeof (mem) memp = (mem); \
 		do \
 		  oldval = *memp; \
-		while (! __arch_compare_and_exchange_64_acq (memp, \
-							     oldval + addval, \
-							     oldval)); \
+		while (__arch_compare_and_exchange_val_64_acq \
+			(memp, oldval + addval, oldval) == oldval); \
 		(void) addval; \
 	      } \
 	    })
 
 #define atomic_add_negative(mem, value) \
   ({ unsigned char __result; \
+     __typeof (value) __value; \
      if (sizeof (*mem) == 1) \
        __asm __volatile ("\
 	  .align 2\n\
@@ -225,7 +221,7 @@ typedef uintmax_t uatomic_max_t;
        1: mov r1,r15\n\
 	  shal %1\n\
 	  movt %0"\
-	: "=r" (__result), "=&r" (value) : "r" (mem), "1" (value) \
+	: "=r" (__result), "=&r" (__value) : "r" (mem), "1" (value) \
 	: "r0", "r1", "r2", "t", "memory"); \
      else if (sizeof (*mem) == 2) \
        __asm __volatile ("\
@@ -239,7 +235,7 @@ typedef uintmax_t uatomic_max_t;
        1: mov r1,r15\n\
 	  shal %1\n\
 	  movt %0"\
-	: "=r" (__result), "=&r" (value) : "r" (mem), "1" (value) \
+	: "=r" (__result), "=&r" (__value) : "r" (mem), "1" (value) \
 	: "r0", "r1", "r2", "t", "memory"); \
      else if (sizeof (*mem) == 4) \
        __asm __volatile ("\
@@ -253,7 +249,7 @@ typedef uintmax_t uatomic_max_t;
        1: mov r1,r15\n\
 	  shal %1\n\
 	  movt %0"\
-	: "=r" (__result), "=&r" (value) : "r" (mem), "1" (value) \
+	: "=r" (__result), "=&r" (__value) : "r" (mem), "1" (value) \
 	: "r0", "r1", "r2", "t", "memory"); \
      else \
        abort (); \
@@ -261,6 +257,7 @@ typedef uintmax_t uatomic_max_t;
 
 #define atomic_add_zero(mem, value) \
   ({ unsigned char __result; \
+     __typeof (value) __value; \
      if (sizeof (*mem) == 1) \
        __asm __volatile ("\
 	  .align 2\n\
@@ -273,7 +270,7 @@ typedef uintmax_t uatomic_max_t;
        1: mov r1,r15\n\
 	  tst %1,%1\n\
 	  movt %0"\
-	: "=r" (__result), "=&r" (value) : "r" (mem), "1" (value) \
+	: "=r" (__result), "=&r" (__value) : "r" (mem), "1" (value) \
 	: "r0", "r1", "r2", "t", "memory"); \
      else if (sizeof (*mem) == 2) \
        __asm __volatile ("\
@@ -287,7 +284,7 @@ typedef uintmax_t uatomic_max_t;
        1: mov r1,r15\n\
 	  tst %1,%1\n\
 	  movt %0"\
-	: "=r" (__result), "=&r" (value) : "r" (mem), "1" (value) \
+	: "=r" (__result), "=&r" (__value) : "r" (mem), "1" (value) \
 	: "r0", "r1", "r2", "t", "memory"); \
      else if (sizeof (*mem) == 4) \
        __asm __volatile ("\
@@ -301,7 +298,7 @@ typedef uintmax_t uatomic_max_t;
        1: mov r1,r15\n\
 	  tst %1,%1\n\
 	  movt %0"\
-	: "=r" (__result), "=&r" (value) : "r" (mem), "1" (value) \
+	: "=r" (__result), "=&r" (__value) : "r" (mem), "1" (value) \
 	: "r0", "r1", "r2", "t", "memory"); \
      else \
        abort (); \

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] SH: atomic.h fixes
  2003-03-29  1:23 [PATCH] SH: atomic.h fixes kaz Kojima
@ 2003-03-29  2:06 ` Ulrich Drepper
  2003-03-29  2:13   ` kaz Kojima
  0 siblings, 1 reply; 11+ messages in thread
From: Ulrich Drepper @ 2003-03-29  2:06 UTC (permalink / raw)
  To: kaz Kojima; +Cc: libc-hacker

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kaz Kojima wrote:

> This is a patch for sh specific atomic.h. It's corresponding to
> the similar change on the other architectures and also fixes
> a problem when the macro is used with constant arguments.

Thanks, I've applied it.

> BTW, the atomic operations in sh's atomic.h suppose a special
> kernel support. Should it be moved to sysdeps/unix/sysv/linux/sh/bits?

Yes, unless there are effort underway to standardize the interfaces for
SH/ELF in general.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+hPV42ijCOnn/RHQRAuS9AKDHUY7BcqbrdJq8FtTmK2/QD6AelwCeO38P
p4NP5390bbebH4+tp4ODmE4=
=9PeW
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] SH: atomic.h fixes
  2003-03-29  2:06 ` Ulrich Drepper
@ 2003-03-29  2:13   ` kaz Kojima
  2003-03-29  2:26     ` Roland McGrath
  2003-03-29  2:36     ` Ulrich Drepper
  0 siblings, 2 replies; 11+ messages in thread
From: kaz Kojima @ 2003-03-29  2:13 UTC (permalink / raw)
  To: libc-hacker

Ulrich Drepper <drepper@redhat.com> wrote:
>> BTW, the atomic operations in sh's atomic.h suppose a special
>> kernel support. Should it be moved to sysdeps/unix/sysv/linux/sh/bits?
> 
> Yes, unless there are effort underway to standardize the interfaces for
> SH/ELF in general.

Would it be better to propose this move as a patch?

Regards,
	kaz


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] SH: atomic.h fixes
  2003-03-29  2:13   ` kaz Kojima
@ 2003-03-29  2:26     ` Roland McGrath
  2003-03-29  2:39       ` kaz Kojima
  2003-03-29  2:36     ` Ulrich Drepper
  1 sibling, 1 reply; 11+ messages in thread
From: Roland McGrath @ 2003-03-29  2:26 UTC (permalink / raw)
  To: kaz Kojima; +Cc: libc-hacker

Your current version looks like it still evaluates the macro arg VALUE twice
in several macros.  Also, I am not sure about using __typeof(value).
Stick to __typeof(*(mem)) (and don't forget the parens around the macro arg),
since the value might be a widened literal or something.

I don't know SH at all, but I don't see anything that looks like system
calls in here so I am confused by your comments.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] SH: atomic.h fixes
  2003-03-29  2:13   ` kaz Kojima
  2003-03-29  2:26     ` Roland McGrath
@ 2003-03-29  2:36     ` Ulrich Drepper
  2003-03-29  2:58       ` kaz Kojima
  1 sibling, 1 reply; 11+ messages in thread
From: Ulrich Drepper @ 2003-03-29  2:36 UTC (permalink / raw)
  To: kaz Kojima; +Cc: libc-hacker

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kaz Kojima wrote:

> Would it be better to propose this move as a patch?

If you say this is the right thing to do I'll move the file.  A patch
isn't necessary.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+hQQs2ijCOnn/RHQRAnQlAKDMIJ/ftEiDtX0vCXA/kLg9hENRpgCfSGby
GJiEIivtOLsEM43LulaFK50=
=vCcR
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] SH: atomic.h fixes
  2003-03-29  2:26     ` Roland McGrath
@ 2003-03-29  2:39       ` kaz Kojima
  2003-03-29  2:40         ` Roland McGrath
  0 siblings, 1 reply; 11+ messages in thread
From: kaz Kojima @ 2003-03-29  2:39 UTC (permalink / raw)
  To: libc-hacker

Roland McGrath <roland@redhat.com> wrote:
> Your current version looks like it still evaluates the macro arg VALUE twice
> in several macros.  Also, I am not sure about using __typeof(value).
> Stick to __typeof(*(mem)) (and don't forget the parens around the macro arg),
> since the value might be a widened literal or something.

I'd like to fix these points. Thanks.

> I don't know SH at all, but I don't see anything that looks like system
> calls in here so I am confused by your comments.

Yes, there are no system calls. Please see
<URL:http://sources.redhat.com/ml/libc-hacker/2002-05/msg00029.html>.

Regards,
	kaz

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] SH: atomic.h fixes
  2003-03-29  2:39       ` kaz Kojima
@ 2003-03-29  2:40         ` Roland McGrath
  2003-03-29  3:03           ` kaz Kojima
  0 siblings, 1 reply; 11+ messages in thread
From: Roland McGrath @ 2003-03-29  2:40 UTC (permalink / raw)
  To: kaz Kojima; +Cc: libc-hacker

> Yes, there are no system calls. Please see
> <URL:http://sources.redhat.com/ml/libc-hacker/2002-05/msg00029.html>.

I see.  Nice scheme.  Please put some comments in bits/atomic.h explaining it.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] SH: atomic.h fixes
  2003-03-29  2:36     ` Ulrich Drepper
@ 2003-03-29  2:58       ` kaz Kojima
  0 siblings, 0 replies; 11+ messages in thread
From: kaz Kojima @ 2003-03-29  2:58 UTC (permalink / raw)
  To: libc-hacker

Ulrich Drepper <drepper@redhat.com> wrote:
> kaz Kojima wrote:
> 
>> Would it be better to propose this move as a patch?
> 
> If you say this is the right thing to do I'll move the file.  A patch
> isn't necessary.

Yep, I believe it is the right thing at this stage.

Regards,
	kaz

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] SH: atomic.h fixes
  2003-03-29  2:40         ` Roland McGrath
@ 2003-03-29  3:03           ` kaz Kojima
  2003-03-29  4:10             ` David Mosberger
  0 siblings, 1 reply; 11+ messages in thread
From: kaz Kojima @ 2003-03-29  3:03 UTC (permalink / raw)
  To: libc-hacker

Roland McGrath <roland@redhat.com> wrote:
>> Yes, there are no system calls. Please see
>> <URL:http://sources.redhat.com/ml/libc-hacker/2002-05/msg00029.html>.
> 
> I see.  Nice scheme.  Please put some comments in bits/atomic.h explaining it.

It's a good idea. I'll come up with a patch. Thanks a lot.

Regards,
	kaz

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] SH: atomic.h fixes
  2003-03-29  3:03           ` kaz Kojima
@ 2003-03-29  4:10             ` David Mosberger
  2003-03-29  6:59               ` kaz Kojima
  0 siblings, 1 reply; 11+ messages in thread
From: David Mosberger @ 2003-03-29  4:10 UTC (permalink / raw)
  To: kaz Kojima; +Cc: libc-hacker

>>>>> On Sat, 29 Mar 2003 12:04:14 +0900, kaz Kojima <kkojima@rr.iij4u.or.jp> said:

  Roland> Roland McGrath <roland@redhat.com> wrote:

  >  I see.  Nice scheme.  Please put some comments in bits/atomic.h
  > explaining it.

Perhaps a pointer to Bershad's paper might be appropriate, too:

 B.N. Bershad, D. Redell, and J. Ellis.  Fast Mutual Exclusion for
 Uniprocessors.  Proceedings of the Fifth Architectural Support for
 Programming Languages and Operating Systems (ASPLOS), pp. 223-233,
 October 1992.

 http://www.cs.washington.edu/homes/bershad/Papers/Rcs.ps

	--david

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] SH: atomic.h fixes
  2003-03-29  4:10             ` David Mosberger
@ 2003-03-29  6:59               ` kaz Kojima
  0 siblings, 0 replies; 11+ messages in thread
From: kaz Kojima @ 2003-03-29  6:59 UTC (permalink / raw)
  To: davidm; +Cc: libc-hacker

David Mosberger <davidm@napali.hpl.hp.com> wrote:
> Perhaps a pointer to Bershad's paper might be appropriate, too:
> 
>  B.N. Bershad, D. Redell, and J. Ellis.  Fast Mutual Exclusion for
>  Uniprocessors.  Proceedings of the Fifth Architectural Support for
>  Programming Languages and Operating Systems (ASPLOS), pp. 223-233,
>  October 1992.
> 
>  http://www.cs.washington.edu/homes/bershad/Papers/Rcs.ps

Thanks for the pointer. I'll read it.

Regards,
	kaz

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2003-03-29  4:10 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-29  1:23 [PATCH] SH: atomic.h fixes kaz Kojima
2003-03-29  2:06 ` Ulrich Drepper
2003-03-29  2:13   ` kaz Kojima
2003-03-29  2:26     ` Roland McGrath
2003-03-29  2:39       ` kaz Kojima
2003-03-29  2:40         ` Roland McGrath
2003-03-29  3:03           ` kaz Kojima
2003-03-29  4:10             ` David Mosberger
2003-03-29  6:59               ` kaz Kojima
2003-03-29  2:36     ` Ulrich Drepper
2003-03-29  2:58       ` kaz Kojima

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).