Since the hardware is generally the same between Raspberry Pi's, the target hardware is known to have a hardware floating point unit. I also understand that some operating systems opt to use soft-FP based instructions over using the FPU for software compatibility reasons.

However, I'm wondering: what's stopping you from using the ARM opcodes to use the FPU, even under a soft-FP compiled OS? Are there any technical limitations to running hard-FP binaries on a soft-FP operating system?

Finally, given the above two questions, can I compile software with the various GCC floating point options (soft, softfp, or hard) regardless of what the host OS was compiled with?

Update: For further clarification, do these compiler options only affect function calls containing the float data type? Would the ABI limitation come into play when dealing with simple programs like this one which only uses floating point operations, and not library function calls using floats?

Compiling the above program with gcc -O0 -S -c main.c results in this assembler output listing. For comparison, here is the assembler output using -O3 instead of -O0. Aside from the -O3 build having pre-computed the integer value as 2, the library call for printf is pretty much the same, as expected.

2 Answers 2

  1. The only problem with hardfloat binaries on softfloat system is application binary interface (ABI) incompatibility. And ABI is about interfacing between libraries. You won't be able to link dynamically to the system libraries if you use wrong ABI. If you provide your own hardfp libraries and configure linker to use them instead of system libraries, there should be no problem with that. Also, you should not have any problems if your binary is statically linked (which means it won't need any dynamic libraries).

  2. It should be possible to compile with other floating point options that your system was created but this may require you to create different toolchain for that. This is because of the libraries that has to be linked to your executable which ABI must match ABI of your executable and hardfp toolchain will only contain hardfp libraries.

  3. You have to worry about ABI compatibility even if you are not calling functions with floating point arguments/return value and not using floating point at all. This is because linker will always mark your executable with ABI flags and will refuse to link it with libraries with different ABI. Unless you are compiling your executable in static mode, it must be linked with at least libc library.

  • So there is absolutely no kernel requirement for using the FPU?
    – XTL
    Commented Aug 22, 2012 at 7:20
  • That's not exactly true. Of course kernel has to support FPU because of context switches. But AFAIK there is no configuration option that can disable this so it's always supported (on architectures with FPU). And it doesn't really care which ABI is being used. Commented Aug 22, 2012 at 7:45
  • Before accepting, I'd like to ask one last question then. I'm assuming this only applies when using things in the math library? What about a simple program like this? Would the ABI be a problem, since those operations should compile directly into FP operations (without any function calls)? Commented Aug 22, 2012 at 14:11
  • See my original question for the outputted assembler listing. Commented Aug 22, 2012 at 14:28
  • @Breakthrough: I'm not 100% sure of that but unfortunately linker will set hardfp flags even if no floating point arithmetic was used in the program and you where not using any function calls with floating point. This will make it impossible to link with libc and other libriaries. So it won't work. I will try to check that today to be sure. Commented Aug 22, 2012 at 14:32

Theres several seperate but related issues here.

  1. kernel support, the kernel must support vfp so it can correctly save the registers.
  2. compiler FPU use, does the compiler use the FPU
  3. procedure call abi, how are parameters passed to procedures?
  4. binary tagging, is the binary tagged with what ABI it uses and does the OS do anything with that information.

Regarding 1 there is a config option (CONFIG_VFP iirc) but I don't think i've ever seen a Pi kernel that didn't have it enabled.

Regarding 2 and 3 gcc has a slightly confusing setting called "-mfloat-abi" with three possible values. If it is set to "soft" then software floating point is used along with the soft float ABI. If it is set to "softfp" then hardware floating point is used but with the soft float ABI. If it is set to "hard" then gcc will use hardware floating point and the hard float ABI.

Regarding 4 I know debian based distros will refuse to load a dynamic library if it doesn't match the declared ABI of the binary. No idea if this behaviour has made it into other distros.

P.S. note that variadic functions like printf don't pass parameters in vfp registers even under the hard float ABI.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.