Changes between Version 11 and Version 12 of TBR/UserManual/Floating_Point_Support

Timestamp:

07/12/09 21:32:58 (15 years ago)

Author:

KenPeters

Comment:

TBR/UserManual/Floating_Point_Support

@@ -141 +141 @@
 There are several options at this point:
 
- *  Just live with it and do not use floating point. Many embedded systems can accept this.
+ *  Just live with it, compile and link everything with {{{-msoft-float</code> (or equivalent), and do not use hardware floating point. For many BSPs, this is what will happen by default; the standard RTEMS makefile inclusions for such BSPs will automatically set {{{-msoft-float</code> (or equivalent) for user application builds. 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:
 
@@ -152 +152 @@
 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 have {{{-msoft-float</code> (or equivalent) applied to code used in floating point tasks. Any code that is (or might be) used in non-floating-point tasks will still need to be compiled with {{{-msoft-float</code> (or equivalent). The linker step needs that option also (to bring in the needed software floating point library code, for the RTEMS kernel even if nothing else).
 
+This can be tricky to pull off, since your standard C libraries and so on also need to have been built with {{{-msoft-float</code> (or equivalent), and for some CPUs the GCC documentation indicates that the function calling convention is different for soft- and hard-float, so that mixing the two may not be compatible. But, if your application needs a lot of floating point speed, this is worth a try. Make sure to test thoroughly for incompatibilities and proper context switches, etc.
+
  *  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?