[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patches] Including IBM add-ons in EGLIBC?
- To: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
- Subject: Re: [patches] Including IBM add-ons in EGLIBC?
- From: Steve Papacharalambous <stevep@xxxxxxxxxxxxx>
- Date: Fri, 17 Nov 2006 11:24:08 +0000
I agree with Joseph, it is a good idea to add powerpc-cpu and DFP to
eglibc.
On Thu, 2006-11-16 at 21:17 +0000, Joseph S. Myers wrote:
> On Thu, 16 Nov 2006, Mark Mitchell wrote:
>
> > Geoff Smith at IBM asked me to forward the following note about possibly
> > functionality to include in EGLIBC.
> >
> > Perhaps the EGLIBC maintainers could comment?
>
> I think adding these to EGLIBC 2.5 and EGLIBC trunk is a good idea -
> subject to all the assignments to the FSF being in place. As Steve Munroe
> is a maintainer he can add the powerpc-cpu add-on himself.
>
> In the case of the DFP add-on, which overrides some files from core glibc,
> I would encourage patching those files in the libc/ directory directly
> instead for the EGLIBC version (conditional on appropriate feature test
> macros for the headers, and with some other condition for the files that
> get compiled into libc - for example, have SUPPORT_DECIMAL_FLOAT
> conditionals in libc/stdio-common/vfprintf.c, and have
> dfp/sysdeps/dfp/stdio-common/vfprintf.c define SUPPORT_DECIMAL_FLOAT then
> include the file from libc). These patches to core libc would need
> posting separately for review.
>
> > > Possible work -- add optimizations for Freescale's E500 cpus, extend to
> > > non-powerpc CPUs
>
> I intend to implement the basic port for E500 (v1 and v2) based on the old
> SPE add-on (available on savannah for glibc 2.3.4) and reimplement the
> parts of the add-on not assigned to the FSF - once I have GCC for E500
> back in a reliable state and have implemented 128-bit long double support.
> Because much of the port is needed to operate correctly with hardware
> floating-point on those CPUs (separate <fenv.h> and setjmp/longjmp
> implementations, for example), I think that should go in the ports
> collection (for EGLIBC and FSF GLIBC), leaving the spe add-on only for the
> extra functions defined in the SPE PIM (string-to-fixed-point
> conversions); anything that is purely an optimization could go in
> powerpc-cpu, though with a directory for the CPU in ports I'm not sure how
> much benefit there would be to separating out some files like that.
>
If there is a directory for the e500 in ports I don't see much benefit
in separating out the SPE PIM functions, on balance it would be better
to keep them together.