This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PowerPC E500 hardware floating point support in libc


On Wed, 25 Jun 2008, Alex Dubov wrote:

> I'm interested in having a hardware floating point working on 8548. I see,
> there was a discussion couple of months back, but no consensus was reached,
> as far as I can tell.
> 
> Basically, I want to implement the missing bits in libc (if there are 
> any), but I would like to do it in a way that'll be acceptable for 
> inclusion into the main tree.
> 
> I would also like to ask: what is the status of the already proposed 
> patches? Are they usable for real projects or additional work is 
> required?

First, if you wish to implement any patches, you should first make sure 
you have a copyright assignment and any employer disclaimer needed on file 
with the FSF before doing any work.

The patch as posted last September and discussed last October should still 
work fine, *except* that core libc now has a file 
sysdeps/unix/sysv/linux/powerpc/bits/mathinline.h that would need an extra 
__NO_FPRS__ check similar to those in the libc part of my previous patch 
submission.  You can find the relevant patch

2008-04-12  Joseph Myers  <joseph@codesourcery.com>

        * sysdeps/unix/sysv/linux/powerpc/bits/mathinline.h: Also test
        __NO_FPRS__.

in EGLIBC.  As the port is available to E500 users and subject to ongoing 
automatic testing in EGLIBC, the FSF GLIBC submission is a low priority 
for me.  The port has been working fine for over a year.

Roland's proposal to use nofpu directories would avoid all the files that 
include core files in order to override fpu files in core libc.  However, 
there would be other problematic consequences.  For example, this would 
bring in sysdeps/powerpc/nofpu/Makefile, some of whose effects (building 
in some of the soft-fp code, in particular) are inappropriate for E500, 
and would need to be reversed in some way.  It would be necessary to 
ensure that E500 versions of all relevant files are used in place of nofpu 
versions.  Some of the effects of the fpu/ makefiles in core libc are 
appropriate for E500 and would need to be replicated.  Ensuring, in the 
course of making this change, that all relevant definitions are unchanged 
so that the correct set of files continue to be built into libc and libm 
would be quite fiddly (but certainly feasible).

Configuring based on the host triplet powerpc*linux*spe would avoid the 
fragility seen with the configure code in my patch in practice, though 
you'd need to work out how to select the E500v2 code (possibly with 
--with-cpu=8548).  I'd recommend copious sanity checks that when this 
triplet is used it really is an E500 compiler, and that when not used the 
compiler configuration for whether FPRs are in use agrees with the libc 
configuration for floating point.

(I continue to believe that in principle the way MIPS autodetects the ABI, 
or m68k detects ColdFire, is better than having an accumulation of target 
triplets, and that the powerpc-linux-gnuspe triplet was a mistake in the 
first place; and that in principle the handling of fpu directories done 
when ColdFire support was added would be the right way to handle Power, 
although not feasible within present FSF glibc policy on separation into 
libc and ports.)

There is no need for any HWCAP checks such as Steve Munroe suggests; the 
port and powerpc*linux*spe name are only for processors with E500 floating 
point (single or double).

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]