There are a few articles around that say it is best to use soft float algorithms on ARM devices, because very few ARM chips have hard float coprocessors. So, does the RPi have hard float support? If so, is it quicker that soft float? (It should be, right?)

6 Answers 6


According to the FAQs, the Raspberry Pi uses an ARM 11 chip with floating point support:

What SoC are you using?

The SoC is a Broadcom BCM2835. This contains an ARM1176JZFS, with floating point, running at 700Mhz, and a Videocore 4 GPU. The GPU is capable of BluRay quality playback, using H.264 at 40MBits/s. It has a fast 3D core accessed using the supplied OpenGL ES2.0 and OpenVG libraries.

This will be quicker than soft float (if it isn’t, I’d be amazed!), though on systems without hardware support it’s often a better idea to leverage fixed point processing if you don’t specifically need the range offered by floating point precision.


It does have hardware floating point support. As far as I'm aware this isn't available in the default Debian distro provided for the RPi (yet). I'm not too sure about Arch, although if they don't have support then I imagine it will have soon.

I have Gentoo on my RPi, so I have everything compiled with hard float support by default. It's speedy :)

CFLAGS="-O2 -pipe -mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard"

(distcc and cross-compiling used extensively, of course!)

  • 2
    Xiol, can you do a Unixbench-Benchmark on your Gentoo System and post the results? It surely would be interesting for comparison as the performance difference between the soft-fpu and hard-fpu is quite large. According to copypaste.at/2012/06/raspberry-pi-und-debian-7-wheezy-soft.html (sorry, german language) the whetstone benchmark is about 10x faster with Raspian (ARMHF arch w/ HardFPU) versus the RPI recommended Debian (ARMEL w/ SoftFPU). I guess for GenToo it must be even bigger.
    – user327
    Commented Jun 22, 2012 at 19:09

So, does the RPi have hard float support?

Yes, specifically (on the original Pi) VFPv2.

If so, is it quicker that soft float?


There are a few articles around that say it is best to use soft float algorithms on ARM devices, because very few ARM chips have hard float coprocessors.

Back in 2007 floating point on arm was a mess, many chips didn't have a FPU at all. Those that did often had one of several different and incompatible ones. Worse Debian arm (one of the major arm linux distros at the time) was for historical reasons built for a FPU called FPA which very few chips had and mostly relied on kernel emulation for floating point (software floating point is slow, kernel emulated floating point is slower). I think the situation in other distros was similar but i'm not positive on that.

Given the mess at the time a descision was made that the best option was to do an EABI port using the baseline (soft-float) version of EABI. This ABI was designed in such a way that code could use the baseline ABI while optionally using the FPU. The idea at the time was that the core of the distro would be built using software floating point and then specific code that heavilly used floating point could be built with hardware floating point but still using the baseline (soft float) ABI. This port was known in the Debian world as "armel".

However the "specific packages built using hardware floating point" bit didn't really work out. In practice few packages bothered to do such a thing and there was also the overhead of shuffling values around between integer and floating point registers.

Fast forward to 2011 and the situation had changed considerablly. Arm had been agressively pushing VFP and the vast majority of "applications processors" (the sort of thing you find in moblie phones and simliar) had adopted it. A number of major linux distros (at least Debian, Ubuntu and Fedora initially, more later) chose to do ports using hardware floating point and the hard float ABI. Unfortunately for the Pi these distros (which were reaching compleition around the time the Pi was released) generally set their minimum hardware requirements as ARMv7 with VFPv3_d16 so they would not run on the Pi.

So Pi fans started working on pi-specific distro variants which used hardware floating point and the hard float ABI but were built with compiler settings that would run on the pi.


Yes, as others have stated the Raspberry Pi does have hard float support. Check out the operating system Raspbian.

Raspbian is an unofficial port of Debian Wheezy armhf with compilation settings adjusted to produce optimized "hard float" code that will run on the Raspberry Pi. This should provide significantly faster performance for applications that make heavy use of floating point arithmetic operations.


Since September 18, 2012, Arch Linux ARM also has hard float support. Read this announcement:

Today we are opening the new armv6 hard-float repositories to the public, with all packages built to support the VFP floating-point unit available in the Raspberry Pi and Via APC-IO. Because there is no upgrade path between the armv5 soft-float repository and the new armv6h repository, we have also released a new installation image for the Raspberry Pi. The link to the image is available on the Installation page for the Pi on our main site. This image is also set up for systemd instead of sysvinit and initscripts, so boot times are faster and the installation is future-proofed for changes that are eventually becoming permanent in Arch.

Arch Linux ARM Raspberry Pi


When I downloaded FreeBasic off of FreeBasic.net and tried to compile a simple QuickBasic program, I was notified that the processor has no FPU. It makes it sound to me like there's some kind of Voodoo going on making software work.

What I mean by that is that the core processor of your computer takes care of math and device I/O. The graphics card for instance has its own processor, is a separate computer with a specific instruction set specifically concerned with doing the graphics stuff for you, but doesn't have math commands for you to invoke.

If I'm told the Raspberry Pi doesn't have an FPU, that sounds like it doesn't have a main processor. It makes it feel like the Raspberry Pi is only a graphics card that is somehow manipulated to do the work of the main processor, network card, and so forth, without even having the basic functionality an operating system makes use of for basic math and to connect all of the devices.

The best I can make of it is that the scientific documentation of the Raspberry Pi is thus far off that by any standard it shouldn't do more than turn on its fan when you power it up.

For all intent and purposes, if you want to test what its instruction set is, you should get an external computer that recognizes the INP-command and an adapter cable: parallel to either PCI or ISA, so you can connect the Raspberry Pi as an external graphics card to your computer, the same way they would with fixed systems in buildings, like cash machines.

  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented May 18 at 20:15

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.