[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200629201719.GC6430@brightrain.aerifal.cx>
Date: Mon, 29 Jun 2020 16:17:19 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Posits support under Musl libc?
On Mon, Jun 29, 2020 at 08:15:40PM +0200, Markus Wichmann wrote:
> On Mon, Jun 29, 2020 at 06:26:42PM +0200, Szabolcs Nagy wrote:
> > i would not hold my breath for posit support even if it was the
> > best possible floating-point format.
> >
> > it has to be properly standardized and added to hw architectures.
> >
> > then the related software standards need to be developed (abi,
> > programming language support, math library behaviour for special
> > cases, printf format specifiers, etc)
> >
> > then the tooling support has to be added (compilers, emulators,
> > softfloat libraries, etc)
> >
> > then we can come back and consider doing something about it in
> > musl.
> >
> > (and even then it will take time for it to be usable in user
> > code: requires widely deployed hw, protocol and file format
> > updates, new algorithm designs and review of existing algorithms
> > for compatibility)
>
> In addition, Posit support is going to run into the problem that IEEE
> 754 implementations are readily available /right now/ and are "good
> enough" for most applications. Hell, most applications don't even
> require floating-point at all. The good can sometimes be the enemy of
> the perfect, but here I am squarely on the side of pragmatism.
Not only are they "good enough"; pretty much everyone except the
inventor of posits and a small fan club thinks IEEE 754 floating point
is *better* than posits.
In any case, musl is not a platform for launching and promoting new
experimental ideas. We implement interfaces where there is already
widespread consensus that they belong in libc, either as a result of a
published standard or agreement between multiple libc implementations
across different systems(*). The Austin Group (responsible for POSIX)
generally doesn't accept new ideas without a sponsor (an existing
implementation already committed to it) and agreement from members.
WG14 (C standard) sometimes takes new ideas but they usually turn out
botched when it happens; ideally they go through optional TRs first
and only become standard if they're widely liked.
Rich
(*) That's not entirely true. We also have thin syscall wrappers for
Linux-specific functionality, on the presumption that it's not any big
design or bloat commitment, but sometimes this turns out to be false,
e.g. in the case of sendmmsg/recvmmsg.
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.
