What's the difference between hard and soft floating point numbers?

Question

When I compile C code with my cross toolchain, the linker prints pages of warnings saying that my executable uses hard floats but my libc uses soft floats. What's the difference?

Solution 1

Hard floats use an on-chip floating point unit. Soft floats emulate one in software. The difference is speed. It's strange to see both used on the same target architecture, since the chip either has an FPU or doesn't. You can enable soft floating point in GCC with -msoft-float. You may want to recompile your libc to use hardware floating point if you use it.

Solution 2

There are three ways to do floating point arithmetic:

• Use float instructions if your CPU has a FPU. (fast)
• Have your compiler translate floating point arithmetic to integer arithmetic. (slow)
• Use float instructions and a CPU with no FPU. Your CPU will generate a exception (Reserved Instruction, Unimplemented Instruction or similar), and if your OS kernel includes a floating point emulator it will emulate those instructions (slowest).

Solution 3

Strictly speaking, all of these answers seem wrong to me.

When I compile C code with my cross toolchain, the linker prints pages of warnings saying that my executable uses hard floats but my libc uses soft floats. What's the difference?

The Debian VFP wiki has information on the three choices for -mfloat-abi,

• soft - this is pure software
• softfp - this supports a hardware FPU, but the ABI is soft compatible.
• hard - the ABI uses float or VFP registers.

The linker (loader) error is because you have a shared library that will pass floating point values in integer registers. You can still compile your code with a -mfpu=vfp, etc but you should use -mfloat-abi=softfp so that if the libc needs a float it is passed in a way the library understands.

The Linux kernel can support emulation of the VFP instructions. Obviously, you are better off to compile with -mfpu=none for this case and have the compile generate code directly instead of relying on any Linux kernel emulation. However, I don't believe the OP's error is actually related to this issue. It is separate and must also be dealt with along with the -mfloat-abi.

Armv5 shared library with ArmV7 CPU is an opposite of this one; the libc was hard float but the application was only soft. It has some ways to work around the issue, but recompiling with correct options is always the easiest.

Another issue is that the Linux kernel must support VFP tasks (or whatever ARM floating point is present) to save/restore the registers on a context switch.

Solution 4

It sounds like your libc was built for software floating point operations while your exe was compiled assuming hardware support for floating point. In the short term, you could force soft floats as a compiler flag. (if you're using gcc I think it's -msoft-float)

Longer term, if your target's processor has hardware support for floating point operations you'll generally want to build or find a cross toolchain with hardware float enabled for speed. Some processor families have model variants some with and some without hardware support. So, for example, just saying your processor is an ARM is insufficient to know if you have hardware floating point support.

Solution 5

The computation may be done either by floating-point hardware or in software based on integer arithmetic.

Doing it in hardware is much faster, but many microcontrollers don't have floating-point hardware. In that case you may either avoid using floating point (usually the best option) or rely on an implementation in software, which will be part of the C library.

In some families of controllers, for example ARM, the floating-point hardware is present in some models of the family but not in others, so gcc for these families supports both. Your problem seems to be that you mixed up the two options.

View more solutions

Comments

[Nils Pipenbrinck]

If it is ARM architecture please put that into the tags :-)

[nullException]

@Nils Pipenbrinck: MIPS chips also have this issue

[artless noise]

Modern GCC (~4.8+) versions support 'multi-lib', which have hard float and soft float libraries. Earlier versions required you had a compiler built with a specific version. Occasionally the path to the correct library is needed when linking with a 'multi-lib' gcc distribution as there are several version of the libraries (requiring a longer time to build the compiler). Directory names might be 'hf', 'hardf', 'libhf', or 'hard-float' but they are usually under the regular 'soft' directory or a nearby location.

[Tor Klingberg]

This is the right answer. The calling conversion for floats needs to match between your code and libc. It might still work with a mismatch, if you never never call any floating point libc functions.

[PhilLab]

"It's strange to see both used on the same target architecture" This can make sense for a library to be machine-independent and bit-exact (soft float) in accuracy-critical parts and fast (hard float) in parts where small deviations don't matter.

[Aaron Franke]

It happens on 32-bit ARM.

[MeatFlavourDev]

Soft floats can be used for deterministic calculations, e.g. for physics simulation. They will give the same results every time, on every platform, on every processor.

[silvergasp]

+1 as this seems to be the most correct answer. I'd also add that while you might have an FPU or not. You can also have an FPU that only supports a subset of the functions that can be expressed in a C program e.g. 1.0L / 2.0L would not be possible on a single-precision FPU but 1.0f / 2.0f would be. It is often the case that the compiler runtime (e.g. libgcc) will provide the 'soft' version of the missing long-double-division. However, the single-precision instructions will be 'soft' wrapped hardware instructions.