[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
## [Qemu-devel] QEMU support for IEEE 754-201x minimumNumber/maximumNumber

**From**: |
Michael Clark |

**Subject**: |
[Qemu-devel] QEMU support for IEEE 754-201x minimumNumber/maximumNumber |

**Date**: |
Thu, 8 Feb 2018 11:45:46 +1300 |

Hi Folks,
I'm currently going through riscv-tests failures in riscv-qemu and we have
an issue with fmin/fmax.
In particular, this test case is failing:
- https://github.com/riscv/riscv-tests/blob/master/isa/rv64uf/fmin.S#L35-L35
The RISC-V port is currently using the solftfloat floatXX_minnum/maxnum
methods which implement IEEE 754-2008 minNum/maxNum.
RISC-V depends on the IEEE 754-201x definition of
minimumNumber/maximumNumber which returns x for fminmax(sNaN, x) whereas
QEMU implements IEEE 754-2008 minNum/maxNum and will return x, for
fminmax(qNaN, x) but will return NaN for fminmax(sNaN, x)
minNum(x, y) is defined as
- min(x, y) if neither is NaN
- if one of x and y is a number and one is qNaN, return the number
- if both are qNaN, or either is sNaN, return NaN
minimumNumber(x, y) is defined as
- min(x, y) if neither is NaN
- if one of x and y is a number and one is qNaN or sNaN, return the number
- if both are NaN, return the number
My question. Should we add support for minimumNumber/maximumNumber in
fpu/softfloat.c or just implement private versions of these intrinsics in
target/riscv/fpu_helper.c
If we were to change core code, we'd have to think about the interface to
the common min/max macro. i.e. instead of having the ieee flag, have
ieee2008 and ieee201x flags.
The least risk approach would be to define a macro
in target/riscv/fpu_support.c, and then later consider moving it to core
code.
Does the fpu/softfloat.c code have good test coverage in make check?
Michael.

**[Qemu-devel] QEMU support for IEEE 754-201x minimumNumber/maximumNumber**,
*Michael Clark* **<=**