2006-08-23 Joel Sherrill <joel@OARcorp.com>

	* Makefile.am, configure.ac, FAQ/stamp-vti, FAQ/version.texi,
	common/cpright.texi: Merging CPU Supplements into a single document.
	As part of this removed the obsolete and impossible to maintain size
	and timing information.
	* cpu_supplement/.cvsignore, cpu_supplement/Makefile.am,
	cpu_supplement/arm.t, cpu_supplement/i386.t, cpu_supplement/m68k.t,
	cpu_supplement/mips.t, cpu_supplement/powerpc.t,
	cpu_supplement/preface.texi, cpu_supplement/sh.t,
	cpu_supplement/sparc.t, cpu_supplement/tic4x.t: New files.
	* supplements/.cvsignore, supplements/Makefile.am,
	supplements/supplement.am, supplements/arm/.cvsignore,
	supplements/arm/BSP_TIMES, supplements/arm/ChangeLog,
	supplements/arm/Makefile.am, supplements/arm/arm.texi,
	supplements/arm/bsp.t, supplements/arm/callconv.t,
	supplements/arm/cpumodel.t, supplements/arm/cputable.t,
	supplements/arm/fatalerr.t, supplements/arm/intr_NOTIMES.t,
	supplements/arm/memmodel.t, supplements/arm/preface.texi,
	supplements/arm/timeBSP.t, supplements/c4x/.cvsignore,
	supplements/c4x/BSP_TIMES, supplements/c4x/ChangeLog,
	supplements/c4x/Makefile.am, supplements/c4x/bsp.t,
	supplements/c4x/c4x.texi, supplements/c4x/callconv.t,
	supplements/c4x/cpumodel.t, supplements/c4x/cputable.t,
	supplements/c4x/fatalerr.t, supplements/c4x/intr_NOTIMES.t,
	supplements/c4x/memmodel.t, supplements/c4x/preface.texi,
	supplements/c4x/timeBSP.t, supplements/i386/.cvsignore,
	supplements/i386/ChangeLog, supplements/i386/FORCE386_TIMES,
	supplements/i386/Makefile.am, supplements/i386/bsp.t,
	supplements/i386/callconv.t, supplements/i386/cpumodel.t,
	supplements/i386/cputable.t, supplements/i386/fatalerr.t,
	supplements/i386/i386.texi, supplements/i386/intr_NOTIMES.t,
	supplements/i386/memmodel.t, supplements/i386/preface.texi,
	supplements/i386/timeFORCE386.t, supplements/m68k/.cvsignore,
	supplements/m68k/ChangeLog, supplements/m68k/MVME136_TIMES,
	supplements/m68k/Makefile.am, supplements/m68k/bsp.t,
	supplements/m68k/callconv.t, supplements/m68k/cpumodel.t,
	supplements/m68k/cputable.t, supplements/m68k/fatalerr.t,
	supplements/m68k/intr_NOTIMES.t, supplements/m68k/m68k.texi,
	supplements/m68k/memmodel.t, supplements/m68k/preface.texi,
	supplements/m68k/timeMVME136.t, supplements/m68k/timedata.t,
	supplements/mips/.cvsignore, supplements/mips/BSP_TIMES,
	supplements/mips/ChangeLog, supplements/mips/Makefile.am,
	supplements/mips/bsp.t, supplements/mips/callconv.t,
	supplements/mips/cpumodel.t, supplements/mips/cputable.t,
	supplements/mips/fatalerr.t, supplements/mips/intr_NOTIMES.t,
	supplements/mips/memmodel.t, supplements/mips/mips.texi,
	supplements/mips/preface.texi, supplements/mips/timeBSP.t,
	supplements/powerpc/.cvsignore, supplements/powerpc/ChangeLog,
	supplements/powerpc/DMV177_TIMES, supplements/powerpc/Makefile.am,
	supplements/powerpc/PSIM_TIMES, supplements/powerpc/bsp.t,
	supplements/powerpc/callconv.t, supplements/powerpc/cpumodel.t,
	supplements/powerpc/cputable.t, supplements/powerpc/fatalerr.t,
	supplements/powerpc/intr_NOTIMES.t, supplements/powerpc/memmodel.t,
	supplements/powerpc/powerpc.texi, supplements/powerpc/preface.texi,
	supplements/powerpc/timeDMV177.t, supplements/powerpc/timePSIM.t,
	supplements/sh/.cvsignore, supplements/sh/BSP_TIMES,
	supplements/sh/ChangeLog, supplements/sh/Makefile.am,
	supplements/sh/bsp.t, supplements/sh/callconv.t,
	supplements/sh/cpumodel.t, supplements/sh/cputable.t,
	supplements/sh/fatalerr.t, supplements/sh/intr_NOTIMES.t,
	supplements/sh/memmodel.t, supplements/sh/preface.texi,
	supplements/sh/sh.texi, supplements/sh/timeBSP.t,
	supplements/sparc/.cvsignore, supplements/sparc/ChangeLog,
	supplements/sparc/ERC32_TIMES, supplements/sparc/Makefile.am,
	supplements/sparc/bsp.t, supplements/sparc/callconv.t,
	supplements/sparc/cpumodel.t, supplements/sparc/cputable.t,
	supplements/sparc/fatalerr.t, supplements/sparc/intr_NOTIMES.t,
	supplements/sparc/memmodel.t, supplements/sparc/preface.texi,
	supplements/sparc/sparc.texi, supplements/sparc/timeERC32.t,
	supplements/template/.cvsignore, supplements/template/BSP_TIMES,
	supplements/template/ChangeLog, supplements/template/Makefile.am,
	supplements/template/bsp.t, supplements/template/callconv.t,
	supplements/template/cpumodel.t, supplements/template/cputable.t,
	supplements/template/fatalerr.t, supplements/template/intr_NOTIMES.t,
	supplements/template/memmodel.t, supplements/template/preface.texi,
	supplements/template/template.texi, supplements/template/timeBSP.t: Removed.

