Add feature to simplify lazy stacking of FPU context

[christian-herber-nxp]

https://docs.zephyrproject.org/latest/kernel/services/other/float.html#risc-v-architecture

Zephyr has a concept of lazy stacking of FPU registers.
In a nutshell, FPU registers are not stacked, and FPU accesses cause an illegal instruction exception.
As RISC-V does not have a dedicated FP exception, the exception handler has to decode if the faulting instruction is an FPU instruction.
This is quite cumbersome: https://github.com/zephyrproject-rtos/zephyr/blob/c0a2928f46e962e05504981e7e4dacaca9be4114/arch/riscv/core/isr.S#L238

This code is difficult to maintain (e.g. does not support Zfinx (for Zfinx, a completely different strategy should anyway be chosen) or Zfa), and adds a significant penalty on the execution time.

I am not proposing a solution for now, but there should be plenty ways in which adding a single bit somewhere makes all this code obsolete.
Same thing would apply to V.

[mark-honman]

What I think I read somewhere is that ARM has a cunning mechanism where the first time it gets an FP instruction in the trap handler context, HW pauses to stack the FP registers (in principle if there is an instruction fetch buffer this could be triggered as soon as the FP op enters the buffer).

IMO FP shadow registers are a better solution for common use-cases (FPU area cost is already high, shadow register file is small by comparison). The shadow register file approach runs out of steam when there are a large number of preemption levels, but in such cases I think that the cost of FP stacking and unstacking would defeat the expected performance benefit of many preemption levels.

One thing we should consider is stacking/unstacking of FCSR which if I remember right has about 10 useful bits. Especially as FCSR could potentially be altered by interrupt-handler code. On the other hand a trap handler may have valid reasons for altering FCSR.
Ideally FCSR would be stacked in the same word as some other state.

[christian-herber-nxp]

Arm is not Arm, and only some architectures have this feature. Others will trigger a dedicated FP exception.

Note that Zephyr discourages usage of the FPU in ISRs.
As the ISR has to stack its FP context into the last thread, it cannot be preempted by another ISR using the FPU.

The fcsr CSR should be saved in lazy fashion together with the floating point context, and not upfront in the isr prologue (e.g. ipush).