source: rtems/doc/cpu_supplement/sparc64.t @ 9b4422a2

4.115
Last change on this file since 9b4422a2 was 9b4422a2, checked in by Joel Sherrill <joel.sherrill@…>, on 05/03/12 at 15:09:24

Remove All CVS Id Strings Possible Using a Script

Script does what is expected and tries to do it as
smartly as possible.

+ remove occurrences of two blank comment lines

next to each other after Id string line removed.

+ remove entire comment blocks which only exited to

contain CVS Ids

+ If the processing left a blank line at the top of

a file, it was removed.

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