> There are too many cases to enumerate... Compilers try hard to use all > available registers and instructions - that's what they are supposed > to do!
It sounds like I'd need a far broader change to ensure a 64-bit CPU could guarantee support for nested interrupts with the low-latency that saving only the non-SIMD registers provides. I suspect the easy "fix" here is to simply mark 64-bit ARM targets as unable to support nested interrupts in Zephyr, which is unfortunate. > Is that done automatically or do you need to write an explicit > disable_interrupts() > before you use FP/SIMD operations? It's automatic; the FPU is disabled at interrupt entry. When a trap occurs, the FPU register contents are saved to the current task block. Interrupts are left disabled and the FPU re-enabled. There's currently a special hack for va_start (which stores all of the SIMD registers) -- the trap emulates FPU store instructions (by writing zero) to avoid needing the FPU in this case. While the automatic handling is convenient, it also makes interrupt latency depend upon the whole call graph from the ISR. Sometimes you get nested interrupts and sometimes you don't. More complex code, where nested interrupts would provide the greatest latency improvement, are worse here. > You have control already: -mgeneral-regs-only or +nosimd will disable large > parts > of the backend. However any registers or backend patterns that are enabled > will > still be used automatically. Even if say only FP registers are enabled (and > no FP > operations at all), the register allocator may use them as spill registers. This is surprising to me as a compiler user. Given that the architecture explicitly enables opportunistic SIMD register saves as a way to reduce interrupt latency, it appears that the compiler now makes this extremely challenging to actually use. -- -keith
signature.asc
Description: PGP signature
