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


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

Legend:

Unmodified
Added
Removed
Modified
  • TBR/UserManual/Floating_Point_Support

    v8 v9  
    128128
    129129In general, a GCC cross-compiler has command line options for specifying what member of a CPU family for which to specialize the object code, as well as command line options to enable use of specific CPU features/accessories, such as a hardware FPU. Typically, the specific CPU has an option like {{{-mcpu=<cpu_type></code> with several supported CPU types. Also typically, there is an option such as {{{-msoft-float</code> to tell GCC to use software floating point subroutines (generally in some compiler-provided library) rather than generating hardware FPU instructions and using hardware FPU registers.
     130=  Disaster Strikes  =
    130131
    131 '''This raises a problem.''' Unfortunately, GCC versions since 3.4 or so and up to at least 4.3.3 (I think) will sometimes use registers in a hardware floating point unit as temporary storage, ''even for integer variables.'' There is some indication that maybe using an optimization level less than 3 avoids this, though it is not obvious that any of the documented level 3 optimizations have anything to do with this, and that might be CPU-dependent.
    132132
    133 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!
     133'''This raises a problem.''' Unfortunately, GCC versions since 3.4 or so and up to at least 4.3.3 (I think) will sometimes use registers in a hardware floating point unit as temporary storage, ''even for integer variables.'' There is some indication that maybe using an optimization level less than 3 avoids this, though it is not obvious that any of the documented level 3 optimizations have anything to do with this, and that might be CPU-dependent. And there is no GCC-provided option to specifically tell the compiler not to use FPU registers for integer variables, short of the {{{-msoft-float</code> (or equivalent) telling the compiler that no FPU exists at all.
     134
     135From 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.
     136
     137But 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).