Why the portSAVE_CONTEXT called in irq so late in CA9 port? is it has the problem of VFP register not consistency after the irq handler processed?

tugouxp wrote on Monday, December 02, 2019:

in the CA9 port, portSAVE_CONTEXT was call after the actual irq handler has returned,
is this has some potential issue if the interrupt happend during the vfp process has been working ,
and ,just right the irq_handler also do some vfp process and the interrupted task`s vfp registes spot has been broken?

thanks for your kindly help.


call irq_handler

/* A context swtich is to be performed. Clear the context switch pending
flag. */
MOV r0, #0
STR r0, [r1]

       /* Restore used registers, LR-irq and SPSR before saving the context
       to the task stack. */
       POP             {r0-r4, r12}
       CPS             #IRQ_MODE 
       POP             {LR}      
       MSR             SPSR_cxsf, LR             
       POP             {LR}      

       /* Call the function that selects the new task to execute.
       vTaskSwitchContext() if vTaskSwitchContext() uses LDRD or STRD
       instructions, or 8 byte aligned stack allocated data.  LR does not need
       saving as a new LR will be loaded by portRESTORE_CONTEXT anyway. */
       LDR             R0, vTaskSwitchContextConst
       BLX             R0

       /* Restore the context of, and branch to, the task selected to execute
       next. */

The port tries to minimise the interrupt entry and exit time, especially when interrupt nest, but only storing registers when necessary - currently it assumes floating point registers are not going to be used from inside an interrupt service routine so doesn’t store those. The alternative would be to store all the floating point registers on each entry and exit - but that would take additional time and space on each interrupt - including nesting interrupts. Are you able to defer interrupt processing to a task by having the interrupt unblock a task that uses the floating point registers rather than performing floating point operations directly in the interrupt handler?

Note some previous compiler versions use floating point registers as optimisations in calls to things like memcpy() - hence the demos create their own implementations of these calls to prevent that happening.