powerpc64 libffi not yet ported

powerpc64 libffi not yet ported

[Alan Modra]

This at least lets us get to the point of compiling libjava on a
powerpc-linux host.

	* configure.host: Add powerpc64*-* entry.

OK mainline?

Index: libjava/configure.host
===================================================================
RCS file: /cvs/gcc/gcc/libjava/configure.host,v
retrieving revision 1.35
diff -u -p -r1.35 configure.host
--- libjava/configure.host	19 Jul 2002 14:41:14 -0000	1.35
+++ libjava/configure.host	26 Jul 2002 07:17:16 -0000
@@ -101,6 +101,16 @@ case "${host}" in
 	libgcj_interpreter=yes
 	enable_hash_synchronization_default=yes
 	;;
+  powerpc64*-*)
+	# libffi not ported.
+	with_libffi_default=no
+	libgcj_interpreter=no
+	libgcj_flags="${libgcj_flags} -mminimal-toc"
+	# this may not be correct
+	sysdeps_dir=powerpc
+	enable_hash_synchronization_default=yes
+	slow_pthread_self=yes
+	;;
   powerpc*-*)
 	sysdeps_dir=powerpc
 	libgcj_interpreter=yes

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: powerpc64 libffi not yet ported

[Tom Tromey]

>>>>> "Alan" == Alan Modra <amodra@bigpond.net.au> writes:

Alan> 	* configure.host: Add powerpc64*-* entry.
Alan> OK mainline?

Yes, thanks.

Alan> +	# this may not be correct
Alan> +	sysdeps_dir=powerpc

Could you look at this code to see if it will work for this powerpc64?

Tom

Re: powerpc64 libffi not yet ported

[Jeff Sturm]

On Fri, 26 Jul 2002, Alan Modra wrote:
> +  powerpc64*-*)
> +	# libffi not ported.
> +	with_libffi_default=no

Will you by any chance be working on libffi for powerpc64?  I assume this
is an LP64 target?

I've had issues with sparc64 related to word size and endianness.
Though the patches I recently posted contain a workaround, I'd like to
solve them in a more general way.

Jeff

Re: powerpc64 libffi not yet ported

[Alan Modra]

On Fri, Jul 26, 2002 at 12:27:15PM -0400, Jeff Sturm wrote:
> On Fri, 26 Jul 2002, Alan Modra wrote:
> > +  powerpc64*-*)
> > +	# libffi not ported.
> > +	with_libffi_default=no
> 
> Will you by any chance be working on libffi for powerpc64?

If not me, then probably someone else from IBM's LTC.

> I assume this is an LP64 target?

Yes.

> I've had issues with sparc64 related to word size and endianness.
> Though the patches I recently posted contain a workaround, I'd like to
> solve them in a more general way.

I'd like to see someone else solve all the tricky problems so we
can do an easy port.  :-)

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: powerpc64 libffi not yet ported

[dank]

David Edelsohn wrote:
>         The multilib is redundant.  If GCC is configured for ppc405, then
> build libstdc++ with the extra sync, period.  No multilib.

But then that gcc can't also generate good executables for, say, the ppc750,
which doesn't need the extra sync.  So the multilib is not redundant at all.

If the multilib stuff is so offensive to you, then go ahead and
commit just the changes to libjava/sysdep/powerpc/locks.h
and libstdc++-v3/config/cpu/powerpc/bits/atomicity.h   

I must admit I'm mystified by your opposition to the optional multilib
generation.  Could you explain the downside to it?

Thanks,
Dan

Re: powerpc64 libffi not yet ported

[David Edelsohn]

	The multilib is redundant.  If GCC is configured for ppc405, then
build libstdc++ with the extra sync, period.  No multilib.

David

Re: powerpc64 libffi not yet ported

[dank]

David Edelsohn wrote:
> > Also, please note that just having powerpc processor instructions
> > seems to also be insufficient, at least for some powerpc chips. See
> > libstdc++/7383. I'd appreciate it if a powerpc maintainer could figure
> > out how to work ppc405 work-arounds into the libstdc++ atomicity.h file. 
>
>         I am not currently inclined to create a PPC405 multilib, as
> suggested in the PR.  This basically says that one cannot use
> multithreaded apps or libraries created for any other PowerPC processor on
> this chip.  I can only see this as useful for GCC explicitly configured
> for PPC405, not a runtime option.

