Index: doc/ChangeLog
===================================================================
--- doc/ChangeLog	(revision 56e8ccd859562842feda0bfc79b39dd9bc79cdd8)
+++ doc/ChangeLog	(revision d3d9908fec8f5d146ffeff5607e9091c3ddd5bfd)
@@ -1,2 +1,9 @@
+2010-06-15	Gedare Bloom <giddyup44@yahoo.com>
+
+	PR 1565/cpukit
+	* cpu_supplement/Makefile.am, cpu_supplement/cpu_supplement.texi: Merge
+	SPARC64 port.
+	* cpu_supplement/sparc64.t: New file.
+
 2010-06-11	Ralf CorsÃ©pius <ralf.corsepius@rtems.org>
 
Index: doc/cpu_supplement/Makefile.am
===================================================================
--- doc/cpu_supplement/Makefile.am	(revision 56e8ccd859562842feda0bfc79b39dd9bc79cdd8)
+++ doc/cpu_supplement/Makefile.am	(revision d3d9908fec8f5d146ffeff5607e9091c3ddd5bfd)
@@ -15,5 +15,5 @@
 
 GENERATED_FILES = general.texi arm.texi avr.texi bfin.texi i386.texi lm32.texi \
-    m68k.texi mips.texi powerpc.texi sh.texi sparc.texi tic4x.texi
+    m68k.texi mips.texi powerpc.texi sh.texi sparc.texi sparc64.texi tic4x.texi
 
 COMMON_FILES += $(top_srcdir)/common/cpright.texi
@@ -83,4 +83,9 @@
 	    -n "" < $< > $@
 
+sparc64.texi: sparc64.t
+	$(BMENU2) -p "" \
+	    -u "Top" \
+	    -n "" < $< > $@
+
 tic4x.texi: tic4x.t
 	$(BMENU2) -p "" \
Index: doc/cpu_supplement/cpu_supplement.texi
===================================================================
--- doc/cpu_supplement/cpu_supplement.texi	(revision 56e8ccd859562842feda0bfc79b39dd9bc79cdd8)
+++ doc/cpu_supplement/cpu_supplement.texi	(revision d3d9908fec8f5d146ffeff5607e9091c3ddd5bfd)
@@ -71,4 +71,5 @@
 @include sh.texi
 @include sparc.texi
+@include sparc64.texi
 @include tic4x.texi
 @ifinfo
@@ -91,4 +92,5 @@
 * SuperH Specific Information::
 * SPARC Specific Information::
+* SPARC-64 Specific Information::
 * Texas Instruments C3x/C4x Specific Information::
 * Command and Variable Index::
