Index: doc/supplements/powerpc/bsp.t
===================================================================
--- doc/supplements/powerpc/bsp.t	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/bsp.t	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -37,24 +37,15 @@
 
 An RTEMS based application is initiated or
-re-initiated when the PowerPC processor is reset.  When the PowerPC
-is reset, the processor performs the following actions:
+re-initiated when the PowerPC processor is reset.  The PowerPC 
+architecture defines a Reset Exception, but leaves the
+details of the CPU state as implementation specific.  Please
+refer to the User's Manual for the CPU model in question.
 
-@itemize @bullet
-@item TBD
-
-@item TBD
-
-@item TBD
-@end itemize
-
-The processor then begins to execute the code at location 0x00100.  
-By using the SRR1 bit corresponding to MSR[RI] the softwere may 
-distinguish between power-on reset and other types of system resets.
-
-It is important to note that all fields in the psr
-are not explicitly set by the above steps and all other
-registers retain their value from the previous execution mode.
-This is true even of the Trap Base Register (TBR) whose contents
-reflect the last trap which occurred before the reset.
+In general, at power-up the PowerPC begin execution at address
+0xFFF00100 in supervisor mode with all exceptions disabled.  For
+soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100
+depending upon the setting of the Exception Prefix bit in the MSR.
+If during a soft reset, a Machine Check Exception occurs, then the
+CPU may execute a hard reset.
 
 @ifinfo
@@ -64,34 +55,31 @@
 
 It is the responsibility of the application's
-initialization code to initialize the TBR and install trap
-handlers for at least the register window overflow and register
-window underflow conditions.  Traps should be enabled before
-invoking any subroutines to allow for register window
-management.  However, interrupts should be disabled by setting
-the Processor Interrupt Level (pil) field of the psr to 15.
-RTEMS installs it's own Trap Table as part of initialization
-which is initialized with the contents of the Trap Table in
-place when the rtems_initialize_executive directive was invoked.
-Upon completion of executive initialization, interrupts are
-enabled.
+initialization code to initialize the CPU and board
+to a quiescent state before invoking the @code{rtems_initialize_executive}
+directive.  It is recommended that the BSP utilize the @code{predriver_hook}
+to install default handlers for all exceptions.  These default handlers
+may be overwritten as various device drivers and subsystems install
+their own exception handlers.  Upon completion of RTEMS executive
+initialization, all interrupts are enabled.
 
 If this PowerPC implementation supports on-chip caching
 and this is to be utilized, then it should be enabled during the
-reset application initialization code.
+reset application initialization code.  On-chip caching has been
+observed to prevent some emulators from working properly, so it
+may be necessary to run with caching disabled to use these emulators.
 
 In addition to the requirements described in the
