2008-06-02 Joel Sherrill <joel.sherrill@oarcorp.com>

	* cpu_supplement/.cvsignore, cpu_supplement/Makefile.am,
	cpu_supplement/arm.t, cpu_supplement/bfin.t,
	cpu_supplement/cpu_supplement.texi, cpu_supplement/i386.t,
	cpu_supplement/m68k.t, cpu_supplement/mips.t,
	cpu_supplement/powerpc.t, cpu_supplement/preface.texi,
	cpu_supplement/sh.t: Remove duplicated text from each CPU specific
	chapter. This text was necessary when each CPU was a separate manual
	but now only needs to be one place and that is in an introductory
	chapter.
	* cpu_supplement/general.t: New file.

13 files changed, 706 insertions, 2089 deletions

diff --git a/doc/ChangeLog b/doc/ChangeLog
index 931c932b11..d312ed13e0 100644
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -1,5 +1,18 @@
 2008-06-02	Joel Sherrill <joel.sherrill@oarcorp.com>
 
+	* cpu_supplement/.cvsignore, cpu_supplement/Makefile.am,
+	cpu_supplement/arm.t, cpu_supplement/bfin.t,
+	cpu_supplement/cpu_supplement.texi, cpu_supplement/i386.t,
+	cpu_supplement/m68k.t, cpu_supplement/mips.t,
+	cpu_supplement/powerpc.t, cpu_supplement/preface.texi,
+	cpu_supplement/sh.t: Remove duplicated text from each CPU specific
+	chapter. This text was necessary when each CPU was a separate manual
+	but now only needs to be one place and that is in an introductory
+	chapter.
+	* cpu_supplement/general.t: New file.
+
+2008-06-02	Joel Sherrill <joel.sherrill@oarcorp.com>
+
 	* user/bsp.t, user/init.t: Rework initialization and BSP chapters to
 	account for changes to initialization framework.
 
diff --git a/doc/cpu_supplement/.cvsignore b/doc/cpu_supplement/.cvsignore
index fea78c69cf..9e74f55449 100644
--- a/doc/cpu_supplement/.cvsignore
+++ b/doc/cpu_supplement/.cvsignore
@@ -21,6 +21,7 @@ cpu_supplement.ps
 cpu_supplement.toc
 cpu_supplement.tp
 cpu_supplement.vr
+general.texi
 i386.texi
 index.html
 m68k.texi
diff --git a/doc/cpu_supplement/Makefile.am b/doc/cpu_supplement/Makefile.am
index dd6c4e5e01..d45b4eab14 100644
--- a/doc/cpu_supplement/Makefile.am
+++ b/doc/cpu_supplement/Makefile.am
@@ -21,7 +21,7 @@ TEXI2WWW_ARGS=\
 -header rtems_header.html \
 -footer rtems_footer.html \
 -icons ../images
-GENERATED_FILES = arm.texi bfin.texi i386.texi m68k.texi mips.texi \
+GENERATED_FILES = general.texi arm.texi bfin.texi i386.texi m68k.texi mips.texi \
     powerpc.texi sh.texi sparc.texi tic4x.texi
 
 COMMON_FILES += $(top_srcdir)/common/cpright.texi
@@ -35,11 +35,16 @@ cpu_supplement_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
 #  Chapters which get automatic processing
 #
 
-arm.texi: arm.t
+general.texi: general.t
 	$(BMENU2) -p "Preface" \
 	    -u "Top" \
 	    -n "" < $< > $@
 
+arm.texi: arm.t
+	$(BMENU2) -p "" \
+	    -u "Top" \
+	    -n "" < $< > $@
+
 bfin.texi: bfin.t
 	$(BMENU2) -p "" \
 	    -u "Top" \
diff --git a/doc/cpu_supplement/arm.t b/doc/cpu_supplement/arm.t
index 95fd5029e6..697d306e02 100644
--- a/doc/cpu_supplement/arm.t
+++ b/doc/cpu_supplement/arm.t
@@ -10,34 +10,17 @@
 @end ifinfo
 @chapter ARM Specific Information
 
-The Real Time Executive for Multiprocessor Systems (RTEMS)
-is designed to be portable across multiple processor
-architectures.  However, the nature of real-time systems makes
-it essential that the application designer understand certain
-processor dependent implementation details.  These processor
-dependencies include calling convention, board support package
-issues, interrupt processing, exact RTEMS memory requirements,
-performance data, header files, and the assembly language
-interface to the executive.
-
-This document discusses the ARM architecture dependencies
+This chapter discusses the ARM architecture dependencies
 in this port of RTEMS.  The ARM family has a wide variety
 of implementations by a wide range of vendors.  Consequently,
-there are 100's of CPU models within it.
-
-It is highly recommended that the ARM
-RTEMS application developer obtain and become familiar with the
-documentation for the processor being used as well as the
-documentation for the ARM architecture as a whole.
+there are many, many CPU models within it.
 
 @subheading Architecture Documents
 
-For information on the ARM architecture,
-refer to the following documents available from Arm, Limited
-(@file{http//www.arm.com/}).  There does not appear to
-be an electronic version of a manual on the architecture
-in general on that site.  The following book is a good 
-resource:
+For information on the ARM architecture, refer to the following documents
+available from Arm, Limited (@file{http//www.arm.com/}).  There does
+not appear to be an electronic version of a manual on the architecture
+in general on that site.  The following book is a good resource:
 
 @itemize @bullet
 @item @cite{David Seal. "ARM Architecture Reference Manual."
@@ -47,54 +30,16 @@ Addison-Wesley. @b{ISBN 0-201-73719-1}. 2001.}
 
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section CPU Model Dependent Features
 
-
-Microprocessors are generally classified into
-families with a variety of CPU models or implementations within
-that family.  Within a processor family, there is a high level
-of binary compatibility.  This family may be based on either an
-architectural specification or on maintaining compatibility with
-a popular processor.  Recent microprocessor families such as the
-ARM, SPARC, and PowerPC are based on an architectural specification
-which is independent or any particular CPU model or
-implementation.  Older families such as the M68xxx and the iX86
-evolved as the manufacturer strived to produce higher
-performance processor models which maintained binary
-compatibility with older models.
-
-RTEMS takes advantage of the similarity of the
-various models within a CPU family.  Although the models do vary
-in significant ways, the high level of compatibility makes it
-possible to share the bulk of the CPU dependent executive code
-across the entire family.  Each processor family supported by
-RTEMS has a list of features which vary between CPU models
-within a family.  For example, the most common model dependent
-feature regardless of CPU family is the presence or absence of a
-floating point unit or coprocessor.  When defining the list of
-features present on a particular CPU model, one simply notes
-that floating point hardware is or is not present and defines a
-single constant appropriately.  Conditional compilation is
-utilized to include the appropriate source code for this CPU
-model's feature set.  It is important to note that this means
-that RTEMS is thus compiled using the appropriate feature set
-and compilation flags optimal for this CPU model used.  The
-alternative would be to generate a binary which would execute on
-all family members using only the features which were always
-present.
-
-This chapter presents the set of features which vary
+This section presents the set of features which vary
 across ARM implementations and are of importance to RTEMS.
 The set of CPU model feature macros are defined in the file
-cpukit/score/cpu/arm/rtems/score/arm.h based upon the particular CPU
-model defined on the compilation command line.
+@code{cpukit/score/cpu/arm/rtems/score/arm.h} based upon the particular CPU
+model flags specified on the compilation command line.
 
 @subsection CPU Model Name
 
@@ -128,53 +73,24 @@ point support is incorporated on-chip or is an external
 coprocessor.
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section Calling Conventions
 
-
-Each high-level language compiler generates
-subroutine entry and exit code based upon a set of rules known
-as the compiler's calling convention.   These rules address the
-following issues:
-
-@itemize @bullet
-@item register preservation and usage
-@item parameter passing
-@item call and return mechanism
-@end itemize
-
-A compiler's calling convention is of importance when
-interfacing to subroutines written in another language either
-assembly or high-level.  Even when the high-level language and
-target processor are the same, different compilers may use
-different calling conventions.  As a result, calling conventions
-are both processor and compiler dependent.
-
-@subsection Processor Background
-
-The ARM architecture supports a simple yet
-effective call and return mechanism.  A subroutine is invoked
-via the branch and link (@code{bl}) instruction.  This instruction
-saves the return address in the @code{lr} register.  Returning
-from a subroutine only requires that the return address be
-moved into the program counter (@code{pc}), possibly with
-an offset.  It is is important to
-note that the @code{bl} instruction does not
-automatically save or restore any registers.  It is the
-responsibility of the high-level language compiler to define the
-register preservation and usage convention.
+The ARM architecture supports a simple yet effective call and
+return mechanism.  A subroutine is invoked via the branch and link
+(@code{bl}) instruction.  This instruction saves the return address
+in the @code{lr} register.  Returning from a subroutine only requires
+that the return address be moved into the program counter (@code{pc}),
+possibly with an offset.  It is is important to note that the @code{bl}
+instruction does not automatically save or restore any registers.
+It is the responsibility of the high-level language compiler to define
+the register preservation and usage convention.
 
 @subsection Calling Mechanism
 
-All RTEMS directives are invoked using the @code{bl}
-instruction and return to the user application via the
-mechanism described above.
+All RTEMS directives are invoked using the @code{bl} instruction and
+return to the user application via the mechanism described above.
 
 @subsection Register Usage
 
@@ -193,71 +109,32 @@ the first four arguments are placed in registers @code{r0} through
 @code{r3}.  If there are more arguments, than that, then they
 are place on the stack.
 
-@subsection User-Provided Routines
-
-All user-provided routines invoked by RTEMS, such as
-user extensions, device drivers, and MPCI routines, must also
-adhere to these calling conventions.
-
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Memory Model
 
-
-A processor may support any combination of memory
-models ranging from pure physical addressing to complex demand
-paged virtual memory systems.  RTEMS supports a flat memory
-model which ranges contiguously over the processor's allowable
-address space.  RTEMS does not support segmentation or virtual
-memory of any kind.  The appropriate memory model for RTEMS
-provided by the targeted processor and related characteristics
-of that model are described in this chapter.
-
 @subsection Flat Memory Model
 
-Members of the ARM family newer than Version 3 support a flat
-32-bit address space with addresses ranging from 0x00000000 to
-0xFFFFFFFF (4 gigabytes).  Each address is represented by a
-32-bit value and is byte addressable.  
-The address may be used to reference a
-single byte, word (2-bytes), or long word (4 bytes).  Memory
-accesses within this address space are performed in the endian
-mode that the processor is configured for.   In general, ARM
-processors are used in little endian mode.
-
-Some of the ARM family members such as the 
-920 and 720 include an MMU and thus support virtual memory and
-segmentation.  RTEMS does not support virtual memory or
-segmentation on any of the ARM family members.
+Members of the ARM family newer than Version 3 support a flat 32-bit
+address space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
+gigabytes).  Each address is represented by a 32-bit value and is byte
+addressable.  The address may be used to reference a single byte, word
+(2-bytes), or long word (4 bytes).  Memory accesses within this address
+space are performed in the endian mode that the processor is configured
+for.   In general, ARM processors are used in little endian mode.
+
+Some of the ARM family members such as the 920 and 720 include an MMU
+and thus support virtual memory and segmentation.  RTEMS does not support
+virtual memory or segmentation on any of the ARM family members.
 
 @c
-@c  Interrupt Stack Frame Picture
-@c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section Interrupt Processing
 
-
-Different types of processors respond to the
-occurrence of an interrupt in its own unique fashion. In
-addition, each processor type provides a control mechanism to
-allow for the proper handling of an interrupt.  The processor
-dependent response to the interrupt modifies the current
-execution state and results in a change in the execution stream.
-Most processors require that an interrupt handler utilize some
-special control mechanisms to return to the normal processing
-stream.  Although RTEMS hides many of the processor dependent
+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 ARM's
@@ -265,6 +142,7 @@ interrupt response and control mechanisms as they pertain to
 RTEMS.
 
 The ARM has 7 exception types:
+
 @itemize @bullet
 
 @item Reset
@@ -282,7 +160,6 @@ vectoring.
 
 @subsection Vectoring of an Interrupt Handler
 
-
 Unlike many other architectures, the ARM has seperate stacks for each
 interrupt. When the CPU receives an interrupt, it:
 
@@ -328,62 +205,17 @@ Setting bit 7 (0 is least significant bit) disables the IRQ.
  
 @end table
  
-
-@subsection Disabling of Interrupts by RTEMS
-
-During the execution of directive calls, critical
-sections of code may be executed.  When these sections are
-encountered, RTEMS disables interrupts to level seven (7) 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 processor 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.]
-
-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.
-
 @subsection Interrupt Stack
 
 RTEMS expects the interrupt stacks to be set up in bsp_start(). The memory
 for the stacks is reserved in the linker script. 
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section Default Fatal Error Processing
 
-
-Upon detection of a fatal error by either the
-application or RTEMS the fatal error manager is invoked.  The
-fatal error manager will invoke the user-supplied fatal error
-handlers.  If no user-supplied handlers are configured,  the
-RTEMS provided default fatal error handler is invoked.  If the
-user-supplied fatal error handlers return to the executive the
-default fatal error handler is then invoked.  This chapter
-describes the precise operations of the default fatal error
-handler.
-
-@subsection Default Fatal Error Handler Operations
-
-The default fatal error handler which is invoked by
-the @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 performs the
+The default fatal error handler for this architecture performs the
 following actions:
 
 @itemize @bullet
@@ -394,94 +226,21 @@ simulate a halt processor instruction.
 @end itemize
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section Board Support Packages
 
-
-An RTEMS Board Support Package (BSP) must be designed
-to support a particular processor and target board combination.
-This chapter presents a discussion of XXX specific BSP
-issues.   For more information on developing a BSP, refer to the
-chapter titled Board Support Packages in the RTEMS
-Applications User's Guide.
-
 @subsection System Reset
 
-An RTEMS based application is initiated or
-re-initiated when the XXX processor is reset.  When the
-XXX is reset, the processor performs the following actions:
+An RTEMS based application is initiated or re-initiated when the processor
+is reset.  When the processor is reset, the processor performs the
+following actions:
 
 @itemize @bullet
-@item The tracing bits of the status register are cleared to
-disable tracing.
-
-@item The supervisor interrupt state is entered by setting the
-supervisor (S) bit and clearing the master/interrupt (M) bit of
-the status register.
-
-@item The interrupt mask of the status register is set to
-level 7 to effectively disable all maskable interrupts.
-
-@item The vector base register (VBR) is set to zero.
-
-@item The cache control register (CACR) is set to zero to
-disable and freeze the processor cache.
-
-@item The interrupt stack pointer (ISP) is set to the value
-stored at vector 0 (bytes 0-3) of the exception vector table
-(EVT).
-
-@item The program counter (PC) is set to the value stored at
-vector 1 (bytes 4-7) of the EVT.
+@item TBD
 
-@item The processor begins execution at the address stored in
-the PC.
 @end itemize
 
 @subsection Processor Initialization
 
-The address of the application's initialization code
-should be stored in the first vector of the EVT which will allow
-the immediate vectoring to the application code.  If the
-application requires that the VBR be some value besides zero,
-then it should be set to the required value at this point.  All
-tasks share the same XXX's VBR value.  Because interrupts
-are enabled automatically by RTEMS as part of the initialize
-executive directive, the VBR MUST be set before this directive
-is invoked to insure correct interrupt vectoring.  If processor
-caching 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 Applications User's
-Manual for the reset code which is executed before the call to
-initialize executive, the XXX version has the following
-specific requirements:
-
-@itemize @bullet
-@item Must leave the S bit of the status register set so that
-the XXX remains in the supervisor state.
-
-@item Must set the M bit of the status register to remove the
-XXX from the interrupt state.
-
-@item Must set the master stack pointer (MSP) such that a
-minimum stack size of MINIMUM_STACK_SIZE bytes is provided for
-the initialize executive directive.
-
-@item Must initialize the XXX's vector table.
-@end itemize
-
-Note that the BSP is not responsible for allocating
-or installing the interrupt stack.  RTEMS does this
-automatically as part of initialization.  If the BSP does not
-install an interrupt stack and -- for whatever reason -- an
-interrupt occurs before initialize_executive is invoked, then
-the results are unpredictable.
-
+TBD
diff --git a/doc/cpu_supplement/bfin.t b/doc/cpu_supplement/bfin.t
index d8b9028e88..c4dea702ee 100644
--- a/doc/cpu_supplement/bfin.t
+++ b/doc/cpu_supplement/bfin.t
@@ -10,174 +10,121 @@
 @end ifinfo
 @chapter Blackfin Specific Information
 
-This chapter discusses the Blackfin architecture dependencies
-in this port of RTEMS.  
+This chapter discusses the Blackfin architecture dependencies in this
+port of RTEMS.
 
 @subheading Architecture Documents
 
-For information on the Blackfin architecture,
-refer to the following documents available from
-Analog Devices. 
+For information on the Blackfin architecture, refer to the following
+documents available from Analog Devices.
 
 TBD
 
-@c @itemize @bullet
-@c @item @cite{"ADSP-BF533 Blackfin Processor Hardware Reference."
-@c @file{http://www.analog.com/UploadedFiles/Associated_Docs/892485982bf533_hwr.pdf} 
-@c 
-@c @end itemize
-
-
-@section CPU Model Dependent Features
-
+@itemize @bullet
+@item @cite{"ADSP-BF533 Blackfin Processor Hardware Reference."}
+@file{http://www.analog.com/UploadedFiles/Associated_Docs/892485982bf533_hwr.pdf} 
 
-CPUs of the Blackfin 53X only differ in the perifericals
-and thus in the device drivers. This port does not yet
-support the 56X dual core variants.
+@end itemize
 
-@subsection CPU Model Name
 
-The macro @code{CPU_MODEL_NAME} is a string which designates
-the architectural level of this CPU model.  The following is
-a list of the settings for this string based upon @code{gcc}
-CPU model predefines:
+@section CPU Model Dependent Features
 
-@example
-"BF533"
-@end example
+CPUs of the Blackfin 53X only differ in the peripherals and thus in the
+device drivers. This port does not yet support the 56X dual core variants.
 
 @subsection Count Leading Zeroes Instruction
 
-The Blackfin CPU has the BITTST instruction
-which could be used to speed up the find first bit
-operation.  The use of this instruction should significantly speed up
-the scheduling associated with a thread blocking.
-
-@subsection Floating Point Unit
-
-The macro BF_HAS_FPU is set to 0 to indicate that
-this CPU model has no hardware floating point unit.
-Blackfin CPUs don't have floating point so 
+The Blackfin CPU has the BITTST instruction which could be used to speed
+up the find first bit operation.  The use of this instruction should
+significantly speed up the scheduling associated with a thread blocking.
 
 @section Calling Conventions
 
-Each high-level language compiler generates
-subroutine entry and exit code based upon a set of rules known
-as the compiler's calling convention.   These rules address the
-following issues:
-
-@itemize @bullet
-@item register preservation and usage
-@item parameter passing
-@item call and return mechanism
-@end itemize
-
-A compiler's calling convention is of importance when
-interfacing to subroutines written in another language either
-assembly or high-level.  Even when the high-level language and
-target processor are the same, different compilers may use
-different calling conventions.  As a result, calling conventions
-are both processor and compiler dependent.
-
-This section is heavily based on content taken from the
-Blackfin uCLinux documentation wiki which is edited
-by Analog Devices and Arcturus Networks.
-@file{http://docs.blackfin.uclinux.org/}
+This section is heavily based on content taken from the Blackfin uCLinux
+documentation wiki which is edited by Analog Devices and Arcturus
+Networks.  @file{http://docs.blackfin.uclinux.org/}
 
 @subsection Processor Background
 
-
 The Blackfin architecture supports a simple call and return mechanism.
 A subroutine is invoked via the call (@code{call}) instruction.
 This instruction saves the return address in the @code{RETS} register
 and transfers the execution to the given address.
 
-It is the called funcions responsability to use the link instruction to
-reserve space on the stack for the local variables.
-Returning from a subroutine is done by using the RTS (@code{RTS})
-instruction which loads the PC with the adress stored in RETS.
+It is the called funcions responsability to use the link instruction
+to reserve space on the stack for the local variables.  Returning from
+a subroutine is done by using the RTS (@code{RTS}) instruction which
+loads the PC with the adress stored in RETS.
 
 It is is important to note that the @code{call} instruction does not
-automatically save or restore any registers.  It is the
-responsibility of the high-level language compiler to define the
-register preservation and usage convention.
+automatically save or restore any registers.  It is the responsibility
+of the high-level language compiler to define the register preservation
+and usage convention.
 
 @subsection Register Usage
 
-A called function may clobber all registers, except RETS, R4-R7, P3-P5, FP and SP. 
-It may also modify the first 12 bytes in the caller’s stack frame which is used as
-an argument area for the first three arguments (which are passed in R0...R3 but may
-be placed on the stack by the called function).
+A called function may clobber all registers, except RETS, R4-R7, P3-P5,
+FP and SP.  It may also modify the first 12 bytes in the caller’s stack
+frame which is used as an argument area for the first three arguments
+(which are passed in R0...R3 but may be placed on the stack by the
+called function).
 
 @subsection Parameter Passing
 
 RTEMS assumes that the Blackfin GCC calling convention is followed.
 The first three parameters are stored in registers R0, R1, and R2.
-All other parameters are put pushed on the stack.
-The result is returned through register R0.
-
-@subsection User-Provided Routines
-
-All user-provided routines invoked by RTEMS, such as
-user extensions, device drivers, and MPCI routines, must also
-adhere to these calling conventions.
+All other parameters are put pushed on the stack.  The result is returned
+through register R0.
 
 @section Memory Model
 
-The Blackfin family architecutre support a single unified 4
-G byte address space using 32-bit addresses. It maps all
-resources like internal and external memory and IO registers
-into separate sections of this common address space.
+The Blackfin family architecutre support a single unified 4 GB byte
+address space using 32-bit addresses. It maps all resources like internal
+and external memory and IO registers into separate sections of this
+common address space.
 
-The Blackfin architcture supporst some form of memory
+The Blackfin architcture supports some form of memory
 protection via its Memory Management Unit. Since the
 Blackfin port runs in supervisior mode this memory
 protection mechanisms are not used.
 
 @section Interrupt Processing
 
-Discussed in this chapter are the Blackfin's
-interrupt response and control mechanisms as they pertain to
-RTEMS. The Blackfin architecture support 16 kinds of
-interrupts broken down into Core and general-purpose
+Discussed in this chapter are the Blackfin's interrupt response and
+control mechanisms as they pertain to RTEMS. The Blackfin architecture
+support 16 kinds of interrupts broken down into Core and general-purpose
 interrupts.
 
 @subsection Vectoring of an Interrupt Handler
 
-RTEMS maps levels 0 -15 directly to Blackfins event
-vectors EVT0 - EVT15. Since EVT0 - EVT6 are core
-events and it is suggested to use EVT15 and EVT15 for
-Software interrupts, 7 Interrupts (EVT7-EVT13) are left
-for periferical use.
+RTEMS maps levels 0 -15 directly to Blackfins event vectors EVT0 -
+EVT15. Since EVT0 - EVT6 are core events and it is suggested to use
+EVT15 and EVT15 for Software interrupts, 7 Interrupts (EVT7-EVT13)
+are left for periferical use.
 
-When installing an RTEMS interrupt handler RTEMS installs
-a generic Interrupt Handler which saves some context and
-enables nested interrupt servicing and then vectors
-to the users interrupt handler.
+When installing an RTEMS interrupt handler RTEMS installs a generic
+Interrupt Handler which saves some context and enables nested interrupt
+servicing and then vectors to the users interrupt handler.
 
 @subsection Disabling of Interrupts by RTEMS
 
-During the execution of directive calls, critical
-sections of code may be executed.  When these sections are
-encountered, RTEMS disables interrupts to level four (4) before
-the execution of this section and restores them to the previous
-level upon completion of the section. RTEMS uses the instructions
-CLI and STI to enable and disable Interrupts. Emulation,
+During interrupt disable critical sections, RTEMS disables interrupts to
+level four (4) before the execution of this section and restores them
+to the previous level upon completion of the section. RTEMS uses the
+instructions CLI and STI to enable and disable Interrupts. Emulation,
 Reset, NMI and Exception Interrupts are never disabled.
 
 @subsection Interrupt Stack
 
-The Blackfin Architecuter works with two different kind of stacks,
+The Blackfin Architecture works with two different kind of stacks,
 User and Supervisor Stack. Since RTEMS and its Application run
 in supervisor mode, all interrupts will use the interrupted
 tasks stack for execution.
 
 @section Default Fatal Error Processing
 
-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 performs the
-following actions:
+The default fatal error handler for the Blackfin performs the following
+actions:
 
 @itemize @bullet
 @item disables processor interrupts,
@@ -192,9 +139,3 @@ simulate a halt processor instruction.
 @subsection System Reset
 
 TBD
-
-@subsection Processor Initialization
-
-TBD
-
-
diff --git a/doc/cpu_supplement/cpu_supplement.texi b/doc/cpu_supplement/cpu_supplement.texi
index 70c661253a..a609f6f0fc 100644
--- a/doc/cpu_supplement/cpu_supplement.texi
+++ b/doc/cpu_supplement/cpu_supplement.texi
@@ -59,6 +59,7 @@
 @contents
 
 @include preface.texi
+@include general.texi
 @include arm.texi
 @include bfin.texi
 @include i386.texi
@@ -72,14 +73,15 @@
 @node Top, Preface, (dir), (dir)
 @top cpu_supplement
 
-This is the online version of the RTEMS CPU Architecture Supplement
+This is the online version of the RTEMS CPU Architecture Supplement.
 
 @menu
 * Preface::
+* Port Specific Information::
 * ARM Specific Information::
 * Blackfin Specific Information::
 * Intel/AMD x86 Specific Information::
-* Motorola M68xxx and Coldfire Specific Information::
+* M68xxx and Coldfire Specific Information::
 * MIPS Specific Information::
 * PowerPC Specific Information::
 * SuperH Specific Information::
diff --git a/doc/cpu_supplement/general.t b/doc/cpu_supplement/general.t
new file mode 100644
index 0000000000..c4f277d27f
--- /dev/null
+++ b/doc/cpu_supplement/general.t
@@ -0,0 +1,342 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@ifinfo
+@end ifinfo
+@chapter Port Specific Information
+
+This chaper provides a general description of the type of
+architecture specific information which is in each of
+the architecture specific chapters that follow.  The outline
+of this chapter is identical to that of the architecture
+specific chapters.
+
+In each of the architecture specific chapters, this
+introductory section will provide an overview of the
+architecture
+
+@subheading Architecture Documents
+
+In each of the architecture specific chapters, this
+section will provide pointers on where to obtain
+documentation.
+
+@c
+@c
+@c
+@section CPU Model Dependent Features
+
+Microprocessors are generally classified into families with a variety of
+CPU models or implementations within that family.  Within a processor
+family, there is a high level of binary compatibility.  This family
+may be based on either an architectural specification or on maintaining
+compatibility with a popular processor.  Recent microprocessor families
+such as the SPARC or PowerPC are based on an architectural specification
+which is independent or any particular CPU model or implementation.
+Older families such as the M68xxx and the iX86 evolved as the manufacturer
+strived to produce higher performance processor models which maintained
+binary compatibility with older models.
+
+RTEMS takes advantage of the similarity of the various models within a
+CPU family.  Although the models do vary in significant ways, the high
+level of compatibility makes it possible to share the bulk of the CPU
+dependent executive code across the entire family.  Each processor family
+supported by RTEMS has a list of features which vary between CPU models
+within a family.  For example, the most common model dependent feature
+regardless of CPU family is the presence or absence of a floating point
+unit or coprocessor.  When defining the list of features present on a
+particular CPU model, one simply notes that floating point hardware
+is or is not present and defines a single constant appropriately.
+Conditional compilation is utilized to include the appropriate source
+code for this CPU model's feature set.  It is important to note that
+this means that RTEMS is thus compiled using the appropriate feature set
+and compilation flags optimal for this CPU model used.  The alternative
+would be to generate a binary which would execute on all family members
+using only the features which were always present.
+
+The set of CPU model feature macros are defined in the file
+@code{cpukit/score/cpu/CPU/rtems/score/cpu.h} based upon the GNU tools
+multilib variant that is appropriate for the particular CPU model defined
+on the compilation command line.
+
+In each of the architecture specific chapters, this section presents
+the set of features which vary across various implementations of the
+architecture that may be of importance to RTEMS application developers.
+
+The subsections will vary amongst the target architecture chapters as
+the specific features may vary.  However, each port will include a few
+common features such as the CPU Model Name and presence of a hardware
+Floating Point Unit.  The common features are described here.
+
+@subsection CPU Model Name
+
+The macro @code{CPU_MODEL_NAME} is a string which designates
+the name of this CPU model.  For example, for the MC68020
+processor model from the m68k architecture, this macro
+is set to the string "mc68020".
+
+@subsection Floating Point Unit
+
+In most architectures, the presence of a floating point unit is an option.
+It does not matter whether the hardware floating point support is
+incorporated on-chip or is an external coprocessor as long as it
+appears an FPU per the ISA.  However, if a hardware FPU is not present,
+it is possible that the floating point emulation library for this
+CPU is not reentrant and thus context switched by RTEMS.
+
+RTEMS provides two feature macros to indicate the FPU configuration:
+
+@itemize @bullet
+
+@item CPU_HARDWARE_FP
+is set to TRUE to indicate that a hardware FPU is present.
+
+@item CPU_SOFTWARE_FP
+is set to TRUE to indicate that a hardware FPU is not present and that
+the FP software emulation will be context switched.
+
+@end itemize
+
+@c
+@c
+@c
+@section Calling Conventions
+
+Each high-level language compiler generates subroutine entry and exit
+code based upon a set of rules known as the compiler's calling convention.
+These rules address the following issues:
+
+@itemize @bullet
+@item register preservation and usage
+@item parameter passing
+@item call and return mechanism
+@end itemize
+
+A compiler's calling convention is of importance when
+interfacing to subroutines written in another language either
+assembly or high-level.  Even when the high-level language and
+target processor are the same, different compilers may use
+different calling conventions.  As a result, calling conventions
+are both processor and compiler dependent.
+
+@subsection Calling Mechanism
+
+In each of the architecture specific chapters, this subsection will
+describe the instruction(s) used to perform a @i{normal} subroutine
+invocation.  All RTEMS directives are invoked as @i{normal} C language
+functions so it is important to the user application to understand the
+call and return mechanism.
+
+@subsection Register Usage
+
+In each of the architecture specific chapters, this subsection will
+detail the set of registers which are @b{NOT} preserved across subroutine
+invocations.  The registers which are not preserved are assumed to be
+available for use as scratch registers.  Therefore, the contents of these
+registers should not be assumed upon return from any RTEMS directive.
+
+In some architectures, there may be a set of registers made available
+automatically as a side-effect of the subroutine invocation 
+mechanism.
+
+@subsection Parameter Passing
+
+In each of the architecture specific chapters, this subsection will
+describe the mechanism by which the parameters or arguments are passed
+by the caller to a subroutine.  In some architectures, all parameters
+are passed on the stack while in others some are passed in registers.
+
+@subsection User-Provided Routines
+
+All user-provided routines invoked by RTEMS, such as
+user extensions, device drivers, and MPCI routines, must also
+adhere to these calling conventions.
+
+@c
+@c
+@c
+@section Memory Model
+
+A processor may support any combination of memory
+models ranging from pure physical addressing to complex demand
+paged virtual memory systems.  RTEMS supports a flat memory
+model which ranges contiguously over the processor's allowable
+address space.  RTEMS does not support segmentation or virtual
+memory of any kind.  The appropriate memory model for RTEMS
+provided by the targeted processor and related characteristics
+of that model are described in this chapter.
+
+@subsection Flat Memory Model
+
+Most RTEMS target processors can be initialized to support a flat address
+space.  Although the size of addresses varies between architectures, on
+most RTEMS targets, an address is 32-bits wide which defines addresses
+ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes).  Each address is
+represented by a 32-bit value and is byte addressable.  The address may be
+used to reference a single byte, word (2-bytes), or long word (4 bytes).
+Memory accesses within this address space may be performed in little or
+big endian fashion.
+
+On smaller CPU architectures supported by RTEMS, the address space 
+may only be 20 or 24 bits wide.  
+
+If the CPU model has support for virtual memory or segmentation, it is
+the responsibility of the Board Support Package (BSP) to initialize the
+MMU hardware to perform address translations which correspond to flat
+memory model.
+
+In each of the architecture specific chapters, this subsection will
+describe any architecture characteristics that differ from this general
+description.
+
+@c
+@c
+@c
+@section Interrupt Processing
+
+Different types of processors respond to the occurrence of an interrupt
+in its own unique fashion. In addition, each processor type provides
+a control mechanism to allow for the proper handling of an interrupt.
+The processor dependent response to the interrupt modifies the current
+execution state and results in a change in the execution stream.  Most
+processors require that an interrupt handler utilize some 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.
+
+RTEMS supports a dedicated interrupt stack for all architectures.
+On architectures with hardware support for a dedicated interrupt stack,
+it will be initialized such that when an interrupt occurs, the processor
+automatically switches to this dedicated stack.  On architectures without
+hardware support for a dedicated interrupt stack which is separate from
+those of the tasks, RTEMS will support switching to a dedicated stack
+for interrupt processing.
+
+Without a dedicated interrupt stack, every task in
+the system MUST have enough stack space to accommodate the worst
+case stack usage of that particular task and the interrupt
+service routines COMBINED.  By supporting a dedicated interrupt
+stack, RTEMS significantly lowers the stack requirements for
+each task.
+
+A nested interrupt is processed similarly with the exception that since
+the CPU is already executing on the interrupt stack, there is no need
+to switch to the interrupt stack.
+
+In some configurations, RTEMS allocates the interrupt stack from the
+Workspace Area.  The amount of memory allocated for the interrupt stack
+is user configured and based upon the @code{confdefs.h} parameter
+@code{CONFIGURE_INTERRUPT_STACK_SIZE}.  This parameter is described
+in detail in the Configuring a System chapter of the User's Guide.
+On configurations in which RTEMS allocates the interrupt stack, during
+the initialization process, RTEMS will also install its interrupt stack.
+In other configurations, the interrupt stack is allocated and installed
+by the Board Support Package (BSP).
+
+In each of the architecture specific chapters, this section discesses
+the interrupt response and control mechanisms of the architecture as
+they pertain to RTEMS.
+
+@subsection Vectoring of an Interrupt Handler
+
+In each of the architecture specific chapters, this subsection will
+describe the architecture specific details of the interrupt vectoring
+process.  In particular, it should include a description of the 
+Interrupt Stack Frame (ISF).
+
+@subsection Interrupt Levels
+
+In each of the architecture specific chapters, this subsection will
+describe how the interrupt levels available on this particular architecture
+are mapped onto the 255 reserved in the task mode.  The interrupt level
+value of zero (0) should always mean that interrupts are enabled.
+
+Any use of an  interrupt level that is is not undefined on a particular
+architecture may result in behavior that is unpredictable.
+
+@subsection Disabling of Interrupts by RTEMS
+
+During the execution of directive calls, critical sections of code may
+be executed.  When these sections are encountered, RTEMS disables all
+external interrupts before the execution of this section and restores
+them to the previous level upon completion of the section.  RTEMS has
+been optimized to ensure that interrupts are disabled for the shortest
+number of instructions possible.  Since the precise number of instructions
+and their execution time varies based upon target CPU family, CPU model,
+board memory speed, compiler version, and optimization level, it is 
+not practical to provide the precise number for all possible RTEMS 
+configurations. 
+
+Historically, the measurements were made by hand analyzing and counting
+the execution time of instruction sequences during interrupt disable 
+critical sections.  For reference purposes, on a 16 Mhz Motorola
+MC68020, the maximum interrupt disable period was typically approximately
+ten (10) to thirteen (13) microseconds.  This architecture was memory bound
+and had a slow bit scan instruction.  In contrast, during the same 
+period a 14 Mhz SPARC would have a worst case disable time of approximately
+two (2) to three (3) microseconds because it had a single cycle bit scan
+instruction and used fewer cycles for memory accesses.
+
+If you are interested in knowing the worst case execution time for
+a particular version of RTEMS, please contact OAR Corporation and
+we will be happy to product the results as a consulting service.
+
+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.
+
+
+@c
+@c
+@c
+@section Default Fatal Error Processing
+
+Upon detection of a fatal error by either the application or RTEMS during
+initialization the @code{rtems_fatal_error_occurred} directive supplied
+by the Fatal Error Manager is invoked.  The Fatal Error Manager will
+invoke the user-supplied fatal error handlers.  If no user-supplied
+handlers are configured or all of them return without taking action to
+shutdown the processor or reset, a default fatal error handler is invoked.
+
+Most of the action performed as part of processing the fatal error are
+described in detail in the Fatal Error Manager chapter in the User's
+Guide.  However, the if no user provided extension or BSP specific fatal
+error handler takes action, the final default action is to invoke a
+CPU architecture specific function.  Typically this function disables
+interrupts and halts the processor.
+
+In each of the architecture specific chapters, this describes the precise
+operations of the default CPU specific fatal error handler.
+
+@c
+@c
+@c
+
+@section Board Support Packages
+
+An RTEMS Board Support Package (BSP) must be designed to support a
+particular processor model and target board combination.
+
+In each of the architecture specific chapters, this section will present
+a discussion of architecture specific BSP issues.   For more information
+on developing a BSP, refer to BSP and Device Driver Development Guide
+and the chapter titled Board Support Packages in the RTEMS
+Applications User's Guide.
+
+@subsection System Reset
+
+An RTEMS based application is initiated or re-initiated when the processor
+is reset or transfer is passed to it from a boot monitor or ROM monitor.
+
+In each of the architecture specific chapters, this subsection describes
+the actions that the BSP must tak assuming the application gets control
+when the microprocessor is reset.
diff --git a/doc/cpu_supplement/i386.t b/doc/cpu_supplement/i386.t
index 81222a0f6e..0914663cbc 100644
--- a/doc/cpu_supplement/i386.t
+++ b/doc/cpu_supplement/i386.t
@@ -10,15 +10,10 @@
 @end ifinfo
 @chapter Intel/AMD x86 Specific Information
 
-The Real Time Executive for Multiprocessor Systems
-(RTEMS) is designed to be portable across multiple processor
-architectures.  However, the nature of real-time systems makes
-it essential that the application designer understand certain
-processor dependent implementation details.  These processor
-dependencies include calling convention, board support package
-issues, interrupt processing, exact RTEMS memory requirements,
-performance data, header files, and the assembly language
-interface to the executive.
+This chapter discusses the Intel x86 architecture dependencies
+in this port of RTEMS.  This family has multiple implementations
+from multiple vendors and suffers more from having evolved rather
+than being designed for growth.
 
 For information on the i386 processor, refer to the
 following documents:
@@ -34,118 +29,36 @@ Order No. 231732-003}.
 @item @cite{80387 Programmer's Reference Manual, Intel, Order No.  231917-001}.
 @end itemize
 
-It is highly recommended that the i386 RTEMS
-application developer obtain and become familiar with Intel's
-386 Programmer's Reference Manual.
-
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section CPU Model Dependent Features
 
-
-Microprocessors are generally classified into
-families with a variety of CPU models or implementations within
-that family.  Within a processor family, there is a high level
-of binary compatibility.  This family may be based on either an
-architectural specification or on maintaining compatibility with
-a popular processor.  Recent microprocessor families such as the
-SPARC or PowerPC are based on an architectural specification
-which is independent or any particular CPU model or
-implementation.  Older families such as the M68xxx and the iX86
-evolved as the manufacturer strived to produce higher
-performance processor models which maintained binary
-compatibility with older models.
-
-RTEMS takes advantage of the similarity of the
-various models within a CPU family.  Although the models do vary
-in significant ways, the high level of compatibility makes it
-possible to share the bulk of the CPU dependent executive code
-across the entire family.  Each processor family supported by
-RTEMS has a list of features which vary between CPU models
-within a family.  For example, the most common model dependent
-feature regardless of CPU family is the presence or absence of a
-floating point unit or coprocessor.  When defining the list of
-features present on a particular CPU model, one simply notes
-that floating point hardware is or is not present and defines a
-single constant appropriately.  Conditional compilation is
-utilized to include the appropriate source code for this CPU
-model's feature set.  It is important to note that this means
-that RTEMS is thus compiled using the appropriate feature set
-and compilation flags optimal for this CPU model used.  The
-alternative would be to generate a binary which would execute on
-all family members using only the features which were always
-present.
-
-This chapter presents the set of features which vary
+This section presents the set of features which vary
 across i386 implementations and are of importance to RTEMS.
 The set of CPU model feature macros are defined in the file
-cpukit/score/cpu/i386/i386.h based upon the particular CPU
-model defined on the compilation command line.
-
-@subsection CPU Model Name
-
-The macro CPU_MODEL_NAME is a string which designates
-the name of this CPU model.  For example, for the Intel i386 without an
-i387 coprocessor, this macro is set to the string "i386 with i387".
+@code{cpukit/score/cpu/i386/i386.h} based upon the particular CPU
+model specified on the compilation command line.
 
 @subsection bswap Instruction
 
-The macro I386_HAS_BSWAP is set to 1 to indicate that
+The macro @code{I386_HAS_BSWAP} is set to 1 to indicate that
 this CPU model has the @code{bswap} instruction which
 endian swaps a thirty-two bit quantity.  This instruction
 appears to be present in all CPU models
 i486's and above.
 
-@subsection Floating Point Unit
-
-The macro I386_HAS_FPU is set to 1 to indicate that
-this CPU model has a hardware floating point unit and 0
-otherwise.  The hardware floating point may be on-chip (as in the
-case of an i486DX or Pentium) or as a coprocessor (as in the case of
-an i386/i387 combination).
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section Calling Conventions
 
-
-Each high-level language compiler generates
-subroutine entry and exit code based upon a set of rules known
-as the compiler's calling convention.   These rules address the
-following issues:
-
-@itemize @bullet
-@item register preservation and usage
-
-@item parameter passing
-
-@item call and return mechanism
-@end itemize
-
-A compiler's calling convention is of importance when
-interfacing to subroutines written in another language either
-assembly or high-level.  Even when the high-level language and
-target processor are the same, different compilers may use
-different calling conventions.  As a result, calling conventions
-are both processor and compiler dependent.
-
 @subsection Processor Background
 
 The i386 architecture supports a simple yet effective
 call and return mechanism.  A subroutine is invoked via the call
-(call) instruction.  This instruction pushes the return address
-on the stack.  The return from subroutine (ret) instruction pops
+(@code{call}) instruction.  This instruction pushes the return address
+on the stack.  The return from subroutine (@code{ret}) instruction pops
 the return address off the current stack and transfers control
 to that instruction.  It is is important to note that the i386
 call and return mechanism does not automatically save or restore
@@ -155,18 +68,16 @@ convention.
 
 @subsection Calling Mechanism
 
-All RTEMS directives are invoked using a call
-instruction and return to the user application via the ret
-instruction.
+All RTEMS directives are invoked using a call instruction and return to
+the user application via the ret instruction.
 
 @subsection Register Usage
 
-As discussed above, the call instruction does not
-automatically save any registers.  RTEMS uses the registers EAX,
-ECX, and EDX as scratch registers.  These registers are not
-preserved by RTEMS directives therefore, the contents of these
-registers should not be assumed upon return from any RTEMS
-directive.
+As discussed above, the call instruction does not automatically save
+any registers.  RTEMS uses the registers EAX, ECX, and EDX as scratch
+registers.  These registers are not preserved by RTEMS directives
+therefore, the contents of these registers should not be assumed upon
+return from any RTEMS directive.
 
 @subsection Parameter Passing
 
@@ -192,32 +103,12 @@ from the stack after control is returned to the caller.  This
 removal is typically accomplished by adding the size of the
 argument list in bytes to the stack pointer.
 
-@subsection User-Provided Routines
-
-All user-provided routines invoked by RTEMS, such as
-user extensions, device drivers, and MPCI routines, must also
-adhere to these calling conventions.
-
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Memory Model
 
-
-A processor may support any combination of memory
-models ranging from pure physical addressing to complex demand
-paged virtual memory systems.  RTEMS supports a flat memory
-model which ranges contiguously over the processor's allowable
-address space.  RTEMS does not support segmentation or virtual
-memory of any kind.  The appropriate memory model for RTEMS
-provided by the targeted processor and related characteristics
-of that model are described in this chapter.
-
 @subsection Flat Memory Model
 
 RTEMS supports the i386 protected mode, flat memory
@@ -247,48 +138,13 @@ gigabytes).  Each address is represented by a 32-bit value and
 is byte addressable.  The address may be used to reference a
 single byte, half-word (2-bytes), or word (4 bytes).
 
-RTEMS does not require that logical addresses map
-directly to physical addresses, although it is desirable in many
-applications to do so.  If logical and physical addresses are
-not the same, then an additional selector will be required so
-RTEMS can access the Interrupt Descriptor Table to install
-interrupt service routines.  The selector number of this segment
-is provided to RTEMS in the CPU Dependent Information Table.
-
-By not requiring that logical addresses map directly
-to physical addresses, the memory space of an RTEMS application
-can be separated from that of a ROM monitor.  For example, on
-the Force Computers CPU386, the ROM monitor loads application
-programs into a logical address space where logical address
-0x00000000 corresponds to physical address 0x0002000.  On this
-board, RTEMS and the application use virtual addresses which do
-not map to physical addresses.
-
-RTEMS assumes that the DS and ES registers contain
-the selector for the single data segment when a directive is
-invoked.   This assumption is especially important when
-developing interrupt service routines.
-
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Interrupt Processing
 
-
-Different types of processors respond to the
-occurrence of an interrupt in their own unique fashion. In
-addition, each processor type provides a control mechanism to
-allow the proper handling of an interrupt.  The processor
-dependent response to the interrupt modifies the execution state
-and results in the modification of the execution stream. This
-modification usually requires that an interrupt handler utilize
-the provided control mechanisms to return to the normal
-processing stream.  Although RTEMS hides many of the processor
+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
@@ -392,27 +248,6 @@ RTEMS interrupt levels 0 and 1 such that level zero
 that interrupts are disabled.  All other RTEMS interrupt levels
 are undefined and their behavior is unpredictable.
 
-@subsection Disabling of Interrupts by RTEMS
-
-During the execution of directive calls, critical
-sections of code may be executed.  When these sections are
-encountered, RTEMS disables interrupts 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 i386 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 within RTEMS was last calculated for
-Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-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.
-
 @subsection Interrupt Stack
 
 The i386 family does not support a dedicated hardware
@@ -424,69 +259,26 @@ non-nested interrupt returns, RTEMS switches back to the stack
 of the interrupted stack.  The current stack pointer is not
 altered by RTEMS on nested interrupt.
 
-Without a dedicated interrupt stack, every task in
-the system MUST have enough stack space to accommodate the worst
-case stack usage of that particular task and the interrupt
-service routines COMBINED.  By supporting a dedicated interrupt
-stack, RTEMS significantly lowers the stack requirements for
-each task.
-
-RTEMS allocates the dedicated interrupt stack from
-the Workspace Area.  The amount of memory allocated for the
-interrupt stack is determined by the interrupt_stack_size field
-in the CPU Configuration Table.
-
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Default Fatal Error Processing
 
-
-Upon detection of a fatal error by either the
-application or RTEMS the fatal error manager is invoked.  The
-fatal error manager will invoke the user-supplied fatal error
-handlers.  If no user-supplied handlers are configured,  the
-RTEMS provided default fatal error handler is invoked.  If the
-user-supplied fatal error handlers return to the executive the
-default fatal error handler is then invoked.  This chapter
-describes the precise operations of the default fatal error
-handler.
-
-@subsection Default Fatal Error Handler Operations
-
-The default fatal error handler which is invoked by
-the fatal_error_occurred directive when there is no user handler
-configured or the user handler returns control to RTEMS.  The
-default fatal error handler disables processor interrupts,
-places the error code in EAX, and executes a HLT instruction to
-halt the processor.
+The default fatal error handler for this architecture disables processor
+interrupts, places the error code in EAX, and executes a HLT instruction
+to halt the processor.
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Board Support Packages
 
-
-An RTEMS Board Support Package (BSP) must be designed to support a
-particular processor and target board combination.  This chapter presents a
-discussion of i386 specific BSP issues.  For more information on developing
-a BSP, refer to the chapter titled Board Support Packages in the RTEMS
-Applications User's Guide. 
-
 @subsection System Reset
 
-An RTEMS based application is initiated when the i386
-processor is reset.  When the i386 is reset,
+An RTEMS based application is initiated when the i386 processor is reset.
+When the i386 is reset,
 
 @itemize @bullet
 
@@ -571,6 +363,6 @@ enabled during the reset application initialization code.  The reset code
 which is executed before the call to initialize_executive has the following
 requirements:
 
-For more information regarding the i386s data structures and their
+For more information regarding the i386 data structures and their
 contents, refer to Intel's 386 Programmer's Reference Manual.
 
diff --git a/doc/cpu_supplement/m68k.t b/doc/cpu_supplement/m68k.t
index b39c3236b3..037a3e6596 100644
--- a/doc/cpu_supplement/m68k.t
+++ b/doc/cpu_supplement/m68k.t
@@ -8,212 +8,105 @@
 
 @ifinfo
 @end ifinfo
-@chapter Motorola M68xxx and Coldfire Specific Information
-
-The Real Time Executive for Multiprocessor Systems (RTEMS)
-is designed to be portable across multiple processor
-architectures.  However, the nature of real-time systems makes
-it essential that the application designer understand certain
-processor dependent implementation details.  These processor
-dependencies include calling convention, board support package
-issues, interrupt processing, exact RTEMS memory requirements,
-performance data, header files, and the assembly language
-interface to the executive.
-
-This document discusses the Motorola MC68xxx
-architecture dependencies in this port of RTEMS.  The MC68xxx
-family has a wide variety of CPU models within it.  The part
-numbers for these models are generally divided into MC680xx and
-MC683xx.  The MC680xx models are more general purpose processors
-with no integrated peripherals.  The MC683xx models, on the
-other hand, are more specialized and have a variety of
-peripherals on chip including sophisticated timers and serial
+@chapter M68xxx and Coldfire Specific Information
+
+This chapter discusses the Freescale (formerly Motorola) MC68xxx
+and Coldfire architectural dependencies.  The MC68xxx family has a
+wide variety of CPU models within it based upon different CPU core
+implementations.  Ignoring the Coldfire parts, the part numbers for
+these models are generally divided into MC680xx and MC683xx.  The MC680xx
+models are more general purpose processors with no integrated peripherals.
+The MC683xx models, on the other hand, are more specialized and have a
+variety of peripherals on chip including sophisticated timers and serial
 communications controllers.
 
-It is highly recommended that the Motorola MC68xxx
-RTEMS application developer obtain and become familiar with the
-documentation for the processor being used as well as the
-documentation for the family as a whole.
-
 @subheading Architecture Documents
 
-For information on the Motorola MC68xxx architecture,
-refer to the following documents available from Motorola
-(@file{http//www.moto.com/}):
+For information on the MC68xxx and Coldfire architecture, refer to the following documents available from Freescale website (@file{http//www.freescale.com/}):
 
 @itemize @bullet
 @item @cite{M68000 Family Reference, Motorola, FR68K/D}.
-@end itemize
-
-@subheading MODEL SPECIFIC DOCUMENTS
-
-For information on specific processor models and
-their associated coprocessors, refer to the following documents:
-
-@itemize  @bullet
 @item @cite{MC68020 User's Manual, Motorola, MC68020UM/AD}.
-
-@item @cite{MC68881/MC68882 Floating-Point Coprocessor User's
-Manual, Motorola, MC68881UM/AD}.
+@item @cite{MC68881/MC68882 Floating-Point Coprocessor User's Manual,
+Motorola, MC68881UM/AD}.
 @end itemize
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section CPU Model Dependent Features
 
 
-Microprocessors are generally classified into
-families with a variety of CPU models or implementations within
-that family.  Within a processor family, there is a high level
-of binary compatibility.  This family may be based on either an
-architectural specification or on maintaining compatibility with
-a popular processor.  Recent microprocessor families such as the
-SPARC or PowerPC are based on an architectural specification
-which is independent or any particular CPU model or
-implementation.  Older families such as the M68xxx and the iX86
-evolved as the manufacturer strived to produce higher
-performance processor models which maintained binary
-compatibility with older models.
-
-RTEMS takes advantage of the similarity of the
-various models within a CPU family.  Although the models do vary
-in significant ways, the high level of compatibility makes it
-possible to share the bulk of the CPU dependent executive code
-across the entire family.  Each processor family supported by
-RTEMS has a list of features which vary between CPU models
-within a family.  For example, the most common model dependent
-feature regardless of CPU family is the presence or absence of a
-floating point unit or coprocessor.  When defining the list of
-features present on a particular CPU model, one simply notes
-that floating point hardware is or is not present and defines a
-single constant appropriately.  Conditional compilation is
-utilized to include the appropriate source code for this CPU
-model's feature set.  It is important to note that this means
-that RTEMS is thus compiled using the appropriate feature set
-and compilation flags optimal for this CPU model used.  The
-alternative would be to generate a binary which would execute on
-all family members using only the features which were always
-present.
-
-This chapter presents the set of features which vary
-across SPARC implementations and are of importance to RTEMS.
+This section presents the set of features which vary
+across m68k/Coldfire implementations that are of importance to RTEMS.
 The set of CPU model feature macros are defined in the file
-cpukit/score/cpu/m68k/m68k.h based upon the particular CPU
-model defined on the compilation command line.
-
-@subsection CPU Model Name
-
-The macro CPU_MODEL_NAME is a string which designates
-the name of this CPU model.  For example, for the MC68020
-processor, this macro is set to the string "mc68020".
-
-@subsection Floating Point Unit
-
-The macro M68K_HAS_FPU is set to 1 to indicate that
-this CPU model has a hardware floating point unit and 0
-otherwise.  It does not matter whether the hardware floating
-point support is incorporated on-chip or is an external
-coprocessor.
+@code{cpukit/score/cpu/m68k/m68k.h} based upon the particular CPU
+model selected on the compilation command line.
 
 @subsection BFFFO Instruction
 
-The macro M68K_HAS_BFFFO is set to 1 to indicate that
+The macro @code{M68K_HAS_BFFFO} is set to 1 to indicate that
 this CPU model has the bfffo instruction.
 
 @subsection Vector Base Register
 
-The macro M68K_HAS_VBR is set to 1 to indicate that
+The macro @code{M68K_HAS_VBR} is set to 1 to indicate that
 this CPU model has a vector base register (vbr).
 
 @subsection Separate Stacks
 
-The macro M68K_HAS_SEPARATE_STACKS is set to 1 to
+The macro @code{M68K_HAS_SEPARATE_STACKS} is set to 1 to
 indicate that this CPU model has separate interrupt, user, and
 supervisor mode stacks.
 
 @subsection Pre-Indexing Address Mode
 
-The macro M68K_HAS_PREINDEXING is set to 1 to indicate that
+The macro @code{M68K_HAS_PREINDEXING} is set to 1 to indicate that
 this CPU model has the pre-indexing address mode.
 
 @subsection Extend Byte to Long Instruction
  
-The macro M68K_HAS_EXTB_L is set to 1 to indicate that this CPU model 
+The macro @code{M68K_HAS_EXTB_L} is set to 1 to indicate that this CPU model 
 has the extb.l instruction.  This instruction is supposed to be available
 in all models based on the cpu32 core as well as mc68020 and up models.
+
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section Calling Conventions
 
-
-Each high-level language compiler generates
-subroutine entry and exit code based upon a set of rules known
-as the compiler's calling convention.   These rules address the
-following issues:
-
-@itemize @bullet
-@item register preservation and usage
-@item parameter passing
-@item call and return mechanism
-@end itemize
-
-A compiler's calling convention is of importance when
-interfacing to subroutines written in another language either
-assembly or high-level.  Even when the high-level language and
-target processor are the same, different compilers may use
-different calling conventions.  As a result, calling conventions
-are both processor and compiler dependent.
-
-@subsection Processor Background
-
-The MC68xxx architecture supports a simple yet
-effective call and return mechanism.  A subroutine is invoked
-via the branch to subroutine (bsr) or the jump to subroutine
-(jsr) instructions.  These instructions push the return address
-on the current stack.  The return from subroutine (rts)
-instruction pops the return address off the current stack and
-transfers control to that instruction.  It is is important to
-note that the MC68xxx call and return mechanism does not
-automatically save or restore any registers.  It is the
-responsibility of the high-level language compiler to define the
-register preservation and usage convention.
+The MC68xxx architecture supports a simple yet effective call and
+return mechanism.  A subroutine is invoked via the branch to subroutine
+(@code{bsr}) or the jump to subroutine (@code{jsr}) instructions.
+These instructions push the return address on the current stack.
+The return from subroutine (@code{rts}) instruction pops the return
+address off the current stack and transfers control to that instruction.
+It is is important to note that the MC68xxx call and return mechanism does
+not automatically save or restore any registers.  It is the responsibility
+of the high-level language compiler to define the register preservation
+and usage convention.
 
 @subsection Calling Mechanism
 
-All RTEMS directives are invoked using either a bsr
-or jsr instruction and return to the user application via the
-rts instruction.
+All RTEMS directives are invoked using either a @code{bsr} or @code{jsr}
+instruction and return to the user application via the rts instruction.
 
 @subsection Register Usage
 
-As discussed above, the bsr and jsr instructions do
-not automatically save any registers.  RTEMS uses the registers
-D0, D1, A0, and A1 as scratch registers.  These registers are
-not preserved by RTEMS directives therefore, the contents of
-these registers should not be assumed upon return from any RTEMS
-directive.
+As discussed above, the @code{bsr} and @code{jsr} instructions do not
+automatically save any registers.  RTEMS uses the registers D0, D1,
+A0, and A1 as scratch registers.  These registers are not preserved by
+RTEMS directives therefore, the contents of these registers should not
+be assumed upon return from any RTEMS directive.
 
 @subsection Parameter Passing
 
-RTEMS assumes that arguments are placed on the
-current stack before the directive is invoked via the bsr or jsr
-instruction.  The first argument is assumed to be closest to the
-return address on the stack.  This means that the first argument
-of the C calling sequence is pushed last.  The following
-pseudo-code illustrates the typical sequence used to call a
-RTEMS directive with three (3) arguments:
+RTEMS assumes that arguments are placed on the current stack before
+the directive is invoked via the bsr or jsr instruction.  The first
+argument is assumed to be closest to the return address on the stack.
+This means that the first argument of the C calling sequence is pushed
+last.  The following pseudo-code illustrates the typical sequence used
+to call a RTEMS directive with three (3) arguments:
 
 @example
 @group
@@ -225,41 +118,17 @@ remove arguments from the stack
 @end group
 @end example
 
-The arguments to RTEMS are typically pushed onto the
-stack using a move instruction with a pre-decremented stack
-pointer as the destination.  These arguments must be removed
-from the stack after control is returned to the caller.  This
-removal is typically accomplished by adding the size of the
-argument list in bytes to the current stack pointer.
-
-@subsection User-Provided Routines
-
-All user-provided routines invoked by RTEMS, such as
-user extensions, device drivers, and MPCI routines, must also
-adhere to these calling conventions.
+The arguments to RTEMS are typically pushed onto the stack using a move
+instruction with a pre-decremented stack pointer as the destination.
+These arguments must be removed from the stack after control is returned
+to the caller.  This removal is typically accomplished by adding the
+size of the argument list in bytes to the current stack pointer.
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section Memory Model
 
-
-A processor may support any combination of memory
-models ranging from pure physical addressing to complex demand
-paged virtual memory systems.  RTEMS supports a flat memory
-model which ranges contiguously over the processor's allowable
-address space.  RTEMS does not support segmentation or virtual
-memory of any kind.  The appropriate memory model for RTEMS
-provided by the targeted processor and related characteristics
-of that model are described in this chapter.
-
-@subsection Flat Memory Model
-
 The MC68xxx family supports a flat 32-bit address
 space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
 gigabytes).  Each address is represented by a 32-bit value and
@@ -277,44 +146,23 @@ these systems.  RTEMS does not support virtual memory or
 segmentation on any of the MC68xxx family members.
 
 @c
-@c  Interrupt Stack Frame Picture
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
-@c
-
 @section Interrupt Processing
 
-
-Different types of processors respond to the
-occurrence of an interrupt in its own unique fashion. In
-addition, each processor type provides a control mechanism to
-allow for the proper handling of an interrupt.  The processor
-dependent response to the interrupt modifies the current
-execution state and results in a change in the execution stream.
-Most processors require that an interrupt handler utilize some
-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 MC68xxx's
-interrupt response and control mechanisms as they pertain to
-RTEMS.
+Discussed in this section are the MC68xxx's interrupt response and
+control mechanisms as they pertain to RTEMS.
 
 @subsection Vectoring of an Interrupt Handler
 
-Depending on whether or not the particular CPU
-supports a separate interrupt stack, the MC68xxx family has two
-different interrupt handling models.
+Depending on whether or not the particular CPU supports a separate
+interrupt stack, the MC68xxx family has two different interrupt handling
+models.
 
 @subsubsection Models Without Separate Interrupt Stacks
 
-Upon receipt of an interrupt the MC68xxx family
-members without separate interrupt stacks automatically perform
-the following actions:
+Upon receipt of an interrupt the MC68xxx family members without separate
+interrupt stacks automatically perform the following actions:
 
 @itemize @bullet
 @item To Be Written
@@ -322,9 +170,8 @@ the following actions:
 
 @subsubsection Models With Separate Interrupt Stacks
 
-Upon receipt of an interrupt the MC68xxx family
-members with separate interrupt stacks automatically perform the
-following actions:
+Upon receipt of an interrupt the MC68xxx family members with separate
+interrupt stacks automatically perform the following actions:
 
 @itemize @bullet
 @item saves the current status register (SR),
@@ -425,19 +272,18 @@ MC68xxx CPU models with separate interrupt stacks:
 This is from a post by Zoltan Kocsi <zoltan@@bendor.com.au> and is
 a nice trick in certain situations.  In his words:
 
-I think somebody on this list asked about the interupt vector 
-handling w/o VBR and RAM at 0.  The usual trick is 
-to initialise the vector table (except the first 2 two entries, of 
-course) to point to the same location BUT you also add the vector 
-number times 0x1000000 to them. That is, bits 31-24 contain the vector 
-number and 23-0 the address of the common handler.
-Since the PC is 32 bit wide but the actual address bus is only 24,
-the top byte will be in the PC but will be ignored when jumping
-onto your routine.
+I think somebody on this list asked about the interupt vector handling
+w/o VBR and RAM at 0.  The usual trick is to initialise the vector table
+(except the first 2 two entries, of course) to point to the same location
+BUT you also add the vector number times 0x1000000 to them. That is,
+bits 31-24 contain the vector number and 23-0 the address of the common
+handler.  Since the PC is 32 bit wide but the actual address bus is only
+24, the top byte will be in the PC but will be ignored when jumping onto
+your routine.
 
-Then your common interrupt routine gets this info by loading the PC 
-into some register and based on that info, you can jump to a vector
-in a vector table pointed by a virtual VBR:
+Then your common interrupt routine gets this info by loading the PC
+into some register and based on that info, you can jump to a vector in
+a vector table pointed by a virtual VBR:
 
 @example
 //
@@ -505,95 +351,26 @@ through 7 directly correspond to MC68xxx interrupt levels.  All
 other RTEMS interrupt levels are undefined and their behavior is
 unpredictable.
 
-@subsection Disabling of Interrupts by RTEMS
-
-During the execution of directive calls, critical
-sections of code may be executed.  When these sections are
-encountered, RTEMS disables interrupts to level seven (7) 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 MC68020 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.]
-
-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.
-
-@subsection Interrupt Stack
-
-RTEMS allocates the interrupt stack from the
-Workspace Area.  The amount of memory allocated for the
-interrupt stack is determined by the interrupt_stack_size field
-in the CPU Configuration Table.  During the initialization
-process, RTEMS will install its interrupt stack.
-
-The MC68xxx port of RTEMS supports a software managed
-dedicated interrupt stack on those CPU models which do not
-support a separate interrupt stack in hardware.
-
-
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section Default Fatal Error Processing
 
-
-Upon detection of a fatal error by either the
-application or RTEMS the fatal error manager is invoked.  The
-fatal error manager will invoke the user-supplied fatal error
-handlers.  If no user-supplied handlers are configured,  the
-RTEMS provided default fatal error handler is invoked.  If the
-user-supplied fatal error handlers return to the executive the
-default fatal error handler is then invoked.  This chapter
-describes the precise operations of the default fatal error
-handler.
-
-@subsection Default Fatal Error Handler Operations
-
-The default fatal error handler which is invoked by
-the fatal_error_occurred directive when there is no user handler
-configured or the user handler returns control to RTEMS.  The
-default fatal error handler disables processor interrupts to
-level 7, places the error code in D0, and executes a stop
-instruction to simulate a halt processor instruction.
+The default fatal error handler for this architecture disables processor
+interrupts to level 7, places the error code in D0, and executes a
+@code{stop} instruction to simulate a halt processor instruction.
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Board Support Packages
 
-
-An RTEMS Board Support Package (BSP) must be designed
-to support a particular processor and target board combination.
-This chapter presents a discussion of MC68020 specific BSP
-issues.   For more information on developing a BSP, refer to the
-chapter titled Board Support Packages in the RTEMS
-Applications User's Guide.
-
 @subsection System Reset
 
-An RTEMS based application is initiated or
-re-initiated when the MC68020 processor is reset.  When the
-MC68020 is reset, the processor performs the following actions:
+An RTEMS based application is initiated or re-initiated when the MC68020
+processor is reset.  When the MC68020 is reset, the processor performs
+the following actions:
 
 @itemize @bullet
 @item The tracing bits of the status register are cleared to
@@ -624,17 +401,16 @@ the PC.
 
 @subsection Processor Initialization
 
-The address of the application's initialization code
-should be stored in the first vector of the EVT which will allow
-the immediate vectoring to the application code.  If the
-application requires that the VBR be some value besides zero,
-then it should be set to the required value at this point.  All
-tasks share the same MC68020's VBR value.  Because interrupts
-are enabled automatically by RTEMS as part of the initialize
-executive directive, the VBR MUST be set before this directive
-is invoked to insure correct interrupt vectoring.  If processor
-caching is to be utilized, then it should be enabled during the
-reset application initialization code.
+The address of the application's initialization code should be stored in
+the first vector of the EVT which will allow the immediate vectoring to
+the application code.  If the application requires that the VBR be some
+value besides zero, then it should be set to the required value at this
+point.  All tasks share the same MC68020's VBR value.  Because interrupts
+are enabled automatically by RTEMS as part of the context switch to the
+first task, the VBR MUST be set by either RTEMS of the BSP before this
+occurs ensure correct interrupt vectoring.  If processor caching 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 Applications User's
@@ -656,9 +432,3 @@ the initialize executive directive.
 @item Must initialize the MC68020's vector table.
 @end itemize
 
-Note that the BSP is not responsible for allocating
-or installing the interrupt stack.  RTEMS does this
-automatically as part of initialization.  If the BSP does not
-install an interrupt stack and -- for whatever reason -- an
-interrupt occurs before initialize_executive is invoked, then
-the results are unpredictable.
diff --git a/doc/cpu_supplement/mips.t b/doc/cpu_supplement/mips.t
index 1d65981719..1d9a0af77c 100644
--- a/doc/cpu_supplement/mips.t
+++ b/doc/cpu_supplement/mips.t
@@ -10,231 +10,68 @@
 @end ifinfo
 @chapter MIPS Specific Information
 
-The Real Time Executive for Multiprocessor Systems (RTEMS)
-is designed to be portable across multiple processor
-architectures.  However, the nature of real-time systems makes
-it essential that the application designer understand certain
-processor dependent implementation details.  These processor
-dependencies include calling convention, board support package
-issues, interrupt processing, exact RTEMS memory requirements,
-performance data, header files, and the assembly language
-interface to the executive.
-
-This document discusses the VENDOR XXX
-architecture dependencies in this port of RTEMS.  The XXX
-family has a wide variety of CPU models within it.  The part 
-numbers ...
-
-XXX fill in some things here
-
-It is highly recommended that the XXX
-RTEMS application developer obtain and become familiar with the
-documentation for the processor being used as well as the
-documentation for the family as a whole.
+This chapter discusses the MIPS architecture dependencies
+in this port of RTEMS.  The MIPS family has a wide variety
+of implementations by a wide range of vendors.  Consequently,
+there are many, many CPU models within it.
 
 @subheading Architecture Documents
 
 IDT docs are online at http://www.idt.com/products/risc/Welcome.html
 
-For information on the XXX architecture,
-refer to the following documents available from VENDOR
-(@file{http//www.XXX.com/}):
+For information on the XXX architecture, refer to the following documents
+available from VENDOR (@file{http//www.XXX.com/}):
 
 @itemize @bullet
 @item @cite{XXX Family Reference, VENDOR, PART NUMBER}.
 @end itemize
 
-@subheading MODEL SPECIFIC DOCUMENTS
-
-For information on specific processor models and
-their associated coprocessors, refer to the following documents:
-
-@itemize  @bullet
-@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}.
-@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}.
-@end itemize
-
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section CPU Model Dependent Features
 
-
-Microprocessors are generally classified into
-families with a variety of CPU models or implementations within
-that family.  Within a processor family, there is a high level
-of binary compatibility.  This family may be based on either an
-architectural specification or on maintaining compatibility with
-a popular processor.  Recent microprocessor families such as the
-SPARC or PowerPC are based on an architectural specification
-which is independent or any particular CPU model or
-implementation.  Older families such as the M68xxx and the iX86
-evolved as the manufacturer strived to produce higher
-performance processor models which maintained binary
-compatibility with older models.
-
-RTEMS takes advantage of the similarity of the
-various models within a CPU family.  Although the models do vary
-in significant ways, the high level of compatibility makes it
-possible to share the bulk of the CPU dependent executive code
-across the entire family.  Each processor family supported by
-RTEMS has a list of features which vary between CPU models
-within a family.  For example, the most common model dependent
-feature regardless of CPU family is the presence or absence of a
-floating point unit or coprocessor.  When defining the list of
-features present on a particular CPU model, one simply notes
-that floating point hardware is or is not present and defines a
-single constant appropriately.  Conditional compilation is
-utilized to include the appropriate source code for this CPU
-model's feature set.  It is important to note that this means
-that RTEMS is thus compiled using the appropriate feature set
-and compilation flags optimal for this CPU model used.  The
-alternative would be to generate a binary which would execute on
-all family members using only the features which were always
-present.
-
-This chapter presents the set of features which vary
-across SPARC implementations and are of importance to RTEMS.
+This section presents the set of features which vary
+across MIPS implementations and are of importance to RTEMS.
 The set of CPU model feature macros are defined in the file
-cpukit/score/cpu/XXX/XXX.h based upon the particular CPU
-model defined on the compilation command line.
-
-@subsection CPU Model Name
-
-The macro CPU_MODEL_NAME is a string which designates
-the name of this CPU model.  For example, for the MODEL
-processor, this macro is set to the string "XXX".
-
-@subsection Floating Point Unit
-
-The macro XXX_HAS_FPU is set to 1 to indicate that
-this CPU model has a hardware floating point unit and 0
-otherwise.  It does not matter whether the hardware floating
-point support is incorporated on-chip or is an external
-coprocessor.
+@code{cpukit/score/cpu/mips/mips.h} based upon the particular CPU
+model specified on the compilation command line.
 
 @subsection Another Optional Feature
 
 The macro XXX 
+
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Calling Conventions
 
-
-Each high-level language compiler generates
-subroutine entry and exit code based upon a set of rules known
-as the compiler's calling convention.   These rules address the
-following issues:
-
-@itemize @bullet
-@item register preservation and usage
-@item parameter passing
-@item call and return mechanism
-@end itemize
-
-A compiler's calling convention is of importance when
-interfacing to subroutines written in another language either
-assembly or high-level.  Even when the high-level language and
-target processor are the same, different compilers may use
-different calling conventions.  As a result, calling conventions
-are both processor and compiler dependent.
-
 @subsection Processor Background
 
-The MC68xxx architecture supports a simple yet
-effective call and return mechanism.  A subroutine is invoked
-via the branch to subroutine (@code{XXX}) or the jump to subroutine
-(@code{XXX}) instructions.  These instructions push the return address
-on the current stack.  The return from subroutine (@code{XXX})
-instruction pops the return address off the current stack and
-transfers control to that instruction.  It is is important to
-note that the XXX call and return mechanism does not
-automatically save or restore any registers.  It is the
-responsibility of the high-level language compiler to define the
-register preservation and usage convention.
+TBD
 
 @subsection Calling Mechanism
 
-All RTEMS directives are invoked using either a @code{XXX}
-or @code{XXX} instruction and return to the user application via the
-@code{XXX} instruction.
+TBD
 
 @subsection Register Usage
 
-As discussed above, the @code{XXX} and @code{XXX} instructions do
-not automatically save any registers.  RTEMS uses the registers
-@b{D0}, @b{D1}, @b{A0}, and @b{A1} as scratch registers.  These registers are
-not preserved by RTEMS directives therefore, the contents of
-these registers should not be assumed upon return from any RTEMS
-directive.
+TBD
 
 @subsection Parameter Passing
 
-RTEMS assumes that arguments are placed on the
-current stack before the directive is invoked via the @code{XXX} or @code{XXX}
-instruction.  The first argument is assumed to be closest to the
-return address on the stack.  This means that the first argument
-of the C calling sequence is pushed last.  The following
-pseudo-code illustrates the typical sequence used to call a
-RTEMS directive with three (3) arguments:
-
-@example
-@group
-push third argument
-push second argument
-push first argument
-invoke directive
-remove arguments from the stack
-@end group
-@end example
-
-The arguments to RTEMS are typically pushed onto the
-stack using a move instruction with a pre-decremented stack
-pointer as the destination.  These arguments must be removed
-from the stack after control is returned to the caller.  This
-removal is typically accomplished by adding the size of the
-argument list in bytes to the current stack pointer.
-
-@subsection User-Provided Routines
-
-All user-provided routines invoked by RTEMS, such as
-user extensions, device drivers, and MPCI routines, must also
-adhere to these calling conventions.
+TBD
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section Memory Model
 
-
-A processor may support any combination of memory
-models ranging from pure physical addressing to complex demand
-paged virtual memory systems.  RTEMS supports a flat memory
-model which ranges contiguously over the processor's allowable
-address space.  RTEMS does not support segmentation or virtual
-memory of any kind.  The appropriate memory model for RTEMS
-provided by the targeted processor and related characteristics
-of that model are described in this chapter.
-
 @subsection Flat Memory Model
 
-The XXX family supports a flat 32-bit address
+The MIPS family supports a flat 32-bit address
 space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
 gigabytes).  Each address is represented by a 32-bit value and
 is byte addressable.  The address may be used to reference a
@@ -242,88 +79,32 @@ single byte, word (2-bytes), or long word (4 bytes).  Memory
 accesses within this address space are performed in big endian
 fashion by the processors in this family.
 
-Some of the XXX family members such as the
-XXX, XXX, and XXX support virtual memory and
-segmentation.  The XXX requires external hardware support
-such as the XXX Paged Memory Management Unit coprocessor
-which is typically used to perform address translations for
-these systems.  RTEMS does not support virtual memory or
-segmentation on any of the XXX family members.
+Some of the MIPS family members such as the support virtual memory and
+segmentation.  RTEMS does not support virtual memory or
+segmentation on any of these family members.
 
 @c
-@c  Interrupt Stack Frame Picture
-@c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Interrupt Processing
 
-
-Different types of processors respond to the
-occurrence of an interrupt in its own unique fashion. In
-addition, each processor type provides a control mechanism to
-allow for the proper handling of an interrupt.  The processor
-dependent response to the interrupt modifies the current
-execution state and results in a change in the execution stream.
-Most processors require that an interrupt handler utilize some
-special control mechanisms to return to the normal processing
-stream.  Although RTEMS hides many of the processor dependent
+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 XXX's
+unique architecture. Discussed in this chapter are the MIPS's
 interrupt response and control mechanisms as they pertain to
 RTEMS.
 
 @subsection Vectoring of an Interrupt Handler
 
-Depending on whether or not the particular CPU
-supports a separate interrupt stack, the XXX family has two
-different interrupt handling models.
-
-@subsubsection Models Without Separate Interrupt Stacks
-
-Upon receipt of an interrupt the XXX family
-members without separate interrupt stacks automatically perform
-the following actions:
-
-@itemize @bullet
-@item To Be Written
-@end itemize
-
-@subsubsection Models With Separate Interrupt Stacks
-
 Upon receipt of an interrupt the XXX family
 members with separate interrupt stacks automatically perform the
 following actions:
 
 @itemize @bullet
-@item saves the current status register (SR),
-
-@item clears the master/interrupt (M) bit of the SR to
-indicate the switch from master state to interrupt state,
-
-@item sets the privilege mode to supervisor,
-
-@item suppresses tracing,
-
-@item sets the interrupt mask level equal to the level of the
-interrupt being serviced,
-
-@item pushes an interrupt stack frame (ISF), which includes
-the program counter (PC), the status register (SR), and the
-format/exception vector offset (FVO) word, onto the supervisor
-and interrupt stacks,
+@item TBD
 
-@item switches the current stack to the interrupt stack and
-vectors to an interrupt service routine (ISR).  If the ISR was
-installed with the interrupt_catch directive, then the RTEMS
-interrupt handler will begin execution.  The RTEMS interrupt
-handler saves all registers which are not preserved according to
-the calling conventions and invokes the application's ISR.
 @end itemize
 
 A nested interrupt is processed similarly by these
@@ -331,238 +112,35 @@ CPU models with the exception that only a single ISF is placed
 on the interrupt stack and the current stack need not be
 switched.
 
-The FVO word in the Interrupt Stack Frame is examined
-by RTEMS to determine when an outer most interrupt is being
-exited. Since the FVO is used by RTEMS for this purpose, the
-user application code MUST NOT modify this field.
-
-The following shows the Interrupt Stack Frame for
-XXX CPU models with separate interrupt stacks:
-
-@ifset use-ascii
-@example
-@group
-               +----------------------+
-               |    Status Register   | 0x0
-               +----------------------+    
-               | Program Counter High | 0x2
-               +----------------------+    
-               | Program Counter Low  | 0x4
-               +----------------------+    
-               | Format/Vector Offset | 0x6
-               +----------------------+    
-@end group
-@end example
-@end ifset
-
-@ifset use-tex
-@sp 1
-@tex
-\centerline{\vbox{\offinterlineskip\halign{
-\strut\vrule#&
-\hbox to 2.00in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 0.50in{\enskip\hfil#\hfil}
-\cr
-\multispan{3}\hrulefill\cr
-& Status Register && 0x0\cr
-\multispan{3}\hrulefill\cr
-& Program Counter High && 0x2\cr
-\multispan{3}\hrulefill\cr
-& Program Counter Low && 0x4\cr
-\multispan{3}\hrulefill\cr
-& Format/Vector Offset && 0x6\cr
-\multispan{3}\hrulefill\cr
-}}\hfil}
-@end tex
-@end ifset
-
-@ifset use-html
-@html
-<CENTER>
-  <TABLE COLS=2 WIDTH="40%" BORDER=2>
-<TR><TD ALIGN=center><STRONG>Status Register</STRONG></TD>
-    <TD ALIGN=center>0x0</TD></TR>
-<TR><TD ALIGN=center><STRONG>Program Counter High</STRONG></TD>
-    <TD ALIGN=center>0x2</TD></TR>
-<TR><TD ALIGN=center><STRONG>Program Counter Low</STRONG></TD>
-    <TD ALIGN=center>0x4</TD></TR>
-<TR><TD ALIGN=center><STRONG>Format/Vector Offset</STRONG></TD>
-    <TD ALIGN=center>0x6</TD></TR>
-  </TABLE>
-</CENTER>
-@end html
-@end ifset
-
 @subsection Interrupt Levels
 
-Eight levels (0-7) of interrupt priorities are
-supported by XXX family members with level seven (7) 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
-XXX family only supports eight.  RTEMS interrupt levels 0
-through 7 directly correspond to XXX interrupt levels.  All
-other RTEMS interrupt levels are undefined and their behavior is
-unpredictable.
-
-@subsection Disabling of Interrupts by RTEMS
-
-During the execution of directive calls, critical
-sections of code may be executed.  When these sections are
-encountered, RTEMS disables interrupts to level seven (7) 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 processor 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.]
-
-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.
-
-@subsection Interrupt Stack
-
-RTEMS allocates the interrupt stack from the
-Workspace Area.  The amount of memory allocated for the
-interrupt stack is determined by the interrupt_stack_size field
-in the CPU Configuration Table.  During the initialization
-process, RTEMS will install its interrupt stack.
-
-The mips port of RTEMS supports a software managed
-dedicated interrupt stack on those CPU models which do not
-support a separate interrupt stack in hardware.
-
+TBD
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section Default Fatal Error Processing
 
-
-Upon detection of a fatal error by either the
-application or RTEMS the fatal error manager is invoked.  The
-fatal error manager will invoke the user-supplied fatal error
-handlers.  If no user-supplied handlers are configured,  the
-RTEMS provided default fatal error handler is invoked.  If the
-user-supplied fatal error handlers return to the executive the
-default fatal error handler is then invoked.  This chapter
-describes the precise operations of the default fatal error
-handler.
-
-@subsection Default Fatal Error Handler Operations
-
-The default fatal error handler which is invoked by
-the @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 processor interrupts,
-places the error code in @b{XXX}, and executes a @code{XXX}
-instruction to simulate a halt processor instruction.
+The default fatal error handler for this target architecture disables
+processor interrupts, places the error code in @b{XXX}, and executes a
+@code{XXX} instruction to simulate a halt processor instruction.
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section Board Support Packages
 
-
-An RTEMS Board Support Package (BSP) must be designed
-to support a particular processor and target board combination.
-This chapter presents a discussion of XXX specific BSP
-issues.   For more information on developing a BSP, refer to the
-chapter titled Board Support Packages in the RTEMS
-Applications User's Guide.
-
 @subsection System Reset
 
 An RTEMS based application is initiated or
-re-initiated when the XXX processor is reset.  When the
-XXX is reset, the processor performs the following actions:
+re-initiated when the processor is reset.  When the
+processor is reset, it performs the following actions:
 
 @itemize @bullet
-@item The tracing bits of the status register are cleared to
-disable tracing.
-
-@item The supervisor interrupt state is entered by setting the
-supervisor (S) bit and clearing the master/interrupt (M) bit of
-the status register.
-
-@item The interrupt mask of the status register is set to
-level 7 to effectively disable all maskable interrupts.
-
-@item The vector base register (VBR) is set to zero.
+@item TBD
 
-@item The cache control register (CACR) is set to zero to
-disable and freeze the processor cache.
-
-@item The interrupt stack pointer (ISP) is set to the value
-stored at vector 0 (bytes 0-3) of the exception vector table
-(EVT).
-
-@item The program counter (PC) is set to the value stored at
-vector 1 (bytes 4-7) of the EVT.
-
-@item The processor begins execution at the address stored in
-the PC.
 @end itemize
 
 @subsection Processor Initialization
 
-The address of the application's initialization code
-should be stored in the first vector of the EVT which will allow
-the immediate vectoring to the application code.  If the
-application requires that the VBR be some value besides zero,
-then it should be set to the required value at this point.  All
-tasks share the same XXX's VBR value.  Because interrupts
-are enabled automatically by RTEMS as part of the initialize
-executive directive, the VBR MUST be set before this directive
-is invoked to insure correct interrupt vectoring.  If processor
-caching 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 Applications User's
-Manual for the reset code which is executed before the call to
-initialize executive, the XXX version has the following
-specific requirements:
-
-@itemize @bullet
-@item Must leave the S bit of the status register set so that
-the XXX remains in the supervisor state.
-
-@item Must set the M bit of the status register to remove the
-XXX from the interrupt state.
-
-@item Must set the master stack pointer (MSP) such that a
-minimum stack size of MINIMUM_STACK_SIZE bytes is provided for
-the initialize executive directive.
-
-@item Must initialize the XXX's vector table.
-@end itemize
-
-Note that the BSP is not responsible for allocating
-or installing the interrupt stack.  RTEMS does this
-automatically as part of initialization.  If the BSP does not
-install an interrupt stack and -- for whatever reason -- an
-interrupt occurs before initialize_executive is invoked, then
-the results are unpredictable.
+TBD
diff --git a/doc/cpu_supplement/powerpc.t b/doc/cpu_supplement/powerpc.t
index 8b6604acb7..39d673dc15 100644
--- a/doc/cpu_supplement/powerpc.t
+++ b/doc/cpu_supplement/powerpc.t
@@ -10,18 +10,10 @@
 @end ifinfo
 @chapter PowerPC Specific Information
 
-The Real Time Executive for Multiprocessor Systems
-(RTEMS) is designed to be portable across multiple processor
-architectures.  However, the nature of real-time systems makes
-it essential that the application designer understand certain
-processor dependent implementation details.  These processor
-dependencies include calling convention, board support package
-issues, interrupt processing, exact RTEMS memory requirements,
-performance data, header files, and the assembly language
-interface to the executive.
-
-This document discusses the PowerPC architecture
-dependencies in this port of RTEMS.
+This chapter discusses the PowerPC architecture dependencies
+in this port of RTEMS.  The PowerPC family has a wide variety
+of implementations by a range of vendors.  Consequently,
+there are many, many CPU models within it.
 
 It is highly recommended that the PowerPC RTEMS
 application developer obtain and become familiar with the
@@ -61,7 +53,6 @@ Unit Reference Manual} (Motorola Document RCPUURM/AD).
 
 @item @cite{PowerQUICC MPC860 User's Manual} (Motorola Document MPC860UM/AD).
 
-
 @end itemize
 
 Motorola maintains an on-line electronic library for the PowerPC
@@ -85,85 +76,28 @@ supports the addition of user provided device models which can be
 used to allow one to develop and debug embedded applications using
 the simulator.
 
-The latest version of PSIM is made available to the public via
-anonymous ftp at ftp://ftp.ci.com.au/pub/psim or
-ftp://cambridge.cygnus.com/pub/psim.  There is also a mailing list 
-at powerpc-psim@@ci.com.au.
-
+The latest version of PSIM is included in GDB and enabled on pre-built
+binaries provided by the RTEMS Project.
 
 @c
-@c  COPYRIGHT (c) 1989-2007.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section CPU Model Dependent Features
 
-
-Microprocessors are generally classified into
-families with a variety of CPU models or implementations within
-that family.  Within a processor family, there is a high level
-of binary compatibility.  This family may be based on either an
-architectural specification or on maintaining compatibility with
-a popular processor.  Recent microprocessor families such as the
-SPARC, and PowerPC are based on an architectural specification
-which is independent or any particular CPU model or
-implementation.  Older families such as the M68xxx and the iX86
-evolved as the manufacturer strived to produce higher
-performance processor models which maintained binary
-compatibility with older models.
-
-RTEMS takes advantage of the similarity of the
-various models within a CPU family.  Although the models do vary
-in significant ways, the high level of compatibility makes it
-possible to share the bulk of the CPU dependent executive code
-across the entire family.
-
-@subsection CPU Model Feature Flags
-
-Each processor family supported by RTEMS has a
-list of features which vary between CPU models
-within a family.  For example, the most common model dependent
-feature regardless of CPU family is the presence or absence of a
-floating point unit or coprocessor.  When defining the list of
-features present on a particular CPU model, one simply notes
-that floating point hardware is or is not present and defines a
-single constant appropriately.  Conditional compilation is
-utilized to include the appropriate source code for this CPU
-model's feature set.  It is important to note that this means
-that RTEMS is thus compiled using the appropriate feature set
-and compilation flags optimal for this CPU model used.  The
-alternative would be to generate a binary which would execute on
-all family members using only the features which were always
-present.
-
 This section presents the set of features which vary
 across PowerPC implementations and are of importance to RTEMS.
 The set of CPU model feature macros are defined in the file
-cpukit/score/cpu/ppc/ppc.h based upon the particular CPU
-model defined on the compilation command line.
-
-@subsubsection CPU Model Name
-
-The macro CPU_MODEL_NAME is a string which designates
-the name of this CPU model.  For example, for the PowerPC 603e
-model, this macro is set to the string "PowerPC 603e".
+@code{cpukit/score/cpu/powerpc/powerpc.h} based upon the particular CPU
+model specified on the compilation command line.
 
-@subsubsection 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.
-
-@subsubsection Alignment
+@subsection Alignment
 
 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.
 
-@subsubsection Cache Alignment
+@subsection Cache Alignment
 
 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
@@ -174,24 +108,24 @@ 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.
 
-@subsubsection Maximum Interrupts
+@subsection Maximum Interrupts
 
 The macro PPC_INTERRUPT_MAX is set to the number of exception sources
 supported by this PowerPC model.
 
-@subsubsection Has Double Precision Floating Point
+@subsection Has Double Precision Floating Point
 
 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.
 
-@subsubsection Critical Interrupts
+@subsection Critical Interrupts
 
 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.
 
-@subsubsection Use Multiword Load/Store Instructions
+@subsection Use Multiword Load/Store Instructions
 
 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.
@@ -199,15 +133,15 @@ 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.
 
-@subsubsection Instruction Cache Size
+@subsection Instruction Cache Size
 
 The macro PPC_I_CACHE is set to the size in bytes of the instruction cache.
 
-@subsubsection Data Cache Size
+@subsection Data Cache Size
 
 The macro PPC_D_CACHE is set to the size in bytes of the data cache.
 
-@subsubsection Debug Model
+@subsection 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
@@ -246,37 +180,13 @@ indicates that this CPU model follows the low power model defined for
 the PPC603e.
 
 @end table
+
 @c
-@c  COPYRIGHT (c) 1989-2007.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Calling Conventions
 
-
-Each high-level language compiler generates
-subroutine entry and exit code based upon a set of rules known
-as the compiler's calling convention.   These rules address the
-following issues:
-
-@itemize @bullet
-@item register preservation and usage
-
-@item parameter passing
-
-@item call and return mechanism
-@end itemize
-
-A compiler's calling convention is of importance when
-interfacing to subroutines written in another language either
-assembly or high-level.  Even when the high-level language and
-target processor are the same, different compilers may use
-different calling conventions.  As a result, calling conventions
-are both processor and compiler dependent.
-
 RTEMS supports the Embedded Application Binary Interface (EABI)
 calling convention.  Documentation for EABI is available by sending
 a message with a subject line of "EABI" to eabi@@goth.sis.mot.com.
@@ -467,33 +377,12 @@ load first argument into r3
 invoke directive
 @end example
 
-@subsection User-Provided Routines
-
-All user-provided routines invoked by RTEMS, such as
-user extensions, device drivers, and MPCI routines, must also
-adhere to these same calling conventions.
-
-
 @c
-@c  COPYRIGHT (c) 1989-2007.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Memory Model
 
-
-A processor may support any combination of memory
-models ranging from pure physical addressing to complex demand
-paged virtual memory systems.  RTEMS supports a flat memory
-model which ranges contiguously over the processor's allowable
-address space.  RTEMS does not support segmentation or virtual
-memory of any kind.  The appropriate memory model for RTEMS
-provided by the targeted processor and related characteristics
-of that model are described in this chapter.
-
 @subsection Flat Memory Model
 
 The PowerPC architecture supports a variety of memory models.
@@ -593,26 +482,17 @@ involving the PowerPC  are not supported.
 
 @section Interrupt Processing
 
-
-Different types of processors respond to the
-occurrence of an interrupt in its own unique fashion. In
-addition, each processor type provides a control mechanism to
-allow for the proper handling of an interrupt.  The processor
-dependent response to the interrupt modifies the current
-execution state and results in a change in the execution stream.
-Most processors require that an interrupt handler utilize some
-special control mechanisms to return to the normal processing
-stream.  Although RTEMS hides many of the processor dependent
+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 PowerPC's
 interrupt response and control mechanisms as they pertain to
 RTEMS.
 
-RTEMS and associated documentation uses the 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.
+RTEMS and associated documentation uses the 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.
 
 @subsection Synchronous Versus Asynchronous Exceptions
 
@@ -722,77 +602,14 @@ Setting bit 2 of the interrupt level enables External Interrupt execptions.
 
 All other bits in the RTEMS task interrupt level are ignored.
 
-@subsection Disabling of Interrupts by RTEMS
-
-During the execution of directive calls, critical
-sections of code may be executed.  When these sections are
-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 
-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.]
-
-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.
-
-@subsection Interrupt Stack
-
-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 PowerPC by providing a dedicated interrupt stack
-managed by software.
-
-During system initialization, RTEMS allocates the
-interrupt stack from the Workspace Area.  The amount of memory
-allocated for the interrupt stack is determined by the
-interrupt_stack_size field in the CPU Configuration Table.  As
-part of processing a non-nested interrupt, RTEMS will switch to
-the interrupt stack before invoking the installed handler.
-
-
-
 @c
-@c  COPYRIGHT (c) 1989-2007.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Default Fatal Error Processing
 
-
-Upon detection of a fatal error by either the
-application or RTEMS the fatal error manager is invoked.  The
-fatal error manager will invoke the user-supplied fatal error
-handlers.  If no user-supplied handlers are configured,  the
-RTEMS provided default fatal error handler is invoked.  If the
-user-supplied fatal error handlers return to the executive the
-default fatal error handler is then invoked.  This chapter
-describes the precise operations of the default fatal error
-handler.
-
-@subsection Default Fatal Error Handler Operations
-
-The default fatal error handler which is invoked by
-the @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 performs the following actions:
+The default fatal error handler for this architecture performs the
+following actions:
 
 @itemize @bullet
 
@@ -813,23 +630,11 @@ If the Program Exception returns, then the following actions are performed:
 @end itemize
 
 @c
-@c  COPYRIGHT (c) 1989-2007.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Board Support Packages
 
-
-An RTEMS Board Support Package (BSP) must be designed
-to support a particular processor and target board combination.
-This chapter presents a discussion of 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.
-
 @subsection System Reset
 
 An RTEMS based application is initiated or
@@ -847,15 +652,6 @@ CPU may execute a hard reset.
 
 @subsection Processor Initialization
 
-It is the responsibility of the application's
-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.  On-chip caching has been
@@ -873,8 +669,8 @@ the PowrePC version has the following specific requirements:
 to 0 so the PowerPC remains in the supervisor state.
 
 @item Must set stack pointer (sp or r1) such that a minimum stack
-size of MINIMUM_STACK_SIZE bytes is provided for the
-@code{rtems_initialize_executive} directive.
+size of MINIMUM_STACK_SIZE bytes is provided for the RTEMS initialization
+sequence.
 
 @item Must disable all external interrupts (i.e. clear the EI (EE)
 bit of the machine state register).
diff --git a/doc/cpu_supplement/preface.texi b/doc/cpu_supplement/preface.texi
index 75c3e386d9..8184c54bcd 100644
--- a/doc/cpu_supplement/preface.texi
+++ b/doc/cpu_supplement/preface.texi
@@ -7,7 +7,7 @@
 @c
 
 @ifinfo
-@node Preface, ARM Specific Information, Top, Top
+@node Preface, Port Specific Information, Top, Top
 @end ifinfo
 @unnumbered Preface
 
@@ -21,5 +21,35 @@ issues, interrupt processing, exact RTEMS memory requirements,
 performance data, header files, and the assembly language
 interface to the executive.
 
-Each chapter in this document discusses the details of how
-RTEMS was ported.
+Each architecture represents a CPU family and usually there are
+a wide variety of CPU models within it.  These models share a
+common Instruction Set Architecture (ISA) which often varies
+based upon some well-defined rules.  There are often
+multiple implementations of the ISA and these may be from
+one or multiple vendors.
+
+On top of variations in the ISA, there may also be variations
+which occur when a CPU core implementation is combined with
+a set of peripherals to form a system on chip.  For example,
+there are many ARM CPU models from numerous semiconductor
+vendors and a wide variety of peripherals.  But at the
+ISA level, they share a common compaability.
+
+RTEMS depends upon this core similarity across the CPU models
+and leverages that to minimize the source code that is specific
+to any particular CPU core implementation or CPU model.
+
+This manual is separate and distinct from the RTEMS Porting
+Guide.  That manual is a guide on porting RTEMS to a new
+architecture.  This manual is focused on the more mundane
+CPU architecture specific issues that may impact
+application development.  For example, if you need to write
+a subroutine in assembly language, it is critical to understand
+the calling conventions for the target architecture.
+
+The first chapter in this manual describes these issues 
+in general terms.  In a sense, it is posing the questions
+one should be aware may need to be answered and understood
+when porting an RTEMS application to a new architecture. 
+Each subsequent chapter gives the answers to those questions
+for a particular CPU architecture.
diff --git a/doc/cpu_supplement/sh.t b/doc/cpu_supplement/sh.t
index 42b9c24a63..30907a2a34 100644
--- a/doc/cpu_supplement/sh.t
+++ b/doc/cpu_supplement/sh.t
@@ -10,239 +10,84 @@
 @end ifinfo
 @chapter SuperH Specific Information
 
-The Real Time Executive for Multiprocessor Systems (RTEMS)
-is designed to be portable across multiple processor
-architectures.  However, the nature of real-time systems makes
-it essential that the application designer understand certain
-processor dependent implementation details.  These processor
-dependencies include calling convention, board support package
-issues, interrupt processing, exact RTEMS memory requirements,
-performance data, header files, and the assembly language
-interface to the executive.
-
-This document discusses the VENDOR XXX
-architecture dependencies in this port of RTEMS.  The XXX
-family has a wide variety of CPU models within it.  The part 
-numbers ...
-
-XXX fill in some things here
-
-It is highly recommended that the XXX
-RTEMS application developer obtain and become familiar with the
-documentation for the processor being used as well as the
-documentation for the family as a whole.
+This chapter discusses the SuperH architecture dependencies
+in this port of RTEMS.  The SuperH family has a wide variety
+of implementations by a wide range of vendors.  Consequently,
+there are many, many CPU models within it.
+
 
 @subheading Architecture Documents
 
-For information on the XXX architecture,
+For information on the SuperH architecture,
 refer to the following documents available from VENDOR
 (@file{http//www.XXX.com/}):
 
 @itemize @bullet
-@item @cite{XXX Family Reference, VENDOR, PART NUMBER}.
-@end itemize
-
-@subheading MODEL SPECIFIC DOCUMENTS
-
-For information on specific processor models and
-their associated coprocessors, refer to the following documents:
-
-@itemize  @bullet
-@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}.
-@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}.
+@item @cite{SuperH Family Reference, VENDOR, PART NUMBER}.
 @end itemize
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
-
 @section CPU Model Dependent Features
 
-
-Microprocessors are generally classified into
-families with a variety of CPU models or implementations within
-that family.  Within a processor family, there is a high level
-of binary compatibility.  This family may be based on either an
-architectural specification or on maintaining compatibility with
-a popular processor.  Recent microprocessor families such as the
-SPARC or PowerPC are based on an architectural specification
-which is independent or any particular CPU model or
-implementation.  Older families such as the M68xxx and the iX86
-evolved as the manufacturer strived to produce higher
-performance processor models which maintained binary
-compatibility with older models.
-
-RTEMS takes advantage of the similarity of the
-various models within a CPU family.  Although the models do vary
-in significant ways, the high level of compatibility makes it
-possible to share the bulk of the CPU dependent executive code
-across the entire family.  Each processor family supported by
-RTEMS has a list of features which vary between CPU models
-within a family.  For example, the most common model dependent
-feature regardless of CPU family is the presence or absence of a
-floating point unit or coprocessor.  When defining the list of
-features present on a particular CPU model, one simply notes
-that floating point hardware is or is not present and defines a
-single constant appropriately.  Conditional compilation is
-utilized to include the appropriate source code for this CPU
-model's feature set.  It is important to note that this means
-that RTEMS is thus compiled using the appropriate feature set
-and compilation flags optimal for this CPU model used.  The
-alternative would be to generate a binary which would execute on
-all family members using only the features which were always
-present.
-
 This chapter presents the set of features which vary
-across SPARC implementations and are of importance to RTEMS.
+across SuperH implementations and are of importance to RTEMS.
 The set of CPU model feature macros are defined in the file
-cpukit/score/cpu/XXX/XXX.h based upon the particular CPU
-model defined on the compilation command line.
-
-@subsection CPU Model Name
-
-The macro CPU_MODEL_NAME is a string which designates
-the name of this CPU model.  For example, for the MODEL
-processor, this macro is set to the string "XXX".
-
-@subsection Floating Point Unit
-
-The macro XXX_HAS_FPU is set to 1 to indicate that
-this CPU model has a hardware floating point unit and 0
-otherwise.  It does not matter whether the hardware floating
-point support is incorporated on-chip or is an external
-coprocessor.
+@code{cpukit/score/cpu/sh/sh.h} based upon the particular CPU
+model specified on the compilation command line.
 
 @subsection Another Optional Feature
 
 The macro XXX 
+
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Calling Conventions
 
 
-Each high-level language compiler generates
-subroutine entry and exit code based upon a set of rules known
-as the compiler's calling convention.   These rules address the
-following issues:
+@subsection Calling Mechanism
 
-@itemize @bullet
-@item register preservation and usage
-@item parameter passing
-@item call and return mechanism
-@end itemize
+All RTEMS directives are invoked using a @code{XXX}
+instruction and return to the user application via the
+@code{XXX} instruction.
 
-A compiler's calling convention is of importance when
-interfacing to subroutines written in another language either
-assembly or high-level.  Even when the high-level language and
-target processor are the same, different compilers may use
-different calling conventions.  As a result, calling conventions
-are both processor and compiler dependent.
-
-The Hitachi SH architecture supports a simple yet
-effective call and return mechanism.  A subroutine is invoked
-via the branch to subroutine (XXX) or the jump to subroutine
-(XXX) instructions.  These instructions push the return address
-on the current stack.  The return from subroutine (rts)
-instruction pops the return address off the current stack and
-transfers control to that instruction.  It is is important to
-note that the MC68xxx call and return mechanism does not
-automatically save or restore any registers.  It is the
-responsibility of the high-level language compiler to define the
-register preservation and usage convention.
+@subsection Register Usage
 
-@subsection Calling Mechanism
+The SH1 has 16 general registers (r0..r15).
 
-All RTEMS directives are invoked using either a bsr
-or jsr instruction and return to the user application via the
-rts instruction.
+@itemize @bullet
 
-@subsection Register Usage
+@item r0..r3 used as general volatile registers
+
+@item r4..r7 used to pass up to 4 arguments to functions, arguments
+above 4 are
+passed via the stack)
 
-As discussed above, the bsr and jsr instructions do
-not automatically save any registers.  RTEMS uses the registers
-D0, D1, A0, and A1 as scratch registers.  These registers are
-not preserved by RTEMS directives therefore, the contents of
-these registers should not be assumed upon return from any RTEMS
-directive.
+@item r8..13 caller saved registers (i.e. push them to the stack if you
+need them inside of a function)
 
+@item r14 frame pointer
 
-> > The SH1 has 16 general registers (r0..r15)
-> > r0..r3 used as general volatile registers
-> > r4..r7 used to pass up to 4 arguments to functions, arguments above 4 are
-> > passed via the stack)
-> > r8..13 caller saved registers (i.e. push them to the stack if you need them
-> > inside of a function)
-> > r14 frame pointer
-> > r15 stack pointer
->
+@item r15 stack pointer
 
+@end itemize
 
 @subsection Parameter Passing
 
-RTEMS assumes that arguments are placed on the
-current stack before the directive is invoked via the bsr or jsr
-instruction.  The first argument is assumed to be closest to the
-return address on the stack.  This means that the first argument
-of the C calling sequence is pushed last.  The following
-pseudo-code illustrates the typical sequence used to call a
-RTEMS directive with three (3) arguments:
-
-@example
-@group
-push third argument
-push second argument
-push first argument
-invoke directive
-remove arguments from the stack
-@end group
-@end example
-
-The arguments to RTEMS are typically pushed onto the
-stack using a move instruction with a pre-decremented stack
-pointer as the destination.  These arguments must be removed
-from the stack after control is returned to the caller.  This
-removal is typically accomplished by adding the size of the
-argument list in bytes to the current stack pointer.
-
-@subsection User-Provided Routines
-
-All user-provided routines invoked by RTEMS, such as
-user extensions, device drivers, and MPCI routines, must also
-adhere to these calling conventions.
+XXX
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Memory Model
 
-
-A processor may support any combination of memory
-models ranging from pure physical addressing to complex demand
-paged virtual memory systems.  RTEMS supports a flat memory
-model which ranges contiguously over the processor's allowable
-address space.  RTEMS does not support segmentation or virtual
-memory of any kind.  The appropriate memory model for RTEMS
-provided by the targeted processor and related characteristics
-of that model are described in this chapter.
-
 @subsection Flat Memory Model
 
-The XXX family supports a flat 32-bit address
+The SuperH family supports a flat 32-bit address
 space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
 gigabytes).  Each address is represented by a 32-bit value and
 is byte addressable.  The address may be used to reference a
@@ -250,88 +95,34 @@ single byte, word (2-bytes), or long word (4 bytes).  Memory
 accesses within this address space are performed in big endian
 fashion by the processors in this family.
 
-Some of the XXX family members such as the
-XXX, XXX, and XXX support virtual memory and
-segmentation.  The XXX requires external hardware support
-such as the XXX Paged Memory Management Unit coprocessor
-which is typically used to perform address translations for
-these systems.  RTEMS does not support virtual memory or
-segmentation on any of the XXX family members.
+Some of the SuperH family members support virtual memory and
+segmentation.  RTEMS does not support virtual memory or
+segmentation on any of the SuperH family members.  It is the
+responsibility of the BSP to initialize the mapping for
+a flat memory model.
 
 @c
-@c  Interrupt Stack Frame Picture
-@c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Interrupt Processing
 
-
-Different types of processors respond to the
-occurrence of an interrupt in its own unique fashion. In
-addition, each processor type provides a control mechanism to
-allow for the proper handling of an interrupt.  The processor
-dependent response to the interrupt modifies the current
-execution state and results in a change in the execution stream.
-Most processors require that an interrupt handler utilize some
-special control mechanisms to return to the normal processing
-stream.  Although RTEMS hides many of the processor dependent
+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 SH's
+unique architecture. Discussed in this chapter are the MIPS's
 interrupt response and control mechanisms as they pertain to
 RTEMS.
 
 @subsection Vectoring of an Interrupt Handler
 
-Depending on whether or not the particular CPU
-supports a separate interrupt stack, the SH family has two
-different interrupt handling models.
-
-@subsubsection Models Without Separate Interrupt Stacks
-
-Upon receipt of an interrupt the SH family
-members without separate interrupt stacks automatically perform
-the following actions:
-
-@itemize @bullet
-@item To Be Written
-@end itemize
-
-@subsubsection Models With Separate Interrupt Stacks
-
-Upon receipt of an interrupt the SH family
+Upon receipt of an interrupt the XXX family
 members with separate interrupt stacks automatically perform the
 following actions:
 
 @itemize @bullet
-@item saves the current status register (SR),
-
-@item clears the master/interrupt (M) bit of the SR to
-indicate the switch from master state to interrupt state,
-
-@item sets the privilege mode to supervisor,
-
-@item suppresses tracing,
-
-@item sets the interrupt mask level equal to the level of the
-interrupt being serviced,
+@item TBD
 
-@item pushes an interrupt stack frame (ISF), which includes
-the program counter (PC), the status register (SR), and the
-format/exception vector offset (FVO) word, onto the supervisor
-and interrupt stacks,
-
-@item switches the current stack to the interrupt stack and
-vectors to an interrupt service routine (ISR).  If the ISR was
-installed with the interrupt_catch directive, then the RTEMS
-interrupt handler will begin execution.  The RTEMS interrupt
-handler saves all registers which are not preserved according to
-the calling conventions and invokes the application's ISR.
 @end itemize
 
 A nested interrupt is processed similarly by these
@@ -339,238 +130,35 @@ CPU models with the exception that only a single ISF is placed
 on the interrupt stack and the current stack need not be
 switched.
 
-The FVO word in the Interrupt Stack Frame is examined
-by RTEMS to determine when an outer most interrupt is being
-exited. Since the FVO is used by RTEMS for this purpose, the
-user application code MUST NOT modify this field.
-
-The following shows the Interrupt Stack Frame for
-XXX CPU models with separate interrupt stacks:
-
-@ifset use-ascii
-@example
-@group
-               +----------------------+
-               |    Status Register   | 0x0
-               +----------------------+    
-               | Program Counter High | 0x2
-               +----------------------+    
-               | Program Counter Low  | 0x4
-               +----------------------+    
-               | Format/Vector Offset | 0x6
-               +----------------------+    
-@end group
-@end example
-@end ifset
-
-@ifset use-tex
-@sp 1
-@tex
-\centerline{\vbox{\offinterlineskip\halign{
-\strut\vrule#&
-\hbox to 2.00in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 0.50in{\enskip\hfil#\hfil}
-\cr
-\multispan{3}\hrulefill\cr
-& Status Register && 0x0\cr
-\multispan{3}\hrulefill\cr
-& Program Counter High && 0x2\cr
-\multispan{3}\hrulefill\cr
-& Program Counter Low && 0x4\cr
-\multispan{3}\hrulefill\cr
-& Format/Vector Offset && 0x6\cr
-\multispan{3}\hrulefill\cr
-}}\hfil}
-@end tex
-@end ifset
-
-@ifset use-html
-@html
-<CENTER>
-  <TABLE COLS=2 WIDTH="40%" BORDER=2>
-<TR><TD ALIGN=center><STRONG>Status Register</STRONG></TD>
-    <TD ALIGN=center>0x0</TD></TR>
-<TR><TD ALIGN=center><STRONG>Program Counter High</STRONG></TD>
-    <TD ALIGN=center>0x2</TD></TR>
-<TR><TD ALIGN=center><STRONG>Program Counter Low</STRONG></TD>
-    <TD ALIGN=center>0x4</TD></TR>
-<TR><TD ALIGN=center><STRONG>Format/Vector Offset</STRONG></TD>
-    <TD ALIGN=center>0x6</TD></TR>
-  </TABLE>
-</CENTER>
-@end html
-@end ifset
-
 @subsection Interrupt Levels
 
-Eight levels (0-7) of interrupt priorities are
-supported by XXX family members with level seven (7) 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
-XXX family only supports eight.  RTEMS interrupt levels 0
-through 7 directly correspond to XXX interrupt levels.  All
-other RTEMS interrupt levels are undefined and their behavior is
-unpredictable.
-
-@subsection Disabling of Interrupts by RTEMS
-
-During the execution of directive calls, critical
-sections of code may be executed.  When these sections are
-encountered, RTEMS disables interrupts to level seven (7) 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 XXX 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.]
-
-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.
-
-@subsection Interrupt Stack
-
-RTEMS allocates the interrupt stack from the
-Workspace Area.  The amount of memory allocated for the
-interrupt stack is determined by the interrupt_stack_size field
-in the CPU Configuration Table.  During the initialization
-process, RTEMS will install its interrupt stack.
-
-The XXX port of RTEMS supports a software managed
-dedicated interrupt stack on those CPU models which do not
-support a separate interrupt stack in hardware.
-
+TBD
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
-@c
-@c  $Id$
 @c
-
 @section Default Fatal Error Processing
 
-
-Upon detection of a fatal error by either the
-application or RTEMS the fatal error manager is invoked.  The
-fatal error manager will invoke the user-supplied fatal error
-handlers.  If no user-supplied handlers are configured,  the
-RTEMS provided default fatal error handler is invoked.  If the
-user-supplied fatal error handlers return to the executive the
-default fatal error handler is then invoked.  This chapter
-describes the precise operations of the default fatal error
-handler.
-
-@subsection Default Fatal Error Handler Operations
-
-The default fatal error handler which is invoked by
-the @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 processor interrupts,
-places the error code in @b{XXX}, and executes a @code{XXX}
+The default fatal error handler for this architecture disables processor
+interrupts, places the error code in @b{XXX}, and executes a @code{XXX}
 instruction to simulate a halt processor instruction.
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
 @c
-@c  $Id$
 @c
 
 @section Board Support Packages
 
-
-An RTEMS Board Support Package (BSP) must be designed
-to support a particular processor and target board combination.
-This chapter presents a discussion of XXX specific BSP
-issues.   For more information on developing a BSP, refer to the
-chapter titled Board Support Packages in the RTEMS
-Applications User's Guide.
-
 @subsection System Reset
 
 An RTEMS based application is initiated or
-re-initiated when the XXX processor is reset.  When the
-XXX is reset, the processor performs the following actions:
+re-initiated when the processor is reset.  When the
+processor is reset, it performs the following actions:
 
 @itemize @bullet
-@item The tracing bits of the status register are cleared to
-disable tracing.
-
-@item The supervisor interrupt state is entered by setting the
-supervisor (S) bit and clearing the master/interrupt (M) bit of
-the status register.
-
-@item The interrupt mask of the status register is set to
-level 7 to effectively disable all maskable interrupts.
-
-@item The vector base register (VBR) is set to zero.
+@item TBD
 
-@item The cache control register (CACR) is set to zero to
-disable and freeze the processor cache.
-
-@item The interrupt stack pointer (ISP) is set to the value
-stored at vector 0 (bytes 0-3) of the exception vector table
-(EVT).
-
-@item The program counter (PC) is set to the value stored at
-vector 1 (bytes 4-7) of the EVT.
-
-@item The processor begins execution at the address stored in
-the PC.
 @end itemize
 
 @subsection Processor Initialization
 
-The address of the application's initialization code
-should be stored in the first vector of the EVT which will allow
-the immediate vectoring to the application code.  If the
-application requires that the VBR be some value besides zero,
-then it should be set to the required value at this point.  All
-tasks share the same XXX's VBR value.  Because interrupts
-are enabled automatically by RTEMS as part of the initialize
-executive directive, the VBR MUST be set before this directive
-is invoked to insure correct interrupt vectoring.  If processor
-caching 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 Applications User's
-Manual for the reset code which is executed before the call to
-initialize executive, the XXX version has the following
-specific requirements:
-
-@itemize @bullet
-@item Must leave the S bit of the status register set so that
-the XXX remains in the supervisor state.
-
-@item Must set the M bit of the status register to remove the
-XXX from the interrupt state.
-
-@item Must set the master stack pointer (MSP) such that a
-minimum stack size of MINIMUM_STACK_SIZE bytes is provided for
-the initialize executive directive.
-
-@item Must initialize the XXX's vector table.
-@end itemize
-
-Note that the BSP is not responsible for allocating
-or installing the interrupt stack.  RTEMS does this
-automatically as part of initialization.  If the BSP does not
-install an interrupt stack and -- for whatever reason -- an
-interrupt occurs before initialize_executive is invoked, then
-the results are unpredictable.
+TBD