You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Zephyr Kernel specification claims that under the Unshared FP registers' mode, only a single context (a thread, not an ISR) is allowed to use the FP registers, otherwise the behavior is undefined.
This allows us to implement the following enhancements that will increase system performance:
We remove the requirement for Stacking the FP-context during Exception Entry and/or context-switch. We don't really need to do this, since the ISRs won't touch the FP registers, and the next switched-in thread won't do it, either. This will improve both interrupt latency, when building with CONFIG_FLOAT=y, and required stack size for threads that use the FP
We remove the activation of FP-context during boot. This is not needed, as the single thread that will use the FP-context, can, simply initialize it. We update the documentation to match this change.
We add the initialization of FPSCR and the FP registers during boot. This is fine, since only a single entity will use the FP-context.
We also remove the FP-context from the ESF and _preempt_float structures, since we won't be stacking these registers, anyway. This saves us some memory from the thread structures.
Finally, we configure the FPCCR according to the setup with respect to CONFIG_USERSPACE.
The text was updated successfully, but these errors were encountered:
The Zephyr Kernel specification claims that under the Unshared FP registers' mode, only a single context (a thread, not an ISR) is allowed to use the FP registers, otherwise the behavior is undefined.
This allows us to implement the following enhancements that will increase system performance:
We remove the requirement for Stacking the FP-context during Exception Entry and/or context-switch. We don't really need to do this, since the ISRs won't touch the FP registers, and the next switched-in thread won't do it, either. This will improve both interrupt latency, when building with CONFIG_FLOAT=y, and required stack size for threads that use the FP
We remove the activation of FP-context during boot. This is not needed, as the single thread that will use the FP-context, can, simply initialize it. We update the documentation to match this change.
We add the initialization of FPSCR and the FP registers during boot. This is fine, since only a single entity will use the FP-context.
We also remove the FP-context from the ESF and
_preempt_float
structures, since we won't be stacking these registers, anyway. This saves us some memory from the thread structures.Finally, we configure the FPCCR according to the setup with respect to
CONFIG_USERSPACE
.The text was updated successfully, but these errors were encountered: