> Is that done automatically or do you need to write an explicit > disable_interrupts() > before you use FP/SIMD operations?
I want to thank you for introducing some much needed clarity on this topic. We held an informal chat amongst a few Zephyr toolchain developers on this topic, and I think there's general agreement that the current FPU register management plan which leads to inconsistent behavior depending on what the application does during interrupt processing is not great. I've filed a bug which reproduces the issue using explicit floating point operations to avoid compiler dependencies. To fix this, while still allowing FP operations during interrupt processing, Zephyr needs to support nested save/restore of Advanced SIMD register contents. This should be a reasonably modest change which will remove the fundamental issue. However, we'd also like to have you consider something like this compiler option as a way to improve performance for targets where the Advanced SIMD register save/restore cost outweighs the benefits of using those registers where not required for correct operation of the program. We'd like to catch all such usages to tighten the interrupt latency bounds, but it would be sufficient to simply reduce them where possible to improve average interrupt latency and application performance. We could use some help finding a suitable name for the option, clarifying the precise semantics and reviewing patches, but I'm happy to do the implementation work. -- -keith
signature.asc
Description: PGP signature