Re: PowerPC E500 port

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 8 Oct 2007, Steven Munroe wrote:

> 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

I.e., it is compatible with the soft-float ABI.  It has never claimed to 
be compatible with the 6xx hard-float ABI.

> 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.

It is a compatible extension to soft-float (apart from the <fenv.h> 
constants).  There is no change to the size of jmpbuf and its contents are 
a matter of internal convention between setjmp and longjmp which will 
always come from the same libc.  The ucontext contents are defined by the 
kernel; again there is no change to the structure size (the kernel puts 
E500 register high-parts in the same area as Altivec registers).

> 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

It does not change those sizes.  Just like all the other ISA variants, 
subdirectories for a given CPU will use features of that CPU where 
appropriate.  Everything from powerpc32 soft-float directories can be 
safely inherited, only for a few special cases such as setjmp/longjmp are 
E500 versions needed.

> different (incompatable) ABI to use/expose the SPE features. Mixing

The only incompatibility is the <fenv.h> constants.  The register 
high-parts are transparent to non-SPE code which neither uses nor modifies 
them.

> 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.

E500 can't leak into non-E500 builds.  powerpc32/fpu could leak into E500 
builds, in which case the assembler will give an error for the non-E500 
instructions and the answer is to add a new dummy .c file in 
sysdeps/powerpc/powerpc32/e500/fpu that includes the generic file.

The abstractly best approach would be to recognise that Power has two 
different floating point options and move the existing fpu directories to 
classic/fpu or similar.  This is what was done when the ColdFire port was 
added to the m68k port - existing files were moved to m68020/fpu and 
ColdFire files went into coldfire/fpu.  But this would involve changes to 
core libc that would not be accepted, so overriding all files from the 
core fpu directories seemed like the next best option (and safe given the 
assembler errors for non-E500 instructions when assembling for E500).  
(If you can get such renames into core libc, then of course I'll update 
the ports patch accordingly to use the cleaner, more orthogonal structure 
of two alternative FPU implementations within the common powerpc32 
architecture.)

> Net E500 needs a separate target and ABI!

It does not have or need a separate ABI, it uses the normal soft-float 
GNU/Linux ABI with minor compatible extensions.

A proliferation of target triplets is a bad idea; the same compiler can be 
configured with E500v1, E500v2, classic hard-float, soft-float and 64-bit 
multilibs.  Feature tests are better than target triplet tests, and are 
the GNU way.  (The target powerpc-*-linux-gnuspe exists, but is only 
suggestive of a feature that might be supported, not indicative of whether 
a particular multilib uses that feature.)

> 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:

The EABI is not used for Power GNU/Linux, E500 or otherwise.  The ABI used 
is the soft-float GNU/Linux ABI.  EABI for Power is something different 
and not relevant to glibc.

> 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.

soft-fp is used for the emulation of double - nofpu is inapplicable since 
there is always hardware floating point at least for single precision on 
E500.  The use of soft-fp for emulation of double is exactly in line with 
the targets using it for IEEE quad, for example.

-- 
Joseph S. Myers
joseph@codesourcery.com