fenv on RISC-V

Joel Sherrill joel at rtems.org
Wed Aug 14 18:44:37 UTC 2019


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


More information about the devel mailing list