store_f f0, 2 * portWORD_SIZE( sp )
Why not start with index 0？
store_f f0, 0 * portWORD_SIZE(sp)
It seems like the the size of FPU register is not fix, should we use portFPU_REG_SIZE?
store_f f0, 2 * portFPU_REG_SIZE(sp)
Thanks
Why not start with index 0？
Looking at the code it does seems strange that storing of the FPU registers happens with a 2 register offset. @aggarg who is the expert here is out. I’m going to see if I can get a demo up an verify the gap in the stored stack.
It seems like the the size of FPU register is not fix, should we use
portFPU_REG_SIZE?
This looks right. We should be able to update to this.
Thank you for your quick replay.
I have figured out why start with 2 offset.
/*
* x12
* x11
* pvParameters
* x9
* x8
* x7
* x6
* x5
* portTASK_RETURN_ADDRESS
* [FPU registers (when enabled/available) go here] -> sp + 2
* [chip specific registers go here]
* mstatus -> sp+1
* pxCode -> sp
*/
This is for pxCode and mstatus
About the size of FPU, each register in Fextension is 32 bits and 64 bits in D-extension.
I raised a PR to fix it.
Additionally, I noticed that the lazy context save/restore flow for the FPU appears somewhat unusual. If I encounter any issues related to this, I’d like to revisit this topic and seek your guidance when appropriate.
1 Like
As you rightly figured, index 0 and 1 are for return address and mstatus.
Thank you for pointing that. portWORD_SIZE is set according to XLEN and portFPU_REG_SIZE is set according to FLEN. Since XLEN and FLEN can be different for the same core, it makes sense to use portFPU_REG_SIZE. I will get the PR merged.
Can you help me understand what you find unusual? I am more than happy to look if you face any issue.
Thank you for the incredibly quick response!
Your feedback made me realize there was an issue in my PR: the offsets at sp[0] and sp[1] should depend on XLEN instead of FLEN. I’ve submitted a new PR to fix this mistake. My apologies for the oversight.
Thank you for submitting the PR. I think the PR had an issue which I have addressed in the latest commit. Please take a look.
1 Like
Dear aggarg
I have seen that if mstatus.FS becomes dirty during the execution of a task, the task will always keep mstatus.FS = dirty during its execution without clean dirty state after restore. However, because FPU context is saved in task stack and depends on sp, this approach is fine.
If a task has used fpu registers, then the task needs to save FPU context every time context switch
I am not sure I understand this completely. If mstatus.FS is dirty, it means that the FPU is in use and we need to be save/restore FPU registers during a context switch.