The patch referred to in the PR only creates a PPC405 multilib only
when using a GCC explicitly configured for PPC405.  It's behaving
exactly as you request, I think.  (If you look carefully at the
config-ml.in change, you'll see it *disables* the ppc405 multilib by
default.  Whoever configures GCC must explicitly enable the ppc405 multilib
if they want the workaround.)

Applying the patch would not affect anyone but PPC405 users, I'm quite sure.
Can you have another look, please?  Here's the latest version of the patch:
http://www.kegel.com/xgcc3/gcc-20020722-ppc405erratum77.patch

Thanks,
Dan

Re: powerpc64 libffi not yet ported

[David Edelsohn]

	Is a C conditional in the middle of the inline asm really the best
way to do this?  I don't like this style much.

David

Re: powerpc64 libffi not yet ported

[Alan Modra]

On Fri, Jul 26, 2002 at 02:28:59PM -0400, David Edelsohn wrote:
> Alan> + # this may not be correct
> Alan> + sysdeps_dir=powerpc
> 
> Tom> Could you look at this code to see if it will work for this powerpc64?
> 
> 	The code generally is correct except that compare_and_swap need to
> use 64-bit load-linked-store-conditional instructions, not 32-bit, because
> size_t will be a 64-bit object.
> 
> 	I think that localizing the maintenance and using some #ifdef is
> better than two separate directories.

Well, that's easy.

libjava/ChangeLog
	* sysdep/powerpc/locks.h: Formatting.
	(compare_and_swap): Support powerpc64.
	(compare_and_swap_release): Likewise.

powerpc-linux bootstrap and regression test in progress.  OK mainline
assuming no regressions?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Index: libjava/sysdep/powerpc/locks.h
===================================================================
RCS file: /cvs/gcc/gcc/libjava/sysdep/powerpc/locks.h,v
retrieving revision 1.2
diff -u -p -r1.2 locks.h
--- libjava/sysdep/powerpc/locks.h	21 Mar 2002 00:26:45 -0000	1.2
+++ libjava/sysdep/powerpc/locks.h	27 Jul 2002 08:23:10 -0000
@@ -15,21 +15,32 @@ typedef size_t obj_addr_t;	/* Integer ty
 				/* address.				*/
 
 inline static bool
