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

On Tuesday, October 29, 2013 7:11:39 AM UTC-7, dlewin555 wrote:
>
>
>  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 <[email protected] <javascript:>>
>
>> 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
>>  
>> Le lundi 28 octobre 2013 15:44:08 UTC+1, dlewin555 a écrit :
>>
>>> 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
>>>  
>>>
>>> Le samedi 26 octobre 2013 01:27:24 UTC+2, [email protected] a écrit :
>>>
>>>> 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
>>>>
>>>  -- 
>> 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 
>> [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to