From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30101 invoked from network); 19 Aug 2022 03:19:53 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Aug 2022 03:19:53 -0000 Received: (qmail 9897 invoked by uid 550); 19 Aug 2022 03:19:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9837 invoked from network); 19 Aug 2022 03:19:49 -0000 Date: Thu, 18 Aug 2022 23:19:35 -0400 From: Rich Felker To: ardi Cc: musl@lists.openwall.com Message-ID: <20220819031934.GH7074@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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