-Board Support Packages chapter of the @value{LANGUAGE}
-Applications User's Manual for the reset code
-which is executed before the call to
-rtems_initialize executive, the PowrePC version has the following
-specific requirements:
+@b{Board Support Packages} chapter of the @b{@value{LANGUAGE}
+Applications User's Manual} for the reset code
+which is executed before the call to @code{rtems_initialize_executive},
+the PowrePC version has the following specific requirements:
 
 @itemize @bullet
-@item Must leave the PR bit of the machine state register set so that
-the PowerPC remains in the supervisor state.
+@item Must leave the PR bit of the Machine State Register (MSR) set 
+to 0 so the PowerPC remains in the supervisor state.
 
-@item Must set stack pointer (sp) such that a minimum stack
+@item Must set stack pointer (sp or r1) such that a minimum stack
 size of MINIMUM_STACK_SIZE bytes is provided for the
-rtems_initialize executive directive.
+@code{rtems_initialize_executive} directive.
 
 @item Must disable all external interrupts (i.e. clear the EI (EE)
@@ -101,7 +89,7 @@
 conditions can be properly handled.
 
-@item Must initialize the PowerPC's initial trap table with at
-least trap handlers for register window overflow and register
-window underflow.
+@item Must initialize the PowerPC's initial Exception Table with default
+handlers.
+
 @end itemize
 
Index: doc/supplements/powerpc/bsp.texi
===================================================================
--- doc/supplements/powerpc/bsp.texi	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/bsp.texi	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -37,24 +37,15 @@
 
 An RTEMS based application is initiated or
-re-initiated when the PowerPC processor is reset.  When the PowerPC
-is reset, the processor performs the following actions:
+re-initiated when the PowerPC processor is reset.  The PowerPC 
+architecture defines a Reset Exception, but leaves the
+details of the CPU state as implementation specific.  Please
+refer to the User's Manual for the CPU model in question.
 
-@itemize @bullet
-@item TBD
-
-@item TBD
-
-@item TBD
-@end itemize
-
-The processor then begins to execute the code at location 0x00100.  
-By using the SRR1 bit corresponding to MSR[RI] the softwere may 
-distinguish between power-on reset and other types of system resets.
-
-It is important to note that all fields in the psr
-are not explicitly set by the above steps and all other
-registers retain their value from the previous execution mode.
-This is true even of the Trap Base Register (TBR) whose contents
-reflect the last trap which occurred before the reset.
+In general, at power-up the PowerPC begin execution at address
+0xFFF00100 in supervisor mode with all exceptions disabled.  For
+soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100
+depending upon the setting of the Exception Prefix bit in the MSR.
+If during a soft reset, a Machine Check Exception occurs, then the
+CPU may execute a hard reset.
 
 @ifinfo
@@ -64,34 +55,31 @@
 
 It is the responsibility of the application's
-initialization code to initialize the TBR and install trap
-handlers for at least the register window overflow and register
-window underflow conditions.  Traps should be enabled before
-invoking any subroutines to allow for register window
-management.  However, interrupts should be disabled by setting
-the Processor Interrupt Level (pil) field of the psr to 15.
-RTEMS installs it's own Trap Table as part of initialization
-which is initialized with the contents of the Trap Table in
-place when the rtems_initialize_executive directive was invoked.
-Upon completion of executive initialization, interrupts are
-enabled.
+initialization code to initialize the CPU and board
+to a quiescent state before invoking the @code{rtems_initialize_executive}
+directive.  It is recommended that the BSP utilize the @code{predriver_hook}
+to install default handlers for all exceptions.  These default handlers
+may be overwritten as various device drivers and subsystems install
+their own exception handlers.  Upon completion of RTEMS executive
+initialization, all interrupts are enabled.
 
 If this PowerPC implementation supports on-chip caching
 and this is to be utilized, then it should be enabled during the
-reset application initialization code.
+reset application initialization code.  On-chip caching has been
+observed to prevent some emulators from working properly, so it
+may be necessary to run with caching disabled to use these emulators.
 
 In addition to the requirements described in the
-Board Support Packages chapter of the @value{LANGUAGE}
-Applications User's Manual for the reset code
-which is executed before the call to
-rtems_initialize executive, the PowrePC version has the following
-specific requirements:
+@b{Board Support Packages} chapter of the @b{@value{LANGUAGE}
+Applications User's Manual} for the reset code
+which is executed before the call to @code{rtems_initialize_executive},
+the PowrePC version has the following specific requirements:
 
 @itemize @bullet
-@item Must leave the PR bit of the machine state register set so that
-the PowerPC remains in the supervisor state.
+@item Must leave the PR bit of the Machine State Register (MSR) set 
+to 0 so the PowerPC remains in the supervisor state.
 
-@item Must set stack pointer (sp) such that a minimum stack
+@item Must set stack pointer (sp or r1) such that a minimum stack
 size of MINIMUM_STACK_SIZE bytes is provided for the
-rtems_initialize executive directive.
+@code{rtems_initialize_executive} directive.
 
 @item Must disable all external interrupts (i.e. clear the EI (EE)
@@ -101,7 +89,7 @@
 conditions can be properly handled.
 
-@item Must initialize the PowerPC's initial trap table with at
-least trap handlers for register window overflow and register
-window underflow.
+@item Must initialize the PowerPC's initial Exception Table with default
+handlers.
+
 @end itemize
 
Index: doc/supplements/powerpc/callconv.t
===================================================================
--- doc/supplements/powerpc/callconv.t	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/callconv.t	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -8,5 +8,5 @@
 
 @ifinfo
-@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features CPU Model Implementation Notes, Top
+@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Low Power Model, Top
 @end ifinfo
 @chapter Calling Conventions
@@ -15,5 +15,4 @@
 * Calling Conventions Introduction::
 * Calling Conventions Programming Model::
-* Calling Conventions Register Windows::
 * Calling Conventions Call and Return Mechanism::
 * Calling Conventions Calling Mechanism::
@@ -54,12 +53,12 @@
 
 @ifinfo
-@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
+@node Calling Conventions Programming Model, Calling Conventions Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
 @end ifinfo
 @section Programming Model
 @ifinfo
 @menu
-* Non-Floating Point Registers::
-* Floating Point Registers::
-* Special Registers::
+* Calling Conventions Non-Floating Point Registers::
+* Calling Conventions Floating Point Registers::
+* Calling Conventions Special Registers::
 @end menu
 @end ifinfo
@@ -69,5 +68,5 @@
 
 @ifinfo
-@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
+@node Calling Conventions Non-Floating Point Registers, Calling Conventions Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
 @end ifinfo
 @subsection Non-Floating Point Registers
@@ -86,16 +85,17 @@
 @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    |
-     +---------------+----------------+----------------------+
+     +---------------+----------------+------------------------------+
+     | Register Name | Alternate Name |         Description          |
+     +---------------+----------------+------------------------------+
+     |      r1       |      sp        |         stack pointer        |
+     +---------------+----------------+------------------------------+
+     |               |                |  global pointer to the Small |
+     |      r2       |      na        |     Constant Area (SDA2)     |
+     +---------------+----------------+------------------------------+
+     |    r3 - r12   |      na        | parameter and result passing |
+     +---------------+----------------+------------------------------+
+     |               |                |  global pointer to the Small |
+     |      r13      |      na        |         Data Area (SDA)      |
+     +---------------+----------------+------------------------------+
 @end group
 @end example
@@ -111,13 +111,14 @@
 \hbox to 1.75in{\enskip\hfil#\hfil}&
 \vrule#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
+\hbox to 2.50in{\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}
+&r1&&sp&&stack pointer&\cr\noalign{\hrule}
+&r2&&NA&&global pointer to the Small&\cr
+&&&&&Constant Area (SDA2)&\cr\noalign{\hrule}
+&r3 - r12&&NA&&parameter and result passing&\cr\noalign{\hrule}
+&r13&&NA&&global pointer to the Small&\cr
+&&&&&Data Area (SDA2)&\cr\noalign{\hrule}
 }}\hfil}
 @end tex
@@ -131,16 +132,16 @@
     <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>
+<TR><TD ALIGN=center>r1</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>
+<TR><TD ALIGN=center>r2</TD>
+    <TD ALIGN=center>na</TD>
+    <TD ALIGN=center>global pointer to the Small Constant Area (SDA2)</TD></TR>
+<TR><TD ALIGN=center>r3 - r12</TD>
     <TD ALIGN=center>NA</TD>
-    <TD ALIGN=center>return address</TD></TR>
+    <TD ALIGN=center>parameter and result passing</TD></TR>
+<TR><TD ALIGN=center>r13</TD>
+    <TD ALIGN=center>NA</TD>
+    <TD ALIGN=center>global pointer to the Small Data Area (SDA)</TD></TR>
   </TABLE>
 </CENTER>
@@ -150,11 +151,11 @@
 
 @ifinfo
-@node Floating Point Registers, Special Registers, Non-Floating Point Registers, Calling Conventions Programming Model
+@node Calling Conventions Floating Point Registers, Calling Conventions Special Registers, Calling Conventions Non-Floating Point Registers, Calling Conventions Programming Model
 @end ifinfo
 @subsection Floating Point Registers
 
-The PowerPC architecture includes thirty-two,
-sixty-four bit registers.  All PowwerPC floating point instructions 
-interprete these registers as 32 double precision floating point registers,
+The PowerPC architecture includes thirty-two, sixty-four bit
+floating point registers.  All PowerPC floating point instructions 
+interpret these registers as 32 double precision floating point registers,
 regardless of whether the processor has 64-bit or 32-bit implementation.
 
@@ -164,157 +165,64 @@
 reporting of floating exceptions to be enabled or disabled.
 
-XXXXXX
-A queue of the floating point instructions which have
-started execution but not yet completed is maintained.  This
-queue is needed to support the multiple cycle nature of floating
-point operations and to aid floating point exception trap
-handlers.  Once a floating point exception has been encountered,
-the queue is frozen until it is emptied by the trap handler.
-The floating point queue is loaded by launching instructions.
-It is emptied normally when the floating point completes all
-outstanding instructions and by floating point exception
-handlers with the store double floating point queue (stdfq)
-instruction.
-XXX
-
-@ifinfo
-@node Special Registers, Calling Conventions Register Windows, Floating Point Registers, Calling Conventions Programming Model
+@ifinfo
+@node Calling Conventions Special Registers, Calling Conventions Call and Return Mechanism, Calling Conventions Floating Point Registers, Calling Conventions Programming Model
 @end ifinfo
 @subsection Special Registers
 
-The PowerPC architecture includes XXX special registers
-which are critical to the programming model: the Machine State
-Register (msr) and XXX the Window Invalid Mask (wim) XXX.  The msr
-contains the processor mode, power management mode, endian mode, exception
-information, privlige level, floating point available and floating point 
-excepiton mode, address translation information and the exception prefix.
-
-XXX
-condition codes, processor interrupt level, trap
-enable bit, supervisor mode and previous supervisor mode bits,
-version information, floating point unit and coprocessor enable
-bits, and the current window pointer (cwp).  The cwp field of
-the psr and wim register are used to manage the register windows
-in the SPARC architecture.  The register windows are discussed
-in more detail below.
-XXX
-
-@ifinfo
-@node Calling Conventions Register Windows, Calling Conventions Call and Return Mechanism, Special Registers, Calling Conventions
-@end ifinfo
-@section 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 decrements 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 increments 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 Window Invalid Mask (wim) and the Current Window
-Pointer (cwp) field in the psr are used in conjunction to manage
-the finite set of register windows and detect the window
-overflow and underflow conditions.  The cwp contains the index
-of the register window currently in use.  The save instruction
-decrements the cwp modulo the number of register windows.
-Similarly, the restore instruction increments the cwp modulo the
-number of register windows.  Each bit in the  wim represents
-represents whether a register window contains valid information.
-The value of 0 indicates the register window is valid and 1
-indicates it is invalid.  When a save instruction causes the cwp
-to point to a register window which is marked as invalid, a
-window overflow condition results.  Conversely, the restore
-instruction may result in a window underflow condition.
-
-Other than the assumption that a register window is
-always available for trap (i.e. interrupt) handlers, the SPARC
-architecture places no limits on the number of register windows
-simultaneously marked as invalid (i.e. number of bits set in the
-wim).  However, RTEMS assumes that only one register window is
-marked invalid at a time (i.e. only one bit set in the wim).
-This makes the maximum possible number of register windows
-available to the user while still meeting the requirement that
-window overflow and underflow conditions can be detected.
-
-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.
-
-@ifinfo
-@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Register Windows, Calling Conventions
+The PowerPC architecture includes a number of special registers
+which are critical to the programming model:
+
+@table @b
+
+@item Machine State Register
+
+The MSR contains the processor mode, power management mode, endian mode,
+exception information, privilege level, floating point available and
+floating point excepiton mode, address translation information and
+the exception prefix.
+
+@item Link Register
+
+The LR contains the return address after a function call.  This register
+must be saved before a subsequent subroutine call can be made.  The
+use of this register is discussed further in the @b{Call and Return
+Mechanism} section below.
+
+@item Count Register
+
+The CTR contains the iteration variable for some loops.  It may also be used
+for indirect function calls and jumps.
+
+@end table
+
+@ifinfo
+@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Special Registers, Calling Conventions
 @end ifinfo
 @section 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
+The PowerPC architecture supports a simple yet effective call
+and return mechanism.  A subroutine is invoked
+via the "branch and link" (@code{bl}) and
+"brank and link absolute" (@code{bla})
+instructions.  This instructions place the return address
+in the Link Register (LR).  The callee returns to the caller by 
+executing a "branch unconditional to the link register" (@code{blr})
+instruction.  Thus the callee returns to the caller via a jump
+to the return address which is stored in the LR.
+
+The previous contents of the LR are not automatically saved 
+by either the @code{bl} or @code{bla}.  It is the responsibility
+of the callee to save the contents of the LR before invoking
+another subroutine.  If the callee invokes another subroutine,
+it must restore the LR before executing the @code{blr} instruction
+to return to the caller.
+
+It is important to note that the PowerPC 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.
+restore any registers.
+
+The LR may be accessed as special purpose register 8 (@code{SPR8}) using the
+"move from special register" (@code{mfspr}) and
+"move to special register" (@code{mtspr}) instructions.
 
 @ifinfo
@@ -324,5 +232,6 @@
 
 All RTEMS directives are invoked using the regular
-SPARC calling convention via the call instruction.
+PowerPC EABI calling convention via the @code{bl} or
+@code{bla} instructions.
 
 @ifinfo
@@ -332,9 +241,9 @@
 
 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.
+automatically save any registers.  It is the responsibility
+of the callee to save and restore any registers which must be preserved
+across subroutine calls.  The callee is responsible for saving 
+callee-preserved registers to the program stack and restoring them
+before returning to the caller.
 
 @ifinfo
@@ -344,17 +253,17 @@
 
 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
+general purpose registers with the first argument in 
+register 3 (@code{r3}), the second argument in general purpose
+register 4 (@code{r4}), and so forth until the seventh
+argument is in general purpose register 10 (@code{r10}).  
+If there are more than seven arguments, then subsequent arguments
+are placed on the program stack.  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
+load third argument into r5
+load second argument into r4
+load first argument into r3
 invoke directive
 @end example
@@ -367,6 +276,5 @@
 All user-provided routines invoked by RTEMS, such as
 user extensions, device drivers, and MPCI routines, must also
-adhere to these calling conventions.
-
-
-
+adhere to these same calling conventions.
+
+
Index: doc/supplements/powerpc/callconv.texi
===================================================================
--- doc/supplements/powerpc/callconv.texi	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/callconv.texi	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -8,5 +8,5 @@
 
 @ifinfo
-@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features CPU Model Implementation Notes, Top
+@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Low Power Model, Top
 @end ifinfo
 @chapter Calling Conventions
@@ -15,5 +15,4 @@
 * Calling Conventions Introduction::
 * Calling Conventions Programming Model::
-* Calling Conventions Register Windows::
 * Calling Conventions Call and Return Mechanism::
 * Calling Conventions Calling Mechanism::
@@ -54,12 +53,12 @@
 
 @ifinfo
-@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
+@node Calling Conventions Programming Model, Calling Conventions Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
 @end ifinfo
 @section Programming Model
 @ifinfo
 @menu
-* Non-Floating Point Registers::
-* Floating Point Registers::
-* Special Registers::
+* Calling Conventions Non-Floating Point Registers::
+* Calling Conventions Floating Point Registers::
+* Calling Conventions Special Registers::
 @end menu
 @end ifinfo
@@ -69,5 +68,5 @@
 
 @ifinfo
-@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
+@node Calling Conventions Non-Floating Point Registers, Calling Conventions Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
 @end ifinfo
 @subsection Non-Floating Point Registers
@@ -86,16 +85,17 @@
 @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    |
-     +---------------+----------------+----------------------+
+     +---------------+----------------+------------------------------+
+     | Register Name | Alternate Name |         Description          |
+     +---------------+----------------+------------------------------+
+     |      r1       |      sp        |         stack pointer        |
+     +---------------+----------------+------------------------------+
+     |               |                |  global pointer to the Small |
+     |      r2       |      na        |     Constant Area (SDA2)     |
+     +---------------+----------------+------------------------------+
+     |    r3 - r12   |      na        | parameter and result passing |
+     +---------------+----------------+------------------------------+
+     |               |                |  global pointer to the Small |
+     |      r13      |      na        |         Data Area (SDA)      |
+     +---------------+----------------+------------------------------+
 @end group
 @end example
@@ -111,13 +111,14 @@
 \hbox to 1.75in{\enskip\hfil#\hfil}&
 \vrule#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
+\hbox to 2.50in{\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}
+&r1&&sp&&stack pointer&\cr\noalign{\hrule}
+&r2&&NA&&global pointer to the Small&\cr
+&&&&&Constant Area (SDA2)&\cr\noalign{\hrule}
+&r3 - r12&&NA&&parameter and result passing&\cr\noalign{\hrule}
+&r13&&NA&&global pointer to the Small&\cr
+&&&&&Data Area (SDA2)&\cr\noalign{\hrule}
 }}\hfil}
 @end tex
