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.
Since RTEMS was designed specifically for embedded military applications
which are floating point intensive, the executive is optimized to avoid
unnecessarily saving and restoring the state of the numeric coprocessor.
The state of the numeric coprocessor is only saved when a
RTEMS_FLOATING_POINT
task is dispatched and that task was
not the last task to utilize the coprocessor. In a system with only one
RTEMS_FLOATING_POINT
task, the state of the numeric
coprocessor will never be saved or restored.
Although the overhead imposed by RTEMS_FLOATING_POINT
tasks
is minimal, some applications may wish to completely avoid the overhead
associated with RTEMS_FLOATING_POINT
tasks and still
utilize a numeric coprocessor. By preventing a task from being preempted
while performing a sequence of floating point operations, a
RTEMS_NO_FLOATING_POINT
task can utilize the numeric
coprocessor without incurring the overhead of a
RTEMS_FLOATING_POINT
context switch. This approach also
avoids the allocation of a floating point context area. However, if this
approach is taken by the application designer, NO tasks should be created
as RTEMS_FLOATING_POINT
tasks. Otherwise, the floating
point context will not be correctly maintained because RTEMS assumes that
the state of the numeric coprocessor will not be altered by
RTEMS_NO_FLOATING_POINT
tasks.
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.
Copyright © 1988-2008 OAR Corporation