Index: doc/cpu_supplement/sparc64.t
===================================================================
--- doc/cpu_supplement/sparc64.t	(revision d3d9908fec8f5d146ffeff5607e9091c3ddd5bfd)
+++ doc/cpu_supplement/sparc64.t	(revision d3d9908fec8f5d146ffeff5607e9091c3ddd5bfd)
@@ -0,0 +1,817 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@ifinfo
+@end ifinfo
+@chapter 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.
+
+@subheading 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:
+@itemize @bullet
+@item UltraSPARC  Userâs Manual
+(http://www.sun.com/microelectronics/manuals/ultrasparc/802-7220-02.pdf)
+@item UltraSPARC IIIi Processor (datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf)
+@end itemize  
+
+@subheading 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:
+@itemize @bullet
+@item UltraSPARC Architecture 2005 Specification  
+    (http://opensparc-t1.sunsource.net/specs/UA2005-current-draft-P-EXT.pdf)
+@item UltraSPARC T1 supplement to UltraSPARC Architecture 2005 Specification
+(http://opensparc-t1.sunsource.net/specs/UST1-UASuppl-current-draft-P-EXT.pdf)
+@end itemize
+
+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.
+
+@c
+@c
+@c
+
+@section CPU Model Dependent Features
+
+@subsection 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.
+
+@subsubsection 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".
+
+@subsubsection 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.
+
+@subsubsection 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.
+
+@subsection CPU Model Implementation Notes 
+
+This section describes the implemenation dependencies of the 
+CPU Models sun4u and sun4v of the SPARC V9 architecture.
+
+@subsubsection sun4u Notes
+
+XXX
+
+@subsection sun4v Notes
+
+XXX
+
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@section 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:
+
+@itemize @bullet
+@item register preservation and usage
+
+@item parameter passing
+
+@item call and return mechanism
+@end itemize
+
+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
+
+@subsection Programming Model
+
+This section discusses the programming model for the
+SPARC architecture.
+
+@subsubsection 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:
+
+@itemize @bullet
+@item input registers
+
+@item local registers
+
+@item output registers
+
+@item global registers
+@end itemize
+
+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:
+
+@ifset use-ascii
+@example
+@group
+     +-----------------+----------------+------------------+
+     | 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  |
+     +-----------------+----------------+------------------+
+@end group
+@end example
+@end ifset
+
+@ifset use-tex
+@sp 1
+@tex
+\centerline{\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule}
+&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule}
+&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule}
+&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule}
+&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule}
+}}\hfil}
+@end tex
+@end ifset
+
+@ifset use-html
+@html
+<CENTER>
+  <TABLE COLS=3 WIDTH="80%" BORDER=2>
+<TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD>
+    <TD ALIGN=center><STRONG>Register Names</STRONG></TD>
+    <TD ALIGN=center><STRONG>Description</STRONG></TD>
+<TR><TD ALIGN=center>0 - 7</TD>
+    <TD ALIGN=center>g0 - g7</TD>
+    <TD ALIGN=center>Global Registers</TD></TR>
+<TR><TD ALIGN=center>8 - 15</TD>
+    <TD ALIGN=center>o0 - o7</TD>
+    <TD ALIGN=center>Output Registers</TD></TR>
+<TR><TD ALIGN=center>16 - 23</TD>
+    <TD ALIGN=center>l0 - l7</TD>
+    <TD ALIGN=center>Local Registers</TD></TR>
+<TR><TD ALIGN=center>24 - 31</TD>
+    <TD ALIGN=center>i0 - i7</TD>
+    <TD ALIGN=center>Input Registers</TD></TR>
+  </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+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:
+
+@ifset use-ascii
+@example
+@group
+     +---------------+----------------+----------------------+
+     | 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    |
+     +---------------+----------------+----------------------+
+@end group
+@end example
+@end ifset
+
+@ifset use-tex
+@sp 1
+@tex
+\centerline{\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule}
+&g0&&NA&&reads return 0; &\cr
+&&&&&writes are ignored&\cr\noalign{\hrule}
+&o6&&sp&&stack pointer&\cr\noalign{\hrule}
+&i6&&fp&&frame pointer&\cr\noalign{\hrule}
+&i7&&NA&&return address&\cr\noalign{\hrule}
+}}\hfil}
+@end tex
+@end ifset
+ 
+@ifset use-html
+@html
+<CENTER>
+  <TABLE COLS=3 WIDTH="80%" BORDER=2>
+<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD>
+    <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD>
+    <TD ALIGN=center><STRONG>Description</STRONG></TD></TR>
+<TR><TD ALIGN=center>g0</TD>
+    <TD ALIGN=center>NA</TD>
+    <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR>
+<TR><TD ALIGN=center>o6</TD>
+    <TD ALIGN=center>sp</TD>
+    <TD ALIGN=center>stack pointer</TD></TR>
+<TR><TD ALIGN=center>i6</TD>
+    <TD ALIGN=center>fp</TD>
+    <TD ALIGN=center>frame pointer</TD></TR>
+<TR><TD ALIGN=center>i7</TD>
+    <TD ALIGN=center>NA</TD>
+    <TD ALIGN=center>return address</TD></TR>
+  </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+
+@subsubsection Floating Point Registers
+
+The SPARC V9 architecture includes sixty-four,
+thirty-two bit registers.  These registers may be viewed as
+follows:
+
+@itemize @bullet
+@item 32 32-bit single precision floating point or integer registers
+(f0, f1,  ... f31)
+
+@item 32 64-bit double precision floating point registers (f0, f2,
+f4, ... f62)
+
+@item 16 128-bit extended precision floating point registers (f0, f4,
+f8, ... f60)
+@end itemize
+
+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.
+
+@subsubsection Special Registers
+
+The SPARC architecture includes a number of special registers:
+@table @b
+
+@item @code{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.
+
+@item @code{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.
+
+@item @code{Processor Interrupt Level (pil)}
+The PIL specifies the interrupt level above which interrupts will be
+accepted.
+
+@item @code{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).
+
+@item @code{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.
+
+@item @code{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).
+
+@end table
+
+@subsection 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.
+
+@subsection 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.
+
+@subsection Calling Mechanism
+
+All RTEMS directives are invoked using the regular
+SPARC calling convention via the call instruction.
+
+@subsection 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.
+
+@subsection 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:
+
+@example
+load third argument into o2
+load second argument into o1
+load first argument into o0
+invoke directive
+@end example
+
+@subsection 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.
+
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@section 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.
+
+@subsection 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:
+
+@ifset use-ascii
+@example
+@group
+          +--------------+-----------------------+
+          |   Data Type  | Alignment Requirement |
+          +--------------+-----------------------+
+          |     byte     |          1            |
+          |   half-word  |          2            |
+          |     word     |          4            |
+          |  doubleword  |          8            |
+          |   quadword   |          16           |
+          +--------------+-----------------------+
+@end group
+@end example
+@end ifset
+
+@ifset use-tex
+@sp 1
+@tex
+\centerline{\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule}
+&byte&&1&\cr\noalign{\hrule}
+&half-word&&2&\cr\noalign{\hrule}
+&word&&4&\cr\noalign{\hrule}
+&doubleword&&8&\cr\noalign{\hrule}
+&quadword&&16&\cr\noalign{\hrule}
+}}\hfil}
+@end tex
+@end ifset
+ 
+@ifset use-html
+@html
+<CENTER>
+  <TABLE COLS=2 WIDTH="60%" BORDER=2>
+<TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD>
+    <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR>
+<TR><TD ALIGN=center>byte</TD>
+    <TD ALIGN=center>1</TD></TR>
+<TR><TD ALIGN=center>half-word</TD>
+    <TD ALIGN=center>2</TD></TR>
+<TR><TD ALIGN=center>word</TD>
+    <TD ALIGN=center>4</TD></TR>
+<TR><TD ALIGN=center>doubleword</TD>
+    <TD ALIGN=center>8</TD></TR>
+<TR><TD ALIGN=center>quadword</TD>
+    <TD ALIGN=center>16</TD></TR>
+  </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+RTEMS currently does not support any SPARC Memory Management
+Units, therefore, virtual memory or segmentation systems
+involving the SPARC are not supported.
+
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@section 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.
+
+@subsection 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.
+
+@subsection Vectoring of Interrupt Handler
+
+Upon receipt of an interrupt the SPARC automatically
+performs the following actions:
+
+@itemize @bullet
+@item 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
+@item Existing state is preserved
+@itemize @bullet
+  @item TSTATE[TL].CCR <- CCR
+  @item TSTATE[TL].ASI <- ASI
+  @item TSTATE[TL].PSTATE <- PSTATE
+  @item TSTATE[TL].CWP <- CWP
+  @item TPC[TL] <- PC
+  @item TNPC[TL] <- nPC
+@end itemize
+@item The trap type is preserved. TT[TL] <- the trap type
+@item The PSTATE register is updated to a predefined state
+@itemize @bullet
+  @item PSTATE.MM is unchanged
+  @item PSTATE.RED <- 0
+  @item PSTATE.PEF <- 1 if FPU is present, 0 otherwise
+  @item PSTATE.AM <- 0 (address masking is turned off)
+  @item PSTATE.PRIV <- 1 (the processor enters privileged mode)
+  @item PSTATE.IE <- 0 (interrupts are disabled)
+  @item PSTATE.AG <- 1 (global regs are replaced with alternate globals)
+  @item PSTATE.CLE <- PSTATE.TLE (set endian mode for traps)
+@end itemize
+@item 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:
+@itemize @bullet
+  @item If TT[TL] = 0x24 (a clean window trap), then CWP <- CWP + 1.
+  @item If (0x80 <= TT[TL] <= 0xBF) (window spill trap), then CWP <- CWP +
+CANSAVE + 2.
+  @item If (0xC0 <= TT[TL] <= 0xFF) (window fill trap), then CWP <- CWP1.
+  @item For non-register-window traps, CWP is not changed.
+@end itemize
+@item Control is transferred into the trap table:
+@itemize @bullet
+  @item PC <- TBA<63:15> (TL>0) TT[TL] 0 0000
+  @item nPC <- TBA<63:15> (TL>0) TT[TL] 0 0100
+  @item where (TL>0) is 0 if TL = 0, and 1 if TL > 0.
+@end itemize
+
+@end itemize
+
+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:
+
+@itemize @bullet
+@item saves the state of the interrupted task on it's stack,
+
+@item switches the processor to trap level 0,
+
+@item if this is the outermost (i.e. non-nested) interrupt,
+then the RTEMS interrupt handler switches from the current stack
+to the interrupt stack,
+
+@item enables traps,
+
+@item invokes the vectors to a user interrupt service routine (ISR).
+@end itemize
+
+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.
+
+@subsection Traps and Register Windows
+
+XXX
+
+@subsection 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.
+
+@subsection Disabling of Interrupts by RTEMS
+
+XXX
+
+@subsection 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.
+
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@section 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.
+
+@subsection 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.
+
+
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@section 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.
+
+@subsection 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. 
+
