Raspberry PI, Slackware ARM and floating point calculations
 

Supposing I've a PI running with a Raspbian hardfloat enabled kernel and a Slackware ARM 14.0 or 14.1 userland that includes distribuited GCC package (and necessary dependencies to compile stuff).

If I write C code that does tons of floating point calculations can I instrucg gcc (on the slackware ARM userland) to compile the executable so as to use hardfloat ? or will I run into all sorts of problems dew to system libraries being compiled softfloat ?

I was looking at the GCC ARM options and I noticed a few things that might be of intrest concerning what I want to acheive:

I did some FP experiments on the RasPi.
http://www.linuxquestions.org/questi...8/#post4913580
But I didn't give any special instructions to the compiler.

jlinkels

Good to know ... but what distribution were you using when you did your tests ? as this may have a lot of influence on the FP performance.

The Slackware ARM userland is compiled to use softfloat, while I think that Debian derivates for the ARM platform are compiled to use hardfloat, while raspbian is specifically tune for the PI hardware.

What I'm asking for is advice on options (if there are any) on compiling stuff to use hardfloat on a softfloat userland.

Raspbian.

jlinkels

Well then I think it's normal, the compiler is most likely configured to produce hardfloat binaries by default.

The question still remains what options are there (if any) for compiling stuff to use hardfloat on a softfloat userland ?

Linux distro managers configure GCC's defaults to produce object code using the specified ABI for the distro. In the case of ARM, Raspbian uses hard-float (and the VFP), and Slackware uses soft-float (and emulated floating-point, not VFP). You can compile, specifying the "wrong" hard/soft-float, and you will get an object file, but the linker will reject it as unsupported. Given that Glibc was built using GCC (with its already-configured defaults), just about every executable binary will need to use the same ABI as Glibc.

(Unless you're building a free-standing image, i.e. a Linux kernel or some other bare-metal programming. But that's for a different thread.)

There is also a third option for ARM: "softfp", which passes FP arguments on the stack, conforming to "soft" ABI, but generates instructions for using the VFP/Neon instruction within a function. It can provide a code speedup, as well as decreasing a process's RSS. It's even possible to rebuild Slackware's Glibc to use softfp for /lib/libm.*. I have a HOWTO explaining this, but bear in mind it is definitely not for the faint-hearted. I can't post a URL, but you can do a Google search for "slackware arm rebuild glibc vfp" and it will be at the top of the results.

Does that clarify things?

Yes ... a whole lot more.
The biggest issue I have is time ... 2 lively, under 5, kids occupy almost all my spare time.
Although I dislike the idea it might be a whole lot faster to have an SD image with a PI tuned ready-made image (like raspbian) on it ... while waiting for raspware :D
Maybe next time I send wife and kids away a month or so for summer vacation I can look into vfp glibc ... I suppose that once I do that a lot of my ARM devices running slackwareARM could benefit from the effort ?

They can benefit only if they have an FPU (VFP or Neon). I have 3 Android devices, all ARM, and none of them have an FPU. The RPi is the only one with an FPU.

The Pi obviously has VFP, as far as I know the tegra2 in the AC100 is lacking NEON but has VFPv3, the Allwinner Axx all have NEON, VFPv3 and Thumb-2, the RK3066 should be much like the A20, the MT8125 has a Cortex A7 core so I suspect it has FPU ...the PXA270 I don't use much anymore (I've forgotten if it had VFP) and the kirkwood plug related stuff needs not do much floating point anyway as they've become NAS and print server.

If I ever get round to follow your HOWTO I've more hardware that can benefit ;-)

Actually, it almost sounds like you have a build farm going there. Have you figured out how to shoe-horn Slackware into all of them?

The RK3066 and MT8125 are the only 2 that are pending work to get into the slackware club ... all the others, have or had at some point, slackware installed on them (and if it was not a slackware it was my own Clash/ClashNG miniroot).
None of the the ones that currently run slackware are particularly good for building because they lack ram ... in any case I don't have much time for that at the moment: I'll look into buying an Odroid U3 or an Nvidia TK1 (or whatever will be bang for buck with tons of computing power) when the kids grow up a little and I might have a bit more time.
It might be interesting to see how the dual core 1.6Ghz RK3066 with 1Gb of ram manages compiling stuff ... more on this when I get slackware running on it. It's a damm pity it's lacking GPIO or I'd be using that instead of the pi for my droid model submarine project. It's just a matter of time now for the RK3066: this howto has all the information required ... it just needs a little bit of tinkering to adapt it to slackware.