This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: PowerPC E500 hardware floating point support in libc
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Alex Dubov <oakad at yahoo dot com>
- Cc: libc-ports at sourceware dot org
- Date: Thu, 26 Jun 2008 11:34:15 +0000 (UTC)
- Subject: Re: PowerPC E500 hardware floating point support in libc
- References: <531233.68342.qm@web36706.mail.mud.yahoo.com>
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