Does Angstrom use hard float ?

[tee....@gmail.com]

Hello,

After trying to cross-compile with the hard float library without success, I finally use the soft float library and it work.

I would like to check if the cause is really the hard float.

I'm using the default Angstrom distribution. Does it use soft float and how to check that ?

If Angstrom distribution doesn't use hard float, why ?

Regards

[dlewin555]

As I think this a sane question (ie : everyone should ask himself/herself this ) I answer you that :

 

- the BBB is based on the AM335x

- This last is itself is based on Cortex A8

 

Therefore if you dig into the A8 arm documentation CortexA_ProgGuide.pdf  that you can easily download from Arm website ( free account is required)

you'll see :

 

 

If your target platform supports hardware floating-point or NEON, specify this to ensure that
the compiler can make use of these instructions. For a Cortex-A5 target, you would specify
–mfpu=neon-vfpv4.
-mfloat-abi=<name>
This option specifies the floating-point ABI to use. Values for <name> are:
soft  causes GCC to generate code containing calls to the software floating-point
library for floating-point operations.
softfp  enables GCC to generate code containing hardware floating-point instructions,
but still uses the software floating-point linkage.

 

....

 

hard  enables GCC to generate code containing hardware floating-point instructions
and uses FPU-specific hardware floating-point linkage.
The default depends on the target configuration. You must compile your entire program with the
same ABI, and link with a compatible set of libraries.
Table 19-1 shows a few examples of code generation for floating-point operations.
19.1.5 armcc optimization options
The armcc compiler enables you to compile your C and C++ code. It is an optimizing compiler
with a range of command-line options to enable you to control the level of optimization.
The command line option gives a choice of optimization levels, as follows:
• -Ospace. This option instructs the compiler to perform optimizations to reduce image size
at the expense of a possible increase in execution time.
• -Otime. This option instructs the compiler to perform optimizations to reduce execution
time at the expense of a possible increase in image size.
• -O0. Turns off most optimizations. It gives the best possible debug view and the lowest
level of optimization.
• -O1. Removes unused inline functions and unused static functions. Turns off optimizations
that seriously degrade the debug view. If used with --debug, this option gives a satisfactory
debug view with good code density.
• -O2 (default). High optimization. If used with --debug, the debug view might be less
satisfactory because the mapping of object code to source code is not always clear.
• -O3. performs the same optimizations as -O2 however the balance between space and time
optimizations in the generated code is more heavily weighted towards space or time
compared with -O2. That is:
— -O3 -Otime aims to produce faster code than -O2 -Otime, at the risk of
increasing your image size
— -O3 -Ospace aims to produce smaller code than -O2 -Ospace, but performance might
be degraded.
Table 19-1 Floating-point code generation
-mfpu -mfloat-abi Resultant code
Any value soft Floating-point emulation using software floating-point library
vfpv3 softfp VFPv3 floating-point code
vfpv3-d16 softfp VFPv3 floating-point code
neon hard VFPv3 and Advanced SIMD code, where the floating-point and
SIMD types use the hardware FP registers 

 

So in clear, as far as you use neon option (which is hardwired in the BBB)  you need to define the hardfloat as well .

 

Hope this will help

[tee....@gmail.com]

Thanks dlewin555.

I understand that it's possible to use hard float. Some Android or arm Ubuntu version are using it.

But for the default Angstrom (this the BeagleBone Black is delivered with). How can we check the hard float is not used ?
I guess I could rebuild Anstrong using hard float but I am wondering why the default build doesn't use it ?

I trust the Angstrom builder. It should have better knowledge than me. So if he preferred not to use the hard float it should have a good reason and I would like to know it.

Regards

[David Lewin]

The computation may be done either by floating-point hardware or in software ( based on integer arithmetic ). Doing it in hardware is much faster, but many microcontrollers don't have floating-point hardware like the Sitara here. In that case you may either avoid using floating point (usually the best option) or rely on an implementation in software, which will be part of the C library. In some families of controllers, for example ARM, the floating-point hardware is present in some models of the family but not in others, so gcc for these families supports both. Have you ever thought that softfloat could be used to be sure to"bypass" the analysis of hardwired math (Neon type) unit for each ? this could be done for historical reasons also: If I were about porting to a new board, softfloat allows me to be sure that my board will accept it.

2013/10/29 <tee....@gmail.com>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/hZ39EQr_tyk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dean Franks]

I believe there is also an issue that using hard float makes context switches much more expensive.  When hardfloat is in use, all the additional registers (possibly including wide vector registers) have to be saved and restore on every context switch regardless of whether the running application is using floating point or not.  I have not looked at the Sitara but some processors have hardware assistance for this context switching that reduces the cost but with the exception of shadow register sets used in hard RTOS systems there is always a memory bandwidth cost.  This context switching cost slows the entire system down.

Our application is floating point arithmetic intensive so hard float is the better option, but I suspect there are many common workloads that do better under softfloat.

Dean

[dlewin555]

Interesting.Nevertheless,the only reference to the fp operation context switch cost I've found is related to the VFP which we don't use with the Sitara under Angstrom.

For some eventual interested people :

In addition to saving and restoring integer registers, the kernel may also need to perform saving and restoring of VFP registers on a context switch. To avoid wasting cycles, this is done only when an application actually used VFP. As the VFP initialization code leaves VFP disabled, the first time a thread actually tries to access the floating-point hardware, an undefined exception occurs. The kernel function which handles this, sees that VFP is disabled and that a new thread
wishes to use VFP. It saves the current VFP state and restores the state for the new thread

