Re: [patches] Including IBM add-ons in EGLIBC?

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

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.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx