This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
e500 port plans
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>, <libc-ports at sourceware dot org>
- Date: Mon, 16 Sep 2013 23:28:26 +0000
- Subject: e500 port plans
- Authentication-results: sourceware.org; auth=none
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
joseph@codesourcery.com