summaryrefslogtreecommitdiffstats
path: root/cpu-supplement
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--cpu-supplement/index.rst1
-rw-r--r--cpu-supplement/sparc.rst101
2 files changed, 61 insertions, 41 deletions
diff --git a/cpu-supplement/index.rst b/cpu-supplement/index.rst
index 951d6b7..733ffcc 100644
--- a/cpu-supplement/index.rst
+++ b/cpu-supplement/index.rst
@@ -24,6 +24,7 @@ RTEMS CPU Architecture Supplement (|version|).
preface
port
+ aarch64
arm
atmel_avr
blackfin
diff --git a/cpu-supplement/sparc.rst b/cpu-supplement/sparc.rst
index f3851dc..11b63d9 100644
--- a/cpu-supplement/sparc.rst
+++ b/cpu-supplement/sparc.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: CC-BY-SA-4.0
+.. Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR)
SPARC Specific Information
@@ -25,7 +26,7 @@ to that processor.
**SPARC Architecture Documents**
For information on the SPARC architecture, refer to the following documents
-available from SPARC International, Inc. (http://www.sparc.com):
+available from SPARC International, Inc. (`<https://sparc.org/>`_):
- SPARC Standard Version 7.
@@ -285,11 +286,11 @@ Special Registers
~~~~~~~~~~~~~~~~~
The SPARC architecture includes two special registers which are critical to the
-programming model: the Processor State Register (psr) and the Window Invalid
-Mask (wim). The psr contains the condition codes, processor interrupt level,
+programming model: the Processor State Register (``PSR``) and the Window Invalid
+Mask (``WIM``). The ``PSR`` contains the condition codes, processor interrupt level,
trap enable bit, supervisor mode and previous supervisor mode bits, version
information, floating point unit and coprocessor enable bits, and the current
-window pointer (cwp). The cwp field of the psr and wim register are used to
+window pointer (``CWP``). The ``CWP`` field of the ``PSR`` and ``WIM`` register are used to
manage the register windows in the SPARC architecture. The register windows
are discussed in more detail below.
@@ -330,15 +331,15 @@ underflow condition must be handled in software by a trap handler. The window
underflow trap handler is responsible for reloading the contents of the
register window requested by the restore instruction from the program stack.
-The Window Invalid Mask (wim) and the Current Window Pointer (cwp) field in the
-psr are used in conjunction to manage the finite set of register windows and
-detect the window overflow and underflow conditions. The cwp contains the
+The Window Invalid Mask (``WIM``) and the Current Window Pointer (``CWP``) field in the
+``PSR`` are used in conjunction to manage the finite set of register windows and
+detect the window overflow and underflow conditions. The ``CWP`` contains the
index of the register window currently in use. The save instruction decrements
-the cwp modulo the number of register windows. Similarly, the restore
-instruction increments the cwp modulo the number of register windows. Each bit
-in the wim represents represents whether a register window contains valid
+the ``CWP`` modulo the number of register windows. Similarly, the restore
+instruction increments the ``CWP`` modulo the number of register windows. Each bit
+in the ``WIM`` represents represents whether a register window contains valid
information. The value of 0 indicates the register window is valid and 1
-indicates it is invalid. When a save instruction causes the cwp to point to a
+indicates it is invalid. When a save instruction causes the ``CWP`` to point to a
register window which is marked as invalid, a window overflow condition
results. Conversely, the restore instruction may result in a window underflow
condition.
@@ -346,8 +347,8 @@ condition.
Other than the assumption that a register window is always available for trap
(i.e. interrupt) handlers, the SPARC architecture places no limits on the
number of register windows simultaneously marked as invalid (i.e. number of
-bits set in the wim). However, RTEMS assumes that only one register window is
-marked invalid at a time (i.e. only one bit set in the wim). This makes the
+bits set in the ``WIM``). However, RTEMS assumes that only one register window is
+marked invalid at a time (i.e. only one bit set in the ``WIM``). This makes the
maximum possible number of register windows available to the user while still
meeting the requirement that window overflow and underflow conditions can be
detected.
@@ -356,7 +357,7 @@ The window overflow and window underflow trap handlers are a critical part of
the run-time environment for a SPARC application. The SPARC architectural
specification allows for the number of register windows to be any power of two
less than or equal to 32. The most common choice for SPARC implementations
-appears to be 8 register windows. This results in the cwp ranging in value
+appears to be 8 register windows. This results in the ``CWP`` ranging in value
from 0 to 7 on most implementations.
The second complicating factor is the sharing of registers between adjacent
@@ -563,35 +564,52 @@ state changes occur in the processor itself. The return address reported by
the processor for synchronous traps is the instruction which caused the trap
and the following instruction.
+Trap Table
+----------
+
+A SPARC processor uses a trap table to execute the trap handler associated with
+a trap. The trap table location is defined by the Trap Base Register
+(``TBR``). The trap table has 256 entries. Each entry has space for four
+instructions (16 bytes). RTEMS uses a statically initialized trap table. The
+start address of the trap table is associated with the ``trap_table`` global
+symbol. The first action of the system initialization (entry points ``_start``
+and ``hard_reset``) is to set the ``TBR`` to ``trap_table``. The interrupt
+traps (trap numbers 16 to 31) are connected with the RTEMS interrupt handling.
+Some traps are connected to standard services defined by the SPARC
+architecture, for example the window overflow, underflow, and flush handling.
+Most traps are connected to a fatal error handler. The fatal error trap
+handler saves the processor context to an exception frame and starts the system
+termination procedure.
+
Vectoring of Interrupt Handler
------------------------------
-Upon receipt of an interrupt the SPARC automatically performs the following
-actions:
+Upon receipt of an interrupt a SPARC processor automatically performs the
+following actions:
-- disables traps (sets the ET bit of the psr to 0),
+- disables traps (sets the ``PSR.ET`` bit to 0 in the ``PSR``),
-- the S bit of the psr is copied into the Previous Supervisor Mode (PS) bit of
- the psr,
+- the ``PSR.S`` bit is copied into the Previous Supervisor Mode (``PSR.PS``)
+ bit in the ``PSR``,
-- the cwp is decremented by one (modulo the number of register windows) to
+- the ``CWP`` is decremented by one (modulo the number of register windows) to
activate a trap window,
-- the PC and nPC are loaded into local register 1 and 2 (l0 and l1),
+- the PC and nPC are loaded into local register 1 and 2 (``%l0`` and ``%l1``),
-- the trap type (tt) field of the Trap Base Register (TBR) is set to the
- appropriate value, and
+- the trap type (``tt``) field of the Trap Base Register (``TBR``) is set to
+ the appropriate value, and
- if the trap is not a reset, then the PC is written with the contents of the
- TBR and the nPC is written with TBR + 4. If the trap is a reset, then the PC
- is set to zero and the nPC is set to 4.
+ ``TBR`` and the nPC is written with ``TBR`` + 4. If the trap is a reset,
+ then the PC is set to zero and the nPC is set to 4.
Trap processing on the SPARC has two features which are noticeably different
-than interrupt processing on other architectures. First, the value of psr
+than interrupt processing on other architectures. First, the value of ``PSR``
register in effect immediately before the trap occurred is not explicitly
saved. Instead only reversible alterations are made to it. Second, the
-Processor Interrupt Level (pil) is not set to correspond to that of the
-interrupt being processed. When a trap occurs, ALL subsequent traps are
+Processor Interrupt Level (``PSR.PIL``) is not set to correspond to that of the
+interrupt being processed. When a trap occurs, **all** subsequent traps are
disabled. In order to safely invoke a subroutine during trap handling, traps
must be enabled to allow for the possibility of register window overflow and
underflow traps.
@@ -698,15 +716,16 @@ Interrupt Stack
The SPARC architecture does not provide for a dedicated interrupt stack. Thus
by default, trap handlers would execute on the stack of the RTEMS task which
they interrupted. This artificially inflates the stack requirements for each
-task since EVERY task stack would have to include enough space to account for
-the worst case interrupt stack requirements in addition to it's own worst case
-usage. RTEMS addresses this problem on the SPARC by providing a dedicated
+task since **every** task stack would have to include enough space to account
+for the worst case interrupt stack requirements in addition to it's own worst
+case usage. RTEMS addresses this problem on the SPARC by providing a dedicated
interrupt stack managed by software.
-During system initialization, RTEMS allocates the interrupt stack from the
-Workspace Area. The amount of memory allocated for the interrupt stack is
-determined by the interrupt_stack_size field in the CPU Configuration Table.
-As part of processing a non-nested interrupt, RTEMS will switch to the
+The interrupt stack is statically allocated by RTEMS. There is one interrupt
+stack for each configured processor. The interrupt stack is used to initialize
+the system. The amount of memory allocated for the interrupt stack is
+determined by the ``CONFIGURE_INTERRUPT_STACK_SIZE`` application configuration
+option. As part of processing a non-nested interrupt, RTEMS will switch to the
interrupt stack before invoking the installed handler.
Default Fatal Error Processing
@@ -764,27 +783,27 @@ An RTEMS based application is initiated or re-initiated when the SPARC
processor is reset. When the SPARC is reset, the processor performs the
following actions:
-- the enable trap (ET) of the psr is set to 0 to disable traps,
+- the enable trap (ET) of the ``PSR`` is set to 0 to disable traps,
-- the supervisor bit (S) of the psr is set to 1 to enter supervisor mode, and
+- the supervisor bit (S) of the ``PSR`` is set to 1 to enter supervisor mode, and
- the PC is set 0 and the nPC is set to 4.
The processor then begins to execute the code at location 0. It is important
-to note that all fields in the psr are not explicitly set by the above steps
+to note that all fields in the ``PSR`` are not explicitly set by the above steps
and all other registers retain their value from the previous execution mode.
-This is true even of the Trap Base Register (TBR) whose contents reflect the
+This is true even of the Trap Base Register (``TBR``) whose contents reflect the
last trap which occurred before the reset.
Processor Initialization
------------------------
It is the responsibility of the application's initialization code to initialize
-the TBR and install trap handlers for at least the register window overflow and
+the ``TBR`` and install trap handlers for at least the register window overflow and
register window underflow conditions. Traps should be enabled before invoking
any subroutines to allow for register window management. However, interrupts
should be disabled by setting the Processor Interrupt Level (pil) field of the
-psr to 15. RTEMS installs it's own Trap Table as part of initialization which
+``PSR`` to 15. RTEMS installs it's own Trap Table as part of initialization which
is initialized with the contents of the Trap Table in place when the
``rtems_initialize_executive`` directive was invoked. Upon completion of
executive initialization, interrupts are enabled.