[RFC] Adding RISC-V Vector support to RTEMS

[Ken.Unger at microchip.com]

Hello RTEMS experts,

We're in the process of implementing support for RTEMS on a new RISC-V platform.  Among other things, our processor core supports the RISC-V Vector ISA (RVV), with its 32 vector registers which in our case are 512 bits (VLEN) deep.   RVV is used by applications to accelerate a variety of code/algorithms utilizing either the auto-vectorizer in GCC/Clang, or through C intrinsics or direct assembly coding.

My query here is regarding context saving, and options for optimization.  Before I get to that, here's a few points of background.

#1. Use of RVV by the compiler (GCC/Clang) is dictated by the ISA string provided, e.g -march=rv64imadcv,  where v is for vector.  The compiler preprocessor symbol "__riscv_vector" can then be used for conditionally compiled code, similar to what is done for floating point.



#2. Enablement of RVV can be controlled via a machine status CSR.   This allows one to disable RVV entirely (triggering an exception if RVV instructions are executed), but also allows one to track the dirty/clean state of the vector register file.  (https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#vector-context-status-in-mstatus).  So, one can conditionally save/restore the registers, although the 2KB of stack space (32 x (512b / 8)) would need to be allocated.

#3. The C ABI specifies that vector registers are Caller saved.  So, any system call (or any function call for that matter) does not need to preserve these registers.

A relatively straightforward approach is to say that RTEMS + Application is built with vectors enabled (i.e  -march=rv64imadcv).  One does not need to save/restore the vector registers within Context_Control because of #3, however, because we are now building RTEMS with V enabled, we need to add this save/restore to the CPU_Interrupt_frame and incur that cost on all interrupts and stack space for all tasks.   (A small secondary effect is that CPU_INTERRUPT_FRAME_SIZE is now larger than the immediate addressing range).

Is there an alternative to consider?   Might one build RTEMS itself without V, leaving that only for Applications/Tasks, perhaps adding a Task attribute, and thereby taking the vector save/restore penalty only when switching into or out of a vector enabled task?  (Perhaps similar to HW floating point from the past).  One would then use an RTEMS config flag to enable vector support, although qualified in runtime by validating the existence of the vector ISA (misa CSR).    Or maybe that direction would require too many changes?  e.g I see that "is_fp" is used more specifically, rather than the more general rtems_attribute in Thread_Control and in the arguments to _Context_Initialize().  Anyways, I'm happy to hear any thoughts on this subject.  Note that I'm new to RTEMS, so may not have some past context.

Thank you,
Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240314/3cb03c72/attachment.htm>