[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171206173316.GV1627@brightrain.aerifal.cx>
Date: Wed, 6 Dec 2017 12:33:16 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Feasability of patching libm with OS X 10.5.8 libc for
IBM double-double in PPC
On Wed, Dec 06, 2017 at 06:23:33PM +0100, ardi wrote:
> Hi!!
>
> Disclaimer: I've read previous threads about long double support in
> musl, as well as web pages and I understand that musl won't support
> the IBM double-double, by design choice. I respect that decision (I've
> just started to use musl and I can only say I admire the quality and
> the design), and I'm not writing this as my opinion about that
> decision.
>
> Said this, I need IBM double-double in PowerPC targets (using clang as
> compiler), and I'd like to use musl because of its well written code.
>
> I'd also have the option of using the libc from OS X 10.5.8, which,
> AFAIK, is the latest libc from Apple with full support for PPC and
> PPC64 before they dropped them. This is libc 498.1.7 from the Apple
> open source site.
>
> However, building Darwin components was never easy (build instructions
> are most of the times missing, ask the PureDarwin people), so I
> *believe* I can get this libc working, but who knows...
>
> As a (perhaps) better solution, I thought that maybe I don't need to
> patch too many musl source files in order to get double-double
> working. If I'm understanding the situation correctly, the
> double-double implementation is actually generated by clang at compile
> code. The libc library should only need to provide the interface
> definitions (the definitions for mantissa bits, exponent bits, max
> values, etc...), and perhaps the implementation of some functions
> whose code wouldn't be generated by the compiler (not sure of this, as
> clang generates code for a set of functions through builtins in
> compiler_rt).
>
> Maybe there would be some issues with converting floating point to
> char string, but it would depend on what code you'd use for that
> conversion.
The musl code for printing and parsing floating point numbers depends
on long double having IEEE semantics. It's a complete toss-up whether
it will work with formats like double-double that don't give IEEE
semantics. Aside from guaranteeing reasonable semantics that you can
reason about to programs using musl, this internal dependency is a
major reason why musl does not support weird long double formats.
> So, as a personal patch (not pushing for official support, as I said
> above), do you consider it would be feasible to patch the necessary
> musl source files with contents from the OS X 10.5.8 libc?
I don't think this solves the main problem (the dependency above) at
all; at best it just gives you math.h long-double functions that work
on double-double.
You could obviously modify vfprintf.c and __floatscan.c to work with
double instead of long double, avoiding the double-double issue, but
then %Lf and strtold functionality would not work.
It's possible that you get "lucky" and they happen to work (or work
well enough for you) with double-double as-is, but I would be really
skeptical of relying on that in situations where it matters.
> Do you believe it would be a matter of a reasonably small set of
> files, or rather an overwhelming task?
>
> And... do you know of any confidence test I could run for checking
> that it's working as expected?
The libc-test math tests and printf/scanf type tests might be
sufficient to get some confidence that you didn't break normal float
and double stuff, but I'm not sure; you'd probably need to review what
they cover. I'm not aware of any tests that would help for
double-double testing.
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.