@@ -131,16 +132,16 @@
     <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>
+<TR><TD ALIGN=center>r1</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>
+<TR><TD ALIGN=center>r2</TD>
+    <TD ALIGN=center>na</TD>
+    <TD ALIGN=center>global pointer to the Small Constant Area (SDA2)</TD></TR>
+<TR><TD ALIGN=center>r3 - r12</TD>
     <TD ALIGN=center>NA</TD>
-    <TD ALIGN=center>return address</TD></TR>
+    <TD ALIGN=center>parameter and result passing</TD></TR>
+<TR><TD ALIGN=center>r13</TD>
+    <TD ALIGN=center>NA</TD>
+    <TD ALIGN=center>global pointer to the Small Data Area (SDA)</TD></TR>
   </TABLE>
 </CENTER>
@@ -150,11 +151,11 @@
 
 @ifinfo
-@node Floating Point Registers, Special Registers, Non-Floating Point Registers, Calling Conventions Programming Model
+@node Calling Conventions Floating Point Registers, Calling Conventions Special Registers, Calling Conventions Non-Floating Point Registers, Calling Conventions Programming Model
 @end ifinfo
 @subsection Floating Point Registers
 
-The PowerPC architecture includes thirty-two,
-sixty-four bit registers.  All PowwerPC floating point instructions 
-interprete these registers as 32 double precision floating point registers,
+The PowerPC architecture includes thirty-two, sixty-four bit
+floating point registers.  All PowerPC floating point instructions 
+interpret these registers as 32 double precision floating point registers,
 regardless of whether the processor has 64-bit or 32-bit implementation.
 
