[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220819031934.GH7074@brightrain.aerifal.cx>
Date: Thu, 18 Aug 2022 23:19:35 -0400
From: Rich Felker <dalias@...c.org>
To: ardi <ardillasdelmonte@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Do you recommend using fmt_fp() and
On Thu, Aug 18, 2022 at 05:51:26PM +0200, ardi wrote:
> Hi,
>
> I'm looking for a small and robust dtoa-like implementation for quad
> floats (IEEE binary128). The need is because I'm using John Hauser's
> SoftFloat for IEEE binary128 computing, but I have no easy means for
> converting such floats from/to strings (I can use the host
> printf/strtold for 80bit extended long doubles, but I'm missing some
> significant digits by doing that, and besides, if I ever build in a
> host that considers long doubles as regular doubles, I'd lose even
> more digits).
>
> I've been considering gdtoa for some days, taking into account its
> pros and cons, but I don't like its code size, its dependency on the
> FPU flavour behaviour, and that it requires mutexes if it's used in
> parallel.
>
> So, I was looking at how musl does this. It appears to be in the
> fmt_fp() function in vfprintf.c and in floatscan.c
>
> It looks like I can modify these functions and force them to use the
> binary128 type as provided by SoftFloat, instead of using long double.
>
> But it can require quite a bit of surgery, so, before I get my hands
> busy in it, I have to ask the question: Would you use this
> implementation for my needs if you were me?
>
> Did you adapt fmt_fp() and floatscan from older code? Was that code
> ready for 128bit floats?
>
> Or maybe you can recommend another dtoa-like code for 128bit floats?
I think the fmt_fp code is a very good choice for this. It's basically
the minimal, dependency-free, most straightforward way of doing
exact/correctly-rounded binary floating point to decimal conversion,
and it doess not depend in any way on the format of the long double
type, just knowing the parameters (MANT_DIG, MAX_EXP), and being able
to do a very minimal amount of math on the floating point type to
extract the mantissa and to determine rounding behavior to match the
floating point type's.
If you don't have the equivalent of frexpl you can even do that part
with portable arithmetic on the floating point type. At one point long
ago I think I even had a version of the code that did that, but it
doesn't seem to have ever been in musl proper. It probably predated
musl.
The same should apply to the floatscan.c code if you need the other
direction conversion too. It's just a direct dependency-free version
of the minimal bignum logic needed to do it.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
