fenv on RISC-V

[Jiri Gaisler]

Having said that, I will check if the generation of FP exception flag for RISC-V in sis are as accurate as for SPARC. Generating the wrong flags could cause the type of failures we are seeing ...

On 8/14/19 10:42 PM, Jiri Gaisler wrote:
> 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel