Changeset c6c06ae in rtems-docs


Ignore:
Timestamp:
Mar 5, 2020, 11:04:41 AM (4 months ago)
Author:
Sebastian Huber <sebastian.huber@…>
Branches:
5, master
Children:
2424590
Parents:
8bd4e6a
git-author:
Sebastian Huber <sebastian.huber@…> (03/05/20 11:04:41)
git-committer:
Sebastian Huber <sebastian.huber@…> (03/05/20 14:32:38)
Message:

c-user: Document task memory

Close #3835.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • c-user/task_manager.rst

    r8bd4e6a rc6c06ae  
    11.. SPDX-License-Identifier: CC-BY-SA-4.0
    22
     3.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
    34.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
    45
     
    8283compete on its own for system resources.  A task is manifested by the existence
    8384of a task control block (TCB).
     85
     86.. _TaskControlBlock:
    8487
    8588Task Control Block
     
    103106task is restarted, the initial state of the task is restored from the starting
    104107context area in the task's TCB.
     108
     109.. index:: task memory
     110
     111Task Memory
     112-----------
     113
     114The system uses two separate memory areas to manage a task.  One memory area is
     115the :ref:`TaskControlBlock`.  The other memory area is allocated from the stack
     116space or provided by the user and contains
     117
     118* the task stack,
     119
     120* the thread-local storage (:term:`TLS`), and
     121
     122* an optional architecture-specific floating-point context.
     123
     124The size of the thread-local storage is determined at link time.  A
     125user-provided task stack must take the size of the thread-local storage into
     126account.
     127
     128On architectures with a dedicated floating-point context, the application
     129configuration assumes that every task is a floating-point task, but whether or
     130not a task is actually floating-point is determined at runtime during task
     131creation (see :ref:`TaskFloatingPointConsiderations`).  In highly memory
     132constrained systems this potential overestimate of the task stack space can be
     133mitigated through the :ref:`CONFIGURE_MINIMUM_TASK_STACK_SIZE` configuration
     134option and aligned task stack sizes for the tasks.  A user-provided task stack
     135must take the potential floating-point context into account.
    105136
    106137.. index:: task name
     
    272303.. index:: floating point
    273304
     305.. _TaskFloatingPointConsiderations:
     306
    274307Floating Point Considerations
    275308-----------------------------
    276309
     310Please consult the *RTEMS CPU Architecture Supplement* if this section is
     311relevant on your architecture.  On some architectures the floating-point context
     312is contained in the normal task context and this section does not apply.
     313
    277314Creating a task with the ``RTEMS_FLOATING_POINT`` attribute flag results in
    278 additional memory being allocated for the TCB to store the state of the numeric
    279 coprocessor during task switches.  This additional memory is *NOT* allocated for
    280 ``RTEMS_NO_FLOATING_POINT`` tasks. Saving and restoring the context of a
     315additional memory being allocated for the task to store the state of the numeric
     316coprocessor during task switches.  This additional memory is **not** allocated
     317for ``RTEMS_NO_FLOATING_POINT`` tasks. Saving and restoring the context of a
    281318``RTEMS_FLOATING_POINT`` task takes longer than that of a
    282319``RTEMS_NO_FLOATING_POINT`` task because of the relatively large amount of time
    283 required for the numeric coprocessor to save or restore its computational
    284 state.
     320required for the numeric coprocessor to save or restore its computational state.
    285321
    286322Since RTEMS was designed specifically for embedded military applications which
    287323are floating point intensive, the executive is optimized to avoid unnecessarily
    288 saving and restoring the state of the numeric coprocessor.  The state of the
    289 numeric coprocessor is only saved when a ``RTEMS_FLOATING_POINT`` task is
    290 dispatched and that task was not the last task to utilize the coprocessor.  In
    291 a system with only one ``RTEMS_FLOATING_POINT`` task, the state of the numeric
    292 coprocessor will never be saved or restored.
     324saving and restoring the state of the numeric coprocessor.  In uniprocessor
     325configurations, the state of the numeric coprocessor is only saved when a
     326``RTEMS_FLOATING_POINT`` task is dispatched and that task was not the last task
     327to utilize the coprocessor.  In a uniprocessor system with only one
     328``RTEMS_FLOATING_POINT`` task, the state of the numeric coprocessor will never
     329be saved or restored.
    293330
    294331Although the overhead imposed by ``RTEMS_FLOATING_POINT`` tasks is minimal,
     
    300337context switch.  This approach also avoids the allocation of a floating point
    301338context area.  However, if this approach is taken by the application designer,
    302 NO tasks should be created as ``RTEMS_FLOATING_POINT`` tasks.  Otherwise, the
     339**no** tasks should be created as ``RTEMS_FLOATING_POINT`` tasks.  Otherwise, the
    303340floating point context will not be correctly maintained because RTEMS assumes
    304341that the state of the numeric coprocessor will not be altered by
    305 ``RTEMS_NO_FLOATING_POINT`` tasks.
     342``RTEMS_NO_FLOATING_POINT`` tasks.  Some architectures with a dedicated
     343floating-point context raise a processor exception if a task with
     344``RTEMS_NO_FLOATING_POINT`` issues a floating-point instruction, so this
     345approach may not work at all.
    306346
    307347If the supported processor type does not have hardware floating capabilities or
Note: See TracChangeset for help on using the changeset viewer.