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

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?

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.

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).

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.

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.

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.