1 files changed, 0 insertions, 160 deletions

diff --git a/doc/supplements/c4x/memmodel.t b/doc/supplements/c4x/memmodel.t
deleted file mode 100644
index 0f6189ca26..0000000000
--- a/doc/supplements/c4x/memmodel.t
+++ /dev/null
@@ -1,160 +0,0 @@
-@c
-@c  COPYRIGHT (c) 1988-1999.
-@c  On-Line Applications Research Corporation (OAR).
-@c  All rights reserved.
-@c
-@c  $Id$
-@c
-
-@chapter Memory Model
-
-@section Introduction
-
-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.
-
-@section Byte Addressable versus Word Addressable
-
-Processor in the Texas Instruments C3x/C4x family are 
-word addressable.  This is in sharp contrast to CISC and
-RISC processors that are typically byte addressable.  In a word
-addressable architecture, each address points not to an
-8-bit byte or octet but to 32 bits.
-
-On first glance, byte versus word addressability does not
-sound like a problem but in fact, this issue can result in
-subtle problems in high-level language software that is ported
-to a word addressable processor family.  The following is a 
-list of the commonly encountered problems:
-
-@table @b
-
-@item String Optimizations
-Although each character in a string occupies a single address just
-as it does on a byte addressable CPU, each character occupies
-32 rather than 8 bits.  The most significant 24 bytes are 
-of each address are ignored.  This in and of itself does not
-cause problems but it violates the assumption that two 
-adjacent characters in a string have no intervening bits.
-This assumption is often implicit in string and memory comparison
-routines that are optimized to compare 4 adjacent characters
-with a word oriented operation.  This optimization is 
-invalid on word addressable processors.
-
-@item Sizeof
-The C operation @code{sizeof} returns very different results
-on the C3x/C4x than on traditional RISC/CISC processors. 
-The @code{sizeof(char)}, @code{sizeof(short)}, and @code{sizeof(int)}
-are all 1 since each occupies a single addressable unit that is
-thirty-two bits wide.  On most thirty-two bit processors,
-@code{sizeof(char} is one, @code{sizeof(short)} is two,
-and @code{sizeof(int)} is four.  Just as software makes assumptions
-about the sizes of the primitive data types has problems
-when ported to a sixty-four bit architecture, these same
-assumptions cause problems on the C3x/C4x.
-
-@item Alignment
-Since each addressable unit is thirty-two bit wide, there
-are no alignment restrictions.  The native integer type
-need only be aligned on a "one unit" boundary not a "four
-unit" boundary as on numerous other processors.
-
-@end table
-
-@section Flat Memory Model
-
-XXX check actual bits on the various processor families.
-
-The XXX 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
-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.
-
-@section Compiler Memory Models
-
-The Texas Instruments C3x/C4x processors include a Data Page
-(@code{dp}) register that logically is a base address.  The
-@code{dp} register allows the use of shorter offsets in
-instructions.  Up to 64K words may be addressed using
-offsets from the @code{dp} register.  In order to address
-words not addressable based on the current value of
-@code{dp}, the register must be loaded with a different
-value.
-
-The @code{dp} register is managed automatically by
-the high-level language compilers.
-The various compilers for this processor family support
-two memory models that manage the @code{dp} register
-in very different manners.  The large and small memory
-models are discussed in the following sections.
-
-NOTE: The C3x/C4x port of RTEMS has been written
-so that it should support either memory model.
-However, it has only been tested using the
-large memory model.
-
-@subsection Small Memory Model
-
-The small memory model is the simplest and most
-efficient.  However, it includes a limitation that
-make it inappropriate for numerous applications.  The
-small memory model assumes that the application needs
-to access no more than 64K words. Thus the @code{dp} 
-register can be loaded at application start time 
-and never reloaded.  Thus the compiler will not
-even generate instructions to load the @code{dp}.
-
-This can significantly reduce the code space
-required by an application but the application
-is limited in the amount of data it can access.
-
-With the GNU Compiler Suite, small memory model is 
-selected by invoking the compiler with either the 
-@code{-msmall} or @code{-msmallmemoryXXX} argument.
-This argument must be included when linking the application
-in order to ensure that support libraries also compiled
-for the large memory model are used.  
-The default memory model is XXX.
-
-When this memory model is selected, the @code{XXX}
-symbol is predefined by the C and C++ compilers
-and the @code{XXX} symbol is predefined by the assembler.
-This behavior is the same for the GNU and Texas Instruments
-toolsets.  RTEMS uses these predefines to determine the proper handling
-of the @code{dp} register in those C3x/C4x specific routines
-that were written in assembly language.
-
-@subsection Large Memory Model
-
-The large memory model is more complex and less efficient
-than the small memory model.  However, it removes the
-64K uninitialized data restriction from applications.
-The @code{dp} register is reloaded automatically
-by the compiler each time data is accessed.  This leads
-to an increase in the code space requirements for the
-application but gives it access to much more data space.
-
-With the GNU Compiler Suite, large memory model is 
-selected by invoking the compiler with either the 
-@code{-mlarge} or @code{-mlargememoryXXX} argument.
-This argument must be included when linking the application
-in order to ensure that support libraries also compiled
-for the large memory model are used.
-The default memory model is XXX.
-
-When this memory model is selected, the @code{XXX}
-symbol is predefined by the C and C++ compilers
-and the @code{XXX} symbol is predefined by the assembler.
-This behavior is the same for the GNU and Texas Instruments
-toolsets.  RTEMS uses these predefines to determine the proper handling
-of the @code{dp} register in those C3x/C4x specific routines
-that were written in assembly language.