source: rtems-docs/cpu_supplement/sparc64.rst @ 11e1a6f

4.115
Last change on this file since 11e1a6f was d755cbd, checked in by Amar Takhar <amar@…>, on 01/17/16 at 01:13:02

Split document into seperate files by section.

  • Property mode set to 100644
File size: 25.0 KB
Line 
1SPARC-64 Specific Information
2#############################
3
4This document discusses the SPARC Version 9 (aka SPARC-64, SPARC64 or SPARC V9)
5architecture dependencies in this port of RTEMS.
6
7The SPARC V9 architecture leaves a lot of undefined implemenation dependencies
8which are defined by the processor models. Consult the specific CPU model
9section in this document for additional documents covering the implementation
10dependent architectural features.
11
12**sun4u Specific Information**
13
14sun4u is the subset of the SPARC V9 implementations comprising the UltraSPARC I
15through UltraSPARC IV processors.
16
17The following documents were used in developing the SPARC-64 sun4u port:
18
19- UltraSPARC  User’s Manual
20  (http://www.sun.com/microelectronics/manuals/ultrasparc/802-7220-02.pdf)
21
22- UltraSPARC IIIi Processor (datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf)
23
24**sun4v Specific Information**
25
26sun4v is the subset of the SPARC V9 implementations comprising the
27UltraSPARC T1 or T2 processors.
28
29The following documents were used in developing the SPARC-64 sun4v port:
30
31- UltraSPARC Architecture 2005 Specification
32  (http://opensparc-t1.sunsource.net/specs/UA2005-current-draft-P-EXT.pdf)
33
34- UltraSPARC T1 supplement to UltraSPARC Architecture 2005 Specification
35  (http://opensparc-t1.sunsource.net/specs/UST1-UASuppl-current-draft-P-EXT.pdf)
36
37The defining feature that separates the sun4v architecture from its
38predecessor is the existence of a super-privileged hypervisor that
39is responsible for providing virtualized execution environments.  The impact
40of the hypervisor on the real-time guarantees available with sun4v has not
41yet been determined.
42
43CPU Model Dependent Features
44============================
45
46CPU Model Feature Flags
47-----------------------
48
49This section presents the set of features which vary across
50SPARC-64 implementations and
51are of importance to RTEMS. The set of CPU model feature macros
52are defined in the file
53cpukit/score/cpu/sparc64/sparc64.h based upon the particular
54CPU model defined on the compilation command line.
55
56CPU Model Name
57~~~~~~~~~~~~~~
58
59The macro CPU MODEL NAME is a string which designates
60the name of this CPU model.
61For example, for the UltraSPARC T1 SPARC V9 model,
62this macro is set to the string "sun4v".
63
64Floating Point Unit
65~~~~~~~~~~~~~~~~~~~
66
67The macro SPARC_HAS_FPU is set to 1 to indicate that
68this CPU model has a hardware floating point unit and 0
69otherwise.
70
71Number of Register Windows
72~~~~~~~~~~~~~~~~~~~~~~~~~~
73
74The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to
75indicate the number of register window sets implemented by this
76CPU model.  The SPARC architecture allows for a maximum of
77thirty-two register window sets although most implementations
78only include eight.
79
80CPU Model Implementation Notes
81------------------------------
82
83This section describes the implemenation dependencies of the
84CPU Models sun4u and sun4v of the SPARC V9 architecture.
85
86sun4u Notes
87~~~~~~~~~~~
88
89XXX
90
91sun4v Notes
92-----------
93
94XXX
95
96.. COMMENT: COPYRIGHT (c) 1988-2002.
97
98.. COMMENT: On-Line Applications Research Corporation (OAR).
99
100.. COMMENT: All rights reserved.
101
102Calling Conventions
103===================
104
105Each high-level language compiler generates
106subroutine entry and exit code based upon a set of rules known
107as the compiler’s calling convention.   These rules address the
108following issues:
109
110- register preservation and usage
111
112- parameter passing
113
114- call and return mechanism
115
116A compiler’s calling convention is of importance when
117interfacing to subroutines written in another language either
118assembly or high-level.  Even when the high-level language and
119target processor are the same, different compilers may use
120different calling conventions.  As a result, calling conventions
121are both processor and compiler dependent.
122
123The following document also provides some conventions on the
124global register usage in SPARC V9:
125http://developers.sun.com/solaris/articles/sparcv9abi.html
126
127Programming Model
128-----------------
129
130This section discusses the programming model for the
131SPARC architecture.
132
133Non-Floating Point Registers
134~~~~~~~~~~~~~~~~~~~~~~~~~~~~
135
136The SPARC architecture defines thirty-two
137non-floating point registers directly visible to the programmer.
138These are divided into four sets:
139
140- input registers
141
142- local registers
143
144- output registers
145
146- global registers
147
148Each register is referred to by either two or three
149names in the SPARC reference manuals.  First, the registers are
150referred to as r0 through r31 or with the alternate notation
151r[0] through r[31].  Second, each register is a member of one of
152the four sets listed above.  Finally, some registers have an
153architecturally defined role in the programming model which
154provides an alternate name.  The following table describes the
155mapping between the 32 registers and the register sets:
156
157.. code:: c
158
159    +-----------------+----------------+------------------+
160    | Register Number | Register Names |   Description    |
161    +-----------------+----------------+------------------+
162    |     0 - 7       |    g0 - g7     | Global Registers |
163    +-----------------+----------------+------------------+
164    |     8 - 15      |    o0 - o7     | Output Registers |
165    +-----------------+----------------+------------------+
166    |    16 - 23      |    l0 - l7     | Local Registers  |
167    +-----------------+----------------+------------------+
168    |    24 - 31      |    i0 - i7     | Input Registers  |
169    +-----------------+----------------+------------------+
170
171As mentioned above, some of the registers serve
172defined roles in the programming model.  The following table
173describes the role of each of these registers:
174
175.. code:: c
176
177    +---------------+----------------+----------------------+
178    | Register Name | Alternate Name |      Description     |
179    +---------------+----------------+----------------------+
180    |     g0        |      na        |    reads return 0    |
181    |               |                |  writes are ignored  |
182    +---------------+----------------+----------------------+
183    |     o6        |      sp        |     stack pointer    |
184    +---------------+----------------+----------------------+
185    |     i6        |      fp        |     frame pointer    |
186    +---------------+----------------+----------------------+
187    |     i7        |      na        |    return address    |
188    +---------------+----------------+----------------------+
189
190Floating Point Registers
191~~~~~~~~~~~~~~~~~~~~~~~~
192
193The SPARC V9 architecture includes sixty-four,
194thirty-two bit registers.  These registers may be viewed as
195follows:
196
197- 32 32-bit single precision floating point or integer registers
198  (f0, f1,  ... f31)
199
200- 32 64-bit double precision floating point registers (f0, f2,
201  f4, ... f62)
202
203- 16 128-bit extended precision floating point registers (f0, f4,
204  f8, ... f60)
205
206The floating point state register (fsr) specifies
207the behavior of the floating point unit for rounding, contains
208its condition codes, version specification, and trap information.
209
210Special Registers
211~~~~~~~~~~~~~~~~~
212
213The SPARC architecture includes a number of special registers:
214
215*``Ancillary State Registers (ASRs)``*
216    The ancillary state registers (ASRs) are optional state registers that
217    may be privileged or nonprivileged. ASRs 16-31 are implementation-
218    dependent. The SPARC V9 ASRs include: y, ccr, asi, tick, pc, fprs.
219    The sun4u ASRs include: pcr, pic, dcr, gsr, softint set, softint clr,
220    softint, and tick cmpr. The sun4v ASRs include: pcr, pic, gsr, soft-
221    int set, softint clr, softint, tick cmpr, stick, and stick cmpr.
222
223*``Processor State Register (pstate)``*
224    The privileged pstate register contains control fields for the proces-
225    sor’s current state. Its flag fields include the interrupt enable, privi-
226    leged mode, and enable FPU.
227
228*``Processor Interrupt Level (pil)``*
229    The PIL specifies the interrupt level above which interrupts will be
230    accepted.
231
232*``Trap Registers``*
233    The trap handling mechanism of the SPARC V9 includes a number of
234    registers, including: trap program counter (tpc), trap next pc (tnpc),
235    trap state (tstate), trap type (tt), trap base address (tba), and trap
236    level (tl).
237
238*``Alternate Globals``*
239    The AG bit of the pstate register provides access to an alternate set
240    of global registers. On sun4v, the AG bit is replaced by the global
241    level (gl) register, providing access to at least two and at most eight
242    alternate sets of globals.
243
244*``Register Window registers``*
245    A number of registers assist in register window management.
246    These include the current window pointer (cwp), savable windows
247    (cansave), restorable windows (canrestore), clean windows (clean-
248    win), other windows (otherwin), and window state (wstate).
249
250Register Windows
251----------------
252
253The SPARC architecture includes the concept of
254register windows.  An overly simplistic way to think of these
255windows is to imagine them as being an infinite supply of
256"fresh" register sets available for each subroutine to use.  In
257reality, they are much more complicated.
258
259The save instruction is used to obtain a new register window.
260This instruction increments the current window pointer, thus
261providing a new set of registers for use. This register set
262includes eight fresh local registers for use exclusively by
263this subroutine. When done with a register set, the restore
264instruction decrements the current window pointer and the
265previous register set is once again available.
266
267The two primary issues complicating the use of register windows
268are that (1) the set of register windows is finite, and (2) some
269registers are shared between adjacent registers windows.
270
271Because the set of register windows is finite, it is
272possible to execute enough save instructions without
273corresponding restore’s to consume all of the register windows.
274This is easily accomplished in a high level language because
275each subroutine typically performs a save instruction upon
276entry.  Thus having a subroutine call depth greater than the
277number of register windows will result in a window overflow
278condition.  The window overflow condition generates a trap which
279must be handled in software.  The window overflow trap handler
280is responsible for saving the contents of the oldest register
281window on the program stack.
282
283Similarly, the subroutines will eventually complete
284and begin to perform restore’s.  If the restore results in the
285need for a register window which has previously been written to
286memory as part of an overflow, then a window underflow condition
287results.  Just like the window overflow, the window underflow
288condition must be handled in software by a trap handler.  The
289window underflow trap handler is responsible for reloading the
290contents of the register window requested by the restore
291instruction from the program stack.
292
293The cansave, canrestore, otherwin, and cwp are used in conjunction
294to manage the finite set of register windows and detect the window
295overflow and underflow conditions. The first three of these
296registers must satisfy the invariant cansave + canrestore + otherwin =
297nwindow - 2, where nwindow is the number of register windows.
298The cwp contains the index of the register window currently in use.
299RTEMS does not use the cleanwin and otherwin registers.
300
301The save instruction increments the cwp modulo the number of
302register windows, and if cansave is 0 then it also generates a
303window overflow. Similarly, the restore instruction decrements the
304cwp modulo the number of register windows, and if canrestore is 0 then it
305also generates a window underflow.
306
307Unlike with the SPARC model, the SPARC-64 port does not assume that
308a register window is available for a trap. The window overflow
309and underflow conditions are not detected without hardware generating
310the trap. (These conditions can be detected by reading the register window
311registers and doing some simple arithmetic.)
312
313The window overflow and window underflow trap
314handlers are a critical part of the run-time environment for a
315SPARC application.  The SPARC architectural specification allows
316for the number of register windows to be any power of two less
317than or equal to 32.  The most common choice for SPARC
318implementations appears to be 8 register windows.  This results
319in the cwp ranging in value from 0 to 7 on most implementations.
320
321The second complicating factor is the sharing of
322registers between adjacent register windows.  While each
323register window has its own set of local registers, the input
324and output registers are shared between adjacent windows.  The
325output registers for register window N are the same as the input
326registers for register window ((N + 1) modulo RW) where RW is
327the number of register windows.  An alternative way to think of
328this is to remember how parameters are passed to a subroutine on
329the SPARC.  The caller loads values into what are its output
330registers.  Then after the callee executes a save instruction,
331those parameters are available in its input registers.  This is
332a very efficient way to pass parameters as no data is actually
333moved by the save or restore instructions.
334
335Call and Return Mechanism
336-------------------------
337
338The SPARC architecture supports a simple yet
339effective call and return mechanism.  A subroutine is invoked
340via the call (call) instruction.  This instruction places the
341return address in the caller’s output register 7 (o7).  After
342the callee executes a save instruction, this value is available
343in input register 7 (i7) until the corresponding restore
344instruction is executed.
345
346The callee returns to the caller via a jmp to the
347return address.  There is a delay slot following this
348instruction which is commonly used to execute a restore
349instruction – if a register window was allocated by this
350subroutine.
351
352It is important to note that the SPARC subroutine
353call and return mechanism does not automatically save and
354restore any registers.  This is accomplished via the save and
355restore instructions which manage the set of registers windows.
356This allows for the compiler to generate leaf-optimized functions
357that utilize the caller’s output registers without using save and restore.
358
359Calling Mechanism
360-----------------
361
362All RTEMS directives are invoked using the regular
363SPARC calling convention via the call instruction.
364
365Register Usage
366--------------
367
368As discussed above, the call instruction does not
369automatically save any registers.  The save and restore
370instructions are used to allocate and deallocate register
371windows.  When a register window is allocated, the new set of
372local registers are available for the exclusive use of the
373subroutine which allocated this register set.
374
375Parameter Passing
376-----------------
377
378RTEMS assumes that arguments are placed in the
379caller’s output registers with the first argument in output
380register 0 (o0), the second argument in output register 1 (o1),
381and so forth.  Until the callee executes a save instruction, the
382parameters are still visible in the output registers.  After the
383callee executes a save instruction, the parameters are visible
384in the corresponding input registers.  The following pseudo-code
385illustrates the typical sequence used to call a RTEMS directive
386with three (3) arguments:
387.. code:: c
388
389    load third argument into o2
390    load second argument into o1
391    load first argument into o0
392    invoke directive
393
394User-Provided Routines
395----------------------
396
397All user-provided routines invoked by RTEMS, such as
398user extensions, device drivers, and MPCI routines, must also
399adhere to these calling conventions.
400
401.. COMMENT: COPYRIGHT (c) 1988-2002.
402
403.. COMMENT: On-Line Applications Research Corporation (OAR).
404
405.. COMMENT: All rights reserved.
406
407Memory Model
408============
409
410A processor may support any combination of memory
411models ranging from pure physical addressing to complex demand
412paged virtual memory systems.  RTEMS supports a flat memory
413model which ranges contiguously over the processor’s allowable
414address space.  RTEMS does not support segmentation or virtual
415memory of any kind.  The appropriate memory model for RTEMS
416provided by the targeted processor and related characteristics
417of that model are described in this chapter.
418
419Flat Memory Model
420-----------------
421
422The SPARC-64 architecture supports a flat 64-bit address space with
423addresses ranging from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF.
424Each address is represented by a 64-bit value (and an 8-bit address
425space identifider or ASI) and is byte addressable. The address
426may be used to reference a single byte, half-word (2-bytes),
427word (4 bytes), doubleword (8 bytes), or quad-word (16 bytes).
428Memory accesses within this address space are performed
429in big endian fashion by the SPARC. Memory accesses which are not
430properly aligned generate a "memory address not aligned" trap
431(type number 0x34). The following table lists the alignment
432requirements for a variety of data accesses:
433
434.. code:: c
435
436    +--------------+-----------------------+
437    |   Data Type  | Alignment Requirement |
438    +--------------+-----------------------+
439    |     byte     |          1            |
440    |   half-word  |          2            |
441    |     word     |          4            |
442    |  doubleword  |          8            |
443    |   quadword   |          16           |
444    +--------------+-----------------------+
445
446RTEMS currently does not support any SPARC Memory Management
447Units, therefore, virtual memory or segmentation systems
448involving the SPARC are not supported.
449
450.. COMMENT: COPYRIGHT (c) 1988-2002.
451
452.. COMMENT: On-Line Applications Research Corporation (OAR).
453
454.. COMMENT: All rights reserved.
455
456Interrupt Processing
457====================
458
459RTEMS and associated documentation uses the terms
460interrupt and vector.  In the SPARC architecture, these terms
461correspond to traps and trap type, respectively.  The terms will
462be used interchangeably in this manual. Note that in the SPARC manuals,
463interrupts are a subset of the traps that are delivered to software
464interrupt handlers.
465
466Synchronous Versus Asynchronous Traps
467-------------------------------------
468
469The SPARC architecture includes two classes of traps:
470synchronous (precise) and asynchronous (deferred).
471Asynchronous traps occur when an
472external event interrupts the processor.  These traps are not
473associated with any instruction executed by the processor and
474logically occur between instructions.  The instruction currently
475in the execute stage of the processor is allowed to complete
476although subsequent instructions are annulled.  The return
477address reported by the processor for asynchronous traps is the
478pair of instructions following the current instruction.
479
480Synchronous traps are caused by the actions of an
481instruction.  The trap stimulus in this case either occurs
482internally to the processor or is from an external signal that
483was provoked by the instruction.  These traps are taken
484immediately and the instruction that caused the trap is aborted
485before any state changes occur in the processor itself.   The
486return address reported by the processor for synchronous traps
487is the instruction which caused the trap and the following
488instruction.
489
490Vectoring of Interrupt Handler
491------------------------------
492
493Upon receipt of an interrupt the SPARC automatically
494performs the following actions:
495
496- The trap level is set. This provides access to a fresh set of
497  privileged trap-state registers used to save the current state,
498  in effect, pushing a frame on the trap stack.
499  TL <- TL + 1
500
501- Existing state is preserved
502  - TSTATE[TL].CCR <- CCR
503  - TSTATE[TL].ASI <- ASI
504  - TSTATE[TL].PSTATE <- PSTATE
505  - TSTATE[TL].CWP <- CWP
506  - TPC[TL] <- PC
507  - TNPC[TL] <- nPC
508
509- The trap type is preserved. TT[TL] <- the trap type
510
511- The PSTATE register is updated to a predefined state
512  - PSTATE.MM is unchanged
513  - PSTATE.RED <- 0
514  - PSTATE.PEF <- 1 if FPU is present, 0 otherwise
515  - PSTATE.AM <- 0 (address masking is turned off)
516  - PSTATE.PRIV <- 1 (the processor enters privileged mode)
517  - PSTATE.IE <- 0 (interrupts are disabled)
518  - PSTATE.AG <- 1 (global regs are replaced with alternate globals)
519  - PSTATE.CLE <- PSTATE.TLE (set endian mode for traps)
520
521- For a register-window trap only, CWP is set to point to the register
522  window that must be accessed by the trap-handler software, that is:
523
524  - If TT[TL] = 0x24 (a clean window trap), then CWP <- CWP + 1.
525  - If (0x80 <= TT[TL] <= 0xBF) (window spill trap), then CWP <- CWP +
526    CANSAVE + 2.
527  - If (0xC0 <= TT[TL] <= 0xFF) (window fill trap), then CWP <- CWP1.
528  - For non-register-window traps, CWP is not changed.
529
530- Control is transferred into the trap table:
531
532  - PC <- TBA<63:15> (TL>0) TT[TL] 0 0000
533  - nPC <- TBA<63:15> (TL>0) TT[TL] 0 0100
534  - where (TL>0) is 0 if TL = 0, and 1 if TL > 0.
535
536In order to safely invoke a subroutine during trap handling, traps must be
537enabled to allow for the possibility of register window overflow and
538underflow traps.
539
540If the interrupt handler was installed as an RTEMS
541interrupt handler, then upon receipt of the interrupt, the
542processor passes control to the RTEMS interrupt handler which
543performs the following actions:
544
545- saves the state of the interrupted task on it’s stack,
546
547- switches the processor to trap level 0,
548
549- if this is the outermost (i.e. non-nested) interrupt,
550  then the RTEMS interrupt handler switches from the current stack
551  to the interrupt stack,
552
553- enables traps,
554
555- invokes the vectors to a user interrupt service routine (ISR).
556
557Asynchronous interrupts are ignored while traps are
558disabled.  Synchronous traps which occur while traps are
559disabled may result in the CPU being forced into an error mode.
560
561A nested interrupt is processed similarly with the
562exception that the current stack need not be switched to the
563interrupt stack.
564
565Traps and Register Windows
566--------------------------
567
568XXX
569
570Interrupt Levels
571----------------
572
573Sixteen levels (0-15) of interrupt priorities are
574supported by the SPARC architecture with level fifteen (15)
575being the highest priority.  Level zero (0) indicates that
576interrupts are fully enabled.  Interrupt requests for interrupts
577with priorities less than or equal to the current interrupt mask
578level are ignored.
579
580Although RTEMS supports 256 interrupt levels, the
581SPARC only supports sixteen.  RTEMS interrupt levels 0 through
58215 directly correspond to SPARC processor interrupt levels.  All
583other RTEMS interrupt levels are undefined and their behavior is
584unpredictable.
585
586Disabling of Interrupts by RTEMS
587--------------------------------
588
589XXX
590
591Interrupt Stack
592---------------
593
594The SPARC architecture does not provide for a
595dedicated interrupt stack.  Thus by default, trap handlers would
596execute on the stack of the RTEMS task which they interrupted.
597This artificially inflates the stack requirements for each task
598since EVERY task stack would have to include enough space to
599account for the worst case interrupt stack requirements in
600addition to it’s own worst case usage.  RTEMS addresses this
601problem on the SPARC by providing a dedicated interrupt stack
602managed by software.
603
604During system initialization, RTEMS allocates the
605interrupt stack from the Workspace Area.  The amount of memory
606allocated for the interrupt stack is determined by the
607interrupt_stack_size field in the CPU Configuration Table.  As
608part of processing a non-nested interrupt, RTEMS will switch to
609the interrupt stack before invoking the installed handler.
610
611.. COMMENT: COPYRIGHT (c) 1988-2002.
612
613.. COMMENT: On-Line Applications Research Corporation (OAR).
614
615.. COMMENT: All rights reserved.
616
617Default Fatal Error Processing
618==============================
619
620Upon detection of a fatal error by either the
621application or RTEMS the fatal error manager is invoked.  The
622fatal error manager will invoke the user-supplied fatal error
623handlers.  If no user-supplied handlers are configured,  the
624RTEMS provided default fatal error handler is invoked.  If the
625user-supplied fatal error handlers return to the executive the
626default fatal error handler is then invoked.  This chapter
627describes the precise operations of the default fatal error
628handler.
629
630Default Fatal Error Handler Operations
631--------------------------------------
632
633The default fatal error handler which is invoked by
634the fatal_error_occurred directive when there is no user handler
635configured or the user handler returns control to RTEMS.  The
636default fatal error handler disables processor interrupts to
637level 15, places the error code in g1, and goes into an infinite
638loop to simulate a halt processor instruction.
639
640Symmetric Multiprocessing
641=========================
642
643SMP is not supported.
644
645Thread-Local Storage
646====================
647
648Thread-local storage is supported.
649
650.. COMMENT: COPYRIGHT (c) 1988-2002.
651
652.. COMMENT: On-Line Applications Research Corporation (OAR).
653
654.. COMMENT: All rights reserved.
655
656Board Support Packages
657======================
658
659An RTEMS Board Support Package (BSP) must be designed
660to support a particular processor and target board combination.
661This chapter presents a discussion of SPARC specific BSP issues.
662For more information on developing a BSP, refer to the chapter
663titled Board Support Packages in the RTEMS
664Applications User’s Guide.
665
666HelenOS and Open Firmware
667-------------------------
668
669The provided BSPs make use of some bootstrap and low-level hardware code
670of the HelenOS operating system. These files can be found in the shared/helenos
671directory of the sparc64 bsp directory.  Consult the sources for more
672detailed information.
673
674The shared BSP code also uses the Open Firmware interface to re-use firmware
675code, primarily for console support and default trap handlers.
676
Note: See TracBrowser for help on using the repository browser.