-compare_and_swap(volatile obj_addr_t *addr,
-		  			      obj_addr_t old,
-					      obj_addr_t new_val) 
+compare_and_swap (volatile obj_addr_t *addr, obj_addr_t old,
+		  obj_addr_t new_val) 
 {
   int ret;
 
-  __asm__ __volatile__ (
+  if (sizeof (obj_addr_t) == 8)
+    __asm__ __volatile__ (
+	   "0:    ldarx %0,0,%1 ;"
+	   "      xor. %0,%3,%0;"
+	   "      bne 1f;"
+	   "      stdcx. %2,0,%1;"
+	   "      bne- 0b;"
+	   "1:    "
+	: "=&r" (ret)
+	: "r" (addr), "r" (new_val), "r" (old)
+	: "cr0", "memory");
+  else
+    __asm__ __volatile__ (
 	   "0:    lwarx %0,0,%1 ;"
 	   "      xor. %0,%3,%0;"
 	   "      bne 1f;"
 	   "      stwcx. %2,0,%1;"
 	   "      bne- 0b;"
 	   "1:    "
-	: "=&r"(ret)
-	: "r"(addr), "r"(new_val), "r"(old)
+	: "=&r" (ret)
+	: "r" (addr), "r" (new_val), "r" (old)
 	: "cr0", "memory");
   /* This version of __compare_and_swap is to be used when acquiring
      a lock, so we don't need to worry about whether other memory
@@ -40,29 +51,40 @@ compare_and_swap(volatile obj_addr_t *ad
 }
 
 inline static void
-release_set(volatile obj_addr_t *addr, obj_addr_t new_val)
+release_set (volatile obj_addr_t *addr, obj_addr_t new_val)
 {
   __asm__ __volatile__ ("sync" : : : "memory");
-  *(addr) = new_val;
+  *addr = new_val;
 }
 
 inline static bool
-compare_and_swap_release(volatile obj_addr_t *addr,
-		  				     obj_addr_t old,
-						     obj_addr_t new_val)
+compare_and_swap_release (volatile obj_addr_t *addr, obj_addr_t old,
+			  obj_addr_t new_val)
 {
   int ret;
 
   __asm__ __volatile__ ("sync" : : : "memory");
-  __asm__ __volatile__ (
+  if (sizeof (obj_addr_t) == 8)
+    __asm__ __volatile__ (
+	   "0:    ldarx %0,0,%1 ;"
+	   "      xor. %0,%3,%0;"
+	   "      bne 1f;"
+	   "      stdcx. %2,0,%1;"
+	   "      bne- 0b;"
+	   "1:    "
+	: "=&r" (ret)
+	: "r" (addr), "r" (new_val), "r" (old)
+	: "cr0", "memory");
+  else
+    __asm__ __volatile__ (
 	   "0:    lwarx %0,0,%1 ;"
 	   "      xor. %0,%3,%0;"
 	   "      bne 1f;"
 	   "      stwcx. %2,0,%1;"
 	   "      bne- 0b;"
 	   "1:    "
-	: "=&r"(ret)
-	: "r"(addr), "r"(new_val), "r"(old)
+	: "=&r" (ret)
+	: "r" (addr), "r" (new_val), "r" (old)
 	: "cr0", "memory");
   return ret == 0;
 }
@@ -70,7 +92,7 @@ compare_and_swap_release(volatile obj_ad
 // Ensure that subsequent instructions do not execute on stale
 // data that was loaded from memory before the barrier.
 inline static void
-read_barrier()
+read_barrier ()
 {
   __asm__ __volatile__ ("isync" : : : "memory");
 }
@@ -78,7 +100,7 @@ read_barrier()
 // Ensure that prior stores to memory are completed with respect to other
 // processors.
 inline static void
-write_barrier()
+write_barrier ()
 {
   __asm__ __volatile__ ("sync" : : : "memory");
 }

Re: powerpc64 libffi not yet ported

[David Edelsohn]

	I am not currently inclined to create a PPC405 multilib, as
suggested in the PR.  This basically says that one cannot use
multithreaded apps or libraries created for any other PowerPC processor on
this chip.  I can only see this as useful for GCC explicitly configured
for PPC405, not a runtime option.

David

Re: powerpc64 libffi not yet ported

[Benjamin Kosnik]

> 	For AIX, we probably need a separate directory because one needs
> to use AIX primitives, not the the processor instructions.  Similar to the
> compare_and_swap support in libstdc++-v3.

Yep. I remember this issue well.

Also, please note that just having powerpc processor instructions
seems to also be insufficient, at least for some powerpc chips. See
libstdc++/7383. I'd appreciate it if a powerpc maintainer could figure
out how to work ppc405 work-arounds into the libstdc++ atomicity.h file. 

The work is mostly done and in the PR. Can I assign it to somebody,
and if so, who?

thanks!
benjamin

Re: powerpc64 libffi not yet ported

[Tom Tromey]

>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:

David> I think that localizing the maintenance and using some #ifdef
David> is better than two separate directories.

Sounds good, thanks for looking at this.

Tom

Re: powerpc64 libffi not yet ported

[David Edelsohn]

Alan> + # this may not be correct
Alan> + sysdeps_dir=powerpc

Tom> Could you look at this code to see if it will work for this powerpc64?

	The code generally is correct except that compare_and_swap need to
use 64-bit load-linked-store-conditional instructions, not 32-bit, because
size_t will be a 64-bit object.

	I think that localizing the maintenance and using some #ifdef is
better than two separate directories.

	For AIX, we probably need a separate directory because one needs
to use AIX primitives, not the the processor instructions.  Similar to the
compare_and_swap support in libstdc++-v3.

David