[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patches] DFP for EGLIBC
- To: "H.J. Lu" <hjl@xxxxxxxxx>
- Subject: Re: [patches] DFP for EGLIBC
- From: Jim Blandy <jimb@xxxxxxxxxxxxxxxx>
- Date: Wed, 31 Oct 2007 17:23:11 -0700
"H.J. Lu" <hjl at lucon.org> writes:
> On Tue, Oct 30, 2007 at 10:31:14AM -0700, Jim Blandy wrote:
>>
>> Hi, Peter and Ryan! How is the decimal floating point work coming
>> along? Do you have a timeline for the submission process at this
>> point?
>
> Speaking of DFP, I am investigating DFP functions optimized for
> BID. libbid in gcc includes a complete set of DFP functions optimized
> for BID. But only those functions used by gcc intrinsics are compiled
> in gcc. I'd like to use the full libbid in eglibc. We have 3 choices:
>
> 1. Include libbid source in eglibc. We will run into license issue,
> LPGL vs. GPL, as well as duplicated source trees.
Is there any chance libbid could be re-licensed as we recommended for
libdfp?
http://www.eglibc.org/archives/patches/msg00338.html
It seems to me that duplicated source trees are less than ideal, but
if we designate one copy to be the master it doesn't seem like a
deal-breaker. What has your experience been with similar
arrangements, like the one between gcc/config/soft-fp and
eglibc/soft-fp?
> 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.