Bug#579780: powerpcspe: Preliminary architecture port and minor bugfix
Package: gcc-4.4
Version: 4.4.2-9 Severity: normal Tags: sid patch The 'powerpcspe' architecture is a binary-incompatible variant of PowerPC/POWER designed and supported by FreeScale and IBM. It is also known under the trade names "e500"/"MPC8500" and "e200"/"MPC5xx". This architecture was added to dpkg in commit feb5792 on 2010/04/30: http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=feb5792 Additional information can be found at: http://en.wikipedia.org/wiki/PowerPC_e500 http://en.wikipedia.org/wiki/PowerPC_e200 In particular, the 'powerpcspe' architecture lacks the classic FPU with dedicated FPRs found on most other PowerPC systems. It is replaced with a set of "SPE" instructions which perform floating-point operations on the integer registers. In an unfortunate choice of architecture design, the instructions used for the "SPE" operations overlap with those for the AltiVec unit on most other modern PowerPC cores. The "e500v2"-series chips have 64-bit GPRs, where the high 32-bits are accesible only via the special "SPE" instructions, allowing them to make efficient use of the "double" datatype. The relative rare "e500v1"-series chips have only 32-bit GPRs, and require software traps and emulation to support native "double". The "e200z3" and "e200z6" chips have no support for floating point at all, but with software traps and emulation are binary-compatible with the "e500"-series chips. The Debian port to this architecture specifically chooses to optimize for the higher-end chips (e500v2), as most of the others are targeted at automotive applications or no longer in production. GCC by default builds correctly with full support for the e500v2 as long as the following options are passed to "configure": --with-cpu=8548 --enable-e500_double --with-long-double-128 The only changes needed are to extend a few matches on "powerpc ppc64" to also match "powerpcspe" to ensure that we include essential headers. One of those headers in particular (spe.h) is necessary to successfully build EGLIBC's floating-point support. At this time the 'powerpcspe' architecture port is still very much an unofficial port. While we hope that will change in the future, it is entirely possible that the embedded niche of the processor will make such an official Debian port problematic. Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com> --- debian/rules.d/binary-gcc-cross.mk | 4 ++-- debian/rules.d/binary-gcc.mk | 2 +- debian/rules.d/binary-java.mk | 2 +- debian/rules2 | 4 ++++ 4 files changed, 8 insertions(+), 4 deletions(-) diff --git a/debian/rules.d/binary-gcc-cross.mk b/debian/rules.d/binary-gcc-cross.mk index a39e84f..b642ba2 100644 --- a/debian/rules.d/binary-gcc-cross.mk +++ b/debian/rules.d/binary-gcc-cross.mk @@ -71,8 +71,8 @@ ifeq ($(DEB_TARGET_ARCH),m68k) files_gcc += $(gcc_lib_dir)/include/math-68881.h endif -ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64)) - files_gcc += $(gcc_lib_dir)/include/{altivec.h,ppc-asm.h} +ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64 powerpcspe)) + files_gcc += $(gcc_lib_dir)/include/{altivec.h,ppc-asm.h,spe.h} endif usr_doc_files = debian/README.Bugs diff --git a/debian/rules.d/binary-gcc.mk b/debian/rules.d/binary-gcc.mk index 55af73b..20e36ff 100644 --- a/debian/rules.d/binary-gcc.mk +++ b/debian/rules.d/binary-gcc.mk @@ -74,7 +74,7 @@ ifeq ($(DEB_HOST_ARCH),m68k) files_gcc += $(gcc_lib_dir)/include/math-68881.h endif -ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64)) +ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64 powerpcspe)) files_gcc += $(gcc_lib_dir)/include/{altivec.h,ppc-asm.h,spe.h} endif diff --git a/debian/rules.d/binary-java.mk b/debian/rules.d/binary-java.mk index 7f0249a..f2b9f94 100644 --- a/debian/rules.d/binary-java.mk +++ b/debian/rules.d/binary-java.mk @@ -236,7 +236,7 @@ ifeq ($(with_standalone_gcj),yes) files_gcj += $(gcc_lib_dir)/include/math-68881.h endif - ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64)) + ifeq ($(DEB_TARGET_ARCH),$(findstring $(DEB_TARGET_ARCH),powerpc ppc64 powerpcspe)) files_gcj += $(gcc_lib_dir)/include/{altivec.h,ppc-asm.h,spe.h} endif diff --git a/debian/rules2 b/debian/rules2 index 252c671..01bbbca 100644 --- a/debian/rules2 +++ b/debian/rules2 @@ -260,6 +260,10 @@ ifneq (,$(findstring powerpc-linux,$(DEB_TARGET_GNU_TYPE))) endif endif +ifeq ($(findstring powerpcspe,$(DEB_TARGET_ARCH)),powerpcspe) + CONFARGS += --with-cpu=8548 --enable-e500_double --with-long-double-128 +endif + ifneq (,$(findstring softfloat,$(DEB_TARGET_GNU_CPU))) CONFARGS += --with-float=soft endif -- 1.7.0 |
Bug#579780: powerpcspe: Preliminary architecture port and minor bugfix
* Kyle Moffett | 2010-04-30 13:48:32 [-0400]:
>Package: gcc-4.4 >Version: 4.4.2-9 >Severity: normal >Tags: sid patch Please use someting like: User: debian-powerpcspe@breakpoint.cc Usertags: powerpcspe So you can track all port related bugs in one go. The severity is _always_ wishlist because it is not an official architecture. I think you don't have to write the complete history each time. You could write "new port" followed by a link to wiki page which has some more informations. Sebastian -- To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 20100430181851.GA25645@Chamillionaire.breakpoint.c c">http://lists.debian.org/20100430181851.GA25645@Chamillionaire.breakpoint.c c |
Bug#579780: powerpcspe: Preliminary architecture port and minor bugfix
* Kyle Moffett | 2010-04-30 13:48:32 [-0400]:
> debian/rules.d/binary-gcc-cross.mk | 4 ++-- > debian/rules.d/binary-gcc.mk | 2 +- > debian/rules.d/binary-java.mk | 2 +- > debian/rules2 | 4 ++++ > 4 files changed, 8 insertions(+), 4 deletions(-) We need probably need the attached patch on top. The e500 core doesn't recognize lwsync, there is a workaround for this in gcc since 4.3. According to my 4.3 buildlog [0] boehm-gc is compiled and probably used. I remember gcj segfaulted without his patch, everything else was fine. [0] http://download.breakpoint.cc/debian/powerpcspe-staging/build/buildlog-gcc-4.3-4.3.2.txt Sebastian >From fb656ff1be8f1aafe3013d859100581d5e386d67 Mon Sep 17 00:00:00 2001 From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: Sat, 1 May 2010 10:30:24 +0200 Subject: [PATCH] don't use lwsync if it is not available Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- boehm-gc/include/private/gc_locks.h | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/boehm-gc/include/private/gc_locks.h b/boehm-gc/include/private/gc_locks.h index 4e2b641..52db8e3 100644 --- a/src/boehm-gc/include/private/gc_locks.h +++ b/src/boehm-gc/include/private/gc_locks.h @@ -178,7 +178,11 @@ # endif # define GC_TEST_AND_SET_DEFINED inline static void GC_clear(volatile unsigned int *addr) { +#ifdef __NO_LWSYNC__ + __asm__ __volatile__("sync" : : : "memory"); +#else __asm__ __volatile__("lwsync" : : : "memory"); +#endif *(addr) = 0; } # define GC_CLEAR_DEFINED -- 1.6.6.1 |
| All times are GMT. The time now is 12:56 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.