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

Timestamp:

07/12/09 06:48:35 (15 years ago)

Author:

Kptrs

Comment:

TBR/UserManual/Floating_Point_Support

@@ -85 +85 @@
 }}}
 If 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.
-= BSP/cpukit Support =
+= cpukit/BSP Support =
 
 
@@ -121 +121 @@
 In 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).
 
-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>.
+In 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>.
 = Compiler Support =
 
@@ -135 +135 @@
 From 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.
 
-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).
+But 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).
+= Escaping Disaster =
+
+
+There are several options at this point:
+
+ *  Just live with it and do not use floating point. Many embedded systems can accept this.
+ *  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:
+
+ <strike>#if defined(_SOFT_FLOAT)
+ #define SPARC_HAS_FPU 0
+ #else</strike>
+ #define SPARC_HAS_FPU 1
+ <strike>#endif</strike>
+
+This 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).
+
+ *  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?