@@ -164,157 +165,64 @@
 reporting of floating exceptions to be enabled or disabled.
 
-XXXXXX
-A queue of the floating point instructions which have
-started execution but not yet completed is maintained.  This
-queue is needed to support the multiple cycle nature of floating
-point operations and to aid floating point exception trap
-handlers.  Once a floating point exception has been encountered,
-the queue is frozen until it is emptied by the trap handler.
-The floating point queue is loaded by launching instructions.
-It is emptied normally when the floating point completes all
-outstanding instructions and by floating point exception
-handlers with the store double floating point queue (stdfq)
-instruction.
-XXX
-
-@ifinfo
-@node Special Registers, Calling Conventions Register Windows, Floating Point Registers, Calling Conventions Programming Model
+@ifinfo
+@node Calling Conventions Special Registers, Calling Conventions Call and Return Mechanism, Calling Conventions Floating Point Registers, Calling Conventions Programming Model
 @end ifinfo
 @subsection Special Registers
 
-The PowerPC architecture includes XXX special registers
-which are critical to the programming model: the Machine State
-Register (msr) and XXX the Window Invalid Mask (wim) XXX.  The msr
-contains the processor mode, power management mode, endian mode, exception
-information, privlige level, floating point available and floating point 
-excepiton mode, address translation information and the exception prefix.
-
-XXX
-condition codes, processor interrupt level, trap
-enable bit, supervisor mode and previous supervisor mode bits,
-version information, floating point unit and coprocessor enable
-bits, and the current window pointer (cwp).  The cwp field of
-the psr and wim register are used to manage the register windows
-in the SPARC architecture.  The register windows are discussed
-in more detail below.
-XXX
-
-@ifinfo
-@node Calling Conventions Register Windows, Calling Conventions Call and Return Mechanism, Special Registers, Calling Conventions
-@end ifinfo
-@section 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 decrements 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 increments 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 Window Invalid Mask (wim) and the Current Window
-Pointer (cwp) field in the psr are used in conjunction to manage
-the finite set of register windows and detect the window
-overflow and underflow conditions.  The cwp contains the index
-of the register window currently in use.  The save instruction
-decrements the cwp modulo the number of register windows.
-Similarly, the restore instruction increments the cwp modulo the
-number of register windows.  Each bit in the  wim represents
-represents whether a register window contains valid information.
-The value of 0 indicates the register window is valid and 1
-indicates it is invalid.  When a save instruction causes the cwp
-to point to a register window which is marked as invalid, a
-window overflow condition results.  Conversely, the restore
-instruction may result in a window underflow condition.
-
-Other than the assumption that a register window is
-always available for trap (i.e. interrupt) handlers, the SPARC
-architecture places no limits on the number of register windows
-simultaneously marked as invalid (i.e. number of bits set in the
-wim).  However, RTEMS assumes that only one register window is
-marked invalid at a time (i.e. only one bit set in the wim).
-This makes the maximum possible number of register windows
-available to the user while still meeting the requirement that
-window overflow and underflow conditions can be detected.
-
-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.
-
-@ifinfo
-@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Register Windows, Calling Conventions
+The PowerPC architecture includes a number of special registers
+which are critical to the programming model:
+
+@table @b
+
+@item Machine State Register
+
+The MSR contains the processor mode, power management mode, endian mode,
+exception information, privilege level, floating point available and
+floating point excepiton mode, address translation information and
+the exception prefix.
+
+@item Link Register
+
+The LR contains the return address after a function call.  This register
+must be saved before a subsequent subroutine call can be made.  The
+use of this register is discussed further in the @b{Call and Return
+Mechanism} section below.
+
+@item Count Register
+
+The CTR contains the iteration variable for some loops.  It may also be used
+for indirect function calls and jumps.
+
+@end table
+
+@ifinfo
+@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Special Registers, Calling Conventions
 @end ifinfo
 @section 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
+The PowerPC architecture supports a simple yet effective call
+and return mechanism.  A subroutine is invoked
+via the "branch and link" (@code{bl}) and
+"brank and link absolute" (@code{bla})
+instructions.  This instructions place the return address
+in the Link Register (LR).  The callee returns to the caller by 
+executing a "branch unconditional to the link register" (@code{blr})
+instruction.  Thus the callee returns to the caller via a jump
+to the return address which is stored in the LR.
+
+The previous contents of the LR are not automatically saved 
+by either the @code{bl} or @code{bla}.  It is the responsibility
+of the callee to save the contents of the LR before invoking
+another subroutine.  If the callee invokes another subroutine,
+it must restore the LR before executing the @code{blr} instruction
+to return to the caller.
+
+It is important to note that the PowerPC 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.
+restore any registers.
+
+The LR may be accessed as special purpose register 8 (@code{SPR8}) using the
+"move from special register" (@code{mfspr}) and
+"move to special register" (@code{mtspr}) instructions.
 
 @ifinfo
@@ -324,5 +232,6 @@
 
 All RTEMS directives are invoked using the regular
-SPARC calling convention via the call instruction.
+PowerPC EABI calling convention via the @code{bl} or
+@code{bla} instructions.
 
 @ifinfo
@@ -332,9 +241,9 @@
 
 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.
+automatically save any registers.  It is the responsibility
+of the callee to save and restore any registers which must be preserved
+across subroutine calls.  The callee is responsible for saving 
+callee-preserved registers to the program stack and restoring them
+before returning to the caller.
 
 @ifinfo
@@ -344,17 +253,17 @@
 
 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
+general purpose registers with the first argument in 
+register 3 (@code{r3}), the second argument in general purpose
+register 4 (@code{r4}), and so forth until the seventh
+argument is in general purpose register 10 (@code{r10}).  
+If there are more than seven arguments, then subsequent arguments
+are placed on the program stack.  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
+load third argument into r5
+load second argument into r4
+load first argument into r3
 invoke directive
 @end example
@@ -367,6 +276,5 @@
 All user-provided routines invoked by RTEMS, such as
 user extensions, device drivers, and MPCI routines, must also
-adhere to these calling conventions.
-
-
-
+adhere to these same calling conventions.
+
+
Index: doc/supplements/powerpc/cpumodel.t
===================================================================
--- doc/supplements/powerpc/cpumodel.t	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/cpumodel.t	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -15,5 +15,4 @@
 * CPU Model Dependent Features Introduction::
 * CPU Model Dependent Features CPU Model Feature Flags::
