I’ve already browsed the forum and found many hints that indicate that it should be possible without register corruption on context switch, but I found it only mentioned in context with the “normal” VFP.
I am aware that you have to enable FPU support: #define configUSE_TASK_FPU_SUPPORT 2
But is this enough to save and restore all FPU registers, also those used exclusively by the neon, when using the compiler flag -mfpu=neon ?
The neon apparently shares some registers with the VFP but has more. Are those additional registers also secured during a context switch?
Looking at the portSAVE_CONTEXT macro in the portASM.S, I guess it’s fine as all D-registers appear to be saved (assuming that the matching name is not just by coincidence), or am I mistaken?
/* Save the floating point context, if any. */
FMRXNE R1, FPSCR
VPUSHNE {D0-D15}
VPUSHNE {D16-D31}
PUSHNE {R1}
As I said, it strongly appears to be fine, but I want to be extra safe by asking you guys, in order to avoid nasty bugs later on.
Which device are you using. Or more specifically, does it implement advanced SIMD and VFPv3? If so, you should be fine. If not, you will “probably” be fine, but it would take a deeper dive into what exactly is implemented on your device.
@rtel Hello, thanks for your fast reply.
I am using a Zynq7000, precisely the xc7z014sclg484-1. It features an ARM cortex A9 core with ... support for the ARM v7 Advanced SIMD and Vector Floating-Point v3 (VFPv3)
So accoring to you, I should be fine, thanks for this estimation.
However out of interest, I’d really like to know how you come to your conclusion? How comes you know it’s safe if advanced SIMD & VFPv3 are present?
Do you see that from reading the portASM.S?
The key here is that ARM fairly precisely defines their processors, so all ARM cortex A9s with VFPv3 will look the same as far as interfacing with the core of the processor (the peripherals may change, but the processor and its capabilities are well defined). Thus a port that handles the one such machine, will handle all of them, since FreeRTOS itself, only needs to deal with that core.
Arm’s documentation is explicit in that you don’t need to update context switch code when using advanced SIMD and VFPv3. So my claim is contingent on the accuracy of their documentation, which is a safe assumption.
