C++ compiler version

[ernestoa]

Checking the version of the C++ compiler for NI Linux Real-time I see that it currently uses gcc 4.7.2. This is a pretty old version (released in Sept 2012) that only provides "experimental" support for C++11 features. Are there any plans to upgrade the compiler version at some point?

Also, how difficult would it be to switch to my own cross-compilation chain for the intel models, for example using clang instead of gcc?

[BradM]

Hi ernestoa,

Regarding the question of how difficult it would be to use a different toolchain, since we're talking about the x86_64 controllers (I'm guessing that's what you meant by saying "intel models"), I regularly build x86_64 software on my development machine:

$ gcc --version
gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I have yet to find a situation where software that I've built with my native development machine's toolchain has not been able to run on a x64 controller.

Now, just because it works for me (and note that it's not a clang-based compiler), doesn't mean that you'll have no issues to contend with.

tl;dr is "try it out, let us know what you find!"

(and, honestly, that goes for Zynq controllers as well, but it's a bit more of a precarious situation there since you need to find or build a toolchain configured for softfp)

[Deborah_B]

Hi ernestoa,

Regarding updates to GCC, for every major release (like NIWeek 2017) we aim to update the kernel as well as use an upstream version of the Open Embedded framework for building our distribution. We usually use whatever GCC version that Open Embedded release requires.

For the 2017 release we plan to update to GCC version 5.3.

[metux]

---

@Deborah_B wrote:

Regarding updates to GCC, for every major release (like NIWeek 2017) we aim to update the kernel as well as use an upstream version of the Open Embedded framework for building our distribution. 

So, can we expect kernel-4.10, barebox-2017.03, glibc-2.25 ?

Actually, I'd be happy with having all kernel/driver sources (including configs + dts) for the crio-9064 (and the corresponding IO modules), so I can port it to recent mainline myself (I'll probably need to do it myself anyways, as I need the ADCs as IIO devices).

Note that proprietary drivers are completely useless for us - so we just wont buy w/ free drivers.

By the way: with the proper specs avaible, developing proper kernel drivers (and bringing them to mainline) most likely costs way below 10 units. My client certainly would buy way more than 10 units (once there are free drivers). Looks like a trivial calculation.

[metux]

---

(and, honestly, that goes for Zynq controllers as well, but it's a bit more of a precarious situation there since you need to find or build a toolchain configured for softfp)

---

softfp ? seriously ?

Then what does the cpu have an fpu (actually, multiple, iirc) for, if it's not used ?

IOW: anything that's fops-bound (like signal analysis, like my client is doing) is going to be slohohohw w/ softfp.

[gratian.crisan]

'softfp' refers to the calling convention not to the use of FPU. See the gcc documentation quoted below for an explanation of the difference between 'soft', 'softfp', and 'hardfp'.

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

-mfloat-abi=name

Specifies which floating-point ABI to use. Permissible values are: ‘soft’, ‘softfp’ and ‘hard’.

Specifying ‘soft’ causes GCC to generate output containing library calls for floating-point operations. ‘softfp’ allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions. ‘hard’ allows generation of floating-point instructions and uses FPU-specific calling conventions.

The default depends on the specific target configuration. Note that the hard-float and soft-float ABIs are not link-compatible; you must compile your entire program with the same ABI, and link with a compatible set of libraries.

[metux]

@gratian.crisan wrote:

Specifying ‘soft’ causes GCC to generate output containing library calls for floating-point operations. ‘softfp’ allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions.

Well, it uses fpops inside functions, but has to keep the old integer-based calling convention. Thus must translate between native float and int registers - add at least 20 cycles per parameter per call - cant use float registers for parameter passing and so has to use stack sooner. So, softfp uses the fpops only partially.

You could work around explicitly for some hot pathes (possibly replace lib functions by local or even inlinable code) and specify other calling conventions via attributes, etc - but that's time consuming and expert-only.

As my client (who'm I'm evaluating the crio for) has very fops-bound applications, so we'll certainly use hardfloat and several fine tunings.