From 72a62ad88f82fe1ffee50024db4dd0f3fa5806f7 Mon Sep 17 00:00:00 2001 From: Chris Johns Date: Thu, 3 Nov 2016 16:58:08 +1100 Subject: Rename all manuals with an _ to have a -. It helps released naming of files. --- cpu_supplement/sparc64.rst | 582 --------------------------------------------- 1 file changed, 582 deletions(-) delete mode 100644 cpu_supplement/sparc64.rst (limited to 'cpu_supplement/sparc64.rst') diff --git a/cpu_supplement/sparc64.rst b/cpu_supplement/sparc64.rst deleted file mode 100644 index f2785ff..0000000 --- a/cpu_supplement/sparc64.rst +++ /dev/null @@ -1,582 +0,0 @@ -.. 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 -############################# - -This document discusses the SPARC Version 9 (aka SPARC-64, SPARC64 or SPARC V9) -architecture dependencies in this port of RTEMS. - -The SPARC V9 architecture leaves a lot of undefined implemenation dependencies -which are defined by the processor models. Consult the specific CPU model -section in this document for additional documents covering the implementation -dependent architectural features. - -**sun4u Specific Information** - -sun4u is the subset of the SPARC V9 implementations comprising the UltraSPARC I -through UltraSPARC IV processors. - -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 (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. - -The following documents were used in developing the SPARC-64 sun4v port: - -- UltraSPARC Architecture 2005 Specification - (http://opensparc-t1.sunsource.net/specs/UA2005-current-draft-P-EXT.pdf) - -- 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. - -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. - -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". - -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. - -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. - -CPU Model Implementation Notes ------------------------------- - -This section describes the implemenation dependencies of the CPU Models sun4u -and sun4v of the SPARC V9 architecture. - -sun4u Notes -~~~~~~~~~~~ - -XXX - -sun4v Notes ------------ - -XXX - -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: - -- register preservation and usage - -- parameter passing - -- call and return mechanism - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -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 - -Programming Model ------------------ - -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: - -- input registers - -- local registers - -- output registers - -- 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: - -================ ================ =================== -Register Number Register Names Description -================ ================ =================== -0 - 7 g0 - g7 Global Registers -8 - 15 o0 - o7 Output Registers -16 - 23 l0 - l7 Local Registers -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: - -============== ================ ================================== -Register Name Alternate Name Description -============== ================ ================================== -g0 na reads return 0, writes are ignored -o6 sp stack pointer -i6 fp frame pointer -i7 na return address -============== ================ ================================== - -Floating Point Registers -~~~~~~~~~~~~~~~~~~~~~~~~ - -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 64-bit double precision floating point registers (f0, f2, f4, ... f62) - -- 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. - -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. - -*``Processor State Register (pstate)``* - The privileged pstate register contains control fields for the proces- - sor's current state. Its flag fields include the interrupt enable, privi- - leged mode, and enable FPU. - -*``Processor Interrupt Level (pil)``* - The PIL specifies the interrupt level above which interrupts will be - 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). - -*``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. - -*``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). - -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. - -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 -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. - -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. - -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-block:: c - - load third argument into o2 - load second argument into o1 - load first argument into o0 - invoke directive - -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. - -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. - -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: - -============== ====================== -Data Type Alignment Requirement -============== ====================== -byte 1 -half-word 2 -word 4 -doubleword 8 -quadword 16 -============== ====================== - -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. - -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. - -Vectoring of Interrupt Handler ------------------------------- - -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 - -- Existing state is preserved - - TSTATE[TL].CCR <- CCR - - TSTATE[TL].ASI <- ASI - - TSTATE[TL].PSTATE <- PSTATE - - TSTATE[TL].CWP <- CWP - - TPC[TL] <- PC - - TNPC[TL] <- nPC - -- The trap type is preserved. TT[TL] <- the trap type - -- The PSTATE register is updated to a predefined state - - PSTATE.MM is unchanged - - PSTATE.RED <- 0 - - PSTATE.PEF <- 1 if FPU is present, 0 otherwise - - PSTATE.AM <- 0 (address masking is turned off) - - PSTATE.PRIV <- 1 (the processor enters privileged mode) - - PSTATE.IE <- 0 (interrupts are disabled) - - PSTATE.AG <- 1 (global regs are replaced with alternate globals) - - PSTATE.CLE <- PSTATE.TLE (set endian mode for traps) - -- For a register-window trap only, CWP is set to point to the register - window that must be accessed by the trap-handler software, that is: - - - If TT[TL] = 0x24 (a clean window trap), then CWP <- CWP + 1. - - If (0x80 <= TT[TL] <= 0xBF) (window spill trap), then CWP <- CWP + - CANSAVE + 2. - - If (0xC0 <= TT[TL] <= 0xFF) (window fill trap), then CWP <- CWP1. - - For non-register-window traps, CWP is not changed. - -- Control is transferred into the trap table: - - - PC <- TBA<63:15> (TL>0) TT[TL] 0 0000 - - nPC <- TBA<63:15> (TL>0) TT[TL] 0 0100 - - 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. - -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, - -- 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. - -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 --------------------------- - -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 -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. - -Disabling of Interrupts by RTEMS --------------------------------- - -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. - -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. - -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 -loop to simulate a halt processor instruction. - -Symmetric Multiprocessing -========================= - -SMP is not supported. - -Thread-Local Storage -==================== - -Thread-local storage is supported. - -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. - -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 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