Version 13 (modified by KenPeters, on Jul 12, 2009 at 9:35:09 PM) (diff)

/* Escaping Disaster */

Floating Point Support

RTEMS provides software and hardware floating-point support. However, there are some issues to beware of when building RTEMS and when building your applications.

This page has been written from a SPARC BSP perspective, so some things here may not be generally applicable. And it has been initially written by an experienced RTEMS user, but not by an actual RTEMS developer, so this is not definitive and there could be misunderstandings here. Feel free to improve this page.

Task/Thread? Support


The presence or absence of the {{{RTEMS_FLOATING_POINT</code> attribute in the call to {{{rtems_task_create()</code> determines whether or not the task is floating-point enabled.

From the RTEMS C User's Guide:

Creating a task with the RTEMS_FLOATING_POINT attribute flag results in additional memory being allocated for the TCB to store the state of the numeric coprocessor during task switches. This additional memory is NOT allocated for RTEMS_NO_FLOATING_POINT tasks. Saving and restoring the context of a RTEMS_FLOATING_POINT task takes longer than that of a RTEMS_NO_FLOATING_POINT task because of the relatively large amount of time required for the numeric coprocessor to save or restore its computational state.


If the supported processor type does not have hardware floating capabilities or a standard numeric coprocessor, RTEMS will not provide built-in support for hardware floating point on that processor. In this case, all tasks are considered RTEMS_NO_FLOATING_POINT whether created as RTEMS_FLOATING_POINT or RTEMS_NO_FLOATING_POINT tasks. A floating point emulation software library must be utilized for floating point operations.

On some processors, it is possible to disable the floating point unit dynamically. If this capability is supported by the target processor, then RTEMS will utilize this capability to enable the floating point unit only for tasks which are created with the RTEMS_FLOATING_POINT attribute. The consequence of a RTEMS_NO_FLOATING_POINT task attempting to access the floating point unit is CPU dependent but will generally result in an exception condition.

RTEMS Init Task

The RTEMS Init task is not floating point by default (has {{{RTEMS_DEFAULT_ATTRIBUTES</code>). It can be made floating point by #defining {{{ CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT</code> before including {{{confdefs.h</code>


All POSIX threads are floating point, if either software or hardware floating point is defined to be available at the time of compilation of the RTEMS libraries (see more below). From pthreadcreate.c:


  • Currently all POSIX threads are floating point if the hardware
  • supports it. */

is_fp = true;


is_fp = false;


{{{is_fp</code> is then used in a call to {{{_Thread_Initialize</code>, similar to the ITRON code segment below.


All ITRON tasks are floating point, if either software or hardware floating point is defined to be available at the time of compilation of the RTEMS libraries (see more below). From cre_tsk.c:

status = _Thread_Initialize(

&_ITRON_Task_Information, the_thread, NULL, pk_ctsk->stksz,


TRUE, /* XXX - All tasks FP (if the HW supports it) for now */




core_priority, TRUE, /* preemptible */ THREAD_CPU_BUDGET_ALGORITHM_EXHAUST_TIMESLICE, NULL, /* no budget algorithm callout */ 0, name


RTEMS Library Support

Throughout the RTEMS kernel, actions are taken to support floating point, if either software or hardware floating point is defined to be available at the time of compilation of the RTEMS libraries. For example, from {{{threaddispatch.c</code> (edited here for simplification):

    if ( executing->fp_context != NULL )
      _Context_Save_fp( &executing->fp_context );

    _Context_Switch( &executing->Registers, &heir->Registers );

    if ( executing->fp_context != NULL )
      _Context_Restore_fp( &executing->fp_context );

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.

cpukit/BSP Support

Technically I should probably call this "cpukit support" rather than "BSP support." However, since often someone looking into a board port needs to at least look at the CPU support, and possibly adjust it, I am considering the cpukit as part of the "greater BSP".

The definitions controlling floating point support for the RTEMS kernel are found in a CPU-dependent header file in the RTEMS source tree, typically {{{cpukit/score/cpu/<cpu name>/rtems/score/cpu.h</code>.

For example, for the {{{sparc</code> CPU:

 *  Does the CPU have hardware floating point?
 *  If TRUE, then the FLOATING_POINT task attribute is supported.
 *  If FALSE, then the FLOATING_POINT task attribute is ignored.

#if ( SPARC_HAS_FPU == 1 )

For more details about this precompiler definition and others related to floating point specializations, read the comments in any {{{cpu.h</code> file, and (even more informative) the file in the RTEMS source tree {{{doc/porting/taskcontext.t</code>, which gets built into a nice document somewhere if you build the docs, but is readable as-is.

Most CPUs are really a CPU family, some members of which have hardware floating point and some do not. Thus, in the example above, the definition of SPARC_HAS_FPU</code> comes from another header file that specifies the different members of the CPU family, typically {{{cpukit/score/cpu/<cpu name>/rtems/score/<cpu name>.h</code>. For eample, for the {{{sparc

#if defined(_SOFT_FLOAT) #define SPARC_HAS_FPU 0 #else #define SPARC_HAS_FPU 1 #endif

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 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

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.

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.

Disaster Strikes

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.

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 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, 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:

<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 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. 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.

  • 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?