Raspberry PI, Slackware ARM and floating point calculations
Slackware - ARMThis forum is for the discussion of Slackware ARM.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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:
Specifies which floating-point ABI to use. Permissible values are:
soft, softfp and hard.
This specifies what floating-point hardware (or hardware emulation)
is available on the target. Permissible names are: fpa, fpe2,
fpe3, maverick, vfp, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16,
vfpv3xd, vfpv3xd-fp16, neon, neon-fp16, vfpv4, vfpv4-d16,
fpv4-sp-d16 and neon-vfpv4. -mfp and -mfpe are synonyms for
-mfpu=fpenumber, for compatibility with older versions of GCC.
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.
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?
Last edited by gus3; 06-23-2014 at 03:57 PM.
Reason: clarify a small point
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
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 ?
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 ;-)
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.