Linux kernel floating point usage

Question

I read Robert Love "Linux Kernel Development" and I came across the following passage:

No (simple) use of floating point

When floating point commands are used in user space, the kernel controls the transition from integer to floating point mode. What the kernel should do when using floating point instructions depends on the architecture, but the kernel usually catches a trap and then initiates the transition from integer to floating point mode.

Unlike user space, the kernel does not have the luxury of seamless support for floating point, because it cannot easily lure itself. Using a floating point inside the kernel requires manually saving and restoring floating point registers, among other possible tasks. Short answer: do not do this! Except in rare cases, there are no floating point operations in the kernel.

I have never heard of these "whole" and "floating" modes. What exactly are they and why are they needed? Does this difference exist on major hardware architectures (e.g. x86), or is it specific to some more exotic environments? What exactly does the transition from integer to floating point mean, both from the point of view of the process and the kernel?

Answer 1

Because...

• many programs do not use floating point or do not use it on any given time fragment; and
• maintaining registers of FPUs and other state of FPUs takes time; therefore

... the OS kernel can simply disable FPU. Presto, there is no state to save and restore and, therefore, faster context switching. (This is what mode means, it just means that the FPU is on.)

If the program tries to perform the FPU operation, the program enters the kernel, the kernel turns on the FPU, restores any saved state that may already exist, and then returns to perform the FPU operation again.

When switching the context of time, he knows that he needs to go through the logic of saving state. (And then he can disable FPU again.)

By the way, I believe that the explanation of the book because the kernels (and not just Linux) avoid FPU operations ... is not entirely accurate. ^one

The kernel can cling to itself and do this for many things. (Timers, page errors, device interruptions, etc.). The real reason is that the kernel does not need FPU operators and also needs to run on architectures without FPUs. Therefore, it simply avoids the complexity and runtime required to manage its own FPU context without performing operations for which other software solutions always exist.

It is interesting to note how often the state of the FPU should be saved if the kernel wanted to use FP .,. every system call, every interrupt, every switch between kernel threads. Even if there was a need for a random FP kernel, ² most likely, it will be faster to do this in software.

---

<sup>1. That is, wrong.
2. There are several cases where I know where the kernel software contains a floating-point arithmetic implementation. Some architectures implement traditional FPU operating systems on hardware, but leave some complex IEEE FP operations for software. (Think: abnormal arithmetic.) When an odd case arises with IEEE, they end up in software that contains pedantic correct emulation of operating systems that may trap.</sup>

Answer 2

In some versions of the kernel, floating point registers are not saved when the kernel or system task is disabled. (This is because FP registers are large and take up both time and storage space.) Therefore, if you try to use FP, the values ​​will be randomly selected by "poof".

In addition, some floating point hardware circuits rely on the kernel to handle strange situations (such as zero division) through the trap, and the required trap mechanism may be at a higher level than the kernel task currently works.

For these reasons (and even more in pairs), some FP hardware circuits are caught when you first use the FP instruction in a task. If you are allowed to use FP, the floating-point flag is turned on in the task; if not, you are removed by the firing squad.