Re: PowerPC E500 port

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC E500 port

Steven Munroe
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.
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC E500 port

Daniel Jacobowitz-2
On Mon, Oct 08, 2007 at 06:23:55PM -0500, Steven Munroe wrote:
> 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.

I don't understand.  Why shouldn't e500 be a subdirectory of
powerpc32?  It's a sibling of the soft FP version of powerpc32, with
which it is almost ABI compatible.  Anything under powerpc32 that
requires hard FP should be in powerpc32/fpu.

> 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

The target triplet powerpc-unknown-linux-gnuspe has been in use for a
couple of years.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC E500 port

Joseph Myers
In reply to this post by Steven Munroe
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC E500 port

Roland McGrath
The glibc norm is that host triplet and --with-fp setting are what specify
the ABI the glibc build will support.  The --with-cpu setting affects what
hardware the glibc being built can run on, but it may not affect the ABI.
The powerpc32 soft-float ABI is indicated by powerpc-*-linux --without-fp.
If powerpc-*-linux --with-cpu=e500 will produce that ABI, it must be
synonymous with powerpc-*-linux --without-fp --with-cpu=e500.  

The sysdeps/ subdirectory layout is an internal implementation matter.
It's nice when the names are intuitive off the cuff, but that's not really
what they're there for.  The configure machinery drives it in a certain
way, and given that algorithm we organize things as works best to share code.

To avoid accidental misconfigurations, sysdeps/powerpc/preconfigure should do:

        test "x$with_cpu" = xe500 && with_fp=no

This means configure will check sysdeps/powerpc/powerpc32/e500 and
sysdeps/powerpc/powerpc32/e500/nofpu.  It doesn't matter whether you have
an FPU, that's just what the directory is going to be called for this
combination of configuration options.  If all E500s have always had FPU
hardware, then you can add sysdeps/powerpc/powerpc32/e500/Implies with:

        powerpc/powerpc32/e500/fpu
        powerpc/fpu

or whatever is appropriate.

Your use of soft-fp seems fine to me as far as organization.  Does that
interact correctly with sysdwps/powerpc/soft-fp/?


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC E500 port

Joseph Myers
On Mon, 8 Oct 2007, Roland McGrath wrote:

> The glibc norm is that host triplet and --with-fp setting are what specify
> the ABI the glibc build will support.  The --with-cpu setting affects what

My understanding was that the ABI was effectively determined by the
compiler being used, where hard and soft-float have incompatible ABIs (as
on Power and MIPS) - if the glibc configuration disagrees (in particular
if glibc is configured for hard float but the compiler is using the
soft-float ABI) you'll get a broken glibc (or if lucky an assembler
error).

Determination from the compiler is explicit for mips64*, where the
compiler options are examined in preconfigure to determine the particular
ABI (and different host triplets for the different ABIs simply aren't
used).  Likewise for m68k where the compiler behavior is examined to
distinguish ColdFire (which has a different ABI as well as being an
instruction set variant) from m680x0; again there is no separate host
triplet.  (Core libc probably has fewer such cases of multiple
incompatible ABI and CPU variants.)

> hardware the glibc being built can run on, but it may not affect the ABI.
> The powerpc32 soft-float ABI is indicated by powerpc-*-linux --without-fp.
> If powerpc-*-linux --with-cpu=e500 will produce that ABI, it must be
> synonymous with powerpc-*-linux --without-fp --with-cpu=e500.  

I should note that while --with-cpu for glibc implies passing a -mcpu
option to GCC, there is no such GCC option as -mcpu=e500 - the options are
-mcpu=8540 and -mcpu=8548.  But while 8540 is E500v1 and 8548 is E500v2,
those options are synonymous - the actual E500v2 features are enabled with
-mfloat-gprs=double (or by configuring GCC appropriately - a
configure-time option not a different target triplet - to default that
way).

Now the host triplet used when configuring glibc need bear no resemblence
to the target triplet used when configuring GCC - just as it's possible to
build an i686-pc-linux-gnu glibc with x86_64-pc-linux-gnu-gcc -m32, a
powerpc-none-linux-gnuspe glibc could be built with a compiler using
another target triplet and appropriate options to select an E500 CPU and
ABI.  So perhaps configuring based on powerpc*-linux*spe as the configured
host triplet would be the simplest approach after all (and avoid questions
of whether the ABI with different <fenv.h> constants is or is not
different from the soft-float ABI), with compiler test or --with-cpu only
to distinguish E500v1 and E500v2?  Because of the lack of -mcpu=e500, the
"e500" sysdeps directories could not be accidentally selected by a
--with-cpu option.

> Your use of soft-fp seems fine to me as far as organization.  Does that
> interact correctly with sysdwps/powerpc/soft-fp/?

With the one in ports or the one in libc, or both?

With the one in ports (overriding its sfp-machine.h), yes I think so.

With the one in libc, there's a serious question of what's "correct".  
Recall that one does

