Changes between Version 14 and Version 15 of TBR/UserManual/Floating_Point_Support


Ignore:
Timestamp:
Jul 13, 2009, 7:12:07 PM (10 years ago)
Author:
KenPeters
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • TBR/UserManual/Floating_Point_Support

    v14 v15  
    150150 <strike>#endif</strike>
    151151
    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).
     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).
    153153
    154 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. You may have to disable or override your BSP's automatic setting of {{{-msoft-float</code> (or equivalent) in your makefiles. Make sure to test thoroughly for incompatibilities and proper context switches, etc.
     154 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. You may have to disable or override your BSP's automatic setting of {{{-msoft-float</code> (or equivalent) in your makefiles. Make sure to test thoroughly for incompatibilities and proper context switches, etc.
    155155
     156 *  Have {{{cpu.h</code> set {{{CPU_SOFTWARE_FP TRUE</code>. A quick look through the RTEMS source code indicates that this may work to properly activate the RTEMS library support. However, I have not looked into this thoroughly, and there may be BSP-specific problems with this, such as not enabling the hardware FPU.
    156157 *  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?