We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi
We found the issue when using floating-point calculations in the mulitple ISR, then the floating-point number will be not as expected sometimes.
After adding "VPUSH {D0-D15}" in the beginning of the interrupt callback and adding "VPOP {D0-D15}" in the end of the interrupt callback, the issue will not occur anymore.
I think the cause is the floating-point register set is not automatically saved and restored for Cortex-R52+, is that right ?
What is the suggestion for such issue ?
Is it necessary to pop and push FPSCR manually ?
BR, Grace
Grace WANG said:I think the cause is the floating-point register set is not automatically saved and restored for Cortex-R52+, is that right ?
That's correct.
Cortex-R52 implements Armv8-R AArch32. In AArch32, the general purpose and floating-point registers are not automatically saved on exception entry (or restored on exception return). It's up to software to stack whichever registers it needs/wants to use in the exception handlers.
The same goes for registers such as the FPSCR. Avoiding the overhead is why some software chooses not to use FP/Neon in exception handlers.
This guide might be useful: https://developer.arm.com/documentation/den0042/a/Exceptions-and-Interrupts/Exception-handling It was written more for the Cortex-R4/5, but the basics of exception handling remain the same
Hi Martin
I see the Cortex-R programming guide only mentions about the Rn, LR, etc, for exception handling, but no floating-point registers. Is there any document to indicate that the floating-point registers for Cortex-R need be saved and restored manually and also any guide or instruction process for that ?
Yeah, I suspect that's because of the assumption that a lot of interrupt handler code will avoid the FP registers to save the overhead.
In terms of a list, it's more the other way around. The architecture lists those registers which are updated on exception entry/exit. Any other register you update, or cause to be updated, that effects where the exception was taken from potentially has to be saved/restored. The architecture doesn't spell it out as you might deliberately choose to save/restore some registers. For example, you might use registers to pass arguments in and out of a system call.