* powerpc64 libffi not yet ported
@ 2002-07-26 3:46 Alan Modra
2002-07-26 8:39 ` Tom Tromey
2002-07-26 9:33 ` Jeff Sturm
0 siblings, 2 replies; 13+ messages in thread
From: Alan Modra @ 2002-07-26 3:46 UTC (permalink / raw)
To: gcc-patches
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
2002-07-26 3:46 powerpc64 libffi not yet ported Alan Modra
@ 2002-07-26 8:39 ` Tom Tromey
2002-07-26 9:33 ` Jeff Sturm
1 sibling, 0 replies; 13+ messages in thread
From: Tom Tromey @ 2002-07-26 8:39 UTC (permalink / raw)
To: Alan Modra; +Cc: gcc-patches
>>>>> "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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
2002-07-26 3:46 powerpc64 libffi not yet ported Alan Modra
2002-07-26 8:39 ` Tom Tromey
@ 2002-07-26 9:33 ` Jeff Sturm
2002-07-26 17:23 ` Alan Modra
1 sibling, 1 reply; 13+ messages in thread
From: Jeff Sturm @ 2002-07-26 9:33 UTC (permalink / raw)
To: Alan Modra; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
2002-07-26 9:33 ` Jeff Sturm
@ 2002-07-26 17:23 ` Alan Modra
0 siblings, 0 replies; 13+ messages in thread
From: Alan Modra @ 2002-07-26 17:23 UTC (permalink / raw)
To: Jeff Sturm; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
2002-07-27 17:00 ` David Edelsohn
@ 2002-07-27 17:20 ` dank
0 siblings, 0 replies; 13+ messages in thread
From: dank @ 2002-07-27 17:20 UTC (permalink / raw)
To: David Edelsohn; +Cc: bkoz, gcc-patches
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
2002-07-27 16:26 ` dank
@ 2002-07-27 17:00 ` David Edelsohn
2002-07-27 17:20 ` dank
0 siblings, 1 reply; 13+ messages in thread
From: David Edelsohn @ 2002-07-27 17:00 UTC (permalink / raw)
To: dank; +Cc: bkoz, gcc-patches
The multilib is redundant. If GCC is configured for ppc405, then
build libstdc++ with the extra sync, period. No multilib.
David
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
2002-07-26 13:38 ` David Edelsohn
@ 2002-07-27 16:26 ` dank
2002-07-27 17:00 ` David Edelsohn
0 siblings, 1 reply; 13+ messages in thread
From: dank @ 2002-07-27 16:26 UTC (permalink / raw)
To: David Edelsohn; +Cc: bkoz, gcc-patches
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
2002-07-27 1:50 ` Alan Modra
@ 2002-07-27 14:08 ` David Edelsohn
0 siblings, 0 replies; 13+ messages in thread
From: David Edelsohn @ 2002-07-27 14:08 UTC (permalink / raw)
To: Alan Modra; +Cc: gcc-patches, tromey
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
2002-07-26 11:50 David Edelsohn
2002-07-26 12:40 ` Tom Tromey
@ 2002-07-27 1:50 ` Alan Modra
2002-07-27 14:08 ` David Edelsohn
1 sibling, 1 reply; 13+ messages in thread
From: Alan Modra @ 2002-07-27 1:50 UTC (permalink / raw)
To: gcc-patches; +Cc: tromey, David Edelsohn
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");
}
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
2002-07-26 13:14 Benjamin Kosnik
@ 2002-07-26 13:38 ` David Edelsohn
2002-07-27 16:26 ` dank
0 siblings, 1 reply; 13+ messages in thread
From: David Edelsohn @ 2002-07-26 13:38 UTC (permalink / raw)
To: bkoz; +Cc: gcc-patches, dank
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
@ 2002-07-26 13:14 Benjamin Kosnik
2002-07-26 13:38 ` David Edelsohn
0 siblings, 1 reply; 13+ messages in thread
From: Benjamin Kosnik @ 2002-07-26 13:14 UTC (permalink / raw)
To: gcc-patches, dje, amodra
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
2002-07-26 11:50 David Edelsohn
@ 2002-07-26 12:40 ` Tom Tromey
2002-07-27 1:50 ` Alan Modra
1 sibling, 0 replies; 13+ messages in thread
From: Tom Tromey @ 2002-07-26 12:40 UTC (permalink / raw)
To: David Edelsohn; +Cc: Alan Modra, gcc-patches
>>>>> "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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: powerpc64 libffi not yet ported
@ 2002-07-26 11:50 David Edelsohn
2002-07-26 12:40 ` Tom Tromey
2002-07-27 1:50 ` Alan Modra
0 siblings, 2 replies; 13+ messages in thread
From: David Edelsohn @ 2002-07-26 11:50 UTC (permalink / raw)
To: Alan Modra, tromey; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2002-07-27 23:56 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-26 3:46 powerpc64 libffi not yet ported Alan Modra
2002-07-26 8:39 ` Tom Tromey
2002-07-26 9:33 ` Jeff Sturm
2002-07-26 17:23 ` Alan Modra
2002-07-26 11:50 David Edelsohn
2002-07-26 12:40 ` Tom Tromey
2002-07-27 1:50 ` Alan Modra
2002-07-27 14:08 ` David Edelsohn
2002-07-26 13:14 Benjamin Kosnik
2002-07-26 13:38 ` David Edelsohn
2002-07-27 16:26 ` dank
2002-07-27 17:00 ` David Edelsohn
2002-07-27 17:20 ` dank
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).