Atomic operations for PA

Atomic operations for PA

[John David Anglin]

The enclosed patch adds __exchange_and_add and __atomic_add to libstdc++
for the PA.  It is based on a patch that Alan Modra sent me.  However,
it wasn't fully ansi compatible and it didn't work with 32-bit hpux.
So, I rewrote the locking asm and added code to allow for explicit
instantiantion of the lock structure under hpux.

The PA has only one atomic instruction and the address it uses must
be 16-byte aligned.  Thus, we need an atomicity lock structure.  Since
the 32-bit hpux port doesn't support weak, I had to explicitly
instantiate it somewhere.  I picked src/misc-inst.cc as it seemed
to contain other miscellaneous instantiations.  I realize that
this is somewhat ugly but I don't see any way around this.

The patch has been tested on hppa-unknown-linux-gnu, hppa2.0-hp-hpux11*,
and hppa64-hp-hpux11*.  There are no regressions and under hppa-linux
it appears to fix pthread[2-3].cc.

Ok for main.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-11-05  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* configure.target (hppa*): Define cpu_include_dir.
	* config/os/hpux/os_defines.h (_GLIBCPP_INST_ATOMICITY_LOCK): Define.
	* src/misc-inst.cc (std): Instantiate atomicity lock when
	_GLIBCPP_INST_ATOMICITY_LOCK is defined.
	* config/cpu/hppa/atomicity.h: New file.

Index: configure.target
===================================================================
RCS file: /cvsroot/gcc/gcc/libstdc++-v3/configure.target,v
retrieving revision 1.54
diff -u -3 -p -r1.54 configure.target
--- configure.target	2 Nov 2002 01:42:21 -0000	1.54
+++ configure.target	4 Nov 2002 21:17:15 -0000
@@ -72,6 +72,9 @@ case "${target_cpu}" in
   athlon* | i586 | i686 | i786 | x86_64)
     cpu_include_dir="cpu/i486"
     ;;
+  hppa*)
+    cpu_include_dir="cpu/hppa"
+    ;;
   m680[246]0)
     cpu_include_dir="cpu/m68k"
     ;;
Index: config/os/hpux/os_defines.h
===================================================================
RCS file: /cvsroot/gcc/gcc/libstdc++-v3/config/os/hpux/os_defines.h,v
retrieving revision 1.3
diff -u -3 -p -r1.3 os_defines.h
--- config/os/hpux/os_defines.h	26 Sep 2002 05:25:10 -0000	1.3
+++ config/os/hpux/os_defines.h	4 Nov 2002 21:17:15 -0000
@@ -84,4 +84,8 @@ namespace std 
 typedef long int __padding_type;
 #endif
 
+/* We need explicit instantiation of the atomicity lock on 32-bit HPUX.  */
+#ifndef __LP64__
+#define _GLIBCPP_INST_ATOMICITY_LOCK 1
+#endif
 #endif
Index: src/misc-inst.cc
===================================================================
RCS file: /cvsroot/gcc/gcc/libstdc++-v3/src/misc-inst.cc,v
retrieving revision 1.19
diff -u -3 -p -r1.19 misc-inst.cc
--- src/misc-inst.cc	9 Sep 2002 20:26:42 -0000	1.19
+++ src/misc-inst.cc	4 Nov 2002 21:17:15 -0000
@@ -37,6 +37,7 @@
 #include <ostream>
 #include <algorithm>
 #include <vector>
