Changeset f233256 in rtems-docs for cpu_supplement/sparc64.rst


Ignore:
Timestamp:
Oct 6, 2016, 10:13:16 PM (4 years ago)
Author:
Chris Johns <chrisj@…>
Branches:
4.11, 5, am, master
Children:
be428d1
Parents:
e6fe68d
Message:

Clean up the CPU Supplement.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • cpu_supplement/sparc64.rst

    re6fe68d rf233256  
    11.. comment SPDX-License-Identifier: CC-BY-SA-4.0
     2
     3.. COMMENT: COPYRIGHT (c) 1988-2002.
     4.. COMMENT: On-Line Applications Research Corporation (OAR).
     5.. COMMENT: All rights reserved.
    26
    37SPARC-64 Specific Information
     
    2226  (http://www.sun.com/microelectronics/manuals/ultrasparc/802-7220-02.pdf)
    2327
    24 - UltraSPARC IIIi Processor (datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf)
     28- UltraSPARC IIIi Processor (http://datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf)
    2529
    2630**sun4v Specific Information**
    2731
    28 sun4v is the subset of the SPARC V9 implementations comprising the
    29 UltraSPARC T1 or T2 processors.
     32sun4v is the subset of the SPARC V9 implementations comprising the UltraSPARC
     33T1 or T2 processors.
    3034
    3135The following documents were used in developing the SPARC-64 sun4v port:
     
    3741  (http://opensparc-t1.sunsource.net/specs/UST1-UASuppl-current-draft-P-EXT.pdf)
    3842
    39 The defining feature that separates the sun4v architecture from its
    40 predecessor is the existence of a super-privileged hypervisor that
    41 is responsible for providing virtualized execution environments.  The impact
    42 of the hypervisor on the real-time guarantees available with sun4v has not
    43 yet been determined.
     43The defining feature that separates the sun4v architecture from its predecessor
     44is the existence of a super-privileged hypervisor that is responsible for
     45providing virtualized execution environments.  The impact of the hypervisor on
     46the real-time guarantees available with sun4v has not yet been determined.
    4447
    4548CPU Model Dependent Features
     
    4952-----------------------
    5053
    51 This section presents the set of features which vary across
    52 SPARC-64 implementations and
    53 are of importance to RTEMS. The set of CPU model feature macros
    54 are defined in the file
    55 cpukit/score/cpu/sparc64/sparc64.h based upon the particular
    56 CPU model defined on the compilation command line.
     54This section presents the set of features which vary across SPARC-64
     55implementations and are of importance to RTEMS. The set of CPU model feature
     56macros are defined in the file cpukit/score/cpu/sparc64/sparc64.h based upon
     57the particular CPU model defined on the compilation command line.
    5758
    5859CPU Model Name
    5960~~~~~~~~~~~~~~
    6061
    61 The macro CPU MODEL NAME is a string which designates
    62 the name of this CPU model.
    63 For example, for the UltraSPARC T1 SPARC V9 model,
    64 this macro is set to the string "sun4v".
     62The macro CPU MODEL NAME is a string which designates the name of this CPU
     63model.  For example, for the UltraSPARC T1 SPARC V9 model, this macro is set to
     64the string "sun4v".
    6565
    6666Floating Point Unit
    6767~~~~~~~~~~~~~~~~~~~
    6868
    69 The macro SPARC_HAS_FPU is set to 1 to indicate that
    70 this CPU model has a hardware floating point unit and 0
    71 otherwise.
     69The macro SPARC_HAS_FPU is set to 1 to indicate that this CPU model has a
     70hardware floating point unit and 0 otherwise.
    7271
    7372Number of Register Windows
    7473~~~~~~~~~~~~~~~~~~~~~~~~~~
    7574
    76 The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to
    77 indicate the number of register window sets implemented by this
    78 CPU model.  The SPARC architecture allows for a maximum of
    79 thirty-two register window sets although most implementations
    80 only include eight.
     75The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to indicate the number of
     76register window sets implemented by this CPU model.  The SPARC architecture
     77allows for a maximum of thirty-two register window sets although most
     78implementations only include eight.
    8179
    8280CPU Model Implementation Notes
    8381------------------------------
    8482
    85 This section describes the implemenation dependencies of the
    86 CPU Models sun4u and sun4v of the SPARC V9 architecture.
     83This section describes the implemenation dependencies of the CPU Models sun4u
     84and sun4v of the SPARC V9 architecture.
    8785
    8886sun4u Notes
     
    9694XXX
    9795
    98 .. COMMENT: COPYRIGHT (c) 1988-2002.
    99 
    100 .. COMMENT: On-Line Applications Research Corporation (OAR).
    101 
    102 .. COMMENT: All rights reserved.
    103 
    10496Calling Conventions
    10597===================
    10698
    107 Each high-level language compiler generates
    108 subroutine entry and exit code based upon a set of rules known
    109 as the compiler's calling convention.   These rules address the
    110 following issues:
     99Each high-level language compiler generates subroutine entry and exit code
     100based upon a set of rules known as the compiler's calling convention.  These
     101rules address the following issues:
    111102
    112103- register preservation and usage
     
    123114are both processor and compiler dependent.
    124115
    125 The following document also provides some conventions on the
    126 global register usage in SPARC V9:
    127 http://developers.sun.com/solaris/articles/sparcv9abi.html
     116The following document also provides some conventions on the global register
     117usage in SPARC V9: http://developers.sun.com/solaris/articles/sparcv9abi.html
    128118
    129119Programming Model
    130120-----------------
    131121
    132 This section discusses the programming model for the
    133 SPARC architecture.
     122This section discusses the programming model for the SPARC architecture.
    134123
    135124Non-Floating Point Registers
    136125~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    137126
    138 The SPARC architecture defines thirty-two
    139 non-floating point registers directly visible to the programmer.
    140 These are divided into four sets:
     127The SPARC architecture defines thirty-two non-floating point registers directly
     128visible to the programmer.  These are divided into four sets:
    141129
    142130- input registers
     
    148136- global registers
    149137
    150 Each register is referred to by either two or three
    151 names in the SPARC reference manuals.  First, the registers are
    152 referred to as r0 through r31 or with the alternate notation
    153 r[0] through r[31].  Second, each register is a member of one of
    154 the four sets listed above.  Finally, some registers have an
    155 architecturally defined role in the programming model which
    156 provides an alternate name.  The following table describes the
    157 mapping between the 32 registers and the register sets:
    158 
    159 .. code:: c
     138Each register is referred to by either two or three names in the SPARC
     139reference manuals.  First, the registers are referred to as r0 through r31 or
     140with the alternate notation r[0] through r[31].  Second, each register is a
     141member of one of the four sets listed above.  Finally, some registers have an
     142architecturally defined role in the programming model which provides an
     143alternate name.  The following table describes the mapping between the 32
     144registers and the register sets:
    160145
    161146    +-----------------+----------------+------------------+
     
    171156    +-----------------+----------------+------------------+
    172157
    173 As mentioned above, some of the registers serve
    174 defined roles in the programming model.  The following table
    175 describes the role of each of these registers:
    176 
    177 .. code:: c
     158As mentioned above, some of the registers serve defined roles in the
     159programming model.  The following table describes the role of each of these
     160registers:
    178161
    179162    +---------------+----------------+----------------------+
     
    193176~~~~~~~~~~~~~~~~~~~~~~~~
    194177
    195 The SPARC V9 architecture includes sixty-four,
    196 thirty-two bit registers.  These registers may be viewed as
    197 follows:
    198 
    199 - 32 32-bit single precision floating point or integer registers
    200   (f0, f1,  ... f31)
    201 
    202 - 32 64-bit double precision floating point registers (f0, f2,
    203   f4, ... f62)
    204 
    205 - 16 128-bit extended precision floating point registers (f0, f4,
    206   f8, ... f60)
    207 
    208 The floating point state register (fsr) specifies
    209 the behavior of the floating point unit for rounding, contains
    210 its condition codes, version specification, and trap information.
     178The SPARC V9 architecture includes sixty-four, thirty-two bit registers.  These
     179registers may be viewed as follows:
     180
     181- 32 32-bit single precision floating point or integer registers (f0, f1,
     182  ... f31)
     183
     184- 32 64-bit double precision floating point registers (f0, f2, f4, ... f62)
     185
     186- 16 128-bit extended precision floating point registers (f0, f4, f8, ... f60)
     187
     188The floating point state register (fsr) specifies the behavior of the floating
     189point unit for rounding, contains its condition codes, version specification,
     190and trap information.
    211191
    212192Special Registers
     
    216196
    217197*``Ancillary State Registers (ASRs)``*
    218     The ancillary state registers (ASRs) are optional state registers that
    219     may be privileged or nonprivileged. ASRs 16-31 are implementation-
    220     dependent. The SPARC V9 ASRs include: y, ccr, asi, tick, pc, fprs.
    221     The sun4u ASRs include: pcr, pic, dcr, gsr, softint set, softint clr,
    222     softint, and tick cmpr. The sun4v ASRs include: pcr, pic, gsr, soft-
    223     int set, softint clr, softint, tick cmpr, stick, and stick cmpr.
     198    The ancillary state registers (ASRs) are optional state registers that may
     199    be privileged or nonprivileged. ASRs 16-31 are implementation-
     200    dependent. The SPARC V9 ASRs include: y, ccr, asi, tick, pc, fprs.  The
     201    sun4u ASRs include: pcr, pic, dcr, gsr, softint set, softint clr, softint,
     202    and tick cmpr. The sun4v ASRs include: pcr, pic, gsr, soft- int set,
     203    softint clr, softint, tick cmpr, stick, and stick cmpr.
    224204
    225205*``Processor State Register (pstate)``*
     
    233213
    234214*``Trap Registers``*
    235     The trap handling mechanism of the SPARC V9 includes a number of
    236     registers, including: trap program counter (tpc), trap next pc (tnpc),
    237     trap state (tstate), trap type (tt), trap base address (tba), and trap
    238     level (tl).
     215    The trap handling mechanism of the SPARC V9 includes a number of registers,
     216    including: trap program counter (tpc), trap next pc (tnpc), trap state
     217    (tstate), trap type (tt), trap base address (tba), and trap level (tl).
    239218
    240219*``Alternate Globals``*
    241     The AG bit of the pstate register provides access to an alternate set
    242     of global registers. On sun4v, the AG bit is replaced by the global
    243     level (gl) register, providing access to at least two and at most eight
    244     alternate sets of globals.
     220    The AG bit of the pstate register provides access to an alternate set of
     221    global registers. On sun4v, the AG bit is replaced by the global level (gl)
     222    register, providing access to at least two and at most eight alternate sets
     223    of globals.
    245224
    246225*``Register Window registers``*
    247     A number of registers assist in register window management.
    248     These include the current window pointer (cwp), savable windows
    249     (cansave), restorable windows (canrestore), clean windows (clean-
    250     win), other windows (otherwin), and window state (wstate).
     226    A number of registers assist in register window management.  These include
     227    the current window pointer (cwp), savable windows (cansave), restorable
     228    windows (canrestore), clean windows (clean- win), other windows (otherwin),
     229    and window state (wstate).
    251230
    252231Register Windows
    253232----------------
    254233
    255 The SPARC architecture includes the concept of
    256 register windows.  An overly simplistic way to think of these
    257 windows is to imagine them as being an infinite supply of
    258 "fresh" register sets available for each subroutine to use.  In
    259 reality, they are much more complicated.
    260 
    261 The save instruction is used to obtain a new register window.
    262 This instruction increments the current window pointer, thus
    263 providing a new set of registers for use. This register set
    264 includes eight fresh local registers for use exclusively by
    265 this subroutine. When done with a register set, the restore
    266 instruction decrements the current window pointer and the
    267 previous register set is once again available.
    268 
    269 The two primary issues complicating the use of register windows
    270 are that (1) the set of register windows is finite, and (2) some
    271 registers are shared between adjacent registers windows.
    272 
    273 Because the set of register windows is finite, it is
    274 possible to execute enough save instructions without
    275 corresponding restore's to consume all of the register windows.
    276 This is easily accomplished in a high level language because
    277 each subroutine typically performs a save instruction upon
    278 entry.  Thus having a subroutine call depth greater than the
    279 number of register windows will result in a window overflow
    280 condition.  The window overflow condition generates a trap which
    281 must be handled in software.  The window overflow trap handler
    282 is responsible for saving the contents of the oldest register
    283 window on the program stack.
    284 
    285 Similarly, the subroutines will eventually complete
    286 and begin to perform restore's.  If the restore results in the
    287 need for a register window which has previously been written to
    288 memory as part of an overflow, then a window underflow condition
    289 results.  Just like the window overflow, the window underflow
    290 condition must be handled in software by a trap handler.  The
    291 window underflow trap handler is responsible for reloading the
    292 contents of the register window requested by the restore
    293 instruction from the program stack.
    294 
    295 The cansave, canrestore, otherwin, and cwp are used in conjunction
    296 to manage the finite set of register windows and detect the window
    297 overflow and underflow conditions. The first three of these
    298 registers must satisfy the invariant cansave + canrestore + otherwin =
    299 nwindow - 2, where nwindow is the number of register windows.
    300 The cwp contains the index of the register window currently in use.
    301 RTEMS does not use the cleanwin and otherwin registers.
    302 
    303 The save instruction increments the cwp modulo the number of
    304 register windows, and if cansave is 0 then it also generates a
    305 window overflow. Similarly, the restore instruction decrements the
    306 cwp modulo the number of register windows, and if canrestore is 0 then it
    307 also generates a window underflow.
    308 
    309 Unlike with the SPARC model, the SPARC-64 port does not assume that
    310 a register window is available for a trap. The window overflow
    311 and underflow conditions are not detected without hardware generating
    312 the trap. (These conditions can be detected by reading the register window
    313 registers and doing some simple arithmetic.)
    314 
    315 The window overflow and window underflow trap
    316 handlers are a critical part of the run-time environment for a
    317 SPARC application.  The SPARC architectural specification allows
    318 for the number of register windows to be any power of two less
    319 than or equal to 32.  The most common choice for SPARC
    320 implementations appears to be 8 register windows.  This results
    321 in the cwp ranging in value from 0 to 7 on most implementations.
    322 
    323 The second complicating factor is the sharing of
    324 registers between adjacent register windows.  While each
    325 register window has its own set of local registers, the input
    326 and output registers are shared between adjacent windows.  The
    327 output registers for register window N are the same as the input
    328 registers for register window ((N + 1) modulo RW) where RW is
    329 the number of register windows.  An alternative way to think of
    330 this is to remember how parameters are passed to a subroutine on
    331 the SPARC.  The caller loads values into what are its output
    332 registers.  Then after the callee executes a save instruction,
    333 those parameters are available in its input registers.  This is
    334 a very efficient way to pass parameters as no data is actually
    335 moved by the save or restore instructions.
     234The SPARC architecture includes the concept of register windows.  An overly
     235simplistic way to think of these windows is to imagine them as being an
     236infinite supply of "fresh" register sets available for each subroutine to use.
     237In reality, they are much more complicated.
     238
     239The save instruction is used to obtain a new register window.  This instruction
     240increments the current window pointer, thus providing a new set of registers
     241for use. This register set includes eight fresh local registers for use
     242exclusively by this subroutine. When done with a register set, the restore
     243instruction decrements the current window pointer and the previous register set
     244is once again available.
     245
     246The two primary issues complicating the use of register windows are that (1)
     247the set of register windows is finite, and (2) some registers are shared
     248between adjacent registers windows.
     249
     250Because the set of register windows is finite, it is possible to execute enough
     251save instructions without corresponding restore's to consume all of the
     252register windows.  This is easily accomplished in a high level language because
     253each subroutine typically performs a save instruction upon entry.  Thus having
     254a subroutine call depth greater than the number of register windows will result
     255in a window overflow condition.  The window overflow condition generates a trap
     256which must be handled in software.  The window overflow trap handler is
     257responsible for saving the contents of the oldest register window on the
     258program stack.
     259
     260Similarly, the subroutines will eventually complete and begin to perform
     261restore's.  If the restore results in the need for a register window which has
     262previously been written to memory as part of an overflow, then a window
     263underflow condition results.  Just like the window overflow, the window
     264underflow condition must be handled in software by a trap handler.  The window
     265underflow trap handler is responsible for reloading the contents of the
     266register window requested by the restore instruction from the program stack.
     267
     268The cansave, canrestore, otherwin, and cwp are used in conjunction to manage
     269the finite set of register windows and detect the window overflow and underflow
     270conditions. The first three of these registers must satisfy the invariant
     271cansave + canrestore + otherwin = nwindow - 2, where nwindow is the number of
     272register windows.  The cwp contains the index of the register window currently
     273in use.  RTEMS does not use the cleanwin and otherwin registers.
     274
     275The save instruction increments the cwp modulo the number of register windows,
     276and if cansave is 0 then it also generates a window overflow. Similarly, the
     277restore instruction decrements the cwp modulo the number of register windows,
     278and if canrestore is 0 then it also generates a window underflow.
     279
     280Unlike with the SPARC model, the SPARC-64 port does not assume that a register
     281window is available for a trap. The window overflow and underflow conditions
     282are not detected without hardware generating the trap. (These conditions can be
     283detected by reading the register window registers and doing some simple
     284arithmetic.)
     285
     286The window overflow and window underflow trap handlers are a critical part of
     287the run-time environment for a SPARC application.  The SPARC architectural
     288specification allows for the number of register windows to be any power of two
     289less than or equal to 32.  The most common choice for SPARC implementations
     290appears to be 8 register windows.  This results in the cwp ranging in value
     291from 0 to 7 on most implementations.
     292
     293The second complicating factor is the sharing of registers between adjacent
     294register windows.  While each register window has its own set of local
     295registers, the input and output registers are shared between adjacent windows.
     296The output registers for register window N are the same as the input registers
     297for register window ((N + 1) modulo RW) where RW is the number of register
     298windows.  An alternative way to think of this is to remember how parameters are
     299passed to a subroutine on the SPARC.  The caller loads values into what are its
     300output registers.  Then after the callee executes a save instruction, those
     301parameters are available in its input registers.  This is a very efficient way
     302to pass parameters as no data is actually moved by the save or restore
     303instructions.
    336304
    337305Call and Return Mechanism
    338306-------------------------
    339307
    340 The SPARC architecture supports a simple yet
    341 effective call and return mechanism.  A subroutine is invoked
    342 via the call (call) instruction.  This instruction places the
    343 return address in the caller's output register 7 (o7).  After
    344 the callee executes a save instruction, this value is available
    345 in input register 7 (i7) until the corresponding restore
    346 instruction is executed.
    347 
    348 The callee returns to the caller via a jmp to the
    349 return address.  There is a delay slot following this
    350 instruction which is commonly used to execute a restore
    351 instruction - if a register window was allocated by this
    352 subroutine.
    353 
    354 It is important to note that the SPARC subroutine
    355 call and return mechanism does not automatically save and
    356 restore any registers.  This is accomplished via the save and
    357 restore instructions which manage the set of registers windows.
    358 This allows for the compiler to generate leaf-optimized functions
     308The SPARC architecture supports a simple yet effective call and return
     309mechanism.  A subroutine is invoked via the call (call) instruction.  This
     310instruction places the return address in the caller's output register 7 (o7).
     311After the callee executes a save instruction, this value is available in input
     312register 7 (i7) until the corresponding restore instruction is executed.
     313
     314The callee returns to the caller via a jmp to the return address.  There is a
     315delay slot following this instruction which is commonly used to execute a
     316restore instruction - if a register window was allocated by this subroutine.
     317
     318It is important to note that the SPARC subroutine call and return mechanism
     319does not automatically save and restore any registers.  This is accomplished
     320via the save and restore instructions which manage the set of registers
     321windows.  This allows for the compiler to generate leaf-optimized functions
    359322that utilize the caller's output registers without using save and restore.
    360323
     
    362325-----------------
    363326
    364 All RTEMS directives are invoked using the regular
    365 SPARC calling convention via the call instruction.
     327All RTEMS directives are invoked using the regular SPARC calling convention via
     328the call instruction.
    366329
    367330Register Usage
    368331--------------
    369332
    370 As discussed above, the call instruction does not
    371 automatically save any registers.  The save and restore
    372 instructions are used to allocate and deallocate register
    373 windows.  When a register window is allocated, the new set of
    374 local registers are available for the exclusive use of the
    375 subroutine which allocated this register set.
     333As discussed above, the call instruction does not automatically save any
     334registers.  The save and restore instructions are used to allocate and
     335deallocate register windows.  When a register window is allocated, the new set
     336of local registers are available for the exclusive use of the subroutine which
     337allocated this register set.
    376338
    377339Parameter Passing
    378340-----------------
    379341
    380 RTEMS assumes that arguments are placed in the
    381 caller's output registers with the first argument in output
    382 register 0 (o0), the second argument in output register 1 (o1),
    383 and so forth.  Until the callee executes a save instruction, the
    384 parameters are still visible in the output registers.  After the
    385 callee executes a save instruction, the parameters are visible
    386 in the corresponding input registers.  The following pseudo-code
    387 illustrates the typical sequence used to call a RTEMS directive
    388 with three (3) arguments:
    389 .. code:: c
     342RTEMS assumes that arguments are placed in the caller's output registers with
     343the first argument in output register 0 (o0), the second argument in output
     344register 1 (o1), and so forth.  Until the callee executes a save instruction,
     345the parameters are still visible in the output registers.  After the callee
     346executes a save instruction, the parameters are visible in the corresponding
     347input registers.  The following pseudo-code illustrates the typical sequence
     348used to call a RTEMS directive with three (3) arguments:
     349
     350.. code-block:: c
    390351
    391352    load third argument into o2
     
    397358----------------------
    398359
    399 All user-provided routines invoked by RTEMS, such as
    400 user extensions, device drivers, and MPCI routines, must also
    401 adhere to these calling conventions.
    402 
    403 .. COMMENT: COPYRIGHT (c) 1988-2002.
    404 
    405 .. COMMENT: On-Line Applications Research Corporation (OAR).
    406 
    407 .. COMMENT: All rights reserved.
     360All user-provided routines invoked by RTEMS, such as user extensions, device
     361drivers, and MPCI routines, must also adhere to these calling conventions.
    408362
    409363Memory Model
    410364============
    411365
    412 A processor may support any combination of memory
    413 models ranging from pure physical addressing to complex demand
    414 paged virtual memory systems.  RTEMS supports a flat memory
    415 model which ranges contiguously over the processor's allowable
    416 address space.  RTEMS does not support segmentation or virtual
    417 memory of any kind.  The appropriate memory model for RTEMS
    418 provided by the targeted processor and related characteristics
    419 of that model are described in this chapter.
     366A processor may support any combination of memory models ranging from pure
     367physical addressing to complex demand paged virtual memory systems.  RTEMS
     368supports a flat memory model which ranges contiguously over the processor's
     369allowable address space.  RTEMS does not support segmentation or virtual memory
     370of any kind.  The appropriate memory model for RTEMS provided by the targeted
     371processor and related characteristics of that model are described in this
     372chapter.
    420373
    421374Flat Memory Model
    422375-----------------
    423376
    424 The SPARC-64 architecture supports a flat 64-bit address space with
    425 addresses ranging from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF.
    426 Each address is represented by a 64-bit value (and an 8-bit address
    427 space identifider or ASI) and is byte addressable. The address
    428 may be used to reference a single byte, half-word (2-bytes),
    429 word (4 bytes), doubleword (8 bytes), or quad-word (16 bytes).
    430 Memory accesses within this address space are performed
    431 in big endian fashion by the SPARC. Memory accesses which are not
    432 properly aligned generate a "memory address not aligned" trap
    433 (type number 0x34). The following table lists the alignment
    434 requirements for a variety of data accesses:
    435 
    436 .. code:: c
     377The SPARC-64 architecture supports a flat 64-bit address space with addresses
     378ranging from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF.  Each address is
     379represented by a 64-bit value (and an 8-bit address space identifider or ASI)
     380and is byte addressable. The address may be used to reference a single byte,
     381half-word (2-bytes), word (4 bytes), doubleword (8 bytes), or quad-word (16
     382bytes).  Memory accesses within this address space are performed in big endian
     383fashion by the SPARC. Memory accesses which are not properly aligned generate a
     384"memory address not aligned" trap (type number 0x34). The following table lists
     385the alignment requirements for a variety of data accesses:
     386
     387.. table::
    437388
    438389    +--------------+-----------------------+
     
    446397    +--------------+-----------------------+
    447398
    448 RTEMS currently does not support any SPARC Memory Management
    449 Units, therefore, virtual memory or segmentation systems
    450 involving the SPARC are not supported.
    451 
    452 .. COMMENT: COPYRIGHT (c) 1988-2002.
    453 
    454 .. COMMENT: On-Line Applications Research Corporation (OAR).
    455 
    456 .. COMMENT: All rights reserved.
     399RTEMS currently does not support any SPARC Memory Management Units, therefore,
     400virtual memory or segmentation systems involving the SPARC are not supported.
    457401
    458402Interrupt Processing
    459403====================
    460404
    461 RTEMS and associated documentation uses the terms
    462 interrupt and vector.  In the SPARC architecture, these terms
    463 correspond to traps and trap type, respectively.  The terms will
    464 be used interchangeably in this manual. Note that in the SPARC manuals,
    465 interrupts are a subset of the traps that are delivered to software
    466 interrupt handlers.
     405RTEMS and associated documentation uses the terms interrupt and vector.  In the
     406SPARC architecture, these terms correspond to traps and trap type,
     407respectively.  The terms will be used interchangeably in this manual. Note that
     408in the SPARC manuals, interrupts are a subset of the traps that are delivered
     409to software interrupt handlers.
    467410
    468411Synchronous Versus Asynchronous Traps
    469412-------------------------------------
    470413
    471 The SPARC architecture includes two classes of traps:
    472 synchronous (precise) and asynchronous (deferred).
    473 Asynchronous traps occur when an
    474 external event interrupts the processor.  These traps are not
    475 associated with any instruction executed by the processor and
    476 logically occur between instructions.  The instruction currently
    477 in the execute stage of the processor is allowed to complete
    478 although subsequent instructions are annulled.  The return
    479 address reported by the processor for asynchronous traps is the
    480 pair of instructions following the current instruction.
    481 
    482 Synchronous traps are caused by the actions of an
    483 instruction.  The trap stimulus in this case either occurs
    484 internally to the processor or is from an external signal that
    485 was provoked by the instruction.  These traps are taken
    486 immediately and the instruction that caused the trap is aborted
    487 before any state changes occur in the processor itself.   The
    488 return address reported by the processor for synchronous traps
    489 is the instruction which caused the trap and the following
    490 instruction.
     414The SPARC architecture includes two classes of traps: synchronous (precise) and
     415asynchronous (deferred).  Asynchronous traps occur when an external event
     416interrupts the processor.  These traps are not associated with any instruction
     417executed by the processor and logically occur between instructions.  The
     418instruction currently in the execute stage of the processor is allowed to
     419complete although subsequent instructions are annulled.  The return address
     420reported by the processor for asynchronous traps is the pair of instructions
     421following the current instruction.
     422
     423Synchronous traps are caused by the actions of an instruction.  The trap
     424stimulus in this case either occurs internally to the processor or is from an
     425external signal that was provoked by the instruction.  These traps are taken
     426immediately and the instruction that caused the trap is aborted before any
     427state changes occur in the processor itself.  The return address reported by
     428the processor for synchronous traps is the instruction which caused the trap
     429and the following instruction.
    491430
    492431Vectoring of Interrupt Handler
    493432------------------------------
    494433
    495 Upon receipt of an interrupt the SPARC automatically
    496 performs the following actions:
    497 
    498 - The trap level is set. This provides access to a fresh set of
    499   privileged trap-state registers used to save the current state,
    500   in effect, pushing a frame on the trap stack.
    501   TL <- TL + 1
     434Upon receipt of an interrupt the SPARC automatically performs the following
     435actions:
     436
     437- The trap level is set. This provides access to a fresh set of privileged
     438  trap-state registers used to save the current state, in effect, pushing a
     439  frame on the trap stack.  TL <- TL + 1
    502440
    503441- Existing state is preserved
     
    537475
    538476In order to safely invoke a subroutine during trap handling, traps must be
    539 enabled to allow for the possibility of register window overflow and
    540 underflow traps.
    541 
    542 If the interrupt handler was installed as an RTEMS
    543 interrupt handler, then upon receipt of the interrupt, the
    544 processor passes control to the RTEMS interrupt handler which
    545 performs the following actions:
     477enabled to allow for the possibility of register window overflow and underflow
     478traps.
     479
     480If the interrupt handler was installed as an RTEMS interrupt handler, then upon
     481receipt of the interrupt, the processor passes control to the RTEMS interrupt
     482handler which performs the following actions:
    546483
    547484- saves the state of the interrupted task on it's stack,
     
    549486- switches the processor to trap level 0,
    550487
    551 - if this is the outermost (i.e. non-nested) interrupt,
    552   then the RTEMS interrupt handler switches from the current stack
    553   to the interrupt stack,
     488- if this is the outermost (i.e. non-nested) interrupt, then the RTEMS
     489  interrupt handler switches from the current stack to the interrupt stack,
    554490
    555491- enables traps,
     
    557493- invokes the vectors to a user interrupt service routine (ISR).
    558494
    559 Asynchronous interrupts are ignored while traps are
    560 disabled.  Synchronous traps which occur while traps are
    561 disabled may result in the CPU being forced into an error mode.
    562 
    563 A nested interrupt is processed similarly with the
    564 exception that the current stack need not be switched to the
    565 interrupt stack.
     495Asynchronous interrupts are ignored while traps are disabled.  Synchronous
     496traps which occur while traps are disabled may result in the CPU being forced
     497into an error mode.
     498
     499A nested interrupt is processed similarly with the exception that the current
     500stack need not be switched to the interrupt stack.
    566501
    567502Traps and Register Windows
     
    573508----------------
    574509
    575 Sixteen levels (0-15) of interrupt priorities are
    576 supported by the SPARC architecture with level fifteen (15)
    577 being the highest priority.  Level zero (0) indicates that
    578 interrupts are fully enabled.  Interrupt requests for interrupts
    579 with priorities less than or equal to the current interrupt mask
     510Sixteen levels (0-15) of interrupt priorities are supported by the SPARC
     511architecture with level fifteen (15) being the highest priority.  Level
     512zero (0) indicates that interrupts are fully enabled.  Interrupt requests for
     513interrupts with priorities less than or equal to the current interrupt mask
    580514level are ignored.
    581515
    582 Although RTEMS supports 256 interrupt levels, the
    583 SPARC only supports sixteen.  RTEMS interrupt levels 0 through
    584 15 directly correspond to SPARC processor interrupt levels.  All
    585 other RTEMS interrupt levels are undefined and their behavior is
    586 unpredictable.
     516Although RTEMS supports 256 interrupt levels, the SPARC only supports sixteen.
     517RTEMS interrupt levels 0 through 15 directly correspond to SPARC processor
     518interrupt levels.  All other RTEMS interrupt levels are undefined and their
     519behavior is unpredictable.
    587520
    588521Disabling of Interrupts by RTEMS
     
    594527---------------
    595528
    596 The SPARC architecture does not provide for a
    597 dedicated interrupt stack.  Thus by default, trap handlers would
    598 execute on the stack of the RTEMS task which they interrupted.
    599 This artificially inflates the stack requirements for each task
    600 since EVERY task stack would have to include enough space to
    601 account for the worst case interrupt stack requirements in
    602 addition to it's own worst case usage.  RTEMS addresses this
    603 problem on the SPARC by providing a dedicated interrupt stack
    604 managed by software.
    605 
    606 During system initialization, RTEMS allocates the
    607 interrupt stack from the Workspace Area.  The amount of memory
    608 allocated for the interrupt stack is determined by the
    609 interrupt_stack_size field in the CPU Configuration Table.  As
    610 part of processing a non-nested interrupt, RTEMS will switch to
    611 the interrupt stack before invoking the installed handler.
    612 
    613 .. COMMENT: COPYRIGHT (c) 1988-2002.
    614 
    615 .. COMMENT: On-Line Applications Research Corporation (OAR).
    616 
    617 .. COMMENT: All rights reserved.
     529The SPARC architecture does not provide for a dedicated interrupt stack.  Thus
     530by default, trap handlers would execute on the stack of the RTEMS task which
     531they interrupted.  This artificially inflates the stack requirements for each
     532task since EVERY task stack would have to include enough space to account for
     533the worst case interrupt stack requirements in addition to it's own worst case
     534usage.  RTEMS addresses this problem on the SPARC by providing a dedicated
     535interrupt stack managed by software.
     536
     537During system initialization, RTEMS allocates the interrupt stack from the
     538Workspace Area.  The amount of memory allocated for the interrupt stack is
     539determined by the interrupt_stack_size field in the CPU Configuration Table.
     540As part of processing a non-nested interrupt, RTEMS will switch to the
     541interrupt stack before invoking the installed handler.
    618542
    619543Default Fatal Error Processing
    620544==============================
    621545
    622 Upon detection of a fatal error by either the
    623 application or RTEMS the fatal error manager is invoked.  The
    624 fatal error manager will invoke the user-supplied fatal error
    625 handlers.  If no user-supplied handlers are configured,  the
    626 RTEMS provided default fatal error handler is invoked.  If the
    627 user-supplied fatal error handlers return to the executive the
    628 default fatal error handler is then invoked.  This chapter
    629 describes the precise operations of the default fatal error
    630 handler.
     546Upon detection of a fatal error by either the application or RTEMS the fatal
     547error manager is invoked.  The fatal error manager will invoke the
     548user-supplied fatal error handlers.  If no user-supplied handlers are
     549configured, the RTEMS provided default fatal error handler is invoked.  If the
     550user-supplied fatal error handlers return to the executive the default fatal
     551error handler is then invoked.  This chapter describes the precise operations
     552of the default fatal error handler.
    631553
    632554Default Fatal Error Handler Operations
    633555--------------------------------------
    634556
    635 The default fatal error handler which is invoked by
    636 the fatal_error_occurred directive when there is no user handler
    637 configured or the user handler returns control to RTEMS.  The
    638 default fatal error handler disables processor interrupts to
    639 level 15, places the error code in g1, and goes into an infinite
     557The default fatal error handler which is invoked by the fatal_error_occurred
     558directive when there is no user handler configured or the user handler returns
     559control to RTEMS.  The default fatal error handler disables processor
     560interrupts to level 15, places the error code in g1, and goes into an infinite
    640561loop to simulate a halt processor instruction.
    641562
     
    650571Thread-local storage is supported.
    651572
    652 .. COMMENT: COPYRIGHT (c) 1988-2002.
    653 
    654 .. COMMENT: On-Line Applications Research Corporation (OAR).
    655 
    656 .. COMMENT: All rights reserved.
    657 
    658573Board Support Packages
    659574======================
    660575
    661 An RTEMS Board Support Package (BSP) must be designed
    662 to support a particular processor and target board combination.
    663 This chapter presents a discussion of SPARC specific BSP issues.
    664 For more information on developing a BSP, refer to the chapter
    665 titled Board Support Packages in the RTEMS
    666 Applications User's Guide.
     576An RTEMS Board Support Package (BSP) must be designed to support a particular
     577processor and target board combination.  This chapter presents a discussion of
     578SPARC specific BSP issues.  For more information on developing a BSP, refer to
     579the chapter titled Board Support Packages in the RTEMS Applications User's
     580Guide.
    667581
    668582HelenOS and Open Firmware
    669583-------------------------
    670584
    671 The provided BSPs make use of some bootstrap and low-level hardware code
    672 of the HelenOS operating system. These files can be found in the shared/helenos
    673 directory of the sparc64 bsp directory.  Consult the sources for more
    674 detailed information.
     585The provided BSPs make use of some bootstrap and low-level hardware code of the
     586HelenOS operating system. These files can be found in the shared/helenos
     587directory of the sparc64 bsp directory.  Consult the sources for more detailed
     588information.
    675589
    676590The shared BSP code also uses the Open Firmware interface to re-use firmware
    677591code, primarily for console support and default trap handlers.
    678 
Note: See TracChangeset for help on using the changeset viewer.