public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
* e500 port plans
@ 2013-09-16 23:28 Joseph S. Myers
  2013-09-24 23:01 ` Roland McGrath
  0 siblings, 1 reply; 4+ messages in thread
From: Joseph S. Myers @ 2013-09-16 23:28 UTC (permalink / raw)
  To: libc-alpha, libc-ports

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: e500 port plans
  2013-09-16 23:28 e500 port plans Joseph S. Myers
@ 2013-09-24 23:01 ` Roland McGrath
  2013-09-25 21:30   ` Joseph S. Myers
  0 siblings, 1 reply; 4+ messages in thread
From: Roland McGrath @ 2013-09-24 23:01 UTC (permalink / raw)
  To: Joseph S. Myers; +Cc: libc-alpha, libc-ports

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


Thanks,
Roland

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: e500 port plans
  2013-09-24 23:01 ` Roland McGrath
@ 2013-09-25 21:30   ` Joseph S. Myers
  2013-09-25 21:44     ` Roland McGrath
  0 siblings, 1 reply; 4+ messages in thread
From: Joseph S. Myers @ 2013-09-25 21:30 UTC (permalink / raw)
  To: Roland McGrath; +Cc: libc-alpha, libc-ports

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
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: e500 port plans
  2013-09-25 21:30   ` Joseph S. Myers
@ 2013-09-25 21:44     ` Roland McGrath
  0 siblings, 0 replies; 4+ messages in thread
From: Roland McGrath @ 2013-09-25 21:44 UTC (permalink / raw)
  To: Joseph S. Myers; +Cc: libc-alpha, libc-ports

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-09-25 21:44 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-16 23:28 e500 port plans Joseph S. Myers
2013-09-24 23:01 ` Roland McGrath
2013-09-25 21:30   ` Joseph S. Myers
2013-09-25 21:44     ` Roland McGrath

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).