+#include <bits/atomicity.h>
 
 namespace std
 {
@@ -66,6 +67,9 @@ namespace std
   template 
     basic_istream<wchar_t>& 
     getline(basic_istream<wchar_t>&, wstring&);
+#endif
+#ifdef _GLIBCPP_INST_ATOMICITY_LOCK
+  template volatile int __Atomicity_lock<0>::_S_atomicity_lock;
 #endif
 
 #if 1
--- /dev/null	Mon Nov  4 16:19:42 2002
+++ config/cpu/hppa/atomicity.h	Mon Nov  4 16:09:50 2002
@@ -0,0 +1,87 @@
+/* Low-level functions for atomic operations.  PA-RISC version. -*- C++ -*-
+   Copyright 2002 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Library General Public License as
+   published by the Free Software Foundation; either version 2 of the
+   License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Library General Public License for more details.
+
+   You should have received a copy of the GNU Library General Public
+   License along with the GNU C Library; see the file COPYING.LIB.  If not,
+   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#ifndef _BITS_ATOMICITY_H
+#define _BITS_ATOMICITY_H	1
+
+typedef int _Atomic_word;
+
+template <int __inst>
+struct __Atomicity_lock
+{
+  static volatile int __attribute__ ((aligned (16))) _S_atomicity_lock;
+};
+
+template <int __inst>
+volatile int __Atomicity_lock<__inst>::_S_atomicity_lock = 1;
+
+/* Because of the lack of weak support when using the hpux
+   som linker, we explicitly instantiate the atomicity lock
+   in src/misc-inst.cc when _GLIBCPP_INST_ATOMICITY_LOCK
+   is defined.  */
+#ifndef _GLIBCPP_INST_ATOMICITY_LOCK
+template volatile int __Atomicity_lock<0>::_S_atomicity_lock;
+#endif
+
+static inline int
+__attribute__ ((__unused__))
+__exchange_and_add (volatile _Atomic_word* __mem, int __val)
+{
+  _Atomic_word result;
+  int tmp;
+  volatile int& lock = __Atomicity_lock<0>::_S_atomicity_lock;
+
+  __asm__ __volatile__ ("ldcw 0(%1),%0\n\t"
+			"cmpib,<>,n 0,%0,.+20\n\t"
+			"ldw 0(%1),%0\n\t"
+			"cmpib,= 0,%0,.-4\n\t"
+			"nop\n\t"
+			"b,n .-20"
+			: "=&r" (tmp)
+			: "r" (&lock));
+
+  result = *__mem;
+  *__mem = result + __val;
+  __asm__ __volatile__("");
+  lock = tmp;
+  return result;
+}
+
+static inline void
+__attribute__ ((__unused__))
+__atomic_add (_Atomic_word* __mem, int __val)
+{
+  int tmp;
+  volatile int& lock = __Atomicity_lock<0>::_S_atomicity_lock;
+
+  __asm__ __volatile__ ("ldcw 0(%1),%0\n\t"
+			"cmpib,<>,n 0,%0,.+20\n\t"
+			"ldw 0(%1),%0\n\t"
+			"cmpib,= 0,%0,.-4\n\t"
+			"nop\n\t"
+			"b,n .-20"
+			: "=&r" (tmp)
+			: "r" (&lock));
+
+  *__mem += __val;
+  __asm__ __volatile__("");
+  lock = tmp;
+}
+
+#endif

Re: Atomic operations for PA

[Benjamin Kosnik]

>The patch has been tested on hppa-unknown-linux-gnu, hppa2.0-hp-hpux11*,
>and hppa64-hp-hpux11*.  There are no regressions and under hppa-linux
>it appears to fix pthread[2-3].cc.

Ok, with comments.

>Index: configure.target
>===================================================================
>RCS file: /cvsroot/gcc/gcc/libstdc++-v3/configure.target,v
>retrieving revision 1.54
>diff -u -3 -p -r1.54 configure.target
>--- configure.target	2 Nov 2002 01:42:21 -0000	1.54
>+++ configure.target	4 Nov 2002 21:17:15 -0000
>@@ -72,6 +72,9 @@ case "${target_cpu}" in
>   athlon* | i586 | i686 | i786 | x86_64)
>     cpu_include_dir="cpu/i486"
>     ;;
>+  hppa*)
>+    cpu_include_dir="cpu/hppa"
>+    ;;
>   m680[246]0)
>     cpu_include_dir="cpu/m68k"
>     ;;

This is the default. I don't think you need this part (see ia64, which
also doesn't need this part.)

-benjamin

Re: Atomic operations for PA

[Phil Edwards]

On Tue, Nov 05, 2002 at 12:50:20PM -0600, Benjamin Kosnik wrote:
> >The patch has been tested on hppa-unknown-linux-gnu, hppa2.0-hp-hpux11*,
> >and hppa64-hp-hpux11*.  There are no regressions and under hppa-linux
[...]
> >+  hppa*)
> >+    cpu_include_dir="cpu/hppa"
> >+    ;;
> >   m680[246]0)
> >     cpu_include_dir="cpu/m68k"
> >     ;;
> 
> This is the default. I don't think you need this part (see ia64, which
> also doesn't need this part.)

I was thinking the same thing, but doesn't it also have to match hppa2.0 and
hppa64 as cpu names?  The default would look for three different directories.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: Atomic operations for PA

[John David Anglin]

> I was thinking the same thing, but doesn't it also have to match hppa2.0 and
> hppa64 as cpu names?  The default would look for three different directories.

Yes.  I did a quick check on hppa-unknown-linux-gnu and unfortunately
missed this.

Thanks,
Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Atomic operations for PA

[B. Kosnik]

>> I was thinking the same thing, but doesn't it also have to match hppa2.0 and
>> hppa64 as cpu names?  The default would look for three different directories.
>
>Yes.  I did a quick check on hppa-unknown-linux-gnu and unfortunately
>missed this.

Sorry. I guess your patch was more correct as posted. Can you add the
configure.target bits please?

-benjamin

Re: Atomic operations for PA

[John David Anglin]

> Sorry. I guess your patch was more correct as posted. Can you add the
> configure.target bits please?

Done.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)