feq ($(subdir),soft-fp)
ifeq ($(sizeof-long-double),16)
powerpc-quad-routines := q_add q_cmp q_cmpe q_div q_dtoq q_feq q_fge    \
        q_fgt q_fle q_flt q_fne q_itoq q_mul q_neg q_qtod q_qtoi        \
        q_qtos q_qtou q_qtoull q_qtoll q_sqrt q_stoq q_sub q_utoq       \
        q_ulltoq q_lltoq q_util
sysdep_routines += $(powerpc-quad-routines)
endif
endif

and those functions are declared with GLIBC_2.2 version.  Now:

* glibc 2.2 would not have generally been built with compilers with
128-bit long double, so the function wouldn't really have been in the 2.2
ABI, so that version seems wrong.

* q_utoq.c actually defines a function called _q_uitoq instead of the
function _q_utoq in the Versions file.

* If those functions do get built then they still wouldn't meet the 1995
SysV ABI they are meant to meet: they are meant to be functions for IEEE
long double, which has a different argument-passing ABI from IBM long
double which current compilers use (and they aren't built with
-mabi=ieeelongdouble, if that even works on GNU/Linux).

* I believe those quad functions (though in libc not ports) only ever get
built in the soft-float case; the sysdeps/powerpc/soft-fp directory
doesn't get used in hard-float builds (it's not in any relevant Implies
file).  That 1995 ABI is purely a hard-float ABI.

So the _q_* functions are not part of the soft-float ABI for which they
are built, and are not built compatibly with the ABI they are part of, nor
would they have been built in the glibc version corresponding to their
symbol versions because of lack of 128-bit long double support.  The
current project to document the de facto 32-bit GNU/Linux Power ABIs would
be unlikely to document these functions that form no useful part of the
current ABIs.  Frankly I think they are best removed from glibc as no
program could ever have used them successfully in the form they presently
exist.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC E500 port

Steven Munroe
In reply to this post by Daniel Jacobowitz-2
Daniel Jacobowitz wrote:

> On Mon, Oct 08, 2007 at 06:23:55PM -0500, Steven Munroe wrote:
>  
>> 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.
>>    
>
> I don't understand.  Why shouldn't e500 be a subdirectory of
> powerpc32?  It's a sibling of the soft FP version of powerpc32, with
> which it is almost ABI compatible.  Anything under powerpc32 that
> requires hard FP should be in powerpc32/fpu.
>
>  
"almost ABI compatible" is not the same as compatible.

Compatible means that given ISA version minimums, the code as build will
run. This is not exactly true for E500 if any of the SPE specific
instructions are used. Two key differences are VMX vs SPE (mutually
exclusive in the ISA V2.04) and the differences in fenv.h. At minimum
the SPE specific instructions should be guarded with AT_HWCAP tests
(which the current proposed patch does not) as are used for VMX
instructions in setjmp/__longjump and *context.

Currently everything in ./powerpc/powerpc32 is compatible (across all
ISA V1.0 PowerPC) for the base (configured without --with-cpu) or upward
compatible (when configured with --with-cpu, power4 - V2.01 code will
run on a power6). As Roland's note suggests, --with-cpu should not
change the ABI.

Also as the as Roland states the ABI this patch is trying to be
compatible with is --target=powerpc32-linux --without-fp. This implies
powerpc32/nofpu and not ./powerpc32/.../fpu.


>> 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
>>    
>
> The target triplet powerpc-unknown-linux-gnuspe has been in use for a
> couple of years.
>
>  
Then use that to identify this ABI variant. Thoe this triplet looks like
a quadruplet ...

Reply | Threaded
Open this post in threaded view
|

Re: PowerPC E500 port

Joseph Myers
On Tue, 9 Oct 2007, Steven Munroe wrote:

> run on a power6). As Roland's note suggests, --with-cpu should not
> change the ABI.

--with-cpu wasn't my suggestion.  I was proposing that preconfigure
*detect* the ABI - which is what the compiler specified to configure uses
and can't be further changed by how glibc is configured with other
configure options - and follow the ABI the compiler is using.  If you want
the E500 ABI details, configure with a compiler using them; if you don't,
configure with a non-E500 compiler.  Just like trying to build a
soft-float glibc with a hard-float compiler or vice versa, things will
only go wrong if glibc is configured inconsistently with the compiler.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: PowerPC E500 port

Steven Munroe
In reply to this post by Joseph Myers
Joseph S. Myers wrote:

> On Mon, 8 Oct 2007, Roland McGrath wrote:
>
>  
>> The glibc norm is that host triplet and --with-fp setting are what specify
>> the ABI the glibc build will support.  The --with-cpu setting affects what
>>    
>
> My understanding was that the ABI was effectively determined by the
> compiler being used, where hard and soft-float have incompatible ABIs (as
> on Power and MIPS) - if the glibc configuration disagrees (in particular
> if glibc is configured for hard float but the compiler is using the
> soft-float ABI) you'll get a broken glibc (or if lucky an assembler
> error).
>
>  
Not exactly. The ABI is the combined effort of the compiler (register
usage, parm passing, frame stacking, ...) the kernel (environment, aux
vector, ucontext, ...) and the runtime (ld.so, setjmp/__longjmp,
*context, dl-trampolien.S, ...)

