Support for FPU context switch in RISC-V

Hello, I noticed that the RISC-V port does not support (re-)storing the floating point context as part of the context switch process.

I would like to provide that support for FPU. To test it I would also create a Demo port based on QEMU (similar to RISC-V_RV32_QEMU_VIRT_GCC) but that supports:

  1. xlen 64 bits
  2. f extension (to have the FPU)
  3. (In a subsequent PR) Vector support

Does it make sense? Should I create the PRs (in FreeRTOS and FreeRTOS-Kernel) directly or what should I do first?

Thanks!

@cubidesj

Thanks for your interest in contributing to the FreeRTOS kernel.

Does it make sense?

Yes, it looks good to me.

Should I create the PRs (in FreeRTOS and FreeRTOS-Kernel) directly or what should I do first?

You can work on the forked versions of FreeRTOS (for the new demo) and FreeRTOS-Kernel (for supporting FPU in the port) repos and create the PRs together to each of their official repos once they’re ready, so that test/review processes can be performed easily.

Do we really need to create a new demo? Can the existing one not be used to show FPU also (likely by adding register tests that store and verify floating point registers)?

I was thinking of having one that is close to RVA23 (http://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc). Which would be 64-bit (which I did not see on QEMU) and include both FPU and Vector unit (I would also add support for vectors in a later PR).
Those characteristics are different enough from each of the current demos that I thought about creating a new one but I agree that the difference in code itself is small. So I see a few possibilities:

  1. Create a new Demo (as I was doing)
  2. Update RISC-V_RV32_QEMU_VIRT_GCC to support FPU (and later VPU) but we still wouldn’t have a 64-bit QEMU version
  3. Update RISC-V_RV32_QEMU_VIRT_GCC to support FPU (and later VPU) and 64 bits (which would imply a rename because it no longer would be RV32)
  4. Something else that you propose

Please let me know what you think

I am indeed updating the RegTest (under FreeRTOS/Demo/RISC-V_RV32_QEMU_VIRT_GCC/build/gcc/RegTest.S) to include the FPU registers

I like this one except the renaming part as it may break some CIs. Are you thinking of a build time option to pick 32 vs 64 bit? If yes, we can keep 32 but default.

Are you thinking of a build time option to pick 32 vs 64 bit? If yes, we can keep 32 but default.

Yes, a compile time option. I’ll begin working into this, then.

I like this one except the renaming part as it may break some CIs.

Well, I do think that leaving the “RV32” in the name would be misleading but I have no idea if I can do anything for the potentially broken CIs.

Agree that it is a bit misleading. Let’s work on the PR and we’ll see if anything could be done in this regard.