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

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.