-* CPU Model Dependent Features CPU Model Implementation Notes::
 @end menu
 @end ifinfo
@@ -56,5 +55,4 @@
 * CPU Model Dependent Features Has Double Precision Floating Point::
 * CPU Model Dependent Features Critical Interrupts::
-* CPU Model Dependent Features MSR Values::
 * CPU Model Dependent Features Use Multiword Load/Store Instructions::
 * CPU Model Dependent Features Instruction Cache Size::
@@ -147,5 +145,5 @@
 
 @ifinfo
-@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features MSR Values, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Critical Interrupts
@@ -155,12 +153,5 @@
 
 @ifinfo
-@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
-@end ifinfo
-@subsection MSR Values
-
-The macro PPC_MSR_INITIAL is set to
-
-@ifinfo
-@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Use Multiword Load/Store Instructions
@@ -191,41 +182,42 @@
 @subsection Debug Model
 
-The macro PPC_DEBUG_MODEL
+The macro PPC_DEBUG_MODEL is set to indicate the debug support features 
+present in this CPU model.  The following debug support feature sets
+are currently supported:
 
 @table @b
 
 @item @code{PPC_DEBUG_MODEL_STANDARD}
-indicates XXX
+indicates that the single-step trace enable (SE) and branch trace
+enable (BE) bits in the MSR are supported by this CPU model.
 
 @item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
-indicates XXX
+indicates that only the single-step trace enable (SE) bit in the MSR
+is supported by this CPU model. 
 
 @item @code{PPC_DEBUG_MODEL_IBM4xx}
-indicates XXX
+indicates that the debug exception enable (DE) bit in the MSR is supported
+by this CPU model.  At this time, this particular debug feature set 
+has only been seen in the IBM 4xx series.
 
 @end table
 
 @ifinfo
-@node CPU Model Dependent Features Low Power Model, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Low Power Model, Calling Conventions, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Low Power Model
 
-The macro PPC_LOW_POWER_MODE
+The macro PPC_LOW_POWER_MODE is set to indicate the low power model
+supported by this CPU model.  The following low power modes are currently
+supported.
 
 @table @b
 
 @item @code{PPC_LOW_POWER_MODE_NONE}
-indicates XXX
+indicates that this CPU model has no low power mode support.
 
 @item @code{PPC_LOW_POWER_MODE_STANDARD}
-indicates XXX
+indicates that this CPU model follows the low power model defined for
+the PPC603e.
 
 @end table
-
-
-@ifinfo
-@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features
-@end ifinfo
-@section CPU Model Implementation Notes 
-
-TBD
Index: doc/supplements/powerpc/cpumodel.texi
===================================================================
--- doc/supplements/powerpc/cpumodel.texi	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/cpumodel.texi	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -15,5 +15,4 @@
 * CPU Model Dependent Features Introduction::
 * CPU Model Dependent Features CPU Model Feature Flags::
-* CPU Model Dependent Features CPU Model Implementation Notes::
 @end menu
 @end ifinfo
@@ -56,5 +55,4 @@
 * CPU Model Dependent Features Has Double Precision Floating Point::
 * CPU Model Dependent Features Critical Interrupts::
-* CPU Model Dependent Features MSR Values::
 * CPU Model Dependent Features Use Multiword Load/Store Instructions::
 * CPU Model Dependent Features Instruction Cache Size::
@@ -147,5 +145,5 @@
 
 @ifinfo
-@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features MSR Values, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Critical Interrupts
@@ -155,12 +153,5 @@
 
 @ifinfo
-@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
-@end ifinfo
-@subsection MSR Values
-
-The macro PPC_MSR_INITIAL is set to
-
-@ifinfo
-@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Use Multiword Load/Store Instructions
@@ -191,41 +182,42 @@
 @subsection Debug Model
 
-The macro PPC_DEBUG_MODEL
+The macro PPC_DEBUG_MODEL is set to indicate the debug support features 
+present in this CPU model.  The following debug support feature sets
+are currently supported:
 
 @table @b
 
 @item @code{PPC_DEBUG_MODEL_STANDARD}
-indicates XXX
+indicates that the single-step trace enable (SE) and branch trace
+enable (BE) bits in the MSR are supported by this CPU model.
 
 @item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
-indicates XXX
+indicates that only the single-step trace enable (SE) bit in the MSR
+is supported by this CPU model. 
 
 @item @code{PPC_DEBUG_MODEL_IBM4xx}
-indicates XXX
+indicates that the debug exception enable (DE) bit in the MSR is supported
+by this CPU model.  At this time, this particular debug feature set 
+has only been seen in the IBM 4xx series.
 
 @end table
 
 @ifinfo
-@node CPU Model Dependent Features Low Power Model, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Low Power Model, Calling Conventions, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Low Power Model
 
-The macro PPC_LOW_POWER_MODE
+The macro PPC_LOW_POWER_MODE is set to indicate the low power model
+supported by this CPU model.  The following low power modes are currently
+supported.
 
 @table @b
 
 @item @code{PPC_LOW_POWER_MODE_NONE}
-indicates XXX
+indicates that this CPU model has no low power mode support.
 
 @item @code{PPC_LOW_POWER_MODE_STANDARD}
-indicates XXX
+indicates that this CPU model follows the low power model defined for
+the PPC603e.
 
 @end table
-
-
-@ifinfo
-@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features
-@end ifinfo
-@section CPU Model Implementation Notes 
-
-TBD
Index: doc/supplements/powerpc/cputable.t
===================================================================
--- doc/supplements/powerpc/cputable.t	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/cputable.t	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -51,16 +51,17 @@
   /* end of fields required on all CPUs */
 
