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 > Le mardi 29 octobre 2013 19:01:15 UTC+1, Dean Franks a écrit : > > 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 <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 >>> >>> 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, tee....@gmail.com 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 >>> beagleboard...@googlegroups.com. >>> 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
