This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: IEEE128 binary float to decimal float conversion routines
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Steve Munroe <sjmunroe at us dot ibm dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, Michael R Meissner <mrmeissn at us dot ibm dot com>
- Date: Mon, 16 Nov 2015 18:40:12 +0000
- Subject: Re: IEEE128 binary float to decimal float conversion routines
- Authentication-results: sourceware.org; auth=none
- References: <564A16D5 dot 3020105 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 10 dot 1511161803500 dot 30498 at digraph dot polyomino dot org dot uk>
On Mon, 16 Nov 2015, Joseph Myers wrote:
> The BID conversions between binary and decimal float involve several MB of
> tables (whereas libgcc DPD conversions go via strings). Several MB of
I should comment a bit more on conversions via strings.
(a) Current glibc has correctly rounded conversions between binary
floating-point and strings, in both directions (older glibc did not).
(b) Thus, converting via strings is fine as an approach for a correctly
rounded conversion when converting from decimal to binary.
(c) It's not however correct for non-default rounding modes when
converting from binary to decimal, because glibc's conversions from binary
floating-point to decimal strings use the binary rounding mode, in
accordance with IEEE 754, but for a conversion from binary floating-point
to decimal floating-point the correct rounding mode to use is the decimal
rounding mode, again as per IEEE 754. (If the libgcc code doesn't try to
handle non-default rounding modes, that may not matter for libgcc,
however.)
(d) Conversions via strings also aren't a good approach at present for the
present case where the binary type is __float128, because the conversions
between __float128 and strings aren't in glibc (that would be part of the
large and complicated project of supporting TS 18661-3 functions for
__float128, which in this case also involves a dependency on part of TS
18661-1 to support strfrom*). This is why such conversions aren't just an
easy matter of "build libgcc functions for KFmode like they're built for
other binary floating-point modes".
--
Joseph S. Myers
joseph@codesourcery.com