From f233256327e8a01a1236dbdd0f91701bc229936b Mon Sep 17 00:00:00 2001 From: Chris Johns Date: Fri, 7 Oct 2016 11:13:16 +1300 Subject: Clean up the CPU Supplement. --- cpu_supplement/sparc64.rst | 625 +++++++++++++++++++-------------------------- 1 file changed, 269 insertions(+), 356 deletions(-) (limited to 'cpu_supplement/sparc64.rst') diff --git a/cpu_supplement/sparc64.rst b/cpu_supplement/sparc64.rst index 09842e8..4bc5427 100644 --- a/cpu_supplement/sparc64.rst +++ b/cpu_supplement/sparc64.rst @@ -1,5 +1,9 @@ .. comment SPDX-License-Identifier: CC-BY-SA-4.0 +.. COMMENT: COPYRIGHT (c) 1988-2002. +.. COMMENT: On-Line Applications Research Corporation (OAR). +.. COMMENT: All rights reserved. + SPARC-64 Specific Information ############################# @@ -21,12 +25,12 @@ The following documents were used in developing the SPARC-64 sun4u port: - UltraSPARC User's Manual (http://www.sun.com/microelectronics/manuals/ultrasparc/802-7220-02.pdf) -- UltraSPARC IIIi Processor (datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf) +- UltraSPARC IIIi Processor (http://datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf) **sun4v Specific Information** -sun4v is the subset of the SPARC V9 implementations comprising the -UltraSPARC T1 or T2 processors. +sun4v is the subset of the SPARC V9 implementations comprising the UltraSPARC +T1 or T2 processors. The following documents were used in developing the SPARC-64 sun4v port: @@ -36,11 +40,10 @@ The following documents were used in developing the SPARC-64 sun4v port: - UltraSPARC T1 supplement to UltraSPARC Architecture 2005 Specification (http://opensparc-t1.sunsource.net/specs/UST1-UASuppl-current-draft-P-EXT.pdf) -The defining feature that separates the sun4v architecture from its -predecessor is the existence of a super-privileged hypervisor that -is responsible for providing virtualized execution environments. The impact -of the hypervisor on the real-time guarantees available with sun4v has not -yet been determined. +The defining feature that separates the sun4v architecture from its predecessor +is the existence of a super-privileged hypervisor that is responsible for +providing virtualized execution environments. The impact of the hypervisor on +the real-time guarantees available with sun4v has not yet been determined. CPU Model Dependent Features ============================ @@ -48,42 +51,37 @@ CPU Model Dependent Features CPU Model Feature Flags ----------------------- -This section presents the set of features which vary across -SPARC-64 implementations and -are of importance to RTEMS. The set of CPU model feature macros -are defined in the file -cpukit/score/cpu/sparc64/sparc64.h based upon the particular -CPU model defined on the compilation command line. +This section presents the set of features which vary across SPARC-64 +implementations and are of importance to RTEMS. The set of CPU model feature +macros are defined in the file cpukit/score/cpu/sparc64/sparc64.h based upon +the particular CPU model defined on the compilation command line. CPU Model Name ~~~~~~~~~~~~~~ -The macro CPU MODEL NAME is a string which designates -the name of this CPU model. -For example, for the UltraSPARC T1 SPARC V9 model, -this macro is set to the string "sun4v". +The macro CPU MODEL NAME is a string which designates the name of this CPU +model. For example, for the UltraSPARC T1 SPARC V9 model, this macro is set to +the string "sun4v". Floating Point Unit ~~~~~~~~~~~~~~~~~~~ -The macro SPARC_HAS_FPU is set to 1 to indicate that -this CPU model has a hardware floating point unit and 0 -otherwise. +The macro SPARC_HAS_FPU is set to 1 to indicate that this CPU model has a +hardware floating point unit and 0 otherwise. Number of Register Windows ~~~~~~~~~~~~~~~~~~~~~~~~~~ -The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to -indicate the number of register window sets implemented by this -CPU model. The SPARC architecture allows for a maximum of -thirty-two register window sets although most implementations -only include eight. +The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to indicate the number of +register window sets implemented by this CPU model. The SPARC architecture +allows for a maximum of thirty-two register window sets although most +implementations only include eight. CPU Model Implementation Notes ------------------------------ -This section describes the implemenation dependencies of the -CPU Models sun4u and sun4v of the SPARC V9 architecture. +This section describes the implemenation dependencies of the CPU Models sun4u +and sun4v of the SPARC V9 architecture. sun4u Notes ~~~~~~~~~~~ @@ -95,19 +93,12 @@ sun4v Notes XXX -.. COMMENT: COPYRIGHT (c) 1988-2002. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - Calling Conventions =================== -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: +Each high-level language compiler generates subroutine entry and exit code +based upon a set of rules known as the compiler's calling convention. These +rules address the following issues: - register preservation and usage @@ -122,22 +113,19 @@ target processor are the same, different compilers may use different calling conventions. As a result, calling conventions are both processor and compiler dependent. -The following document also provides some conventions on the -global register usage in SPARC V9: -http://developers.sun.com/solaris/articles/sparcv9abi.html +The following document also provides some conventions on the global register +usage in SPARC V9: http://developers.sun.com/solaris/articles/sparcv9abi.html Programming Model ----------------- -This section discusses the programming model for the -SPARC architecture. +This section discusses the programming model for the SPARC architecture. Non-Floating Point Registers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The SPARC architecture defines thirty-two -non-floating point registers directly visible to the programmer. -These are divided into four sets: +The SPARC architecture defines thirty-two non-floating point registers directly +visible to the programmer. These are divided into four sets: - input registers @@ -147,16 +135,13 @@ These are divided into four sets: - global registers -Each register is referred to by either two or three -names in the SPARC reference manuals. First, the registers are -referred to as r0 through r31 or with the alternate notation -r[0] through r[31]. Second, each register is a member of one of -the four sets listed above. Finally, some registers have an -architecturally defined role in the programming model which -provides an alternate name. The following table describes the -mapping between the 32 registers and the register sets: - -.. code:: c +Each register is referred to by either two or three names in the SPARC +reference manuals. First, the registers are referred to as r0 through r31 or +with the alternate notation r[0] through r[31]. Second, each register is a +member of one of the four sets listed above. Finally, some registers have an +architecturally defined role in the programming model which provides an +alternate name. The following table describes the mapping between the 32 +registers and the register sets: +-----------------+----------------+------------------+ | Register Number | Register Names | Description | @@ -170,11 +155,9 @@ mapping between the 32 registers and the register sets: | 24 - 31 | i0 - i7 | Input Registers | +-----------------+----------------+------------------+ -As mentioned above, some of the registers serve -defined roles in the programming model. The following table -describes the role of each of these registers: - -.. code:: c +As mentioned above, some of the registers serve defined roles in the +programming model. The following table describes the role of each of these +registers: +---------------+----------------+----------------------+ | Register Name | Alternate Name | Description | @@ -192,22 +175,19 @@ describes the role of each of these registers: Floating Point Registers ~~~~~~~~~~~~~~~~~~~~~~~~ -The SPARC V9 architecture includes sixty-four, -thirty-two bit registers. These registers may be viewed as -follows: +The SPARC V9 architecture includes sixty-four, thirty-two bit registers. These +registers may be viewed as follows: -- 32 32-bit single precision floating point or integer registers - (f0, f1, ... f31) +- 32 32-bit single precision floating point or integer registers (f0, f1, + ... f31) -- 32 64-bit double precision floating point registers (f0, f2, - f4, ... f62) +- 32 64-bit double precision floating point registers (f0, f2, f4, ... f62) -- 16 128-bit extended precision floating point registers (f0, f4, - f8, ... f60) +- 16 128-bit extended precision floating point registers (f0, f4, f8, ... f60) -The floating point state register (fsr) specifies -the behavior of the floating point unit for rounding, contains -its condition codes, version specification, and trap information. +The floating point state register (fsr) specifies the behavior of the floating +point unit for rounding, contains its condition codes, version specification, +and trap information. Special Registers ~~~~~~~~~~~~~~~~~ @@ -215,12 +195,12 @@ Special Registers The SPARC architecture includes a number of special registers: *``Ancillary State Registers (ASRs)``* - The ancillary state registers (ASRs) are optional state registers that - may be privileged or nonprivileged. ASRs 16-31 are implementation- - dependent. The SPARC V9 ASRs include: y, ccr, asi, tick, pc, fprs. - The sun4u ASRs include: pcr, pic, dcr, gsr, softint set, softint clr, - softint, and tick cmpr. The sun4v ASRs include: pcr, pic, gsr, soft- - int set, softint clr, softint, tick cmpr, stick, and stick cmpr. + The ancillary state registers (ASRs) are optional state registers that may + be privileged or nonprivileged. ASRs 16-31 are implementation- + dependent. The SPARC V9 ASRs include: y, ccr, asi, tick, pc, fprs. The + sun4u ASRs include: pcr, pic, dcr, gsr, softint set, softint clr, softint, + and tick cmpr. The sun4v ASRs include: pcr, pic, gsr, soft- int set, + softint clr, softint, tick cmpr, stick, and stick cmpr. *``Processor State Register (pstate)``* The privileged pstate register contains control fields for the proces- @@ -232,161 +212,142 @@ The SPARC architecture includes a number of special registers: accepted. *``Trap Registers``* - The trap handling mechanism of the SPARC V9 includes a number of - registers, including: trap program counter (tpc), trap next pc (tnpc), - trap state (tstate), trap type (tt), trap base address (tba), and trap - level (tl). + The trap handling mechanism of the SPARC V9 includes a number of registers, + including: trap program counter (tpc), trap next pc (tnpc), trap state + (tstate), trap type (tt), trap base address (tba), and trap level (tl). *``Alternate Globals``* - The AG bit of the pstate register provides access to an alternate set - of global registers. On sun4v, the AG bit is replaced by the global - level (gl) register, providing access to at least two and at most eight - alternate sets of globals. + The AG bit of the pstate register provides access to an alternate set of + global registers. On sun4v, the AG bit is replaced by the global level (gl) + register, providing access to at least two and at most eight alternate sets + of globals. *``Register Window registers``* - A number of registers assist in register window management. - These include the current window pointer (cwp), savable windows - (cansave), restorable windows (canrestore), clean windows (clean- - win), other windows (otherwin), and window state (wstate). + A number of registers assist in register window management. These include + the current window pointer (cwp), savable windows (cansave), restorable + windows (canrestore), clean windows (clean- win), other windows (otherwin), + and window state (wstate). Register Windows ---------------- -The SPARC architecture includes the concept of -register windows. An overly simplistic way to think of these -windows is to imagine them as being an infinite supply of -"fresh" register sets available for each subroutine to use. In -reality, they are much more complicated. - -The save instruction is used to obtain a new register window. -This instruction increments the current window pointer, thus -providing a new set of registers for use. This register set -includes eight fresh local registers for use exclusively by -this subroutine. When done with a register set, the restore -instruction decrements the current window pointer and the -previous register set is once again available. - -The two primary issues complicating the use of register windows -are that (1) the set of register windows is finite, and (2) some -registers are shared between adjacent registers windows. - -Because the set of register windows is finite, it is -possible to execute enough save instructions without -corresponding restore's to consume all of the register windows. -This is easily accomplished in a high level language because -each subroutine typically performs a save instruction upon -entry. Thus having a subroutine call depth greater than the -number of register windows will result in a window overflow -condition. The window overflow condition generates a trap which -must be handled in software. The window overflow trap handler -is responsible for saving the contents of the oldest register -window on the program stack. - -Similarly, the subroutines will eventually complete -and begin to perform restore's. If the restore results in the -need for a register window which has previously been written to -memory as part of an overflow, then a window underflow condition -results. Just like the window overflow, the window 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 cansave, canrestore, otherwin, and cwp are used in conjunction -to manage the finite set of register windows and detect the window -overflow and underflow conditions. The first three of these -registers must satisfy the invariant cansave + canrestore + otherwin = -nwindow - 2, where nwindow is the number of register windows. -The cwp contains the index of the register window currently in use. -RTEMS does not use the cleanwin and otherwin registers. - -The save instruction increments the cwp modulo the number of -register windows, and if cansave is 0 then it also generates a -window overflow. Similarly, the restore instruction decrements the -cwp modulo the number of register windows, and if canrestore is 0 then it -also generates a window underflow. - -Unlike with the SPARC model, the SPARC-64 port does not assume that -a register window is available for a trap. The window overflow -and underflow conditions are not detected without hardware generating -the trap. (These conditions can be detected by reading the register window -registers and doing some simple arithmetic.) - -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 from 0 to 7 on most implementations. - -The second complicating factor is the sharing of -registers between adjacent register windows. While each -register window has its own set of local registers, the input -and output registers are shared between adjacent windows. The -output registers for register window N are the same as the input -registers for register window ((N + 1) modulo RW) where RW is -the number of register windows. An alternative way to think of -this is to remember how parameters are passed to a subroutine on -the SPARC. The caller loads values into what are its output -registers. Then after the callee executes a save instruction, -those parameters are available in its input registers. This is -a very efficient way to pass parameters as no data is actually -moved by the save or restore instructions. +The SPARC architecture includes the concept of register windows. An overly +simplistic way to think of these windows is to imagine them as being an +infinite supply of "fresh" register sets available for each subroutine to use. +In reality, they are much more complicated. + +The save instruction is used to obtain a new register window. This instruction +increments the current window pointer, thus providing a new set of registers +for use. This register set includes eight fresh local registers for use +exclusively by this subroutine. When done with a register set, the restore +instruction decrements the current window pointer and the previous register set +is once again available. + +The two primary issues complicating the use of register windows are that (1) +the set of register windows is finite, and (2) some registers are shared +between adjacent registers windows. + +Because the set of register windows is finite, it is possible to execute enough +save instructions without corresponding restore's to consume all of the +register windows. This is easily accomplished in a high level language because +each subroutine typically performs a save instruction upon entry. Thus having +a subroutine call depth greater than the number of register windows will result +in a window overflow condition. The window overflow condition generates a trap +which must be handled in software. The window overflow trap handler is +responsible for saving the contents of the oldest register window on the +program stack. + +Similarly, the subroutines will eventually complete and begin to perform +restore's. If the restore results in the need for a register window which has +previously been written to memory as part of an overflow, then a window +underflow condition results. Just like the window overflow, the window +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 cansave, canrestore, otherwin, and cwp are used in conjunction to manage +the finite set of register windows and detect the window overflow and underflow +conditions. The first three of these registers must satisfy the invariant +cansave + canrestore + otherwin = nwindow - 2, where nwindow is the number of +register windows. The cwp contains the index of the register window currently +in use. RTEMS does not use the cleanwin and otherwin registers. + +The save instruction increments the cwp modulo the number of register windows, +and if cansave is 0 then it also generates a window overflow. Similarly, the +restore instruction decrements the cwp modulo the number of register windows, +and if canrestore is 0 then it also generates a window underflow. + +Unlike with the SPARC model, the SPARC-64 port does not assume that a register +window is available for a trap. The window overflow and underflow conditions +are not detected without hardware generating the trap. (These conditions can be +detected by reading the register window registers and doing some simple +arithmetic.) + +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 +from 0 to 7 on most implementations. + +The second complicating factor is the sharing of registers between adjacent +register windows. While each register window has its own set of local +registers, the input and output registers are shared between adjacent windows. +The output registers for register window N are the same as the input registers +for register window ((N + 1) modulo RW) where RW is the number of register +windows. An alternative way to think of this is to remember how parameters are +passed to a subroutine on the SPARC. The caller loads values into what are its +output registers. Then after the callee executes a save instruction, those +parameters are available in its input registers. This is a very efficient way +to pass parameters as no data is actually moved by the save or restore +instructions. Call and Return Mechanism ------------------------- -The SPARC architecture supports a simple yet -effective call and return mechanism. A subroutine is invoked -via the call (call) instruction. This instruction places the -return address in the caller's output register 7 (o7). After -the callee executes a save instruction, this value is available -in input register 7 (i7) until the corresponding restore -instruction is executed. - -The callee returns to the caller via a jmp to the -return address. There is a delay slot following this -instruction which is commonly used to execute a restore -instruction - if a register window was allocated by this -subroutine. - -It is important to note that the SPARC subroutine -call and return mechanism does not automatically save and -restore any registers. This is accomplished via the save and -restore instructions which manage the set of registers windows. -This allows for the compiler to generate leaf-optimized functions +The SPARC architecture supports a simple yet effective call and return +mechanism. A subroutine is invoked via the call (call) instruction. This +instruction places the return address in the caller's output register 7 (o7). +After the callee executes a save instruction, this value is available in input +register 7 (i7) until the corresponding restore instruction is executed. + +The callee returns to the caller via a jmp to the return address. There is a +delay slot following this instruction which is commonly used to execute a +restore instruction - if a register window was allocated by this subroutine. + +It is important to note that the SPARC subroutine call and return mechanism +does not automatically save and restore any registers. This is accomplished +via the save and restore instructions which manage the set of registers +windows. This allows for the compiler to generate leaf-optimized functions that utilize the caller's output registers without using save and restore. Calling Mechanism ----------------- -All RTEMS directives are invoked using the regular -SPARC calling convention via the call instruction. +All RTEMS directives are invoked using the regular SPARC calling convention via +the call instruction. Register Usage -------------- -As discussed above, the call instruction does not -automatically save any registers. The save and restore -instructions are used to allocate and deallocate register -windows. When a register window is allocated, the new set of -local registers are available for the exclusive use of the -subroutine which allocated this register set. +As discussed above, the call instruction does not automatically save any +registers. The save and restore instructions are used to allocate and +deallocate register windows. When a register window is allocated, the new set +of local registers are available for the exclusive use of the subroutine which +allocated this register set. Parameter Passing ----------------- -RTEMS assumes that arguments are placed in the -caller's output registers with the first argument in output -register 0 (o0), the second argument in output register 1 (o1), -and so forth. Until the callee executes a save instruction, the -parameters are still visible in the output registers. After the -callee executes a save instruction, the parameters are visible -in the corresponding input registers. The following pseudo-code -illustrates the typical sequence used to call a RTEMS directive -with three (3) arguments: -.. code:: c +RTEMS assumes that arguments are placed in the caller's output registers with +the first argument in output register 0 (o0), the second argument in output +register 1 (o1), and so forth. Until the callee executes a save instruction, +the parameters are still visible in the output registers. After the callee +executes a save instruction, the parameters are visible in the corresponding +input registers. The following pseudo-code illustrates the typical sequence +used to call a RTEMS directive with three (3) arguments: + +.. code-block:: c load third argument into o2 load second argument into o1 @@ -396,44 +357,34 @@ with three (3) arguments: User-Provided Routines ---------------------- -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these calling conventions. - -.. COMMENT: COPYRIGHT (c) 1988-2002. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. +All user-provided routines invoked by RTEMS, such as user extensions, device +drivers, and MPCI routines, must also adhere to these calling conventions. Memory Model ============ -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. +A processor may support any combination of memory models ranging from pure +physical addressing to complex demand paged virtual memory systems. RTEMS +supports a flat memory model which ranges contiguously over the processor's +allowable address space. RTEMS does not support segmentation or virtual memory +of any kind. The appropriate memory model for RTEMS provided by the targeted +processor and related characteristics of that model are described in this +chapter. Flat Memory Model ----------------- -The SPARC-64 architecture supports a flat 64-bit address space with -addresses ranging from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF. -Each address is represented by a 64-bit value (and an 8-bit address -space identifider or ASI) and is byte addressable. The address -may be used to reference a single byte, half-word (2-bytes), -word (4 bytes), doubleword (8 bytes), or quad-word (16 bytes). -Memory accesses within this address space are performed -in big endian fashion by the SPARC. Memory accesses which are not -properly aligned generate a "memory address not aligned" trap -(type number 0x34). The following table lists the alignment -requirements for a variety of data accesses: +The SPARC-64 architecture supports a flat 64-bit address space with addresses +ranging from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF. Each address is +represented by a 64-bit value (and an 8-bit address space identifider or ASI) +and is byte addressable. The address may be used to reference a single byte, +half-word (2-bytes), word (4 bytes), doubleword (8 bytes), or quad-word (16 +bytes). Memory accesses within this address space are performed in big endian +fashion by the SPARC. Memory accesses which are not properly aligned generate a +"memory address not aligned" trap (type number 0x34). The following table lists +the alignment requirements for a variety of data accesses: -.. code:: c +.. table:: +--------------+-----------------------+ | Data Type | Alignment Requirement | @@ -445,60 +396,47 @@ requirements for a variety of data accesses: | quadword | 16 | +--------------+-----------------------+ -RTEMS currently does not support any SPARC Memory Management -Units, therefore, virtual memory or segmentation systems -involving the SPARC are not supported. - -.. COMMENT: COPYRIGHT (c) 1988-2002. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. +RTEMS currently does not support any SPARC Memory Management Units, therefore, +virtual memory or segmentation systems involving the SPARC are not supported. Interrupt Processing ==================== -RTEMS and associated documentation uses the terms -interrupt and vector. In the SPARC architecture, these terms -correspond to traps and trap type, respectively. The terms will -be used interchangeably in this manual. Note that in the SPARC manuals, -interrupts are a subset of the traps that are delivered to software -interrupt handlers. +RTEMS and associated documentation uses the terms interrupt and vector. In the +SPARC architecture, these terms correspond to traps and trap type, +respectively. The terms will be used interchangeably in this manual. Note that +in the SPARC manuals, interrupts are a subset of the traps that are delivered +to software interrupt handlers. Synchronous Versus Asynchronous Traps ------------------------------------- -The SPARC architecture includes two classes of traps: -synchronous (precise) and asynchronous (deferred). -Asynchronous traps occur when an -external event interrupts the processor. These traps are not -associated with any instruction executed by the processor and -logically occur between instructions. The instruction currently -in the execute stage of the processor is allowed to complete -although subsequent instructions are annulled. The return -address reported by the processor for asynchronous traps is the -pair of instructions following the current instruction. - -Synchronous traps are caused by the actions of an -instruction. The trap stimulus in this case either occurs -internally to the processor or is from an external signal that -was provoked by the instruction. These traps are taken -immediately and the instruction that caused the trap is aborted -before any 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. +The SPARC architecture includes two classes of traps: synchronous (precise) and +asynchronous (deferred). Asynchronous traps occur when an external event +interrupts the processor. These traps are not associated with any instruction +executed by the processor and logically occur between instructions. The +instruction currently in the execute stage of the processor is allowed to +complete although subsequent instructions are annulled. The return address +reported by the processor for asynchronous traps is the pair of instructions +following the current instruction. + +Synchronous traps are caused by the actions of an instruction. The trap +stimulus in this case either occurs internally to the processor or is from an +external signal that was provoked by the instruction. These traps are taken +immediately and the instruction that caused the trap is aborted before any +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. Vectoring of Interrupt Handler ------------------------------ -Upon receipt of an interrupt the SPARC automatically -performs the following actions: +Upon receipt of an interrupt the SPARC automatically performs the following +actions: -- The trap level is set. This provides access to a fresh set of - privileged trap-state registers used to save the current state, - in effect, pushing a frame on the trap stack. - TL <- TL + 1 +- The trap level is set. This provides access to a fresh set of privileged + trap-state registers used to save the current state, in effect, pushing a + frame on the trap stack. TL <- TL + 1 - Existing state is preserved - TSTATE[TL].CCR <- CCR @@ -536,33 +474,30 @@ performs the following actions: - where (TL>0) is 0 if TL = 0, and 1 if TL > 0. 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. +enabled to allow for the possibility of register window overflow and underflow +traps. -If the interrupt handler was installed as an RTEMS -interrupt handler, then upon receipt of the interrupt, the -processor passes control to the RTEMS interrupt handler which -performs the following actions: +If the interrupt handler was installed as an RTEMS interrupt handler, then upon +receipt of the interrupt, the processor passes control to the RTEMS interrupt +handler which performs the following actions: - saves the state of the interrupted task on it's stack, - switches the processor to trap level 0, -- if this is the outermost (i.e. non-nested) interrupt, - then the RTEMS interrupt handler switches from the current stack - to the interrupt stack, +- if this is the outermost (i.e. non-nested) interrupt, then the RTEMS + interrupt handler switches from the current stack to the interrupt stack, - enables traps, - invokes the vectors to a user interrupt service routine (ISR). -Asynchronous interrupts are ignored while traps are -disabled. Synchronous traps which occur while traps are -disabled may result in the CPU being forced into an error mode. +Asynchronous interrupts are ignored while traps are disabled. Synchronous +traps which occur while traps are disabled may result in the CPU being forced +into an error mode. -A nested interrupt is processed similarly with the -exception that the current stack need not be switched to the -interrupt stack. +A nested interrupt is processed similarly with the exception that the current +stack need not be switched to the interrupt stack. Traps and Register Windows -------------------------- @@ -572,18 +507,16 @@ XXX Interrupt Levels ---------------- -Sixteen levels (0-15) of interrupt priorities are -supported by the SPARC architecture with level fifteen (15) -being the highest priority. Level zero (0) indicates that -interrupts are fully enabled. Interrupt requests for interrupts -with priorities less than or equal to the current interrupt mask +Sixteen levels (0-15) of interrupt priorities are supported by the SPARC +architecture with level fifteen (15) being the highest priority. Level +zero (0) indicates that interrupts are fully enabled. Interrupt requests for +interrupts with priorities less than or equal to the current interrupt mask level are ignored. -Although RTEMS supports 256 interrupt levels, the -SPARC only supports sixteen. RTEMS interrupt levels 0 through -15 directly correspond to SPARC processor interrupt levels. All -other RTEMS interrupt levels are undefined and their behavior is -unpredictable. +Although RTEMS supports 256 interrupt levels, the SPARC only supports sixteen. +RTEMS interrupt levels 0 through 15 directly correspond to SPARC processor +interrupt levels. All other RTEMS interrupt levels are undefined and their +behavior is unpredictable. Disabling of Interrupts by RTEMS -------------------------------- @@ -593,50 +526,38 @@ XXX 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 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 interrupt stack before invoking the installed handler. +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 +interrupt stack managed by software. -.. COMMENT: COPYRIGHT (c) 1988-2002. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. +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 +interrupt stack before invoking the installed handler. Default Fatal Error Processing ============================== -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. +Upon detection of a fatal error by either the application or RTEMS the fatal +error manager is invoked. The fatal error manager will invoke the +user-supplied fatal error handlers. If no user-supplied handlers are +configured, the RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the default fatal +error handler is then invoked. This chapter describes the precise operations +of the default fatal error handler. Default Fatal Error Handler Operations -------------------------------------- -The default fatal error handler which is invoked by -the fatal_error_occurred directive when there is no user handler -configured or the user handler returns control to RTEMS. The -default fatal error handler disables processor interrupts to -level 15, places the error code in g1, and goes into an infinite +The default fatal error handler which is invoked by the fatal_error_occurred +directive when there is no user handler configured or the user handler returns +control to RTEMS. The default fatal error handler disables processor +interrupts to level 15, places the error code in g1, and goes into an infinite loop to simulate a halt processor instruction. Symmetric Multiprocessing @@ -649,30 +570,22 @@ Thread-Local Storage Thread-local storage is supported. -.. COMMENT: COPYRIGHT (c) 1988-2002. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - Board Support Packages ====================== -An RTEMS Board Support Package (BSP) must be designed -to support a particular processor and target board combination. -This chapter presents a discussion of SPARC specific BSP issues. -For more information on developing a BSP, refer to the chapter -titled Board Support Packages in the RTEMS -Applications User's Guide. +An RTEMS Board Support Package (BSP) must be designed to support a particular +processor and target board combination. This chapter presents a discussion of +SPARC specific BSP issues. For more information on developing a BSP, refer to +the chapter titled Board Support Packages in the RTEMS Applications User's +Guide. HelenOS and Open Firmware ------------------------- -The provided BSPs make use of some bootstrap and low-level hardware code -of the HelenOS operating system. These files can be found in the shared/helenos -directory of the sparc64 bsp directory. Consult the sources for more -detailed information. +The provided BSPs make use of some bootstrap and low-level hardware code of the +HelenOS operating system. These files can be found in the shared/helenos +directory of the sparc64 bsp directory. Consult the sources for more detailed +information. The shared BSP code also uses the Open Firmware interface to re-use firmware code, primarily for console support and default trap handlers. - -- cgit v1.2.3