Re: PowerPC E500 port

[Steven Munroe <munroesj at us dot ibm dot com>]

Joseph writes

> This is the latest revision of the PowerPC E500 port for FSF glibc ports 
> HEAD, the previous one having been 
> <http://sourceware.org/ml/libc-ports/2007-04/msg00007.html>.  The 
> ChangeLog entries have been expanded as requested, and there's a fix from 
> Daniel to some of the exceptions code.  Steve, you previously said 
> <http://sourceware.org/ml/libc-ports/2007-05/msg00044.html> you'd look at 
> this port.
>
> I tried using preconfigure.in as suggested, but preconfigure is used too 
> early in configure for this to work cleanly (in particular, AC_EGREP_CPP 
> can't be used in preconfigure).  So this patch continues to use the same 
> approach to preconfigure as before - this is the established practice for 
> compiler tests in preconfigure files, as in sysdeps/m68k/preconfigure 
> which does essentially what this patch does to identify the CPU variant.


This is an important question because the E500 variant is not compatible
with the powerpc32 ABI except as powerpc32 soft-float ABI subset (FPRs
don't exist and float/double are passed/returned in GRP(pairs)). Adding
the SPE functionality is mutually exclusive with PowerPC features like
Altivec and change the size of ABI visable features like jumbuf and
ucontext (all break the ABI). E500 is not just another micro-arch or
minor ISA varient like ppc970/power4/power5/power6.

The path sysdeps/powerpc/powerpc32/e500/ is only appropriate if the
intent was to CPU-tune the powerpc32 soft-fp ABI for e500 chips (i.e.
not using the SPE features and not changing the size of
jmpbuf/ucontext). Otherwise it is inapropriate as it requires a
different (incompatable) ABI to use/expose the SPE features. Mixing
these together seems error prone with code from powerpc32/fpu leaking to
e500 builds or e500 code leaking into powerpc32 builds with random build
breakage.

Net E500 needs a separate target and ABI!

So what is the ABI name covering E500 SPE variant and how should this
name be used in the autoconf and libc. In practice (powerpc|powerpc32)
./powerpc/powerpc32 and (powerpc64) ./powerpc/powerpc64  represent
existing the 2 Linux ELF ABIs (32-and 64-bit). As in:

--target=powerpc32-linux
--with-cpu=power6

This is well established.

To me e500 needs a separate target to exploit its ISA. This can be
associated with the eabi or as its own target. As in:

--target=ppceabi-linux
-with-cpu=e500

This would imply ./sysdeps/powerpc/ppceabi/e500. Or

--target=ppce500-linux

would imply ./sysdeps/powerpc/ppce500/... which is cleaner and less
error prone. If Aldy wants to (and can safely) use powerpc32 code, then
just #include it from e500 specific directories.

Also I think the usage of  ./e500/soft-fp is incorrect for the function
contained. soft-fp is reserved for FP emulation itself, the soft -fp
variant of the POSIX API should be in ./e500/nofpu.