Lines Matching full:fpu
64 * FPU user: A thread that can use the standard floating point registers
72 context switches to ensure the computations performed by each FPU user
83 treats *all* threads as FPU users when shared FP registers mode is enabled.
145 On the ARM64 (Aarch64) architecture the kernel treats each thread as a FPU
149 FPU user to a non-user thread, and then back to the original FPU user.
151 FPU register usage by ISRs is supported although not recommended. When an
153 current FPU user context is saved in the thread object and the ISR is resumed
155 and potentially requesting FPU usage. Because ISR don't have a persistent
156 register context, there are no provision for saving an ISR's FPU context
166 or FPU user and the thread must be tagged by one of the
193 On the RISC-V architecture the kernel treats each thread as an FPU
194 user on a case-by-case basis with the FPU access allocated on demand.
197 For example, the FPU registers are *not* saved when switching from an
198 FPU user to a non-user thread (or an FPU user that doesn't touch the FPU
199 during its scheduling slot), and then back to the original FPU user.
201 FPU register usage by ISRs is supported although not recommended. When an
203 current FPU user context is saved in the thread object and the ISR is resumed
205 and potentially requesting FPU usage. Because ISR don't have a persistent
206 register context, there are no provision for saving an ISR's FPU context
209 As an optimization, the FPU context is preemptively restored upon scheduling
210 back an "active FPU user" thread that had its FPU context saved away due to
211 FPU usage by another thread. Active FPU users are so designated when they
212 make the FPU state "dirty" during their most recent scheduling slot before
213 being scheduled out. So if a thread doesn't modify the FPU state within its
214 scheduling slot and another thread claims the FPU for itself afterwards then
216 its FPU context restored until it attempts to access it again. But if that
217 thread does modify the FPU before being scheduled out then it is likely to
218 continue using it when scheduled back in and preemptively restoring its FPU
229 or FPU user and the thread must be tagged by one of the
239 kernel saves *all* floating point registers, if the FPU was enabled in
243 point registers is synchronous and thus not lazy. The FPU is always disabled
249 is required for each FPU user thread to load and store floating point
257 FPU user or SSE user on a case-by-case basis. A "lazy save" algorithm is used
260 switching from an FPU user to a non-user thread, and then back to the original
261 FPU user. The following table indicates the amount of additional stack space a
269 preemptive FPU 108 bytes
276 to support the SSE registers, or as an FPU user if the SSE registers are
277 not supported. If this would result in a thread that is an FPU user being
295 :c:func:`k_float_disable` to remove its tagging as an FPU user or SSE user.
300 itself as an FPU user or SSE user by calling :c:func:`k_float_enable`.