source: rtems-docs/cpu-supplement/sparc64.rst @ 67195aa

Last change on this file since 67195aa was 6916004, checked in by Chris Johns <chrisj@…>, on Nov 9, 2016 at 1:39:16 AM

cpu-supplement: Fix header levels.

  • Property mode set to 100644
File size: 23.8 KB
[489740f]1.. comment SPDX-License-Identifier: CC-BY-SA-4.0
[f233256]3.. COMMENT: COPYRIGHT (c) 1988-2002.
4.. COMMENT: On-Line Applications Research Corporation (OAR).
5.. COMMENT: All rights reserved.
[d755cbd]7SPARC-64 Specific Information
10This document discusses the SPARC Version 9 (aka SPARC-64, SPARC64 or SPARC V9)
11architecture dependencies in this port of RTEMS.
13The SPARC V9 architecture leaves a lot of undefined implemenation dependencies
14which are defined by the processor models. Consult the specific CPU model
15section in this document for additional documents covering the implementation
16dependent architectural features.
18**sun4u Specific Information**
20sun4u is the subset of the SPARC V9 implementations comprising the UltraSPARC I
21through UltraSPARC IV processors.
23The following documents were used in developing the SPARC-64 sun4u port:
[d389819]25- UltraSPARC  User's Manual
[d755cbd]26  (
[f233256]28- UltraSPARC IIIi Processor (
30**sun4v Specific Information**
[f233256]32sun4v is the subset of the SPARC V9 implementations comprising the UltraSPARC
33T1 or T2 processors.
35The following documents were used in developing the SPARC-64 sun4v port:
37- UltraSPARC Architecture 2005 Specification
38  (
40- UltraSPARC T1 supplement to UltraSPARC Architecture 2005 Specification
41  (
[f233256]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.
48CPU Model Dependent Features
51CPU Model Feature Flags
[f233256]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.
59CPU Model Name
[f233256]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".
66Floating Point Unit
[f233256]69The macro SPARC_HAS_FPU is set to 1 to indicate that this CPU model has a
70hardware floating point unit and 0 otherwise.
72Number of Register Windows
[f233256]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.
80CPU Model Implementation Notes
[f233256]83This section describes the implemenation dependencies of the CPU Models sun4u
84and sun4v of the SPARC V9 architecture.
86sun4u Notes
91sun4v Notes
96Calling Conventions
[f233256]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:
103- register preservation and usage
105- parameter passing
107- call and return mechanism
[d389819]109A compiler's calling convention is of importance when
[d755cbd]110interfacing to subroutines written in another language either
111assembly or high-level.  Even when the high-level language and
112target processor are the same, different compilers may use
113different calling conventions.  As a result, calling conventions
114are both processor and compiler dependent.
[f233256]116The following document also provides some conventions on the global register
117usage in SPARC V9:
119Programming Model
[f233256]122This section discusses the programming model for the SPARC architecture.
124Non-Floating Point Registers
[f233256]127The SPARC architecture defines thirty-two non-floating point registers directly
128visible to the programmer.  These are divided into four sets:
130- input registers
132- local registers
134- output registers
136- global registers
[f233256]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:
[0c97890]146================ ================ ===================
147Register Number  Register Names   Description
148================ ================ ===================
1490 - 7            g0 - g7          Global Registers
1508 - 15           o0 - o7          Output Registers
15116 - 23          l0 - l7          Local Registers
15224 - 31          i0 - i7          Input Registers
153================ ================ ===================
[f233256]155As mentioned above, some of the registers serve defined roles in the
156programming model.  The following table describes the role of each of these
[0c97890]159============== ================ ==================================
160Register Name  Alternate Name   Description
161============== ================ ==================================
162g0             na               reads return 0, writes are ignored
163o6             sp               stack pointer
164i6             fp               frame pointer
165i7             na               return address
166============== ================ ==================================
168Floating Point Registers
[f233256]171The SPARC V9 architecture includes sixty-four, thirty-two bit registers.  These
172registers may be viewed as follows:
[f233256]174- 32 32-bit single precision floating point or integer registers (f0, f1,
175  ... f31)
[f233256]177- 32 64-bit double precision floating point registers (f0, f2, f4, ... f62)
[f233256]179- 16 128-bit extended precision floating point registers (f0, f4, f8, ... f60)
[f233256]181The floating point state register (fsr) specifies the behavior of the floating
182point unit for rounding, contains its condition codes, version specification,
183and trap information.
185Special Registers
188The SPARC architecture includes a number of special registers:
190*``Ancillary State Registers (ASRs)``*
[f233256]191    The ancillary state registers (ASRs) are optional state registers that may
192    be privileged or nonprivileged. ASRs 16-31 are implementation-
193    dependent. The SPARC V9 ASRs include: y, ccr, asi, tick, pc, fprs.  The
194    sun4u ASRs include: pcr, pic, dcr, gsr, softint set, softint clr, softint,
195    and tick cmpr. The sun4v ASRs include: pcr, pic, gsr, soft- int set,
196    softint clr, softint, tick cmpr, stick, and stick cmpr.
198*``Processor State Register (pstate)``*
199    The privileged pstate register contains control fields for the proces-
[d389819]200    sor's current state. Its flag fields include the interrupt enable, privi-
[d755cbd]201    leged mode, and enable FPU.
203*``Processor Interrupt Level (pil)``*
204    The PIL specifies the interrupt level above which interrupts will be
205    accepted.
207*``Trap Registers``*
[f233256]208    The trap handling mechanism of the SPARC V9 includes a number of registers,
209    including: trap program counter (tpc), trap next pc (tnpc), trap state
210    (tstate), trap type (tt), trap base address (tba), and trap level (tl).
212*``Alternate Globals``*
[f233256]213    The AG bit of the pstate register provides access to an alternate set of
214    global registers. On sun4v, the AG bit is replaced by the global level (gl)
215    register, providing access to at least two and at most eight alternate sets
216    of globals.
218*``Register Window registers``*
[f233256]219    A number of registers assist in register window management.  These include
220    the current window pointer (cwp), savable windows (cansave), restorable
221    windows (canrestore), clean windows (clean- win), other windows (otherwin),
222    and window state (wstate).
224Register Windows
[f233256]227The SPARC architecture includes the concept of register windows.  An overly
228simplistic way to think of these windows is to imagine them as being an
229infinite supply of "fresh" register sets available for each subroutine to use.
230In reality, they are much more complicated.
232The save instruction is used to obtain a new register window.  This instruction
233increments the current window pointer, thus providing a new set of registers
234for use. This register set includes eight fresh local registers for use
235exclusively by this subroutine. When done with a register set, the restore
236instruction decrements the current window pointer and the previous register set
237is once again available.
239The two primary issues complicating the use of register windows are that (1)
240the set of register windows is finite, and (2) some registers are shared
241between adjacent registers windows.
243Because the set of register windows is finite, it is possible to execute enough
244save instructions without corresponding restore's to consume all of the
245register windows.  This is easily accomplished in a high level language because
246each subroutine typically performs a save instruction upon entry.  Thus having
247a subroutine call depth greater than the number of register windows will result
248in a window overflow condition.  The window overflow condition generates a trap
249which must be handled in software.  The window overflow trap handler is
250responsible for saving the contents of the oldest register window on the
251program stack.
253Similarly, the subroutines will eventually complete and begin to perform
254restore's.  If the restore results in the need for a register window which has
255previously been written to memory as part of an overflow, then a window
256underflow condition results.  Just like the window overflow, the window
257underflow condition must be handled in software by a trap handler.  The window
258underflow trap handler is responsible for reloading the contents of the
259register window requested by the restore instruction from the program stack.
261The cansave, canrestore, otherwin, and cwp are used in conjunction to manage
262the finite set of register windows and detect the window overflow and underflow
263conditions. The first three of these registers must satisfy the invariant
264cansave + canrestore + otherwin = nwindow - 2, where nwindow is the number of
265register windows.  The cwp contains the index of the register window currently
266in use.  RTEMS does not use the cleanwin and otherwin registers.
268The save instruction increments the cwp modulo the number of register windows,
269and if cansave is 0 then it also generates a window overflow. Similarly, the
270restore instruction decrements the cwp modulo the number of register windows,
271and if canrestore is 0 then it also generates a window underflow.
273Unlike with the SPARC model, the SPARC-64 port does not assume that a register
274window is available for a trap. The window overflow and underflow conditions
275are not detected without hardware generating the trap. (These conditions can be
276detected by reading the register window registers and doing some simple
279The window overflow and window underflow trap handlers are a critical part of
280the run-time environment for a SPARC application.  The SPARC architectural
281specification allows for the number of register windows to be any power of two
282less than or equal to 32.  The most common choice for SPARC implementations
283appears to be 8 register windows.  This results in the cwp ranging in value
284from 0 to 7 on most implementations.
286The second complicating factor is the sharing of registers between adjacent
287register windows.  While each register window has its own set of local
288registers, the input and output registers are shared between adjacent windows.
289The output registers for register window N are the same as the input registers
290for register window ((N + 1) modulo RW) where RW is the number of register
291windows.  An alternative way to think of this is to remember how parameters are
292passed to a subroutine on the SPARC.  The caller loads values into what are its
293output registers.  Then after the callee executes a save instruction, those
294parameters are available in its input registers.  This is a very efficient way
295to pass parameters as no data is actually moved by the save or restore
298Call and Return Mechanism
[f233256]301The SPARC architecture supports a simple yet effective call and return
302mechanism.  A subroutine is invoked via the call (call) instruction.  This
303instruction places the return address in the caller's output register 7 (o7).
304After the callee executes a save instruction, this value is available in input
305register 7 (i7) until the corresponding restore instruction is executed.
307The callee returns to the caller via a jmp to the return address.  There is a
308delay slot following this instruction which is commonly used to execute a
309restore instruction - if a register window was allocated by this subroutine.
311It is important to note that the SPARC subroutine call and return mechanism
312does not automatically save and restore any registers.  This is accomplished
313via the save and restore instructions which manage the set of registers
314windows.  This allows for the compiler to generate leaf-optimized functions
[d389819]315that utilize the caller's output registers without using save and restore.
317Calling Mechanism
[f233256]320All RTEMS directives are invoked using the regular SPARC calling convention via
321the call instruction.
323Register Usage
[f233256]326As discussed above, the call instruction does not automatically save any
327registers.  The save and restore instructions are used to allocate and
328deallocate register windows.  When a register window is allocated, the new set
329of local registers are available for the exclusive use of the subroutine which
330allocated this register set.
332Parameter Passing
[f233256]335RTEMS assumes that arguments are placed in the caller's output registers with
336the first argument in output register 0 (o0), the second argument in output
337register 1 (o1), and so forth.  Until the callee executes a save instruction,
338the parameters are still visible in the output registers.  After the callee
339executes a save instruction, the parameters are visible in the corresponding
340input registers.  The following pseudo-code illustrates the typical sequence
341used to call a RTEMS directive with three (3) arguments:
343.. code-block:: c
345    load third argument into o2
346    load second argument into o1
347    load first argument into o0
348    invoke directive
350User-Provided Routines
[f233256]353All user-provided routines invoked by RTEMS, such as user extensions, device
354drivers, and MPCI routines, must also adhere to these calling conventions.
356Memory Model
[f233256]359A processor may support any combination of memory models ranging from pure
360physical addressing to complex demand paged virtual memory systems.  RTEMS
361supports a flat memory model which ranges contiguously over the processor's
362allowable address space.  RTEMS does not support segmentation or virtual memory
363of any kind.  The appropriate memory model for RTEMS provided by the targeted
364processor and related characteristics of that model are described in this
367Flat Memory Model
[f233256]370The SPARC-64 architecture supports a flat 64-bit address space with addresses
371ranging from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF.  Each address is
372represented by a 64-bit value (and an 8-bit address space identifider or ASI)
373and is byte addressable. The address may be used to reference a single byte,
374half-word (2-bytes), word (4 bytes), doubleword (8 bytes), or quad-word (16
375bytes).  Memory accesses within this address space are performed in big endian
376fashion by the SPARC. Memory accesses which are not properly aligned generate a
377"memory address not aligned" trap (type number 0x34). The following table lists
378the alignment requirements for a variety of data accesses:
[0c97890]380==============  ======================
381Data Type       Alignment Requirement
382==============  ======================
383byte            1
384half-word       2
385word            4
386doubleword      8
387quadword        16
388==============  ======================
[f233256]390RTEMS currently does not support any SPARC Memory Management Units, therefore,
391virtual memory or segmentation systems involving the SPARC are not supported.
393Interrupt Processing
[f233256]396RTEMS and associated documentation uses the terms interrupt and vector.  In the
397SPARC architecture, these terms correspond to traps and trap type,
398respectively.  The terms will be used interchangeably in this manual. Note that
399in the SPARC manuals, interrupts are a subset of the traps that are delivered
400to software interrupt handlers.
402Synchronous Versus Asynchronous Traps
[f233256]405The SPARC architecture includes two classes of traps: synchronous (precise) and
406asynchronous (deferred).  Asynchronous traps occur when an external event
407interrupts the processor.  These traps are not associated with any instruction
408executed by the processor and logically occur between instructions.  The
409instruction currently in the execute stage of the processor is allowed to
410complete although subsequent instructions are annulled.  The return address
411reported by the processor for asynchronous traps is the pair of instructions
412following the current instruction.
414Synchronous traps are caused by the actions of an instruction.  The trap
415stimulus in this case either occurs internally to the processor or is from an
416external signal that was provoked by the instruction.  These traps are taken
417immediately and the instruction that caused the trap is aborted before any
418state changes occur in the processor itself.  The return address reported by
419the processor for synchronous traps is the instruction which caused the trap
420and the following instruction.
422Vectoring of Interrupt Handler
[f233256]425Upon receipt of an interrupt the SPARC automatically performs the following
[f233256]428- The trap level is set. This provides access to a fresh set of privileged
429  trap-state registers used to save the current state, in effect, pushing a
430  frame on the trap stack.  TL <- TL + 1
432- Existing state is preserved
433  - TSTATE[TL].CCR <- CCR
434  - TSTATE[TL].ASI <- ASI
436  - TSTATE[TL].CWP <- CWP
437  - TPC[TL] <- PC
438  - TNPC[TL] <- nPC
440- The trap type is preserved. TT[TL] <- the trap type
442- The PSTATE register is updated to a predefined state
443  - PSTATE.MM is unchanged
444  - PSTATE.RED <- 0
445  - PSTATE.PEF <- 1 if FPU is present, 0 otherwise
446  - PSTATE.AM <- 0 (address masking is turned off)
447  - PSTATE.PRIV <- 1 (the processor enters privileged mode)
448  - PSTATE.IE <- 0 (interrupts are disabled)
449  - PSTATE.AG <- 1 (global regs are replaced with alternate globals)
450  - PSTATE.CLE <- PSTATE.TLE (set endian mode for traps)
452- For a register-window trap only, CWP is set to point to the register
453  window that must be accessed by the trap-handler software, that is:
455  - If TT[TL] = 0x24 (a clean window trap), then CWP <- CWP + 1.
456  - If (0x80 <= TT[TL] <= 0xBF) (window spill trap), then CWP <- CWP +
457    CANSAVE + 2.
458  - If (0xC0 <= TT[TL] <= 0xFF) (window fill trap), then CWP <- CWP1.
459  - For non-register-window traps, CWP is not changed.
461- Control is transferred into the trap table:
463  - PC <- TBA<63:15> (TL>0) TT[TL] 0 0000
464  - nPC <- TBA<63:15> (TL>0) TT[TL] 0 0100
465  - where (TL>0) is 0 if TL = 0, and 1 if TL > 0.
467In order to safely invoke a subroutine during trap handling, traps must be
[f233256]468enabled to allow for the possibility of register window overflow and underflow
[f233256]471If the interrupt handler was installed as an RTEMS interrupt handler, then upon
472receipt of the interrupt, the processor passes control to the RTEMS interrupt
473handler which performs the following actions:
[d389819]475- saves the state of the interrupted task on it's stack,
477- switches the processor to trap level 0,
[f233256]479- if this is the outermost (i.e. non-nested) interrupt, then the RTEMS
480  interrupt handler switches from the current stack to the interrupt stack,
482- enables traps,
484- invokes the vectors to a user interrupt service routine (ISR).
[f233256]486Asynchronous interrupts are ignored while traps are disabled.  Synchronous
487traps which occur while traps are disabled may result in the CPU being forced
488into an error mode.
[f233256]490A nested interrupt is processed similarly with the exception that the current
491stack need not be switched to the interrupt stack.
493Traps and Register Windows
498Interrupt Levels
[f233256]501Sixteen levels (0-15) of interrupt priorities are supported by the SPARC
502architecture with level fifteen (15) being the highest priority.  Level
503zero (0) indicates that interrupts are fully enabled.  Interrupt requests for
504interrupts with priorities less than or equal to the current interrupt mask
[d755cbd]505level are ignored.
[f233256]507Although RTEMS supports 256 interrupt levels, the SPARC only supports sixteen.
508RTEMS interrupt levels 0 through 15 directly correspond to SPARC processor
509interrupt levels.  All other RTEMS interrupt levels are undefined and their
510behavior is unpredictable.
512Disabling of Interrupts by RTEMS
517Interrupt Stack
[f233256]520The SPARC architecture does not provide for a dedicated interrupt stack.  Thus
521by default, trap handlers would execute on the stack of the RTEMS task which
522they interrupted.  This artificially inflates the stack requirements for each
523task since EVERY task stack would have to include enough space to account for
524the worst case interrupt stack requirements in addition to it's own worst case
525usage.  RTEMS addresses this problem on the SPARC by providing a dedicated
526interrupt stack managed by software.
[f233256]528During system initialization, RTEMS allocates the interrupt stack from the
529Workspace Area.  The amount of memory allocated for the interrupt stack is
530determined by the interrupt_stack_size field in the CPU Configuration Table.
531As part of processing a non-nested interrupt, RTEMS will switch to the
532interrupt stack before invoking the installed handler.
534Default Fatal Error Processing
[f233256]537Upon detection of a fatal error by either the application or RTEMS the fatal
538error manager is invoked.  The fatal error manager will invoke the
539user-supplied fatal error handlers.  If no user-supplied handlers are
540configured, the RTEMS provided default fatal error handler is invoked.  If the
541user-supplied fatal error handlers return to the executive the default fatal
542error handler is then invoked.  This chapter describes the precise operations
543of the default fatal error handler.
545Default Fatal Error Handler Operations
[f233256]548The default fatal error handler which is invoked by the fatal_error_occurred
549directive when there is no user handler configured or the user handler returns
550control to RTEMS.  The default fatal error handler disables processor
551interrupts to level 15, places the error code in g1, and goes into an infinite
[d755cbd]552loop to simulate a halt processor instruction.
554Symmetric Multiprocessing
557SMP is not supported.
559Thread-Local Storage
562Thread-local storage is supported.
564Board Support Packages
[f233256]567An RTEMS Board Support Package (BSP) must be designed to support a particular
568processor and target board combination.  This chapter presents a discussion of
569SPARC specific BSP issues.  For more information on developing a BSP, refer to
570the chapter titled Board Support Packages in the RTEMS Applications User's
573HelenOS and Open Firmware
[f233256]576The provided BSPs make use of some bootstrap and low-level hardware code of the
577HelenOS operating system. These files can be found in the shared/helenos
578directory of the sparc64 bsp directory.  Consult the sources for more detailed
581The shared BSP code also uses the Open Firmware interface to re-use firmware
582code, primarily for console support and default trap handlers.
Note: See TracBrowser for help on using the repository browser.