[libre-riscv-dev] berkeley-softfloat-3 implements different variants of IEEE754

[Hendrik Boom]

On Thu, Feb 28, 2019 at 01:18:16AM +0000, Luke Kenneth Casson Leighton wrote:
> ok so a bit of a pain: softfloat-3 actually implements compatibility
> with different *hardware* variants of the IEEE754 standard.  there are
> three (2 of which have sub-variants): Intel x86 (and an SSE
> sub-variant), ARM-VFP2 (and a sub-variant) and RISC-V.
> 
> RISC-V returns canonical (default) NaNs rather than do what x86 does,
> which is to preserve *some* information when values are added to
> non-canonical NaNs.  hence the weirdness for example of putting the
> MSB of the mantissa into the LSB when adding positive-zero to a
> non-canonical NaN.
> 
> this makes life a bit of a pain in the ass, as far as generic
> implementation goes.  if either operands are NaN, x86 requires that a
> NEGATIVE canonical NaN be returned, whereas RISC-V requires a POSITIVE
> canonical NaN to be returned (actually, x86 may be a bit more complex
> than that).
> 
> either way, we have to choose:
> 
> * do we implement RISC-V *only*
> * do we implement an option to comply with x86 variations on the
> IEEE754 standard
> 
> in particular this makes testing complex: you actually have to compile
> *special versions* of sfpy with -DSPECIALIZE_TYPE=RISCV (or other
> variant).

Seems to me that if we are implementing a RISC-V we should follow the 
RISC-V spec.

Or is there some reason to do otherwise?

Perhaps to make it easy to write x86 emulators on the RISC-V?
Or is the RISC-V convention a violation of the IEEE arithmetic spec?

-- hendrik

> 
> l.
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev