Added more info.

6 files changed, 276 insertions, 272 deletions

diff --git a/doc/supplements/powerpc/bsp.t b/doc/supplements/powerpc/bsp.t
index 76374ccb14..abad444307 100644
--- a/doc/supplements/powerpc/bsp.t
+++ b/doc/supplements/powerpc/bsp.t
@@ -25,7 +25,7 @@
 
 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.
+This chapter presents a discussion of PowerPC 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.
@@ -36,21 +36,22 @@ Applications User's Guide.
 @section System Reset
 
 An RTEMS based application is initiated or
-re-initiated when the SPARC processor is reset.  When the SPARC
+re-initiated when the PowerPC processor is reset.  When the PowerPC
 is reset, the processor performs the following actions:
 
 @itemize @bullet
-@item the enable trap (ET) of the psr is set to 0 to disable
-traps,
+@item TBD
 
-@item the supervisor bit (S) of the psr is set to 1 to enter
-supervisor mode, and
+@item TBD
 
-@item the PC is set 0 and the nPC is set to 4.
+@item TBD
 @end itemize
 
-The processor then begins to execute the code at
-location 0.  It is important to note that all fields in the psr
+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
@@ -79,7 +80,7 @@ and this is to be utilized, then it should be enabled during the
 reset application initialization code.
 
 In addition to the requirements described in the
-Board Support Packages chapter of the @value{RTEMS-LANGUAGE}
+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 SPARC version has the following
diff --git a/doc/supplements/powerpc/bsp.texi b/doc/supplements/powerpc/bsp.texi
index 76374ccb14..abad444307 100644
--- a/doc/supplements/powerpc/bsp.texi
+++ b/doc/supplements/powerpc/bsp.texi
@@ -25,7 +25,7 @@
 
 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.
+This chapter presents a discussion of PowerPC 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.
@@ -36,21 +36,22 @@ Applications User's Guide.
 @section System Reset
 
 An RTEMS based application is initiated or
-re-initiated when the SPARC processor is reset.  When the SPARC
+re-initiated when the PowerPC processor is reset.  When the PowerPC
 is reset, the processor performs the following actions:
 
 @itemize @bullet
-@item the enable trap (ET) of the psr is set to 0 to disable
-traps,
+@item TBD
 
-@item the supervisor bit (S) of the psr is set to 1 to enter
-supervisor mode, and
+@item TBD
 
-@item the PC is set 0 and the nPC is set to 4.
+@item TBD
 @end itemize
 
-The processor then begins to execute the code at
-location 0.  It is important to note that all fields in the psr
+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
@@ -79,7 +80,7 @@ and this is to be utilized, then it should be enabled during the
 reset application initialization code.
 
 In addition to the requirements described in the
-Board Support Packages chapter of the @value{RTEMS-LANGUAGE}
+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 SPARC version has the following
diff --git a/doc/supplements/powerpc/cpumodel.t b/doc/supplements/powerpc/cpumodel.t
index 1280fdf9c4..609854c743 100644
--- a/doc/supplements/powerpc/cpumodel.t
+++ b/doc/supplements/powerpc/cpumodel.t
@@ -56,10 +56,11 @@ across the entire family.
 * 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 FPU Status Control Register Values::
 * CPU Model Dependent Features Use Multiword Load/Store Instructions::
 * CPU Model Dependent Features Instruction Cache Size::
 * CPU Model Dependent Features Data Cache Size::
+* CPU Model Dependent Features Debug Model::
+* CPU Model Dependent Features Low Power Model::
 @end menu
 @end ifinfo
 
@@ -99,94 +100,131 @@ model, this macro is set to the string "PowerPC 603e".
 @end ifinfo
 @subsection Floating Point Unit
 
-The macro PPC_HAS_FPU is set to 1 to indicate that
-this CPU model has a hardware floating point unit and 0
-otherwise.
+The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model
+has a hardware floating point unit and 0 otherwise.
 
 @ifinfo
 @node CPU Model Dependent Features Alignment, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Alignment
 
-The macro PPC_ALIGNMENT is set to 
+The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment
+requirement for data types on a byte boundary.  This value is used
+to derive the alignment restrictions for memory allocated from 
+regions and partitions.
 
 @ifinfo
 @node CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Alignment, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Cache Alignment
 
-The macro PPC_CACHE_ALIGNMENT is set to 
+The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache.  It is
+used to align the entry point of critical routines so that as much code
+as possible can be retrieved with the initial read into cache.  This
+is done for the interrupt handler as well as the context switch routines.
 
-Similarly, the macro PPC_CACHE_ALIGN_POWER is set to the 
+In addition, the "shortcut" data structure used by the PowerPC implementation
+to ease access to data elements frequently accessed by RTEMS routines
+implemented in assembly language is aligned using this value.
 
 @ifinfo
 @node CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Maximum Interrupts
 
-The macro PPC_INTERRUPT_MAX is set to
+The macro PPC_INTERRUPT_MAX is set to the number of exception sources
+supported by this PowerPC model.
 
 @ifinfo
 @node CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Has Double Precision Floating Point
 
-The macro PPC_HAS_DOUBLE is set to
+The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model
+has support for double precision floating point numbers.  This is
+important because the floating point registers need only be four bytes
+wide (not eight) if double precision is not supported.
 
 @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
 @end ifinfo
 @subsection Critical Interrupts
 
-The macro PPC_HAS_RFCI is set to
+The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model
+has the Critical Interrupt capability as defined by the IBM 403 models.
 
 @ifinfo
-@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
+@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_DISABLE_MASK is set to
-
 The macro PPC_MSR_INITIAL is set to
 
-The macro PPC_MSR_0 is set to
-
-The macro PPC_MSR_1 is set to
-
-The macro PPC_MSR_2 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
+@end ifinfo
+@subsection Use Multiword Load/Store Instructions
 
-The macro PPC_MSR_3 is set to
+The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and
+store instructions should be used to perform context switch operations.
+The relative efficiency of multiword load and store instructions versus
+an equivalent set of single word load and store instructions varies based
+upon the PowerPC model.
 
 @ifinfo
-@node CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
-@subsection FPU Status Control Register Values
+@subsection Instruction Cache Size
 
-The macro PPC_INIT_FPSCR is set to
+The macro PPC_I_CACHE is set to the size in bytes of the instruction cache.
 
 @ifinfo
-@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Debug Model, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
-@subsection Use Multiword Load/Store Instructions
+@subsection Data Cache Size
 
-The macro PPC_USE_MULTIPLE is set to
+The macro PPC_D_CACHE is set to the size in bytes of the data cache.
 
 @ifinfo
-@node CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Debug Model, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
-@subsection Instruction Cache Size
+@subsection Debug Model
 
-The macro PPC_I_CACHE is set to 
+The macro PPC_DEBUG_MODEL
+
+@table @b
+
+@item @code{PPC_DEBUG_MODEL_STANDARD}
+indicates XXX
+
+@item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
+indicates XXX
+
+@item @code{PPC_DEBUG_MODEL_IBM4xx}
+indicates XXX
+
+@end table
 
 @ifinfo
-@node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags
+@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
 @end ifinfo
-@subsection Data Cache Size
+@subsection Low Power Model
+
+The macro PPC_LOW_POWER_MODE
+
+@table @b
+
+@item @code{PPC_LOW_POWER_MODE_NONE}
+indicates XXX
+
+@item @code{PPC_LOW_POWER_MODE_STANDARD}
+indicates XXX
+
+@end table
 
-The macro PPC_D_CACHE is set to
 
 @ifinfo
-@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features
+@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 
 
diff --git a/doc/supplements/powerpc/cpumodel.texi b/doc/supplements/powerpc/cpumodel.texi
index 1280fdf9c4..609854c743 100644
--- a/doc/supplements/powerpc/cpumodel.texi
+++ b/doc/supplements/powerpc/cpumodel.texi
@@ -56,10 +56,11 @@ across the entire family.
 * 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 FPU Status Control Register Values::
 * CPU Model Dependent Features Use Multiword Load/Store Instructions::
 * CPU Model Dependent Features Instruction Cache Size::
 * CPU Model Dependent Features Data Cache Size::
+* CPU Model Dependent Features Debug Model::
+* CPU Model Dependent Features Low Power Model::
 @end menu
 @end ifinfo
 
@@ -99,94 +100,131 @@ model, this macro is set to the string "PowerPC 603e".
 @end ifinfo
 @subsection Floating Point Unit
 
-The macro PPC_HAS_FPU is set to 1 to indicate that
-this CPU model has a hardware floating point unit and 0
-otherwise.
+The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model
+has a hardware floating point unit and 0 otherwise.
 
 @ifinfo
 @node CPU Model Dependent Features Alignment, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Alignment
 
-The macro PPC_ALIGNMENT is set to 
+The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment
+requirement for data types on a byte boundary.  This value is used
+to derive the alignment restrictions for memory allocated from 
+regions and partitions.
 
 @ifinfo
 @node CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Alignment, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Cache Alignment
 
-The macro PPC_CACHE_ALIGNMENT is set to 
+The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache.  It is
+used to align the entry point of critical routines so that as much code
+as possible can be retrieved with the initial read into cache.  This
+is done for the interrupt handler as well as the context switch routines.
 
-Similarly, the macro PPC_CACHE_ALIGN_POWER is set to the 
+In addition, the "shortcut" data structure used by the PowerPC implementation
+to ease access to data elements frequently accessed by RTEMS routines
+implemented in assembly language is aligned using this value.
 
 @ifinfo
 @node CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Cache Alignment, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Maximum Interrupts
 
-The macro PPC_INTERRUPT_MAX is set to
+The macro PPC_INTERRUPT_MAX is set to the number of exception sources
+supported by this PowerPC model.
 
 @ifinfo
 @node CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Maximum Interrupts, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
 @subsection Has Double Precision Floating Point
 
-The macro PPC_HAS_DOUBLE is set to
+The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model
+has support for double precision floating point numbers.  This is
+important because the floating point registers need only be four bytes
+wide (not eight) if double precision is not supported.
 
 @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
 @end ifinfo
 @subsection Critical Interrupts
 
-The macro PPC_HAS_RFCI is set to
+The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model
+has the Critical Interrupt capability as defined by the IBM 403 models.
 
 @ifinfo
-@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
+@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_DISABLE_MASK is set to
-
 The macro PPC_MSR_INITIAL is set to
 
-The macro PPC_MSR_0 is set to
-
-The macro PPC_MSR_1 is set to
-
-The macro PPC_MSR_2 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
+@end ifinfo
+@subsection Use Multiword Load/Store Instructions
 
-The macro PPC_MSR_3 is set to
+The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and
+store instructions should be used to perform context switch operations.
+The relative efficiency of multiword load and store instructions versus
+an equivalent set of single word load and store instructions varies based
+upon the PowerPC model.
 
 @ifinfo
-@node CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
-@subsection FPU Status Control Register Values
+@subsection Instruction Cache Size
 
-The macro PPC_INIT_FPSCR is set to
+The macro PPC_I_CACHE is set to the size in bytes of the instruction cache.
 
 @ifinfo
-@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features FPU Status Control Register Values, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Debug Model, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
-@subsection Use Multiword Load/Store Instructions
+@subsection Data Cache Size
 
-The macro PPC_USE_MULTIPLE is set to
+The macro PPC_D_CACHE is set to the size in bytes of the data cache.
 
 @ifinfo
-@node CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features CPU Model Feature Flags
+@node CPU Model Dependent Features Debug Model, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Feature Flags
 @end ifinfo
-@subsection Instruction Cache Size
+@subsection Debug Model
 
-The macro PPC_I_CACHE is set to 
+The macro PPC_DEBUG_MODEL
+
+@table @b
+
+@item @code{PPC_DEBUG_MODEL_STANDARD}
+indicates XXX
+
+@item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
+indicates XXX
+
+@item @code{PPC_DEBUG_MODEL_IBM4xx}
+indicates XXX
+
+@end table
 
 @ifinfo
-@node CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features CPU Model Feature Flags
+@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
 @end ifinfo
-@subsection Data Cache Size
+@subsection Low Power Model
+
+The macro PPC_LOW_POWER_MODE
+
+@table @b
+
+@item @code{PPC_LOW_POWER_MODE_NONE}
+indicates XXX
+
+@item @code{PPC_LOW_POWER_MODE_STANDARD}
+indicates XXX
+
+@end table
 
-The macro PPC_D_CACHE is set to
 
 @ifinfo
-@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Data Cache Size, CPU Model Dependent Features
+@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 
 
diff --git a/doc/supplements/powerpc/intr.t b/doc/supplements/powerpc/intr.t
index 941cd1c2b7..1530dad5e4 100644
--- a/doc/supplements/powerpc/intr.t
+++ b/doc/supplements/powerpc/intr.t
@@ -13,9 +13,8 @@
 @ifinfo
 @menu
 * Interrupt Processing Introduction::
-* Interrupt Processing Synchronous Versus Asynchronous Traps::
+* Interrupt Processing Synchronous Versus Asynchronous Exceptions::
 * Interrupt Processing Vectoring of Interrupt Handler::
-* Interrupt Processing Traps and Register Windows::
 * Interrupt Processing Interrupt Levels::
 * Interrupt Processing Disabling of Interrupts by RTEMS::
 * Interrupt Processing Interrupt Stack::
@@ -23,7 +22,7 @@
 @end ifinfo
 
 @ifinfo
-@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing
+@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing, Interrupt Processing
 @end ifinfo
 @section Introduction
 
@@ -38,80 +37,64 @@ special control mechanisms to return to the normal processing
 stream.  Although RTEMS hides many of the processor dependent
 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 SPARC's
+unique architecture. Discussed in this chapter are the PPC's
 interrupt response and control mechanisms as they pertain to
 RTEMS.
 
 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
+interrupt and vector.  In the PPC architecture, these terms
+correspond to exception and exception handler, respectively.  The terms will
 be used interchangeably in this manual.
 
 @ifinfo
-@node Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
+@node Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
 @end ifinfo
-@section Synchronous Versus Asynchronous Traps
-
-The SPARC architecture includes two classes of traps:
-synchronous and asynchronous.  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.
+@section Synchronous Versus Asynchronous Exceptions
+
+In the PPC architecture exceptions can be either precise or 
+imprecise and either synchronous or asynchronous.  Asynchronous 
+exceptions occur when an external event interrupts the processor.
+Synchronous exceptions are caused by the actions of an 
+instruction. During an exception SRR0 is used to calculate where 
+instruction processing should resume.  All instructions prior to
+the resume instruction will have completed execution.  SRR1 is used to 
+store the machine status.
+
+There are two asynchronous nonmaskable, highest-priority exceptions
+system reset and machine check.  There are two asynchrononous maskable
+low-priority exceptions external interrupt and decrementer.  Nonmaskable
+execptions are never delayed, therefore if two nonmaskable, asynchronous 
+exceptions occur in immediate succession, the state information saved by
+the first exception may be overwritten when the subsequent exception occurs. 
+
+The PowerPC arcitecure defines one imprecise exception, the imprecise 
+floating point enabled exception.  All other synchronous exceptions are
+precise.  The synchronization occuring during asynchronous precise 
+exceptions conforms to the requirements for context synchronization.
 
 @ifinfo
-@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing
+@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Levels, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing
 @end ifinfo
 @section Vectoring of Interrupt Handler
 
-Upon receipt of an interrupt the SPARC automatically
+Upon determining that an exception can be taken the PPC  automatically
 performs the following actions:
 
 @itemize @bullet
-@item disables traps (sets the ET bit of the psr to 0),
+@item an instruction address is loaded into SRR0
 
-@item the S bit of the psr is copied into the Previous
-Supervisor Mode (PS) bit of the psr,
+@item bits 33-36 and 42-47 of SRR1 are loaded with information 
+specific to the exception.
 
-@item the cwp is decremented by one (modulo the number of
-register windows) to activate a trap window,
+@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding
+bits from the MSR.
 
-@item the PC and nPC are loaded into local register 1 and 2
-(l0 and l1),
+@item the MSR is set based upon the exception type.
 
-@item the trap type (tt) field of the Trap Base Register (TBR)
-is set to the appropriate value, and
+@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type. 
 
-@item if the trap is not a reset, then the PC is written with
-the contents of the TBR and the nPC is written with TBR + 4.  If
-the trap is a reset, then the PC is set to zero and the nPC is
-set to 4.
 @end itemize
 
-Trap processing on the SPARC has two features which
-are noticeably different than interrupt processing on other
-architectures.  First, the value of psr register in effect
-immediately before the trap occurred is not explicitly saved.
-Instead only reversible alterations are made to it.  Second, the
-Processor Interrupt Level (pil) is not set to correspond to that
-of the interrupt being processed.  When a trap occurs, ALL
-subsequent traps are disabled.  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
@@ -122,19 +105,19 @@ performs the following actions:
 @item saves the state of the interrupted task on it's stack,
 
 @item insures that a register window is available for
-subsequent traps,
+subsequent exceptions,
 
 @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 enables exceptions,
 
 @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
+Asynchronous interrupts are ignored while exceptions are
+disabled.  Synchronous interrupts which occur while  are
 disabled result in the CPU being forced into an error mode.
 
 A nested interrupt is processed similarly with the
@@ -142,41 +125,19 @@ exception that the current stack need not be switched to the
 interrupt stack.
 
 @ifinfo
-@node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
-@end ifinfo
-@section Traps and Register Windows
-
-One of the register windows must be reserved at all
-times for trap processing.  This is critical to the proper
-operation of the trap mechanism in the SPARC architecture.  It
-is the responsibility of the trap handler to insure that there
-is a register window available for a subsequent trap before
-re-enabling traps.  It is likely that any high level language
-routines invoked by the trap handler (such as a user-provided
-RTEMS interrupt handler) will allocate a new register window.
-The save operation could result in a window overflow trap.  This
-trap cannot be correctly processed unless (1) traps are enabled
-and (2) a register window is reserved for traps.  Thus, the
-RTEMS interrupt handler insures that a register window is
-available for subsequent traps before enabling traps and
-invoking the user's interrupt handler.
-
-@ifinfo
-@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing
+@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
 @end ifinfo
 @section Interrupt Levels
 
-Sixteen levels (0-15) of interrupt priorities are
-supported by the SPARC architecture with level fifteen (15)
+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.
 
-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
+TBD
+All other RTEMS interrupt levels are undefined and their behavior is
 unpredictable.
 
 @ifinfo
@@ -186,21 +147,21 @@ unpredictable.
 
 During the execution of directive calls, critical
 sections of code may be executed.  When these sections are
-encountered, RTEMS disables interrupts to level seven (15)
+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
 optimized to insure that interrupts are disabled for less than
-RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 
-Mhz PowerPC 603e with zero wait states.
-These numbers will vary based the number of wait states and
-processor speed present on the target board.
+RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a 
+RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz PowerPC 603e with zero
+wait states.  These numbers will vary based the number of wait 
+states and processor speed present on the target board.
 [NOTE:  The maximum period with interrupts disabled is hand calculated.  This
 calculation was last performed for Release 
 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 traps are
+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
@@ -215,14 +176,14 @@ execute as non-maskable interrupts.
 @end ifinfo
 @section Interrupt Stack
 
-The SPARC architecture does not provide for a
-dedicated interrupt stack.  Thus by default, trap handlers would
+The PowerPC architecture does not provide for a
+dedicated interrupt stack.  Thus by default, exception 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
+problem on the PowerPC by providing a dedicated interrupt stack
 managed by software.
 
 During system initialization, RTEMS allocates the
@@ -232,3 +193,5 @@ 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.
 
+
+
diff --git a/doc/supplements/powerpc/intr_NOTIMES.t b/doc/supplements/powerpc/intr_NOTIMES.t
index 941cd1c2b7..1530dad5e4 100644
--- a/doc/supplements/powerpc/intr_NOTIMES.t
+++ b/doc/supplements/powerpc/intr_NOTIMES.t
@@ -13,9 +13,8 @@
 @ifinfo
 @menu
 * Interrupt Processing Introduction::
-* Interrupt Processing Synchronous Versus Asynchronous Traps::
+* Interrupt Processing Synchronous Versus Asynchronous Exceptions::
 * Interrupt Processing Vectoring of Interrupt Handler::
-* Interrupt Processing Traps and Register Windows::
 * Interrupt Processing Interrupt Levels::
 * Interrupt Processing Disabling of Interrupts by RTEMS::
 * Interrupt Processing Interrupt Stack::
@@ -23,7 +22,7 @@
 @end ifinfo
 
 @ifinfo
-@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing
+@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing, Interrupt Processing
 @end ifinfo
 @section Introduction
 
@@ -38,80 +37,64 @@ special control mechanisms to return to the normal processing
 stream.  Although RTEMS hides many of the processor dependent
 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 SPARC's
+unique architecture. Discussed in this chapter are the PPC's
 interrupt response and control mechanisms as they pertain to
 RTEMS.
 
 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
+interrupt and vector.  In the PPC architecture, these terms
+correspond to exception and exception handler, respectively.  The terms will
 be used interchangeably in this manual.
 
 @ifinfo
-@node Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
+@node Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
 @end ifinfo
-@section Synchronous Versus Asynchronous Traps
-
-The SPARC architecture includes two classes of traps:
-synchronous and asynchronous.  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.
+@section Synchronous Versus Asynchronous Exceptions
+
+In the PPC architecture exceptions can be either precise or 
+imprecise and either synchronous or asynchronous.  Asynchronous 
+exceptions occur when an external event interrupts the processor.
+Synchronous exceptions are caused by the actions of an 
+instruction. During an exception SRR0 is used to calculate where 
+instruction processing should resume.  All instructions prior to
+the resume instruction will have completed execution.  SRR1 is used to 
+store the machine status.
+
+There are two asynchronous nonmaskable, highest-priority exceptions
+system reset and machine check.  There are two asynchrononous maskable
+low-priority exceptions external interrupt and decrementer.  Nonmaskable
+execptions are never delayed, therefore if two nonmaskable, asynchronous 
+exceptions occur in immediate succession, the state information saved by
+the first exception may be overwritten when the subsequent exception occurs. 
+
+The PowerPC arcitecure defines one imprecise exception, the imprecise 
+floating point enabled exception.  All other synchronous exceptions are
+precise.  The synchronization occuring during asynchronous precise 
+exceptions conforms to the requirements for context synchronization.
 
 @ifinfo
-@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing
+@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Levels, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing
 @end ifinfo
 @section Vectoring of Interrupt Handler
 
-Upon receipt of an interrupt the SPARC automatically
+Upon determining that an exception can be taken the PPC  automatically
 performs the following actions:
 
 @itemize @bullet
-@item disables traps (sets the ET bit of the psr to 0),
+@item an instruction address is loaded into SRR0
 
-@item the S bit of the psr is copied into the Previous
-Supervisor Mode (PS) bit of the psr,
+@item bits 33-36 and 42-47 of SRR1 are loaded with information 
+specific to the exception.
 
-@item the cwp is decremented by one (modulo the number of
-register windows) to activate a trap window,
+@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding
+bits from the MSR.
 
-@item the PC and nPC are loaded into local register 1 and 2
-(l0 and l1),
+@item the MSR is set based upon the exception type.
 
-@item the trap type (tt) field of the Trap Base Register (TBR)
-is set to the appropriate value, and
+@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type. 
 
-@item if the trap is not a reset, then the PC is written with
-the contents of the TBR and the nPC is written with TBR + 4.  If
-the trap is a reset, then the PC is set to zero and the nPC is
-set to 4.
 @end itemize
 
-Trap processing on the SPARC has two features which
-are noticeably different than interrupt processing on other
-architectures.  First, the value of psr register in effect
-immediately before the trap occurred is not explicitly saved.
-Instead only reversible alterations are made to it.  Second, the
-Processor Interrupt Level (pil) is not set to correspond to that
-of the interrupt being processed.  When a trap occurs, ALL
-subsequent traps are disabled.  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
@@ -122,19 +105,19 @@ performs the following actions:
 @item saves the state of the interrupted task on it's stack,
 
 @item insures that a register window is available for
-subsequent traps,
+subsequent exceptions,
 
 @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 enables exceptions,
 
 @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
+Asynchronous interrupts are ignored while exceptions are
+disabled.  Synchronous interrupts which occur while  are
 disabled result in the CPU being forced into an error mode.
 
 A nested interrupt is processed similarly with the
@@ -142,41 +125,19 @@ exception that the current stack need not be switched to the
 interrupt stack.
 
 @ifinfo
-@node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
-@end ifinfo
-@section Traps and Register Windows
-
-One of the register windows must be reserved at all
-times for trap processing.  This is critical to the proper
-operation of the trap mechanism in the SPARC architecture.  It
-is the responsibility of the trap handler to insure that there
-is a register window available for a subsequent trap before
-re-enabling traps.  It is likely that any high level language
-routines invoked by the trap handler (such as a user-provided
-RTEMS interrupt handler) will allocate a new register window.
-The save operation could result in a window overflow trap.  This
-trap cannot be correctly processed unless (1) traps are enabled
-and (2) a register window is reserved for traps.  Thus, the
-RTEMS interrupt handler insures that a register window is
-available for subsequent traps before enabling traps and
-invoking the user's interrupt handler.
-
-@ifinfo
-@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing
+@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
 @end ifinfo
 @section Interrupt Levels
 
-Sixteen levels (0-15) of interrupt priorities are
-supported by the SPARC architecture with level fifteen (15)
+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.
 
-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
+TBD
+All other RTEMS interrupt levels are undefined and their behavior is
 unpredictable.
 
 @ifinfo
@@ -186,21 +147,21 @@ unpredictable.
 
 During the execution of directive calls, critical
 sections of code may be executed.  When these sections are
-encountered, RTEMS disables interrupts to level seven (15)
+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
 optimized to insure that interrupts are disabled for less than
-RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 
-Mhz PowerPC 603e with zero wait states.
-These numbers will vary based the number of wait states and
-processor speed present on the target board.
+RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a 
+RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz PowerPC 603e with zero
+wait states.  These numbers will vary based the number of wait 
+states and processor speed present on the target board.
 [NOTE:  The maximum period with interrupts disabled is hand calculated.  This
 calculation was last performed for Release 
 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 traps are
+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
@@ -215,14 +176,14 @@ execute as non-maskable interrupts.
 @end ifinfo
 @section Interrupt Stack
 
-The SPARC architecture does not provide for a
-dedicated interrupt stack.  Thus by default, trap handlers would
+The PowerPC architecture does not provide for a
+dedicated interrupt stack.  Thus by default, exception 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
+problem on the PowerPC by providing a dedicated interrupt stack
 managed by software.
 
 During system initialization, RTEMS allocates the
@@ -232,3 +193,5 @@ 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.
 
+
+