We get a lot of notes/IRC traffic about broken PPC glibc builds. I would
prefer reducing the the posibility of new failure modes.

> Determination from the compiler is explicit for mips64*, where the
> compiler options are examined in preconfigure to determine the particular
> ABI (and different host triplets for the different ABIs simply aren't
> used).  Likewise for m68k where the compiler behavior is examined to
> distinguish ColdFire (which has a different ABI as well as being an
> instruction set variant) from m680x0; again there is no separate host
> triplet.  (Core libc probably has fewer such cases of multiple
> incompatible ABI and CPU variants.)
>
>  
>> hardware the glibc being built can run on, but it may not affect the ABI.
>> The powerpc32 soft-float ABI is indicated by powerpc-*-linux --without-fp.
>> If powerpc-*-linux --with-cpu=e500 will produce that ABI, it must be
>> synonymous with powerpc-*-linux --without-fp --with-cpu=e500.  
>>    
>
> I should note that while --with-cpu for glibc implies passing a -mcpu
> option to GCC, there is no such GCC option as -mcpu=e500 - the options are
> -mcpu=8540 and -mcpu=8548.  But while 8540 is E500v1 and 8548 is E500v2,
> those options are synonymous - the actual E500v2 features are enabled with
> -mfloat-gprs=double (or by configuring GCC appropriately - a
> configure-time option not a different target triplet - to default that
> way).
>
>  
So :

    --target=powerpc-*-linux-gnuspe
    --without-fp

and optionally:

    --with-cpu=[8540|8548]

If e500 is never a valid -mcpu= target, then powerpc/powerpc32/e500 is
less objectionable, but I still think powerpc/e500/ is clearer. So

    $machine=powerpc/powerpc32/e500

And the none FPU code would live in

    ./sysdeps/powerpc/powerpc32/e500

and soft-fp API code in

    ./sysdeps/powerpc/powerpc32/e500/nofpu

if there is any ./sysdeps/powerpc/powerpc32/e500/fpu directories then
they can only be reached via Implies within a  ./e500/nofpu directory.
Any SPE fpu code in this directories should be guarded with AT_HWCAP
checks (PPC_FEATURE_HAS_EFP_SINGLE & PPC_FEATURE_HAS_EFP_DOUBLE) at runtime.

otherwise: -with-cpu=[8540|8548] can be used to add CPU-TYPE specific
SPE-single/double optimizations from directories:

    ./sysdeps/powerpc/powerpc32/e500/[8540/8548]/nofpu

./e500/8548/nofpu would contain Implies back to ./e500/8540/nofpu so it
can share SPE-single code with 8540, but provide hardware implemented
overides for SPE-double. Code in these directores don't need AT_HWCAP
guards because the configuration is specifically targeting those chips.

This is similar  to how the
--with-cpu=[power4|970|power5|power5+|power6|power6x] source is arranged.

> Now the host triplet used when configuring glibc need bear no resemblence
> to the target triplet used when configuring GCC - just as it's possible to
> build an i686-pc-linux-gnu glibc with x86_64-pc-linux-gnu-gcc -m32, a
> powerpc-none-linux-gnuspe glibc could be built with a compiler using
> another target triplet and appropriate options to select an E500 CPU and
> ABI.  So perhaps configuring based on powerpc*-linux*spe as the configured
> host triplet would be the simplest approach after all (and avoid questions
> of whether the ABI with different <fenv.h> constants is or is not
> different from the soft-float ABI), with compiler test or --with-cpu only
> to distinguish E500v1 and E500v2?  Because of the lack of -mcpu=e500, the
> "e500" sysdeps directories could not be accidentally selected by a
> --with-cpu option.
>
>  
>> Your use of soft-fp seems fine to me as far as organization.  Does that
>> interact correctly with sysdwps/powerpc/soft-fp/?
>>    
>
> With the one in ports or the one in libc, or both?
>
> With the one in ports (overriding its sfp-machine.h), yes I think so.
>
> With the one in libc, there's a serious question of what's "correct".  
> Recall that one does
>
> feq ($(subdir),soft-fp)
> ifeq ($(sizeof-long-double),16)
> powerpc-quad-routines := q_add q_cmp q_cmpe q_div q_dtoq q_feq q_fge    \
>         q_fgt q_fle q_flt q_fne q_itoq q_mul q_neg q_qtod q_qtoi        \
>         q_qtos q_qtou q_qtoull q_qtoll q_sqrt q_stoq q_sub q_utoq       \
>         q_ulltoq q_lltoq q_util
> sysdep_routines += $(powerpc-quad-routines)
> endif
> endif
>
> and those functions are declared with GLIBC_2.2 version.  Now:
>
>  
I agree we should remove that as not used.