xiaoxiang781216 commented on code in PR #9103: URL: https://github.com/apache/nuttx/pull/9103#discussion_r1193856259
########## arch/risc-v/src/common/riscv_macros.S: ########## @@ -227,8 +222,15 @@ REGLOAD t0, REG_INT_CTX(\out) li t1, MSTATUS_FS and t2, t0, t1 - li t1, MSTATUS_FS_INIT - ble t2, t1, 1f + li t1, MSTATUS_FS_DIRTY + bne t2, t1, 1f + + /* Reset FS bit to MSTATUS_FS_CLEAN */ + li t1, MSTATUS_FS_CLEAN Review Comment: > I agree that with the current implementation FPU needs to be saved & restored always if the thread ever uses the FPU, even once. Otherwise the operation is never atomic and the restore occurs from the wrong stack frame. The current "lazy fpu" implementation is just plain wrong and needs to be removed completely in order for this to work. > > However, I would still like to discuss doing the lazy FPU properly, by adding a separate FPU save area into the TCB. RISC-V has tons of memory, but the exception handling (and system call handling) is VERY CPU intensive. I already see this high CPU usage in my application that has a lot of interrupts and uses FPU in almost every thread. > It's strange that almost every thread use FPU. Does the code use FPU instruction explicitly or generated by compler implicitely? > I am in fact already writing the code, the CPU usage is just too important for my application. It's fine to add a new option, but I am afraid the new option can't help so much as you expect if FPU instruction is inserted by compiler like gcc for arm32/arm64. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
