| 125 | |
| 126 | |
| 127 | This is specific to GCC cross-compilers, since those are the compilers generally expected for RTEMS, and are the ones I have experience using with RTEMS. |
| 128 | |
| 129 | In 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 | |
| 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. |
| 132 | |
| 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! |