Changes between Version 9 and Version 10 of TBR/UserManual/Floating_Point_Support


Ignore:
Timestamp:
Jul 12, 2009, 6:48:35 AM (10 years ago)
Author:
Kptrs
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • TBR/UserManual/Floating_Point_Support

    v9 v10  
    8585}}}
    8686If floating point is defined as available, and if the executing task has a floating point context, then that context will be saved and restored in context switches. But where do these definitions of floating point support come from? Read on.
    87 = BSP/cpukit Support =
     87= cpukit/BSP Support =
    8888
    8989
     
    121121In theory, the determination of whether the CPU has a hardware FPU should be made based on knowledge of which CPU is involved. In practice, the determination is commonly made based on a definition set by the compiler based on compiler command line arguments such as -msoft-float (in the example above, if that compiler option is provided, then the SPARC cross-compiler automatically sets the preprocessor definition {{{_SOFT_FLOAT</code>). '''<big>This is often a mistake,</big>''' because there are other reasons for telling the compiler to use software floating point besides absence of a hardware FPU (see below).
    122122
    123 In addition to the preprocessor definitions for floating point settings, the BSP must provide the actual functions for various operations such as saving and restoring the floating point context, since they are CPU dependent. These are typically found in {{{cpukit/score/cpu/<cpu name>/cpu_asm.S</code>.
     123In addition to the preprocessor definitions for floating point settings, the cpukit/BSP must provide the actual functions for various operations such as saving and restoring the floating point context, since they are CPU dependent. These are typically found in {{{cpukit/score/cpu/<cpu name>/cpu_asm.S</code>.
    124124= Compiler Support =
    125125
     
    135135From the perspective of the RTEMS kernel, this means that even tasks that are not floating point might try to access hardware FPU registers thanks to compiler tricks. Even worse, the kernel code itself (which does not use floating point) might be "unknowingly" compiled to use floating point registers! Rather than have the kernel "FPU-safe", which would be painful and less portable, the RTEMS build process uses {{{-msoft-float</code> (or equivalent) so that when compiling the RTEMS libraries, the compiler is specifically instructed not to emit FPU instructions or use FPU registers at all.
    136136
    137 But now, any BSP/cpukit that determines whether the CPU has hardware floating point by using a preprocessor definition automatically set by the compiler as a result of {{{-msoft-float</code> (or equivalent), as many of them currently do (RTEMS 4.8.1), will because of this completely disable the RTEMS library floating point support. So a user application that would like to use floating point will not be able to - RTEMS will not save the floating point context, etc. In fact, RTEMS will probably not enable the floating point unit, likely resulting in "exception conditions" as noted above. All user code in this condition must also be compiled and linked with {{{-msoft-float</code> (or equivalent).
     137But now, any cpukit/BSP that determines whether the CPU has hardware floating point by using a preprocessor definition automatically set by the compiler as a result of {{{-msoft-float</code> (or equivalent), as many of them currently do (RTEMS 4.8.1), will because of this completely disable the RTEMS library floating point support. So a user application that would like to use floating point will not be able to - RTEMS will not save the floating point context, etc. In fact, RTEMS will probably not enable the floating point unit, likely resulting in "exception conditions" as noted above. All user code in this condition must also be compiled and linked with {{{-msoft-float</code> (or equivalent).
     138= Escaping Disaster =
     139
     140
     141There are several options at this point:
     142
     143 *  Just live with it and do not use floating point. Many embedded systems can accept this.
     144 *  Do not base the setting of {{{CPU_HARDWARE_FP</code> ultimately on a compiler definition based on {{{-msoft-float</code> (or equivalent). For example, the {{{cpukit/score/cpu/sparc/rtems/score/sparc.h</code> code shown above could be changed to:
     145
     146 <strike>#if defined(_SOFT_FLOAT)
     147 #define SPARC_HAS_FPU 0
     148 #else</strike>
     149 #define SPARC_HAS_FPU 1
     150 <strike>#endif</strike>
     151
     152This would result in the RTEMS compilation not generating any floating point usage internally (since {{{-msoft-float</code> (or equivalent) is still set), but because {{{CPU_HARDWARE_FP</code> will be set TRUE, the RTEMS kernel will be built containing the code needed to support floating point tasks in user applications. The user applications do not need to be built with {{{-msoft-float</code> (or equivalent).
     153
     154 *  Get GCC to provide a specific named optimization option to enable/disable the storage of integer variables in FPU registers. Then instead of deleting all hardware floating point, we could allow it but only for actual floating point activities. Any GCC developers out there?