[Robert Nelson]

On Wed, Oct 30, 2013 at 3:24 AM, dlewin555 <dlew...@gmail.com> wrote:

Interesting.Nevertheless,the only reference to the fp operation context switch cost I've found is related to the VFP which we don't use with the Sitara under Angstrom.

Wow, way wrong...  Angstrom has "always" utilized the floating point unit on these parts.  Even way before the "armhf" versions of ubuntu/debian and fedora came out.  The only thing that hasn't changed yet, is to use the same armhf linker those guys use (/lib/ld-linux-armhf.so.3).

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[dlewin555]

I think that it can be -at worst -ambiguous, not so wrong: let me resay it :

"Nevertheless,the only reference to the fp operation context switch cost I've found is related to the VFP which we don't use ONLY with the Sitara under Angstrom" as we are talking about hardfloat and softfloat , vfpv3 is not used as is ( read soft/softfp) . when hard for gcc option is used this implies neon : then your code will be VFP3 and SIMD codes.
Hope this is clearer.

[Robert Nelson]

On Wed, Oct 30, 2013 at 9:42 AM, dlewin555 <dlew...@gmail.com> wrote:
> I think that it can be -at worst -ambiguous, not so wrong: let me resay it :
>
> "Nevertheless,the only reference to the fp operation context switch cost
> I've found is related to the VFP which we don't use ONLY with the Sitara
> under Angstrom" as we are talking about hardfloat and softfloat , vfpv3 is
> not used as is ( read soft/softfp) . when hard for gcc option is used this
> implies neon : then your code will be VFP3 and SIMD codes.
> Hope this is clearer.

"hard" with gcc doesn't actually imply neon either..

'armhf' in ubuntu/debian is actually built for "--with-fpu=vfpv3-d16
--with-float=hard --with-mode=thumb" which allows "non-neon"
implementations (such as the tegra2 and one marvel chip) to use it.

Whereas Angstrom for the beagle has always used the full floating
point resources as the omap/sitara parts from TI have the full 32
register vfpv3 with neon implementation..

[dlewin555]

Maybe is that because you have missed the start of the discussion, where I've said :

(...)Therefore if you dig into the A8 arm documentation CortexA_ProgGuide.pdf  that you can easily download from Arm website ( free account is required)

as the question was about Angstrom only, and I was refering to the Arm documentation you will find :

 

Floating-point code generation

 

neon + hard = VFPv3 and Advanced SIMD code, where the floating-point and

SIMD types use the hardware FP registers

From my understanding Neon and vfp have a tight relationship, they even use the same registers. Anyway  the compiler
is free to use any NEON or VFPv3 registers for floating-point values.

Nevertheless, I could eventually misunderstanding the documentation, please then let me know.

[tee....@gmail.com]

Finally it's become darker for me.

Robert, did you mean that Angstrom distribution use hard float but not the armhf that we have in ubuntu ? This is why I can't run software compiled with the ubuntu arm-linux-gnueabihf- tool chain ?

In this case I should better use the Android toolchain (even is less easy to use than the ubuntu packet) or does the ubuntu arm-linux-gnueabi toolchain is acceptable ?.

Regards

[Robert Nelson]

On Wed, Oct 30, 2013 at 5:15 PM, <tee....@gmail.com> wrote:
> Finally it's become darker for me.
>
> Robert, did you mean that Angstrom distribution use hard float but not the
> armhf that we have in ubuntu ? This is why I can't run software compiled
> with the ubuntu arm-linux-gnueabihf- tool chain ?

Correct, as Angstrom doesn't have the new hard float linker..

>
> In this case I should better use the Android toolchain (even is less easy to
> use than the ubuntu packet) or does the ubuntu arm-linux-gnueabi toolchain
> is acceptable ?.

Actually just use Angstrom's sdk gcc, it's hardfp enabled, and matches
the libraries in Angstrom.
http://www.angstrom-distribution.org/toolchains/

[Grissiom]

On Thu, Oct 31, 2013 at 8:02 AM, Robert Nelson <robert...@gmail.com> wrote:

On Wed, Oct 30, 2013 at 5:15 PM,  <tee....@gmail.com> wrote:
> Finally it's become darker for me.
>
> Robert, did you mean that Angstrom distribution use hard float but not the
> armhf that we have in ubuntu ? This is why I can't run software compiled
> with the ubuntu arm-linux-gnueabihf- tool chain ?

Correct, as Angstrom doesn't have the new hard float linker..

Are there any technical difficulties to use a hard float linker? And if there is no hard linker in system, what's the effect of the system?

--
Cheers,
Grissiom

[Markus Reichl]

After trying to cross-compile with the hard float library without success, I finally use the soft float library and it work.

Hi tee,

on the BBB in /lib I just did:

ln -s ld-linux.so.3 ld-linux-armhf.so.3

Now my cross compiled binaries work on BBB.

I used crosstool-ng 1.19 for generating the cross-toolchain on my PC (opensuse 12.2).
I attach the .config for crosstool-ng.

--
Markus

[David Lewin]

Of course it works. There is even the same from the OE environment -and I mean : from the official repo - , here is set for my angstrom-SDK :

export CC="arm-angstrom-linux-gnueabi-gcc  -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/usr/local/oecore-i686/sysroots/cortexa8hf-vfp-neon-angstrom-linux-gnueabi"

Here are the options that pointed out from the Arm Cortex Documentation.

Which works nicely on my  board.

David

2013/10/31 Markus Reichl <rei...@t-online.de>