-  unsigned32   clicks_per_usec; /* Timer clicks per microsecond */
+  unsigned32   clicks_per_usec;       /* Timer clicks per microsecond */
   void       (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
   boolean      exceptions_in_RAM;     /* TRUE if in RAM */
-  unsigned32   serial_per_sec;  /* Serial clocks per second */
+
+#if defined(ppc403)
+  unsigned32   serial_per_sec;        /* Serial clocks per second */
   boolean      serial_external_clock;
   boolean      serial_xon_xoff;
   boolean      serial_cts_rts;
   unsigned32   serial_rate;
-  unsigned32   timer_average_overhead; /* Average overhead of timer in ticks */
-  unsigned32   timer_least_valid; /* Least valid number from timer */
-  void (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
-
+  unsigned32   timer_average_overhead; /* in ticks */
+  unsigned32   timer_least_valid;      /* Least valid number from timer */
+#endif
 @};
 @end example
@@ -133,29 +134,31 @@
 
 @item serial_per_sec
-is the number of clock ticks per second for the PPC403 serial timer.
+is a PPC403 specific field which specifies the number of clock
+ticks per second for the PPC403 serial timer.
 
 @item serial_rate
-is the baud rate for the PPC403 serial timer.
+is a PPC403 specific field which specifies the baud rate for the
+PPC403 serial port.
 
 @item serial_external_clock
-is a flag used by the BSP to indicate whether or not to mask in a 0x2 into
+is a PPC403 specific field which indicates whether or not to mask in a 0x2 into
 the Input/Output Configuration Register (IOCR) during initialization of the
-PPC403 console.  XXX This bit is defined as "reserved" 6-12?
+PPC403 console.  (NOTE: This bit is defined as "reserved" 6-12?)
 
 @item serial_xon_xoff
-is a flag used by the BSP to indicate whether or not  XON/XOFF flow control 
-is supported for the PPC403 serial timer.
+is a PPC403 specific field which indicates whether or not
+XON/XOFF flow control is supported for the PPC403 serial port.
 
 @item serial_cts_rts
-is a flag used by the BSP to indicate whether or not to set the lsb of the 
-Input/Output Configuration Register (IOCR) during initialization of the
-PPC403 console.  XXX This bit is defined as "reserved" 6-12?
-
+is a PPC403 specific field which indicates whether or not to set the 
+least significant bit of the Input/Output Configuration Register
+(IOCR) during initialization of the PPC403 console.  (NOTE: This
+bit is defined as "reserved" 6-12?)
 
 @item timer_average_overhead
-is the average number of overhead ticks that occur on the PPC403 timer.
+is a PPC403 specific field which specifies the average number of overhead ticks that occur on the PPC403 timer.
 
 @item timer_least_valid
-is the maximum valid PPC403 timer value.
+is a PPC403 specific field which specifies the maximum valid PPC403 timer value.
 
 @end table
Index: doc/supplements/powerpc/cputable.texi
===================================================================
--- doc/supplements/powerpc/cputable.texi	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/cputable.texi	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -51,16 +51,17 @@
   /* end of fields required on all CPUs */
 
-  unsigned32   clicks_per_usec; /* Timer clicks per microsecond */
+  unsigned32   clicks_per_usec;       /* Timer clicks per microsecond */
   void       (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
   boolean      exceptions_in_RAM;     /* TRUE if in RAM */
-  unsigned32   serial_per_sec;  /* Serial clocks per second */
+
+#if defined(ppc403)
+  unsigned32   serial_per_sec;        /* Serial clocks per second */
   boolean      serial_external_clock;
   boolean      serial_xon_xoff;
   boolean      serial_cts_rts;
   unsigned32   serial_rate;
-  unsigned32   timer_average_overhead; /* Average overhead of timer in ticks */
-  unsigned32   timer_least_valid; /* Least valid number from timer */
-  void (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
-
+  unsigned32   timer_average_overhead; /* in ticks */
+  unsigned32   timer_least_valid;      /* Least valid number from timer */
+#endif
 @};
 @end example
@@ -133,29 +134,31 @@
 
 @item serial_per_sec
-is the number of clock ticks per second for the PPC403 serial timer.
+is a PPC403 specific field which specifies the number of clock
+ticks per second for the PPC403 serial timer.
 
 @item serial_rate
-is the baud rate for the PPC403 serial timer.
+is a PPC403 specific field which specifies the baud rate for the
+PPC403 serial port.
 
 @item serial_external_clock
-is a flag used by the BSP to indicate whether or not to mask in a 0x2 into
+is a PPC403 specific field which indicates whether or not to mask in a 0x2 into
 the Input/Output Configuration Register (IOCR) during initialization of the
-PPC403 console.  XXX This bit is defined as "reserved" 6-12?
+PPC403 console.  (NOTE: This bit is defined as "reserved" 6-12?)
 
 @item serial_xon_xoff
-is a flag used by the BSP to indicate whether or not  XON/XOFF flow control 
-is supported for the PPC403 serial timer.
+is a PPC403 specific field which indicates whether or not
+XON/XOFF flow control is supported for the PPC403 serial port.
 
 @item serial_cts_rts
-is a flag used by the BSP to indicate whether or not to set the lsb of the 
-Input/Output Configuration Register (IOCR) during initialization of the
-PPC403 console.  XXX This bit is defined as "reserved" 6-12?
-
+is a PPC403 specific field which indicates whether or not to set the 
+least significant bit of the Input/Output Configuration Register
+(IOCR) during initialization of the PPC403 console.  (NOTE: This
+bit is defined as "reserved" 6-12?)
 
 @item timer_average_overhead
-is the average number of overhead ticks that occur on the PPC403 timer.
+is a PPC403 specific field which specifies the average number of overhead ticks that occur on the PPC403 timer.
 
 @item timer_least_valid
-is the maximum valid PPC403 timer value.
+is a PPC403 specific field which specifies the maximum valid PPC403 timer value.
 
 @end table
Index: doc/supplements/powerpc/fatalerr.t
===================================================================
--- doc/supplements/powerpc/fatalerr.t	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/fatalerr.t	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -39,8 +39,24 @@
 
 The default fatal error handler which is invoked by
-the fatal_error_occurred directive when there is no user handler
+the @code{rtems_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 all processor exceptions,
-places the error code in r5, and goes into an infinite
-loop to simulate a halt processor instruction.
+default fatal error handler performs the following actions:
 
+@itemize @bullet
+
+@item places the error code in r3, and
+
+@item executes a trap instruction which results in a Program Exception.
+
+@end itemize
+
+If the Program Exception returns, then the following actions are performed:
+
+@itemize @bullet
+
+@item disables all processor exceptions by loading a 0 into the MSR, and
+
+@item goes into an infinite loop to simulate a halt processor instruction.
+
+@end itemize
+
Index: doc/supplements/powerpc/fatalerr.texi
===================================================================
--- doc/supplements/powerpc/fatalerr.texi	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/fatalerr.texi	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -39,8 +39,24 @@
 
 The default fatal error handler which is invoked by
-the fatal_error_occurred directive when there is no user handler
+the @code{rtems_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 all processor exceptions,
-places the error code in r5, and goes into an infinite
-loop to simulate a halt processor instruction.
+default fatal error handler performs the following actions:
 
+@itemize @bullet
+
+@item places the error code in r3, and
+
+@item executes a trap instruction which results in a Program Exception.
+
+@end itemize
+
+If the Program Exception returns, then the following actions are performed:
+
+@itemize @bullet
+
+@item disables all processor exceptions by loading a 0 into the MSR, and
+
+@item goes into an infinite loop to simulate a halt processor instruction.
+
+@end itemize
+
Index: doc/supplements/powerpc/intr.t
===================================================================
--- doc/supplements/powerpc/intr.t	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/intr.t	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -38,10 +38,10 @@
 details of interrupt processing, it is important to understand
 how the RTEMS interrupt manager is mapped onto the processor's
-unique architecture. Discussed in this chapter are the PPC's
+unique architecture. Discussed in this chapter are the PowerPC's
 interrupt response and control mechanisms as they pertain to
 RTEMS.
 
 RTEMS and associated documentation uses the terms
-interrupt and vector.  In the PPC architecture, these terms
+interrupt and vector.  In the PowerPC architecture, these terms
 correspond to exception and exception handler, respectively.  The terms will
 be used interchangeably in this manual.
@@ -52,5 +52,5 @@
 @section Synchronous Versus Asynchronous Exceptions
 
-In the PPC architecture exceptions can be either precise or 
+In the PowerPC architecture exceptions can be either precise or 
 imprecise and either synchronous or asynchronous.  Asynchronous 
 exceptions occur when an external event interrupts the processor.
@@ -78,5 +78,5 @@
 @section Vectoring of Interrupt Handler
 
-Upon determining that an exception can be taken the PPC  automatically
+Upon determining that an exception can be taken the PowerPC automatically
 performs the following actions:
 
@@ -95,5 +95,4 @@
 
 @end itemize
-
 
 If the interrupt handler was installed as an RTEMS
@@ -105,6 +104,7 @@
 @item saves the state of the interrupted task on it's stack,
 
-@item insures that a register window is available for
-subsequent exceptions,
+@item saves all registers which are not normally preserved
+by the calling sequence so the user's interrupt service
+routine can be written in a high-level language.
 
 @item if this is the outermost (i.e. non-nested) interrupt,
@@ -118,5 +118,5 @@
 
 Asynchronous interrupts are ignored while exceptions are
-disabled.  Synchronous interrupts which occur while  are
+disabled.  Synchronous interrupts which occur while are
 disabled result in the CPU being forced into an error mode.
 
@@ -130,14 +130,37 @@
 @section Interrupt Levels
 
-TBD levels (0-TBD) of interrupt priorities are
-supported by the PowerPC architecture with level TBD (TBD)
-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.
-
-TBD
-All other RTEMS interrupt levels are undefined and their behavior is
-unpredictable.
+The PowerPC architecture supports only a single external
+asynchronous interrupt source.  This interrupt source
+may be enabled and disabled via the External Interrupt Enable (EE)
+bit in the Machine State Register (MSR).  Thus only two level (enabled
+and disabled) of external device interrupt priorities are 
+directly supported by the PowerPC architecture.  
+
+Some PowerPC implementations include a Critical Interrupt capability
+which is often used to receive interrupts from high priority external
+devices.
+
+The RTEMS interrupt level mapping scheme for the PowerPC is not 
+a numeric level as on most RTEMS ports.  It is a bit mapping in
+which the least three significiant bits of the interrupt level
+are mapped directly to the enabling of specific interrupt 
+sources as follows:
+
+@table @b
+
+@item Critical Interrupt
+Setting bit 0 (the least significant bit) of the interrupt level
+enables the Critical Interrupt source, if it is available on this
+CPU model.
+
+@item Machine Check
+Setting bit 1 of the interrupt level enables Machine Check execptions.
+
+@item External Interrupt
+Setting bit 2 of the interrupt level enables External Interrupt execptions.
+
+@end table
+
+All other bits in the RTEMS task interrupt level are ignored.
 
 @ifinfo
@@ -148,7 +171,7 @@
 During the execution of directive calls, critical
 sections of code may be executed.  When these sections are
-encountered, RTEMS disables interrupts to level TBD (TBD)
-before the execution of this section and restores them to the
-previous level upon completion of the section.  RTEMS has been
+encountered, RTEMS disables Critical Interrupts, External Interrupts
+and Machine Checks before the execution of this section and restores
+them to the previous level upon completion of the section.  RTEMS has been
 optimized to insure that interrupts are disabled for less than
 RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a 
@@ -160,15 +183,10 @@
 RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
 
-[NOTE: It is thought that the length of time at which
-the processor interrupt level is elevated to fifteen by RTEMS is
-not anywhere near as long as the length of time ALL exceptions are
-disabled as part of the "flush all register windows" operation.]
-
-Non-maskable interrupts (NMI) cannot be disabled, and
-ISRs which execute at this level MUST NEVER issue RTEMS system
-calls.  If a directive is invoked, unpredictable results may
-occur due to the inability of RTEMS to protect its critical
-sections.  However, ISRs that make no system calls may safely
-execute as non-maskable interrupts.
+If a PowerPC implementation provides non-maskable interrupts (NMI)
+which cannot be disabled, ISRs which process these interrupts
+MUST NEVER issue RTEMS system calls.  If a directive is invoked,
+unpredictable results may occur due to the inability of RTEMS
+to protect its critical sections.  However, ISRs that make no
+system calls may safely execute as non-maskable interrupts.
 
 @ifinfo
Index: doc/supplements/powerpc/intr_NOTIMES.t
===================================================================
--- doc/supplements/powerpc/intr_NOTIMES.t	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/intr_NOTIMES.t	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -38,10 +38,10 @@
 details of interrupt processing, it is important to understand
 how the RTEMS interrupt manager is mapped onto the processor's
-unique architecture. Discussed in this chapter are the PPC's
+unique architecture. Discussed in this chapter are the PowerPC's
 interrupt response and control mechanisms as they pertain to
 RTEMS.
 
 RTEMS and associated documentation uses the terms
-interrupt and vector.  In the PPC architecture, these terms
+interrupt and vector.  In the PowerPC architecture, these terms
 correspond to exception and exception handler, respectively.  The terms will
 be used interchangeably in this manual.
@@ -52,5 +52,5 @@
 @section Synchronous Versus Asynchronous Exceptions
 
-In the PPC architecture exceptions can be either precise or 
+In the PowerPC architecture exceptions can be either precise or 
 imprecise and either synchronous or asynchronous.  Asynchronous 
 exceptions occur when an external event interrupts the processor.
@@ -78,5 +78,5 @@
 @section Vectoring of Interrupt Handler
 
-Upon determining that an exception can be taken the PPC  automatically
+Upon determining that an exception can be taken the PowerPC automatically
 performs the following actions:
 
@@ -95,5 +95,4 @@
 
 @end itemize
-
 
 If the interrupt handler was installed as an RTEMS
@@ -105,6 +104,7 @@
 @item saves the state of the interrupted task on it's stack,
 
-@item insures that a register window is available for
-subsequent exceptions,
+@item saves all registers which are not normally preserved
+by the calling sequence so the user's interrupt service
+routine can be written in a high-level language.
 
 @item if this is the outermost (i.e. non-nested) interrupt,
@@ -118,5 +118,5 @@
 
 Asynchronous interrupts are ignored while exceptions are
-disabled.  Synchronous interrupts which occur while  are
+disabled.  Synchronous interrupts which occur while are
 disabled result in the CPU being forced into an error mode.
 
@@ -130,14 +130,37 @@
 @section Interrupt Levels
 
-TBD levels (0-TBD) of interrupt priorities are
-supported by the PowerPC architecture with level TBD (TBD)
-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.
-
-TBD
-All other RTEMS interrupt levels are undefined and their behavior is
-unpredictable.
+The PowerPC architecture supports only a single external
+asynchronous interrupt source.  This interrupt source
+may be enabled and disabled via the External Interrupt Enable (EE)
+bit in the Machine State Register (MSR).  Thus only two level (enabled
+and disabled) of external device interrupt priorities are 
+directly supported by the PowerPC architecture.  
+
+Some PowerPC implementations include a Critical Interrupt capability
+which is often used to receive interrupts from high priority external
+devices.
+
+The RTEMS interrupt level mapping scheme for the PowerPC is not 
+a numeric level as on most RTEMS ports.  It is a bit mapping in
+which the least three significiant bits of the interrupt level
+are mapped directly to the enabling of specific interrupt 
+sources as follows:
+
+@table @b
+
+@item Critical Interrupt
+Setting bit 0 (the least significant bit) of the interrupt level
+enables the Critical Interrupt source, if it is available on this
+CPU model.
+
+@item Machine Check
+Setting bit 1 of the interrupt level enables Machine Check execptions.
+
+@item External Interrupt
+Setting bit 2 of the interrupt level enables External Interrupt execptions.
+
+@end table
+
+All other bits in the RTEMS task interrupt level are ignored.
 
 @ifinfo
@@ -148,7 +171,7 @@
 During the execution of directive calls, critical
 sections of code may be executed.  When these sections are
-encountered, RTEMS disables interrupts to level TBD (TBD)
-before the execution of this section and restores them to the
-previous level upon completion of the section.  RTEMS has been
+encountered, RTEMS disables Critical Interrupts, External Interrupts
+and Machine Checks before the execution of this section and restores
+them to the previous level upon completion of the section.  RTEMS has been
 optimized to insure that interrupts are disabled for less than
 RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a 
@@ -160,15 +183,10 @@
 RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
 
-[NOTE: It is thought that the length of time at which
-the processor interrupt level is elevated to fifteen by RTEMS is
-not anywhere near as long as the length of time ALL exceptions are
-disabled as part of the "flush all register windows" operation.]
-
-Non-maskable interrupts (NMI) cannot be disabled, and
-ISRs which execute at this level MUST NEVER issue RTEMS system
-calls.  If a directive is invoked, unpredictable results may
-occur due to the inability of RTEMS to protect its critical
-sections.  However, ISRs that make no system calls may safely
-execute as non-maskable interrupts.
+If a PowerPC implementation provides non-maskable interrupts (NMI)
+which cannot be disabled, ISRs which process these interrupts
+MUST NEVER issue RTEMS system calls.  If a directive is invoked,
+unpredictable results may occur due to the inability of RTEMS
+to protect its critical sections.  However, ISRs that make no
+system calls may safely execute as non-maskable interrupts.
 
 @ifinfo
Index: doc/supplements/powerpc/memmodel.t
===================================================================
--- doc/supplements/powerpc/memmodel.t	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/memmodel.t	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -42,5 +42,5 @@
 converts every address from a logical to a physical address
 each time it is used.  The PowerPC uses information provided
-in the XXX to convert these addresses.
+in the Block Address Translation (BAT) to convert these addresses.
 
 Implementations of the PowerPC architecture may be thirty-two or sixty-four bit.
@@ -120,5 +120,5 @@
 PowerPC CPU models which are sixty-four bit implementations.
 
-RTEMS does not directly support any PowerPC  Memory Management
+RTEMS does not directly support any PowerPC Memory Management
 Units, therefore, virtual memory or segmentation systems
 involving the PowerPC  are not supported.
Index: doc/supplements/powerpc/memmodel.texi
===================================================================
--- doc/supplements/powerpc/memmodel.texi	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/memmodel.texi	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -42,5 +42,5 @@
 converts every address from a logical to a physical address
 each time it is used.  The PowerPC uses information provided
-in the XXX to convert these addresses.
+in the Block Address Translation (BAT) to convert these addresses.
 
 Implementations of the PowerPC architecture may be thirty-two or sixty-four bit.
@@ -120,5 +120,5 @@
 PowerPC CPU models which are sixty-four bit implementations.
 
-RTEMS does not directly support any PowerPC  Memory Management
+RTEMS does not directly support any PowerPC Memory Management
 Units, therefore, virtual memory or segmentation systems
 involving the PowerPC  are not supported.
Index: doc/supplements/powerpc/preface.texi
===================================================================
--- doc/supplements/powerpc/preface.texi	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/powerpc/preface.texi	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -34,10 +34,45 @@
 
 For information on the PowerPC architecture, refer to
-the following documents available from Motorola
-(http://www.moto.com):
+the following documents available from Motorola and IBM:
 
 @itemize @bullet
-@item some PowerPC document shere
+
+@item @cite{PowerPC Microprocessor Family: The Programming Environment}
+(Motorola Document MPRPPCFPE-01).
+
+@item @cite{IBM PPC403GB Embedded Controller User's Manual}.
+
+@item @cite{PoweRisControl MPC500 Family RCPU RISC Central Processing
+Unit Reference Manual} (Motorola Document RCPUURM/AD).
+
+@item @cite{PowerPC 601 RISC Microprocessor User's Manual}
+(Motorola Document MPR601UM/AD).
+
+@item @cite{PowerPC 603 RISC Microprocessor User's Manual}
+(Motorola Document MPR603UM/AD).
+
+@item @cite{PowerPC 603e RISC Microprocessor User's Manual}
+(Motorola Document MPR603EUM/AD).
+
+@item @cite{PowerPC 604 RISC Microprocessor User's Manual}
+(Motorola Document MPR604UM/AD).
+
+@item @cite{PowerPC MPC821 Portable Systems Microprocessor User's Manual}
+(Motorola Document MPC821UM/AD).
+
+@item @cite{PowerQUICC MPC860 User's Manual} (Motorola Document MPC860UM/AD).
+
+
 @end itemize
+
+Motorola maintains an on-line electronic library for the PowerPC
+at the following URL:
+
+@itemize @code{ }
+@item @cite{http://www.mot.com/powerpc/library/library.html}
+@end itemize
+
+This site has a a wealth of information and examples.  Many of the
+manuals are available from that site in electronic format.
 
 @subheading PowerPC Processor Simulator Information
Index: doc/supplements/sparc/bsp.t
===================================================================
--- doc/supplements/sparc/bsp.t	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/sparc/bsp.t	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -71,5 +71,5 @@
 RTEMS installs it's own Trap Table as part of initialization
 which is initialized with the contents of the Trap Table in
-place when the rtems_initialize_executive directive was invoked.
+place when the @code{rtems_initialize_executive} directive was invoked.
 Upon completion of executive initialization, interrupts are
 enabled.
@@ -83,5 +83,5 @@
 Applications User's Manual for the reset code
 which is executed before the call to
-rtems_initialize executive, the SPARC version has the following
+@code{rtems_initialize_executive}, the SPARC version has the following
 specific requirements:
 
@@ -92,5 +92,5 @@
 @item Must set stack pointer (sp) such that a minimum stack
 size of MINIMUM_STACK_SIZE bytes is provided for the
-rtems_initialize executive directive.
+@code{rtems_initialize_executive} directive.
 
 @item Must disable all external interrupts (i.e. set the pil
Index: doc/supplements/sparc/bsp.texi
===================================================================
--- doc/supplements/sparc/bsp.texi	(revision 84b0f7c99d076f128bf6e8ac289cb8a5fe7b1b89)
+++ doc/supplements/sparc/bsp.texi	(revision 9aceddaf7c4ba29477f1d5a682a21e17a597e5fb)
@@ -71,5 +71,5 @@
 RTEMS installs it's own Trap Table as part of initialization
 which is initialized with the contents of the Trap Table in
-place when the rtems_initialize_executive directive was invoked.
+place when the @code{rtems_initialize_executive} directive was invoked.
 Upon completion of executive initialization, interrupts are
 enabled.
@@ -83,5 +83,5 @@
 Applications User's Manual for the reset code
 which is executed before the call to
-rtems_initialize executive, the SPARC version has the following
+@code{rtems_initialize_executive}, the SPARC version has the following
 specific requirements:
 
@@ -92,5 +92,5 @@
 @item Must set stack pointer (sp) such that a minimum stack
 size of MINIMUM_STACK_SIZE bytes is provided for the
-rtems_initialize executive directive.
+@code{rtems_initialize_executive} directive.
 
 @item Must disable all external interrupts (i.e. set the pil
