Trunk build - FPU target options vs Kernel FPU Emulator?

My router (TD-W8970 v1) does not have and FPU so "Use software floating point by default" (located inside "Advanced configuration options (for developers)" > "Target Options") must be set. The description provided fopr that option is:

If your target CPU does not have a Floating Point Unit (FPU) or a
kernel FPU emulator, but you still wish to support floating point
functions, then everything will need to be compiled with soft floating
point support (-msoft-float).

Recently I found out that "Compile the kernel with MIPS FPU Emulator" (located inside "Global build settings" > "Kernel build options") exist, and is unset by default.

Now my question are:

  • Which is the difference between the two options?
  • Given the first flag/option description, can I unset that and enable the kernel FPU emulator?
  • If they perform a similar job and they are really interchangeable, which are the pro and cons of each option?

Using any kind of floating point operation without a physical FPU is going to be really slow, unless you have a very good reason it's not worth tinkering with at all.

Especially so on mips.

My cpu does not have a FPU (34kc sadly, not a 34fc) but if I try to create my build without "Use software floating point by default" OpenWRT will simply not boot.

So I was wondering if those two options do and why only one is enable by default.

Software FP is slightly faster than using a kernel FP emulator, there is a performance cost with trapping FP instructions and decoding them in the emulator. So the emulator is mostly good if you have to support binaries compiled for HW FP. For MIPS you might need an emulator even if you have an FPU.
Also note that programs and libraries must use the same model, the calling conventions differs.

Found this on https://www.linux-mips.org/wiki/Floating_point:

MIPS floating points do no support all operations in hardware. A MIPS implementation is free to not implement certain cases in software. For example denormalized numbers - that's numbers very close to zero - are not handled in hardware. In such a case MIPS FPU will throw an unimplemented exception and expects the exception handler to do deal with the issue. The software in the Linux kernel handles all this and more, it's capable of fully emulating a hardware floating point unit. That is code built for hardware floating point will always run correctly, even on systems without an FPU.

Note that since Linux 2.4.4 there is no kernel configuration option for the floating point assist / floating point emulator anymore. All kernels contain it and too many people got that choice wrong - any system having an FPU in the hardware must have the FPU emulator to guarantee correct operation.

1 Like

EDIT: I read things wrong.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.