Linux kernel support for floating-point arithmetic

most CPUs currently support floating-point unit FPU,FPU as a separate coprocessor placed outside the processor core, but for embedded processors, floating-point operations are inherently less used, and some embedded processors remove the floating-point coprocessor.
X86 processors generally have the FPU. And the ARM PPC MIPS processor will appear without the FPU phenomenon.

Linux kernel How to handle floating-point operations, we are divided into a processor with the FPU and the processor without the FPU to discuss.

(The following is a summary of personal knowledge, research is not deep, the error of hope that everyone correct, learn together)

pair to the processor with the FPU

1 for Linux kernel, the kernel itself is compiled by default with the-msoft-float option, which is compiled by default as a soft floating-point program, and the soft floating-point meaning is that the GCC compiler simulates floating-point arithmetic (glibc Library provides), floating-point arithmetic code is replaced by a fixed-point operation.

For processors with FPU, we can remove the compile option-msoft-float, typically in Arch/xxx/makefile. Compile kernel as a hard floating point, that is, let the processor's floating point instruction calculate floating point,
Hard floating-point operations are certainly more efficient than simulated fixed-point operations. (there is generally no floating-point operation in the kernel code, so efficiency has little effect)

2 for apps running on kernel, especially for graphics programs, such as QT, where floating-point arithmetic is more, we compile directly, because the processor supports floating-point arithmetic and supports floating-point arithmetic instructions.

Two for without the FPU processor

1 for Linux kernel, the compilation defaults to the-msoft-float option, which is compiled by default as a soft floating-point program, and the Linux kernel compilation does not rely on any libraries for linking, kernel to implement the corresponding simulated floating-point ABI.

2 for apps running on kernel, there are 2 ways to handle floating-point operations:

(1) The soft floating point is simulated by kernel.

The application uses hard floating-point compilation directly (the compiler defaults to compiling to a hard floating-point program).
And for kernel, I know the PPC MIPS processor has a special floating-point Operation exception processing, the program run encountered floating point instruction, unable to run floating point instruction, the hardware will produce the corresponding interrupt exception, kernel floating-point exception handler based on the content of the instruction soft floating-point simulation operation, Returns the result of the operation and then reverts to user space execution.
For arm I did not find an exception entry for floating point calculations in its exception description, but there is also support for its soft floating point in kernel.
You should see this configuration when configuring the ARM Linux kernel:
Menu "floating point emulation"
Comment "At least one emulation must be selected"
Config FPE_NWFPE
...
This is used to configure the inside of the kernel to simulate floating-point processors.
Specific arm How to implement the support exception simulation soft floating point, the specific implementation time also need to carefully look at the code, in the ARCH/ARM/NWFPE.
The advantage of this approach is that the application does not need to be recompiled, and it needs to be opened in the kernel with floating-point simulations, which is very handy.

But the disadvantage is also obvious, each floating-point operation to trigger the interrupt exception, user space and kernel space switch, the execution efficiency is too low.

(2) Recompile the app with soft floating point
This avoids the problem, the app compiles the need to connect to the GLIBC library, using--msoft-float, using GLIBC's simulated floating point, instead of fixed-point arithmetic, the advantage is that the performance of the operation will be better.
The disadvantage is that because different compilation options are used, the ABI used may have changed, and if a library or application does not use the same compilation option (the ABI is different),
When the system is running, there are unexpected situations and even crashes.

According to the recent debug record of a PPC processor, kernel normal boot into the console after the death of a certain address, user space floating point arithmetic, after asking the IC to know the FPU removed, and the processor floating point exception is not enabled.

This encounters a floating point instruction, and the processor does not trigger an exception and does not know how to run the instruction.

Therefore, when carrying out the kernel transplant, it is also necessary to understand whether the processor has a FPU, and if the processor removes the FPU and the kernel does not handle the corresponding (enable floating-point exception), then the app's floating-point instruction will be unpredictable, and the soft floating-point toolchain can be used to compile the app.

Here's a little bit of thinking:

For a processor, there are floating-point exceptions in the processor design (MIPS PPC is), and the FPU can be connected.

After receiving the FPU, the processor core is to block out floating-point exceptions, or floating-point operations or generate floating-point exceptions, the FPU has no practical significance.

Without the FPU, the processor must be able to make a floating-point exception in the kernel, or, as I have encountered above, the processor does not know how to run the floating-point instruction and the result is unpredictable.

Linux kernel support for floating-point arithmetic