fenv on RISC-V

[Jiri Gaisler]

Interesting. I can confirm that the griscv bsp is using hard floats and doubles, it is compiled with -march=rv32imafd -mabi=ilp32d. The paranoia benchmark runs successfully and uses float instructions and registers. The sis simulator emulates all float and double instructions as define in the RISC-V specification. So the failures in psxfenv01 are likely be due to some gcc/newlib limitations or possibly some shortcomings in the RTEMS RISC-V port.

Jiri.

On 8/14/19 8:44 PM, Joel Sherrill wrote:
> Hi
>
> I emailed Jim Wilson of SiFive and got a quick response. Much thanks
> to him and this is his reply:
>
> ==================
> I don't have any embedded hardware that I can use for testing.  I just
> have linux and simulators (qemu, gdb sim).  I haven't seen gcc
> testsuite failures related to fenv, but not sure if those tests are
> being run for embedded elf targets.  The testcase doesn't work with
> gdb sim, probably a gdb sim bug.  It does work with qemu, but only if
> I use a -march that has FP support.  Checking the code, it looks
> pretty obvious, fegetexceptflag for instance is
>
> int fegetexceptflag(fexcept_t *flagp, int excepts)
> {
> #if __riscv_flen
> ...
> #endif
>   return 0;
> }
>
> __riscv_flen is the number of bits (bytes?) in the FP registers, and
> is zero if this is target has no FP support.  So fenv for soft-float
> targets hasn't been implemented.  Was probably implemented for hard
> float targets because it is easy, we just directly read/write the fp
> status register.
>
> feraiseexcept isn't fully supported, but that seems to be a standards
> interpretation question.  RISC-V hardware doesn't have a way to
> automatically trap when an exception is raised.  We can only set a bit
> in the fp status register and something else needs to check that and
> trap.  So is feraiseexcept full implemented if we set the bit but
> don't trap?  Newlib says no.  Glibc says yes.  But glibc has
> feenableexcept and FE_NOMASK_ENV.  Newlib does not.  So on RISC-V, all
> exceptions are masked, and that can't be changed.
> ==================
>
> This test (and fenv in general) is unlikely to work on an target with
> soft float per Jim and some newlib discussions. On those BSPs,
> it may have to be marked as NA with a comment about soft float.
> Unless the test is automatically disabled if the CPU_HARDWARE_FP
> define in RTEMS is false. But this is always defined to FALSE on risc-v.
>
> Q: Is hardware FP even supported right now on RISC-V? I don't see the
> context switch code assuming there are registers to switch.
>
> And as Jim notes, even on some hardware targets (yes RISC-V), some
> things don't work.
>
> So let's try this on a HW FP target and see if the works.
>
> Then address how to automatically disable this test with fall back to
> updating a lot of .tcfg files.
>
> --joel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel