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

RTEMS API

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>

POSIX API

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

#if ( CPU_HARDWARE_FP == TRUE )

( CPU_SOFTWARE_FP == TRUE )

is_fp = true;

#else

is_fp = false;

#endif

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

ITRON API

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,

#if ( CPU_HARDWARE_FP == TRUE )

( CPU_SOFTWARE_FP == TRUE )

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

#else

FALSE,

#endif

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 ( CPU_HARDWARE_FP == TRUE ) || ( CPU_SOFTWARE_FP == TRUE )
    if ( executing->fp_context != NULL )
      _Context_Save_fp( &executing->fp_context );
 #endif

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

 #if ( CPU_HARDWARE_FP == TRUE ) || ( CPU_SOFTWARE_FP == TRUE )
    if ( executing->fp_context != NULL )
      _Context_Restore_fp( &executing->fp_context );
 #endif

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.

BSP Support

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 )
#define CPU_HARDWARE_FP     TRUE
#else
#define CPU_HARDWARE_FP     FALSE
#endif
#define CPU_SOFTWARE_FP     FALSE

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

Compiler Support