e500 port plans

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

e500 port plans

Joseph Myers
I intend to contribute support for the e500 variant of Power Architecture
processors to glibc.  A previous version of this was posted in 2007
<https://sourceware.org/ml/libc-ports/2007-02/msg00002.html>
<https://sourceware.org/ml/libc-ports/2007-04/msg00007.html>
<https://sourceware.org/ml/libc-ports/2007-09/msg00013.html>.  I intend to
do various things differently from that version of the port:

* This time I intend the ABI to be exactly that of the existing soft-float
Power glibc port, rather than the previous state of two ABI variants for
e500v1 and e500v2, slightly different from each other and from soft-float.  
See <http://www.eglibc.org/archives/patches/msg01291.html> for details of
the exact differences from the previous e500 port.  Thus, this will
effectively be an optimized variant of the soft-float port.

* As a consequence, the port will not include the SPE PIM string to
fixed-point symbols atosfix16 atosfix32 atosfix64 atoufix16 atoufix32
atoufix64 strtosfix16 strtosfix32 strtosfix64 strtoufix16 strtoufix32
strtoufix64.  They could go in a separate library, maybe built as a glibc
add-on (as they did in Aldy's original SPE add-on); they do use the GMP
code in libc the same way as strtod does, so would either need to use
those objects from the glibc build, or would need glibc to export those
symbols at GLIBC_PRIVATE (which could be of use anyway in libm, given the
GMP code is generally faster than the existing multiple-precision code in
libm).  But I suspect those functions were never really being used anyway.

* Where it seems most appropriate, conditionals in common powerpc sysdeps
files will be used instead of artificially separating things to keep as
much as possible in ports.  (Where new files in new sysdeps directories
seem to make the most sense, those will still go in ports while the
existing soft-float port is there.)

* Patches will be submitted incrementally when ready rather than one big
submission of everything.  (Some patches adding or adjusting conditionals
in installed headers went in some time ago.)

Note that the Power Architecture documents include a lot more possible
variations than I actually intend to cover in this port, and GCC's
command-line options in principle provide their own set of variations.  In
particular:

* The Power Architecture defines both SPE and three separate embedded
floating-point categories, Embedded vector single-precision floating-point
[SP.FV], Embedded scalar single-precision floating-point [SP.FS] and
Embedded scalar double-precision floating-point [SP.FD], each of which
requires SPE but is independent of the other.  The presumption of the port
is that SP.FS is present, possibly together with SP.FD.  The case of SP.FD
without SP.FS is not considered (and not supported by GCC).  If neither is
supported, all that's relevant is the register high parts that can be used
by SPE instructions; I expect that case would work (through appropriate
conditionals in functions such as setjmp/longjmp along the lines of
defined __SPE__ || (defined __NO_FPRS__ && !defined _SOFT_FLOAT)), though
it isn't tested.

* The combination of e500 features with classic floating-point is not
considered (and not supported by GCC).  The combination with classic
64-bit is not considered (and not supported by GCC).  Both of those are in
principle supported by the Power Architecture (there are even some
instructions that are only defined for the combination, to convert between
floating-point and 64-bit integers), though I'm not aware of any
implementations.

* I don't really expect the combination of e500 features with
little-endian to work in either glibc or GCC (although again it's defined
in the architecture).

* Various instruction patterns in GCC require that non-e500 instructions
only affect the low 32 bits of registers and not the high parts, and it's
quite likely some code in glibc may end up implicitly requiring the same;
this accords with e500 documentation, but the Power Architecture documents
leave the high parts undefined after such instructions.

In principle, some things such as setjmp/longjmp support for register high
parts could be runtime-conditional based on HWCAP bits, but I don't think
that's particularly useful for the users of these processors and don't
plan to implement it.

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

Re: e500 port plans

Roland McGrath-4
I think it makes sense to migrate all the powerpc bits out of ports/
before integrating this work.


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

Re: e500 port plans

Joseph Myers
On Tue, 24 Sep 2013, Roland McGrath wrote:

> I think it makes sense to migrate all the powerpc bits out of ports/
> before integrating this work.

The two changes (e500 port, and moving powerpc bits out of ports/) seem
completely independent to me.

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

Re: e500 port plans

Roland McGrath-4
> The two changes (e500 port, and moving powerpc bits out of ports/) seem
> completely independent to me.

They are.  But we need to get the ball rolling on migrating things out of
ports somehow, and adding more things into ports/ does not help.  Migrating
the powerpc bits out of ports/ seems far simpler than the other cases there
(because it's not the whole port that is in ports/, but just a few pieces).
I suspect it's not much more than just actually moving the files.