[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patches] A few questions on contributing to eglibc
- To: Steven Munroe <munroesj@xxxxxxxxxx>
- Subject: Re: [patches] A few questions on contributing to eglibc
- From: "H.J. Lu" <hjl@xxxxxxxxx>
- Date: Tue, 28 Aug 2007 06:24:36 -0700
On Tue, Aug 28, 2007 at 08:38:11AM -0500, Steven Munroe wrote:
> >
> > Intel BID library will provide a complete set of optimized DFP
> > functions as specified in DFP TR. I only enabled the part of Intel
> > BID library in gcc to support DFP intrinsics. I don't think
> > we need to put another copy of Intel BID library in eglibc for
> > those DFP functions.
> >
> >
> This sounds like you only have the lowest (IEEE754R) layer. This layer
> has to shared between gcc and eglibc but has to meet slightly different
> requirements in each. For example the gcc runtime disables all IEEE
> exceptions, while the eglibc rumtime need to implement the IEEE754R
> exception and integrate them with the libc fenv.h functions.
>
Gcc runtime disables exceptions by default. User can enable them
via fenv.h functions. There are even gcc tests for them. But they
use non-standard functions and they should be updated for libc
with DFP support.
> > DFP functions in Intel BID library take/return unsigned integers
> > instead of DFP types. A wrapper function is still needed in eglibc.
> > I am thinking to build/install libbid_shared.a and libbid_nonshared.a
> > in gcc. The main usage of them is to build libm.so and libm.a in
> > eglibc. Building libm.so can be done with --whole-archive -lbid_shared.
> > It will be tricky to include libbid_nonshared.a in libm.a. Maybe
> > we can use "ld -r -o bid.o --whole-archive -lbid_nonshared" to
> > generate bid.o.
> >
> >
> There is is lots of function and infrastructure that can and should be
> shared. Most of this TR can be implemented in a DPD/BID neutral way and
> can be shared. But this requires a common source tree and naming
> structure. What you propose is incompatible with the existing DPD
> support and only complicate life for EGLIBC.
Glibc supports generic implementation with optimization. We can have
sysdeps/dfp/generic
sysdeps/dfp/bid
sysdeps/dfp/dpd
DFP functions written in _DecimalXXX can be put in
sysdeps/dfp/generic
and each file should only implement one function. The optimized and
encoding specific ones can be put in
sysdeps/dfp/bid
sysdeps/dfp/dpd
H.J.