Re: [patches] DFP for EGLIBC

["Ryan S. Arnold" <rsa@xxxxxxxxxx>]

On Wed, 2007-10-31 at 17:51 -0700, H.J. Lu wrote:
> > > 2. Include the full libbid in libgcc. We will make libgcc much bigger
> > > and we have to deal with ABI issue for libgcc_s.so.
> > > 3. Build/install libbid.a and libbid_pic.a for gcc. eglibc can
> > > just use them in the build.
> > 
> > This is an interesting suggestion, but I'm not enthusiastic about
> > having the two DFP representations use different approaches for EGLIBC
> > integration.  I'd like to have the two implementations be as parallel
> > as possible.
> 
> It can be done for libdecNumber also.

H.J., Jim, et al.

Here's my vision...

Libdfp has already laid out the GLIBC sysdeps framework for accessing
the C-Spec Technical-Report mandated functions for the DFP extension
including the ieee754r emulation layer which mandates exception support
(which btw, doesn't existing in libgcc).

Currently the GLIBC framework makes compile-time decisions to satisfy
the Libdfp back-end decimal computation needs via the following methods:

1. In the 'generic' case requests for decimal computation are satisfied
by the decNumber library via the libdecnumber.so shared object.

2. Requirements for decimal computation are satisfied with calls to
PowerPC assembler functions that make use of the POWER6 decimal floating
point instruction set if available via powerpc-cpu overrides.

3. Some functions operate directly upon the DPD encoded _Decimal[32|64|
128] types in special situations via generic implementation overrides in
libc/dfp/sysdeps/powerpc.

To leverage what has already been done I envision that libbid can add a
fourth and fifth option:

4. Calls for decimal computation are satisfied by the libbid library via
the libbid.so shared object.

5. Directly operate upon the BID encoded _Decimal[32|64|128] types in
special situations via generic implementation overrides in
libc/dfp/sysdeps/i386 (et al).

What will need to happen for this to take place?

1. Currently the 'generic' implementation uses decNumber as the backend.
We should identify where libdfp makes decNumber calls directly and
identify methods to abstract these calls into compile time decisions to
use decNumber or libbid provided solutions without introducing
unnecessary indirection overhead.

2. Introduce the libc/dfp/sysdeps/i386 (et al) directories.

3. Provide generic function overrides that operate directly on BID
encoded _Decimal[32|64|128] types in libc/dfp/sysdeps/i386 (et al).  An
example is decimal types decoding for printf support.

4. Push the generation of libdecnumber.so and libbid.so into sysdeps
Makefiles dependent on arch.

As part of 1. above we already intend to provide more C function
implementations of the C-spec functions rather than relying on decNumber
directly.  This will push more determination of back-end usage onto
libgcc and allow more architecture specific leverage.

Regards,
Ryan S. Arnold
IBM Linux Technology Center
Linux Toolchain Development