Is the ARM processor on cRIO 9068 "hard float"-capable?

[BFD_LNS]

Hi everyone,

I'm currently trying to port a C/C++ project to cRIO 9068; some code was meant to run, among others, on armhf architecture, i.e. with floating point "in hardware".

But upon reading this post I'm afraid the task could prove difficult (or at the very least require some modifications to the code) because what I infer is that the ARM processor on cRIO 9068 actually has no floating point hardware, since it cannot use the armhf toolchain.

Is that correct?

[BradM]

Not 100% correct, but you are right that it wouldn't be easy.

The Cortex-A9 in the Zynq devices does have a full IEEE 754-compliant FPU (the VFPv3). This FPU is actually being used for any floating-point opperations (in LabVIEW, in regular code, pretty much everywhere).

"Then what's the difference between softfp and hardfp?", you ask. Fundamentally, the code calling convention (where the floating-point numbers that are passed among library calls) is done in a way that supports non-FPU libraries (basically, the doubles/floats/quads are stored in regular general-purpose registers), allowing you to mix-and-match code.

hardfp (or armhf), on the other hand, stores these floating-point values in the FPU's registers.

In some specific (usually contrived, unrealistic) cases, you see a benefit using hardfp (calls with many FP arguments). In most cases, the benefit is minimal if present at all.

[BradM]

I mis-read your initial question: basically, if you are porting code (read: compiling everything and not depending on armhf pre-built libraries), all that is needed is to set the compiler flags to support the softfp calling convention: $CC ... -mfloat-abi=softfp ...

See: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

[BlueCheese]

BradM wrote:

In some specific (usually contrived, unrealistic) cases, you see a benefit using hardfp (calls with many FP arguments). In most cases, the benefit is minimal if present at all.

Well, except for the pipeline stall you take when you need to pass any floating point data to functions when using softfp ABI! (https://wiki.debian.org/ArmHardFloatPort/VfpComparison) Most of the benchmarks I have seen show a 20-30% increase in "normal" FPU-intensive programs (not contrived, but do make use of the FPU, like 3D rendering) when using the hardfloat ABI.

However, this doesn't change the fact that NI Linux RT decided to use softfloat ABI for compatability with most of the ARM world...

[ScotSalmon]

We've seen that 20-30% number thrown around too (and even bigger numbers for some tests), so we evaluated switching, but we haven't been able to reproduce that kind of speedup in a real-world test. To be sure, we're not doing 3D rendering on these devices, but we do use the FPU for i.e. PID control, and we don't see that kind of increase for those applications. If you have a cRIO application that does show that kind of improvement, I'd be really interested to know the details. Switching is painful, but we'd consider it again if there was a new and compelling data point to support it since more Linux ARM software is using hardfp lately, and using hardfp would make a cRIO more likely to be binary compatible with, say, RPi2 binaries.

[BFD_LNS]

First of all, thanks everybody for your replies.

I also apologize for the lack of clarity in the first post, I guess I should have better specified what my doubts were. Likely a language issue on my part since I'm not a native English speaker.

And by the way BradM is right: my current job is to port/recompile a (huge!) project where the only ARM architecture option provided in the various makefiles and the like is/was armhf. Nothing is being supplied as precompiled libraries, it is 100% C/C++ source code.

BradM wrote:

The Cortex-A9 in the Zynq devices does have a full IEEE 754-compliant FPU (the VFPv3). This FPU is actually being used for any floating-point opperations (in LabVIEW, in regular code, pretty much everywhere).

Hmm, didn't know about this.

So, basically, assuming I manage to pass the softfp parameter to the compiler, I should be able NOT to break anything, and also generate code that will take advantage of dedicated floating point coprocessor if present (in cRIO 9068 this would mean the VFPv3 you talk about in the previous quote), right?

EDIT maybe not... I'm getting messages like this in the compilation log "error: minigzip uses VFP register arguments, libz.a(gzclose.o) [...]";

I forgot to mention that the toolchain installed right is the gnueabihf one, as suggested by the source code author for cross-compiling to ARM targets; I suppose this means that the compiler is unable to generate code with the softfp switch (as soon as I removed the compilation switch - previously set with "export CFLAGS" - those errors disappear).

That is, assuming the switch works as intended (see above - I guess I'm slightly confused by now :-\)

[BradM · Accepted solution]

BFD_LNS wrote:

...

EDIT maybe not... I'm getting messages like this in the compilation log "error: minigzip uses VFP register arguments, libz.a(gzclose.o) [...]";

I forgot to mention that the toolchain installed right is the gnueabihf one, as suggested by the source code author for cross-compiling to ARM targets; I suppose this means that the compiler is unable to generate code with the softfp switch (as soon as I removed the compilation switch - previously set with "export CFLAGS" - those errors disappear).

That is, assuming the switch works as intended (see above - I guess I'm slightly confused by now :-\)

Basically, the issue is if you're statically linking any libraries compiled with -mfloat-abi=hardfp. If the project is linking libz.a (a collection of one or more .o files from a previous compilation), then it's effectively akin to building some parts of the project with hardfp (the prebuilt static libraries) and some parts with the softfp library. In fact, the linker would complain if you were attempting to link against hardfp shared object libraries as well.

If I were you, I would recommend using the NI toolchain (which includes prebuilt libraries built with softfp) for your build toolchain. I would imagine many projects recommend using a gnueabihf toolchain as it is compatible with the newer arm Debian and Ubuntu distributions for ARM targets. The toolchain can be downloaded from here

EDIT:For clarification, basically the toolchain itself is providing the problematic library.

[BFD_LNS]

Thanks again.

I have already downloaded the NI cross-toolchain you suggested, let's see what happens...

[BFD_LNS]

Marking previous post as "correct answer".

I haven't solved (yet) my issues completely - as I said this project is quite a beast - but at least those compilation errors seem to be gone for good.

[BradM]

Hey, good to hear you've made progress! Be sure to let us know how things turn out (or, of course, if you rin into more issues).