Re: [musl] Posits support under Musl libc?

[Rich Felker <dalias@libc.org>]

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.