summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--doc/ChangeLog78
-rw-r--r--doc/FAQ/stamp-vti4
-rw-r--r--doc/FAQ/version.texi4
-rw-r--r--doc/Makefile.am2
-rw-r--r--doc/common/cpright.texi4
-rw-r--r--doc/configure.ac11
-rw-r--r--doc/cpu_supplement/.cvsignore28
-rw-r--r--doc/cpu_supplement/Makefile.am81
-rw-r--r--doc/cpu_supplement/arm.t595
-rw-r--r--doc/cpu_supplement/i386.t694
-rw-r--r--doc/cpu_supplement/m68k.t773
-rw-r--r--doc/cpu_supplement/mips.t677
-rw-r--r--doc/cpu_supplement/powerpc.t1043
-rw-r--r--doc/cpu_supplement/preface.texi25
-rw-r--r--doc/cpu_supplement/sh.t685
-rw-r--r--doc/cpu_supplement/sparc.t1127
-rw-r--r--doc/cpu_supplement/tic4x.t888
-rw-r--r--doc/supplements/.cvsignore2
-rw-r--r--doc/supplements/Makefile.am13
-rw-r--r--doc/supplements/arm/.cvsignore31
-rw-r--r--doc/supplements/arm/BSP_TIMES247
-rw-r--r--doc/supplements/arm/ChangeLog83
-rw-r--r--doc/supplements/arm/Makefile.am110
-rw-r--r--doc/supplements/arm/arm.texi115
-rw-r--r--doc/supplements/arm/bsp.t93
-rw-r--r--doc/supplements/arm/callconv.t73
-rw-r--r--doc/supplements/arm/cpumodel.t82
-rw-r--r--doc/supplements/arm/cputable.t109
-rw-r--r--doc/supplements/arm/fatalerr.t37
-rw-r--r--doc/supplements/arm/intr_NOTIMES.t122
-rw-r--r--doc/supplements/arm/memmodel.t38
-rw-r--r--doc/supplements/arm/preface.texi49
-rw-r--r--doc/supplements/arm/timeBSP.t113
-rw-r--r--doc/supplements/c4x/.cvsignore31
-rw-r--r--doc/supplements/c4x/BSP_TIMES247
-rw-r--r--doc/supplements/c4x/ChangeLog49
-rw-r--r--doc/supplements/c4x/Makefile.am108
-rw-r--r--doc/supplements/c4x/bsp.t93
-rw-r--r--doc/supplements/c4x/c4x.texi116
-rw-r--r--doc/supplements/c4x/callconv.t161
-rw-r--r--doc/supplements/c4x/cpumodel.t82
-rw-r--r--doc/supplements/c4x/cputable.t109
-rw-r--r--doc/supplements/c4x/fatalerr.t31
-rw-r--r--doc/supplements/c4x/intr_NOTIMES.t196
-rw-r--r--doc/supplements/c4x/memmodel.t160
-rw-r--r--doc/supplements/c4x/preface.texi64
-rw-r--r--doc/supplements/c4x/timeBSP.t108
-rw-r--r--doc/supplements/i386/.cvsignore31
-rw-r--r--doc/supplements/i386/ChangeLog72
-rw-r--r--doc/supplements/i386/FORCE386_TIMES247
-rw-r--r--doc/supplements/i386/Makefile.am111
-rw-r--r--doc/supplements/i386/bsp.t109
-rw-r--r--doc/supplements/i386/callconv.t90
-rw-r--r--doc/supplements/i386/cpumodel.t72
-rw-r--r--doc/supplements/i386/cputable.t119
-rw-r--r--doc/supplements/i386/fatalerr.t31
-rw-r--r--doc/supplements/i386/i386.texi114
-rw-r--r--doc/supplements/i386/intr_NOTIMES.t168
-rw-r--r--doc/supplements/i386/memmodel.t72
-rw-r--r--doc/supplements/i386/preface.texi41
-rw-r--r--doc/supplements/i386/timeFORCE386.t101
-rw-r--r--doc/supplements/m68k/.cvsignore31
-rw-r--r--doc/supplements/m68k/ChangeLog86
-rw-r--r--doc/supplements/m68k/MVME136_TIMES247
-rw-r--r--doc/supplements/m68k/Makefile.am111
-rw-r--r--doc/supplements/m68k/bsp.t93
-rw-r--r--doc/supplements/m68k/callconv.t92
-rw-r--r--doc/supplements/m68k/cpumodel.t91
-rw-r--r--doc/supplements/m68k/cputable.t109
-rw-r--r--doc/supplements/m68k/fatalerr.t31
-rw-r--r--doc/supplements/m68k/intr_NOTIMES.t266
-rw-r--r--doc/supplements/m68k/m68k.texi115
-rw-r--r--doc/supplements/m68k/memmodel.t39
-rw-r--r--doc/supplements/m68k/preface.texi60
-rw-r--r--doc/supplements/m68k/timeMVME136.t112
-rw-r--r--doc/supplements/m68k/timedata.t154
-rw-r--r--doc/supplements/mips/.cvsignore31
-rw-r--r--doc/supplements/mips/BSP_TIMES247
-rw-r--r--doc/supplements/mips/ChangeLog76
-rw-r--r--doc/supplements/mips/Makefile.am111
-rw-r--r--doc/supplements/mips/bsp.t93
-rw-r--r--doc/supplements/mips/callconv.t92
-rw-r--r--doc/supplements/mips/cpumodel.t68
-rw-r--r--doc/supplements/mips/cputable.t109
-rw-r--r--doc/supplements/mips/fatalerr.t31
-rw-r--r--doc/supplements/mips/intr_NOTIMES.t196
-rw-r--r--doc/supplements/mips/memmodel.t39
-rw-r--r--doc/supplements/mips/mips.texi114
-rw-r--r--doc/supplements/mips/preface.texi57
-rw-r--r--doc/supplements/mips/timeBSP.t112
-rw-r--r--doc/supplements/powerpc/.cvsignore32
-rw-r--r--doc/supplements/powerpc/ChangeLog72
-rw-r--r--doc/supplements/powerpc/DMV177_TIMES248
-rw-r--r--doc/supplements/powerpc/Makefile.am125
-rw-r--r--doc/supplements/powerpc/PSIM_TIMES248
-rw-r--r--doc/supplements/powerpc/bsp.t76
-rw-r--r--doc/supplements/powerpc/callconv.t229
-rw-r--r--doc/supplements/powerpc/cpumodel.t156
-rw-r--r--doc/supplements/powerpc/cputable.t155
-rw-r--r--doc/supplements/powerpc/fatalerr.t47
-rw-r--r--doc/supplements/powerpc/intr_NOTIMES.t184
-rw-r--r--doc/supplements/powerpc/memmodel.t110
-rw-r--r--doc/supplements/powerpc/powerpc.texi115
-rw-r--r--doc/supplements/powerpc/preface.texi94
-rw-r--r--doc/supplements/powerpc/timeDMV177.t113
-rw-r--r--doc/supplements/powerpc/timePSIM.t97
-rw-r--r--doc/supplements/sh/.cvsignore31
-rw-r--r--doc/supplements/sh/BSP_TIMES247
-rw-r--r--doc/supplements/sh/ChangeLog76
-rw-r--r--doc/supplements/sh/Makefile.am111
-rw-r--r--doc/supplements/sh/bsp.t93
-rw-r--r--doc/supplements/sh/callconv.t102
-rw-r--r--doc/supplements/sh/cpumodel.t68
-rw-r--r--doc/supplements/sh/cputable.t109
-rw-r--r--doc/supplements/sh/fatalerr.t31
-rw-r--r--doc/supplements/sh/intr_NOTIMES.t196
-rw-r--r--doc/supplements/sh/memmodel.t39
-rw-r--r--doc/supplements/sh/preface.texi55
-rw-r--r--doc/supplements/sh/sh.texi114
-rw-r--r--doc/supplements/sh/timeBSP.t112
-rw-r--r--doc/supplements/sparc/.cvsignore31
-rw-r--r--doc/supplements/sparc/ChangeLog72
-rw-r--r--doc/supplements/sparc/ERC32_TIMES247
-rw-r--r--doc/supplements/sparc/Makefile.am108
-rw-r--r--doc/supplements/sparc/bsp.t87
-rw-r--r--doc/supplements/sparc/callconv.t392
-rw-r--r--doc/supplements/sparc/cpumodel.t128
-rw-r--r--doc/supplements/sparc/cputable.t102
-rw-r--r--doc/supplements/sparc/fatalerr.t32
-rw-r--r--doc/supplements/sparc/intr_NOTIMES.t199
-rw-r--r--doc/supplements/sparc/memmodel.t104
-rw-r--r--doc/supplements/sparc/preface.texi91
-rw-r--r--doc/supplements/sparc/sparc.texi113
-rw-r--r--doc/supplements/sparc/timeERC32.t120
-rw-r--r--doc/supplements/supplement.am16
-rw-r--r--doc/supplements/template/.cvsignore31
-rw-r--r--doc/supplements/template/BSP_TIMES247
-rw-r--r--doc/supplements/template/ChangeLog76
-rw-r--r--doc/supplements/template/Makefile.am110
-rw-r--r--doc/supplements/template/bsp.t93
-rw-r--r--doc/supplements/template/callconv.t92
-rw-r--r--doc/supplements/template/cpumodel.t68
-rw-r--r--doc/supplements/template/cputable.t109
-rw-r--r--doc/supplements/template/fatalerr.t31
-rw-r--r--doc/supplements/template/intr_NOTIMES.t196
-rw-r--r--doc/supplements/template/memmodel.t39
-rw-r--r--doc/supplements/template/preface.texi55
-rw-r--r--doc/supplements/template/template.texi115
-rw-r--r--doc/supplements/template/timeBSP.t112
149 files changed, 6702 insertions, 13981 deletions
diff --git a/doc/ChangeLog b/doc/ChangeLog
index 08bc850ad5..df17b1c2d2 100644
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -1,3 +1,81 @@
+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.
+
2006-01-20 Ralf Corsepius <ralf.corsepius@rtems.org>
* user/rtemsarc.gif, user/states.gif, user/rtemspie.gif:
diff --git a/doc/FAQ/stamp-vti b/doc/FAQ/stamp-vti
index 576aa38173..e9b27c6743 100644
--- a/doc/FAQ/stamp-vti
+++ b/doc/FAQ/stamp-vti
@@ -1,4 +1,4 @@
@set UPDATED 5 March 2004
@set UPDATED-MONTH March 2004
-@set EDITION 4.6.99.2
-@set VERSION 4.6.99.2
+@set EDITION 4.6.99.3
+@set VERSION 4.6.99.3
diff --git a/doc/FAQ/version.texi b/doc/FAQ/version.texi
index 576aa38173..e9b27c6743 100644
--- a/doc/FAQ/version.texi
+++ b/doc/FAQ/version.texi
@@ -1,4 +1,4 @@
@set UPDATED 5 March 2004
@set UPDATED-MONTH March 2004
-@set EDITION 4.6.99.2
-@set VERSION 4.6.99.2
+@set EDITION 4.6.99.3
+@set VERSION 4.6.99.3
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 237b956b19..412a1e976a 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -9,7 +9,7 @@ ACLOCAL_AMFLAGS = -I ../aclocal
SUBDIRS = tools FAQ started user bsp_howto porting develenv posix_users \
posix1003.1 filesystem itron3.0 networking ada_user started_ada \
- rtems_gdb rgdb_specs new_chapters relnotes supplements gnu_docs
+ rtems_gdb rgdb_specs new_chapters relnotes cpu_supplement gnu_docs
if USE_HTML
html_DATA = index.html HELP.html
diff --git a/doc/common/cpright.texi b/doc/common/cpright.texi
index 8a93b9eefe..1d1be2f8bf 100644
--- a/doc/common/cpright.texi
+++ b/doc/common/cpright.texi
@@ -1,5 +1,5 @@
@c
-@c COPYRIGHT (c) 1988-2002.
+@c COPYRIGHT (c) 1988-2006.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -17,7 +17,7 @@
@end tex
@vskip 0pt plus 1filll
-COPYRIGHT @copyright{} 1988 - 2003.@*
+COPYRIGHT @copyright{} 1988 - 2006.@*
On-Line Applications Research Corporation (OAR).@*
The authors have used their best efforts in preparing
diff --git a/doc/configure.ac b/doc/configure.ac
index 4c6a67c9aa..e875e31a13 100644
--- a/doc/configure.ac
+++ b/doc/configure.ac
@@ -214,16 +214,7 @@ rtems_gdb/Makefile
rgdb_specs/Makefile
relnotes/Makefile
new_chapters/Makefile
-supplements/Makefile
-supplements/arm/Makefile
-supplements/c4x/Makefile
-supplements/i386/Makefile
-supplements/m68k/Makefile
-supplements/mips/Makefile
-supplements/powerpc/Makefile
-supplements/sh/Makefile
-supplements/sparc/Makefile
-supplements/template/Makefile
+cpu_supplement/Makefile
gnu_docs/Makefile
])
AC_OUTPUT
diff --git a/doc/cpu_supplement/.cvsignore b/doc/cpu_supplement/.cvsignore
new file mode 100644
index 0000000000..19d01d9c94
--- /dev/null
+++ b/doc/cpu_supplement/.cvsignore
@@ -0,0 +1,28 @@
+cpu_supplement
+cpu_supplement-?
+cpu_supplement-??
+cpu_supplement.aux
+cpu_supplement.cp
+cpu_supplement.cps
+cpu_supplement.dvi
+cpu_supplement.fn
+cpu_supplement.fns
+cpu_supplement*.html
+cpu_supplement.ky
+cpu_supplement.log
+cpu_supplement.pdf
+cpu_supplement.pg
+cpu_supplement.ps
+cpu_supplement.toc
+cpu_supplement.tp
+cpu_supplement.vr
+index.html
+Makefile
+Makefile.in
+mdate-sh
+rtems_footer.html
+rtems_header.html
+rtemspie.pdf
+stamp-vti
+states.pdf
+version.texi
diff --git a/doc/cpu_supplement/Makefile.am b/doc/cpu_supplement/Makefile.am
new file mode 100644
index 0000000000..02d5be27af
--- /dev/null
+++ b/doc/cpu_supplement/Makefile.am
@@ -0,0 +1,81 @@
+#
+# COPYRIGHT (c) 1988-2002.
+# On-Line Applications Research Corporation (OAR).
+# All rights reserved.
+#
+# $Id$
+#
+
+PROJECT = cpu_supplement
+EDITION = 1
+
+include $(top_srcdir)/project.am
+
+REPLACE2 = $(PERL) $(top_srcdir)/tools/word-replace2
+
+html_projectdir = $(htmldir)/$(PROJECT)
+
+TEXI2WWW_ARGS=\
+-I $(srcdir) -I $(top_srcdir) -I $(top_builddir) \
+-dirfile ../index.html \
+-header rtems_header.html \
+-footer rtems_footer.html \
+-icons ../images
+GENERATED_FILES = arm.texi i386.texi m68k.texi mips.texi powerpc.texi \
+ sh.texi sparc.texi tic4x.texi
+
+COMMON_FILES += $(top_srcdir)/common/cpright.texi
+
+FILES = preface.texi
+
+info_TEXINFOS = cpu_supplement.texi
+cpu_supplement_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
+
+#
+# Chapters which get automatic processing
+#
+
+arm.texi: arm.t
+ $(BMENU2) -p "Preface" \
+ -u "Top" \
+ -n "" < $< > $@
+
+i386.texi: i386.t
+ $(BMENU2) -p "" \
+ -u "Top" \
+ -n "" < $< > $@
+
+m68k.texi: m68k.t
+ $(BMENU2) -p "" \
+ -u "Top" \
+ -n "" < $< > $@
+
+mips.texi: mips.t
+ $(BMENU2) -p "" \
+ -u "Top" \
+ -n "" < $< > $@
+
+powerpc.texi: powerpc.t
+ $(BMENU2) -p "" \
+ -u "Top" \
+ -n "" < $< > $@
+
+sh.texi: sh.t
+ $(BMENU2) -p "" \
+ -u "Top" \
+ -n "" < $< > $@
+
+sparc.texi: sparc.t
+ $(BMENU2) -p "" \
+ -u "Top" \
+ -n "" < $< > $@
+
+tic4x.texi: tic4x.t
+ $(BMENU2) -p "" \
+ -u "Top" \
+ -n "" < $< > $@
+
+CLEANFILES += cpu_supplement.info
+CLEANFILES += cpu_supplement.info-1
+CLEANFILES += cpu_supplement.info-2
+
diff --git a/doc/cpu_supplement/arm.t b/doc/cpu_supplement/arm.t
new file mode 100644
index 0000000000..91e9f23286
--- /dev/null
+++ b/doc/cpu_supplement/arm.t
@@ -0,0 +1,595 @@
+@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 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
+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.
+
+@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:
+
+@itemize @bullet
+@item @cite{David Seal. "ARM Architecture Reference Manual."
+Addison-Wesley. @b{ISBN 0-201-73719-1}. 2001.}
+
+@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
+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
+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.
+
+@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:
+
+@example
+__ARM_ARCH4__ "ARMv4"
+__ARM_ARCH4T__ "ARMv4T"
+__ARM_ARCH5__ "ARMv5"
+__ARM_ARCH5T__ "ARMv5T"
+__ARM_ARCH5E__ "ARMv5E"
+__ARM_ARCH5TE__ "ARMv5TE"
+@end example
+
+@subsection Count Leading Zeroes Instruction
+
+The ARMv5 and later has the count leading zeroes (@code{clz})
+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 ARM_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.
+
+@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.
+
+@subsection Calling Mechanism
+
+All RTEMS directives are invoked using the @code{bl}
+instruction and return to the user application via the
+mechanism described above.
+
+@subsection Register Usage
+
+As discussed above, the ARM's call and return mechanism dos
+not automatically save any registers. RTEMS uses the registers
+@code{r0}, @code{r1}, @code{r2}, and @code{r3} as scratch registers and
+per ARM calling convention, the @code{lr} register is altered
+as well. 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 ARM calling conventions are followed and that
+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.
+
+@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 ARM's
+interrupt response and control mechanisms as they pertain to
+RTEMS.
+
+The ARM has 7 exception types:
+@itemize @bullet
+
+@item Reset
+@item Undefined instruction
+@item Software interrupt (SWI)
+@item Prefetch Abort
+@item Data Abort
+@item Interrupt (IRQ)
+@item Fast Interrupt (FIQ)
+
+@end itemize
+
+Of these types, only IRQ and FIQ are handled through RTEMS's interrupt
+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:
+
+@itemize @bullet
+@item switches to the exception mode corresponding to the interrupt,
+
+@item saves the Current Processor Status Register (CPSR) to the
+exception mode's Saved Processor Status Register (SPSR),
+
+@item masks off the IRQ and if the interrupt source was FIQ, the FIQ
+is masked off as well,
+
+@item saves the Program Counter (PC) to the exception mode's Link
+Register (LR - same as R14),
+
+@item and sets the PC to the exception's vector address.
+
+@end itemize
+
+The vectors for both IRQ and FIQ point to the _ISR_Handler function.
+_ISR_Handler() calls the BSP specific handler, ExecuteITHandler(). Before
+calling ExecuteITHandler(), registers R0-R3, R12, and R14(LR) are saved so
+that it is safe to call C functions. Even ExecuteITHandler() can be written
+in C.
+
+@subsection Interrupt Levels
+
+The ARM architecture supports two external interrupts - IRQ and FIQ. FIQ
+has a higher priority than IRQ, and has its own version of register R8 - R14,
+however RTEMS does not take advantage of them. Both interrupts are enabled
+through the CPSR.
+
+The RTEMS interrupt level mapping scheme for the AEM is not a numeric level
+as on most RTEMS ports. It is a bit mapping that corresponds the enable
+bits's postions in the CPSR:
+
+@table @b
+@item FIQ
+Setting bit 6 (0 is least significant bit) disables the FIQ.
+
+@item IRQ
+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
+following actions:
+
+@itemize @bullet
+@item disables processor interrupts,
+@item places the error code in @b{r0}, and
+@item executes an infinite loop (@code{while(0);} to
+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:
+
+@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 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.
+
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Processor Dependent Information Table
+
+
+Any highly processor dependent information required
+to describe a processor to RTEMS is provided in the CPU
+Dependent Information Table. This table is not required for all
+processors supported by RTEMS. This chapter describes the
+contents, if any, for a particular processor type.
+
+@subsection CPU Dependent Information Table
+
+The XXX version of the RTEMS CPU Dependent
+Information Table contains the information required to interface
+a Board Support Package and RTEMS on the XXX. This
+information is provided to allow RTEMS to interoperate
+effectively with the BSP. The C structure definition is given
+here:
+
+@example
+@group
+typedef struct @{
+ void (*pretasking_hook)( void );
+ void (*predriver_hook)( void );
+ void (*postdriver_hook)( void );
+ void (*idle_task)( void );
+ boolean do_zero_of_workspace;
+ unsigned32 idle_task_stack_size;
+ unsigned32 interrupt_stack_size;
+ unsigned32 extra_mpci_receive_server_stack;
+ void * (*stack_allocate_hook)( unsigned32 );
+ void (*stack_free_hook)( void* );
+ /* end of fields required on all CPUs */
+
+ /* XXX CPU family dependent stuff */
+@} rtems_cpu_table;
+@end group
+@end example
+
+@table @code
+@item pretasking_hook
+is the address of the user provided routine which is invoked
+once RTEMS APIs are initialized. This routine will be invoked
+before any system tasks are created. Interrupts are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item predriver_hook
+is the address of the user provided
+routine that is invoked immediately before the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item postdriver_hook
+is the address of the user provided
+routine that is invoked immediately after the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item idle_task
+is the address of the optional user
+provided routine which is used as the system's IDLE task. If
+this field is not NULL, then the RTEMS default IDLE task is not
+used. This field may be NULL to indicate that the default IDLE
+is to be used.
+
+@item do_zero_of_workspace
+indicates whether RTEMS should
+zero the Workspace as part of its initialization. If set to
+TRUE, the Workspace is zeroed. Otherwise, it is not.
+
+@item idle_task_stack_size
+is the size of the RTEMS idle task stack in bytes.
+If this number is less than MINIMUM_STACK_SIZE, then the
+idle task's stack will be MINIMUM_STACK_SIZE in byte.
+
+@item interrupt_stack_size
+is the size of the RTEMS
+allocated interrupt stack in bytes. This value must be at least
+as large as MINIMUM_STACK_SIZE.
+
+@item extra_mpci_receive_server_stack
+is the extra stack space allocated for the RTEMS MPCI receive server task
+in bytes. The MPCI receive server may invoke nearly all directives and
+may require extra stack space on some targets.
+
+@item stack_allocate_hook
+is the address of the optional user provided routine which allocates
+memory for task stacks. If this hook is not NULL, then a stack_free_hook
+must be provided as well.
+
+@item stack_free_hook
+is the address of the optional user provided routine which frees
+memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
+must be provided as well.
+
+@item XXX
+is where the CPU family dependent stuff goes.
+
+@end table
diff --git a/doc/cpu_supplement/i386.t b/doc/cpu_supplement/i386.t
new file mode 100644
index 0000000000..1b153dd240
--- /dev/null
+++ b/doc/cpu_supplement/i386.t
@@ -0,0 +1,694 @@
+@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 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.
+
+For information on the i386 processor, refer to the
+following documents:
+
+@itemize @bullet
+@item @cite{386 Programmer's Reference Manual, Intel, Order No. 230985-002}.
+
+@item @cite{386 Microprocessor Hardware Reference Manual, Intel,
+Order No. 231732-003}.
+
+@item @cite{80386 System Software Writer's Guide, Intel, Order No. 231499-001}.
+
+@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
+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".
+
+@subsection bswap Instruction
+
+The macro 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
+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
+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 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.
+
+@subsection Parameter Passing
+
+RTEMS assumes that arguments are placed on the
+current stack before the directive is invoked via the call
+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
+push third argument
+push second argument
+push first argument
+invoke directive
+remove arguments from the stack
+@end example
+
+The arguments to RTEMS are typically pushed onto the
+stack using a push instruction. 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 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
+model with paging disabled. In this mode, the i386
+automatically converts every address from a logical to a
+physical address each time it is used. The i386 uses
+information provided in the segment registers and the Global
+Descriptor Table to convert these addresses. RTEMS assumes the
+existence of the following segments:
+
+@itemize @bullet
+@item a single code segment at protection level (0) which
+contains all application and executive code.
+
+@item a single data segment at protection level zero (0) which
+contains all application and executive data.
+@end itemize
+
+The i386 segment registers and associated selectors
+must be initialized when the initialize_executive directive is
+invoked. RTEMS treats the segment registers as system registers
+and does not modify or context switch them.
+
+This i386 memory model 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, 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
+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 the processor's response and control mechanisms as they
+pertain to RTEMS.
+
+@subsection Vectoring of Interrupt Handler
+
+Although the i386 supports multiple privilege levels,
+RTEMS and all user software executes at privilege level 0. This
+decision was made by the RTEMS designers to enhance
+compatibility with processors which do not provide sophisticated
+protection facilities like those of the i386. This decision
+greatly simplifies the discussion of i386 processing, as one
+need only consider interrupts without privilege transitions.
+
+Upon receipt of an interrupt the i386 automatically
+performs the following actions:
+
+@itemize @bullet
+@item pushes the EFLAGS register
+
+@item pushes the far address of the interrupted instruction
+
+@item vectors to the interrupt service routine (ISR).
+@end itemize
+
+A nested interrupt is processed similarly by the
+i386.
+
+@subsection Interrupt Stack Frame
+
+The structure of the Interrupt Stack Frame for the
+i386 which is placed on the interrupt stack by the processor in
+response to an interrupt is as follows:
+
+@ifset use-ascii
+@example
+@group
+ +----------------------+
+ | Old EFLAGS Register | ESP+8
+ +----------+-----------+
+ | UNUSED | Old CS | ESP+4
+ +----------+-----------+
+ | Old EIP | ESP
+ +----------------------+
+@end group
+@end example
+@end ifset
+
+@ifset use-tex
+@sp 1
+@tex
+\centerline{\vbox{\offinterlineskip\halign{
+\strut\vrule#&
+\hbox to 1.00in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.00in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 0.75in{\enskip\hfil#\hfil}
+\cr
+\multispan{4}\hrulefill\cr
+& \multispan{3} Old EFLAGS Register\quad&&ESP+8\cr
+\multispan{4}\hrulefill\cr
+&UNUSED &&Old CS &&ESP+4\cr
+\multispan{4}\hrulefill\cr
+& \multispan{3} Old EIP && ESP\cr
+\multispan{4}\hrulefill\cr
+}}\hfil}
+@end tex
+@end ifset
+
+@ifset use-html
+@html
+<CENTER>
+ <TABLE COLS=3 WIDTH="40%" BORDER=2>
+<TR><TD ALIGN=center COLSPAN=2><STRONG>Old EFLAGS Register</STRONG></TD>
+ <TD ALIGN=center>0x0</TD></TR>
+<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD>
+ <TD ALIGN=center><STRONG>Old CS</STRONG></TD>
+ <TD ALIGN=center>0x2</TD></TR>
+<TR><TD ALIGN=center COLSPAN=2><STRONG>Old EIP</STRONG></TD>
+ <TD ALIGN=center>0x4</TD></TR>
+ </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+@subsection Interrupt Levels
+
+Although RTEMS supports 256 interrupt levels, the
+i386 only supports two -- enabled and disabled. Interrupts are
+enabled when the interrupt-enable flag (IF) in the extended
+flags (EFLAGS) is set. Conversely, interrupt processing is
+inhibited when the IF is cleared. During a non-maskable
+interrupt, all other interrupts, including other non-maskable
+ones, are inhibited.
+
+RTEMS interrupt levels 0 and 1 such that level zero
+(0) indicates that interrupts are fully enabled and level one
+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
+interrupt stack. On this processor, RTEMS allocates and manages
+a dedicated interrupt stack. As part of vectoring a non-nested
+interrupt service routine, RTEMS switches from the stack of the
+interrupted task to a dedicated interrupt stack. When a
+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.
+
+@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,
+
+@itemize @bullet
+
+@item The EAX register is set to indicate the results of the processor's
+power-up self test. If the self-test was not executed, the contents of
+this register are undefined. Otherwise, a non-zero value indicates the
+processor is faulty and a zero value indicates a successful self-test.
+
+@item The DX register holds a component identifier and revision level. DH
+contains 3 to indicate an i386 component and DL contains a unique revision
+level indicator.
+
+@item Control register zero (CR0) is set such that the processor is in real
+mode with paging disabled. Other portions of CR0 are used to indicate the
+presence of a numeric coprocessor.
+
+@item All bits in the extended flags register (EFLAG) which are not
+permanently set are cleared. This inhibits all maskable interrupts.
+
+@item The Interrupt Descriptor Register (IDTR) is set to point at address
+zero.
+
+@item All segment registers are set to zero.
+
+@item The instruction pointer is set to 0x0000FFF0. The first instruction
+executed after a reset is actually at 0xFFFFFFF0 because the i386 asserts
+the upper twelve address until the first intersegment (FAR) JMP or CALL
+instruction. When a JMP or CALL is executed, the upper twelve address
+lines are lowered and the processor begins executing in the first megabyte
+of memory.
+
+@end itemize
+
+Typically, an intersegment JMP to the application's initialization code is
+placed at address 0xFFFFFFF0.
+
+@subsection Processor Initialization
+
+This initialization code is responsible for initializing all data
+structures required by the i386 in protected mode and for actually entering
+protected mode. The i386 must be placed in protected mode and the segment
+registers and associated selectors must be initialized before the
+initialize_executive directive is invoked.
+
+The initialization code is responsible for initializing the Global
+Descriptor Table such that the i386 is in the thirty-two bit flat memory
+model with paging disabled. In this mode, the i386 automatically converts
+every address from a logical to a physical address each time it is used.
+For more information on the memory model used by RTEMS, please refer to the
+Memory Model chapter in this document.
+
+Since the processor is in real mode upon reset, the processor must be
+switched to protected mode before RTEMS can execute. Before switching to
+protected mode, at least one descriptor table and two descriptors must be
+created. Descriptors are needed for a code segment and a data segment. (
+This will give you the flat memory model.) The stack can be placed in a
+normal read/write data segment, so no descriptor for the stack is needed.
+Before the GDT can be used, the base address and limit must be loaded into
+the GDTR register using an LGDT instruction.
+
+If the hardware allows an NMI to be generated, you need to create the IDT
+and a gate for the NMI interrupt handler. Before the IDT can be used, the
+base address and limit for the idt must be loaded into the IDTR register
+using an LIDT instruction.
+
+Protected mode is entered by setting thye PE bit in the CR0 register.
+Either a LMSW or MOV CR0 instruction may be used to set this bit. Because
+the processor overlaps the interpretation of several instructions, it is
+necessary to discard the instructions from the read-ahead cache. A JMP
+instruction immediately after the LMSW changes the flow and empties the
+processor if intructions which have been pre-fetched and/or decoded. At
+this point, the processor is in protected mode and begins to perform
+protected mode application initialization.
+
+If the application requires that the IDTR be some value besides zero, then
+it should set it to the required value at this point. All tasks share the
+same i386 IDTR value. Because interrupts are enabled automatically by
+RTEMS as part of the initialize_executive directive, the IDTR MUST be set
+properly 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 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
+contents, refer to 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 Processor Dependent Information Table
+
+
+Any highly processor dependent information required
+to describe a processor to RTEMS is provided in the CPU
+Dependent Information Table. This table is not required for all
+processors supported by RTEMS. This chapter describes the
+contents, if any, for a particular processor type.
+
+@subsection CPU Dependent Information Table
+
+The i386 version of the RTEMS CPU Dependent
+Information Table contains the information required to interface
+a Board Support Package and RTEMS on the i386. This information
+is provided to allow RTEMS to interoperate effectively with the
+BSP. The C structure definition is given here:
+
+@example
+@group
+typedef struct @{
+ void (*pretasking_hook)( void );
+ void (*predriver_hook)( void );
+ void (*idle_task)( void );
+ boolean do_zero_of_workspace;
+ unsigned32 idle_task_stack_size;
+ unsigned32 interrupt_stack_size;
+ unsigned32 extra_mpci_receive_server_stack;
+ void * (*stack_allocate_hook)( unsigned32 );
+ void (*stack_free_hook)( void* );
+ /* end of fields required on all CPUs */
+
+ unsigned32 interrupt_segment;
+ void *interrupt_vector_table;
+@} rtems_cpu_table;
+@end group
+@end example
+
+@table @code
+@item pretasking_hook
+is the address of the user provided routine which is invoked
+once RTEMS APIs are initialized. This routine will be invoked
+before any system tasks are created. Interrupts are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item predriver_hook
+is the address of the user provided
+routine that is invoked immediately before the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item postdriver_hook
+is the address of the user provided
+routine that is invoked immediately after the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item idle_task
+is the address of the optional user
+provided routine which is used as the system's IDLE task. If
+this field is not NULL, then the RTEMS default IDLE task is not
+used. This field may be NULL to indicate that the default IDLE
+is to be used.
+
+@item do_zero_of_workspace
+indicates whether RTEMS should
+zero the Workspace as part of its initialization. If set to
+TRUE, the Workspace is zeroed. Otherwise, it is not.
+
+@item idle_task_stack_size
+is the size of the RTEMS idle task stack in bytes.
+If this number is less than MINIMUM_STACK_SIZE, then the
+idle task's stack will be MINIMUM_STACK_SIZE in byte.
+
+@item interrupt_stack_size
+is the size of the RTEMS
+allocated interrupt stack in bytes. This value must be at least
+as large as MINIMUM_STACK_SIZE.
+
+@item extra_mpci_receive_server_stack
+is the extra stack space allocated for the RTEMS MPCI receive server task
+in bytes. The MPCI receive server may invoke nearly all directives and
+may require extra stack space on some targets.
+
+@item stack_allocate_hook
+is the address of the optional user provided routine which allocates
+memory for task stacks. If this hook is not NULL, then a stack_free_hook
+must be provided as well.
+
+@item stack_free_hook
+is the address of the optional user provided routine which frees
+memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
+must be provided as well.
+
+@item interrupt_segment
+is the value of the selector which should be placed in a segment
+register to access the Interrupt Descriptor Table.
+
+@item interrupt_vector_table
+is the base address of the Interrupt Descriptor Table relative to the
+interrupt_segment.
+
+@end table
+
+The contents of the i386 Interrupt Descriptor Table
+are discussed in Intel's i386 User's Manual. Structure
+definitions for the i386 IDT is provided by including the file
+rtems.h.
+
diff --git a/doc/cpu_supplement/m68k.t b/doc/cpu_supplement/m68k.t
new file mode 100644
index 0000000000..d684328277
--- /dev/null
+++ b/doc/cpu_supplement/m68k.t
@@ -0,0 +1,773 @@
+@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 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
+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/}):
+
+@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}.
+@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.
+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.
+
+@subsection BFFFO Instruction
+
+The macro 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
+this CPU model has a vector base register (vbr).
+
+@subsection Separate Stacks
+
+The macro 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
+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
+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.
+
+@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.
+
+@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.
+
+@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.
+
+@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
+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.
+
+Some of the MC68xxx family members such as the
+MC68020, MC68030, and MC68040 support virtual memory and
+segmentation. The MC68020 requires external hardware support
+such as the MC68851 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 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.
+
+@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.
+
+@subsubsection Models Without Separate Interrupt Stacks
+
+Upon receipt of an interrupt the MC68xxx 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 MC68xxx 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 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
+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
+MC68xxx 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 CPU Models Without VBR and RAM at 0
+
+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.
+
+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
+//
+// Real vector table at 0
+//
+
+ .long initial_sp
+ .long initial_pc
+ .long myhandler+0x02000000
+ .long myhandler+0x03000000
+ .long myhandler+0x04000000
+ ...
+ .long myhandler+0xff000000
+
+
+//
+// This handler will jump to the interrupt routine of which
+// the address is stored at VBR[ vector_no ]
+// The registers and stackframe will be intact, the interrupt
+// routine will see exactly what it would see if it was called
+// directly from the HW vector table at 0.
+//
+
+ .comm VBR,4,2 // This defines the 'virtual' VBR
+ // From C: extern void *VBR;
+
+myhandler: // At entry, PC contains the full vector
+ move.l %d0,-(%sp) // Save d0
+ move.l %a0,-(%sp) // Save a0
+ lea 0(%pc),%a0 // Get the value of the PC
+ move.l %a0,%d0 // Copy it to a data reg, d0 is VV??????
+ swap %d0 // Now d0 is ????VV??
+ and.w #0xff00,%d0 // Now d0 is ????VV00 (1)
+ lsr.w #6,%d0 // Now d0.w contains the VBR table offset
+ move.l VBR,%a0 // Get the address from VBR to a0
+ move.l (%a0,%d0.w),%a0 // Fetch the vector
+ move.l 4(%sp),%d0 // Restore d0
+ move.l %a0,4(%sp) // Place target address to the stack
+ move.l (%sp)+,%a0 // Restore a0, target address is on TOS
+ ret // This will jump to the handler and
+ // restore the stack
+
+(1) If 'myhandler' is guaranteed to be in the first 64K, e.g. just
+ after the vector table then that insn is not needed.
+
+@end example
+
+There are probably shorter ways to do this, but it I believe is enough
+to illustrate the trick. Optimisation is left as an exercise to the
+reader :-)
+
+
+@subsection Interrupt Levels
+
+Eight levels (0-7) of interrupt priorities are
+supported by MC68xxx 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
+MC68xxx family only supports eight. RTEMS interrupt levels 0
+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.
+
+@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:
+
+@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 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 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.
+
+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 MC68020 version has the following
+specific requirements:
+
+@itemize @bullet
+@item Must leave the S bit of the status register set so that
+the MC68020 remains in the supervisor state.
+
+@item Must set the M bit of the status register to remove the
+MC68020 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 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.
+
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Processor Dependent Information Table
+
+
+Any highly processor dependent information required
+to describe a processor to RTEMS is provided in the CPU
+Dependent Information Table. This table is not required for all
+processors supported by RTEMS. This chapter describes the
+contents, if any, for a particular processor type.
+
+@subsection CPU Dependent Information Table
+
+The MC68xxx version of the RTEMS CPU Dependent
+Information Table contains the information required to interface
+a Board Support Package and RTEMS on the MC68xxx. This
+information is provided to allow RTEMS to interoperate
+effectively with the BSP. The C structure definition is given
+here:
+
+@example
+@group
+typedef struct @{
+ void (*pretasking_hook)( void );
+ void (*predriver_hook)( void );
+ void (*postdriver_hook)( void );
+ void (*idle_task)( void );
+ boolean do_zero_of_workspace;
+ unsigned32 idle_task_stack_size;
+ unsigned32 interrupt_stack_size;
+ unsigned32 extra_mpci_receive_server_stack;
+ void * (*stack_allocate_hook)( unsigned32 );
+ void (*stack_free_hook)( void* );
+ /* end of fields required on all CPUs */
+
+ m68k_isr *interrupt_vector_table;
+@} rtems_cpu_table;
+@end group
+@end example
+
+@table @code
+@item pretasking_hook
+is the address of the user provided routine which is invoked
+once RTEMS APIs are initialized. This routine will be invoked
+before any system tasks are created. Interrupts are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item predriver_hook
+is the address of the user provided
+routine that is invoked immediately before the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item postdriver_hook
+is the address of the user provided
+routine that is invoked immediately after the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item idle_task
+is the address of the optional user
+provided routine which is used as the system's IDLE task. If
+this field is not NULL, then the RTEMS default IDLE task is not
+used. This field may be NULL to indicate that the default IDLE
+is to be used.
+
+@item do_zero_of_workspace
+indicates whether RTEMS should
+zero the Workspace as part of its initialization. If set to
+TRUE, the Workspace is zeroed. Otherwise, it is not.
+
+@item idle_task_stack_size
+is the size of the RTEMS idle task stack in bytes.
+If this number is less than MINIMUM_STACK_SIZE, then the
+idle task's stack will be MINIMUM_STACK_SIZE in byte.
+
+@item interrupt_stack_size
+is the size of the RTEMS
+allocated interrupt stack in bytes. This value must be at least
+as large as MINIMUM_STACK_SIZE.
+
+@item extra_mpci_receive_server_stack
+is the extra stack space allocated for the RTEMS MPCI receive server task
+in bytes. The MPCI receive server may invoke nearly all directives and
+may require extra stack space on some targets.
+
+@item stack_allocate_hook
+is the address of the optional user provided routine which allocates
+memory for task stacks. If this hook is not NULL, then a stack_free_hook
+must be provided as well.
+
+@item stack_free_hook
+is the address of the optional user provided routine which frees
+memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
+must be provided as well.
+
+@item interrupt_vector_table
+is the base address of the CPU's Exception Vector Table.
+
+@end table
diff --git a/doc/cpu_supplement/mips.t b/doc/cpu_supplement/mips.t
new file mode 100644
index 0000000000..2fae46ecc2
--- /dev/null
+++ b/doc/cpu_supplement/mips.t
@@ -0,0 +1,677 @@
+@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 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.
+
+@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/}):
+
+@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.
+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.
+
+@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.
+
+@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.
+
+@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.
+
+@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.
+
+@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
+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.
+
+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.
+
+@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 XXX'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 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
+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.
+
+
+@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.
+
+@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:
+
+@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 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.
+
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Processor Dependent Information Table
+
+
+Any highly processor dependent information required
+to describe a processor to RTEMS is provided in the CPU
+Dependent Information Table. This table is not required for all
+processors supported by RTEMS. This chapter describes the
+contents, if any, for a particular processor type.
+
+@subsection CPU Dependent Information Table
+
+The XXX version of the RTEMS CPU Dependent
+Information Table contains the information required to interface
+a Board Support Package and RTEMS on the XXX. This
+information is provided to allow RTEMS to interoperate
+effectively with the BSP. The C structure definition is given
+here:
+
+@example
+@group
+typedef struct @{
+ void (*pretasking_hook)( void );
+ void (*predriver_hook)( void );
+ void (*postdriver_hook)( void );
+ void (*idle_task)( void );
+ boolean do_zero_of_workspace;
+ unsigned32 idle_task_stack_size;
+ unsigned32 interrupt_stack_size;
+ unsigned32 extra_mpci_receive_server_stack;
+ void * (*stack_allocate_hook)( unsigned32 );
+ void (*stack_free_hook)( void* );
+ /* end of fields required on all CPUs */
+
+ /* XXX CPU family dependent stuff */
+@} rtems_cpu_table;
+@end group
+@end example
+
+@table @code
+@item pretasking_hook
+is the address of the user provided routine which is invoked
+once RTEMS APIs are initialized. This routine will be invoked
+before any system tasks are created. Interrupts are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item predriver_hook
+is the address of the user provided
+routine that is invoked immediately before the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item postdriver_hook
+is the address of the user provided
+routine that is invoked immediately after the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item idle_task
+is the address of the optional user
+provided routine which is used as the system's IDLE task. If
+this field is not NULL, then the RTEMS default IDLE task is not
+used. This field may be NULL to indicate that the default IDLE
+is to be used.
+
+@item do_zero_of_workspace
+indicates whether RTEMS should
+zero the Workspace as part of its initialization. If set to
+TRUE, the Workspace is zeroed. Otherwise, it is not.
+
+@item idle_task_stack_size
+is the size of the RTEMS idle task stack in bytes.
+If this number is less than MINIMUM_STACK_SIZE, then the
+idle task's stack will be MINIMUM_STACK_SIZE in byte.
+
+@item interrupt_stack_size
+is the size of the RTEMS
+allocated interrupt stack in bytes. This value must be at least
+as large as MINIMUM_STACK_SIZE.
+
+@item extra_mpci_receive_server_stack
+is the extra stack space allocated for the RTEMS MPCI receive server task
+in bytes. The MPCI receive server may invoke nearly all directives and
+may require extra stack space on some targets.
+
+@item stack_allocate_hook
+is the address of the optional user provided routine which allocates
+memory for task stacks. If this hook is not NULL, then a stack_free_hook
+must be provided as well.
+
+@item stack_free_hook
+is the address of the optional user provided routine which frees
+memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
+must be provided as well.
+
+@item XXX
+is where the CPU family dependent stuff goes.
+
+@end table
diff --git a/doc/cpu_supplement/powerpc.t b/doc/cpu_supplement/powerpc.t
new file mode 100644
index 0000000000..98828c4eed
--- /dev/null
+++ b/doc/cpu_supplement/powerpc.t
@@ -0,0 +1,1043 @@
+@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 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.
+
+It is highly recommended that the PowerPC RTEMS
+application developer obtain and become familiar with the
+documentation for the processor being used as well as the
+specification for the revision of the PowerPC architecture which
+corresponds to that processor.
+
+@subheading PowerPC Architecture Documents
+
+For information on the PowerPC architecture, refer to
+the following documents available from Motorola and IBM:
+
+@itemize @bullet
+
+@item @cite{PowerPC Microprocessor Family: The Programming Environment}
+(Motorola Document MPRPPCFPE-01).
+
+@item @cite{IBM PPC403GB Embedded Controller User's Manual}.
+
+@item @cite{PoweRisControl MPC500 Family RCPU RISC Central Processing
+Unit Reference Manual} (Motorola Document RCPUURM/AD).
+
+@item @cite{PowerPC 601 RISC Microprocessor User's Manual}
+(Motorola Document MPR601UM/AD).
+
+@item @cite{PowerPC 603 RISC Microprocessor User's Manual}
+(Motorola Document MPR603UM/AD).
+
+@item @cite{PowerPC 603e RISC Microprocessor User's Manual}
+(Motorola Document MPR603EUM/AD).
+
+@item @cite{PowerPC 604 RISC Microprocessor User's Manual}
+(Motorola Document MPR604UM/AD).
+
+@item @cite{PowerPC MPC821 Portable Systems Microprocessor User's Manual}
+(Motorola Document MPC821UM/AD).
+
+@item @cite{PowerQUICC MPC860 User's Manual} (Motorola Document MPC860UM/AD).
+
+
+@end itemize
+
+Motorola maintains an on-line electronic library for the PowerPC
+at the following URL:
+
+@itemize @code{ }
+@item @cite{http://www.mot.com/powerpc/library/library.html}
+@end itemize
+
+This site has a a wealth of information and examples. Many of the
+manuals are available from that site in electronic format.
+
+@subheading PowerPC Processor Simulator Information
+
+PSIM is a program which emulates the Instruction Set Architecture
+of the PowerPC microprocessor family. It is reely available in source
+code form under the terms of the GNU General Public License (version
+2 or later). PSIM can be integrated with the GNU Debugger (gdb) to
+execute and debug PowerPC executables on non-PowerPC hosts. PSIM
+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.
+
+
+@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, 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".
+
+@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
+
+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
+
+The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache. It is
+used to align the entry point of critical routines so that as much code
+as possible can be retrieved with the initial read into cache. This
+is done for the interrupt handler as well as the context switch routines.
+
+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
+
+The macro PPC_INTERRUPT_MAX is set to the number of exception sources
+supported by this PowerPC model.
+
+@subsubsection 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
+
+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
+
+The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and
+store instructions should be used to perform context switch operations.
+The relative efficiency of multiword load and store instructions versus
+an equivalent set of single word load and store instructions varies based
+upon the PowerPC model.
+
+@subsubsection Instruction Cache Size
+
+The macro PPC_I_CACHE is set to the size in bytes of the instruction cache.
+
+@subsubsection Data Cache Size
+
+The macro PPC_D_CACHE is set to the size in bytes of the data cache.
+
+@subsubsection Debug Model
+
+The macro PPC_DEBUG_MODEL is set to indicate the debug support features
+present in this CPU model. The following debug support feature sets
+are currently supported:
+
+@table @b
+
+@item @code{PPC_DEBUG_MODEL_STANDARD}
+indicates that the single-step trace enable (SE) and branch trace
+enable (BE) bits in the MSR are supported by this CPU model.
+
+@item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
+indicates that only the single-step trace enable (SE) bit in the MSR
+is supported by this CPU model.
+
+@item @code{PPC_DEBUG_MODEL_IBM4xx}
+indicates that the debug exception enable (DE) bit in the MSR is supported
+by this CPU model. At this time, this particular debug feature set
+has only been seen in the IBM 4xx series.
+
+@end table
+
+@subsubsection Low Power Model
+
+The macro PPC_LOW_POWER_MODE is set to indicate the low power model
+supported by this CPU model. The following low power modes are currently
+supported.
+
+@table @b
+
+@item @code{PPC_LOW_POWER_MODE_NONE}
+indicates that this CPU model has no low power mode support.
+
+@item @code{PPC_LOW_POWER_MODE_STANDARD}
+indicates that this CPU model follows the low power model defined for
+the PPC603e.
+
+@end table
+@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.
+
+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.
+
+@subsection Programming Model
+
+This section discusses the programming model for the
+PowerPC architecture.
+
+@subsubsection Non-Floating Point Registers
+
+The PowerPC architecture defines thirty-two non-floating point registers
+directly visible to the programmer. In thirty-two bit implementations, each
+register is thirty-two bits wide. In sixty-four bit implementations, each
+register is sixty-four bits wide.
+
+These registers are referred to as @code{gpr0} to @code{gpr31}.
+
+Some of the registers serve defined roles in the EABI programming model.
+The following table describes the role of each of these registers:
+
+@ifset use-ascii
+@example
+@group
+ +---------------+----------------+------------------------------+
+ | Register Name | Alternate Name | Description |
+ +---------------+----------------+------------------------------+
+ | r1 | sp | stack pointer |
+ +---------------+----------------+------------------------------+
+ | | | global pointer to the Small |
+ | r2 | na | Constant Area (SDA2) |
+ +---------------+----------------+------------------------------+
+ | r3 - r12 | na | parameter and result passing |
+ +---------------+----------------+------------------------------+
+ | | | global pointer to the Small |
+ | r13 | na | Data Area (SDA) |
+ +---------------+----------------+------------------------------+
+@end group
+@end example
+@end ifset
+
+@ifset use-tex
+@sp 1
+@tex
+\centerline{\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 2.50in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule}
+&r1&&sp&&stack pointer&\cr\noalign{\hrule}
+&r2&&NA&&global pointer to the Small&\cr
+&&&&&Constant Area (SDA2)&\cr\noalign{\hrule}
+&r3 - r12&&NA&&parameter and result passing&\cr\noalign{\hrule}
+&r13&&NA&&global pointer to the Small&\cr
+&&&&&Data Area (SDA2)&\cr\noalign{\hrule}
+}}\hfil}
+@end tex
+@end ifset
+
+@ifset use-html
+@html
+<CENTER>
+ <TABLE COLS=3 WIDTH="80%" BORDER=2>
+<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD>
+ <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD>
+ <TD ALIGN=center><STRONG>Description</STRONG></TD></TR>
+<TR><TD ALIGN=center>r1</TD>
+ <TD ALIGN=center>sp</TD>
+ <TD ALIGN=center>stack pointer</TD></TR>
+<TR><TD ALIGN=center>r2</TD>
+ <TD ALIGN=center>na</TD>
+ <TD ALIGN=center>global pointer to the Small Constant Area (SDA2)</TD></TR>
+<TR><TD ALIGN=center>r3 - r12</TD>
+ <TD ALIGN=center>NA</TD>
+ <TD ALIGN=center>parameter and result passing</TD></TR>
+<TR><TD ALIGN=center>r13</TD>
+ <TD ALIGN=center>NA</TD>
+ <TD ALIGN=center>global pointer to the Small Data Area (SDA)</TD></TR>
+ </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+
+@subsubsection Floating Point Registers
+
+The PowerPC architecture includes thirty-two, sixty-four bit
+floating point registers. All PowerPC floating point instructions
+interpret these registers as 32 double precision floating point registers,
+regardless of whether the processor has 64-bit or 32-bit implementation.
+
+The floating point status and control register (fpscr) records exceptions
+and the type of result generated by floating-point operations.
+Additionally, it controls the rounding mode of operations and allows the
+reporting of floating exceptions to be enabled or disabled.
+
+@subsubsection Special Registers
+
+The PowerPC architecture includes a number of special registers
+which are critical to the programming model:
+
+@table @b
+
+@item Machine State Register
+
+The MSR contains the processor mode, power management mode, endian mode,
+exception information, privilege level, floating point available and
+floating point excepiton mode, address translation information and
+the exception prefix.
+
+@item Link Register
+
+The LR contains the return address after a function call. This register
+must be saved before a subsequent subroutine call can be made. The
+use of this register is discussed further in the @b{Call and Return
+Mechanism} section below.
+
+@item Count Register
+
+The CTR contains the iteration variable for some loops. It may also be used
+for indirect function calls and jumps.
+
+@end table
+
+@subsection Call and Return Mechanism
+
+The PowerPC architecture supports a simple yet effective call
+and return mechanism. A subroutine is invoked
+via the "branch and link" (@code{bl}) and
+"brank and link absolute" (@code{bla})
+instructions. This instructions place the return address
+in the Link Register (LR). The callee returns to the caller by
+executing a "branch unconditional to the link register" (@code{blr})
+instruction. Thus the callee returns to the caller via a jump
+to the return address which is stored in the LR.
+
+The previous contents of the LR are not automatically saved
+by either the @code{bl} or @code{bla}. It is the responsibility
+of the callee to save the contents of the LR before invoking
+another subroutine. If the callee invokes another subroutine,
+it must restore the LR before executing the @code{blr} instruction
+to return to the caller.
+
+It is important to note that the PowerPC subroutine
+call and return mechanism does not automatically save and
+restore any registers.
+
+The LR may be accessed as special purpose register 8 (@code{SPR8}) using the
+"move from special register" (@code{mfspr}) and
+"move to special register" (@code{mtspr}) instructions.
+
+@subsection Calling Mechanism
+
+All RTEMS directives are invoked using the regular
+PowerPC EABI calling convention via the @code{bl} or
+@code{bla} instructions.
+
+@subsection Register Usage
+
+As discussed above, the call instruction does not
+automatically save any registers. It is the responsibility
+of the callee to save and restore any registers which must be preserved
+across subroutine calls. The callee is responsible for saving
+callee-preserved registers to the program stack and restoring them
+before returning to the caller.
+
+@subsection Parameter Passing
+
+RTEMS assumes that arguments are placed in the
+general purpose registers with the first argument in
+register 3 (@code{r3}), the second argument in general purpose
+register 4 (@code{r4}), and so forth until the seventh
+argument is in general purpose register 10 (@code{r10}).
+If there are more than seven arguments, then subsequent arguments
+are placed on the program stack. The following pseudo-code
+illustrates the typical sequence used to call a RTEMS directive
+with three (3) arguments:
+
+@example
+load third argument into r5
+load second argument into r4
+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) 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 PowerPC architecture supports a variety of memory models.
+RTEMS supports the PowerPC using a flat memory model with
+paging disabled. In this mode, the PowerPC automatically
+converts every address from a logical to a physical address
+each time it is used. The PowerPC uses information provided
+in the Block Address Translation (BAT) to convert these addresses.
+
+Implementations of the PowerPC architecture may be thirty-two or sixty-four bit.
+The PowerPC architecture supports a flat thirty-two or sixty-four bit address
+space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
+gigabytes) in thirty-two bit implementations or to 0xFFFFFFFFFFFFFFFF
+in sixty-four bit implementations. Each address is represented
+by either a thirty-two bit or sixty-four bit value and is byte addressable.
+The address may be used to reference a single byte, half-word
+(2-bytes), word (4 bytes), or in sixty-four bit implementations a
+doubleword (8 bytes). Memory accesses within the address space are
+performed in big or little endian fashion by the PowerPC based
+upon the current setting of the Little-endian mode enable bit (LE)
+in the Machine State Register (MSR). While the processor is in
+big endian mode, memory accesses which are not properly aligned
+generate an "alignment exception" (vector offset 0x00600). In
+little endian mode, the PowerPC architecture does not require
+the processor to generate alignment exceptions.
+
+The following table lists the alignment requirements for a variety
+of data accesses:
+
+@ifset use-ascii
+@example
+@group
+ +--------------+-----------------------+
+ | Data Type | Alignment Requirement |
+ +--------------+-----------------------+
+ | byte | 1 |
+ | half-word | 2 |
+ | word | 4 |
+ | doubleword | 8 |
+ +--------------+-----------------------+
+@end group
+@end example
+@end ifset
+
+@ifset use-tex
+@sp 1
+@tex
+\centerline{\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule}
+&byte&&1&\cr\noalign{\hrule}
+&half-word&&2&\cr\noalign{\hrule}
+&word&&4&\cr\noalign{\hrule}
+&doubleword&&8&\cr\noalign{\hrule}
+}}\hfil}
+@end tex
+@end ifset
+
+@ifset use-html
+@html
+<CENTER>
+ <TABLE COLS=2 WIDTH="60%" BORDER=2>
+<TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD>
+ <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR>
+<TR><TD ALIGN=center>byte</TD>
+ <TD ALIGN=center>1</TD></TR>
+<TR><TD ALIGN=center>half-word</TD>
+ <TD ALIGN=center>2</TD></TR>
+<TR><TD ALIGN=center>word</TD>
+ <TD ALIGN=center>4</TD></TR>
+<TR><TD ALIGN=center>doubleword</TD>
+ <TD ALIGN=center>8</TD></TR>
+ </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+Doubleword load and store operations are only available in
+PowerPC CPU models which are sixty-four bit implementations.
+
+RTEMS does not directly support any PowerPC Memory Management
+Units, therefore, virtual memory or segmentation systems
+involving the PowerPC are not supported.
+
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Interrupt Processing
+
+
+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 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.
+
+@subsection Synchronous Versus Asynchronous Exceptions
+
+In the PowerPC architecture exceptions can be either precise or
+imprecise and either synchronous or asynchronous. Asynchronous
+exceptions occur when an external event interrupts the processor.
+Synchronous exceptions are caused by the actions of an
+instruction. During an exception SRR0 is used to calculate where
+instruction processing should resume. All instructions prior to
+the resume instruction will have completed execution. SRR1 is used to
+store the machine status.
+
+There are two asynchronous nonmaskable, highest-priority exceptions
+system reset and machine check. There are two asynchrononous maskable
+low-priority exceptions external interrupt and decrementer. Nonmaskable
+execptions are never delayed, therefore if two nonmaskable, asynchronous
+exceptions occur in immediate succession, the state information saved by
+the first exception may be overwritten when the subsequent exception occurs.
+
+The PowerPC arcitecure defines one imprecise exception, the imprecise
+floating point enabled exception. All other synchronous exceptions are
+precise. The synchronization occuring during asynchronous precise
+exceptions conforms to the requirements for context synchronization.
+
+@subsection Vectoring of Interrupt Handler
+
+Upon determining that an exception can be taken the PowerPC automatically
+performs the following actions:
+
+@itemize @bullet
+@item an instruction address is loaded into SRR0
+
+@item bits 33-36 and 42-47 of SRR1 are loaded with information
+specific to the exception.
+
+@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding
+bits from the MSR.
+
+@item the MSR is set based upon the exception type.
+
+@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type.
+
+@end itemize
+
+If the interrupt handler was installed as an RTEMS
+interrupt handler, then upon receipt of the interrupt, the
+processor passes control to the RTEMS interrupt handler which
+performs the following actions:
+
+@itemize @bullet
+@item saves the state of the interrupted task on it's stack,
+
+@item saves all registers which are not normally preserved
+by the calling sequence so the user's interrupt service
+routine can be written in a high-level language.
+
+@item if this is the outermost (i.e. non-nested) interrupt,
+then the RTEMS interrupt handler switches from the current stack
+to the interrupt stack,
+
+@item enables exceptions,
+
+@item invokes the vectors to a user interrupt service routine (ISR).
+@end itemize
+
+Asynchronous interrupts are ignored while exceptions are
+disabled. Synchronous interrupts which occur while are
+disabled result in the CPU being forced into an error mode.
+
+A nested interrupt is processed similarly with the
+exception that the current stack need not be switched to the
+interrupt stack.
+
+@subsection Interrupt Levels
+
+The PowerPC architecture supports only a single external
+asynchronous interrupt source. This interrupt source
+may be enabled and disabled via the External Interrupt Enable (EE)
+bit in the Machine State Register (MSR). Thus only two level (enabled
+and disabled) of external device interrupt priorities are
+directly supported by the PowerPC architecture.
+
+Some PowerPC implementations include a Critical Interrupt capability
+which is often used to receive interrupts from high priority external
+devices.
+
+The RTEMS interrupt level mapping scheme for the PowerPC is not
+a numeric level as on most RTEMS ports. It is a bit mapping in
+which the least three significiant bits of the interrupt level
+are mapped directly to the enabling of specific interrupt
+sources as follows:
+
+@table @b
+
+@item Critical Interrupt
+Setting bit 0 (the least significant bit) of the interrupt level
+enables the Critical Interrupt source, if it is available on this
+CPU model.
+
+@item Machine Check
+Setting bit 1 of the interrupt level enables Machine Check execptions.
+
+@item External Interrupt
+Setting bit 2 of the interrupt level enables External Interrupt execptions.
+
+@end table
+
+All other bits in the RTEMS task interrupt level are ignored.
+
+@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) 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 following actions:
+
+@itemize @bullet
+
+@item places the error code in r3, and
+
+@item executes a trap instruction which results in a Program Exception.
+
+@end itemize
+
+If the Program Exception returns, then the following actions are performed:
+
+@itemize @bullet
+
+@item disables all processor exceptions by loading a 0 into the MSR, and
+
+@item goes into an infinite loop to simulate a halt processor instruction.
+
+@end itemize
+
+@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 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
+re-initiated when the PowerPC processor is reset. The PowerPC
+architecture defines a Reset Exception, but leaves the
+details of the CPU state as implementation specific. Please
+refer to the User's Manual for the CPU model in question.
+
+In general, at power-up the PowerPC begin execution at address
+0xFFF00100 in supervisor mode with all exceptions disabled. For
+soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100
+depending upon the setting of the Exception Prefix bit in the MSR.
+If during a soft reset, a Machine Check Exception occurs, then the
+CPU may execute a hard reset.
+
+@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
+observed to prevent some emulators from working properly, so it
+may be necessary to run with caching disabled to use these emulators.
+
+In addition to the requirements described in the
+@b{Board Support Packages} chapter of the RTEMS C
+Applications User's Manual for the reset code
+which is executed before the call to @code{rtems_initialize_executive},
+the PowrePC version has the following specific requirements:
+
+@itemize @bullet
+@item Must leave the PR bit of the Machine State Register (MSR) set
+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.
+
+@item Must disable all external interrupts (i.e. clear the EI (EE)
+bit of the machine state register).
+
+@item Must enable traps so window overflow and underflow
+conditions can be properly handled.
+
+@item Must initialize the PowerPC's initial Exception Table with default
+handlers.
+
+@end itemize
+
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Processor Dependent Information Table
+
+
+Any highly processor dependent information required
+to describe a processor to RTEMS is provided in the CPU
+Dependent Information Table. This table is not required for all
+processors supported by RTEMS. This chapter describes the
+contents, if any, for a particular processor type.
+
+@subsection CPU Dependent Information Table
+
+The PowerPC version of the RTEMS CPU Dependent
+Information Table is given by the C structure definition is
+shown below:
+
+@example
+typedef struct @{
+ void (*pretasking_hook)( void );
+ void (*predriver_hook)( void );
+ void (*postdriver_hook)( void );
+ void (*idle_task)( void );
+ boolean do_zero_of_workspace;
+ unsigned32 idle_task_stack_size;
+ unsigned32 interrupt_stack_size;
+ unsigned32 extra_mpci_receive_server_stack;
+ void * (*stack_allocate_hook)( unsigned32 );
+ void (*stack_free_hook)( void* );
+ /* end of fields required on all CPUs */
+
+ unsigned32 clicks_per_usec; /* Timer clicks per microsecond */
+ void (*spurious_handler)(
+ unsigned32 vector, CPU_Interrupt_frame *);
+ boolean exceptions_in_RAM; /* TRUE if in RAM */
+
+#if defined(ppc403)
+ unsigned32 serial_per_sec; /* Serial clocks per second */
+ boolean serial_external_clock;
+ boolean serial_xon_xoff;
+ boolean serial_cts_rts;
+ unsigned32 serial_rate;
+ unsigned32 timer_average_overhead; /* in ticks */
+ unsigned32 timer_least_valid; /* Least valid number from timer */
+#endif
+@};
+@end example
+
+@table @code
+@item pretasking_hook
+is the address of the user provided routine which is invoked
+once RTEMS APIs are initialized. This routine will be invoked
+before any system tasks are created. Interrupts are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item predriver_hook
+is the address of the user provided
+routine that is invoked immediately before the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item postdriver_hook
+is the address of the user provided
+routine that is invoked immediately after the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item idle_task
+is the address of the optional user
+provided routine which is used as the system's IDLE task. If
+this field is not NULL, then the RTEMS default IDLE task is not
+used. This field may be NULL to indicate that the default IDLE
+is to be used.
+
+@item do_zero_of_workspace
+indicates whether RTEMS should
+zero the Workspace as part of its initialization. If set to
+TRUE, the Workspace is zeroed. Otherwise, it is not.
+
+@item idle_task_stack_size
+is the size of the RTEMS idle task stack in bytes.
+If this number is less than MINIMUM_STACK_SIZE, then the
+idle task's stack will be MINIMUM_STACK_SIZE in byte.
+
+@item interrupt_stack_size
+is the size of the RTEMS allocated interrupt stack in bytes.
+This value must be at least as large as MINIMUM_STACK_SIZE.
+
+@item extra_mpci_receive_server_stack
+is the extra stack space allocated for the RTEMS MPCI receive server task
+in bytes. The MPCI receive server may invoke nearly all directives and
+may require extra stack space on some targets.
+
+@item stack_allocate_hook
+is the address of the optional user provided routine which allocates
+memory for task stacks. If this hook is not NULL, then a stack_free_hook
+must be provided as well.
+
+@item stack_free_hook
+is the address of the optional user provided routine which frees
+memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
+must be provided as well.
+
+@item clicks_per_usec
+is the number of decrementer interupts that occur each microsecond.
+
+@item spurious_handler
+is the address of the
+routine which is invoked when a spurious interrupt occurs.
+
+@item exceptions_in_RAM
+indicates whether the exception vectors are located in RAM or ROM. If
+they are located in RAM dynamic vector installation occurs, otherwise
+it does not.
+
+@item serial_per_sec
+is a PPC403 specific field which specifies the number of clock
+ticks per second for the PPC403 serial timer.
+
+@item serial_rate
+is a PPC403 specific field which specifies the baud rate for the
+PPC403 serial port.
+
+@item serial_external_clock
+is a PPC403 specific field which indicates whether or not to mask in a 0x2 into
+the Input/Output Configuration Register (IOCR) during initialization of the
+PPC403 console. (NOTE: This bit is defined as "reserved" 6-12?)
+
+@item serial_xon_xoff
+is a PPC403 specific field which indicates whether or not
+XON/XOFF flow control is supported for the PPC403 serial port.
+
+@item serial_cts_rts
+is a PPC403 specific field which indicates whether or not to set the
+least significant bit of the Input/Output Configuration Register
+(IOCR) during initialization of the PPC403 console. (NOTE: This
+bit is defined as "reserved" 6-12?)
+
+@item timer_average_overhead
+is a PPC403 specific field which specifies the average number of overhead ticks that occur on the PPC403 timer.
+
+@item timer_least_valid
+is a PPC403 specific field which specifies the maximum valid PPC403 timer value.
+
+@end table
+
diff --git a/doc/cpu_supplement/preface.texi b/doc/cpu_supplement/preface.texi
new file mode 100644
index 0000000000..75c3e386d9
--- /dev/null
+++ b/doc/cpu_supplement/preface.texi
@@ -0,0 +1,25 @@
+@c
+@c COPYRIGHT (c) 1988-2006.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@ifinfo
+@node Preface, ARM Specific Information, Top, Top
+@end ifinfo
+@unnumbered Preface
+
+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.
+
+Each chapter in this document discusses the details of how
+RTEMS was ported.
diff --git a/doc/cpu_supplement/sh.t b/doc/cpu_supplement/sh.t
new file mode 100644
index 0000000000..d3ce913457
--- /dev/null
+++ b/doc/cpu_supplement/sh.t
@@ -0,0 +1,685 @@
+@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 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.
+
+@subheading Architecture Documents
+
+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.
+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.
+
+@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.
+
+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 Calling Mechanism
+
+All RTEMS directives are invoked using either a bsr
+or 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.
+
+
+> > 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
+>
+
+
+@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.
+
+@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
+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.
+
+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.
+
+@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 SH'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
+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 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
+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.
+
+
+@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.
+
+@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:
+
+@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 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.
+
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Processor Dependent Information Table
+
+
+Any highly processor dependent information required
+to describe a processor to RTEMS is provided in the CPU
+Dependent Information Table. This table is not required for all
+processors supported by RTEMS. This chapter describes the
+contents, if any, for a particular processor type.
+
+@subsection CPU Dependent Information Table
+
+The XXX version of the RTEMS CPU Dependent
+Information Table contains the information required to interface
+a Board Support Package and RTEMS on the XXX. This
+information is provided to allow RTEMS to interoperate
+effectively with the BSP. The C structure definition is given
+here:
+
+@example
+@group
+typedef struct @{
+ void (*pretasking_hook)( void );
+ void (*predriver_hook)( void );
+ void (*postdriver_hook)( void );
+ void (*idle_task)( void );
+ boolean do_zero_of_workspace;
+ unsigned32 idle_task_stack_size;
+ unsigned32 interrupt_stack_size;
+ unsigned32 extra_mpci_receive_server_stack;
+ void * (*stack_allocate_hook)( unsigned32 );
+ void (*stack_free_hook)( void* );
+ /* end of fields required on all CPUs */
+
+ /* XXX CPU family dependent stuff */
+@} rtems_cpu_table;
+@end group
+@end example
+
+@table @code
+@item pretasking_hook
+is the address of the user provided routine which is invoked
+once RTEMS APIs are initialized. This routine will be invoked
+before any system tasks are created. Interrupts are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item predriver_hook
+is the address of the user provided
+routine that is invoked immediately before the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item postdriver_hook
+is the address of the user provided
+routine that is invoked immediately after the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item idle_task
+is the address of the optional user
+provided routine which is used as the system's IDLE task. If
+this field is not NULL, then the RTEMS default IDLE task is not
+used. This field may be NULL to indicate that the default IDLE
+is to be used.
+
+@item do_zero_of_workspace
+indicates whether RTEMS should
+zero the Workspace as part of its initialization. If set to
+TRUE, the Workspace is zeroed. Otherwise, it is not.
+
+@item idle_task_stack_size
+is the size of the RTEMS idle task stack in bytes.
+If this number is less than MINIMUM_STACK_SIZE, then the
+idle task's stack will be MINIMUM_STACK_SIZE in byte.
+
+@item interrupt_stack_size
+is the size of the RTEMS
+allocated interrupt stack in bytes. This value must be at least
+as large as MINIMUM_STACK_SIZE.
+
+@item extra_mpci_receive_server_stack
+is the extra stack space allocated for the RTEMS MPCI receive server task
+in bytes. The MPCI receive server may invoke nearly all directives and
+may require extra stack space on some targets.
+
+@item stack_allocate_hook
+is the address of the optional user provided routine which allocates
+memory for task stacks. If this hook is not NULL, then a stack_free_hook
+must be provided as well.
+
+@item stack_free_hook
+is the address of the optional user provided routine which frees
+memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
+must be provided as well.
+
+@item XXX
+is where the CPU family dependent stuff goes.
+
+@end table
diff --git a/doc/cpu_supplement/sparc.t b/doc/cpu_supplement/sparc.t
new file mode 100644
index 0000000000..c8fc03ba30
--- /dev/null
+++ b/doc/cpu_supplement/sparc.t
@@ -0,0 +1,1127 @@
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@ifinfo
+@end ifinfo
+@chapter SPARC 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 SPARC architecture
+dependencies in this port of RTEMS. Currently, only
+implementations of SPARC Version 7 are supported by RTEMS.
+
+It is highly recommended that the SPARC RTEMS
+application developer obtain and become familiar with the
+documentation for the processor being used as well as the
+specification for the revision of the SPARC architecture which
+corresponds to that processor.
+
+@subheading SPARC Architecture Documents
+
+For information on the SPARC architecture, refer to
+the following documents available from SPARC International, Inc.
+(http://www.sparc.com):
+
+@itemize @bullet
+@item SPARC Standard Version 7.
+
+@item SPARC Standard Version 8.
+
+@item SPARC Standard Version 9.
+@end itemize
+
+@subheading ERC32 Specific Information
+
+The European Space Agency's ERC32 is a three chip
+computing core implementing a SPARC V7 processor and associated
+support circuitry for embedded space applications. The integer
+and floating-point units (90C601E & 90C602E) are based on the
+Cypress 7C601 and 7C602, with additional error-detection and
+recovery functions. The memory controller (MEC) implements
+system support functions such as address decoding, memory
+interface, DMA interface, UARTs, timers, interrupt control,
+write-protection, memory reconfiguration and error-detection.
+The core is designed to work at 25MHz, but using space qualified
+memories limits the system frequency to around 15 MHz, resulting
+in a performance of 10 MIPS and 2 MFLOPS.
+
+Information on the ERC32 and a number of development
+support tools, such as the SPARC Instruction Simulator (SIS),
+are freely available on the Internet. The following documents
+and SIS are available via anonymous ftp or pointing your web
+browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32.
+
+@itemize @bullet
+@item ERC32 System Design Document
+
+@item MEC Device Specification
+@end itemize
+
+Additionally, the SPARC RISC User's Guide from Matra
+MHS documents the functionality of the integer and floating
+point units including the instruction set information. To
+obtain this document as well as ERC32 components and VHDL models
+contact:
+
+@example
+Matra MHS SA
+3 Avenue du Centre, BP 309,
+78054 St-Quentin-en-Yvelines,
+Cedex, France
+VOICE: +31-1-30607087
+FAX: +31-1-30640693
+@end example
+
+Amar Guennon (amar.guennon@@matramhs.fr) is familiar with the ERC32.
+
+@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.
+
+@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 SPARC implementations and are of importance to RTEMS.
+The set of CPU model feature macros are defined in the file
+cpukit/score/cpu/sparc/sparc.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 European Space
+Agency's ERC32 SPARC model, this macro is set to the string
+"erc32".
+
+@subsubsection Floating Point Unit
+
+The macro SPARC_HAS_FPU is set to 1 to indicate that
+this CPU model has a hardware floating point unit and 0
+otherwise.
+
+@subsubsection Bitscan Instruction
+
+The macro SPARC_HAS_BITSCAN is set to 1 to indicate
+that this CPU model has the bitscan instruction. For example,
+this instruction is supported by the Fujitsu SPARClite family.
+
+@subsubsection Number of Register Windows
+
+The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to
+indicate the number of register window sets implemented by this
+CPU model. The SPARC architecture allows a for a maximum of
+thirty-two register window sets although most implementations
+only include eight.
+
+@subsubsection Low Power Mode
+
+The macro SPARC_HAS_LOW_POWER_MODE is set to one to
+indicate that this CPU model has a low power mode. If low power
+is enabled, then there must be CPU model specific implementation
+of the IDLE task in cpukit/score/cpu/sparc/cpu.c. The low
+power mode IDLE task should be of the form:
+
+@example
+while ( TRUE ) @{
+ enter low power mode
+@}
+@end example
+
+The code required to enter low power mode is CPU model specific.
+
+@subsection CPU Model Implementation Notes
+
+The ERC32 is a custom SPARC V7 implementation based on the Cypress 601/602
+chipset. This CPU has a number of on-board peripherals and was developed by
+the European Space Agency to target space applications. RTEMS currently
+provides support for the following peripherals:
+
+@itemize @bullet
+@item UART Channels A and B
+@item General Purpose Timer
+@item Real Time Clock
+@item Watchdog Timer (so it can be disabled)
+@item Control Register (so powerdown mode can be enabled)
+@item Memory Control Register
+@item Interrupt Control
+@end itemize
+
+The General Purpose Timer and Real Time Clock Timer provided with the ERC32
+share the Timer Control Register. Because the Timer Control Register is write
+only, we must mirror it in software and insure that writes to one timer do not
+alter the current settings and status of the other timer. Routines are
+provided in erc32.h which promote the view that the two timers are completely
+independent. By exclusively using these routines to access the Timer Control
+Register, the application can view the system as having a General Purpose
+Timer Control Register and a Real Time Clock Timer Control Register
+rather than the single shared value.
+
+The RTEMS Idle thread take advantage of the low power mode provided by the
+ERC32. Low power mode is entered during idle loops and is enabled at
+initialization time.
+@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 Programming Model
+
+This section discusses the programming model for the
+SPARC architecture.
+
+@subsubsection Non-Floating Point Registers
+
+The SPARC architecture defines thirty-two
+non-floating point registers directly visible to the programmer.
+These are divided into four sets:
+
+@itemize @bullet
+@item input registers
+
+@item local registers
+
+@item output registers
+
+@item global registers
+@end itemize
+
+Each register is referred to by either two or three
+names in the SPARC reference manuals. First, the registers are
+referred to as r0 through r31 or with the alternate notation
+r[0] through r[31]. Second, each register is a member of one of
+the four sets listed above. Finally, some registers have an
+architecturally defined role in the programming model which
+provides an alternate name. The following table describes the
+mapping between the 32 registers and the register sets:
+
+@ifset use-ascii
+@example
+@group
+ +-----------------+----------------+------------------+
+ | Register Number | Register Names | Description |
+ +-----------------+----------------+------------------+
+ | 0 - 7 | g0 - g7 | Global Registers |
+ +-----------------+----------------+------------------+
+ | 8 - 15 | o0 - o7 | Output Registers |
+ +-----------------+----------------+------------------+
+ | 16 - 23 | l0 - l7 | Local Registers |
+ +-----------------+----------------+------------------+
+ | 24 - 31 | i0 - i7 | Input Registers |
+ +-----------------+----------------+------------------+
+@end group
+@end example
+@end ifset
+
+@ifset use-tex
+@sp 1
+@tex
+\centerline{\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule}
+&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule}
+&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule}
+&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule}
+&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule}
+}}\hfil}
+@end tex
+@end ifset
+
+@ifset use-html
+@html
+<CENTER>
+ <TABLE COLS=3 WIDTH="80%" BORDER=2>
+<TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD>
+ <TD ALIGN=center><STRONG>Register Names</STRONG></TD>
+ <TD ALIGN=center><STRONG>Description</STRONG></TD>
+<TR><TD ALIGN=center>0 - 7</TD>
+ <TD ALIGN=center>g0 - g7</TD>
+ <TD ALIGN=center>Global Registers</TD></TR>
+<TR><TD ALIGN=center>8 - 15</TD>
+ <TD ALIGN=center>o0 - o7</TD>
+ <TD ALIGN=center>Output Registers</TD></TR>
+<TR><TD ALIGN=center>16 - 23</TD>
+ <TD ALIGN=center>l0 - l7</TD>
+ <TD ALIGN=center>Local Registers</TD></TR>
+<TR><TD ALIGN=center>24 - 31</TD>
+ <TD ALIGN=center>i0 - i7</TD>
+ <TD ALIGN=center>Input Registers</TD></TR>
+ </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+As mentioned above, some of the registers serve
+defined roles in the programming model. The following table
+describes the role of each of these registers:
+
+@ifset use-ascii
+@example
+@group
+ +---------------+----------------+----------------------+
+ | Register Name | Alternate Name | Description |
+ +---------------+----------------+----------------------+
+ | g0 | na | reads return 0 |
+ | | | writes are ignored |
+ +---------------+----------------+----------------------+
+ | o6 | sp | stack pointer |
+ +---------------+----------------+----------------------+
+ | i6 | fp | frame pointer |
+ +---------------+----------------+----------------------+
+ | i7 | na | return address |
+ +---------------+----------------+----------------------+
+@end group
+@end example
+@end ifset
+
+@ifset use-tex
+@sp 1
+@tex
+\centerline{\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule}
+&g0&&NA&&reads return 0; &\cr
+&&&&&writes are ignored&\cr\noalign{\hrule}
+&o6&&sp&&stack pointer&\cr\noalign{\hrule}
+&i6&&fp&&frame pointer&\cr\noalign{\hrule}
+&i7&&NA&&return address&\cr\noalign{\hrule}
+}}\hfil}
+@end tex
+@end ifset
+
+@ifset use-html
+@html
+<CENTER>
+ <TABLE COLS=3 WIDTH="80%" BORDER=2>
+<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD>
+ <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD>
+ <TD ALIGN=center><STRONG>Description</STRONG></TD></TR>
+<TR><TD ALIGN=center>g0</TD>
+ <TD ALIGN=center>NA</TD>
+ <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR>
+<TR><TD ALIGN=center>o6</TD>
+ <TD ALIGN=center>sp</TD>
+ <TD ALIGN=center>stack pointer</TD></TR>
+<TR><TD ALIGN=center>i6</TD>
+ <TD ALIGN=center>fp</TD>
+ <TD ALIGN=center>frame pointer</TD></TR>
+<TR><TD ALIGN=center>i7</TD>
+ <TD ALIGN=center>NA</TD>
+ <TD ALIGN=center>return address</TD></TR>
+ </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+
+@subsubsection Floating Point Registers
+
+The SPARC V7 architecture includes thirty-two,
+thirty-two bit registers. These registers may be viewed as
+follows:
+
+@itemize @bullet
+@item 32 single precision floating point or integer registers
+(f0, f1, ... f31)
+
+@item 16 double precision floating point registers (f0, f2,
+f4, ... f30)
+
+@item 8 extended precision floating point registers (f0, f4,
+f8, ... f28)
+@end itemize
+
+The floating point status register (fpsr) specifies
+the behavior of the floating point unit for rounding, contains
+its condition codes, version specification, and trap information.
+
+A queue of the floating point instructions which have
+started execution but not yet completed is maintained. This
+queue is needed to support the multiple cycle nature of floating
+point operations and to aid floating point exception trap
+handlers. Once a floating point exception has been encountered,
+the queue is frozen until it is emptied by the trap handler.
+The floating point queue is loaded by launching instructions.
+It is emptied normally when the floating point completes all
+outstanding instructions and by floating point exception
+handlers with the store double floating point queue (stdfq)
+instruction.
+
+@subsubsection Special Registers
+
+The SPARC architecture includes two special registers
+which are critical to the programming model: the Processor State
+Register (psr) and the Window Invalid Mask (wim). The psr
+contains the condition codes, processor interrupt level, trap
+enable bit, supervisor mode and previous supervisor mode bits,
+version information, floating point unit and coprocessor enable
+bits, and the current window pointer (cwp). The cwp field of
+the psr and wim register are used to manage the register windows
+in the SPARC architecture. The register windows are discussed
+in more detail below.
+
+@subsection Register Windows
+
+The SPARC architecture includes the concept of
+register windows. An overly simplistic way to think of these
+windows is to imagine them as being an infinite supply of
+"fresh" register sets available for each subroutine to use. In
+reality, they are much more complicated.
+
+The save instruction is used to obtain a new register
+window. This instruction decrements the current window pointer,
+thus providing a new set of registers for use. This register
+set includes eight fresh local registers for use exclusively by
+this subroutine. When done with a register set, the restore
+instruction increments the current window pointer and the
+previous register set is once again available.
+
+The two primary issues complicating the use of
+register windows are that (1) the set of register windows is
+finite, and (2) some registers are shared between adjacent
+registers windows.
+
+Because the set of register windows is finite, it is
+possible to execute enough save instructions without
+corresponding restore's to consume all of the register windows.
+This is easily accomplished in a high level language because
+each subroutine typically performs a save instruction upon
+entry. Thus having a subroutine call depth greater than the
+number of register windows will result in a window overflow
+condition. The window overflow condition generates a trap which
+must be handled in software. The window overflow trap handler
+is responsible for saving the contents of the oldest register
+window on the program stack.
+
+Similarly, the subroutines will eventually complete
+and begin to perform restore's. If the restore results in the
+need for a register window which has previously been written to
+memory as part of an overflow, then a window underflow condition
+results. Just like the window overflow, the window underflow
+condition must be handled in software by a trap handler. The
+window underflow trap handler is responsible for reloading the
+contents of the register window requested by the restore
+instruction from the program stack.
+
+The Window Invalid Mask (wim) and the Current Window
+Pointer (cwp) field in the psr are used in conjunction to manage
+the finite set of register windows and detect the window
+overflow and underflow conditions. The cwp contains the index
+of the register window currently in use. The save instruction
+decrements the cwp modulo the number of register windows.
+Similarly, the restore instruction increments the cwp modulo the
+number of register windows. Each bit in the wim represents
+represents whether a register window contains valid information.
+The value of 0 indicates the register window is valid and 1
+indicates it is invalid. When a save instruction causes the cwp
+to point to a register window which is marked as invalid, a
+window overflow condition results. Conversely, the restore
+instruction may result in a window underflow condition.
+
+Other than the assumption that a register window is
+always available for trap (i.e. interrupt) handlers, the SPARC
+architecture places no limits on the number of register windows
+simultaneously marked as invalid (i.e. number of bits set in the
+wim). However, RTEMS assumes that only one register window is
+marked invalid at a time (i.e. only one bit set in the wim).
+This makes the maximum possible number of register windows
+available to the user while still meeting the requirement that
+window overflow and underflow conditions can be detected.
+
+The window overflow and window underflow trap
+handlers are a critical part of the run-time environment for a
+SPARC application. The SPARC architectural specification allows
+for the number of register windows to be any power of two less
+than or equal to 32. The most common choice for SPARC
+implementations appears to be 8 register windows. This results
+in the cwp ranging in value from 0 to 7 on most implementations.
+
+
+The second complicating factor is the sharing of
+registers between adjacent register windows. While each
+register window has its own set of local registers, the input
+and output registers are shared between adjacent windows. The
+output registers for register window N are the same as the input
+registers for register window ((N - 1) modulo RW) where RW is
+the number of register windows. An alternative way to think of
+this is to remember how parameters are passed to a subroutine on
+the SPARC. The caller loads values into what are its output
+registers. Then after the callee executes a save instruction,
+those parameters are available in its input registers. This is
+a very efficient way to pass parameters as no data is actually
+moved by the save or restore instructions.
+
+@subsection Call and Return Mechanism
+
+The SPARC architecture supports a simple yet
+effective call and return mechanism. A subroutine is invoked
+via the call (call) instruction. This instruction places the
+return address in the caller's output register 7 (o7). After
+the callee executes a save instruction, this value is available
+in input register 7 (i7) until the corresponding restore
+instruction is executed.
+
+The callee returns to the caller via a jmp to the
+return address. There is a delay slot following this
+instruction which is commonly used to execute a restore
+instruction -- if a register window was allocated by this
+subroutine.
+
+It is important to note that the SPARC subroutine
+call and return mechanism does not automatically save and
+restore any registers. This is accomplished via the save and
+restore instructions which manage the set of registers windows.
+
+@subsection Calling Mechanism
+
+All RTEMS directives are invoked using the regular
+SPARC calling convention via the call instruction.
+
+@subsection Register Usage
+
+As discussed above, the call instruction does not
+automatically save any registers. The save and restore
+instructions are used to allocate and deallocate register
+windows. When a register window is allocated, the new set of
+local registers are available for the exclusive use of the
+subroutine which allocated this register set.
+
+@subsection Parameter Passing
+
+RTEMS assumes that arguments are placed in the
+caller's output registers with the first argument in output
+register 0 (o0), the second argument in output register 1 (o1),
+and so forth. Until the callee executes a save instruction, the
+parameters are still visible in the output registers. After the
+callee executes a save instruction, the parameters are visible
+in the corresponding input registers. The following pseudo-code
+illustrates the typical sequence used to call a RTEMS directive
+with three (3) arguments:
+
+@example
+load third argument into o2
+load second argument into o1
+load first argument into o0
+invoke directive
+@end example
+
+@subsection User-Provided Routines
+
+All user-provided routines invoked by RTEMS, such as
+user extensions, device drivers, and MPCI routines, must also
+adhere to these calling conventions.
+
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Memory Model
+
+
+A processor may support any combination of memory
+models ranging from pure physical addressing to complex demand
+paged virtual memory systems. RTEMS supports a flat memory
+model which ranges contiguously over the processor's allowable
+address space. RTEMS does not support segmentation or virtual
+memory of any kind. The appropriate memory model for RTEMS
+provided by the targeted processor and related characteristics
+of that model are described in this chapter.
+
+@subsection Flat Memory Model
+
+The SPARC architecture 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, half-word (2-bytes), word (4 bytes), or doubleword
+(8 bytes). Memory accesses within this address space are
+performed in big endian fashion by the SPARC. Memory accesses
+which are not properly aligned generate a "memory address not
+aligned" trap (type number 7). The following table lists the
+alignment requirements for a variety of data accesses:
+
+@ifset use-ascii
+@example
+@group
+ +--------------+-----------------------+
+ | Data Type | Alignment Requirement |
+ +--------------+-----------------------+
+ | byte | 1 |
+ | half-word | 2 |
+ | word | 4 |
+ | doubleword | 8 |
+ +--------------+-----------------------+
+@end group
+@end example
+@end ifset
+
+@ifset use-tex
+@sp 1
+@tex
+\centerline{\vbox{\offinterlineskip\halign{
+\vrule\strut#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#&
+\hbox to 1.75in{\enskip\hfil#\hfil}&
+\vrule#\cr
+\noalign{\hrule}
+&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule}
+&byte&&1&\cr\noalign{\hrule}
+&half-word&&2&\cr\noalign{\hrule}
+&word&&4&\cr\noalign{\hrule}
+&doubleword&&8&\cr\noalign{\hrule}
+}}\hfil}
+@end tex
+@end ifset
+
+@ifset use-html
+@html
+<CENTER>
+ <TABLE COLS=2 WIDTH="60%" BORDER=2>
+<TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD>
+ <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR>
+<TR><TD ALIGN=center>byte</TD>
+ <TD ALIGN=center>1</TD></TR>
+<TR><TD ALIGN=center>half-word</TD>
+ <TD ALIGN=center>2</TD></TR>
+<TR><TD ALIGN=center>word</TD>
+ <TD ALIGN=center>4</TD></TR>
+<TR><TD ALIGN=center>doubleword</TD>
+ <TD ALIGN=center>8</TD></TR>
+ </TABLE>
+</CENTER>
+@end html
+@end ifset
+
+Doubleword load and store operations must use a pair
+of registers as their source or destination. This pair of
+registers must be an adjacent pair of registers with the first
+of the pair being even numbered. For example, a valid
+destination for a doubleword load might be input registers 0 and
+1 (i0 and i1). The pair i1 and i2 would be invalid. [NOTE:
+Some assemblers for the SPARC do not generate an error if an odd
+numbered register is specified as the beginning register of the
+pair. In this case, the assembler assumes that what the
+programmer meant was to use the even-odd pair which ends at the
+specified register. This may or may not have been a correct
+assumption.]
+
+RTEMS does not support any SPARC Memory Management
+Units, therefore, virtual memory or segmentation systems
+involving the SPARC are not supported.
+
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Interrupt Processing
+
+
+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 SPARC's
+interrupt response and control mechanisms as they pertain to
+RTEMS.
+
+RTEMS and associated documentation uses the terms
+interrupt and vector. In the SPARC architecture, these terms
+correspond to traps and trap type, respectively. The terms will
+be used interchangeably in this manual.
+
+@subsection Synchronous Versus Asynchronous Traps
+
+The SPARC architecture includes two classes of traps:
+synchronous and asynchronous. Asynchronous traps occur when an
+external event interrupts the processor. These traps are not
+associated with any instruction executed by the processor and
+logically occur between instructions. The instruction currently
+in the execute stage of the processor is allowed to complete
+although subsequent instructions are annulled. The return
+address reported by the processor for asynchronous traps is the
+pair of instructions following the current instruction.
+
+Synchronous traps are caused by the actions of an
+instruction. The trap stimulus in this case either occurs
+internally to the processor or is from an external signal that
+was provoked by the instruction. These traps are taken
+immediately and the instruction that caused the trap is aborted
+before any state changes occur in the processor itself. The
+return address reported by the processor for synchronous traps
+is the instruction which caused the trap and the following
+instruction.
+
+@subsection Vectoring of Interrupt Handler
+
+Upon receipt of an interrupt the SPARC automatically
+performs the following actions:
+
+@itemize @bullet
+@item disables traps (sets the ET bit of the psr to 0),
+
+@item the S bit of the psr is copied into the Previous
+Supervisor Mode (PS) bit of the psr,
+
+@item the cwp is decremented by one (modulo the number of
+register windows) to activate a trap window,
+
+@item the PC and nPC are loaded into local register 1 and 2
+(l0 and l1),
+
+@item the trap type (tt) field of the Trap Base Register (TBR)
+is set to the appropriate value, and
+
+@item if the trap is not a reset, then the PC is written with
+the contents of the TBR and the nPC is written with TBR + 4. If
+the trap is a reset, then the PC is set to zero and the nPC is
+set to 4.
+@end itemize
+
+Trap processing on the SPARC has two features which
+are noticeably different than interrupt processing on other
+architectures. First, the value of psr register in effect
+immediately before the trap occurred is not explicitly saved.
+Instead only reversible alterations are made to it. Second, the
+Processor Interrupt Level (pil) is not set to correspond to that
+of the interrupt being processed. When a trap occurs, ALL
+subsequent traps are disabled. In order to safely invoke a
+subroutine during trap handling, traps must be enabled to allow
+for the possibility of register window overflow and underflow
+traps.
+
+If the interrupt handler was installed as an RTEMS
+interrupt handler, then upon receipt of the interrupt, the
+processor passes control to the RTEMS interrupt handler which
+performs the following actions:
+
+@itemize @bullet
+@item saves the state of the interrupted task on it's stack,
+
+@item insures that a register window is available for
+subsequent traps,
+
+@item if this is the outermost (i.e. non-nested) interrupt,
+then the RTEMS interrupt handler switches from the current stack
+to the interrupt stack,
+
+@item enables traps,
+
+@item invokes the vectors to a user interrupt service routine (ISR).
+@end itemize
+
+Asynchronous interrupts are ignored while traps are
+disabled. Synchronous traps which occur while traps are
+disabled result in the CPU being forced into an error mode.
+
+A nested interrupt is processed similarly with the
+exception that the current stack need not be switched to the
+interrupt stack.
+
+@subsection Traps and Register Windows
+
+One of the register windows must be reserved at all
+times for trap processing. This is critical to the proper
+operation of the trap mechanism in the SPARC architecture. It
+is the responsibility of the trap handler to insure that there
+is a register window available for a subsequent trap before
+re-enabling traps. It is likely that any high level language
+routines invoked by the trap handler (such as a user-provided
+RTEMS interrupt handler) will allocate a new register window.
+The save operation could result in a window overflow trap. This
+trap cannot be correctly processed unless (1) traps are enabled
+and (2) a register window is reserved for traps. Thus, the
+RTEMS interrupt handler insures that a register window is
+available for subsequent traps before enabling traps and
+invoking the user's interrupt handler.
+
+@subsection Interrupt Levels
+
+Sixteen levels (0-15) of interrupt priorities are
+supported by the SPARC architecture with level fifteen (15)
+being the highest priority. Level zero (0) indicates that
+interrupts are fully enabled. Interrupt requests for interrupts
+with priorities less than or equal to the current interrupt mask
+level are ignored.
+
+Although RTEMS supports 256 interrupt levels, the
+SPARC only supports sixteen. RTEMS interrupt levels 0 through
+15 directly correspond to SPARC processor interrupt levels. All
+other RTEMS interrupt levels are undefined and their behavior is
+unpredictable.
+
+@subsection Disabling of Interrupts by RTEMS
+
+During the execution of directive calls, critical
+sections of code may be executed. When these sections are
+encountered, RTEMS disables interrupts to level seven (15)
+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 ERC32 with zero wait states.
+These numbers will vary based the number of wait states and
+processor speed present on the target board.
+[NOTE: The maximum period with interrupts disabled is hand calculated. This
+calculation was last performed for Release
+RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
+
+[NOTE: It is thought that the length of time at which
+the processor interrupt level is elevated to fifteen by RTEMS is
+not anywhere near as long as the length of time ALL traps are
+disabled as part of the "flush all register windows" operation.]
+
+Non-maskable interrupts (NMI) cannot be disabled, and
+ISRs which execute at this level MUST NEVER issue RTEMS system
+calls. If a directive is invoked, unpredictable results may
+occur due to the inability of RTEMS to protect its critical
+sections. However, ISRs that make no system calls may safely
+execute as non-maskable interrupts.
+
+@subsection Interrupt Stack
+
+The SPARC architecture does not provide for a
+dedicated interrupt stack. Thus by default, trap handlers would
+execute on the stack of the RTEMS task which they interrupted.
+This artificially inflates the stack requirements for each task
+since EVERY task stack would have to include enough space to
+account for the worst case interrupt stack requirements in
+addition to it's own worst case usage. RTEMS addresses this
+problem on the SPARC by providing a dedicated interrupt stack
+managed by software.
+
+During system initialization, RTEMS allocates the
+interrupt stack from the Workspace Area. The amount of memory
+allocated for the interrupt stack is determined by the
+interrupt_stack_size field in the CPU Configuration Table. As
+part of processing a non-nested interrupt, RTEMS will switch to
+the interrupt stack before invoking the installed handler.
+
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Default Fatal Error Processing
+
+
+Upon detection of a fatal error by either the
+application or RTEMS the fatal error manager is invoked. The
+fatal error manager will invoke the user-supplied fatal error
+handlers. If no user-supplied handlers are configured, the
+RTEMS provided default fatal error handler is invoked. If the
+user-supplied fatal error handlers return to the executive the
+default fatal error handler is then invoked. This chapter
+describes the precise operations of the default fatal error
+handler.
+
+@subsection Default Fatal Error Handler Operations
+
+The default fatal error handler which is invoked by
+the fatal_error_occurred directive when there is no user handler
+configured or the user handler returns control to RTEMS. The
+default fatal error handler disables processor interrupts to
+level 15, places the error code in g1, and goes into an infinite
+loop to simulate a halt processor instruction.
+
+
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Board Support Packages
+
+
+An RTEMS Board Support Package (BSP) must be designed
+to support a particular processor and target board combination.
+This chapter presents a discussion of SPARC specific BSP issues.
+For more information on developing a BSP, refer to the chapter
+titled Board Support Packages in the RTEMS
+Applications User's Guide.
+
+@subsection System Reset
+
+An RTEMS based application is initiated or
+re-initiated when the SPARC processor is reset. When the SPARC
+is reset, the processor performs the following actions:
+
+@itemize @bullet
+@item the enable trap (ET) of the psr is set to 0 to disable
+traps,
+
+@item the supervisor bit (S) of the psr is set to 1 to enter
+supervisor mode, and
+
+@item the PC is set 0 and the nPC is set to 4.
+@end itemize
+
+The processor then begins to execute the code at
+location 0. It is important to note that all fields in the psr
+are not explicitly set by the above steps and all other
+registers retain their value from the previous execution mode.
+This is true even of the Trap Base Register (TBR) whose contents
+reflect the last trap which occurred before the reset.
+
+@subsection Processor Initialization
+
+It is the responsibility of the application's
+initialization code to initialize the TBR and install trap
+handlers for at least the register window overflow and register
+window underflow conditions. Traps should be enabled before
+invoking any subroutines to allow for register window
+management. However, interrupts should be disabled by setting
+the Processor Interrupt Level (pil) field of the psr to 15.
+RTEMS installs it's own Trap Table as part of initialization
+which is initialized with the contents of the Trap Table in
+place when the @code{rtems_initialize_executive} directive was invoked.
+Upon completion of executive initialization, interrupts are
+enabled.
+
+If this SPARC implementation supports on-chip caching
+and this is to be utilized, then it should be enabled during the
+reset application initialization code.
+
+In addition to the requirements described in the
+Board Support Packages chapter of the @value{LANGUAGE}
+Applications User's Manual for the reset code
+which is executed before the call to
+@code{rtems_initialize_executive}, the SPARC version has the following
+specific requirements:
+
+@itemize @bullet
+@item Must leave the S bit of the status register set so that
+the SPARC remains in the supervisor state.
+
+@item Must set stack pointer (sp) such that a minimum stack
+size of MINIMUM_STACK_SIZE bytes is provided for the
+@code{rtems_initialize_executive} directive.
+
+@item Must disable all external interrupts (i.e. set the pil
+to 15).
+
+@item Must enable traps so window overflow and underflow
+conditions can be properly handled.
+
+@item Must initialize the SPARC's initial trap table with at
+least trap handlers for register window overflow and register
+window underflow.
+@end itemize
+
+@c
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Processor Dependent Information Table
+
+
+Any highly processor dependent information required
+to describe a processor to RTEMS is provided in the CPU
+Dependent Information Table. This table is not required for all
+processors supported by RTEMS. This chapter describes the
+contents, if any, for a particular processor type.
+
+@subsection CPU Dependent Information Table
+
+The SPARC version of the RTEMS CPU Dependent
+Information Table is given by the C structure definition is
+shown below:
+
+@example
+@group
+typedef struct @{
+ void (*pretasking_hook)( void );
+ void (*predriver_hook)( void );
+ void (*postdriver_hook)( void );
+ void (*idle_task)( void );
+ boolean do_zero_of_workspace;
+ unsigned32 idle_task_stack_size;
+ unsigned32 interrupt_stack_size;
+ unsigned32 extra_mpci_receive_server_stack;
+ void * (*stack_allocate_hook)( unsigned32 );
+ void (*stack_free_hook)( void* );
+ /* end of fields required on all CPUs */
+
+@} rtems_cpu_table;
+@end group
+@end example
+
+@table @code
+@item pretasking_hook
+is the address of the user provided routine which is invoked
+once RTEMS APIs are initialized. This routine will be invoked
+before any system tasks are created. Interrupts are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item predriver_hook
+is the address of the user provided
+routine that is invoked immediately before the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item postdriver_hook
+is the address of the user provided
+routine that is invoked immediately after the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item idle_task
+is the address of the optional user
+provided routine which is used as the system's IDLE task. If
+this field is not NULL, then the RTEMS default IDLE task is not
+used. This field may be NULL to indicate that the default IDLE
+is to be used.
+
+@item do_zero_of_workspace
+indicates whether RTEMS should
+zero the Workspace as part of its initialization. If set to
+TRUE, the Workspace is zeroed. Otherwise, it is not.
+
+@item idle_task_stack_size
+is the size of the RTEMS idle task stack in bytes.
+If this number is less than MINIMUM_STACK_SIZE, then the
+idle task's stack will be MINIMUM_STACK_SIZE in byte.
+
+@item interrupt_stack_size
+is the size of the RTEMS allocated interrupt stack in bytes.
+This value must be at least as large as MINIMUM_STACK_SIZE.
+
+@item extra_mpci_receive_server_stack
+is the extra stack space allocated for the RTEMS MPCI receive server task
+in bytes. The MPCI receive server may invoke nearly all directives and
+may require extra stack space on some targets.
+
+@item stack_allocate_hook
+is the address of the optional user provided routine which allocates
+memory for task stacks. If this hook is not NULL, then a stack_free_hook
+must be provided as well.
+
+@item stack_free_hook
+is the address of the optional user provided routine which frees
+memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
+must be provided as well.
+
+@end table
+
diff --git a/doc/cpu_supplement/tic4x.t b/doc/cpu_supplement/tic4x.t
new file mode 100644
index 0000000000..9c276eae5c
--- /dev/null
+++ b/doc/cpu_supplement/tic4x.t
@@ -0,0 +1,888 @@
+@c
+@c COPYRIGHT (c) 1988-1999.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@ifinfo
+@end ifinfo
+@chapter Texas Instruments C3x/C4x 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 Texas Instrument C3x/C4x
+architecture dependencies in this port of RTEMS. The C3x/C4x
+family has a wide variety of CPU models within it. The following
+CPU model numbers could be supported by this port:
+
+@itemize
+@item C30 - TMSXXX
+@item C31 - TMSXXX
+@item C32 - TMSXXX
+@item C41 - TMSXXX
+@item C44 - TMSXXX
+@end itemize
+
+Initiially, this port does not include full support for C4x models.
+Primarily, the C4x specific implementations of interrupt flag and
+mask management routines have not been completed.
+
+It is highly recommended that the 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 Texas Instruments C3x/C4x architecture,
+refer to the following documents available from VENDOR
+(@file{http//www.ti.com/}):
+
+@itemize @bullet
+@item @cite{XXX Family Reference, Texas Instruments, 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, Texas Instruments, PART NUMBER}.
+@item @cite{XXX MODEL Manual, Texas Instruments, PART NUMBER}.
+@end itemize
+
+@c
+@c COPYRIGHT (c) 1988-1999.
+@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 the various implementations of the C3x/C4x architecture
+that are of importance to rtems.
+the set of cpu model feature macros are defined in the file
+cpukit/score/cpu/c4x/rtems/score/c4x.h and are based upon
+the particular cpu model defined in the bsp's custom configuration
+file as well as the compilation command line.
+
+@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 c32
+processor, this macro is set to the string "c32".
+
+@subsection Floating Point Unit
+
+The Texas Instruments C3x/C4x family makes little distinction
+between the various cpu registers. Although floating point
+operations may only be performed on a subset of the cpu registers,
+these same registers may be used for normal integer operations.
+as a result of this, this port of rtems makes no distinction
+between integer and floating point contexts. The routine
+@code{_CPU_Context_switch} saves all of the registers that
+comprise a task's context. the routines that initialize,
+save, and restore floating point contexts are not present
+in this port.
+
+Moreover, there is no floating point context pointer and
+the code in @code{_Thread_Dispatch} that manages the
+floating point context switching process is disabled
+on this port.
+
+This not only simplifies the port, it also speeds up context
+switches by reducing the code involved and reduces the code
+space footprint of the executive on the Texas Instruments
+C3x/C4x.
+
+@c
+@c COPYRIGHT (c) 1988-1999.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Calling Conventions
+
+
+Each high-level language compiler generates
+subroutine entry and exit code based upon a set of rules known
+as the compiler's calling convention. These rules address the
+following issues:
+
+@itemize @bullet
+@item register preservation and usage
+@item parameter passing
+@item call and return mechanism
+@end itemize
+
+A compiler's calling convention is of importance when
+interfacing to subroutines written in another language either
+assembly or high-level. Even when the high-level language and
+target processor are the same, different compilers may use
+different calling conventions. As a result, calling conventions
+are both processor and compiler dependent.
+
+The GNU Compiler Suite follows the same calling conventions
+as the Texas Instruments toolset.
+
+@subsection Processor Background
+
+The TI C3x and C4x processors support 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 important to
+note that the call and return mechanism for the C3x/C4x 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.
+
+XXX other supplements may have "is is".
+
+@subsection Calling Mechanism
+
+All subroutines are invoked using either a @code{XXX}
+or @code{XXX} instruction and return to the user application via the
+@code{XXX} instruction.
+
+@subsection Register Usage
+
+XXX
+
+As discussed above, the @code{XXX} and @code{XXX} instructions do
+not automatically save any registers. Subroutines use the registers
+@b{D0}, @b{D1}, @b{A0}, and @b{A1} as scratch registers. These registers are
+not preserved by subroutines therefore, the contents of
+these registers should not be assumed upon return from any subroutine
+call including but not limited to an RTEMS directive.
+
+The GNU and Texas Instruments compilers follow the same conventions
+for register usage.
+
+@subsection Parameter Passing
+
+Both the GNU and Texas Instruments compilers support two conventions
+for passing parameters to subroutines. Arguments may be passed in
+memory on the stack or in registers.
+
+@subsubsection Parameters Passed in Memory
+
+When passing parameters on the stack, the calling convention assumes
+that arguments are placed on the current stack before the subroutine
+is invoked via the @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
+subroutine with three (3) arguments:
+
+@example
+@group
+push third argument
+push second argument
+push first argument
+invoke subroutine
+remove arguments from the stack
+@end group
+@end example
+
+The arguments to RTEMS are typically pushed onto the
+stack using a @code{sti} instruction with a pre-incremented 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 subtracting the size of the
+argument list in words from the current stack pointer.
+
+@c XXX XXX instruction .. XXX should be code format.
+
+With the GNU Compiler Suite, parameter passing via the
+stack is selected by invoking the compiler with the
+@code{-mmemparm XXX} argument. This argument must be
+included when linking the application in order to
+ensure that support libraries also compiled assuming
+parameter passing via the stack are used. The default
+parameter passing mechanism is XXX.
+
+When this parameter passing mecahanism 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 how
+parameters are passed in to those C3x/C4x specific routines
+that were written in assembly language.
+
+@subsubsection Parameters Passed in Registers
+
+When passing parameters via registers, the calling convention assumes
+that the arguments are placed in particular registers based upon
+their position and data type before the subroutine is invoked via
+the @code{XXX} instruction.
+
+The following pseudo-code illustrates
+the typical sequence used to call a subroutine with three (3) arguments:
+
+@example
+@group
+move third argument to XXX
+move second argument to XXX
+move first argument to XXX
+invoke subroutine
+@end group
+@end example
+
+With the GNU Compiler Suite, parameter passing via
+registers is selected by invoking the compiler with the
+@code{-mregparm XXX} argument. This argument must be
+included when linking the application in order to
+ensure that support libraries also compiled assuming
+parameter passing via the stack are used. The default
+parameter passing mechanism is XXX.
+
+When this parameter passing mecahanism 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 how
+parameters are passed in to those C3x/C4x specific routines
+that were written in assembly language.
+
+@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-1999.
+@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 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
+
+@subsection 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.
+
+@subsection 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.
+
+@subsubsection 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.
+
+@subsubsection 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.
+@c
+@c Interrupt Stack Frame Picture
+@c
+@c COPYRIGHT (c) 1988-1999.
+@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 XXX'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 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
+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.
+
+
+@c
+@c COPYRIGHT (c) 1988-1999.
+@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.
+
+@c
+@c COPYRIGHT (c) 1988-1999.
+@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:
+
+@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 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.
+
+@c
+@c COPYRIGHT (c) 1988-1999.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c
+@c $Id$
+@c
+
+@section Processor Dependent Information Table
+
+
+Any highly processor dependent information required
+to describe a processor to RTEMS is provided in the CPU
+Dependent Information Table. This table is not required for all
+processors supported by RTEMS. This chapter describes the
+contents, if any, for a particular processor type.
+
+@subsection CPU Dependent Information Table
+
+The XXX version of the RTEMS CPU Dependent
+Information Table contains the information required to interface
+a Board Support Package and RTEMS on the XXX. This
+information is provided to allow RTEMS to interoperate
+effectively with the BSP. The C structure definition is given
+here:
+
+@example
+@group
+typedef struct @{
+ void (*pretasking_hook)( void );
+ void (*predriver_hook)( void );
+ void (*postdriver_hook)( void );
+ void (*idle_task)( void );
+ boolean do_zero_of_workspace;
+ unsigned32 idle_task_stack_size;
+ unsigned32 interrupt_stack_size;
+ unsigned32 extra_mpci_receive_server_stack;
+ void * (*stack_allocate_hook)( unsigned32 );
+ void (*stack_free_hook)( void* );
+ /* end of fields required on all CPUs */
+
+ /* XXX CPU family dependent stuff */
+@} rtems_cpu_table;
+@end group
+@end example
+
+@table @code
+@item pretasking_hook
+is the address of the user provided routine which is invoked
+once RTEMS APIs are initialized. This routine will be invoked
+before any system tasks are created. Interrupts are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item predriver_hook
+is the address of the user provided
+routine that is invoked immediately before the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item postdriver_hook
+is the address of the user provided
+routine that is invoked immediately after the
+the device drivers and MPCI are initialized. RTEMS
+initialization is complete but interrupts and tasking are disabled.
+This field may be NULL to indicate that the hook is not utilized.
+
+@item idle_task
+is the address of the optional user
+provided routine which is used as the system's IDLE task. If
+this field is not NULL, then the RTEMS default IDLE task is not
+used. This field may be NULL to indicate that the default IDLE
+is to be used.
+
+@item do_zero_of_workspace
+indicates whether RTEMS should
+zero the Workspace as part of its initialization. If set to
+TRUE, the Workspace is zeroed. Otherwise, it is not.
+
+@item idle_task_stack_size
+is the size of the RTEMS idle task stack in bytes.
+If this number is less than MINIMUM_STACK_SIZE, then the
+idle task's stack will be MINIMUM_STACK_SIZE in byte.
+
+@item interrupt_stack_size
+is the size of the RTEMS
+allocated interrupt stack in bytes. This value must be at least
+as large as MINIMUM_STACK_SIZE.
+
+@item extra_mpci_receive_server_stack
+is the extra stack space allocated for the RTEMS MPCI receive server task
+in bytes. The MPCI receive server may invoke nearly all directives and
+may require extra stack space on some targets.
+
+@item stack_allocate_hook
+is the address of the optional user provided routine which allocates
+memory for task stacks. If this hook is not NULL, then a stack_free_hook
+must be provided as well.
+
+@item stack_free_hook
+is the address of the optional user provided routine which frees
+memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
+must be provided as well.
+
+@item XXX
+is where the CPU family dependent stuff goes.
+
+@end table
diff --git a/doc/supplements/.cvsignore b/doc/supplements/.cvsignore
deleted file mode 100644
index 282522db03..0000000000
--- a/doc/supplements/.cvsignore
+++ /dev/null
@@ -1,2 +0,0 @@
-Makefile
-Makefile.in
diff --git a/doc/supplements/Makefile.am b/doc/supplements/Makefile.am
deleted file mode 100644
index 94fcb0e6a4..0000000000
--- a/doc/supplements/Makefile.am
+++ /dev/null
@@ -1,13 +0,0 @@
-## $Id$
-
-SUBDIRS = arm
-SUBDIRS += c4x
-SUBDIRS += i386
-SUBDIRS += m68k
-SUBDIRS += mips
-SUBDIRS += powerpc
-SUBDIRS += sh
-SUBDIRS += sparc
-SUBDIRS += template
-
-EXTRA_DIST = supplement.am
diff --git a/doc/supplements/arm/.cvsignore b/doc/supplements/arm/.cvsignore
deleted file mode 100644
index 0e010a5559..0000000000
--- a/doc/supplements/arm/.cvsignore
+++ /dev/null
@@ -1,31 +0,0 @@
-arm
-arm-?
-arm-??
-arm.aux
-arm.cp
-arm.dvi
-arm.fn
-arm*.html
-arm.ky
-arm.log
-arm.pdf
-arm.pg
-arm.ps
-arm.toc
-arm.tp
-arm.vr
-index.html
-intr.t
-intr.texi
-Makefile
-Makefile.in
-mdate-sh
-rtems_footer.html
-rtems_header.html
-stamp-vti
-timeBSP_.t
-timing.t
-timing.texi
-version.texi
-wksheets.t
-wksheets.texi
diff --git a/doc/supplements/arm/BSP_TIMES b/doc/supplements/arm/BSP_TIMES
deleted file mode 100644
index 296602a23f..0000000000
--- a/doc/supplements/arm/BSP_TIMES
+++ /dev/null
@@ -1,247 +0,0 @@
-#
-# CPU MODEL/BSP Timing and Size Information
-#
-# $Id$
-#
-
-#
-# CPU Model Information
-#
-RTEMS_BSP generic-arm9dtmi
-RTEMS_CPU_MODEL arm9dtmi
-#
-# Interrupt Latency
-#
-# NOTE: In general, the text says it is hand-calculated to be
-# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-# Mhz and this was last calculated for Release
-# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
-#
-RTEMS_MAXIMUM_DISABLE_PERIOD TBD
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 100
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD ss-20020301
-#
-# Context Switch Times
-#
-RTEMS_NO_FP_CONTEXTS 11
-RTEMS_RESTORE_1ST_FP_TASK NA
-RTEMS_SAVE_INIT_RESTORE_INIT NA
-RTEMS_SAVE_IDLE_RESTORE_INIT NA
-RTEMS_SAVE_IDLE_RESTORE_IDLE NA
-#
-# Task Manager Times
-#
-RTEMS_TASK_CREATE_ONLY 43
-RTEMS_TASK_IDENT_ONLY 85
-RTEMS_TASK_START_ONLY 19
-RTEMS_TASK_RESTART_CALLING_TASK 26
-RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 23
-RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 28
-RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 24
-RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 35
-RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 64
-RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 64
-RTEMS_TASK_DELETE_CALLING_TASK 55
-RTEMS_TASK_DELETE_SUSPENDED_TASK 42
-RTEMS_TASK_DELETE_BLOCKED_TASK 43
-RTEMS_TASK_DELETE_READY_TASK 43
-RTEMS_TASK_SUSPEND_CALLING_TASK 21
-RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 9
-RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 10
-RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 18
-RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 7
-RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 15
-RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 29
-RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 4
-RTEMS_TASK_MODE_NO_RESCHEDULE 4
-RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 13
-RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 30
-RTEMS_TASK_GET_NOTE_ONLY 8
-RTEMS_TASK_SET_NOTE_ONLY 7
-RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 5
-RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 17
-RTEMS_TASK_WAKE_WHEN_ONLY 33
-#
-# Interrupt Manager
-#
-RTEMS_INTR_ENTRY_RETURNS_TO_NESTED unavailable
-RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK unavailable
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK unavailable
-RTEMS_INTR_EXIT_RETURNS_TO_NESTED unavailable
-RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK unavailable
-RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK unavailable
-#
-# Clock Manager
-#
-RTEMS_CLOCK_SET_ONLY 21
-RTEMS_CLOCK_GET_ONLY 1
-RTEMS_CLOCK_TICK_ONLY 10
-#
-# Timer Manager
-#
-RTEMS_TIMER_CREATE_ONLY 8
-RTEMS_TIMER_IDENT_ONLY 83
-RTEMS_TIMER_DELETE_INACTIVE 11
-RTEMS_TIMER_DELETE_ACTIVE 12
-RTEMS_TIMER_FIRE_AFTER_INACTIVE 14
-RTEMS_TIMER_FIRE_AFTER_ACTIVE 15
-RTEMS_TIMER_FIRE_WHEN_INACTIVE 21
-RTEMS_TIMER_FIRE_WHEN_ACTIVE 21
-RTEMS_TIMER_RESET_INACTIVE 14
-RTEMS_TIMER_RESET_ACTIVE 15
-RTEMS_TIMER_CANCEL_INACTIVE 7
-RTEMS_TIMER_CANCEL_ACTIVE 9
-#
-# Semaphore Manager
-#
-RTEMS_SEMAPHORE_CREATE_ONLY 27
-RTEMS_SEMAPHORE_IDENT_ONLY 97
-RTEMS_SEMAPHORE_DELETE_ONLY 24
-RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 5
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 5
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 28
-RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 9
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 14
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 22
-#
-# Message Manager
-#
-RTEMS_MESSAGE_QUEUE_CREATE_ONLY 54
-RTEMS_MESSAGE_QUEUE_IDENT_ONLY 83
-RTEMS_MESSAGE_QUEUE_DELETE_ONLY 32
-RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 14
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 16
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 25
-RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 14
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 16
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 25
-RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 11
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 35
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 42
-RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 15
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 10
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 29
-RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 8
-RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 9
-#
-# Event Manager
-#
-RTEMS_EVENT_SEND_NO_TASK_READIED 7
-RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 13
-RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 22
-RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1
-RTEMS_EVENT_RECEIVE_AVAILABLE 14
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 7
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 24
-#
-# Signal Manager
-#
-RTEMS_SIGNAL_CATCH_ONLY 7
-RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 16
-RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 29
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 22
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 25
-#
-# Partition Manager
-#
-RTEMS_PARTITION_CREATE_ONLY 27
-RTEMS_PARTITION_IDENT_ONLY 83
-RTEMS_PARTITION_DELETE_ONLY 18
-RTEMS_PARTITION_GET_BUFFER_AVAILABLE 14
-RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 10
-RTEMS_PARTITION_RETURN_BUFFER_ONLY 17
-#
-# Region Manager
-#
-RTEMS_REGION_CREATE_ONLY 29
-RTEMS_REGION_IDENT_ONLY 84
-RTEMS_REGION_DELETE_ONLY 17
-RTEMS_REGION_GET_SEGMENT_AVAILABLE 14
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 18
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 56
-RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 15
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 40
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 58
-#
-# Dual-Ported Memory Manager
-#
-RTEMS_PORT_CREATE_ONLY 18
-RTEMS_PORT_IDENT_ONLY 83
-RTEMS_PORT_DELETE_ONLY 19
-RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 6
-RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 6
-#
-# IO Manager
-#
-RTEMS_IO_INITIALIZE_ONLY 2
-RTEMS_IO_OPEN_ONLY 1
-RTEMS_IO_CLOSE_ONLY 1
-RTEMS_IO_READ_ONLY 1
-RTEMS_IO_WRITE_ONLY 1
-RTEMS_IO_CONTROL_ONLY 1
-#
-# Rate Monotonic Manager
-#
-RTEMS_RATE_MONOTONIC_CREATE_ONLY 18
-RTEMS_RATE_MONOTONIC_IDENT_ONLY 83
-RTEMS_RATE_MONOTONIC_CANCEL_ONLY 18
-RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 23
-RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 21
-RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 25
-RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 20
-RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 13
-#
-# Size Information
-#
-#
-# xxx alloted for numbers
-#
-RTEMS_DATA_SPACE na
-RTEMS_MINIMUM_CONFIGURATION na
-RTEMS_MAXIMUM_CONFIGURATION na
-# x,xxx alloted for numbers
-RTEMS_CORE_CODE_SIZE na
-RTEMS_INITIALIZATION_CODE_SIZE na
-RTEMS_TASK_CODE_SIZE na
-RTEMS_INTERRUPT_CODE_SIZE na
-RTEMS_CLOCK_CODE_SIZE na
-RTEMS_TIMER_CODE_SIZE na
-RTEMS_SEMAPHORE_CODE_SIZE na
-RTEMS_MESSAGE_CODE_SIZE na
-RTEMS_EVENT_CODE_SIZE na
-RTEMS_SIGNAL_CODE_SIZE na
-RTEMS_PARTITION_CODE_SIZE na
-RTEMS_REGION_CODE_SIZE na
-RTEMS_DPMEM_CODE_SIZE na
-RTEMS_IO_CODE_SIZE na
-RTEMS_FATAL_ERROR_CODE_SIZE na
-RTEMS_RATE_MONOTONIC_CODE_SIZE na
-RTEMS_MULTIPROCESSING_CODE_SIZE na
-# xxx alloted for numbers
-RTEMS_TIMER_CODE_OPTSIZE na
-RTEMS_SEMAPHORE_CODE_OPTSIZE na
-RTEMS_MESSAGE_CODE_OPTSIZE na
-RTEMS_EVENT_CODE_OPTSIZE na
-RTEMS_SIGNAL_CODE_OPTSIZE na
-RTEMS_PARTITION_CODE_OPTSIZE na
-RTEMS_REGION_CODE_OPTSIZE na
-RTEMS_DPMEM_CODE_OPTSIZE na
-RTEMS_IO_CODE_OPTSIZE na
-RTEMS_RATE_MONOTONIC_CODE_OPTSIZE na
-RTEMS_MULTIPROCESSING_CODE_OPTSIZE na
-# xxx alloted for numbers
-RTEMS_BYTES_PER_TASK na
-RTEMS_BYTES_PER_TIMER na
-RTEMS_BYTES_PER_SEMAPHORE na
-RTEMS_BYTES_PER_MESSAGE_QUEUE na
-RTEMS_BYTES_PER_REGION na
-RTEMS_BYTES_PER_PARTITION na
-RTEMS_BYTES_PER_PORT na
-RTEMS_BYTES_PER_PERIOD na
-RTEMS_BYTES_PER_EXTENSION na
-RTEMS_BYTES_PER_FP_TASK na
-RTEMS_BYTES_PER_NODE na
-RTEMS_BYTES_PER_GLOBAL_OBJECT na
-RTEMS_BYTES_PER_PROXY na
-# x,xxx alloted for numbers
-RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS na
diff --git a/doc/supplements/arm/ChangeLog b/doc/supplements/arm/ChangeLog
deleted file mode 100644
index 74092a8203..0000000000
--- a/doc/supplements/arm/ChangeLog
+++ /dev/null
@@ -1,83 +0,0 @@
-2003-12-12 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-12-11 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-11-26 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Add *.info to CLEANFILES to accomodate
- automake-1.7f/1.8 breaking building infos.
-
-2003-09-26 Joel Sherrill <joel@OARcorp.com>
-
- * cpumodel.t: Obsoleting HP PA-RISC port and removing all references.
-
-2003-09-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Merger from rtems-4-6-branch.
-
-2003-09-19 Joel Sherrill <joel@OARcorp.com>
-
- * arm.texi: Merge from branch.
-
-2003-01-25 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * arm.texi: Set @setfilename arm.info.
-
-2003-01-24 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Put GENERATED_FILES into $builddir.
-
-2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * version.texi: Remove from CVS.
- * stamp-vti: Remove from CVS.
- * .cvsignore: Add version.texi.
- Add stamp-vti.
- Re-sort.
-
-2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * wksheets.texi: Remove from CVS.
- * timing.texi: Remove from CVS.
-
-2003-01-21 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-11-13 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-11-13 Jay Monkman <jtm@smoothsmoothie.com>
-
- * intr_NOTIMES.t: Real version submitted.
-
-2002-10-24 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-08-01 Joel Sherrill <joel@OARcorp.com>
-
- * BSP_TIMES, wksheets.texi: Updated to reflect ARM times
- reported by Jay Monkman <jmonkman@adventnetworks.com>. These
- times are subject to change as he tunes the ARM port and their BSP.
-
-2002-07-30 Joel Sherrill <joel@OARcorp.com>
-
- * .cvsignore: Corrected by tailoring for the ARM.
-
-2002-07-30 Joel Sherrill <joel@OARcorp.com>
-
- * .cvsignore: New file.
-
-2002-07-30 Joel Sherrill <joel@OARcorp.com>
-
- * BSP_TIMES, ChangeLog, Makefile.am, arm.texi, bsp.t, callconv.t,
- cpumodel.t, cputable.t, fatalerr.t, intr_NOTIMES.t, memmodel.t,
- preface.texi, stamp-vti, timeBSP.t, timing.texi, version.texi,
- wksheets.texi: New files as ARM supplement initial version added.
-
diff --git a/doc/supplements/arm/Makefile.am b/doc/supplements/arm/Makefile.am
deleted file mode 100644
index 3a83e7184d..0000000000
--- a/doc/supplements/arm/Makefile.am
+++ /dev/null
@@ -1,110 +0,0 @@
-#
-# COPYRIGHT (c) 1988-2002.
-# On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# $Id$
-#
-
-PROJECT = arm
-EDITION = 1
-
-include $(top_srcdir)/project.am
-include $(top_srcdir)/supplements/supplement.am
-
-GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \
- fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \
- timeBSP.texi
-COMMON_FILES += $(top_srcdir)/common/cpright.texi \
- $(top_srcdir)/common/timemac.texi
-
-FILES = preface.texi
-
-info_TEXINFOS = arm.texi
-arm_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
-
-#
-# Chapters which get automatic processing
-#
-
-cpumodel.texi: cpumodel.t
- $(BMENU2) -p "Preface" \
- -u "Top" \
- -n "Calling Conventions" < $< > $@
-
-callconv.texi: callconv.t
- $(BMENU2) -p "CPU Model Dependent Features Floating Point Unit" \
- -u "Top" \
- -n "Memory Model" < $< > $@
-
-memmodel.texi: memmodel.t
- $(BMENU2) -p "Calling Conventions User-Provided Routines" \
- -u "Top" \
- -n "Interrupt Processing" < $< > $@
-
-# Interrupt Chapter:
-# 1. Replace Times and Sizes
-# 2. Build Node Structure
-intr.texi: intr_NOTIMES.t BSP_TIMES
- ${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \
- $(BMENU2) -p "Memory Model Flat Memory Model" \
- -u "Top" \
- -n "Default Fatal Error Processing" > $@
-
-fatalerr.texi: fatalerr.t
- $(BMENU2) -p "Interrupt Processing Interrupt Stack" \
- -u "Top" \
- -n "Board Support Packages" < $< > $@
-
-bsp.texi: bsp.t
- $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
- -u "Top" \
- -n "Processor Dependent Information Table" < $< > $@
-
-cputable.texi: cputable.t
- $(BMENU2) -p "Board Support Packages Processor Initialization" \
- -u "Top" \
- -n "Memory Requirements" < $< > $@
-
-# Worksheets Chapter:
-# 1. Obtain the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES
- ${REPLACE2} -p $(srcdir)/BSP_TIMES \
- $(top_srcdir)/common/wksheets.t | \
- $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \
- -u "Top" \
- -n "Timing Specification" > $@
-
-# Timing Specification Chapter:
-# 1. Copy the Shared File
-# 3. Build Node Structure
-
-timing.texi: $(top_srcdir)/common/timing.t
- $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \
- -u "Top" \
- -n "MYBSP Timing Data" < $< > $@
-
-# Timing Data for BSP BSP Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t
- cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t
- @echo >>timeBSP_.t
- @echo "@tex" >>timeBSP_.t
- @echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t
- @echo "@end tex" >>timeBSP_.t
- ${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \
- $(BMENU2) -p "Timing Specification Terminology" \
- -u "Top" \
- -n "Command and Variable Index" > $@
-CLEANFILES += timeBSP_.t
-
-EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \
- intr_NOTIMES.t memmodel.t timeBSP.t
-
-CLEANFILES += arm.info
diff --git a/doc/supplements/arm/arm.texi b/doc/supplements/arm/arm.texi
deleted file mode 100644
index 32c3dcab18..0000000000
--- a/doc/supplements/arm/arm.texi
+++ /dev/null
@@ -1,115 +0,0 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename arm.info
-@setcontentsaftertitlepage
-@syncodeindex vr fn
-@synindex ky cp
-@paragraphindent 0
-@c %**end of header
-
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@c
-@c Master file for the ARM Applications Supplement
-@c
-
-@include version.texi
-@include common/setup.texi
-@include common/rtems.texi
-
-@ifset use-ascii
-@dircategory RTEMS Target Supplements
-@direntry
-* RTEMS ARM Applications Supplement: (arm).
-@end direntry
-@end ifset
-
-@c
-@c Title Page Stuff
-@c
-
-@c
-@c I don't really like having a short title page. --joel
-@c
-@c @shorttitlepage RTEMS ARM Applications Supplement
-
-@setchapternewpage odd
-@settitle RTEMS ARM Applications Supplement
-@titlepage
-@finalout
-
-@title RTEMS ARM Applications Supplement
-@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION}
-@sp 1
-@subtitle @value{UPDATED}
-@author On-Line Applications Research Corporation
-@page
-
-@include common/cpright.texi
-@end titlepage
-
-@c This prevents a black box from being printed on "overflow" lines.
-@c The alternative is to rework a sentence to avoid this problem.
-
-@include preface.texi
-@include cpumodel.texi
-@include callconv.texi
-@include memmodel.texi
-@include intr.texi
-@include fatalerr.texi
-@include bsp.texi
-@include cputable.texi
-@include wksheets.texi
-@include timing.texi
-@include timeBSP.texi
-@ifinfo
-@node Top, Preface, (dir), (dir)
-@top arm
-
-This is the online version of the RTEMS ARM
-Applications Supplement.
-
-@menu
-* Preface::
-* CPU Model Dependent Features::
-* Calling Conventions::
-* Memory Model::
-* Interrupt Processing::
-* Default Fatal Error Processing::
-* Board Support Packages::
-* Processor Dependent Information Table::
-* Memory Requirements::
-* Timing Specification::
-* MYBSP Timing Data::
-* Command and Variable Index::
-* Concept Index::
-@end menu
-
-@end ifinfo
-@c
-@c
-@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
-@c
-
-@node Command and Variable Index, Concept Index, MYBSP Timing Data Rate Monotonic Manager, Top
-@unnumbered Command and Variable Index
-
-There are currently no Command and Variable Index entries.
-
-@c @printindex fn
-
-@node Concept Index, , Command and Variable Index, Top
-@unnumbered Concept Index
-
-There are currently no Concept Index entries.
-@c @printindex cp
-
-@contents
-@bye
-
diff --git a/doc/supplements/arm/bsp.t b/doc/supplements/arm/bsp.t
deleted file mode 100644
index 657c359a96..0000000000
--- a/doc/supplements/arm/bsp.t
+++ /dev/null
@@ -1,93 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Board Support Packages
-
-@section Introduction
-
-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.
-
-@section 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:
-
-@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 The processor begins execution at the address stored in
-the PC.
-@end itemize
-
-@section 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.
-
diff --git a/doc/supplements/arm/callconv.t b/doc/supplements/arm/callconv.t
deleted file mode 100644
index 167f5b8fa5..0000000000
--- a/doc/supplements/arm/callconv.t
+++ /dev/null
@@ -1,73 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Calling Conventions
-
-@section Introduction
-
-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.
-
-@section 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.
-
-@section Calling Mechanism
-
-All RTEMS directives are invoked using the @code{bl}
-instruction and return to the user application via the
-mechanism described above.
-
-@section Register Usage
-
-As discussed above, the ARM's call and return mechanism dos
-not automatically save any registers. RTEMS uses the registers
-@code{r0}, @code{r1}, @code{r2}, and @code{r3} as scratch registers and
-per ARM calling convention, the @code{lr} register is altered
-as well. These registers are not preserved by RTEMS directives
-therefore, the contents of these registers should not be assumed
-upon return from any RTEMS directive.
-
-@section Parameter Passing
-
-RTEMS assumes that ARM calling conventions are followed and that
-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.
-
-@section 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.
-
diff --git a/doc/supplements/arm/cpumodel.t b/doc/supplements/arm/cpumodel.t
deleted file mode 100644
index af45d1a77b..0000000000
--- a/doc/supplements/arm/cpumodel.t
+++ /dev/null
@@ -1,82 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter CPU Model Dependent Features
-
-@section Introduction
-
-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
-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.
-
-@section 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:
-
-@example
-__ARM_ARCH4__ "ARMv4"
-__ARM_ARCH4T__ "ARMv4T"
-__ARM_ARCH5__ "ARMv5"
-__ARM_ARCH5T__ "ARMv5T"
-__ARM_ARCH5E__ "ARMv5E"
-__ARM_ARCH5TE__ "ARMv5TE"
-@end example
-
-@section Count Leading Zeroes Instruction
-
-The ARMv5 and later has the count leading zeroes (@code{clz})
-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 Floating Point Unit
-
-The macro ARM_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.
-
diff --git a/doc/supplements/arm/cputable.t b/doc/supplements/arm/cputable.t
deleted file mode 100644
index 75d0fc15f6..0000000000
--- a/doc/supplements/arm/cputable.t
+++ /dev/null
@@ -1,109 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Processor Dependent Information Table
-
-@section Introduction
-
-Any highly processor dependent information required
-to describe a processor to RTEMS is provided in the CPU
-Dependent Information Table. This table is not required for all
-processors supported by RTEMS. This chapter describes the
-contents, if any, for a particular processor type.
-
-@section CPU Dependent Information Table
-
-The XXX version of the RTEMS CPU Dependent
-Information Table contains the information required to interface
-a Board Support Package and RTEMS on the XXX. This
-information is provided to allow RTEMS to interoperate
-effectively with the BSP. The C structure definition is given
-here:
-
-@example
-@group
-typedef struct @{
- void (*pretasking_hook)( void );
- void (*predriver_hook)( void );
- void (*postdriver_hook)( void );
- void (*idle_task)( void );
- boolean do_zero_of_workspace;
- unsigned32 idle_task_stack_size;
- unsigned32 interrupt_stack_size;
- unsigned32 extra_mpci_receive_server_stack;
- void * (*stack_allocate_hook)( unsigned32 );
- void (*stack_free_hook)( void* );
- /* end of fields required on all CPUs */
-
- /* XXX CPU family dependent stuff */
-@} rtems_cpu_table;
-@end group
-@end example
-
-@table @code
-@item pretasking_hook
-is the address of the user provided routine which is invoked
-once RTEMS APIs are initialized. This routine will be invoked
-before any system tasks are created. Interrupts are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item predriver_hook
-is the address of the user provided
-routine that is invoked immediately before the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item postdriver_hook
-is the address of the user provided
-routine that is invoked immediately after the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item idle_task
-is the address of the optional user
-provided routine which is used as the system's IDLE task. If
-this field is not NULL, then the RTEMS default IDLE task is not
-used. This field may be NULL to indicate that the default IDLE
-is to be used.
-
-@item do_zero_of_workspace
-indicates whether RTEMS should
-zero the Workspace as part of its initialization. If set to
-TRUE, the Workspace is zeroed. Otherwise, it is not.
-
-@item idle_task_stack_size
-is the size of the RTEMS idle task stack in bytes.
-If this number is less than MINIMUM_STACK_SIZE, then the
-idle task's stack will be MINIMUM_STACK_SIZE in byte.
-
-@item interrupt_stack_size
-is the size of the RTEMS
-allocated interrupt stack in bytes. This value must be at least
-as large as MINIMUM_STACK_SIZE.
-
-@item extra_mpci_receive_server_stack
-is the extra stack space allocated for the RTEMS MPCI receive server task
-in bytes. The MPCI receive server may invoke nearly all directives and
-may require extra stack space on some targets.
-
-@item stack_allocate_hook
-is the address of the optional user provided routine which allocates
-memory for task stacks. If this hook is not NULL, then a stack_free_hook
-must be provided as well.
-
-@item stack_free_hook
-is the address of the optional user provided routine which frees
-memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
-must be provided as well.
-
-@item XXX
-is where the CPU family dependent stuff goes.
-
-@end table
diff --git a/doc/supplements/arm/fatalerr.t b/doc/supplements/arm/fatalerr.t
deleted file mode 100644
index 8a703718ea..0000000000
--- a/doc/supplements/arm/fatalerr.t
+++ /dev/null
@@ -1,37 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Default Fatal Error Processing
-
-@section Introduction
-
-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.
-
-@section 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:
-
-@itemize @bullet
-@item disables processor interrupts,
-@item places the error code in @b{r0}, and
-@item executes an infinite loop (@code{while(0);} to
-simulate a halt processor instruction.
-@end itemize
-
diff --git a/doc/supplements/arm/intr_NOTIMES.t b/doc/supplements/arm/intr_NOTIMES.t
deleted file mode 100644
index f4c61fa448..0000000000
--- a/doc/supplements/arm/intr_NOTIMES.t
+++ /dev/null
@@ -1,122 +0,0 @@
-@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
-
-@chapter Interrupt Processing
-
-@section Introduction
-
-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 ARM's
-interrupt response and control mechanisms as they pertain to
-RTEMS.
-
-The ARM has 7 exception types:
-@itemize @bullet
-
-@item Reset
-@item Undefined instruction
-@item Software interrupt (SWI)
-@item Prefetch Abort
-@item Data Abort
-@item Interrupt (IRQ)
-@item Fast Interrupt (FIQ)
-
-@end itemize
-
-Of these types, only IRQ and FIQ are handled through RTEMS's interrupt
-vectoring.
-
-@section Vectoring of an Interrupt Handler
-
-
-Unlike many other architectures, the ARM has seperate stacks for each
-interrupt. When the CPU receives an interrupt, it:
-
-@itemize @bullet
-@item switches to the exception mode corresponding to the interrupt,
-
-@item saves the Current Processor Status Register (CPSR) to the
-exception mode's Saved Processor Status Register (SPSR),
-
-@item masks off the IRQ and if the interrupt source was FIQ, the FIQ
-is masked off as well,
-
-@item saves the Program Counter (PC) to the exception mode's Link
-Register (LR - same as R14),
-
-@item and sets the PC to the exception's vector address.
-
-@end itemize
-
-The vectors for both IRQ and FIQ point to the _ISR_Handler function.
-_ISR_Handler() calls the BSP specific handler, ExecuteITHandler(). Before
-calling ExecuteITHandler(), registers R0-R3, R12, and R14(LR) are saved so
-that it is safe to call C functions. Even ExecuteITHandler() can be written
-in C.
-
-@section Interrupt Levels
-
-The ARM architecture supports two external interrupts - IRQ and FIQ. FIQ
-has a higher priority than IRQ, and has its own version of register R8 - R14,
-however RTEMS does not take advantage of them. Both interrupts are enabled
-through the CPSR.
-
-The RTEMS interrupt level mapping scheme for the AEM is not a numeric level
-as on most RTEMS ports. It is a bit mapping that corresponds the enable
-bits's postions in the CPSR:
-
-@table @b
-@item FIQ
-Setting bit 6 (0 is least significant bit) disables the FIQ.
-
-@item IRQ
-Setting bit 7 (0 is least significant bit) disables the IRQ.
-
-@end table
-
-
-@section 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.
-
-@section 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.
-
diff --git a/doc/supplements/arm/memmodel.t b/doc/supplements/arm/memmodel.t
deleted file mode 100644
index bf543364c7..0000000000
--- a/doc/supplements/arm/memmodel.t
+++ /dev/null
@@ -1,38 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@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 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.
-
diff --git a/doc/supplements/arm/preface.texi b/doc/supplements/arm/preface.texi
deleted file mode 100644
index 27bb11a558..0000000000
--- a/doc/supplements/arm/preface.texi
+++ /dev/null
@@ -1,49 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Preface, CPU Model Dependent Features, Top, Top
-@end ifinfo
-@unnumbered Preface
-
-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
-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.
-
-@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:
-
-@itemize @bullet
-@item @cite{David Seal. "ARM Architecture Reference Manual."
-Addison-Wesley. @b{ISBN 0-201-73719-1}. 2001.}
-
-@end itemize
-
-
diff --git a/doc/supplements/arm/timeBSP.t b/doc/supplements/arm/timeBSP.t
deleted file mode 100644
index 742272f775..0000000000
--- a/doc/supplements/arm/timeBSP.t
+++ /dev/null
@@ -1,113 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@include common/timemac.texi
-@tex
-\global\advance \smallskipamount by -4pt
-@end tex
-
-@chapter MYBSP Timing Data
-
-@section Introduction
-
-The timing data for the ARM version of RTEMS is
-provided along with the target dependent aspects concerning the
-gathering of the timing data. The hardware platform used to
-gather the times is described to give the reader a better
-understanding of each directive time provided. Also, provided
-is a description of the interrupt latency and the context switch
-times as they pertain to the ARM version of RTEMS.
-
-@section Hardware Platform
-
-All times reported except for the maximum period
-interrupts are disabled by RTEMS were measured using a Motorola
-MYBSP CPU board. The MYBSP is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz board with SDRAM and no numeric coprocessor. A
-countdown timer on this board was used to measure
-elapsed time with a 20 nanosecond resolution. All
-sources of hardware interrupts were disabled, although the
-interrupt level of the ARM microprocessor allows all interrupts.
-
-The maximum period interrupts are disabled was
-measured by summing the number of CPU cycles required by each
-assembly language instruction executed while interrupts were
-disabled. The worst case times of the ARM9DTMI microprocessor
-were used for each instruction. Zero wait state memory was
-assumed. The total CPU cycles executed with interrupts
-disabled, including the instructions to disable and enable
-interrupts, was divided by TBD to simulate a TBD Mhz processor. It
-should be noted that the worst case instruction times
-assume that the internal cache is disabled and that no
-instructions overlap.
-
-@section Interrupt Latency
-
-The maximum period with interrupts disabled within
-RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD
-microseconds including the instructions
-which disable and re-enable interrupts. The time required for
-the processor to vector an interrupt and for the RTEMS entry
-overhead before invoking the user's interrupt handler are a
-total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds. These combine to yield a worst case
-interrupt latency of less than
-RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz. [NOTE: The maximum period with interrupts
-disabled was last determined for Release
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-It should be noted again that the maximum period with
-interrupts disabled within RTEMS is hand-timed and based upon
-worst case (i.e. CPU cache disabled and no instruction overlap)
-times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz processor.
-The interrupt vector and entry
-overhead time was generated on an MYBSP benchmark platform
-using the Multiprocessing Communications registers to generate
-as the interrupt source.
-
-@section Context Switch
-
-The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
-microseconds on the MYBSP benchmark platform when no floating
-point context is saved or restored. Additional execution time
-is required when a TASK_SWITCH user extension is configured.
-The use of the TASK_SWITCH extension is application dependent.
-Thus, its execution time is not considered part of the raw
-context switch time.
-
-The ARM processor benchmarked does not have a floating point
-unit and consequently no FPU results are reported.
-
-@c Since RTEMS was designed specifically for embedded
-@c missile applications which are floating point intensive, the
-@c executive is optimized to avoid unnecessarily saving and
-@c restoring the state of the numeric coprocessor. The state of
-@c the numeric coprocessor is only saved when an FLOATING_POINT
-@c task is dispatched and that task was not the last task to
-@c utilize the coprocessor. In a system with only one
-@c FLOATING_POINT task, the state of the numeric coprocessor will
-@c never be saved or restored. When the first FLOATING_POINT task
-@c is dispatched, RTEMS does not need to save the current state of
-@c the numeric coprocessor.
-
-@c The exact amount of time required to save and restore
-@c floating point context is dependent on whether an XXX or
-@c XXX is being used as well as the state of the numeric
-@c coprocessor. These numeric coprocessors define three operating
-@c states: initialized, idle, and busy. RTEMS places the
-@c coprocessor in the initialized state when a task is started or
-@c restarted. Once the task has utilized the coprocessor, it is in
-@c the idle state when floating point instructions are not
-@c executing and the busy state when floating point instructions
-@c are executing. The state of the coprocessor is task specific.
-
-The following table summarizes the context switch
-times for the MYBSP benchmark platform:
-
diff --git a/doc/supplements/c4x/.cvsignore b/doc/supplements/c4x/.cvsignore
deleted file mode 100644
index 3585dc8094..0000000000
--- a/doc/supplements/c4x/.cvsignore
+++ /dev/null
@@ -1,31 +0,0 @@
-c4x
-c4x-?
-c4x-??
-c4x.aux
-c4x.cp
-c4x.dvi
-c4x.fn
-c4x*.html
-c4x.ky
-c4x.log
-c4x.pdf
-c4x.pg
-c4x.ps
-c4x.toc
-c4x.tp
-c4x.vr
-index.html
-intr.t
-intr.texi
-Makefile
-Makefile.in
-mdate-sh
-rtems_footer.html
-rtems_header.html
-stamp-vti
-timeBSP_.t
-timing.t
-timing.texi
-version.texi
-wksheets.t
-wksheets.texi
diff --git a/doc/supplements/c4x/BSP_TIMES b/doc/supplements/c4x/BSP_TIMES
deleted file mode 100644
index c80ed37148..0000000000
--- a/doc/supplements/c4x/BSP_TIMES
+++ /dev/null
@@ -1,247 +0,0 @@
-#
-# CPU MODEL/BSP Timing and Size Information
-#
-# $Id$
-#
-
-#
-# CPU Model Information
-#
-RTEMS_BSP BSP_FOR_TIMES
-RTEMS_CPU_MODEL BSP_CPU_MODEL
-#
-# Interrupt Latency
-#
-# NOTE: In general, the text says it is hand-calculated to be
-# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-# Mhz and this was last calculated for Release
-# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
-#
-RTEMS_MAXIMUM_DISABLE_PERIOD TBD
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0
-#
-# Context Switch Times
-#
-RTEMS_NO_FP_CONTEXTS 35
-RTEMS_RESTORE_1ST_FP_TASK 39
-RTEMS_SAVE_INIT_RESTORE_INIT 66
-RTEMS_SAVE_IDLE_RESTORE_INIT 66
-RTEMS_SAVE_IDLE_RESTORE_IDLE 68
-#
-# Task Manager Times
-#
-RTEMS_TASK_CREATE_ONLY 148
-RTEMS_TASK_IDENT_ONLY 350
-RTEMS_TASK_START_ONLY 76
-RTEMS_TASK_RESTART_CALLING_TASK 95
-RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89
-RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124
-RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92
-RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125
-RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149
-RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142
-RTEMS_TASK_DELETE_CALLING_TASK 170
-RTEMS_TASK_DELETE_SUSPENDED_TASK 138
-RTEMS_TASK_DELETE_BLOCKED_TASK 143
-RTEMS_TASK_DELETE_READY_TASK 144
-RTEMS_TASK_SUSPEND_CALLING_TASK 71
-RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43
-RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45
-RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67
-RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31
-RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64
-RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106
-RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14
-RTEMS_TASK_MODE_NO_RESCHEDULE 16
-RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23
-RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60
-RTEMS_TASK_GET_NOTE_ONLY 33
-RTEMS_TASK_SET_NOTE_ONLY 33
-RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16
-RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56
-RTEMS_TASK_WAKE_WHEN_ONLY 117
-#
-# Interrupt Manager
-#
-RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12
-RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9
-RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1
-RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8
-RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54
-#
-# Clock Manager
-#
-RTEMS_CLOCK_SET_ONLY 86
-RTEMS_CLOCK_GET_ONLY 1
-RTEMS_CLOCK_TICK_ONLY 17
-#
-# Timer Manager
-#
-RTEMS_TIMER_CREATE_ONLY 28
-RTEMS_TIMER_IDENT_ONLY 343
-RTEMS_TIMER_DELETE_INACTIVE 43
-RTEMS_TIMER_DELETE_ACTIVE 47
-RTEMS_TIMER_FIRE_AFTER_INACTIVE 58
-RTEMS_TIMER_FIRE_AFTER_ACTIVE 61
-RTEMS_TIMER_FIRE_WHEN_INACTIVE 88
-RTEMS_TIMER_FIRE_WHEN_ACTIVE 88
-RTEMS_TIMER_RESET_INACTIVE 54
-RTEMS_TIMER_RESET_ACTIVE 58
-RTEMS_TIMER_CANCEL_INACTIVE 31
-RTEMS_TIMER_CANCEL_ACTIVE 34
-#
-# Semaphore Manager
-#
-RTEMS_SEMAPHORE_CREATE_ONLY 60
-RTEMS_SEMAPHORE_IDENT_ONLY 367
-RTEMS_SEMAPHORE_DELETE_ONLY 58
-RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109
-RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87
-#
-# Message Manager
-#
-RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200
-RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341
-RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80
-RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123
-RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123
-RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133
-RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114
-RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29
-RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39
-#
-# Event Manager
-#
-RTEMS_EVENT_SEND_NO_TASK_READIED 24
-RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60
-RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84
-RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1
-RTEMS_EVENT_RECEIVE_AVAILABLE 28
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84
-#
-# Signal Manager
-#
-RTEMS_SIGNAL_CATCH_ONLY 15
-RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37
-RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54
-#
-# Partition Manager
-#
-RTEMS_PARTITION_CREATE_ONLY 70
-RTEMS_PARTITION_IDENT_ONLY 341
-RTEMS_PARTITION_DELETE_ONLY 42
-RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35
-RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33
-RTEMS_PARTITION_RETURN_BUFFER_ONLY 43
-#
-# Region Manager
-#
-RTEMS_REGION_CREATE_ONLY 63
-RTEMS_REGION_IDENT_ONLY 348
-RTEMS_REGION_DELETE_ONLY 39
-RTEMS_REGION_GET_SEGMENT_AVAILABLE 52
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123
-RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136
-#
-# Dual-Ported Memory Manager
-#
-RTEMS_PORT_CREATE_ONLY 35
-RTEMS_PORT_IDENT_ONLY 340
-RTEMS_PORT_DELETE_ONLY 39
-RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26
-RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27
-#
-# IO Manager
-#
-RTEMS_IO_INITIALIZE_ONLY 4
-RTEMS_IO_OPEN_ONLY 2
-RTEMS_IO_CLOSE_ONLY 1
-RTEMS_IO_READ_ONLY 2
-RTEMS_IO_WRITE_ONLY 3
-RTEMS_IO_CONTROL_ONLY 2
-#
-# Rate Monotonic Manager
-#
-RTEMS_RATE_MONOTONIC_CREATE_ONLY 32
-RTEMS_RATE_MONOTONIC_IDENT_ONLY 341
-RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39
-RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51
-RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48
-RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54
-RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74
-RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31
-#
-# Size Information
-#
-#
-# xxx alloted for numbers
-#
-RTEMS_DATA_SPACE 723
-RTEMS_MINIMUM_CONFIGURATION 18,980
-RTEMS_MAXIMUM_CONFIGURATION 36,438
-# x,xxx alloted for numbers
-RTEMS_CORE_CODE_SIZE 12,674
-RTEMS_INITIALIZATION_CODE_SIZE 970
-RTEMS_TASK_CODE_SIZE 3,562
-RTEMS_INTERRUPT_CODE_SIZE 54
-RTEMS_CLOCK_CODE_SIZE 334
-RTEMS_TIMER_CODE_SIZE 1,110
-RTEMS_SEMAPHORE_CODE_SIZE 1,632
-RTEMS_MESSAGE_CODE_SIZE 1,754
-RTEMS_EVENT_CODE_SIZE 1,000
-RTEMS_SIGNAL_CODE_SIZE 418
-RTEMS_PARTITION_CODE_SIZE 1,164
-RTEMS_REGION_CODE_SIZE 1,494
-RTEMS_DPMEM_CODE_SIZE 724
-RTEMS_IO_CODE_SIZE 686
-RTEMS_FATAL_ERROR_CODE_SIZE 24
-RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212
-RTEMS_MULTIPROCESSING_CODE_SIZE 6.952
-# xxx alloted for numbers
-RTEMS_TIMER_CODE_OPTSIZE 184
-RTEMS_SEMAPHORE_CODE_OPTSIZE 172
-RTEMS_MESSAGE_CODE_OPTSIZE 288
-RTEMS_EVENT_CODE_OPTSIZE 56
-RTEMS_SIGNAL_CODE_OPTSIZE 56
-RTEMS_PARTITION_CODE_OPTSIZE 132
-RTEMS_REGION_CODE_OPTSIZE 160
-RTEMS_DPMEM_CODE_OPTSIZE 132
-RTEMS_IO_CODE_OPTSIZE 00
-RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184
-RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332
-# xxx alloted for numbers
-RTEMS_BYTES_PER_TASK 400
-RTEMS_BYTES_PER_TIMER 68
-RTEMS_BYTES_PER_SEMAPHORE 124
-RTEMS_BYTES_PER_MESSAGE_QUEUE 148
-RTEMS_BYTES_PER_REGION 144
-RTEMS_BYTES_PER_PARTITION 56
-RTEMS_BYTES_PER_PORT 36
-RTEMS_BYTES_PER_PERIOD 36
-RTEMS_BYTES_PER_EXTENSION 64
-RTEMS_BYTES_PER_FP_TASK 332
-RTEMS_BYTES_PER_NODE 48
-RTEMS_BYTES_PER_GLOBAL_OBJECT 20
-RTEMS_BYTES_PER_PROXY 124
-# x,xxx alloted for numbers
-RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872
diff --git a/doc/supplements/c4x/ChangeLog b/doc/supplements/c4x/ChangeLog
deleted file mode 100644
index d18962cd77..0000000000
--- a/doc/supplements/c4x/ChangeLog
+++ /dev/null
@@ -1,49 +0,0 @@
-2003-12-12 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-12-11 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-11-26 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Add *.info to CLEANFILES to accomodate
- automake-1.7f/1.8 breaking building infos.
-
-2003-09-26 Joel Sherrill <joel@OARcorp.com>
-
- * cpumodel.t: Obsoleting HP PA-RISC port and removing all references.
-
-2003-09-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Merger from rtems-4-6-branch.
-
-2003-09-19 Joel Sherrill <joel@OARcorp.com>
-
- * c4x.texi: Merge from branch.
-
-2003-05-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * cpumodel.t: Reflect c/src/exec having moved to cpukit.
-
-2003-01-28 Joel Sherrill <joel@OARcorp.com>
-
- * .cvsignore: New file.
-
-2003-01-25 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * c4x.texi: Set @setfilename c4x.info.
-
-2003-01-25 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: New.
- * c4x.texi, cpumodel.t, timeBSP.t: Various minor changes to get them
- building.
-
-2003-01-24 Joel Sherrill <joel@OARcorp.com>
-
- * BSP_TIMES, bsp.t, c4x.texi, callconv.t, cpumodel.t, cputable.t,
- fatalerr.t, intr_NOTIMES.t, memmodel.t, preface.texi, timeBSP.t:
- New files. These should have been added long ago.
-
diff --git a/doc/supplements/c4x/Makefile.am b/doc/supplements/c4x/Makefile.am
deleted file mode 100644
index 55f666f8f5..0000000000
--- a/doc/supplements/c4x/Makefile.am
+++ /dev/null
@@ -1,108 +0,0 @@
-#
-# COPYRIGHT (c) 1988-2002.
-# On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# $Id$
-#
-
-PROJECT = c4x
-EDITION = 1
-
-include $(top_srcdir)/project.am
-include $(top_srcdir)/supplements/supplement.am
-
-GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \
- fatalerr.texi bsp.texi cputable.texi timing.texi wksheets.texi \
- timeBSP.texi
-
-COMMON_FILES += $(top_srcdir)/common/cpright.texi
-
-FILES = preface.texi
-
-info_TEXINFOS = c4x.texi
-c4x_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
-
-#
-# Chapters which get automatic processing
-#
-
-cpumodel.texi: cpumodel.t
- $(BMENU2) -p "Preface" \
- -u "Top" \
- -n "Calling Conventions" < $< > $@
-
-callconv.texi: callconv.t
- $(BMENU2) -p "CPU Model Dependent Features Floating Point Unit" \
- -u "Top" \
- -n "Memory Model" < $< > $@
-
-memmodel.texi: memmodel.t
- $(BMENU2) -p "Calling Conventions User-Provided Routines" \
- -u "Top" \
- -n "Interrupt Processing" < $< > $@
-
-# Interrupt Chapter:
-# 1. Replace Times and Sizes
-# 2. Build Node Structure
-intr.texi: intr_NOTIMES.t BSP_TIMES
- ${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \
- $(BMENU2) -p "Memory Model Large Memory Model" \
- -u "Top" \
- -n "Default Fatal Error Processing" > $@
-
-fatalerr.texi: fatalerr.t
- $(BMENU2) -p "Interrupt Processing Interrupt Stack" \
- -u "Top" \
- -n "Board Support Packages" < $< > $@
-
-bsp.texi: bsp.t
- $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
- -u "Top" \
- -n "Processor Dependent Information Table" < $< > $@
-
-cputable.texi: cputable.t
- $(BMENU2) -p "Board Support Packages Processor Initialization" \
- -u "Top" \
- -n "Memory Requirements" < $< > $@
-
-# Worksheets Chapter:
-# 1. Obtain the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES
- ${REPLACE2} -p $(srcdir)/BSP_TIMES $(top_srcdir)/common/wksheets.t | \
- $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \
- -u "Top" \
- -n "Timing Specification" > $@
-
-# Timing Specification Chapter:
-# 1. Copy the Shared File
-# 3. Build Node Structure
-timing.texi: $(top_srcdir)/common/timing.t
- $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \
- -u "Top" \
- -n "BSP_FOR_TIMES Timing Data" < $< > $@
-
-# Timing Data for BSP BSP_FOR_TIMES Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t
- cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t
- @echo >>timeBSP_.t
- @echo "@tex" >>timeBSP_.t
- @echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t
- @echo "@end tex" >>timeBSP_.t
- ${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \
- $(BMENU2) -p "Timing Specification Terminology" \
- -u "Top" \
- -n "Command and Variable Index" > $@
-CLEANFILES += timeBSP_.t
-
-EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \
- intr_NOTIMES.t memmodel.t timeBSP.t
-
-CLEANFILES += c4x.info c4x.info-?
diff --git a/doc/supplements/c4x/bsp.t b/doc/supplements/c4x/bsp.t
deleted file mode 100644
index a19aa06129..0000000000
--- a/doc/supplements/c4x/bsp.t
+++ /dev/null
@@ -1,93 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1999.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Board Support Packages
-
-@section Introduction
-
-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.
-
-@section 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:
-
-@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 The processor begins execution at the address stored in
-the PC.
-@end itemize
-
-@section 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.
-
diff --git a/doc/supplements/c4x/c4x.texi b/doc/supplements/c4x/c4x.texi
deleted file mode 100644
index 49fa76fd34..0000000000
--- a/doc/supplements/c4x/c4x.texi
+++ /dev/null
@@ -1,116 +0,0 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename c4x.info
-@setcontentsaftertitlepage
-@syncodeindex vr fn
-@synindex ky cp
-@paragraphindent 0
-@c @smallbook
-@c %**end of header
-
-@c
-@c COPYRIGHT (c) 1988-1999.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@c
-@c Master file for the TI C3x/C4x Applications Supplement
-@c
-
-@include version.texi
-@include common/setup.texi
-@include common/rtems.texi
-
-@ifset use-ascii
-@dircategory RTEMS Target Supplements
-@direntry
-* RTEMS TI C3x/C4x Applications Supplement: (c4x).
-@end direntry
-@end ifset
-
-@c
-@c Title Page Stuff
-@c
-
-@c
-@c I don't really like having a short title page. --joel
-@c
-@c @shorttitlepage RTEMS TI C3x/C4x Applications Supplement
-
-@setchapternewpage odd
-@settitle RTEMS TI C3x/C4x Applications Supplement
-@titlepage
-@finalout
-
-@title RTEMS TI C3x/C4x Applications Supplement
-@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION}
-@sp 1
-@subtitle @value{UPDATED}
-@author On-Line Applications Research Corporation
-@page
-
-@include common/cpright.texi
-@end titlepage
-
-@c This prevents a black box from being printed on "overflow" lines.
-@c The alternative is to rework a sentence to avoid this problem.
-
-@include preface.texi
-@include cpumodel.texi
-@include callconv.texi
-@include memmodel.texi
-@include intr.texi
-@include fatalerr.texi
-@include bsp.texi
-@include cputable.texi
-@include wksheets.texi
-@include timing.texi
-@include timeBSP.texi
-@ifinfo
-@node Top, Preface, (dir), (dir)
-@top c4x
-
-This is the online version of the RTEMS TI C3x/C4x
-Applications Supplement.
-
-@menu
-* Preface::
-* CPU Model Dependent Features::
-* Calling Conventions::
-* Memory Model::
-* Interrupt Processing::
-* Default Fatal Error Processing::
-* Board Support Packages::
-* Processor Dependent Information Table::
-* Memory Requirements::
-* Timing Specification::
-* BSP_FOR_TIMES Timing Data::
-* Command and Variable Index::
-* Concept Index::
-@end menu
-
-@end ifinfo
-@c
-@c
-@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
-@c
-
-@node Command and Variable Index, Concept Index, BSP_FOR_TIMES Timing Data Rate Monotonic Manager, Top
-@unnumbered Command and Variable Index
-
-There are currently no Command and Variable Index entries.
-
-@c @printindex fn
-
-@node Concept Index, , Command and Variable Index, Top
-@unnumbered Concept Index
-
-There are currently no Concept Index entries.
-@c @printindex cp
-
-@contents
-@bye
-
diff --git a/doc/supplements/c4x/callconv.t b/doc/supplements/c4x/callconv.t
deleted file mode 100644
index 94d52a05a3..0000000000
--- a/doc/supplements/c4x/callconv.t
+++ /dev/null
@@ -1,161 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1999.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Calling Conventions
-
-@section Introduction
-
-Each high-level language compiler generates
-subroutine entry and exit code based upon a set of rules known
-as the compiler's calling convention. These rules address the
-following issues:
-
-@itemize @bullet
-@item register preservation and usage
-@item parameter passing
-@item call and return mechanism
-@end itemize
-
-A compiler's calling convention is of importance when
-interfacing to subroutines written in another language either
-assembly or high-level. Even when the high-level language and
-target processor are the same, different compilers may use
-different calling conventions. As a result, calling conventions
-are both processor and compiler dependent.
-
-The GNU Compiler Suite follows the same calling conventions
-as the Texas Instruments toolset.
-
-@section Processor Background
-
-The TI C3x and C4x processors support 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 important to
-note that the call and return mechanism for the C3x/C4x 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.
-
-XXX other supplements may have "is is".
-
-@section Calling Mechanism
-
-All subroutines are invoked using either a @code{XXX}
-or @code{XXX} instruction and return to the user application via the
-@code{XXX} instruction.
-
-@section Register Usage
-
-XXX
-
-As discussed above, the @code{XXX} and @code{XXX} instructions do
-not automatically save any registers. Subroutines use the registers
-@b{D0}, @b{D1}, @b{A0}, and @b{A1} as scratch registers. These registers are
-not preserved by subroutines therefore, the contents of
-these registers should not be assumed upon return from any subroutine
-call including but not limited to an RTEMS directive.
-
-The GNU and Texas Instruments compilers follow the same conventions
-for register usage.
-
-@section Parameter Passing
-
-Both the GNU and Texas Instruments compilers support two conventions
-for passing parameters to subroutines. Arguments may be passed in
-memory on the stack or in registers.
-
-@subsection Parameters Passed in Memory
-
-When passing parameters on the stack, the calling convention assumes
-that arguments are placed on the current stack before the subroutine
-is invoked via the @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
-subroutine with three (3) arguments:
-
-@example
-@group
-push third argument
-push second argument
-push first argument
-invoke subroutine
-remove arguments from the stack
-@end group
-@end example
-
-The arguments to RTEMS are typically pushed onto the
-stack using a @code{sti} instruction with a pre-incremented 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 subtracting the size of the
-argument list in words from the current stack pointer.
-
-@c XXX XXX instruction .. XXX should be code format.
-
-With the GNU Compiler Suite, parameter passing via the
-stack is selected by invoking the compiler with the
-@code{-mmemparm XXX} argument. This argument must be
-included when linking the application in order to
-ensure that support libraries also compiled assuming
-parameter passing via the stack are used. The default
-parameter passing mechanism is XXX.
-
-When this parameter passing mecahanism 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 how
-parameters are passed in to those C3x/C4x specific routines
-that were written in assembly language.
-
-@subsection Parameters Passed in Registers
-
-When passing parameters via registers, the calling convention assumes
-that the arguments are placed in particular registers based upon
-their position and data type before the subroutine is invoked via
-the @code{XXX} instruction.
-
-The following pseudo-code illustrates
-the typical sequence used to call a subroutine with three (3) arguments:
-
-@example
-@group
-move third argument to XXX
-move second argument to XXX
-move first argument to XXX
-invoke subroutine
-@end group
-@end example
-
-With the GNU Compiler Suite, parameter passing via
-registers is selected by invoking the compiler with the
-@code{-mregparm XXX} argument. This argument must be
-included when linking the application in order to
-ensure that support libraries also compiled assuming
-parameter passing via the stack are used. The default
-parameter passing mechanism is XXX.
-
-When this parameter passing mecahanism 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 how
-parameters are passed in to those C3x/C4x specific routines
-that were written in assembly language.
-
-@section 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.
-
diff --git a/doc/supplements/c4x/cpumodel.t b/doc/supplements/c4x/cpumodel.t
deleted file mode 100644
index 079c6e15c7..0000000000
--- a/doc/supplements/c4x/cpumodel.t
+++ /dev/null
@@ -1,82 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1999.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter CPU Model Dependent Features
-
-@section Introduction
-
-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 the various implementations of the C3x/C4x architecture
-that are of importance to rtems.
-the set of cpu model feature macros are defined in the file
-cpukit/score/cpu/c4x/rtems/score/c4x.h and are based upon
-the particular cpu model defined in the bsp's custom configuration
-file as well as the compilation command line.
-
-@section CPU Model Name
-
-The macro @code{CPU_MODEL_NAME} is a string which designates
-the name of this cpu model. for example, for the c32
-processor, this macro is set to the string "c32".
-
-@section Floating Point Unit
-
-The Texas Instruments C3x/C4x family makes little distinction
-between the various cpu registers. Although floating point
-operations may only be performed on a subset of the cpu registers,
-these same registers may be used for normal integer operations.
-as a result of this, this port of rtems makes no distinction
-between integer and floating point contexts. The routine
-@code{_CPU_Context_switch} saves all of the registers that
-comprise a task's context. the routines that initialize,
-save, and restore floating point contexts are not present
-in this port.
-
-Moreover, there is no floating point context pointer and
-the code in @code{_Thread_Dispatch} that manages the
-floating point context switching process is disabled
-on this port.
-
-This not only simplifies the port, it also speeds up context
-switches by reducing the code involved and reduces the code
-space footprint of the executive on the Texas Instruments
-C3x/C4x.
-
diff --git a/doc/supplements/c4x/cputable.t b/doc/supplements/c4x/cputable.t
deleted file mode 100644
index 1a9f1e50d9..0000000000
--- a/doc/supplements/c4x/cputable.t
+++ /dev/null
@@ -1,109 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1999.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Processor Dependent Information Table
-
-@section Introduction
-
-Any highly processor dependent information required
-to describe a processor to RTEMS is provided in the CPU
-Dependent Information Table. This table is not required for all
-processors supported by RTEMS. This chapter describes the
-contents, if any, for a particular processor type.
-
-@section CPU Dependent Information Table
-
-The XXX version of the RTEMS CPU Dependent
-Information Table contains the information required to interface
-a Board Support Package and RTEMS on the XXX. This
-information is provided to allow RTEMS to interoperate
-effectively with the BSP. The C structure definition is given
-here:
-
-@example
-@group
-typedef struct @{
- void (*pretasking_hook)( void );
- void (*predriver_hook)( void );
- void (*postdriver_hook)( void );
- void (*idle_task)( void );
- boolean do_zero_of_workspace;
- unsigned32 idle_task_stack_size;
- unsigned32 interrupt_stack_size;
- unsigned32 extra_mpci_receive_server_stack;
- void * (*stack_allocate_hook)( unsigned32 );
- void (*stack_free_hook)( void* );
- /* end of fields required on all CPUs */
-
- /* XXX CPU family dependent stuff */
-@} rtems_cpu_table;
-@end group
-@end example
-
-@table @code
-@item pretasking_hook
-is the address of the user provided routine which is invoked
-once RTEMS APIs are initialized. This routine will be invoked
-before any system tasks are created. Interrupts are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item predriver_hook
-is the address of the user provided
-routine that is invoked immediately before the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item postdriver_hook
-is the address of the user provided
-routine that is invoked immediately after the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item idle_task
-is the address of the optional user
-provided routine which is used as the system's IDLE task. If
-this field is not NULL, then the RTEMS default IDLE task is not
-used. This field may be NULL to indicate that the default IDLE
-is to be used.
-
-@item do_zero_of_workspace
-indicates whether RTEMS should
-zero the Workspace as part of its initialization. If set to
-TRUE, the Workspace is zeroed. Otherwise, it is not.
-
-@item idle_task_stack_size
-is the size of the RTEMS idle task stack in bytes.
-If this number is less than MINIMUM_STACK_SIZE, then the
-idle task's stack will be MINIMUM_STACK_SIZE in byte.
-
-@item interrupt_stack_size
-is the size of the RTEMS
-allocated interrupt stack in bytes. This value must be at least
-as large as MINIMUM_STACK_SIZE.
-
-@item extra_mpci_receive_server_stack
-is the extra stack space allocated for the RTEMS MPCI receive server task
-in bytes. The MPCI receive server may invoke nearly all directives and
-may require extra stack space on some targets.
-
-@item stack_allocate_hook
-is the address of the optional user provided routine which allocates
-memory for task stacks. If this hook is not NULL, then a stack_free_hook
-must be provided as well.
-
-@item stack_free_hook
-is the address of the optional user provided routine which frees
-memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
-must be provided as well.
-
-@item XXX
-is where the CPU family dependent stuff goes.
-
-@end table
diff --git a/doc/supplements/c4x/fatalerr.t b/doc/supplements/c4x/fatalerr.t
deleted file mode 100644
index 0871fa3cb9..0000000000
--- a/doc/supplements/c4x/fatalerr.t
+++ /dev/null
@@ -1,31 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1999.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Default Fatal Error Processing
-
-@section Introduction
-
-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.
-
-@section 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.
-
diff --git a/doc/supplements/c4x/intr_NOTIMES.t b/doc/supplements/c4x/intr_NOTIMES.t
deleted file mode 100644
index 074420f2c9..0000000000
--- a/doc/supplements/c4x/intr_NOTIMES.t
+++ /dev/null
@@ -1,196 +0,0 @@
-@c
-@c Interrupt Stack Frame Picture
-@c
-@c COPYRIGHT (c) 1988-1999.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Interrupt Processing
-
-@section Introduction
-
-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 XXX's
-interrupt response and control mechanisms as they pertain to
-RTEMS.
-
-@section 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.
-
-@subsection 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
-
-@subsection 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 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
-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
-
-@section 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.
-
-@section 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.
-
-@section 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.
-
-
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.
diff --git a/doc/supplements/c4x/preface.texi b/doc/supplements/c4x/preface.texi
deleted file mode 100644
index c0eecf3ff6..0000000000
--- a/doc/supplements/c4x/preface.texi
+++ /dev/null
@@ -1,64 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1999.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Preface, CPU Model Dependent Features, Top, Top
-@end ifinfo
-@unnumbered Preface
-
-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 Texas Instrument C3x/C4x
-architecture dependencies in this port of RTEMS. The C3x/C4x
-family has a wide variety of CPU models within it. The following
-CPU model numbers could be supported by this port:
-
-@itemize
-@item C30 - TMSXXX
-@item C31 - TMSXXX
-@item C32 - TMSXXX
-@item C41 - TMSXXX
-@item C44 - TMSXXX
-@end itemize
-
-Initiially, this port does not include full support for C4x models.
-Primarily, the C4x specific implementations of interrupt flag and
-mask management routines have not been completed.
-
-It is highly recommended that the 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 Texas Instruments C3x/C4x architecture,
-refer to the following documents available from VENDOR
-(@file{http//www.ti.com/}):
-
-@itemize @bullet
-@item @cite{XXX Family Reference, Texas Instruments, 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, Texas Instruments, PART NUMBER}.
-@item @cite{XXX MODEL Manual, Texas Instruments, PART NUMBER}.
-@end itemize
-
diff --git a/doc/supplements/c4x/timeBSP.t b/doc/supplements/c4x/timeBSP.t
deleted file mode 100644
index a64dc93ca9..0000000000
--- a/doc/supplements/c4x/timeBSP.t
+++ /dev/null
@@ -1,108 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1999.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@include common/timemac.texi
-@tex
-\global\advance \smallskipamount by -4pt
-@end tex
-
-@chapter BSP_FOR_TIMES Timing Data
-
-@section Introduction
-
-The timing data for the XXX version of RTEMS is
-provided along with the target dependent aspects concerning the
-gathering of the timing data. The hardware platform used to
-gather the times is described to give the reader a better
-understanding of each directive time provided. Also, provided
-is a description of the interrupt latency and the context switch
-times as they pertain to the XXX version of RTEMS.
-
-@section Hardware Platform
-
-All times reported except for the maximum period
-interrupts are disabled by RTEMS were measured using a Motorola
-BSP_FOR_TIMES CPU board. The BSP_FOR_TIMES is a 20Mhz board with one wait
-state dynamic memory and a XXX numeric coprocessor. The
-Zilog 8036 countdown timer on this board was used to measure
-elapsed time with a one-half microsecond resolution. All
-sources of hardware interrupts were disabled, although the
-interrupt level of the XXX allows all interrupts.
-
-The maximum period interrupts are disabled was
-measured by summing the number of CPU cycles required by each
-assembly language instruction executed while interrupts were
-disabled. The worst case times of the XXX microprocessor
-were used for each instruction. Zero wait state memory was
-assumed. The total CPU cycles executed with interrupts
-disabled, including the instructions to disable and enable
-interrupts, was divided by 20 to simulate a 20Mhz XXX. It
-should be noted that the worst case instruction times for the
-XXX assume that the internal cache is disabled and that no
-instructions overlap.
-
-@section Interrupt Latency
-
-The maximum period with interrupts disabled within
-RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD
-microseconds including the instructions
-which disable and re-enable interrupts. The time required for
-the XXX to vector an interrupt and for the RTEMS entry
-overhead before invoking the user's interrupt handler are a
-total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds. These combine to yield a worst case
-interrupt latency of less than
-RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds at 20Mhz. [NOTE: The maximum period with interrupts
-disabled was last determined for Release
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-It should be noted again that the maximum period with
-interrupts disabled within RTEMS is hand-timed and based upon
-worst case (i.e. CPU cache disabled and no instruction overlap)
-times for a 20Mhz XXX. The interrupt vector and entry
-overhead time was generated on an BSP_FOR_TIMES benchmark platform
-using the Multiprocessing Communications registers to generate
-as the interrupt source.
-
-@section Context Switch
-
-The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
-microseconds on the BSP_FOR_TIMES benchmark platform when no floating
-point context is saved or restored. Additional execution time
-is required when a TASK_SWITCH user extension is configured.
-The use of the TASK_SWITCH extension is application dependent.
-Thus, its execution time is not considered part of the raw
-context switch time.
-
-Since RTEMS was designed specifically for embedded
-missile applications which are floating point intensive, the
-executive is optimized to avoid unnecessarily saving and
-restoring the state of the numeric coprocessor. The state of
-the numeric coprocessor is only saved when an FLOATING_POINT
-task is dispatched and that task was not the last task to
-utilize the coprocessor. In a system with only one
-FLOATING_POINT task, the state of the numeric coprocessor will
-never be saved or restored. When the first FLOATING_POINT task
-is dispatched, RTEMS does not need to save the current state of
-the numeric coprocessor.
-
-The exact amount of time required to save and restore
-floating point context is dependent on whether an XXX or
-XXX is being used as well as the state of the numeric
-coprocessor. These numeric coprocessors define three operating
-states: initialized, idle, and busy. RTEMS places the
-coprocessor in the initialized state when a task is started or
-restarted. Once the task has utilized the coprocessor, it is in
-the idle state when floating point instructions are not
-executing and the busy state when floating point instructions
-are executing. The state of the coprocessor is task specific.
-
-The following table summarizes the context switch
-times for the BSP_FOR_TIMES benchmark platform:
-
diff --git a/doc/supplements/i386/.cvsignore b/doc/supplements/i386/.cvsignore
deleted file mode 100644
index 0a0639e981..0000000000
--- a/doc/supplements/i386/.cvsignore
+++ /dev/null
@@ -1,31 +0,0 @@
-i386
-i386-?
-i386-??
-i386.aux
-i386.cp
-i386.dvi
-i386.fn
-i386*.html
-i386.ky
-i386.log
-i386.pdf
-i386.pg
-i386.ps
-i386.toc
-i386.tp
-i386.vr
-index.html
-intr.t
-intr.texi
-Makefile
-Makefile.in
-mdate-sh
-rtems_footer.html
-rtems_header.html
-stamp-vti
-timeFORCE386_.t
-timing.t
-timing.texi
-version.texi
-wksheets.t
-wksheets.texi
diff --git a/doc/supplements/i386/ChangeLog b/doc/supplements/i386/ChangeLog
deleted file mode 100644
index 438b5fe127..0000000000
--- a/doc/supplements/i386/ChangeLog
+++ /dev/null
@@ -1,72 +0,0 @@
-2003-12-12 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-12-11 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-11-26 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Add *.info to CLEANFILES to accomodate
- automake-1.7f/1.8 breaking building infos.
-
-2003-09-26 Joel Sherrill <joel@OARcorp.com>
-
- * cpumodel.t: Obsoleting HP PA-RISC port and removing all references.
-
-2003-09-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Merger from rtems-4-6-branch.
-
-2003-09-19 Joel Sherrill <joel@OARcorp.com>
-
- * i386.texi: Merge from branch.
-
-2003-05-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * cpumodel.t: Reflect c/src/exec having moved to cpukit.
-
-2003-01-25 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * i386.texi: Set @setfilename i386.info.
-
-2003-01-24 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Put GENERATED_FILES into $builddir.
-
-2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * version.texi: Remove from CVS.
- * stamp-vti: Remove from CVS.
- * .cvsignore: Add version.texi.
- Add stamp-vti.
- Re-sort.
-
-2003-01-21 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-11-13 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-10-24 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-03-27 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Remove AUTOMAKE_OPTIONS.
-
-2002-01-18 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Require automake-1.5.
-
-2001-01-17 Joel Sherrill <joel@OARcorp.com>
-
- * .cvsignore: Added rtems_header.html and rtems_footer.html.
-
-2000-08-10 Joel Sherrill <joel@OARcorp.com>
-
- * ChangeLog: New file.
diff --git a/doc/supplements/i386/FORCE386_TIMES b/doc/supplements/i386/FORCE386_TIMES
deleted file mode 100644
index b40f8ad50b..0000000000
--- a/doc/supplements/i386/FORCE386_TIMES
+++ /dev/null
@@ -1,247 +0,0 @@
-#
-# Intel i386/Force CPU-386 Timing and Size Information
-#
-# $Id$
-#
-
-#
-# CPU Model Information
-#
-RTEMS_BSP CPU386
-RTEMS_CPU_MODEL i386
-#
-# Interrupt Latency
-#
-# NOTE: In general, the text says it is hand-calculated to be
-# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-# Mhz and this was last calculated for Release
-# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
-#
-RTEMS_MAXIMUM_DISABLE_PERIOD 13.0
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 16
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.1.0
-#
-# Context Switch Times
-#
-RTEMS_NO_FP_CONTEXTS 34
-RTEMS_RESTORE_1ST_FP_TASK 57
-RTEMS_SAVE_INIT_RESTORE_INIT 59
-RTEMS_SAVE_IDLE_RESTORE_INIT 59
-RTEMS_SAVE_IDLE_RESTORE_IDLE 83
-#
-# Task Manager Times
-#
-RTEMS_TASK_CREATE_ONLY 157
-RTEMS_TASK_IDENT_ONLY 748
-RTEMS_TASK_START_ONLY 86
-RTEMS_TASK_RESTART_CALLING_TASK 118
-RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 45
-RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 138
-RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 105
-RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 149
-RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 162
-RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 156
-RTEMS_TASK_DELETE_CALLING_TASK 187
-RTEMS_TASK_DELETE_SUSPENDED_TASK 147
-RTEMS_TASK_DELETE_BLOCKED_TASK 153
-RTEMS_TASK_DELETE_READY_TASK 157
-RTEMS_TASK_SUSPEND_CALLING_TASK 81
-RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 45
-RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 46
-RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 71
-RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 30
-RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 67
-RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 115
-RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 19
-RTEMS_TASK_MODE_NO_RESCHEDULE 21
-RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 27
-RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 66
-RTEMS_TASK_GET_NOTE_ONLY 32
-RTEMS_TASK_SET_NOTE_ONLY 32
-RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 18
-RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 63
-RTEMS_TASK_WAKE_WHEN_ONLY 128
-#
-# Interrupt Manager
-#
-RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12
-RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 13
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 12
-RTEMS_INTR_EXIT_RETURNS_TO_NESTED 10
-RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 13
-RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 58
-#
-# Clock Manager
-#
-RTEMS_CLOCK_SET_ONLY 85
-RTEMS_CLOCK_GET_ONLY 2
-RTEMS_CLOCK_TICK_ONLY 16
-#
-# Timer Manager
-#
-RTEMS_TIMER_CREATE_ONLY 34
-RTEMS_TIMER_IDENT_ONLY 729
-RTEMS_TIMER_DELETE_INACTIVE 48
-RTEMS_TIMER_DELETE_ACTIVE 52
-RTEMS_TIMER_FIRE_AFTER_INACTIVE 65
-RTEMS_TIMER_FIRE_AFTER_ACTIVE 69
-RTEMS_TIMER_FIRE_WHEN_INACTIVE 92
-RTEMS_TIMER_FIRE_WHEN_ACTIVE 92
-RTEMS_TIMER_RESET_INACTIVE 58
-RTEMS_TIMER_RESET_ACTIVE 63
-RTEMS_TIMER_CANCEL_INACTIVE 32
-RTEMS_TIMER_CANCEL_ACTIVE 37
-#
-# Semaphore Manager
-#
-RTEMS_SEMAPHORE_CREATE_ONLY 64
-RTEMS_SEMAPHORE_IDENT_ONLY 787
-RTEMS_SEMAPHORE_DELETE_ONLY 60
-RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 41
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 40
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 123
-RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 47
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 70
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 95
-#
-# Message Manager
-#
-RTEMS_MESSAGE_QUEUE_CREATE_ONLY 294
-RTEMS_MESSAGE_QUEUE_IDENT_ONLY 730
-RTEMS_MESSAGE_QUEUE_DELETE_ONLY 81
-RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 117
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 118
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 144
-RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 117
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 116
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 144
-RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 122
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 146
-RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 93
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 45
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 127
-RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29
-RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 41
-#
-# Event Manager
-#
-RTEMS_EVENT_SEND_NO_TASK_READIED 26
-RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60
-RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 89
-RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS <1
-RTEMS_EVENT_RECEIVE_AVAILABLE 27
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 25
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 94
-#
-# Signal Manager
-#
-RTEMS_SIGNAL_CATCH_ONLY 13
-RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 34
-RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 59
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 39
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 60
-#
-# Partition Manager
-#
-RTEMS_PARTITION_CREATE_ONLY 83
-RTEMS_PARTITION_IDENT_ONLY 730
-RTEMS_PARTITION_DELETE_ONLY 40
-RTEMS_PARTITION_GET_BUFFER_AVAILABLE 34
-RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33
-RTEMS_PARTITION_RETURN_BUFFER_ONLY 40
-#
-# Region Manager
-#
-RTEMS_REGION_CREATE_ONLY 68
-RTEMS_REGION_IDENT_ONLY 739
-RTEMS_REGION_DELETE_ONLY 39
-RTEMS_REGION_GET_SEGMENT_AVAILABLE 49
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 45
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 127
-RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 52
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 113
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 138
-#
-# Dual-Ported Memory Manager
-#
-RTEMS_PORT_CREATE_ONLY 39
-RTEMS_PORT_IDENT_ONLY 728
-RTEMS_PORT_DELETE_ONLY 39
-RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26
-RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 26
-#
-# IO Manager
-#
-RTEMS_IO_INITIALIZE_ONLY 4
-RTEMS_IO_OPEN_ONLY 1
-RTEMS_IO_CLOSE_ONLY 1
-RTEMS_IO_READ_ONLY <1
-RTEMS_IO_WRITE_ONLY 1
-RTEMS_IO_CONTROL_ONLY 1
-#
-# Rate Monotonic Manager
-#
-RTEMS_RATE_MONOTONIC_CREATE_ONLY 36
-RTEMS_RATE_MONOTONIC_IDENT_ONLY 725
-RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39
-RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 53
-RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 49
-RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 53
-RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 82
-RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 30
-#
-# Size Information
-#
-#
-# xxx alloted for numbers
-#
-RTEMS_DATA_SPACE 833
-RTEMS_MINIMUM_CONFIGURATION 22,660
-RTEMS_MAXIMUM_CONFIGURATION 39,592
-# x,xxx alloted for numbers
-RTEMS_CORE_CODE_SIZE 16,948
-RTEMS_INITIALIZATION_CODE_SIZE 916
-RTEMS_TASK_CODE_SIZE 3,436
-RTEMS_INTERRUPT_CODE_SIZE 52
-RTEMS_CLOCK_CODE_SIZE 296
-RTEMS_TIMER_CODE_SIZE 1,084
-RTEMS_SEMAPHORE_CODE_SIZE 1,500
-RTEMS_MESSAGE_CODE_SIZE 1,596
-RTEMS_EVENT_CODE_SIZE 1,036
-RTEMS_SIGNAL_CODE_SIZE 396
-RTEMS_PARTITION_CODE_SIZE 1,052
-RTEMS_REGION_CODE_SIZE 1,392
-RTEMS_DPMEM_CODE_SIZE 664
-RTEMS_IO_CODE_SIZE 676
-RTEMS_FATAL_ERROR_CODE_SIZE 20
-RTEMS_RATE_MONOTONIC_CODE_SIZE 1,132
-RTEMS_MULTIPROCESSING_CODE_SIZE 6,840
-# xxx alloted for numbers
-RTEMS_TIMER_CODE_OPTSIZE 144
-RTEMS_SEMAPHORE_CODE_OPTSIZE 136
-RTEMS_MESSAGE_CODE_OPTSIZE 224
-RTEMS_EVENT_CODE_OPTSIZE 44
-RTEMS_SIGNAL_CODE_OPTSIZE 44
-RTEMS_PARTITION_CODE_OPTSIZE 104
-RTEMS_REGION_CODE_OPTSIZE 124
-RTEMS_DPMEM_CODE_OPTSIZE 104
-RTEMS_IO_CODE_OPTSIZE 00
-RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 136
-RTEMS_MULTIPROCESSING_CODE_OPTSIZE 228
-# xxx alloted for numbers
-RTEMS_BYTES_PER_TASK 372
-RTEMS_BYTES_PER_TIMER 68
-RTEMS_BYTES_PER_SEMAPHORE 124
-RTEMS_BYTES_PER_MESSAGE_QUEUE 148
-RTEMS_BYTES_PER_REGION 144
-RTEMS_BYTES_PER_PARTITION 56
-RTEMS_BYTES_PER_PORT 36
-RTEMS_BYTES_PER_PERIOD 36
-RTEMS_BYTES_PER_EXTENSION 64
-RTEMS_BYTES_PER_FP_TASK 108
-RTEMS_BYTES_PER_NODE 48
-RTEMS_BYTES_PER_GLOBAL_OBJECT 20
-RTEMS_BYTES_PER_PROXY 124
-# x,xxx alloted for numbers
-RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 6,768
diff --git a/doc/supplements/i386/Makefile.am b/doc/supplements/i386/Makefile.am
deleted file mode 100644
index a8a27d839b..0000000000
--- a/doc/supplements/i386/Makefile.am
+++ /dev/null
@@ -1,111 +0,0 @@
-#
-# COPYRIGHT (c) 1988-2002.
-# On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# $Id$
-#
-
-PROJECT = i386
-EDITION = 1
-
-include $(top_srcdir)/project.am
-include $(top_srcdir)/supplements/supplement.am
-
-GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \
- fatalerr.texi bsp.texi cputable.texi timing.texi wksheets.texi \
- timeFORCE386.texi
-
-COMMON_FILES += $(top_srcdir)/common/cpright.texi \
- $(top_srcdir)/common/timemac.texi
-
-FILES = preface.texi
-
-info_TEXINFOS = i386.texi
-i386_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
-
-#
-# Chapters which get automatic processing
-#
-
-cpumodel.texi: cpumodel.t
- $(BMENU2) -p "Preface" \
- -u "Top" \
- -n "Calling Conventions" < $< > $@
-
-callconv.texi: callconv.t
- $(BMENU2) -p "CPU Model Dependent Features Floating Point Unit" \
- -u "Top" \
- -n "Memory Model" < $< > $@
-
-memmodel.texi: memmodel.t
- $(BMENU2) -p "Calling Conventions User-Provided Routines" \
- -u "Top" \
- -n "Interrupt Processing" < $< > $@
-
-# Interrupt Chapter:
-# 1. Replace Times and Sizes
-# 2. Build Node Structure
-
-intr.texi: intr_NOTIMES.t FORCE386_TIMES
- ${REPLACE2} -p $(srcdir)/FORCE386_TIMES $(srcdir)/intr_NOTIMES.t | \
- $(BMENU2) -p "Memory Model Flat Memory Model" \
- -u "Top" \
- -n "Default Fatal Error Processing" > $@
-
-fatalerr.texi: fatalerr.t
- $(BMENU2) -p "Interrupt Processing Interrupt Stack" \
- -u "Top" \
- -n "Board Support Packages" < $< > $@
-
-bsp.texi: bsp.t
- $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
- -u "Top" \
- -n "Processor Dependent Information Table" < $< > $@
-
-cputable.texi: cputable.t
- $(BMENU2) -p "Board Support Packages Processor Initialization" \
- -u "Top" \
- -n "Memory Requirements" < $< > $@
-
-# Worksheets Chapter:
-# 1. Obtain the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-wksheets.texi: $(top_srcdir)/common/wksheets.t FORCE386_TIMES
- ${REPLACE2} -p $(srcdir)/FORCE386_TIMES \
- $(top_srcdir)/common/wksheets.t | \
- $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \
- -u "Top" \
- -n "Timing Specification" > $@
-
-# Timing Specification Chapter:
-# 1. Copy the Shared File
-# 3. Build Node Structure
-timing.texi: $(top_srcdir)/common/timing.t
- $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \
- -u "Top" \
- -n "CPU386 Timing Data" < $< > $@
-
-# Timing Data for BSP Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-timeFORCE386.texi: $(top_srcdir)/common/timetbl.t timeFORCE386.t
- cat $(srcdir)/timeFORCE386.t $(top_srcdir)/common/timetbl.t >timeFORCE386_.t
- @echo >>timeFORCE386_.t
- @echo "@tex" >>timeFORCE386_.t
- @echo "\\global\\advance \\smallskipamount by 4pt" >>timeFORCE386_.t
- @echo "@end tex" >>timeFORCE386_.t
- ${REPLACE2} -p $(srcdir)/FORCE386_TIMES timeFORCE386_.t | \
- $(BMENU2) -p "Timing Specification Terminology" \
- -u "Top" \
- -n "Command and Variable Index" > $@
-CLEANFILES += timeFORCE386_.t
-
-EXTRA_DIST = FORCE386_TIMES bsp.t callconv.t cpumodel.t cputable.t \
- fatalerr.t intr_NOTIMES.t memmodel.t timeFORCE386.t
-
-CLEANFILES += i386.info i386.info-?
diff --git a/doc/supplements/i386/bsp.t b/doc/supplements/i386/bsp.t
deleted file mode 100644
index 9ac99901f1..0000000000
--- a/doc/supplements/i386/bsp.t
+++ /dev/null
@@ -1,109 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Board Support Packages
-
-@section Introduction
-
-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.
-
-@section System Reset
-
-An RTEMS based application is initiated when the i386
-processor is reset. When the i386 is reset,
-
-@itemize @bullet
-
-@item The EAX register is set to indicate the results of the processor's
-power-up self test. If the self-test was not executed, the contents of
-this register are undefined. Otherwise, a non-zero value indicates the
-processor is faulty and a zero value indicates a successful self-test.
-
-@item The DX register holds a component identifier and revision level. DH
-contains 3 to indicate an i386 component and DL contains a unique revision
-level indicator.
-
-@item Control register zero (CR0) is set such that the processor is in real
-mode with paging disabled. Other portions of CR0 are used to indicate the
-presence of a numeric coprocessor.
-
-@item All bits in the extended flags register (EFLAG) which are not
-permanently set are cleared. This inhibits all maskable interrupts.
-
-@item The Interrupt Descriptor Register (IDTR) is set to point at address
-zero.
-
-@item All segment registers are set to zero.
-
-@item The instruction pointer is set to 0x0000FFF0. The first instruction
-executed after a reset is actually at 0xFFFFFFF0 because the i386 asserts
-the upper twelve address until the first intersegment (FAR) JMP or CALL
-instruction. When a JMP or CALL is executed, the upper twelve address
-lines are lowered and the processor begins executing in the first megabyte
-of memory.
-
-@end itemize
-
-Typically, an intersegment JMP to the application's initialization code is
-placed at address 0xFFFFFFF0.
-
-@section Processor Initialization
-
-This initialization code is responsible for initializing all data
-structures required by the i386 in protected mode and for actually entering
-protected mode. The i386 must be placed in protected mode and the segment
-registers and associated selectors must be initialized before the
-initialize_executive directive is invoked.
-
-The initialization code is responsible for initializing the Global
-Descriptor Table such that the i386 is in the thirty-two bit flat memory
-model with paging disabled. In this mode, the i386 automatically converts
-every address from a logical to a physical address each time it is used.
-For more information on the memory model used by RTEMS, please refer to the
-Memory Model chapter in this document.
-
-Since the processor is in real mode upon reset, the processor must be
-switched to protected mode before RTEMS can execute. Before switching to
-protected mode, at least one descriptor table and two descriptors must be
-created. Descriptors are needed for a code segment and a data segment. (
-This will give you the flat memory model.) The stack can be placed in a
-normal read/write data segment, so no descriptor for the stack is needed.
-Before the GDT can be used, the base address and limit must be loaded into
-the GDTR register using an LGDT instruction.
-
-If the hardware allows an NMI to be generated, you need to create the IDT
-and a gate for the NMI interrupt handler. Before the IDT can be used, the
-base address and limit for the idt must be loaded into the IDTR register
-using an LIDT instruction.
-
-Protected mode is entered by setting thye PE bit in the CR0 register.
-Either a LMSW or MOV CR0 instruction may be used to set this bit. Because
-the processor overlaps the interpretation of several instructions, it is
-necessary to discard the instructions from the read-ahead cache. A JMP
-instruction immediately after the LMSW changes the flow and empties the
-processor if intructions which have been pre-fetched and/or decoded. At
-this point, the processor is in protected mode and begins to perform
-protected mode application initialization.
-
-If the application requires that the IDTR be some value besides zero, then
-it should set it to the required value at this point. All tasks share the
-same i386 IDTR value. Because interrupts are enabled automatically by
-RTEMS as part of the initialize_executive directive, the IDTR MUST be set
-properly 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 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
-contents, refer to Intel's 386 Programmer's Reference Manual.
-
diff --git a/doc/supplements/i386/callconv.t b/doc/supplements/i386/callconv.t
deleted file mode 100644
index f3e428dfad..0000000000
--- a/doc/supplements/i386/callconv.t
+++ /dev/null
@@ -1,90 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Calling Conventions
-
-@section Introduction
-
-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.
-
-@section 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
-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
-any registers. It is the responsibility of the high-level
-language compiler to define the register preservation and usage
-convention.
-
-@section Calling Mechanism
-
-All RTEMS directives are invoked using a call
-instruction and return to the user application via the ret
-instruction.
-
-@section 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.
-
-@section Parameter Passing
-
-RTEMS assumes that arguments are placed on the
-current stack before the directive is invoked via the call
-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
-push third argument
-push second argument
-push first argument
-invoke directive
-remove arguments from the stack
-@end example
-
-The arguments to RTEMS are typically pushed onto the
-stack using a push instruction. 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 stack pointer.
-
-@section 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.
-
diff --git a/doc/supplements/i386/cpumodel.t b/doc/supplements/i386/cpumodel.t
deleted file mode 100644
index 30109f23a2..0000000000
--- a/doc/supplements/i386/cpumodel.t
+++ /dev/null
@@ -1,72 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter CPU Model Dependent Features
-
-@section Introduction
-
-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 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.
-
-@section 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".
-
-@section bswap Instruction
-
-The macro 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.
-
-@section 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).
diff --git a/doc/supplements/i386/cputable.t b/doc/supplements/i386/cputable.t
deleted file mode 100644
index e7dbf045aa..0000000000
--- a/doc/supplements/i386/cputable.t
+++ /dev/null
@@ -1,119 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Processor Dependent Information Table
-
-@section Introduction
-
-Any highly processor dependent information required
-to describe a processor to RTEMS is provided in the CPU
-Dependent Information Table. This table is not required for all
-processors supported by RTEMS. This chapter describes the
-contents, if any, for a particular processor type.
-
-@section CPU Dependent Information Table
-
-The i386 version of the RTEMS CPU Dependent
-Information Table contains the information required to interface
-a Board Support Package and RTEMS on the i386. This information
-is provided to allow RTEMS to interoperate effectively with the
-BSP. The C structure definition is given here:
-
-@example
-@group
-typedef struct @{
- void (*pretasking_hook)( void );
- void (*predriver_hook)( void );
- void (*idle_task)( void );
- boolean do_zero_of_workspace;
- unsigned32 idle_task_stack_size;
- unsigned32 interrupt_stack_size;
- unsigned32 extra_mpci_receive_server_stack;
- void * (*stack_allocate_hook)( unsigned32 );
- void (*stack_free_hook)( void* );
- /* end of fields required on all CPUs */
-
- unsigned32 interrupt_segment;
- void *interrupt_vector_table;
-@} rtems_cpu_table;
-@end group
-@end example
-
-@table @code
-@item pretasking_hook
-is the address of the user provided routine which is invoked
-once RTEMS APIs are initialized. This routine will be invoked
-before any system tasks are created. Interrupts are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item predriver_hook
-is the address of the user provided
-routine that is invoked immediately before the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item postdriver_hook
-is the address of the user provided
-routine that is invoked immediately after the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item idle_task
-is the address of the optional user
-provided routine which is used as the system's IDLE task. If
-this field is not NULL, then the RTEMS default IDLE task is not
-used. This field may be NULL to indicate that the default IDLE
-is to be used.
-
-@item do_zero_of_workspace
-indicates whether RTEMS should
-zero the Workspace as part of its initialization. If set to
-TRUE, the Workspace is zeroed. Otherwise, it is not.
-
-@item idle_task_stack_size
-is the size of the RTEMS idle task stack in bytes.
-If this number is less than MINIMUM_STACK_SIZE, then the
-idle task's stack will be MINIMUM_STACK_SIZE in byte.
-
-@item interrupt_stack_size
-is the size of the RTEMS
-allocated interrupt stack in bytes. This value must be at least
-as large as MINIMUM_STACK_SIZE.
-
-@item extra_mpci_receive_server_stack
-is the extra stack space allocated for the RTEMS MPCI receive server task
-in bytes. The MPCI receive server may invoke nearly all directives and
-may require extra stack space on some targets.
-
-@item stack_allocate_hook
-is the address of the optional user provided routine which allocates
-memory for task stacks. If this hook is not NULL, then a stack_free_hook
-must be provided as well.
-
-@item stack_free_hook
-is the address of the optional user provided routine which frees
-memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
-must be provided as well.
-
-@item interrupt_segment
-is the value of the selector which should be placed in a segment
-register to access the Interrupt Descriptor Table.
-
-@item interrupt_vector_table
-is the base address of the Interrupt Descriptor Table relative to the
-interrupt_segment.
-
-@end table
-
-The contents of the i386 Interrupt Descriptor Table
-are discussed in Intel's i386 User's Manual. Structure
-definitions for the i386 IDT is provided by including the file
-rtems.h.
-
diff --git a/doc/supplements/i386/fatalerr.t b/doc/supplements/i386/fatalerr.t
deleted file mode 100644
index add48ab643..0000000000
--- a/doc/supplements/i386/fatalerr.t
+++ /dev/null
@@ -1,31 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Default Fatal Error Processing
-
-@section Introduction
-
-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.
-
-@section 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.
-
diff --git a/doc/supplements/i386/i386.texi b/doc/supplements/i386/i386.texi
deleted file mode 100644
index 23c92718bc..0000000000
--- a/doc/supplements/i386/i386.texi
+++ /dev/null
@@ -1,114 +0,0 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename i386.info
-@setcontentsaftertitlepage
-@syncodeindex vr fn
-@synindex ky cp
-@paragraphindent 0
-@c %**end of header
-
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@c
-@c Master file for the Intel i386 Applications Supplement
-@c
-
-@include version.texi
-@include common/setup.texi
-@include common/rtems.texi
-
-@ifset use-ascii
-@dircategory RTEMS Target Supplements
-@direntry
-* RTEMS Intel i386 Applications Supplement: (i386).
-@end direntry
-@end ifset
-
-@c
-@c Title Page Stuff
-@c
-
-@c
-@c I don't really like having a short title page. --joel
-@c
-@c @shorttitlepage RTEMS Intel i386 Applications Supplement
-
-@setchapternewpage odd
-@settitle RTEMS Intel i386 Applications Supplement
-@titlepage
-@finalout
-
-@title RTEMS Intel i386 Applications Supplement
-@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION}
-@sp 1
-@subtitle @value{UPDATED}
-@author On-Line Applications Research Corporation
-@page
-@include common/cpright.texi
-@end titlepage
-
-@c This prevents a black box from being printed on "overflow" lines.
-@c The alternative is to rework a sentence to avoid this problem.
-
-@include preface.texi
-@include cpumodel.texi
-@include callconv.texi
-@include memmodel.texi
-@include intr.texi
-@include fatalerr.texi
-@include bsp.texi
-@include cputable.texi
-@include wksheets.texi
-@include timing.texi
-@include timeFORCE386.texi
-@ifinfo
-@node Top, Preface, (dir), (dir)
-@top i386
-
-This is the online version of the RTEMS Intel i386
-Applications Supplement.
-
-@menu
-* Preface::
-* CPU Model Dependent Features::
-* Calling Conventions::
-* Memory Model::
-* Interrupt Processing::
-* Default Fatal Error Processing::
-* Board Support Packages::
-* Processor Dependent Information Table::
-* Memory Requirements::
-* Timing Specification::
-* CPU386 Timing Data::
-* Command and Variable Index::
-* Concept Index::
-@end menu
-
-@end ifinfo
-@c
-@c
-@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
-@c
-
-@node Command and Variable Index, Concept Index, CPU386 Timing Data Rate Monotonic Manager, Top
-@unnumbered Command and Variable Index
-
-There are currently no Command and Variable Index entries.
-
-@c @printindex fn
-
-@node Concept Index, , Command and Variable Index, Top
-@unnumbered Concept Index
-
-There are currently no Concept Index entries.
-@c @printindex cp
-
-@contents
-@bye
-
diff --git a/doc/supplements/i386/intr_NOTIMES.t b/doc/supplements/i386/intr_NOTIMES.t
deleted file mode 100644
index 1db03127ec..0000000000
--- a/doc/supplements/i386/intr_NOTIMES.t
+++ /dev/null
@@ -1,168 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Interrupt Processing
-
-@section Introduction
-
-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
-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 the processor's response and control mechanisms as they
-pertain to RTEMS.
-
-@section Vectoring of Interrupt Handler
-
-Although the i386 supports multiple privilege levels,
-RTEMS and all user software executes at privilege level 0. This
-decision was made by the RTEMS designers to enhance
-compatibility with processors which do not provide sophisticated
-protection facilities like those of the i386. This decision
-greatly simplifies the discussion of i386 processing, as one
-need only consider interrupts without privilege transitions.
-
-Upon receipt of an interrupt the i386 automatically
-performs the following actions:
-
-@itemize @bullet
-@item pushes the EFLAGS register
-
-@item pushes the far address of the interrupted instruction
-
-@item vectors to the interrupt service routine (ISR).
-@end itemize
-
-A nested interrupt is processed similarly by the
-i386.
-
-@section Interrupt Stack Frame
-
-The structure of the Interrupt Stack Frame for the
-i386 which is placed on the interrupt stack by the processor in
-response to an interrupt is as follows:
-
-@ifset use-ascii
-@example
-@group
- +----------------------+
- | Old EFLAGS Register | ESP+8
- +----------+-----------+
- | UNUSED | Old CS | ESP+4
- +----------+-----------+
- | Old EIP | ESP
- +----------------------+
-@end group
-@end example
-@end ifset
-
-@ifset use-tex
-@sp 1
-@tex
-\centerline{\vbox{\offinterlineskip\halign{
-\strut\vrule#&
-\hbox to 1.00in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.00in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 0.75in{\enskip\hfil#\hfil}
-\cr
-\multispan{4}\hrulefill\cr
-& \multispan{3} Old EFLAGS Register\quad&&ESP+8\cr
-\multispan{4}\hrulefill\cr
-&UNUSED &&Old CS &&ESP+4\cr
-\multispan{4}\hrulefill\cr
-& \multispan{3} Old EIP && ESP\cr
-\multispan{4}\hrulefill\cr
-}}\hfil}
-@end tex
-@end ifset
-
-@ifset use-html
-@html
-<CENTER>
- <TABLE COLS=3 WIDTH="40%" BORDER=2>
-<TR><TD ALIGN=center COLSPAN=2><STRONG>Old EFLAGS Register</STRONG></TD>
- <TD ALIGN=center>0x0</TD></TR>
-<TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD>
- <TD ALIGN=center><STRONG>Old CS</STRONG></TD>
- <TD ALIGN=center>0x2</TD></TR>
-<TR><TD ALIGN=center COLSPAN=2><STRONG>Old EIP</STRONG></TD>
- <TD ALIGN=center>0x4</TD></TR>
- </TABLE>
-</CENTER>
-@end html
-@end ifset
-
-@section Interrupt Levels
-
-Although RTEMS supports 256 interrupt levels, the
-i386 only supports two -- enabled and disabled. Interrupts are
-enabled when the interrupt-enable flag (IF) in the extended
-flags (EFLAGS) is set. Conversely, interrupt processing is
-inhibited when the IF is cleared. During a non-maskable
-interrupt, all other interrupts, including other non-maskable
-ones, are inhibited.
-
-RTEMS interrupt levels 0 and 1 such that level zero
-(0) indicates that interrupts are fully enabled and level one
-that interrupts are disabled. All other RTEMS interrupt levels
-are undefined and their behavior is unpredictable.
-
-@section 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.
-
-@section Interrupt Stack
-
-The i386 family does not support a dedicated hardware
-interrupt stack. On this processor, RTEMS allocates and manages
-a dedicated interrupt stack. As part of vectoring a non-nested
-interrupt service routine, RTEMS switches from the stack of the
-interrupted task to a dedicated interrupt stack. When a
-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.
-
diff --git a/doc/supplements/i386/memmodel.t b/doc/supplements/i386/memmodel.t
deleted file mode 100644
index 4ed5c53b7c..0000000000
--- a/doc/supplements/i386/memmodel.t
+++ /dev/null
@@ -1,72 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@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 Flat Memory Model
-
-RTEMS supports the i386 protected mode, flat memory
-model with paging disabled. In this mode, the i386
-automatically converts every address from a logical to a
-physical address each time it is used. The i386 uses
-information provided in the segment registers and the Global
-Descriptor Table to convert these addresses. RTEMS assumes the
-existence of the following segments:
-
-@itemize @bullet
-@item a single code segment at protection level (0) which
-contains all application and executive code.
-
-@item a single data segment at protection level zero (0) which
-contains all application and executive data.
-@end itemize
-
-The i386 segment registers and associated selectors
-must be initialized when the initialize_executive directive is
-invoked. RTEMS treats the segment registers as system registers
-and does not modify or context switch them.
-
-This i386 memory model 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, 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.
-
diff --git a/doc/supplements/i386/preface.texi b/doc/supplements/i386/preface.texi
deleted file mode 100644
index b33c0671c6..0000000000
--- a/doc/supplements/i386/preface.texi
+++ /dev/null
@@ -1,41 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Preface, CPU Model Dependent Features, Top, Top
-@end ifinfo
-@unnumbered Preface
-
-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.
-
-For information on the i386 processor, refer to the
-following documents:
-
-@itemize @bullet
-@item @cite{386 Programmer's Reference Manual, Intel, Order No. 230985-002}.
-
-@item @cite{386 Microprocessor Hardware Reference Manual, Intel,
-Order No. 231732-003}.
-
-@item @cite{80386 System Software Writer's Guide, Intel, Order No. 231499-001}.
-
-@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.
-
diff --git a/doc/supplements/i386/timeFORCE386.t b/doc/supplements/i386/timeFORCE386.t
deleted file mode 100644
index 56f01ae855..0000000000
--- a/doc/supplements/i386/timeFORCE386.t
+++ /dev/null
@@ -1,101 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@include common/timemac.texi
-@tex
-\global\advance \smallskipamount by -4pt
-@end tex
-
-@chapter CPU386 Timing Data
-
-@section Introduction
-
-The timing data for the i386 version of RTEMS is
-provided along with the target dependent aspects concerning the
-gathering of the timing data. The hardware platform used to
-gather the times is described to give the reader a better
-understanding of each directive time provided. Also, provided
-is a description of the interrupt latency and the context
-switch times as they pertain to the i386 version of RTEMS.
-
-@section Hardware Platform
-
-All times reported except for the maximum period
-interrupts are disabled by RTEMS were measured using a Force
-Computers CPU386 board. The CPU386 is a 16 Mhz board with zero
-wait state dynamic memory and an i80387 numeric coprocessor.
-One of the count-down timers provided by a Motorola MC68901 was
-used to measure elapsed time with one microsecond resolution.
-All sources of hardware interrupts are disabled, although the
-interrupt level of the i386 allows all interrupts.
-
-The maximum period interrupts are disabled was
-measured by summing the number of CPU cycles required by each
-assembly language instruction executed while interrupts were
-disabled. Zero wait state memory was assumed. The total CPU
-cycles executed with interrupts disabled, including the
-instructions to disable and enable interrupts, was divided by 16
-to simulate a i386 executing at 16 Mhz.
-
-@section Interrupt Latency
-
-The maximum period with interrupts disabled within
-RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD microseconds
-including the instructions
-which disable and re-enable interrupts. The time required for
-the i386 to generate an interrupt using the int instruction,
-vectoring to an interrupt handler, and for the RTEMS entry
-overhead before invoking the user's interrupt handler are a
-total of 12 microseconds. These combine to yield a worst case
-interrupt latency of less
-RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds. [NOTE: The
-maximum period with interrupts disabled within RTEMS was last
-calculated for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-It should be noted again that the maximum period with
-interrupts disabled within RTEMS is hand-timed. The interrupt
-vector and entry overhead time was generated on the Force
-Computers CPU386 benchmark platform using the int instruction as
-the interrupt source.
-
-@section Context Switch
-
-The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
-microseconds on the Force Computers CPU386 benchmark platform.
-This time represents the raw context switch time with no user
-extensions configured. Additional execution time is required
-when a TASK_SWITCH user extension is configured. The use of the
-TASK_SWITCH extension is application dependent. Thus, its
-execution time is not considered part of the base context switch
-time.
-
-Since RTEMS was designed specifically for embedded
-missile applications which are floating point intensive, the
-executive is optimized to avoid unnecessarily saving and
-restoring the state of the numeric coprocessor. The state of
-the numeric coprocessor is only saved when a FLOATING_POINT task
-is dispatched and that task was not the last task to utilize the
-coprocessor. In a system with only one FLOATING_POINT task, the
-state of the numeric coprocessor will never be saved or
-restored. When the first FLOATING_POINT task is dispatched,
-RTEMS does not need to save the current state of the numeric
-coprocessor.
-
-The exact amount of time required to save and restore
-floating point context is dependent on the state of the numeric
-coprocessor. RTEMS places the coprocessor in the initialized
-state when a task is started or restarted. Once the task has
-utilized the coprocessor, it is in the idle state when floating
-point instructions are not executing and the busy state when
-floating point instructions are executing. The state of the
-coprocessor is task specific.
-
-The following table summarizes the context switch
-times for the Force Computers CPU386 benchmark platform:
-
diff --git a/doc/supplements/m68k/.cvsignore b/doc/supplements/m68k/.cvsignore
deleted file mode 100644
index 9325d2bc53..0000000000
--- a/doc/supplements/m68k/.cvsignore
+++ /dev/null
@@ -1,31 +0,0 @@
-index.html
-intr.t
-intr.texi
-m68k
-m68k-?
-m68k-??
-m68k.aux
-m68k.cp
-m68k.dvi
-m68k.fn
-m68k*.html
-m68k.ky
-m68k.log
-m68k.pdf
-m68k.pg
-m68k.ps
-m68k.toc
-m68k.tp
-m68k.vr
-Makefile
-Makefile.in
-mdate-sh
-rtems_footer.html
-rtems_header.html
-stamp-vti
-timeMVME136_.t
-timing.t
-timing.texi
-version.texi
-wksheets.t
-wksheets.texi
diff --git a/doc/supplements/m68k/ChangeLog b/doc/supplements/m68k/ChangeLog
deleted file mode 100644
index 5d5375e336..0000000000
--- a/doc/supplements/m68k/ChangeLog
+++ /dev/null
@@ -1,86 +0,0 @@
-2003-12-12 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-12-11 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-11-26 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Add *.info to CLEANFILES to accomodate
- automake-1.7f/1.8 breaking building infos.
-
-2003-09-26 Joel Sherrill <joel@OARcorp.com>
-
- * cpumodel.t: Obsoleting HP PA-RISC port and removing all references.
-
-2003-09-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Merger from rtems-4-6-branch.
-
-2003-09-19 Joel Sherrill <joel@OARcorp.com>
-
- * m68k.texi: Merge from branch.
-
-2003-05-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * cpumodel.t: Reflect c/src/exec having moved to cpukit.
-
-2003-01-25 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * m68k.texi: Set @setfilename m68k.info.
-
-2003-01-24 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Put GENERATED_FILES into $builddir.
-
-2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * version.texi: Remove from CVS.
- * stamp-vti: Remove from CVS.
- * .cvsignore: Add version.texi.
- Add stamp-vti.
- Re-sort.
-
-2003-01-21 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-11-13 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-10-24 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-07-30 Joel Sherrill <joel@OARcorp.com>
-
- * timeMVME136.t, timedata.t: Replaced XXX's with real info.
-
-2002-07-26 Joel Sherrill <joel@OARcorp.com>
-
- * intr_NOTIMES.t: Per PR258, changed single @ to double @ in email
- address to make texinfo happy.
-
-2002-06-28 Joel Sherrill <joel@OARcorp.com>
-
- * intr_NOTIMES.t: Per PR70 incorporate the posting by
- Zoltan Kocsi <zoltan@bendor.com.au> explaining a m68k vectoring trick.
-
-2002-03-27 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Remove AUTOMAKE_OPTIONS.
-
-2002-01-18 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Require automake-1.5.
-
-2001-01-17 Joel Sherrill <joel@OARcorp.com>
-
- * .cvsignore: Added rtems_header.html and rtems_footer.html.
-
-2000-08-10 Joel Sherrill <joel@OARcorp.com>
-
- * ChangeLog: New file.
diff --git a/doc/supplements/m68k/MVME136_TIMES b/doc/supplements/m68k/MVME136_TIMES
deleted file mode 100644
index 5b0dfe6fda..0000000000
--- a/doc/supplements/m68k/MVME136_TIMES
+++ /dev/null
@@ -1,247 +0,0 @@
-#
-# M68020/MVME136 Timing and Size Information
-#
-# $Id$
-#
-
-#
-# CPU Model Information
-#
-RTEMS_BSP MVME136
-RTEMS_CPU_MODEL MC68020
-#
-# Interrupt Latency
-#
-# NOTE: In general, the text says it is hand-calculated to be
-# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-# Mhz and this was last calculated for Release
-# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
-#
-RTEMS_MAXIMUM_DISABLE_PERIOD TBD
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.2.1
-#
-# Context Switch Times
-#
-RTEMS_NO_FP_CONTEXTS 35
-RTEMS_RESTORE_1ST_FP_TASK 39
-RTEMS_SAVE_INIT_RESTORE_INIT 66
-RTEMS_SAVE_IDLE_RESTORE_INIT 66
-RTEMS_SAVE_IDLE_RESTORE_IDLE 68
-#
-# Task Manager Times
-#
-RTEMS_TASK_CREATE_ONLY 148
-RTEMS_TASK_IDENT_ONLY 350
-RTEMS_TASK_START_ONLY 76
-RTEMS_TASK_RESTART_CALLING_TASK 95
-RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89
-RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124
-RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92
-RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125
-RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149
-RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142
-RTEMS_TASK_DELETE_CALLING_TASK 170
-RTEMS_TASK_DELETE_SUSPENDED_TASK 138
-RTEMS_TASK_DELETE_BLOCKED_TASK 143
-RTEMS_TASK_DELETE_READY_TASK 144
-RTEMS_TASK_SUSPEND_CALLING_TASK 71
-RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43
-RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45
-RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67
-RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31
-RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64
-RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106
-RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14
-RTEMS_TASK_MODE_NO_RESCHEDULE 16
-RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23
-RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60
-RTEMS_TASK_GET_NOTE_ONLY 33
-RTEMS_TASK_SET_NOTE_ONLY 33
-RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16
-RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56
-RTEMS_TASK_WAKE_WHEN_ONLY 117
-#
-# Interrupt Manager
-#
-RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12
-RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9
-RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1
-RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8
-RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54
-#
-# Clock Manager
-#
-RTEMS_CLOCK_SET_ONLY 86
-RTEMS_CLOCK_GET_ONLY 1
-RTEMS_CLOCK_TICK_ONLY 17
-#
-# Timer Manager
-#
-RTEMS_TIMER_CREATE_ONLY 28
-RTEMS_TIMER_IDENT_ONLY 343
-RTEMS_TIMER_DELETE_INACTIVE 43
-RTEMS_TIMER_DELETE_ACTIVE 47
-RTEMS_TIMER_FIRE_AFTER_INACTIVE 58
-RTEMS_TIMER_FIRE_AFTER_ACTIVE 61
-RTEMS_TIMER_FIRE_WHEN_INACTIVE 88
-RTEMS_TIMER_FIRE_WHEN_ACTIVE 88
-RTEMS_TIMER_RESET_INACTIVE 54
-RTEMS_TIMER_RESET_ACTIVE 58
-RTEMS_TIMER_CANCEL_INACTIVE 31
-RTEMS_TIMER_CANCEL_ACTIVE 34
-#
-# Semaphore Manager
-#
-RTEMS_SEMAPHORE_CREATE_ONLY 60
-RTEMS_SEMAPHORE_IDENT_ONLY 367
-RTEMS_SEMAPHORE_DELETE_ONLY 58
-RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109
-RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87
-#
-# Message Manager
-#
-RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200
-RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341
-RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80
-RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123
-RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123
-RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133
-RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114
-RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29
-RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39
-#
-# Event Manager
-#
-RTEMS_EVENT_SEND_NO_TASK_READIED 24
-RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60
-RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84
-RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1
-RTEMS_EVENT_RECEIVE_AVAILABLE 28
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84
-#
-# Signal Manager
-#
-RTEMS_SIGNAL_CATCH_ONLY 15
-RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37
-RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54
-#
-# Partition Manager
-#
-RTEMS_PARTITION_CREATE_ONLY 70
-RTEMS_PARTITION_IDENT_ONLY 341
-RTEMS_PARTITION_DELETE_ONLY 42
-RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35
-RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33
-RTEMS_PARTITION_RETURN_BUFFER_ONLY 43
-#
-# Region Manager
-#
-RTEMS_REGION_CREATE_ONLY 63
-RTEMS_REGION_IDENT_ONLY 348
-RTEMS_REGION_DELETE_ONLY 39
-RTEMS_REGION_GET_SEGMENT_AVAILABLE 52
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123
-RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136
-#
-# Dual-Ported Memory Manager
-#
-RTEMS_PORT_CREATE_ONLY 35
-RTEMS_PORT_IDENT_ONLY 340
-RTEMS_PORT_DELETE_ONLY 39
-RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26
-RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27
-#
-# IO Manager
-#
-RTEMS_IO_INITIALIZE_ONLY 4
-RTEMS_IO_OPEN_ONLY 2
-RTEMS_IO_CLOSE_ONLY 1
-RTEMS_IO_READ_ONLY 2
-RTEMS_IO_WRITE_ONLY 3
-RTEMS_IO_CONTROL_ONLY 2
-#
-# Rate Monotonic Manager
-#
-RTEMS_RATE_MONOTONIC_CREATE_ONLY 32
-RTEMS_RATE_MONOTONIC_IDENT_ONLY 341
-RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39
-RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51
-RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48
-RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54
-RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74
-RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31
-#
-# Size Information
-#
-#
-# xxx alloted for numbers
-#
-RTEMS_DATA_SPACE 723
-RTEMS_MINIMUM_CONFIGURATION 18,980
-RTEMS_MAXIMUM_CONFIGURATION 36,438
-# x,xxx alloted for numbers
-RTEMS_CORE_CODE_SIZE 12,674
-RTEMS_INITIALIZATION_CODE_SIZE 970
-RTEMS_TASK_CODE_SIZE 3,562
-RTEMS_INTERRUPT_CODE_SIZE 54
-RTEMS_CLOCK_CODE_SIZE 334
-RTEMS_TIMER_CODE_SIZE 1,110
-RTEMS_SEMAPHORE_CODE_SIZE 1,632
-RTEMS_MESSAGE_CODE_SIZE 1,754
-RTEMS_EVENT_CODE_SIZE 1,000
-RTEMS_SIGNAL_CODE_SIZE 418
-RTEMS_PARTITION_CODE_SIZE 1,164
-RTEMS_REGION_CODE_SIZE 1,494
-RTEMS_DPMEM_CODE_SIZE 724
-RTEMS_IO_CODE_SIZE 686
-RTEMS_FATAL_ERROR_CODE_SIZE 24
-RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212
-RTEMS_MULTIPROCESSING_CODE_SIZE 6.952
-# xxx alloted for numbers
-RTEMS_TIMER_CODE_OPTSIZE 184
-RTEMS_SEMAPHORE_CODE_OPTSIZE 172
-RTEMS_MESSAGE_CODE_OPTSIZE 288
-RTEMS_EVENT_CODE_OPTSIZE 56
-RTEMS_SIGNAL_CODE_OPTSIZE 56
-RTEMS_PARTITION_CODE_OPTSIZE 132
-RTEMS_REGION_CODE_OPTSIZE 160
-RTEMS_DPMEM_CODE_OPTSIZE 132
-RTEMS_IO_CODE_OPTSIZE 00
-RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184
-RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332
-# xxx alloted for numbers
-RTEMS_BYTES_PER_TASK 400
-RTEMS_BYTES_PER_TIMER 68
-RTEMS_BYTES_PER_SEMAPHORE 124
-RTEMS_BYTES_PER_MESSAGE_QUEUE 148
-RTEMS_BYTES_PER_REGION 144
-RTEMS_BYTES_PER_PARTITION 56
-RTEMS_BYTES_PER_PORT 36
-RTEMS_BYTES_PER_PERIOD 36
-RTEMS_BYTES_PER_EXTENSION 64
-RTEMS_BYTES_PER_FP_TASK 332
-RTEMS_BYTES_PER_NODE 48
-RTEMS_BYTES_PER_GLOBAL_OBJECT 20
-RTEMS_BYTES_PER_PROXY 124
-# x,xxx alloted for numbers
-RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872
diff --git a/doc/supplements/m68k/Makefile.am b/doc/supplements/m68k/Makefile.am
deleted file mode 100644
index 31752d1548..0000000000
--- a/doc/supplements/m68k/Makefile.am
+++ /dev/null
@@ -1,111 +0,0 @@
-#
-# COPYRIGHT (c) 1988-2002.
-# On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# $Id$
-#
-
-PROJECT = m68k
-EDITION = 1
-
-include $(top_srcdir)/project.am
-include $(top_srcdir)/supplements/supplement.am
-
-GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \
- fatalerr.texi bsp.texi cputable.texi timing.texi wksheets.texi \
- timeMVME136.texi
-
-COMMON_FILES += $(top_srcdir)/common/cpright.texi \
- $(top_srcdir)/common/timemac.texi
-
-FILES = preface.texi
-
-info_TEXINFOS = m68k.texi
-m68k_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
-
-#
-# Chapters which get automatic processing
-#
-
-cpumodel.texi: cpumodel.t
- $(BMENU2) -p "Preface" \
- -u "Top" \
- -n "Calling Conventions" < $< > $@
-
-callconv.texi: callconv.t
- $(BMENU2) -p "CPU Model Dependent Features Extend Byte to Long Instruction" \
- -u "Top" \
- -n "Memory Model" < $< > $@
-
-memmodel.texi: memmodel.t
- $(BMENU2) -p "Calling Conventions User-Provided Routines" \
- -u "Top" \
- -n "Interrupt Processing" < $< > $@
-
-# Interrupt Chapter:
-# 1. Replace Times and Sizes
-# 2. Build Node Structure
-intr.texi: intr_NOTIMES.t MVME136_TIMES
- ${REPLACE2} -p $(srcdir)/MVME136_TIMES $(srcdir)/intr_NOTIMES.t | \
- $(BMENU2) -p "Memory Model Flat Memory Model" \
- -u "Top" \
- -n "Default Fatal Error Processing" > $@
-
-fatalerr.texi: fatalerr.t
- $(BMENU2) -p "Interrupt Processing Interrupt Stack" \
- -u "Top" \
- -n "Board Support Packages" < $< > $@
-
-bsp.texi: bsp.t
- $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
- -u "Top" \
- -n "Processor Dependent Information Table" < $< > $@
-
-cputable.texi: cputable.t
- $(BMENU2) -p "Board Support Packages Processor Initialization" \
- -u "Top" \
- -n "Memory Requirements" < $< > $@
-
-# Worksheets Chapter:
-# 1. Obtain the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-wksheets.texi: $(top_srcdir)/common/wksheets.t MVME136_TIMES
- ${REPLACE2} -p $(srcdir)/MVME136_TIMES \
- $(top_srcdir)/common/wksheets.t | \
- $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \
- -u "Top" \
- -n "Timing Specification" > $@
-
-# Timing Specification Chapter:
-# 1. Copy the Shared File
-# 3. Build Node Structure
-
-timing.texi: $(top_srcdir)/common/timing.t
- $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \
- -u "Top" \
- -n "MVME136 Timing Data" < $< > $@
-
-# Timing Data for BSP Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-timeMVME136.texi: $(top_srcdir)/common/timetbl.t timeMVME136.t
- cat $(srcdir)/timeMVME136.t $(top_srcdir)/common/timetbl.t >timeMVME136_.t
- @echo >>timeMVME136_.t
- @echo "@tex" >>timeMVME136_.t
- @echo "\\global\\advance \\smallskipamount by 4pt" >>timeMVME136_.t
- @echo "@end tex" >>timeMVME136_.t
- ${REPLACE2} -p $(srcdir)/MVME136_TIMES timeMVME136_.t | \
- $(BMENU2) -p "Timing Specification Terminology" \
- -u "Top" \
- -n "Command and Variable Index" > $@
-CLEANFILES += timeMVME136_.t
-
-EXTRA_DIST = MVME136_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \
- intr_NOTIMES.t memmodel.t timeMVME136.t timedata.t
-
-CLEANFILES += m68k.info m68k.info-?
diff --git a/doc/supplements/m68k/bsp.t b/doc/supplements/m68k/bsp.t
deleted file mode 100644
index 3d245c7719..0000000000
--- a/doc/supplements/m68k/bsp.t
+++ /dev/null
@@ -1,93 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Board Support Packages
-
-@section Introduction
-
-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.
-
-@section 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:
-
-@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 The processor begins execution at the address stored in
-the PC.
-@end itemize
-
-@section 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.
-
-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 MC68020 version has the following
-specific requirements:
-
-@itemize @bullet
-@item Must leave the S bit of the status register set so that
-the MC68020 remains in the supervisor state.
-
-@item Must set the M bit of the status register to remove the
-MC68020 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 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/supplements/m68k/callconv.t b/doc/supplements/m68k/callconv.t
deleted file mode 100644
index e572fb4e64..0000000000
--- a/doc/supplements/m68k/callconv.t
+++ /dev/null
@@ -1,92 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Calling Conventions
-
-@section Introduction
-
-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.
-
-@section 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.
-
-@section Calling Mechanism
-
-All RTEMS directives are invoked using either a bsr
-or jsr instruction and return to the user application via the
-rts instruction.
-
-@section 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.
-
-@section 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.
-
-@section 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.
-
diff --git a/doc/supplements/m68k/cpumodel.t b/doc/supplements/m68k/cpumodel.t
deleted file mode 100644
index 1566b322b5..0000000000
--- a/doc/supplements/m68k/cpumodel.t
+++ /dev/null
@@ -1,91 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter CPU Model Dependent Features
-
-@section Introduction
-
-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.
-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.
-
-@section 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".
-
-@section 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.
-
-@section BFFFO Instruction
-
-The macro M68K_HAS_BFFFO is set to 1 to indicate that
-this CPU model has the bfffo instruction.
-
-@section Vector Base Register
-
-The macro M68K_HAS_VBR is set to 1 to indicate that
-this CPU model has a vector base register (vbr).
-
-@section Separate Stacks
-
-The macro M68K_HAS_SEPARATE_STACKS is set to 1 to
-indicate that this CPU model has separate interrupt, user, and
-supervisor mode stacks.
-
-@section Pre-Indexing Address Mode
-
-The macro M68K_HAS_PREINDEXING is set to 1 to indicate that
-this CPU model has the pre-indexing address mode.
-
-@section Extend Byte to Long Instruction
-
-The macro 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.
diff --git a/doc/supplements/m68k/cputable.t b/doc/supplements/m68k/cputable.t
deleted file mode 100644
index a70e89929f..0000000000
--- a/doc/supplements/m68k/cputable.t
+++ /dev/null
@@ -1,109 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Processor Dependent Information Table
-
-@section Introduction
-
-Any highly processor dependent information required
-to describe a processor to RTEMS is provided in the CPU
-Dependent Information Table. This table is not required for all
-processors supported by RTEMS. This chapter describes the
-contents, if any, for a particular processor type.
-
-@section CPU Dependent Information Table
-
-The MC68xxx version of the RTEMS CPU Dependent
-Information Table contains the information required to interface
-a Board Support Package and RTEMS on the MC68xxx. This
-information is provided to allow RTEMS to interoperate
-effectively with the BSP. The C structure definition is given
-here:
-
-@example
-@group
-typedef struct @{
- void (*pretasking_hook)( void );
- void (*predriver_hook)( void );
- void (*postdriver_hook)( void );
- void (*idle_task)( void );
- boolean do_zero_of_workspace;
- unsigned32 idle_task_stack_size;
- unsigned32 interrupt_stack_size;
- unsigned32 extra_mpci_receive_server_stack;
- void * (*stack_allocate_hook)( unsigned32 );
- void (*stack_free_hook)( void* );
- /* end of fields required on all CPUs */
-
- m68k_isr *interrupt_vector_table;
-@} rtems_cpu_table;
-@end group
-@end example
-
-@table @code
-@item pretasking_hook
-is the address of the user provided routine which is invoked
-once RTEMS APIs are initialized. This routine will be invoked
-before any system tasks are created. Interrupts are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item predriver_hook
-is the address of the user provided
-routine that is invoked immediately before the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item postdriver_hook
-is the address of the user provided
-routine that is invoked immediately after the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item idle_task
-is the address of the optional user
-provided routine which is used as the system's IDLE task. If
-this field is not NULL, then the RTEMS default IDLE task is not
-used. This field may be NULL to indicate that the default IDLE
-is to be used.
-
-@item do_zero_of_workspace
-indicates whether RTEMS should
-zero the Workspace as part of its initialization. If set to
-TRUE, the Workspace is zeroed. Otherwise, it is not.
-
-@item idle_task_stack_size
-is the size of the RTEMS idle task stack in bytes.
-If this number is less than MINIMUM_STACK_SIZE, then the
-idle task's stack will be MINIMUM_STACK_SIZE in byte.
-
-@item interrupt_stack_size
-is the size of the RTEMS
-allocated interrupt stack in bytes. This value must be at least
-as large as MINIMUM_STACK_SIZE.
-
-@item extra_mpci_receive_server_stack
-is the extra stack space allocated for the RTEMS MPCI receive server task
-in bytes. The MPCI receive server may invoke nearly all directives and
-may require extra stack space on some targets.
-
-@item stack_allocate_hook
-is the address of the optional user provided routine which allocates
-memory for task stacks. If this hook is not NULL, then a stack_free_hook
-must be provided as well.
-
-@item stack_free_hook
-is the address of the optional user provided routine which frees
-memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
-must be provided as well.
-
-@item interrupt_vector_table
-is the base address of the CPU's Exception Vector Table.
-
-@end table
diff --git a/doc/supplements/m68k/fatalerr.t b/doc/supplements/m68k/fatalerr.t
deleted file mode 100644
index 728d149f37..0000000000
--- a/doc/supplements/m68k/fatalerr.t
+++ /dev/null
@@ -1,31 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Default Fatal Error Processing
-
-@section Introduction
-
-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.
-
-@section 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.
-
diff --git a/doc/supplements/m68k/intr_NOTIMES.t b/doc/supplements/m68k/intr_NOTIMES.t
deleted file mode 100644
index 2568c9f5fa..0000000000
--- a/doc/supplements/m68k/intr_NOTIMES.t
+++ /dev/null
@@ -1,266 +0,0 @@
-@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
-
-@chapter Interrupt Processing
-
-@section Introduction
-
-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.
-
-@section 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.
-
-@subsection Models Without Separate Interrupt Stacks
-
-Upon receipt of an interrupt the MC68xxx family
-members without separate interrupt stacks automatically perform
-the following actions:
-
-@itemize @bullet
-@item To Be Written
-@end itemize
-
-@subsection Models With Separate Interrupt Stacks
-
-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),
-
-@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 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
-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
-MC68xxx 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
-
-@section CPU Models Without VBR and RAM at 0
-
-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.
-
-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
-//
-// Real vector table at 0
-//
-
- .long initial_sp
- .long initial_pc
- .long myhandler+0x02000000
- .long myhandler+0x03000000
- .long myhandler+0x04000000
- ...
- .long myhandler+0xff000000
-
-
-//
-// This handler will jump to the interrupt routine of which
-// the address is stored at VBR[ vector_no ]
-// The registers and stackframe will be intact, the interrupt
-// routine will see exactly what it would see if it was called
-// directly from the HW vector table at 0.
-//
-
- .comm VBR,4,2 // This defines the 'virtual' VBR
- // From C: extern void *VBR;
-
-myhandler: // At entry, PC contains the full vector
- move.l %d0,-(%sp) // Save d0
- move.l %a0,-(%sp) // Save a0
- lea 0(%pc),%a0 // Get the value of the PC
- move.l %a0,%d0 // Copy it to a data reg, d0 is VV??????
- swap %d0 // Now d0 is ????VV??
- and.w #0xff00,%d0 // Now d0 is ????VV00 (1)
- lsr.w #6,%d0 // Now d0.w contains the VBR table offset
- move.l VBR,%a0 // Get the address from VBR to a0
- move.l (%a0,%d0.w),%a0 // Fetch the vector
- move.l 4(%sp),%d0 // Restore d0
- move.l %a0,4(%sp) // Place target address to the stack
- move.l (%sp)+,%a0 // Restore a0, target address is on TOS
- ret // This will jump to the handler and
- // restore the stack
-
-(1) If 'myhandler' is guaranteed to be in the first 64K, e.g. just
- after the vector table then that insn is not needed.
-
-@end example
-
-There are probably shorter ways to do this, but it I believe is enough
-to illustrate the trick. Optimisation is left as an exercise to the
-reader :-)
-
-
-@section Interrupt Levels
-
-Eight levels (0-7) of interrupt priorities are
-supported by MC68xxx 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
-MC68xxx family only supports eight. RTEMS interrupt levels 0
-through 7 directly correspond to MC68xxx interrupt levels. All
-other RTEMS interrupt levels are undefined and their behavior is
-unpredictable.
-
-@section 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.
-
-@section 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.
-
-
diff --git a/doc/supplements/m68k/m68k.texi b/doc/supplements/m68k/m68k.texi
deleted file mode 100644
index b14c58e62f..0000000000
--- a/doc/supplements/m68k/m68k.texi
+++ /dev/null
@@ -1,115 +0,0 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename m68k.info
-@setcontentsaftertitlepage
-@syncodeindex vr fn
-@synindex ky cp
-@paragraphindent 0
-@c %**end of header
-
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@c
-@c Master file for the Motorola MC68xxx Applications Supplement
-@c
-
-@include version.texi
-@include common/setup.texi
-@include common/rtems.texi
-
-@ifset use-ascii
-@dircategory RTEMS Target Supplements
-@direntry
-* RTEMS Motorola MC68xxx Applications Supplement: (m68k).
-@end direntry
-@end ifset
-
-@c
-@c Title Page Stuff
-@c
-
-@c
-@c I don't really like having a short title page. --joel
-@c
-@c @shorttitlepage RTEMS Motorola MC68xxx Applications Supplement
-
-@setchapternewpage odd
-@settitle RTEMS Motorola MC68xxx Applications Supplement
-@titlepage
-@finalout
-
-@title RTEMS Motorola MC68xxx Applications Supplement
-@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION}
-@sp 1
-@subtitle @value{UPDATED}
-@author On-Line Applications Research Corporation
-@page
-
-@include common/cpright.texi
-@end titlepage
-
-@c This prevents a black box from being printed on "overflow" lines.
-@c The alternative is to rework a sentence to avoid this problem.
-
-@include preface.texi
-@include cpumodel.texi
-@include callconv.texi
-@include memmodel.texi
-@include intr.texi
-@include fatalerr.texi
-@include bsp.texi
-@include cputable.texi
-@include wksheets.texi
-@include timing.texi
-@include timeMVME136.texi
-@ifinfo
-@node Top, Preface, (dir), (dir)
-@top m68k
-
-This is the online version of the RTEMS Motorola MC68xxx
-Applications Supplement.
-
-@menu
-* Preface::
-* CPU Model Dependent Features::
-* Calling Conventions::
-* Memory Model::
-* Interrupt Processing::
-* Default Fatal Error Processing::
-* Board Support Packages::
-* Processor Dependent Information Table::
-* Memory Requirements::
-* Timing Specification::
-* MVME136 Timing Data::
-* Command and Variable Index::
-* Concept Index::
-@end menu
-
-@end ifinfo
-@c
-@c
-@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
-@c
-
-@node Command and Variable Index, Concept Index, MVME136 Timing Data Rate Monotonic Manager, Top
-@unnumbered Command and Variable Index
-
-There are currently no Command and Variable Index entries.
-
-@c @printindex fn
-
-@node Concept Index, , Command and Variable Index, Top
-@unnumbered Concept Index
-
-There are currently no Concept Index entries.
-@c @printindex cp
-
-@contents
-@bye
-
diff --git a/doc/supplements/m68k/memmodel.t b/doc/supplements/m68k/memmodel.t
deleted file mode 100644
index 7b7776050c..0000000000
--- a/doc/supplements/m68k/memmodel.t
+++ /dev/null
@@ -1,39 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@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 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
-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.
-
-Some of the MC68xxx family members such as the
-MC68020, MC68030, and MC68040 support virtual memory and
-segmentation. The MC68020 requires external hardware support
-such as the MC68851 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 MC68xxx family members.
-
diff --git a/doc/supplements/m68k/preface.texi b/doc/supplements/m68k/preface.texi
deleted file mode 100644
index e37038f439..0000000000
--- a/doc/supplements/m68k/preface.texi
+++ /dev/null
@@ -1,60 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Preface, CPU Model Dependent Features, Top, Top
-@end ifinfo
-@unnumbered Preface
-
-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
-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/}):
-
-@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}.
-@end itemize
-
diff --git a/doc/supplements/m68k/timeMVME136.t b/doc/supplements/m68k/timeMVME136.t
deleted file mode 100644
index 16933e8055..0000000000
--- a/doc/supplements/m68k/timeMVME136.t
+++ /dev/null
@@ -1,112 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@include common/timemac.texi
-@tex
-\global\advance \smallskipamount by -4pt
-@end tex
-
-@chapter MVME136 Timing Data
-
-@section Introduction
-
-The timing data for the MC68020 version of RTEMS is
-provided along with the target dependent aspects concerning the
-gathering of the timing data. The hardware platform used to
-gather the times is described to give the reader a better
-understanding of each directive time provided. Also, provided
-is a description of the interrupt latency and the context switch
-times as they pertain to the MC68020 version of RTEMS.
-
-@section Hardware Platform
-
-All times reported except for the maximum period
-interrupts are disabled by RTEMS were measured using a Motorola
-MVME135 CPU board. The MVME135 is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz board with one wait
-state dynamic memory and a MC68881 numeric coprocessor. The
-Zilog 8036 countdown timer on this board was used to measure
-elapsed time with a one-half microsecond resolution. All
-sources of hardware interrupts were disabled, although the
-interrupt level of the MC68020 allows all interrupts.
-
-The maximum period interrupts are disabled was
-measured by summing the number of CPU cycles required by each
-assembly language instruction executed while interrupts were
-disabled. The worst case times of the MC68020 microprocessor
-were used for each instruction. Zero wait state memory was
-assumed. The total CPU cycles executed with interrupts
-disabled, including the instructions to disable and enable
-interrupts, was divided by 20 to simulate a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz MC68020. It
-should be noted that the worst case instruction times for the
-MC68020 assume that the internal cache is disabled and that no
-instructions overlap.
-
-@section Interrupt Latency
-
-The maximum period with interrupts disabled within
-RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD
-microseconds including the instructions
-which disable and re-enable interrupts. The time required for
-the MC68020 to vector an interrupt and for the RTEMS entry
-overhead before invoking the user's interrupt handler are a
-total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds. These combine to yield a worst case
-interrupt latency of less than
-RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz. [NOTE: The maximum period with interrupts
-disabled was last determined for Release
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-It should be noted again that the maximum period with
-interrupts disabled within RTEMS is hand-timed and based upon
-worst case (i.e. CPU cache disabled and no instruction overlap)
-times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz MC68020. The interrupt vector and entry
-overhead time was generated on an MVME135 benchmark platform
-using the Multiprocessing Communications registers to generate
-as the interrupt source.
-
-@section Context Switch
-
-The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
-microseconds on the MVME135 benchmark platform when no floating
-point context is saved or restored. Additional execution time
-is required when a TASK_SWITCH user extension is configured.
-The use of the TASK_SWITCH extension is application dependent.
-Thus, its execution time is not considered part of the raw
-context switch time.
-
-Since RTEMS was designed specifically for embedded
-missile applications which are floating point intensive, the
-executive is optimized to avoid unnecessarily saving and
-restoring the state of the numeric coprocessor. The state of
-the numeric coprocessor is only saved when an FLOATING_POINT
-task is dispatched and that task was not the last task to
-utilize the coprocessor. In a system with only one
-FLOATING_POINT task, the state of the numeric coprocessor will
-never be saved or restored. When the first FLOATING_POINT task
-is dispatched, RTEMS does not need to save the current state of
-the numeric coprocessor.
-
-The exact amount of time required to save and restore
-floating point context is dependent on whether an MC68881 or
-MC68882 is being used as well as the state of the numeric
-coprocessor. These numeric coprocessors define three operating
-states: initialized, idle, and busy. RTEMS places the
-coprocessor in the initialized state when a task is started or
-restarted. Once the task has utilized the coprocessor, it is in
-the idle state when floating point instructions are not
-executing and the busy state when floating point instructions
-are executing. The state of the coprocessor is task specific.
-
-The following table summarizes the context switch
-times for the MVME135 benchmark platform:
-
diff --git a/doc/supplements/m68k/timedata.t b/doc/supplements/m68k/timedata.t
deleted file mode 100644
index 72171445ab..0000000000
--- a/doc/supplements/m68k/timedata.t
+++ /dev/null
@@ -1,154 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@include common/timemac.texi
-@tex
-\global\advance \smallskipamount by -4pt
-@end tex
-
-@ifinfo
-@node MVME136 Timing Data, MVME136 Timing Data Introduction, Timing Specification Terminology, Top
-@end ifinfo
-@chapter MVME136 Timing Data
-@ifinfo
-@menu
-* MVME136 Timing Data Introduction::
-* MVME136 Timing Data Hardware Platform::
-* MVME136 Timing Data Interrupt Latency::
-* MVME136 Timing Data Context Switch::
-* MVME136 Timing Data Directive Times::
-* MVME136 Timing Data Task Manager::
-* MVME136 Timing Data Interrupt Manager::
-* MVME136 Timing Data Clock Manager::
-* MVME136 Timing Data Timer Manager::
-* MVME136 Timing Data Semaphore Manager::
-* MVME136 Timing Data Message Manager::
-* MVME136 Timing Data Event Manager::
-* MVME136 Timing Data Signal Manager::
-* MVME136 Timing Data Partition Manager::
-* MVME136 Timing Data Region Manager::
-* MVME136 Timing Data Dual-Ported Memory Manager::
-* MVME136 Timing Data I/O Manager::
-* MVME136 Timing Data Rate Monotonic Manager::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node MVME136 Timing Data Introduction, MVME136 Timing Data Hardware Platform, MVME136 Timing Data, MVME136 Timing Data
-@end ifinfo
-@section Introduction
-
-The timing data for the MC68020 version of RTEMS is
-provided along with the target dependent aspects concerning the
-gathering of the timing data. The hardware platform used to
-gather the times is described to give the reader a better
-understanding of each directive time provided. Also, provided
-is a description of the interrupt latency and the context switch
-times as they pertain to the MC68020 version of RTEMS.
-
-@ifinfo
-@node MVME136 Timing Data Hardware Platform, MVME136 Timing Data Interrupt Latency, MVME136 Timing Data Introduction, MVME136 Timing Data
-@end ifinfo
-@section Hardware Platform
-
-All times reported except for the maximum period
-interrupts are disabled by RTEMS were measured using a Motorola
-MVME135 CPU board. The MVME135 is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz board with one wait
-state dynamic memory and a MC68881 numeric coprocessor. The
-Zilog 8036 countdown timer on this board was used to measure
-elapsed time with a one-half microsecond resolution. All
-sources of hardware interrupts were disabled, although the
-interrupt level of the MC68020 allows all interrupts.
-
-The maximum period interrupts are disabled was
-measured by summing the number of CPU cycles required by each
-assembly language instruction executed while interrupts were
-disabled. The worst case times of the MC68020 microprocessor
-were used for each instruction. Zero wait state memory was
-assumed. The total CPU cycles executed with interrupts
-disabled, including the instructions to disable and enable
-interrupts, was divided by 20 to simulate a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz MC68020. It
-should be noted that the worst case instruction times for the
-MC68020 assume that the internal cache is disabled and that no
-instructions overlap.
-
-@ifinfo
-@node MVME136 Timing Data Interrupt Latency, MVME136 Timing Data Context Switch, MVME136 Timing Data Hardware Platform, MVME136 Timing Data
-@end ifinfo
-@section Interrupt Latency
-
-The maximum period with interrupts disabled within
-RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD
-microseconds including the instructions
-which disable and re-enable interrupts. The time required for
-the MC68020 to vector an interrupt and for the RTEMS entry
-overhead before invoking the user's interrupt handler are a
-total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds. These combine to yield a worst case
-interrupt latency of less than
-RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz. [NOTE: The maximum period with interrupts
-disabled was last determined for Release
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-It should be noted again that the maximum period with
-interrupts disabled within RTEMS is hand-timed and based upon
-worst case (i.e. CPU cache disabled and no instruction overlap)
-times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz MC68020. The interrupt vector and entry
-overhead time was generated on an MVME135 benchmark platform
-using the Multiprocessing Communications registers to generate
-as the interrupt source.
-
-@ifinfo
-@node MVME136 Timing Data Context Switch, MVME136 Timing Data Directive Times, MVME136 Timing Data Interrupt Latency, MVME136 Timing Data
-@end ifinfo
-@section Context Switch
-
-The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
-microseconds on the MVME135 benchmark platform when no floating
-point context is saved or restored. Additional execution time
-is required when a TASK_SWITCH user extension is configured.
-The use of the TASK_SWITCH extension is application dependent.
-Thus, its execution time is not considered part of the raw
-context switch time.
-
-Since RTEMS was designed specifically for embedded
-missile applications which are floating point intensive, the
-executive is optimized to avoid unnecessarily saving and
-restoring the state of the numeric coprocessor. The state of
-the numeric coprocessor is only saved when an FLOATING_POINT
-task is dispatched and that task was not the last task to
-utilize the coprocessor. In a system with only one
-FLOATING_POINT task, the state of the numeric coprocessor will
-never be saved or restored. When the first FLOATING_POINT task
-is dispatched, RTEMS does not need to save the current state of
-the numeric coprocessor.
-
-The exact amount of time required to save and restore
-floating point context is dependent on whether an MC68881 or
-MC68882 is being used as well as the state of the numeric
-coprocessor. These numeric coprocessors define three operating
-states: initialized, idle, and busy. RTEMS places the
-coprocessor in the initialized state when a task is started or
-restarted. Once the task has utilized the coprocessor, it is in
-the idle state when floating point instructions are not
-executing and the busy state when floating point instructions
-are executing. The state of the coprocessor is task specific.
-
-The following table summarizes the context switch
-times for the MVME135 benchmark platform:
-
-@include timetbl.texi
-
-@tex
-\global\advance \smallskipamount by 4pt
-@end tex
diff --git a/doc/supplements/mips/.cvsignore b/doc/supplements/mips/.cvsignore
deleted file mode 100644
index 9ab9e0fec7..0000000000
--- a/doc/supplements/mips/.cvsignore
+++ /dev/null
@@ -1,31 +0,0 @@
-index.html
-intr.t
-intr.texi
-Makefile
-Makefile.in
-mdate-sh
-mips
-mips-?
-mips-??
-mips.aux
-mips.cp
-mips.dvi
-mips.fn
-mips*.html
-mips.ky
-mips.log
-mips.pdf
-mips.pg
-mips.ps
-mips.toc
-mips.tp
-mips.vr
-rtems_footer.html
-rtems_header.html
-stamp-vti
-timeBSP_.t
-timing.t
-timing.texi
-version.texi
-wksheets.t
-wksheets.texi
diff --git a/doc/supplements/mips/BSP_TIMES b/doc/supplements/mips/BSP_TIMES
deleted file mode 100644
index 82b8160aa5..0000000000
--- a/doc/supplements/mips/BSP_TIMES
+++ /dev/null
@@ -1,247 +0,0 @@
-#
-# CPU MODEL/BSP Timing and Size Information
-#
-# $Id$
-#
-
-#
-# CPU Model Information
-#
-RTEMS_BSP BSPFORTIMES
-RTEMS_CPU_MODEL BSP_CPU_MODEL
-#
-# Interrupt Latency
-#
-# NOTE: In general, the text says it is hand-calculated to be
-# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-# Mhz and this was last calculated for Release
-# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
-#
-RTEMS_MAXIMUM_DISABLE_PERIOD TBD
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0
-#
-# Context Switch Times
-#
-RTEMS_NO_FP_CONTEXTS 35
-RTEMS_RESTORE_1ST_FP_TASK 39
-RTEMS_SAVE_INIT_RESTORE_INIT 66
-RTEMS_SAVE_IDLE_RESTORE_INIT 66
-RTEMS_SAVE_IDLE_RESTORE_IDLE 68
-#
-# Task Manager Times
-#
-RTEMS_TASK_CREATE_ONLY 148
-RTEMS_TASK_IDENT_ONLY 350
-RTEMS_TASK_START_ONLY 76
-RTEMS_TASK_RESTART_CALLING_TASK 95
-RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89
-RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124
-RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92
-RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125
-RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149
-RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142
-RTEMS_TASK_DELETE_CALLING_TASK 170
-RTEMS_TASK_DELETE_SUSPENDED_TASK 138
-RTEMS_TASK_DELETE_BLOCKED_TASK 143
-RTEMS_TASK_DELETE_READY_TASK 144
-RTEMS_TASK_SUSPEND_CALLING_TASK 71
-RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43
-RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45
-RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67
-RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31
-RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64
-RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106
-RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14
-RTEMS_TASK_MODE_NO_RESCHEDULE 16
-RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23
-RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60
-RTEMS_TASK_GET_NOTE_ONLY 33
-RTEMS_TASK_SET_NOTE_ONLY 33
-RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16
-RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56
-RTEMS_TASK_WAKE_WHEN_ONLY 117
-#
-# Interrupt Manager
-#
-RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12
-RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9
-RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1
-RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8
-RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54
-#
-# Clock Manager
-#
-RTEMS_CLOCK_SET_ONLY 86
-RTEMS_CLOCK_GET_ONLY 1
-RTEMS_CLOCK_TICK_ONLY 17
-#
-# Timer Manager
-#
-RTEMS_TIMER_CREATE_ONLY 28
-RTEMS_TIMER_IDENT_ONLY 343
-RTEMS_TIMER_DELETE_INACTIVE 43
-RTEMS_TIMER_DELETE_ACTIVE 47
-RTEMS_TIMER_FIRE_AFTER_INACTIVE 58
-RTEMS_TIMER_FIRE_AFTER_ACTIVE 61
-RTEMS_TIMER_FIRE_WHEN_INACTIVE 88
-RTEMS_TIMER_FIRE_WHEN_ACTIVE 88
-RTEMS_TIMER_RESET_INACTIVE 54
-RTEMS_TIMER_RESET_ACTIVE 58
-RTEMS_TIMER_CANCEL_INACTIVE 31
-RTEMS_TIMER_CANCEL_ACTIVE 34
-#
-# Semaphore Manager
-#
-RTEMS_SEMAPHORE_CREATE_ONLY 60
-RTEMS_SEMAPHORE_IDENT_ONLY 367
-RTEMS_SEMAPHORE_DELETE_ONLY 58
-RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109
-RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87
-#
-# Message Manager
-#
-RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200
-RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341
-RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80
-RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123
-RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123
-RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133
-RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114
-RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29
-RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39
-#
-# Event Manager
-#
-RTEMS_EVENT_SEND_NO_TASK_READIED 24
-RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60
-RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84
-RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1
-RTEMS_EVENT_RECEIVE_AVAILABLE 28
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84
-#
-# Signal Manager
-#
-RTEMS_SIGNAL_CATCH_ONLY 15
-RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37
-RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54
-#
-# Partition Manager
-#
-RTEMS_PARTITION_CREATE_ONLY 70
-RTEMS_PARTITION_IDENT_ONLY 341
-RTEMS_PARTITION_DELETE_ONLY 42
-RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35
-RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33
-RTEMS_PARTITION_RETURN_BUFFER_ONLY 43
-#
-# Region Manager
-#
-RTEMS_REGION_CREATE_ONLY 63
-RTEMS_REGION_IDENT_ONLY 348
-RTEMS_REGION_DELETE_ONLY 39
-RTEMS_REGION_GET_SEGMENT_AVAILABLE 52
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123
-RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136
-#
-# Dual-Ported Memory Manager
-#
-RTEMS_PORT_CREATE_ONLY 35
-RTEMS_PORT_IDENT_ONLY 340
-RTEMS_PORT_DELETE_ONLY 39
-RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26
-RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27
-#
-# IO Manager
-#
-RTEMS_IO_INITIALIZE_ONLY 4
-RTEMS_IO_OPEN_ONLY 2
-RTEMS_IO_CLOSE_ONLY 1
-RTEMS_IO_READ_ONLY 2
-RTEMS_IO_WRITE_ONLY 3
-RTEMS_IO_CONTROL_ONLY 2
-#
-# Rate Monotonic Manager
-#
-RTEMS_RATE_MONOTONIC_CREATE_ONLY 32
-RTEMS_RATE_MONOTONIC_IDENT_ONLY 341
-RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39
-RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51
-RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48
-RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54
-RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74
-RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31
-#
-# Size Information
-#
-#
-# xxx alloted for numbers
-#
-RTEMS_DATA_SPACE 723
-RTEMS_MINIMUM_CONFIGURATION 18,980
-RTEMS_MAXIMUM_CONFIGURATION 36,438
-# x,xxx alloted for numbers
-RTEMS_CORE_CODE_SIZE 12,674
-RTEMS_INITIALIZATION_CODE_SIZE 970
-RTEMS_TASK_CODE_SIZE 3,562
-RTEMS_INTERRUPT_CODE_SIZE 54
-RTEMS_CLOCK_CODE_SIZE 334
-RTEMS_TIMER_CODE_SIZE 1,110
-RTEMS_SEMAPHORE_CODE_SIZE 1,632
-RTEMS_MESSAGE_CODE_SIZE 1,754
-RTEMS_EVENT_CODE_SIZE 1,000
-RTEMS_SIGNAL_CODE_SIZE 418
-RTEMS_PARTITION_CODE_SIZE 1,164
-RTEMS_REGION_CODE_SIZE 1,494
-RTEMS_DPMEM_CODE_SIZE 724
-RTEMS_IO_CODE_SIZE 686
-RTEMS_FATAL_ERROR_CODE_SIZE 24
-RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212
-RTEMS_MULTIPROCESSING_CODE_SIZE 6.952
-# xxx alloted for numbers
-RTEMS_TIMER_CODE_OPTSIZE 184
-RTEMS_SEMAPHORE_CODE_OPTSIZE 172
-RTEMS_MESSAGE_CODE_OPTSIZE 288
-RTEMS_EVENT_CODE_OPTSIZE 56
-RTEMS_SIGNAL_CODE_OPTSIZE 56
-RTEMS_PARTITION_CODE_OPTSIZE 132
-RTEMS_REGION_CODE_OPTSIZE 160
-RTEMS_DPMEM_CODE_OPTSIZE 132
-RTEMS_IO_CODE_OPTSIZE 00
-RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184
-RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332
-# xxx alloted for numbers
-RTEMS_BYTES_PER_TASK 400
-RTEMS_BYTES_PER_TIMER 68
-RTEMS_BYTES_PER_SEMAPHORE 124
-RTEMS_BYTES_PER_MESSAGE_QUEUE 148
-RTEMS_BYTES_PER_REGION 144
-RTEMS_BYTES_PER_PARTITION 56
-RTEMS_BYTES_PER_PORT 36
-RTEMS_BYTES_PER_PERIOD 36
-RTEMS_BYTES_PER_EXTENSION 64
-RTEMS_BYTES_PER_FP_TASK 332
-RTEMS_BYTES_PER_NODE 48
-RTEMS_BYTES_PER_GLOBAL_OBJECT 20
-RTEMS_BYTES_PER_PROXY 124
-# x,xxx alloted for numbers
-RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872
diff --git a/doc/supplements/mips/ChangeLog b/doc/supplements/mips/ChangeLog
deleted file mode 100644
index 1b34f35c37..0000000000
--- a/doc/supplements/mips/ChangeLog
+++ /dev/null
@@ -1,76 +0,0 @@
-2003-12-12 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-12-11 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-11-26 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Add *.info to CLEANFILES to accomodate
- automake-1.7f/1.8 breaking building infos.
-
-2003-09-26 Joel Sherrill <joel@OARcorp.com>
-
- * cpumodel.t: Obsoleting HP PA-RISC port and removing all references.
-
-2003-09-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Merger from rtems-4-6-branch.
-
-2003-09-19 Joel Sherrill <joel@OARcorp.com>
-
- * mips.texi: Merge from branch.
-
-2003-05-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * cpumodel.t: Reflect c/src/exec having moved to cpukit.
-
-2003-01-25 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * mips.texi: Set @setfilename mips.info.
-
-2003-01-24 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Put GENERATED_FILES into $builddir.
-
-2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * version.texi: Remove from CVS.
- * stamp-vti: Remove from CVS.
- * .cvsignore: Add version.texi.
- Add stamp-vti.
- Re-sort.
-
-2003-01-21 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-11-13 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-10-24 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-07-30 Joel Sherrill <joel@OARcorp.com>
-
- * .cvsignore: Corrected some errors.
- * intr_NOTIMES.t, timeBSP.t: Replaced XXX's with real info.
-
-2002-03-27 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Remove AUTOMAKE_OPTIONS.
-
-2001-03-01 Joel Sherrill <joel@OARcorp.com>
-
- * .cvsignore: New file.
-
-2002-02-04 Joel Sherrill <joel@OARcorp.com>
-
- * bsp.t, BSP_TIMES, callconv.t, ChangeLog, cpumodel.t, cputable.t,
- fatalerr.t, intr_NOTIMES.t, Makefile.am, memmodel.t, mips.texi,
- preface.texi, stamp-vti, timeBSP.t, version.texi: New files.
-
diff --git a/doc/supplements/mips/Makefile.am b/doc/supplements/mips/Makefile.am
deleted file mode 100644
index e45ba428fa..0000000000
--- a/doc/supplements/mips/Makefile.am
+++ /dev/null
@@ -1,111 +0,0 @@
-#
-# COPYRIGHT (c) 1988-2002.
-# On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# $Id$
-#
-
-PROJECT = mips
-EDITION = 1
-
-include $(top_srcdir)/project.am
-include $(top_srcdir)/supplements/supplement.am
-
-GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \
- fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \
- timeBSP.texi
-
-COMMON_FILES += $(top_srcdir)/common/cpright.texi \
- $(top_srcdir)/common/timemac.texi
-
-FILES = preface.texi
-
-info_TEXINFOS = mips.texi
-mips_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
-
-#
-# Chapters which get automatic processing
-#
-
-cpumodel.texi: cpumodel.t
- $(BMENU2) -p "Preface" \
- -u "Top" \
- -n "Calling Conventions" < $< > $@
-
-callconv.texi: callconv.t
- $(BMENU2) -p "CPU Model Dependent Features Another Optional Feature" \
- -u "Top" \
- -n "Memory Model" < $< > $@
-
-memmodel.texi: memmodel.t
- $(BMENU2) -p "Calling Conventions User-Provided Routines" \
- -u "Top" \
- -n "Interrupt Processing" < $< > $@
-
-# Interrupt Chapter:
-# 1. Replace Times and Sizes
-# 2. Build Node Structure
-intr.texi: intr_NOTIMES.t BSP_TIMES
- ${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \
- $(BMENU2) -p "Memory Model Flat Memory Model" \
- -u "Top" \
- -n "Default Fatal Error Processing" > $@
-
-fatalerr.texi: fatalerr.t
- $(BMENU2) -p "Interrupt Processing Interrupt Stack" \
- -u "Top" \
- -n "Board Support Packages" < $< > $@
-
-bsp.texi: bsp.t
- $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
- -u "Top" \
- -n "Processor Dependent Information Table" < $< > $@
-
-cputable.texi: cputable.t
- $(BMENU2) -p "Board Support Packages Processor Initialization" \
- -u "Top" \
- -n "Memory Requirements" < $< > $@
-
-# Worksheets Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES
- ${REPLACE2} -p $(srcdir)/BSP_TIMES \
- $(top_srcdir)/common/wksheets.t | \
- $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \
- -u "Top" \
- -n "Timing Specification" > $@
-
-# Timing Specification Chapter:
-# 1. Copy the Shared File
-# 3. Build Node Structure
-
-timing.texi: $(top_srcdir)/common/timing.t
- $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \
- -u "Top" \
- -n "BSP_FOR_TIMES Timing Data" < $< > $@
-
-# Timing Data for BSP Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t
- cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t
- @echo >>timeBSP_.t
- @echo "@tex" >>timeBSP_.t
- @echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t
- @echo "@end tex" >>timeBSP_.t
- ${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \
- $(BMENU2) -p "Timing Specification Terminology" \
- -u "Top" \
- -n "Command and Variable Index" > $@
-CLEANFILES += timeBSP_.t
-
-EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \
- intr_NOTIMES.t memmodel.t timeBSP.t
-
-CLEANFILES += mips.info mips.info-?
diff --git a/doc/supplements/mips/bsp.t b/doc/supplements/mips/bsp.t
deleted file mode 100644
index 657c359a96..0000000000
--- a/doc/supplements/mips/bsp.t
+++ /dev/null
@@ -1,93 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Board Support Packages
-
-@section Introduction
-
-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.
-
-@section 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:
-
-@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 The processor begins execution at the address stored in
-the PC.
-@end itemize
-
-@section 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.
-
diff --git a/doc/supplements/mips/callconv.t b/doc/supplements/mips/callconv.t
deleted file mode 100644
index 5387032c60..0000000000
--- a/doc/supplements/mips/callconv.t
+++ /dev/null
@@ -1,92 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Calling Conventions
-
-@section Introduction
-
-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.
-
-@section 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.
-
-@section 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.
-
-@section 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.
-
-@section 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.
-
-@section 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.
-
diff --git a/doc/supplements/mips/cpumodel.t b/doc/supplements/mips/cpumodel.t
deleted file mode 100644
index c366970ae1..0000000000
--- a/doc/supplements/mips/cpumodel.t
+++ /dev/null
@@ -1,68 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter CPU Model Dependent Features
-
-@section Introduction
-
-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.
-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.
-
-@section 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".
-
-@section 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.
-
-@section Another Optional Feature
-
-The macro XXX
diff --git a/doc/supplements/mips/cputable.t b/doc/supplements/mips/cputable.t
deleted file mode 100644
index 75d0fc15f6..0000000000
--- a/doc/supplements/mips/cputable.t
+++ /dev/null
@@ -1,109 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Processor Dependent Information Table
-
-@section Introduction
-
-Any highly processor dependent information required
-to describe a processor to RTEMS is provided in the CPU
-Dependent Information Table. This table is not required for all
-processors supported by RTEMS. This chapter describes the
-contents, if any, for a particular processor type.
-
-@section CPU Dependent Information Table
-
-The XXX version of the RTEMS CPU Dependent
-Information Table contains the information required to interface
-a Board Support Package and RTEMS on the XXX. This
-information is provided to allow RTEMS to interoperate
-effectively with the BSP. The C structure definition is given
-here:
-
-@example
-@group
-typedef struct @{
- void (*pretasking_hook)( void );
- void (*predriver_hook)( void );
- void (*postdriver_hook)( void );
- void (*idle_task)( void );
- boolean do_zero_of_workspace;
- unsigned32 idle_task_stack_size;
- unsigned32 interrupt_stack_size;
- unsigned32 extra_mpci_receive_server_stack;
- void * (*stack_allocate_hook)( unsigned32 );
- void (*stack_free_hook)( void* );
- /* end of fields required on all CPUs */
-
- /* XXX CPU family dependent stuff */
-@} rtems_cpu_table;
-@end group
-@end example
-
-@table @code
-@item pretasking_hook
-is the address of the user provided routine which is invoked
-once RTEMS APIs are initialized. This routine will be invoked
-before any system tasks are created. Interrupts are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item predriver_hook
-is the address of the user provided
-routine that is invoked immediately before the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item postdriver_hook
-is the address of the user provided
-routine that is invoked immediately after the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item idle_task
-is the address of the optional user
-provided routine which is used as the system's IDLE task. If
-this field is not NULL, then the RTEMS default IDLE task is not
-used. This field may be NULL to indicate that the default IDLE
-is to be used.
-
-@item do_zero_of_workspace
-indicates whether RTEMS should
-zero the Workspace as part of its initialization. If set to
-TRUE, the Workspace is zeroed. Otherwise, it is not.
-
-@item idle_task_stack_size
-is the size of the RTEMS idle task stack in bytes.
-If this number is less than MINIMUM_STACK_SIZE, then the
-idle task's stack will be MINIMUM_STACK_SIZE in byte.
-
-@item interrupt_stack_size
-is the size of the RTEMS
-allocated interrupt stack in bytes. This value must be at least
-as large as MINIMUM_STACK_SIZE.
-
-@item extra_mpci_receive_server_stack
-is the extra stack space allocated for the RTEMS MPCI receive server task
-in bytes. The MPCI receive server may invoke nearly all directives and
-may require extra stack space on some targets.
-
-@item stack_allocate_hook
-is the address of the optional user provided routine which allocates
-memory for task stacks. If this hook is not NULL, then a stack_free_hook
-must be provided as well.
-
-@item stack_free_hook
-is the address of the optional user provided routine which frees
-memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
-must be provided as well.
-
-@item XXX
-is where the CPU family dependent stuff goes.
-
-@end table
diff --git a/doc/supplements/mips/fatalerr.t b/doc/supplements/mips/fatalerr.t
deleted file mode 100644
index 53efad0435..0000000000
--- a/doc/supplements/mips/fatalerr.t
+++ /dev/null
@@ -1,31 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Default Fatal Error Processing
-
-@section Introduction
-
-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.
-
-@section 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.
-
diff --git a/doc/supplements/mips/intr_NOTIMES.t b/doc/supplements/mips/intr_NOTIMES.t
deleted file mode 100644
index 5b1025e873..0000000000
--- a/doc/supplements/mips/intr_NOTIMES.t
+++ /dev/null
@@ -1,196 +0,0 @@
-@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
-
-@chapter Interrupt Processing
-
-@section Introduction
-
-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 XXX's
-interrupt response and control mechanisms as they pertain to
-RTEMS.
-
-@section 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.
-
-@subsection 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
-
-@subsection 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 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
-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
-
-@section 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.
-
-@section 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.
-
-@section 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.
-
-
diff --git a/doc/supplements/mips/memmodel.t b/doc/supplements/mips/memmodel.t
deleted file mode 100644
index ef35072230..0000000000
--- a/doc/supplements/mips/memmodel.t
+++ /dev/null
@@ -1,39 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@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 Flat Memory Model
-
-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.
-
-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.
-
diff --git a/doc/supplements/mips/mips.texi b/doc/supplements/mips/mips.texi
deleted file mode 100644
index e33d69332c..0000000000
--- a/doc/supplements/mips/mips.texi
+++ /dev/null
@@ -1,114 +0,0 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename mips.info
-@setcontentsaftertitlepage
-@syncodeindex vr fn
-@synindex ky cp
-@paragraphindent 0
-@c %**end of header
-
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@c
-@c Master file for the Template Applications Supplement
-@c
-
-@include version.texi
-@include common/setup.texi
-@include common/rtems.texi
-
-@ifset use-ascii
-@dircategory RTEMS Target Supplements
-@direntry
-* RTEMS MIPS Applications Supplement: (mips).
-@end direntry
-@end ifset
-
-@c
-@c Title Page Stuff
-@c
-
-@c
-@c I don't really like having a short title page. --joel
-@c
-@c @shorttitlepage RTEMS MIPS Applications Supplement
-
-@setchapternewpage odd
-@settitle RTEMS MIPS Applications Supplement
-@titlepage
-@finalout
-
-@title RTEMS MIPS Applications Supplement
-@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION}
-@sp 1
-@subtitle @value{UPDATED}
-@author On-Line Applications Research Corporation
-@page
-
-@include common/cpright.texi
-@end titlepage
-
-@c This prevents a black box from being printed on "overflow" lines.
-@c The alternative is to rework a sentence to avoid this problem.
-
-@include preface.texi
-@include cpumodel.texi
-@include callconv.texi
-@include memmodel.texi
-@include intr.texi
-@include fatalerr.texi
-@include bsp.texi
-@include cputable.texi
-@include wksheets.texi
-@include timing.texi
-@include timeBSP.texi
-@ifinfo
-@node Top, Preface, (dir), (dir)
-@top mips
-
-This is the online version of the RTEMS MIPS Applications Supplement.
-
-@menu
-* Preface::
-* CPU Model Dependent Features::
-* Calling Conventions::
-* Memory Model::
-* Interrupt Processing::
-* Default Fatal Error Processing::
-* Board Support Packages::
-* Processor Dependent Information Table::
-* Memory Requirements::
-* Timing Specification::
-* BSP_FOR_TIMES Timing Data::
-* Command and Variable Index::
-* Concept Index::
-@end menu
-
-@end ifinfo
-@c
-@c
-@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
-@c
-
-@node Command and Variable Index, Concept Index, BSP_FOR_TIMES Timing Data Rate Monotonic Manager, Top
-@unnumbered Command and Variable Index
-
-There are currently no Command and Variable Index entries.
-
-@c @printindex fn
-
-@node Concept Index, , Command and Variable Index, Top
-@unnumbered Concept Index
-
-There are currently no Concept Index entries.
-@c @printindex cp
-
-@contents
-@bye
-
diff --git a/doc/supplements/mips/preface.texi b/doc/supplements/mips/preface.texi
deleted file mode 100644
index c4f4f3ee0b..0000000000
--- a/doc/supplements/mips/preface.texi
+++ /dev/null
@@ -1,57 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Preface, CPU Model Dependent Features, Top, Top
-@end ifinfo
-@unnumbered Preface
-
-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.
-
-@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/}):
-
-@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
-
diff --git a/doc/supplements/mips/timeBSP.t b/doc/supplements/mips/timeBSP.t
deleted file mode 100644
index a00259ec94..0000000000
--- a/doc/supplements/mips/timeBSP.t
+++ /dev/null
@@ -1,112 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@include common/timemac.texi
-@tex
-\global\advance \smallskipamount by -4pt
-@end tex
-
-@chapter BSP_FOR_TIMES Timing Data
-
-@section Introduction
-
-The timing data for the MIPS version of RTEMS is
-provided along with the target dependent aspects concerning the
-gathering of the timing data. The hardware platform used to
-gather the times is described to give the reader a better
-understanding of each directive time provided. Also, provided
-is a description of the interrupt latency and the context switch
-times as they pertain to the MIPS version of RTEMS.
-
-@section Hardware Platform
-
-All times reported except for the maximum period
-interrupts are disabled by RTEMS were measured using a Motorola
-BSP_FOR_TIMES CPU board. The BSP_FOR_TIMES is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz board with one wait
-state dynamic memory and a XXX numeric coprocessor. The
-Zilog 8036 countdown timer on this board was used to measure
-elapsed time with a one-half microsecond resolution. All
-sources of hardware interrupts were disabled, although the
-interrupt level of the XXX allows all interrupts.
-
-The maximum period interrupts are disabled was
-measured by summing the number of CPU cycles required by each
-assembly language instruction executed while interrupts were
-disabled. The worst case times of the XXX microprocessor
-were used for each instruction. Zero wait state memory was
-assumed. The total CPU cycles executed with interrupts
-disabled, including the instructions to disable and enable
-interrupts, was divided by 20 to simulate a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz processor. It
-should be noted that the worst case instruction times for the
-XXX assume that the internal cache is disabled and that no
-instructions overlap.
-
-@section Interrupt Latency
-
-The maximum period with interrupts disabled within
-RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD
-microseconds including the instructions
-which disable and re-enable interrupts. The time required for
-the XXX to vector an interrupt and for the RTEMS entry
-overhead before invoking the user's interrupt handler are a
-total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds. These combine to yield a worst case
-interrupt latency of less than
-RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz. [NOTE: The maximum period with interrupts
-disabled was last determined for Release
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-It should be noted again that the maximum period with
-interrupts disabled within RTEMS is hand-timed and based upon
-worst case (i.e. CPU cache disabled and no instruction overlap)
-times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz processor. The interrupt vector and entry
-overhead time was generated on an BSP_FOR_TIMES benchmark platform
-using the Multiprocessing Communications registers to generate
-as the interrupt source.
-
-@section Context Switch
-
-The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
-microseconds on the BSP_FOR_TIMES benchmark platform when no floating
-point context is saved or restored. Additional execution time
-is required when a TASK_SWITCH user extension is configured.
-The use of the TASK_SWITCH extension is application dependent.
-Thus, its execution time is not considered part of the raw
-context switch time.
-
-Since RTEMS was designed specifically for embedded
-missile applications which are floating point intensive, the
-executive is optimized to avoid unnecessarily saving and
-restoring the state of the numeric coprocessor. The state of
-the numeric coprocessor is only saved when an FLOATING_POINT
-task is dispatched and that task was not the last task to
-utilize the coprocessor. In a system with only one
-FLOATING_POINT task, the state of the numeric coprocessor will
-never be saved or restored. When the first FLOATING_POINT task
-is dispatched, RTEMS does not need to save the current state of
-the numeric coprocessor.
-
-The exact amount of time required to save and restore
-floating point context is dependent which FPU is being
-used as well as the state of the numeric
-coprocessor. These numeric coprocessors define three operating
-states: initialized, idle, and busy. RTEMS places the
-coprocessor in the initialized state when a task is started or
-restarted. Once the task has utilized the coprocessor, it is in
-the idle state when floating point instructions are not
-executing and the busy state when floating point instructions
-are executing. The state of the coprocessor is task specific.
-
-The following table summarizes the context switch
-times for the BSP_FOR_TIMES benchmark platform:
-
diff --git a/doc/supplements/powerpc/.cvsignore b/doc/supplements/powerpc/.cvsignore
deleted file mode 100644
index f4a6482d2a..0000000000
--- a/doc/supplements/powerpc/.cvsignore
+++ /dev/null
@@ -1,32 +0,0 @@
-index.html
-intr.t
-intr.texi
-Makefile
-Makefile.in
-mdate-sh
-powerpc
-powerpc-?
-powerpc-??
-powerpc.aux
-powerpc.cp
-powerpc.dvi
-powerpc.fn
-powerpc*.html
-powerpc.ky
-powerpc.log
-powerpc.pdf
-powerpc.pg
-powerpc.ps
-powerpc.toc
-powerpc.tp
-powerpc.vr
-rtems_footer.html
-rtems_header.html
-stamp-vti
-timeDMV177_.t
-timePSIM_.t
-timing.t
-timing.texi
-version.texi
-wksheets.t
-wksheets.texi
diff --git a/doc/supplements/powerpc/ChangeLog b/doc/supplements/powerpc/ChangeLog
deleted file mode 100644
index 9e7df2eec7..0000000000
--- a/doc/supplements/powerpc/ChangeLog
+++ /dev/null
@@ -1,72 +0,0 @@
-2003-12-12 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-12-11 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-11-26 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Add *.info to CLEANFILES to accomodate
- automake-1.7f/1.8 breaking building infos.
-
-2003-09-26 Joel Sherrill <joel@OARcorp.com>
-
- * cpumodel.t: Obsoleting HP PA-RISC port and removing all references.
-
-2003-09-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Merger from rtems-4-6-branch.
-
-2003-09-19 Joel Sherrill <joel@OARcorp.com>
-
- * powerpc.texi: Merge from branch.
-
-2003-05-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * cpumodel.t: Reflect c/src/exec having moved to cpukit.
-
-2003-01-25 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * powerpc.texi: Set @setfilename powerpc.info.
-
-2003-01-24 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Put GENERATED_FILES into $builddir.
-
-2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * version.texi: Remove from CVS.
- * stamp-vti: Remove from CVS.
- * .cvsignore: Add version.texi.
- Add stamp-vti.
- Re-sort.
-
-2003-01-21 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-11-13 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-10-24 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-03-27 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Remove AUTOMAKE_OPTIONS.
-
-2002-01-18 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Require automake-1.5.
-
-2001-01-17 Joel Sherrill <joel@OARcorp.com>
-
- * .cvsignore: Added rtems_header.html and rtems_footer.html.
-
-2000-08-10 Joel Sherrill <joel@OARcorp.com>
-
- * ChangeLog: New file.
diff --git a/doc/supplements/powerpc/DMV177_TIMES b/doc/supplements/powerpc/DMV177_TIMES
deleted file mode 100644
index 8f6ff2e3c0..0000000000
--- a/doc/supplements/powerpc/DMV177_TIMES
+++ /dev/null
@@ -1,248 +0,0 @@
-#
-# PowerPC/603e/PSIM Timing and Size Information
-#
-# $Id$
-#
-
-#
-# CPU Model Information
-#
-RTEMS_BSP DMV177
-RTEMS_CPU_MODEL PPC603e
-#
-# Interrupt Latency
-#
-# NOTE: In general, the text says it is hand-calculated to be
-# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-# Mhz and this was last calculated for Release
-# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
-#
-RTEMS_MAXIMUM_DISABLE_PERIOD TBD
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 100.0
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0-lmco
-#
-# Context Switch Times
-#
-RTEMS_NO_FP_CONTEXTS 585
-RTEMS_RESTORE_1ST_FP_TASK 730
-RTEMS_SAVE_INIT_RESTORE_INIT 478
-RTEMS_SAVE_IDLE_RESTORE_INIT 825
-RTEMS_SAVE_IDLE_RESTORE_IDLE 478
-#
-# Task Manager Times
-#
-RTEMS_TASK_CREATE_ONLY 2301
-RTEMS_TASK_IDENT_ONLY 2900
-RTEMS_TASK_START_ONLY 794
-RTEMS_TASK_RESTART_CALLING_TASK 1137
-RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 906
-RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 1102
-RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 928
-RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 1483
-RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 1640
-RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 1601
-RTEMS_TASK_DELETE_CALLING_TASK 2117
-RTEMS_TASK_DELETE_SUSPENDED_TASK 1555
-RTEMS_TASK_DELETE_BLOCKED_TASK 1609
-RTEMS_TASK_DELETE_READY_TASK 1620
-RTEMS_TASK_SUSPEND_CALLING_TASK 960
-RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 433
-RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 960
-RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 803
-RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 368
-RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 633
-RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 1211
-RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 184
-RTEMS_TASK_MODE_NO_RESCHEDULE 213
-RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 247
-RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 919
-RTEMS_TASK_GET_NOTE_ONLY 382
-RTEMS_TASK_SET_NOTE_ONLY 383
-RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 245
-RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 851
-RTEMS_TASK_WAKE_WHEN_ONLY 1275
-#
-# Interrupt Manager
-#
-RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 201
-RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 206
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 202
-RTEMS_INTR_EXIT_RETURNS_TO_NESTED 201
-RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 213
-RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 857
-#
-# Clock Manager
-#
-RTEMS_CLOCK_SET_ONLY 792
-RTEMS_CLOCK_GET_ONLY 78
-RTEMS_CLOCK_TICK_ONLY 214
-#
-# Timer Manager
-#
-RTEMS_TIMER_CREATE_ONLY 357
-RTEMS_TIMER_IDENT_ONLY 2828
-RTEMS_TIMER_DELETE_INACTIVE 432
-RTEMS_TIMER_DELETE_ACTIVE 471
-RTEMS_TIMER_FIRE_AFTER_INACTIVE 607
-RTEMS_TIMER_FIRE_AFTER_ACTIVE 646
-RTEMS_TIMER_FIRE_WHEN_INACTIVE 766
-RTEMS_TIMER_FIRE_WHEN_ACTIVE 764
-RTEMS_TIMER_RESET_INACTIVE 552
-RTEMS_TIMER_RESET_ACTIVE 766
-RTEMS_TIMER_CANCEL_INACTIVE 339
-RTEMS_TIMER_CANCEL_ACTIVE 378
-#
-# Semaphore Manager
-#
-RTEMS_SEMAPHORE_CREATE_ONLY 571
-RTEMS_SEMAPHORE_IDENT_ONLY 3243
-RTEMS_SEMAPHORE_DELETE_ONLY 575
-RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 414
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 414
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 1254
-RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 501
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 636
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 982
-#
-# Message Manager
-#
-RTEMS_MESSAGE_QUEUE_CREATE_ONLY 2270
-RTEMS_MESSAGE_QUEUE_IDENT_ONLY 2828
-RTEMS_MESSAGE_QUEUE_DELETE_ONLY 708
-RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 923
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 955
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 1322
-RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 919
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 955
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 1322
-RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 589
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 1079
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 1435
-RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 755
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 467
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 1283
-RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 369
-RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 431
-#
-# Event Manager
-#
-RTEMS_EVENT_SEND_NO_TASK_READIED 354
-RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 571
-RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 946
-RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 43
-RTEMS_EVENT_RECEIVE_AVAILABLE 357
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 331
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 1043
-#
-# Signal Manager
-#
-RTEMS_SIGNAL_CATCH_ONLY 267
-RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 408
-RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 607
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 464
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 752
-#
-# Partition Manager
-#
-RTEMS_PARTITION_CREATE_ONLY 762
-RTEMS_PARTITION_IDENT_ONLY 2828
-RTEMS_PARTITION_DELETE_ONLY 426
-RTEMS_PARTITION_GET_BUFFER_AVAILABLE 394
-RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 376
-RTEMS_PARTITION_RETURN_BUFFER_ONLY 420
-#
-# Region Manager
-#
-RTEMS_REGION_CREATE_ONLY 614
-RTEMS_REGION_IDENT_ONLY 2878
-RTEMS_REGION_DELETE_ONLY 425
-RTEMS_REGION_GET_SEGMENT_AVAILABLE 515
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 472
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 1345
-RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 544
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 935
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 1296
-#
-# Dual-Ported Memory Manager
-#
-RTEMS_PORT_CREATE_ONLY 428
-RTEMS_PORT_IDENT_ONLY 2828
-RTEMS_PORT_DELETE_ONLY 421
-RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 339
-RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 339
-#
-# IO Manager
-#
-RTEMS_IO_INITIALIZE_ONLY 52
-RTEMS_IO_OPEN_ONLY 42
-RTEMS_IO_CLOSE_ONLY 44
-RTEMS_IO_READ_ONLY 42
-RTEMS_IO_WRITE_ONLY 44
-RTEMS_IO_CONTROL_ONLY 42
-#
-# Rate Monotonic Manager
-#
-RTEMS_RATE_MONOTONIC_CREATE_ONLY 388
-RTEMS_RATE_MONOTONIC_IDENT_ONLY 2826
-RTEMS_RATE_MONOTONIC_CANCEL_ONLY 427
-RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 519
-RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 465
-RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 556
-RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 842
-RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 377
-#
-# Size Information
-#
-#
-# xxx alloted for numbers
-#
-RTEMS_DATA_SPACE 428
-RTEMS_MINIMUM_CONFIGURATION 30,980
-RTEMS_MAXIMUM_CONFIGURATION 55540
-# x,xxx alloted for numbers
-RTEMS_CORE_CODE_SIZE 21,516
-RTEMS_INITIALIZATION_CODE_SIZE 1,412
-RTEMS_TASK_CODE_SIZE 4,804
-RTEMS_INTERRUPT_CODE_SIZE 96
-RTEMS_CLOCK_CODE_SIZE 536
-RTEMS_TIMER_CODE_SIZE 1,380
-RTEMS_SEMAPHORE_CODE_SIZE 1,928
-RTEMS_MESSAGE_CODE_SIZE 532
-RTEMS_EVENT_CODE_SIZE 100
-RTEMS_SIGNAL_CODE_SIZE 100
-RTEMS_PARTITION_CODE_SIZE 1,384
-RTEMS_REGION_CODE_SIZE 1,780
-RTEMS_DPMEM_CODE_SIZE 928
-RTEMS_IO_CODE_SIZE 1,244
-RTEMS_FATAL_ERROR_CODE_SIZE 44
-RTEMS_RATE_MONOTONIC_CODE_SIZE 1,756
-RTEMS_MULTIPROCESSING_CODE_SIZE 11,448
-# xxx alloted for numbers
-RTEMS_TIMER_CODE_OPTSIZE 340
-RTEMS_SEMAPHORE_CODE_OPTSIZE 308
-RTEMS_MESSAGE_CODE_OPTSIZE 532
-RTEMS_EVENT_CODE_OPTSIZE 100
-RTEMS_SIGNAL_CODE_OPTSIZE 100
-RTEMS_PARTITION_CODE_OPTSIZE 244
-RTEMS_REGION_CODE_OPTSIZE 292
-RTEMS_DPMEM_CODE_OPTSIZE 244
-RTEMS_IO_CODE_OPTSIZE NA
-RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 336
-RTEMS_MULTIPROCESSING_CODE_OPTSIZE 612
-# xxx alloted for numbers
-RTEMS_BYTES_PER_TASK 456
-RTEMS_BYTES_PER_TIMER 68
-RTEMS_BYTES_PER_SEMAPHORE 120
-RTEMS_BYTES_PER_MESSAGE_QUEUE 144
-RTEMS_BYTES_PER_REGION 140
-RTEMS_BYTES_PER_PARTITION 56
-RTEMS_BYTES_PER_PORT 36
-RTEMS_BYTES_PER_PERIOD 36
-RTEMS_BYTES_PER_EXTENSION 64
-RTEMS_BYTES_PER_FP_TASK 264
-RTEMS_BYTES_PER_NODE 48
-RTEMS_BYTES_PER_GLOBAL_OBJECT 20
-RTEMS_BYTES_PER_PROXY 124
-# x,xxx alloted for numbers
-RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 10008
-
diff --git a/doc/supplements/powerpc/Makefile.am b/doc/supplements/powerpc/Makefile.am
deleted file mode 100644
index 3dcdf95c6f..0000000000
--- a/doc/supplements/powerpc/Makefile.am
+++ /dev/null
@@ -1,125 +0,0 @@
-#
-# COPYRIGHT (c) 1988-2002.
-# On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# $Id$
-#
-
-PROJECT = powerpc
-EDITION = 1
-
-include $(top_srcdir)/project.am
-include $(top_srcdir)/supplements/supplement.am
-
-GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \
- fatalerr.texi bsp.texi cputable.texi timing.texi wksheets.texi \
- timePSIM.texi timeDMV177.texi
-COMMON_FILES += $(top_srcdir)/common/cpright.texi \
- $(top_srcdir)/common/timemac.texi
-
-FILES = preface.texi
-
-info_TEXINFOS = powerpc.texi
-powerpc_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
-
-#
-# Chapters which get automatic processing
-#
-
-cpumodel.texi: cpumodel.t
- $(BMENU2) -p "Preface" \
- -u "Top" \
- -n "Calling Conventions" < $< > $@
-
-callconv.texi: callconv.t
- $(BMENU2) -p "CPU Model Dependent Features Low Power Model" \
- -u "Top" \
- -n "Memory Model" < $< > $@
-
-memmodel.texi: memmodel.t
- $(BMENU2) -p "Calling Conventions User-Provided Routines" \
- -u "Top" \
- -n "Interrupt Processing" < $< > $@
-
-# Interrupt Chapter:
-# 1. Replace Times and Sizes
-# 2. Build Node Structure
-intr.texi: intr_NOTIMES.t PSIM_TIMES
- ${REPLACE2} -p $(srcdir)/PSIM_TIMES $(srcdir)/intr_NOTIMES.t | \
- $(BMENU2) -p "Memory Model Flat Memory Model" \
- -u "Top" \
- -n "Default Fatal Error Processing" > $@
-
-fatalerr.texi: fatalerr.t
- $(BMENU2) -p "Interrupt Processing Interrupt Stack" \
- -u "Top" \
- -n "Board Support Packages" < $< > $@
-
-bsp.texi: bsp.t
- $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
- -u "Top" \
- -n "Processor Dependent Information Table" < $< > $@
-
-cputable.texi: cputable.t
- $(BMENU2) -p "Board Support Packages Processor Initialization" \
- -u "Top" \
- -n "Memory Requirements" < $< > $@
-
-# Worksheets Chapter:
-# 1. Obtain the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-wksheets.texi: $(top_srcdir)/common/wksheets.t PSIM_TIMES
- ${REPLACE2} -p $(srcdir)/PSIM_TIMES \
- $(top_srcdir)/common/wksheets.t | \
- $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \
- -u "Top" \
- -n "Timing Specification" > $@
-
-# Timing Specification Chapter:
-# 1. Copy the Shared File
-# 3. Build Node Structure
-timing.texi: $(top_srcdir)/common/timing.t
- $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \
- -u "Top" \
- -n "PSIM Timing Data" < $< > $@
-
-# Timing Data for PSIM BSP Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-timePSIM.texi: $(top_srcdir)/common/timetbl.t timePSIM.t
- cat $(srcdir)/timePSIM.t $(top_srcdir)/common/timetbl.t >timePSIM_.t
- @echo >>timePSIM_.t
- @echo "@tex" >>timePSIM_.t
- @echo "\\global\\advance \\smallskipamount by 4pt" >>timePSIM_.t
- @echo "@end tex" >>timePSIM_.t
- ${REPLACE2} -p $(srcdir)/PSIM_TIMES timePSIM_.t | \
- $(BMENU2) -p "Timing Specification Terminology" \
- -u "Top" \
- -n "DMV177 Timing Data" > $@
-CLEANFILES += timePSIM_.t timeDMV177_.t
-
-# Timing Data for DMV177 BSP Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-timeDMV177.texi: $(top_srcdir)/common/timetbl.t timeDMV177.t
- cat $(srcdir)/timeDMV177.t $(top_srcdir)/common/timetbl.t >timeDMV177_.t
- @echo >>timeDMV177_.t
- @echo "@tex" >>timeDMV177_.t
- @echo "\\global\\advance \\smallskipamount by 4pt" >>timeDMV177_.t
- @echo "@end tex" >>timeDMV177_.t
- ${REPLACE2} -p $(srcdir)/DMV177_TIMES timeDMV177_.t | \
- $(BMENU2) -p "PSIM Timing Data Rate Monotonic Manager" \
- -u "Top" \
- -n "Command and Variable Index" > $@
-
-EXTRA_DIST = DMV177_TIMES PSIM_TIMES bsp.t callconv.t cpumodel.t cputable.t \
- fatalerr.t intr_NOTIMES.t memmodel.t timeDMV177.t timePSIM.t
-
-CLEANFILES += powerpc.info powerpc.info-?
diff --git a/doc/supplements/powerpc/PSIM_TIMES b/doc/supplements/powerpc/PSIM_TIMES
deleted file mode 100644
index b357a1fc3c..0000000000
--- a/doc/supplements/powerpc/PSIM_TIMES
+++ /dev/null
@@ -1,248 +0,0 @@
-#
-# PowerPC/603e/PSIM Timing and Size Information
-#
-# $Id$
-#
-
-#
-# CPU Model Information
-#
-RTEMS_BSP PSIM
-RTEMS_CPU_MODEL PPC603e
-#
-# Interrupt Latency
-#
-# NOTE: In general, the text says it is hand-calculated to be
-# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-# Mhz and this was last calculated for Release
-# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
-#
-RTEMS_MAXIMUM_DISABLE_PERIOD TBD
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ na
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0-lmco
-#
-# Context Switch Times
-#
-RTEMS_NO_FP_CONTEXTS 214
-RTEMS_RESTORE_1ST_FP_TASK 255
-RTEMS_SAVE_INIT_RESTORE_INIT 140
-RTEMS_SAVE_IDLE_RESTORE_INIT 140
-RTEMS_SAVE_IDLE_RESTORE_IDLE 290
-#
-# Task Manager Times
-#
-RTEMS_TASK_CREATE_ONLY 1075
-RTEMS_TASK_IDENT_ONLY 1637
-RTEMS_TASK_START_ONLY 345
-RTEMS_TASK_RESTART_CALLING_TASK 483
-RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 396
-RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 491
-RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 404
-RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 644
-RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 709
-RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 686
-RTEMS_TASK_DELETE_CALLING_TASK 941
-RTEMS_TASK_DELETE_SUSPENDED_TASK 703
-RTEMS_TASK_DELETE_BLOCKED_TASK 723
-RTEMS_TASK_DELETE_READY_TASK 729
-RTEMS_TASK_SUSPEND_CALLING_TASK 403
-RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 181
-RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 191
-RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 803
-RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 147
-RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 264
-RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 517
-RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 88
-RTEMS_TASK_MODE_NO_RESCHEDULE 110
-RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 112
-RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 386
-RTEMS_TASK_GET_NOTE_ONLY 156
-RTEMS_TASK_SET_NOTE_ONLY 155
-RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 92
-RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 348
-RTEMS_TASK_WAKE_WHEN_ONLY 546
-#
-# Interrupt Manager
-#
-RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 60
-RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 62
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 61
-RTEMS_INTR_EXIT_RETURNS_TO_NESTED 55
-RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 67
-RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 344
-#
-# Clock Manager
-#
-RTEMS_CLOCK_SET_ONLY 340
-RTEMS_CLOCK_GET_ONLY 29
-RTEMS_CLOCK_TICK_ONLY 81
-#
-# Timer Manager
-#
-RTEMS_TIMER_CREATE_ONLY 144
-RTEMS_TIMER_IDENT_ONLY 1595
-RTEMS_TIMER_DELETE_INACTIVE 197
-RTEMS_TIMER_DELETE_ACTIVE 181
-RTEMS_TIMER_FIRE_AFTER_INACTIVE 252
-RTEMS_TIMER_FIRE_AFTER_ACTIVE 269
-RTEMS_TIMER_FIRE_WHEN_INACTIVE 333
-RTEMS_TIMER_FIRE_WHEN_ACTIVE 334
-RTEMS_TIMER_RESET_INACTIVE 233
-RTEMS_TIMER_RESET_ACTIVE 250
-RTEMS_TIMER_CANCEL_INACTIVE 156
-RTEMS_TIMER_CANCEL_ACTIVE 140
-#
-# Semaphore Manager
-#
-RTEMS_SEMAPHORE_CREATE_ONLY 223
-RTEMS_SEMAPHORE_IDENT_ONLY 1836
-RTEMS_SEMAPHORE_DELETE_ONLY 1836
-RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 175
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 175
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 530
-RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 206
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 272
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 415
-#
-# Message Manager
-#
-RTEMS_MESSAGE_QUEUE_CREATE_ONLY 1022
-RTEMS_MESSAGE_QUEUE_IDENT_ONLY 1596
-RTEMS_MESSAGE_QUEUE_DELETE_ONLY 308
-RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 421
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 434
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 581
-RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 422
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 435
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 582
-RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 244
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 482
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 630
-RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 345
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 197
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 542
-RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 142
-RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 170
-#
-# Event Manager
-#
-RTEMS_EVENT_SEND_NO_TASK_READIED 145
-RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 250
-RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 407
-RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 17
-RTEMS_EVENT_RECEIVE_AVAILABLE 133
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 130
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 442
-#
-# Signal Manager
-#
-RTEMS_SIGNAL_CATCH_ONLY 95
-RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 165
-RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 275
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 216
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 329
-#
-# Partition Manager
-#
-RTEMS_PARTITION_CREATE_ONLY 320
-RTEMS_PARTITION_IDENT_ONLY 1596
-RTEMS_PARTITION_DELETE_ONLY 168
-RTEMS_PARTITION_GET_BUFFER_AVAILABLE 157
-RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 149
-RTEMS_PARTITION_RETURN_BUFFER_ONLY 172
-#
-# Region Manager
-#
-RTEMS_REGION_CREATE_ONLY 239
-RTEMS_REGION_IDENT_ONLY 1625
-RTEMS_REGION_DELETE_ONLY 167
-RTEMS_REGION_GET_SEGMENT_AVAILABLE 206
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 190
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 556
-RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 230
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 412
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 562
-#
-# Dual-Ported Memory Manager
-#
-RTEMS_PORT_CREATE_ONLY 167
-RTEMS_PORT_IDENT_ONLY 1594
-RTEMS_PORT_DELETE_ONLY 165
-RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 133
-RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 134
-#
-# IO Manager
-#
-RTEMS_IO_INITIALIZE_ONLY 23
-RTEMS_IO_OPEN_ONLY 18
-RTEMS_IO_CLOSE_ONLY 18
-RTEMS_IO_READ_ONLY 18
-RTEMS_IO_WRITE_ONLY 18
-RTEMS_IO_CONTROL_ONLY 18
-#
-# Rate Monotonic Manager
-#
-RTEMS_RATE_MONOTONIC_CREATE_ONLY 149
-RTEMS_RATE_MONOTONIC_IDENT_ONLY 1595
-RTEMS_RATE_MONOTONIC_CANCEL_ONLY 169
-RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 212
-RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 186
-RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 226
-RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 362
-RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 142
-#
-# Size Information
-#
-#
-# xxx alloted for numbers
-#
-RTEMS_DATA_SPACE 428
-RTEMS_MINIMUM_CONFIGURATION 30,912
-RTEMS_MAXIMUM_CONFIGURATION 55,572
-# x,xxx alloted for numbers
-RTEMS_CORE_CODE_SIZE 21,452
-RTEMS_INITIALIZATION_CODE_SIZE 1,408
-RTEMS_TASK_CODE_SIZE 4,804
-RTEMS_INTERRUPT_CODE_SIZE 96
-RTEMS_CLOCK_CODE_SIZE 536
-RTEMS_TIMER_CODE_SIZE 1,380
-RTEMS_SEMAPHORE_CODE_SIZE 1,928
-RTEMS_MESSAGE_CODE_SIZE 2,400
-RTEMS_EVENT_CODE_SIZE 1,460
-RTEMS_SIGNAL_CODE_SIZE 576
-RTEMS_PARTITION_CODE_SIZE 1,384
-RTEMS_REGION_CODE_SIZE 1,780
-RTEMS_DPMEM_CODE_SIZE 928
-RTEMS_IO_CODE_SIZE 1,244
-RTEMS_FATAL_ERROR_CODE_SIZE 44
-RTEMS_RATE_MONOTONIC_CODE_SIZE 1,756
-RTEMS_MULTIPROCESSING_CODE_SIZE 11,448
-# xxx alloted for numbers
-RTEMS_TIMER_CODE_OPTSIZE 340
-RTEMS_SEMAPHORE_CODE_OPTSIZE 308
-RTEMS_MESSAGE_CODE_OPTSIZE 532
-RTEMS_EVENT_CODE_OPTSIZE 100
-RTEMS_SIGNAL_CODE_OPTSIZE 100
-RTEMS_PARTITION_CODE_OPTSIZE 244
-RTEMS_REGION_CODE_OPTSIZE 292
-RTEMS_DPMEM_CODE_OPTSIZE 244
-RTEMS_IO_CODE_OPTSIZE NA
-RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 336
-RTEMS_MULTIPROCESSING_CODE_OPTSIZE 612
-# xxx alloted for numbers
-RTEMS_BYTES_PER_TASK 456
-RTEMS_BYTES_PER_TIMER 68
-RTEMS_BYTES_PER_SEMAPHORE 120
-RTEMS_BYTES_PER_MESSAGE_QUEUE 144
-RTEMS_BYTES_PER_REGION 140
-RTEMS_BYTES_PER_PARTITION 56
-RTEMS_BYTES_PER_PORT 36
-RTEMS_BYTES_PER_PERIOD 36
-RTEMS_BYTES_PER_EXTENSION 64
-RTEMS_BYTES_PER_FP_TASK 264
-RTEMS_BYTES_PER_NODE 48
-RTEMS_BYTES_PER_GLOBAL_OBJECT 20
-RTEMS_BYTES_PER_PROXY 124
-# x,xxx alloted for numbers
-RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 10,008
-
diff --git a/doc/supplements/powerpc/bsp.t b/doc/supplements/powerpc/bsp.t
deleted file mode 100644
index cf71029fa6..0000000000
--- a/doc/supplements/powerpc/bsp.t
+++ /dev/null
@@ -1,76 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Board Support Packages
-
-@section Introduction
-
-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.
-
-@section System Reset
-
-An RTEMS based application is initiated or
-re-initiated when the PowerPC processor is reset. The PowerPC
-architecture defines a Reset Exception, but leaves the
-details of the CPU state as implementation specific. Please
-refer to the User's Manual for the CPU model in question.
-
-In general, at power-up the PowerPC begin execution at address
-0xFFF00100 in supervisor mode with all exceptions disabled. For
-soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100
-depending upon the setting of the Exception Prefix bit in the MSR.
-If during a soft reset, a Machine Check Exception occurs, then the
-CPU may execute a hard reset.
-
-@section 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
-observed to prevent some emulators from working properly, so it
-may be necessary to run with caching disabled to use these emulators.
-
-In addition to the requirements described in the
-@b{Board Support Packages} chapter of the @b{@value{LANGUAGE}
-Applications User's Manual} for the reset code
-which is executed before the call to @code{rtems_initialize_executive},
-the PowrePC version has the following specific requirements:
-
-@itemize @bullet
-@item Must leave the PR bit of the Machine State Register (MSR) set
-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.
-
-@item Must disable all external interrupts (i.e. clear the EI (EE)
-bit of the machine state register).
-
-@item Must enable traps so window overflow and underflow
-conditions can be properly handled.
-
-@item Must initialize the PowerPC's initial Exception Table with default
-handlers.
-
-@end itemize
-
diff --git a/doc/supplements/powerpc/callconv.t b/doc/supplements/powerpc/callconv.t
deleted file mode 100644
index 7722589058..0000000000
--- a/doc/supplements/powerpc/callconv.t
+++ /dev/null
@@ -1,229 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Calling Conventions
-
-@section Introduction
-
-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.
-
-@section Programming Model
-
-This section discusses the programming model for the
-PowerPC architecture.
-
-@subsection Non-Floating Point Registers
-
-The PowerPC architecture defines thirty-two non-floating point registers
-directly visible to the programmer. In thirty-two bit implementations, each
-register is thirty-two bits wide. In sixty-four bit implementations, each
-register is sixty-four bits wide.
-
-These registers are referred to as @code{gpr0} to @code{gpr31}.
-
-Some of the registers serve defined roles in the EABI programming model.
-The following table describes the role of each of these registers:
-
-@ifset use-ascii
-@example
-@group
- +---------------+----------------+------------------------------+
- | Register Name | Alternate Name | Description |
- +---------------+----------------+------------------------------+
- | r1 | sp | stack pointer |
- +---------------+----------------+------------------------------+
- | | | global pointer to the Small |
- | r2 | na | Constant Area (SDA2) |
- +---------------+----------------+------------------------------+
- | r3 - r12 | na | parameter and result passing |
- +---------------+----------------+------------------------------+
- | | | global pointer to the Small |
- | r13 | na | Data Area (SDA) |
- +---------------+----------------+------------------------------+
-@end group
-@end example
-@end ifset
-
-@ifset use-tex
-@sp 1
-@tex
-\centerline{\vbox{\offinterlineskip\halign{
-\vrule\strut#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 2.50in{\enskip\hfil#\hfil}&
-\vrule#\cr
-\noalign{\hrule}
-&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule}
-&r1&&sp&&stack pointer&\cr\noalign{\hrule}
-&r2&&NA&&global pointer to the Small&\cr
-&&&&&Constant Area (SDA2)&\cr\noalign{\hrule}
-&r3 - r12&&NA&&parameter and result passing&\cr\noalign{\hrule}
-&r13&&NA&&global pointer to the Small&\cr
-&&&&&Data Area (SDA2)&\cr\noalign{\hrule}
-}}\hfil}
-@end tex
-@end ifset
-
-@ifset use-html
-@html
-<CENTER>
- <TABLE COLS=3 WIDTH="80%" BORDER=2>
-<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD>
- <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD>
- <TD ALIGN=center><STRONG>Description</STRONG></TD></TR>
-<TR><TD ALIGN=center>r1</TD>
- <TD ALIGN=center>sp</TD>
- <TD ALIGN=center>stack pointer</TD></TR>
-<TR><TD ALIGN=center>r2</TD>
- <TD ALIGN=center>na</TD>
- <TD ALIGN=center>global pointer to the Small Constant Area (SDA2)</TD></TR>
-<TR><TD ALIGN=center>r3 - r12</TD>
- <TD ALIGN=center>NA</TD>
- <TD ALIGN=center>parameter and result passing</TD></TR>
-<TR><TD ALIGN=center>r13</TD>
- <TD ALIGN=center>NA</TD>
- <TD ALIGN=center>global pointer to the Small Data Area (SDA)</TD></TR>
- </TABLE>
-</CENTER>
-@end html
-@end ifset
-
-
-@subsection Floating Point Registers
-
-The PowerPC architecture includes thirty-two, sixty-four bit
-floating point registers. All PowerPC floating point instructions
-interpret these registers as 32 double precision floating point registers,
-regardless of whether the processor has 64-bit or 32-bit implementation.
-
-The floating point status and control register (fpscr) records exceptions
-and the type of result generated by floating-point operations.
-Additionally, it controls the rounding mode of operations and allows the
-reporting of floating exceptions to be enabled or disabled.
-
-@subsection Special Registers
-
-The PowerPC architecture includes a number of special registers
-which are critical to the programming model:
-
-@table @b
-
-@item Machine State Register
-
-The MSR contains the processor mode, power management mode, endian mode,
-exception information, privilege level, floating point available and
-floating point excepiton mode, address translation information and
-the exception prefix.
-
-@item Link Register
-
-The LR contains the return address after a function call. This register
-must be saved before a subsequent subroutine call can be made. The
-use of this register is discussed further in the @b{Call and Return
-Mechanism} section below.
-
-@item Count Register
-
-The CTR contains the iteration variable for some loops. It may also be used
-for indirect function calls and jumps.
-
-@end table
-
-@section Call and Return Mechanism
-
-The PowerPC architecture supports a simple yet effective call
-and return mechanism. A subroutine is invoked
-via the "branch and link" (@code{bl}) and
-"brank and link absolute" (@code{bla})
-instructions. This instructions place the return address
-in the Link Register (LR). The callee returns to the caller by
-executing a "branch unconditional to the link register" (@code{blr})
-instruction. Thus the callee returns to the caller via a jump
-to the return address which is stored in the LR.
-
-The previous contents of the LR are not automatically saved
-by either the @code{bl} or @code{bla}. It is the responsibility
-of the callee to save the contents of the LR before invoking
-another subroutine. If the callee invokes another subroutine,
-it must restore the LR before executing the @code{blr} instruction
-to return to the caller.
-
-It is important to note that the PowerPC subroutine
-call and return mechanism does not automatically save and
-restore any registers.
-
-The LR may be accessed as special purpose register 8 (@code{SPR8}) using the
-"move from special register" (@code{mfspr}) and
-"move to special register" (@code{mtspr}) instructions.
-
-@section Calling Mechanism
-
-All RTEMS directives are invoked using the regular
-PowerPC EABI calling convention via the @code{bl} or
-@code{bla} instructions.
-
-@section Register Usage
-
-As discussed above, the call instruction does not
-automatically save any registers. It is the responsibility
-of the callee to save and restore any registers which must be preserved
-across subroutine calls. The callee is responsible for saving
-callee-preserved registers to the program stack and restoring them
-before returning to the caller.
-
-@section Parameter Passing
-
-RTEMS assumes that arguments are placed in the
-general purpose registers with the first argument in
-register 3 (@code{r3}), the second argument in general purpose
-register 4 (@code{r4}), and so forth until the seventh
-argument is in general purpose register 10 (@code{r10}).
-If there are more than seven arguments, then subsequent arguments
-are placed on the program stack. The following pseudo-code
-illustrates the typical sequence used to call a RTEMS directive
-with three (3) arguments:
-
-@example
-load third argument into r5
-load second argument into r4
-load first argument into r3
-invoke directive
-@end example
-
-@section 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.
-
-
diff --git a/doc/supplements/powerpc/cpumodel.t b/doc/supplements/powerpc/cpumodel.t
deleted file mode 100644
index 3173dc15f0..0000000000
--- a/doc/supplements/powerpc/cpumodel.t
+++ /dev/null
@@ -1,156 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter CPU Model Dependent Features
-
-@section Introduction
-
-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.
-
-@section 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.
-
-@subsection 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".
-
-@subsection Floating Point Unit
-
-The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model
-has a hardware floating point unit and 0 otherwise.
-
-@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.
-
-@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
-as possible can be retrieved with the initial read into cache. This
-is done for the interrupt handler as well as the context switch routines.
-
-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.
-
-@subsection Maximum Interrupts
-
-The macro PPC_INTERRUPT_MAX is set to the number of exception sources
-supported by this PowerPC model.
-
-@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.
-
-@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.
-
-@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.
-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.
-
-@subsection Instruction Cache Size
-
-The macro PPC_I_CACHE is set to the size in bytes of the instruction cache.
-
-@subsection Data Cache Size
-
-The macro PPC_D_CACHE is set to the size in bytes of the data cache.
-
-@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
-are currently supported:
-
-@table @b
-
-@item @code{PPC_DEBUG_MODEL_STANDARD}
-indicates that the single-step trace enable (SE) and branch trace
-enable (BE) bits in the MSR are supported by this CPU model.
-
-@item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
-indicates that only the single-step trace enable (SE) bit in the MSR
-is supported by this CPU model.
-
-@item @code{PPC_DEBUG_MODEL_IBM4xx}
-indicates that the debug exception enable (DE) bit in the MSR is supported
-by this CPU model. At this time, this particular debug feature set
-has only been seen in the IBM 4xx series.
-
-@end table
-
-@subsection Low Power Model
-
-The macro PPC_LOW_POWER_MODE is set to indicate the low power model
-supported by this CPU model. The following low power modes are currently
-supported.
-
-@table @b
-
-@item @code{PPC_LOW_POWER_MODE_NONE}
-indicates that this CPU model has no low power mode support.
-
-@item @code{PPC_LOW_POWER_MODE_STANDARD}
-indicates that this CPU model follows the low power model defined for
-the PPC603e.
-
-@end table
diff --git a/doc/supplements/powerpc/cputable.t b/doc/supplements/powerpc/cputable.t
deleted file mode 100644
index 42f67b1a70..0000000000
--- a/doc/supplements/powerpc/cputable.t
+++ /dev/null
@@ -1,155 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Processor Dependent Information Table
-
-@section Introduction
-
-Any highly processor dependent information required
-to describe a processor to RTEMS is provided in the CPU
-Dependent Information Table. This table is not required for all
-processors supported by RTEMS. This chapter describes the
-contents, if any, for a particular processor type.
-
-@section CPU Dependent Information Table
-
-The PowerPC version of the RTEMS CPU Dependent
-Information Table is given by the C structure definition is
-shown below:
-
-@example
-typedef struct @{
- void (*pretasking_hook)( void );
- void (*predriver_hook)( void );
- void (*postdriver_hook)( void );
- void (*idle_task)( void );
- boolean do_zero_of_workspace;
- unsigned32 idle_task_stack_size;
- unsigned32 interrupt_stack_size;
- unsigned32 extra_mpci_receive_server_stack;
- void * (*stack_allocate_hook)( unsigned32 );
- void (*stack_free_hook)( void* );
- /* end of fields required on all CPUs */
-
- unsigned32 clicks_per_usec; /* Timer clicks per microsecond */
- void (*spurious_handler)(
- unsigned32 vector, CPU_Interrupt_frame *);
- boolean exceptions_in_RAM; /* TRUE if in RAM */
-
-#if defined(ppc403)
- unsigned32 serial_per_sec; /* Serial clocks per second */
- boolean serial_external_clock;
- boolean serial_xon_xoff;
- boolean serial_cts_rts;
- unsigned32 serial_rate;
- unsigned32 timer_average_overhead; /* in ticks */
- unsigned32 timer_least_valid; /* Least valid number from timer */
-#endif
-@};
-@end example
-
-@table @code
-@item pretasking_hook
-is the address of the user provided routine which is invoked
-once RTEMS APIs are initialized. This routine will be invoked
-before any system tasks are created. Interrupts are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item predriver_hook
-is the address of the user provided
-routine that is invoked immediately before the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item postdriver_hook
-is the address of the user provided
-routine that is invoked immediately after the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item idle_task
-is the address of the optional user
-provided routine which is used as the system's IDLE task. If
-this field is not NULL, then the RTEMS default IDLE task is not
-used. This field may be NULL to indicate that the default IDLE
-is to be used.
-
-@item do_zero_of_workspace
-indicates whether RTEMS should
-zero the Workspace as part of its initialization. If set to
-TRUE, the Workspace is zeroed. Otherwise, it is not.
-
-@item idle_task_stack_size
-is the size of the RTEMS idle task stack in bytes.
-If this number is less than MINIMUM_STACK_SIZE, then the
-idle task's stack will be MINIMUM_STACK_SIZE in byte.
-
-@item interrupt_stack_size
-is the size of the RTEMS allocated interrupt stack in bytes.
-This value must be at least as large as MINIMUM_STACK_SIZE.
-
-@item extra_mpci_receive_server_stack
-is the extra stack space allocated for the RTEMS MPCI receive server task
-in bytes. The MPCI receive server may invoke nearly all directives and
-may require extra stack space on some targets.
-
-@item stack_allocate_hook
-is the address of the optional user provided routine which allocates
-memory for task stacks. If this hook is not NULL, then a stack_free_hook
-must be provided as well.
-
-@item stack_free_hook
-is the address of the optional user provided routine which frees
-memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
-must be provided as well.
-
-@item clicks_per_usec
-is the number of decrementer interupts that occur each microsecond.
-
-@item spurious_handler
-is the address of the
-routine which is invoked when a spurious interrupt occurs.
-
-@item exceptions_in_RAM
-indicates whether the exception vectors are located in RAM or ROM. If
-they are located in RAM dynamic vector installation occurs, otherwise
-it does not.
-
-@item serial_per_sec
-is a PPC403 specific field which specifies the number of clock
-ticks per second for the PPC403 serial timer.
-
-@item serial_rate
-is a PPC403 specific field which specifies the baud rate for the
-PPC403 serial port.
-
-@item serial_external_clock
-is a PPC403 specific field which indicates whether or not to mask in a 0x2 into
-the Input/Output Configuration Register (IOCR) during initialization of the
-PPC403 console. (NOTE: This bit is defined as "reserved" 6-12?)
-
-@item serial_xon_xoff
-is a PPC403 specific field which indicates whether or not
-XON/XOFF flow control is supported for the PPC403 serial port.
-
-@item serial_cts_rts
-is a PPC403 specific field which indicates whether or not to set the
-least significant bit of the Input/Output Configuration Register
-(IOCR) during initialization of the PPC403 console. (NOTE: This
-bit is defined as "reserved" 6-12?)
-
-@item timer_average_overhead
-is a PPC403 specific field which specifies the average number of overhead ticks that occur on the PPC403 timer.
-
-@item timer_least_valid
-is a PPC403 specific field which specifies the maximum valid PPC403 timer value.
-
-@end table
-
diff --git a/doc/supplements/powerpc/fatalerr.t b/doc/supplements/powerpc/fatalerr.t
deleted file mode 100644
index 8a03d57674..0000000000
--- a/doc/supplements/powerpc/fatalerr.t
+++ /dev/null
@@ -1,47 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Default Fatal Error Processing
-
-@section Introduction
-
-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.
-
-@section 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:
-
-@itemize @bullet
-
-@item places the error code in r3, and
-
-@item executes a trap instruction which results in a Program Exception.
-
-@end itemize
-
-If the Program Exception returns, then the following actions are performed:
-
-@itemize @bullet
-
-@item disables all processor exceptions by loading a 0 into the MSR, and
-
-@item goes into an infinite loop to simulate a halt processor instruction.
-
-@end itemize
-
diff --git a/doc/supplements/powerpc/intr_NOTIMES.t b/doc/supplements/powerpc/intr_NOTIMES.t
deleted file mode 100644
index 514e27c9a5..0000000000
--- a/doc/supplements/powerpc/intr_NOTIMES.t
+++ /dev/null
@@ -1,184 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Interrupt Processing
-
-@section Introduction
-
-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 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.
-
-@section Synchronous Versus Asynchronous Exceptions
-
-In the PowerPC architecture exceptions can be either precise or
-imprecise and either synchronous or asynchronous. Asynchronous
-exceptions occur when an external event interrupts the processor.
-Synchronous exceptions are caused by the actions of an
-instruction. During an exception SRR0 is used to calculate where
-instruction processing should resume. All instructions prior to
-the resume instruction will have completed execution. SRR1 is used to
-store the machine status.
-
-There are two asynchronous nonmaskable, highest-priority exceptions
-system reset and machine check. There are two asynchrononous maskable
-low-priority exceptions external interrupt and decrementer. Nonmaskable
-execptions are never delayed, therefore if two nonmaskable, asynchronous
-exceptions occur in immediate succession, the state information saved by
-the first exception may be overwritten when the subsequent exception occurs.
-
-The PowerPC arcitecure defines one imprecise exception, the imprecise
-floating point enabled exception. All other synchronous exceptions are
-precise. The synchronization occuring during asynchronous precise
-exceptions conforms to the requirements for context synchronization.
-
-@section Vectoring of Interrupt Handler
-
-Upon determining that an exception can be taken the PowerPC automatically
-performs the following actions:
-
-@itemize @bullet
-@item an instruction address is loaded into SRR0
-
-@item bits 33-36 and 42-47 of SRR1 are loaded with information
-specific to the exception.
-
-@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding
-bits from the MSR.
-
-@item the MSR is set based upon the exception type.
-
-@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type.
-
-@end itemize
-
-If the interrupt handler was installed as an RTEMS
-interrupt handler, then upon receipt of the interrupt, the
-processor passes control to the RTEMS interrupt handler which
-performs the following actions:
-
-@itemize @bullet
-@item saves the state of the interrupted task on it's stack,
-
-@item saves all registers which are not normally preserved
-by the calling sequence so the user's interrupt service
-routine can be written in a high-level language.
-
-@item if this is the outermost (i.e. non-nested) interrupt,
-then the RTEMS interrupt handler switches from the current stack
-to the interrupt stack,
-
-@item enables exceptions,
-
-@item invokes the vectors to a user interrupt service routine (ISR).
-@end itemize
-
-Asynchronous interrupts are ignored while exceptions are
-disabled. Synchronous interrupts which occur while are
-disabled result in the CPU being forced into an error mode.
-
-A nested interrupt is processed similarly with the
-exception that the current stack need not be switched to the
-interrupt stack.
-
-@section Interrupt Levels
-
-The PowerPC architecture supports only a single external
-asynchronous interrupt source. This interrupt source
-may be enabled and disabled via the External Interrupt Enable (EE)
-bit in the Machine State Register (MSR). Thus only two level (enabled
-and disabled) of external device interrupt priorities are
-directly supported by the PowerPC architecture.
-
-Some PowerPC implementations include a Critical Interrupt capability
-which is often used to receive interrupts from high priority external
-devices.
-
-The RTEMS interrupt level mapping scheme for the PowerPC is not
-a numeric level as on most RTEMS ports. It is a bit mapping in
-which the least three significiant bits of the interrupt level
-are mapped directly to the enabling of specific interrupt
-sources as follows:
-
-@table @b
-
-@item Critical Interrupt
-Setting bit 0 (the least significant bit) of the interrupt level
-enables the Critical Interrupt source, if it is available on this
-CPU model.
-
-@item Machine Check
-Setting bit 1 of the interrupt level enables Machine Check execptions.
-
-@item External Interrupt
-Setting bit 2 of the interrupt level enables External Interrupt execptions.
-
-@end table
-
-All other bits in the RTEMS task interrupt level are ignored.
-
-@section 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.
-
-@section 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.
-
-
-
diff --git a/doc/supplements/powerpc/memmodel.t b/doc/supplements/powerpc/memmodel.t
deleted file mode 100644
index 13341696cf..0000000000
--- a/doc/supplements/powerpc/memmodel.t
+++ /dev/null
@@ -1,110 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@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 Flat Memory Model
-
-The PowerPC architecture supports a variety of memory models.
-RTEMS supports the PowerPC using a flat memory model with
-paging disabled. In this mode, the PowerPC automatically
-converts every address from a logical to a physical address
-each time it is used. The PowerPC uses information provided
-in the Block Address Translation (BAT) to convert these addresses.
-
-Implementations of the PowerPC architecture may be thirty-two or sixty-four bit.
-The PowerPC architecture supports a flat thirty-two or sixty-four bit address
-space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
-gigabytes) in thirty-two bit implementations or to 0xFFFFFFFFFFFFFFFF
-in sixty-four bit implementations. Each address is represented
-by either a thirty-two bit or sixty-four bit value and is byte addressable.
-The address may be used to reference a single byte, half-word
-(2-bytes), word (4 bytes), or in sixty-four bit implementations a
-doubleword (8 bytes). Memory accesses within the address space are
-performed in big or little endian fashion by the PowerPC based
-upon the current setting of the Little-endian mode enable bit (LE)
-in the Machine State Register (MSR). While the processor is in
-big endian mode, memory accesses which are not properly aligned
-generate an "alignment exception" (vector offset 0x00600). In
-little endian mode, the PowerPC architecture does not require
-the processor to generate alignment exceptions.
-
-The following table lists the alignment requirements for a variety
-of data accesses:
-
-@ifset use-ascii
-@example
-@group
- +--------------+-----------------------+
- | Data Type | Alignment Requirement |
- +--------------+-----------------------+
- | byte | 1 |
- | half-word | 2 |
- | word | 4 |
- | doubleword | 8 |
- +--------------+-----------------------+
-@end group
-@end example
-@end ifset
-
-@ifset use-tex
-@sp 1
-@tex
-\centerline{\vbox{\offinterlineskip\halign{
-\vrule\strut#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#\cr
-\noalign{\hrule}
-&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule}
-&byte&&1&\cr\noalign{\hrule}
-&half-word&&2&\cr\noalign{\hrule}
-&word&&4&\cr\noalign{\hrule}
-&doubleword&&8&\cr\noalign{\hrule}
-}}\hfil}
-@end tex
-@end ifset
-
-@ifset use-html
-@html
-<CENTER>
- <TABLE COLS=2 WIDTH="60%" BORDER=2>
-<TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD>
- <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR>
-<TR><TD ALIGN=center>byte</TD>
- <TD ALIGN=center>1</TD></TR>
-<TR><TD ALIGN=center>half-word</TD>
- <TD ALIGN=center>2</TD></TR>
-<TR><TD ALIGN=center>word</TD>
- <TD ALIGN=center>4</TD></TR>
-<TR><TD ALIGN=center>doubleword</TD>
- <TD ALIGN=center>8</TD></TR>
- </TABLE>
-</CENTER>
-@end html
-@end ifset
-
-Doubleword load and store operations are only available in
-PowerPC CPU models which are sixty-four bit implementations.
-
-RTEMS does not directly support any PowerPC Memory Management
-Units, therefore, virtual memory or segmentation systems
-involving the PowerPC are not supported.
-
diff --git a/doc/supplements/powerpc/powerpc.texi b/doc/supplements/powerpc/powerpc.texi
deleted file mode 100644
index 4e27aa0ee0..0000000000
--- a/doc/supplements/powerpc/powerpc.texi
+++ /dev/null
@@ -1,115 +0,0 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename powerpc.info
-@setcontentsaftertitlepage
-@syncodeindex vr fn
-@synindex ky cp
-@paragraphindent 0
-@c %**end of header
-
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@c
-@c Master file for the PowerPC Applications Supplement
-@c
-
-@include version.texi
-@include common/setup.texi
-@include common/rtems.texi
-
-@ifset use-ascii
-@dircategory RTEMS Target Supplements
-@direntry
-* RTEMS PowerPC Applications Supplement: (powerpc).
-@end direntry
-@end ifset
-
-@c
-@c Title Page Stuff
-@c
-
-@c
-@c I don't really like having a short title page. --joel
-@c
-@c @shorttitlepage RTEMS PowerPC Applications Supplement
-
-@setchapternewpage odd
-@settitle RTEMS PowerPC Applications Supplement
-@titlepage
-@finalout
-
-@title RTEMS PowerPC Applications Supplement
-@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION}
-@sp 1
-@subtitle @value{UPDATED}
-@author On-Line Applications Research Corporation
-@page
-@include common/cpright.texi
-@end titlepage
-
-@c This prevents a black box from being printed on "overflow" lines.
-@c The alternative is to rework a sentence to avoid this problem.
-
-@include preface.texi
-@include cpumodel.texi
-@include callconv.texi
-@include memmodel.texi
-@include intr.texi
-@include fatalerr.texi
-@include bsp.texi
-@include cputable.texi
-@include wksheets.texi
-@include timing.texi
-@include timePSIM.texi
-@include timeDMV177.texi
-@ifinfo
-@node Top, Preface, (dir), (dir)
-@top powerpc
-
-This is the online version of the RTEMS PowerPC Applications Supplement.
-
-@menu
-* Preface::
-* CPU Model Dependent Features::
-* Calling Conventions::
-* Memory Model::
-* Interrupt Processing::
-* Default Fatal Error Processing::
-* Board Support Packages::
-* Processor Dependent Information Table::
-* Memory Requirements::
-* Timing Specification::
-* PSIM Timing Data::
-* DMV177 Timing Data::
-* Command and Variable Index::
-* Concept Index::
-@end menu
-
-@end ifinfo
-@c
-@c
-@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
-@c
-
-@node Command and Variable Index, Concept Index, DMV177 Timing Data Rate Monotonic Manager, Top
-@unnumbered Command and Variable Index
-
-There are currently no Command and Variable Index entries.
-
-@c @printindex fn
-
-@node Concept Index, , Command and Variable Index, Top
-@unnumbered Concept Index
-
-There are currently no Concept Index entries.
-@c @printindex cp
-
-@contents
-@bye
-
diff --git a/doc/supplements/powerpc/preface.texi b/doc/supplements/powerpc/preface.texi
deleted file mode 100644
index 607953e00c..0000000000
--- a/doc/supplements/powerpc/preface.texi
+++ /dev/null
@@ -1,94 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Preface, CPU Model Dependent Features, Top, Top
-@end ifinfo
-@unnumbered Preface
-
-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.
-
-It is highly recommended that the PowerPC RTEMS
-application developer obtain and become familiar with the
-documentation for the processor being used as well as the
-specification for the revision of the PowerPC architecture which
-corresponds to that processor.
-
-@subheading PowerPC Architecture Documents
-
-For information on the PowerPC architecture, refer to
-the following documents available from Motorola and IBM:
-
-@itemize @bullet
-
-@item @cite{PowerPC Microprocessor Family: The Programming Environment}
-(Motorola Document MPRPPCFPE-01).
-
-@item @cite{IBM PPC403GB Embedded Controller User's Manual}.
-
-@item @cite{PoweRisControl MPC500 Family RCPU RISC Central Processing
-Unit Reference Manual} (Motorola Document RCPUURM/AD).
-
-@item @cite{PowerPC 601 RISC Microprocessor User's Manual}
-(Motorola Document MPR601UM/AD).
-
-@item @cite{PowerPC 603 RISC Microprocessor User's Manual}
-(Motorola Document MPR603UM/AD).
-
-@item @cite{PowerPC 603e RISC Microprocessor User's Manual}
-(Motorola Document MPR603EUM/AD).
-
-@item @cite{PowerPC 604 RISC Microprocessor User's Manual}
-(Motorola Document MPR604UM/AD).
-
-@item @cite{PowerPC MPC821 Portable Systems Microprocessor User's Manual}
-(Motorola Document MPC821UM/AD).
-
-@item @cite{PowerQUICC MPC860 User's Manual} (Motorola Document MPC860UM/AD).
-
-
-@end itemize
-
-Motorola maintains an on-line electronic library for the PowerPC
-at the following URL:
-
-@itemize @code{ }
-@item @cite{http://www.mot.com/powerpc/library/library.html}
-@end itemize
-
-This site has a a wealth of information and examples. Many of the
-manuals are available from that site in electronic format.
-
-@subheading PowerPC Processor Simulator Information
-
-PSIM is a program which emulates the Instruction Set Architecture
-of the PowerPC microprocessor family. It is reely available in source
-code form under the terms of the GNU General Public License (version
-2 or later). PSIM can be integrated with the GNU Debugger (gdb) to
-execute and debug PowerPC executables on non-PowerPC hosts. PSIM
-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.
-
-
diff --git a/doc/supplements/powerpc/timeDMV177.t b/doc/supplements/powerpc/timeDMV177.t
deleted file mode 100644
index 301bfee4c1..0000000000
--- a/doc/supplements/powerpc/timeDMV177.t
+++ /dev/null
@@ -1,113 +0,0 @@
-@c
-@c Timing information for the DMV177
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@include common/timemac.texi
-@tex
-\global\advance \smallskipamount by -4pt
-@end tex
-
-@chapter RTEMS_BSP Timing Data
-
-@section Introduction
-
-The timing data for RTEMS on the DY-4 RTEMS_BSP board
-is provided along with the target
-dependent aspects concerning the gathering of the timing data.
-The hardware platform used to gather the times is described to
-give the reader a better understanding of each directive time
-provided. Also, provided is a description of the interrupt
-latency and the context switch times as they pertain to the
-PowerPC version of RTEMS.
-
-@section Hardware Platform
-
-All times reported in this chapter were measured using a RTEMS_BSP board.
-All data and code caching was disabled. This results in very deterministic
-times which represent the worst possible performance. Many embedded
-applications disable caching to insure that execution times are
-repeatable. Moreover, the JTAG port on certain revisions of the PowerPC
-603e does not operate properly if caching is enabled. Thus during
-development and debug, caching must be off.
-
-The PowerPC decrementer register was was used to gather
-all timing information. In the PowerPC architecture,
-this register typically counts
-something like CPU cycles or is a function of the clock
-speed. On the PPC603e decrements once for every four (4) bus cycles.
-On the RTEMS_BSP, the bus operates at a clock speed of
-33 Mhz. This result in a very accurate number since it is a function of the
-microprocessor itself. Thus all measurements in this
-chapter are reported as the actual number of decrementer
-clicks reported.
-
-To convert the numbers reported to microseconds, one should
-divide the number reported by 8.650752. This number was derived as
-shown below:
-
-@example
-((33 * 1048576) / 1000000) / 4 = 8.650752
-@end example
-
-All sources of hardware interrupts were disabled,
-although traps were enabled and the interrupt level of the
-PowerPC allows all interrupts.
-
-@section Interrupt Latency
-
-The maximum period with traps disabled or the
-processor interrupt level set to it's highest value inside RTEMS
-is less than RTEMS_MAXIMUM_DISABLE_PERIOD
-microseconds including the instructions which
-disable and re-enable interrupts. The time required for the
-PowerPC to vector an interrupt and for the RTEMS entry overhead
-before invoking the user's trap handler are a total of
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds. These combine to yield a worst case interrupt
-latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD +
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz.
-[NOTE: The maximum period with interrupts disabled was last
-determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-The maximum period with interrupts disabled within
-RTEMS is hand-timed with some assistance from the PowerPC simulator.
-The maximum period with interrupts disabled with RTEMS has not
-been calculated on this target.
-
-The interrupt vector and entry overhead time was
-generated on the PSIM benchmark platform using the PowerPC's
-decrementer register. This register was programmed to generate
-an interrupt after one countdown.
-
-@section Context Switch
-
-The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
-bus cycle on the RTEMS_BSP benchmark platform when no floating
-point context is saved or restored. Additional execution time
-is required when a TASK_SWITCH user extension is configured.
-The use of the TASK_SWITCH extension is application dependent.
-Thus, its execution time is not considered part of the raw
-context switch time.
-
-Since RTEMS was designed specifically for embedded
-missile applications which are floating point intensive, the
-executive is optimized to avoid unnecessarily saving and
-restoring the state of the numeric coprocessor. The state of
-the numeric coprocessor is only saved when an FLOATING_POINT
-task is dispatched and that task was not the last task to
-utilize the coprocessor. In a system with only one
-FLOATING_POINT task, the state of the numeric coprocessor will
-never be saved or restored. When the first FLOATING_POINT task
-is dispatched, RTEMS does not need to save the current state of
-the numeric coprocessor.
-
-The following table summarizes the context switch
-times for the RTEMS_BSP benchmark platform:
-
diff --git a/doc/supplements/powerpc/timePSIM.t b/doc/supplements/powerpc/timePSIM.t
deleted file mode 100644
index b0516c828b..0000000000
--- a/doc/supplements/powerpc/timePSIM.t
+++ /dev/null
@@ -1,97 +0,0 @@
-@c
-@c Timing information for PSIM
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@include common/timemac.texi
-@tex
-\global\advance \smallskipamount by -4pt
-@end tex
-
-@chapter RTEMS_BSP Timing Data
-
-@section Introduction
-
-The timing data for RTEMS on the RTEMS_BSP target
-is provided along with the target
-dependent aspects concerning the gathering of the timing data.
-The hardware platform used to gather the times is described to
-give the reader a better understanding of each directive time
-provided. Also, provided is a description of the interrupt
-latency and the context switch times as they pertain to the
-PowerPC version of RTEMS.
-
-@section Hardware Platform
-
-All times reported in this chapter were measured using the PowerPC
-Instruction Simulator (PSIM). PSIM simulates a variety of PowerPC
-6xx models with the PPC603e being used as the basis for the measurements
-reported in this chapter.
-
-The PowerPC decrementer register was was used to gather
-all timing information. In real hardware implementations
-of the PowerPC architecture, this register would typically
-count something like CPU cycles or be a function of the clock
-speed. However, with PSIM each count of the decrementer register
-represents an instruction. Thus all measurements in this
-chapter are reported as the actual number of instructions
-executed. All sources of hardware interrupts were disabled,
-although traps were enabled and the interrupt level of the
-PowerPC allows all interrupts.
-
-@section Interrupt Latency
-
-The maximum period with traps disabled or the
-processor interrupt level set to it's highest value inside RTEMS
-is less than RTEMS_MAXIMUM_DISABLE_PERIOD
-microseconds including the instructions which
-disable and re-enable interrupts. The time required for the
-PowerPC to vector an interrupt and for the RTEMS entry overhead
-before invoking the user's trap handler are a total of
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds. These combine to yield a worst case interrupt
-latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD +
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz.
-[NOTE: The maximum period with interrupts disabled was last
-determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-The maximum period with interrupts disabled within
-RTEMS is hand-timed with some assistance from RTEMS_BSP. The maximum
-period with interrupts disabled with RTEMS occurs was not measured
-on this target.
-
-The interrupt vector and entry overhead time was
-generated on the RTEMS_BSP benchmark platform using the PowerPC's
-decrementer register. This register was programmed to generate
-an interrupt after one countdown.
-
-@section Context Switch
-
-The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
-instructions on the RTEMS_BSP benchmark platform when no floating
-point context is saved or restored. Additional execution time
-is required when a TASK_SWITCH user extension is configured.
-The use of the TASK_SWITCH extension is application dependent.
-Thus, its execution time is not considered part of the raw
-context switch time.
-
-Since RTEMS was designed specifically for embedded
-missile applications which are floating point intensive, the
-executive is optimized to avoid unnecessarily saving and
-restoring the state of the numeric coprocessor. The state of
-the numeric coprocessor is only saved when an FLOATING_POINT
-task is dispatched and that task was not the last task to
-utilize the coprocessor. In a system with only one
-FLOATING_POINT task, the state of the numeric coprocessor will
-never be saved or restored. When the first FLOATING_POINT task
-is dispatched, RTEMS does not need to save the current state of
-the numeric coprocessor.
-
-The following table summarizes the context switch
-times for the RTEMS_BSP benchmark platform:
diff --git a/doc/supplements/sh/.cvsignore b/doc/supplements/sh/.cvsignore
deleted file mode 100644
index d18f3b9ad3..0000000000
--- a/doc/supplements/sh/.cvsignore
+++ /dev/null
@@ -1,31 +0,0 @@
-index.html
-intr.t
-intr.texi
-Makefile
-Makefile.in
-mdate-sh
-rtems_footer.html
-rtems_header.html
-sh
-sh-?
-sh-??
-sh.aux
-sh.cp
-sh.dvi
-sh.fn
-sh*.html
-sh.ky
-sh.log
-sh.pdf
-sh.pg
-sh.ps
-sh.toc
-sh.tp
-sh.vr
-stamp-vti
-timeBSP_.t
-timing.t
-timing.texi
-version.texi
-wksheets.t
-wksheets.texi
diff --git a/doc/supplements/sh/BSP_TIMES b/doc/supplements/sh/BSP_TIMES
deleted file mode 100644
index 82b8160aa5..0000000000
--- a/doc/supplements/sh/BSP_TIMES
+++ /dev/null
@@ -1,247 +0,0 @@
-#
-# CPU MODEL/BSP Timing and Size Information
-#
-# $Id$
-#
-
-#
-# CPU Model Information
-#
-RTEMS_BSP BSPFORTIMES
-RTEMS_CPU_MODEL BSP_CPU_MODEL
-#
-# Interrupt Latency
-#
-# NOTE: In general, the text says it is hand-calculated to be
-# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-# Mhz and this was last calculated for Release
-# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
-#
-RTEMS_MAXIMUM_DISABLE_PERIOD TBD
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0
-#
-# Context Switch Times
-#
-RTEMS_NO_FP_CONTEXTS 35
-RTEMS_RESTORE_1ST_FP_TASK 39
-RTEMS_SAVE_INIT_RESTORE_INIT 66
-RTEMS_SAVE_IDLE_RESTORE_INIT 66
-RTEMS_SAVE_IDLE_RESTORE_IDLE 68
-#
-# Task Manager Times
-#
-RTEMS_TASK_CREATE_ONLY 148
-RTEMS_TASK_IDENT_ONLY 350
-RTEMS_TASK_START_ONLY 76
-RTEMS_TASK_RESTART_CALLING_TASK 95
-RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89
-RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124
-RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92
-RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125
-RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149
-RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142
-RTEMS_TASK_DELETE_CALLING_TASK 170
-RTEMS_TASK_DELETE_SUSPENDED_TASK 138
-RTEMS_TASK_DELETE_BLOCKED_TASK 143
-RTEMS_TASK_DELETE_READY_TASK 144
-RTEMS_TASK_SUSPEND_CALLING_TASK 71
-RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43
-RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45
-RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67
-RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31
-RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64
-RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106
-RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14
-RTEMS_TASK_MODE_NO_RESCHEDULE 16
-RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23
-RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60
-RTEMS_TASK_GET_NOTE_ONLY 33
-RTEMS_TASK_SET_NOTE_ONLY 33
-RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16
-RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56
-RTEMS_TASK_WAKE_WHEN_ONLY 117
-#
-# Interrupt Manager
-#
-RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12
-RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9
-RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1
-RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8
-RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54
-#
-# Clock Manager
-#
-RTEMS_CLOCK_SET_ONLY 86
-RTEMS_CLOCK_GET_ONLY 1
-RTEMS_CLOCK_TICK_ONLY 17
-#
-# Timer Manager
-#
-RTEMS_TIMER_CREATE_ONLY 28
-RTEMS_TIMER_IDENT_ONLY 343
-RTEMS_TIMER_DELETE_INACTIVE 43
-RTEMS_TIMER_DELETE_ACTIVE 47
-RTEMS_TIMER_FIRE_AFTER_INACTIVE 58
-RTEMS_TIMER_FIRE_AFTER_ACTIVE 61
-RTEMS_TIMER_FIRE_WHEN_INACTIVE 88
-RTEMS_TIMER_FIRE_WHEN_ACTIVE 88
-RTEMS_TIMER_RESET_INACTIVE 54
-RTEMS_TIMER_RESET_ACTIVE 58
-RTEMS_TIMER_CANCEL_INACTIVE 31
-RTEMS_TIMER_CANCEL_ACTIVE 34
-#
-# Semaphore Manager
-#
-RTEMS_SEMAPHORE_CREATE_ONLY 60
-RTEMS_SEMAPHORE_IDENT_ONLY 367
-RTEMS_SEMAPHORE_DELETE_ONLY 58
-RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109
-RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87
-#
-# Message Manager
-#
-RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200
-RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341
-RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80
-RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123
-RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123
-RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133
-RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114
-RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29
-RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39
-#
-# Event Manager
-#
-RTEMS_EVENT_SEND_NO_TASK_READIED 24
-RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60
-RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84
-RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1
-RTEMS_EVENT_RECEIVE_AVAILABLE 28
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84
-#
-# Signal Manager
-#
-RTEMS_SIGNAL_CATCH_ONLY 15
-RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37
-RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54
-#
-# Partition Manager
-#
-RTEMS_PARTITION_CREATE_ONLY 70
-RTEMS_PARTITION_IDENT_ONLY 341
-RTEMS_PARTITION_DELETE_ONLY 42
-RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35
-RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33
-RTEMS_PARTITION_RETURN_BUFFER_ONLY 43
-#
-# Region Manager
-#
-RTEMS_REGION_CREATE_ONLY 63
-RTEMS_REGION_IDENT_ONLY 348
-RTEMS_REGION_DELETE_ONLY 39
-RTEMS_REGION_GET_SEGMENT_AVAILABLE 52
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123
-RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136
-#
-# Dual-Ported Memory Manager
-#
-RTEMS_PORT_CREATE_ONLY 35
-RTEMS_PORT_IDENT_ONLY 340
-RTEMS_PORT_DELETE_ONLY 39
-RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26
-RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27
-#
-# IO Manager
-#
-RTEMS_IO_INITIALIZE_ONLY 4
-RTEMS_IO_OPEN_ONLY 2
-RTEMS_IO_CLOSE_ONLY 1
-RTEMS_IO_READ_ONLY 2
-RTEMS_IO_WRITE_ONLY 3
-RTEMS_IO_CONTROL_ONLY 2
-#
-# Rate Monotonic Manager
-#
-RTEMS_RATE_MONOTONIC_CREATE_ONLY 32
-RTEMS_RATE_MONOTONIC_IDENT_ONLY 341
-RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39
-RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51
-RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48
-RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54
-RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74
-RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31
-#
-# Size Information
-#
-#
-# xxx alloted for numbers
-#
-RTEMS_DATA_SPACE 723
-RTEMS_MINIMUM_CONFIGURATION 18,980
-RTEMS_MAXIMUM_CONFIGURATION 36,438
-# x,xxx alloted for numbers
-RTEMS_CORE_CODE_SIZE 12,674
-RTEMS_INITIALIZATION_CODE_SIZE 970
-RTEMS_TASK_CODE_SIZE 3,562
-RTEMS_INTERRUPT_CODE_SIZE 54
-RTEMS_CLOCK_CODE_SIZE 334
-RTEMS_TIMER_CODE_SIZE 1,110
-RTEMS_SEMAPHORE_CODE_SIZE 1,632
-RTEMS_MESSAGE_CODE_SIZE 1,754
-RTEMS_EVENT_CODE_SIZE 1,000
-RTEMS_SIGNAL_CODE_SIZE 418
-RTEMS_PARTITION_CODE_SIZE 1,164
-RTEMS_REGION_CODE_SIZE 1,494
-RTEMS_DPMEM_CODE_SIZE 724
-RTEMS_IO_CODE_SIZE 686
-RTEMS_FATAL_ERROR_CODE_SIZE 24
-RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212
-RTEMS_MULTIPROCESSING_CODE_SIZE 6.952
-# xxx alloted for numbers
-RTEMS_TIMER_CODE_OPTSIZE 184
-RTEMS_SEMAPHORE_CODE_OPTSIZE 172
-RTEMS_MESSAGE_CODE_OPTSIZE 288
-RTEMS_EVENT_CODE_OPTSIZE 56
-RTEMS_SIGNAL_CODE_OPTSIZE 56
-RTEMS_PARTITION_CODE_OPTSIZE 132
-RTEMS_REGION_CODE_OPTSIZE 160
-RTEMS_DPMEM_CODE_OPTSIZE 132
-RTEMS_IO_CODE_OPTSIZE 00
-RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184
-RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332
-# xxx alloted for numbers
-RTEMS_BYTES_PER_TASK 400
-RTEMS_BYTES_PER_TIMER 68
-RTEMS_BYTES_PER_SEMAPHORE 124
-RTEMS_BYTES_PER_MESSAGE_QUEUE 148
-RTEMS_BYTES_PER_REGION 144
-RTEMS_BYTES_PER_PARTITION 56
-RTEMS_BYTES_PER_PORT 36
-RTEMS_BYTES_PER_PERIOD 36
-RTEMS_BYTES_PER_EXTENSION 64
-RTEMS_BYTES_PER_FP_TASK 332
-RTEMS_BYTES_PER_NODE 48
-RTEMS_BYTES_PER_GLOBAL_OBJECT 20
-RTEMS_BYTES_PER_PROXY 124
-# x,xxx alloted for numbers
-RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872
diff --git a/doc/supplements/sh/ChangeLog b/doc/supplements/sh/ChangeLog
deleted file mode 100644
index 5bbba06126..0000000000
--- a/doc/supplements/sh/ChangeLog
+++ /dev/null
@@ -1,76 +0,0 @@
-2003-12-12 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-12-11 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-11-26 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Add *.info to CLEANFILES to accomodate
- automake-1.7f/1.8 breaking building infos.
-
-2003-09-26 Joel Sherrill <joel@OARcorp.com>
-
- * cpumodel.t: Obsoleting HP PA-RISC port and removing all references.
-
-2003-09-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Merger from rtems-4-6-branch.
-
-2003-09-19 Joel Sherrill <joel@OARcorp.com>
-
- * sh.texi: Merge from branch.
-
-2003-05-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * cpumodel.t: Reflect c/src/exec having moved to cpukit.
-
-2003-01-25 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * sh.texi: Set @setfilename sh.info.
-
-2003-01-24 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Put GENERATED_FILES into $builddir.
-
-2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * version.texi: Remove from CVS.
- * stamp-vti: Remove from CVS.
- * .cvsignore: Add version.texi.
- Add stamp-vti.
- Re-sort.
-
-2003-01-21 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-11-13 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-10-24 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-07-30 Joel Sherrill <joel@OARcorp.com>
-
- * intr_NOTIMES.t, timeBSP.t: Replaced XXX's with real info.
-
-2002-03-27 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Remove AUTOMAKE_OPTIONS.
-
-2002-01-18 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Require automake-1.5.
-
-2001-01-17 Joel Sherrill <joel@OARcorp.com>
-
- * .cvsignore: Added rtems_header.html and rtems_footer.html.
-
-2000-08-10 Joel Sherrill <joel@OARcorp.com>
-
- * ChangeLog: New file.
diff --git a/doc/supplements/sh/Makefile.am b/doc/supplements/sh/Makefile.am
deleted file mode 100644
index 388173e524..0000000000
--- a/doc/supplements/sh/Makefile.am
+++ /dev/null
@@ -1,111 +0,0 @@
-#
-# COPYRIGHT (c) 1988-2002.
-# On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# $Id$
-#
-
-PROJECT = sh
-EDITION = 1
-
-include $(top_srcdir)/project.am
-include $(top_srcdir)/supplements/supplement.am
-
-GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \
- fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \
- timeBSP.texi
-
-COMMON_FILES += $(top_srcdir)/common/cpright.texi \
- $(top_srcdir)/common/timemac.texi
-
-FILES = preface.texi
-
-info_TEXINFOS = sh.texi
-sh_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
-
-#
-# Chapters which get automatic processing
-#
-
-cpumodel.texi: cpumodel.t
- $(BMENU2) -p "Preface" \
- -u "Top" \
- -n "Calling Conventions" < $< > $@
-
-callconv.texi: callconv.t
- $(BMENU2) -p "CPU Model Dependent Features Another Optional Feature" \
- -u "Top" \
- -n "Memory Model" < $< > $@
-
-memmodel.texi: memmodel.t
- $(BMENU2) -p "Calling Conventions User-Provided Routines" \
- -u "Top" \
- -n "Interrupt Processing" < $< > $@
-
-# Interrupt Chapter:
-# 1. Replace Times and Sizes
-# 2. Build Node Structure
-intr.texi: intr_NOTIMES.t BSP_TIMES
- ${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \
- $(BMENU2) -p "Memory Model Flat Memory Model" \
- -u "Top" \
- -n "Default Fatal Error Processing" > $@
-
-fatalerr.texi: fatalerr.t
- $(BMENU2) -p "Interrupt Processing Interrupt Stack" \
- -u "Top" \
- -n "Board Support Packages" < $< > $@
-
-bsp.texi: bsp.t
- $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
- -u "Top" \
- -n "Processor Dependent Information Table" < $< > $@
-
-cputable.texi: cputable.t
- $(BMENU2) -p "Board Support Packages Processor Initialization" \
- -u "Top" \
- -n "Memory Requirements" < $< > $@
-
-# Worksheets Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES
- ${REPLACE2} -p $(srcdir)/BSP_TIMES \
- $(top_srcdir)/common/wksheets.t | \
- $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \
- -u "Top" \
- -n "Timing Specification" > $@
-
-# Timing Specification Chapter:
-# 1. Copy the Shared File
-# 3. Build Node Structure
-
-timing.texi: $(top_srcdir)/common/timing.t
- $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \
- -u "Top" \
- -n "BSP_FOR_TIMES Timing Data" < $< > $@
-
-# Timing Data for BSP Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t
- cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t
- @echo >>timeBSP_.t
- @echo "@tex" >>timeBSP_.t
- @echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t
- @echo "@end tex" >>timeBSP_.t
- ${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \
- $(BMENU2) -p "Timing Specification Terminology" \
- -u "Top" \
- -n "Command and Variable Index" > $@
-CLEANFILES += timeBSP_.t
-
-EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \
- intr_NOTIMES.t memmodel.t timeBSP.t
-
-CLEANFILES += sh.info sh.info-?
diff --git a/doc/supplements/sh/bsp.t b/doc/supplements/sh/bsp.t
deleted file mode 100644
index 657c359a96..0000000000
--- a/doc/supplements/sh/bsp.t
+++ /dev/null
@@ -1,93 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Board Support Packages
-
-@section Introduction
-
-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.
-
-@section 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:
-
-@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 The processor begins execution at the address stored in
-the PC.
-@end itemize
-
-@section 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.
-
diff --git a/doc/supplements/sh/callconv.t b/doc/supplements/sh/callconv.t
deleted file mode 100644
index 89ac51db68..0000000000
--- a/doc/supplements/sh/callconv.t
+++ /dev/null
@@ -1,102 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Calling Conventions
-
-@section Introduction
-
-Each high-level language compiler generates
-subroutine entry and exit code based upon a set of rules known
-as the compiler's calling convention. These rules address the
-following issues:
-
-@itemize @bullet
-@item register preservation and usage
-@item parameter passing
-@item call and return mechanism
-@end itemize
-
-A compiler's calling convention is of importance when
-interfacing to subroutines written in another language either
-assembly or high-level. Even when the high-level language and
-target processor are the same, different compilers may use
-different calling conventions. As a result, calling conventions
-are both processor and compiler dependent.
-
-The 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.
-
-@section Calling Mechanism
-
-All RTEMS directives are invoked using either a bsr
-or jsr instruction and return to the user application via the
-rts instruction.
-
-@section 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.
-
-
-> > 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
->
-
-
-@section 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.
-
-@section 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.
-
diff --git a/doc/supplements/sh/cpumodel.t b/doc/supplements/sh/cpumodel.t
deleted file mode 100644
index c366970ae1..0000000000
--- a/doc/supplements/sh/cpumodel.t
+++ /dev/null
@@ -1,68 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter CPU Model Dependent Features
-
-@section Introduction
-
-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.
-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.
-
-@section 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".
-
-@section 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.
-
-@section Another Optional Feature
-
-The macro XXX
diff --git a/doc/supplements/sh/cputable.t b/doc/supplements/sh/cputable.t
deleted file mode 100644
index 75d0fc15f6..0000000000
--- a/doc/supplements/sh/cputable.t
+++ /dev/null
@@ -1,109 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Processor Dependent Information Table
-
-@section Introduction
-
-Any highly processor dependent information required
-to describe a processor to RTEMS is provided in the CPU
-Dependent Information Table. This table is not required for all
-processors supported by RTEMS. This chapter describes the
-contents, if any, for a particular processor type.
-
-@section CPU Dependent Information Table
-
-The XXX version of the RTEMS CPU Dependent
-Information Table contains the information required to interface
-a Board Support Package and RTEMS on the XXX. This
-information is provided to allow RTEMS to interoperate
-effectively with the BSP. The C structure definition is given
-here:
-
-@example
-@group
-typedef struct @{
- void (*pretasking_hook)( void );
- void (*predriver_hook)( void );
- void (*postdriver_hook)( void );
- void (*idle_task)( void );
- boolean do_zero_of_workspace;
- unsigned32 idle_task_stack_size;
- unsigned32 interrupt_stack_size;
- unsigned32 extra_mpci_receive_server_stack;
- void * (*stack_allocate_hook)( unsigned32 );
- void (*stack_free_hook)( void* );
- /* end of fields required on all CPUs */
-
- /* XXX CPU family dependent stuff */
-@} rtems_cpu_table;
-@end group
-@end example
-
-@table @code
-@item pretasking_hook
-is the address of the user provided routine which is invoked
-once RTEMS APIs are initialized. This routine will be invoked
-before any system tasks are created. Interrupts are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item predriver_hook
-is the address of the user provided
-routine that is invoked immediately before the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item postdriver_hook
-is the address of the user provided
-routine that is invoked immediately after the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item idle_task
-is the address of the optional user
-provided routine which is used as the system's IDLE task. If
-this field is not NULL, then the RTEMS default IDLE task is not
-used. This field may be NULL to indicate that the default IDLE
-is to be used.
-
-@item do_zero_of_workspace
-indicates whether RTEMS should
-zero the Workspace as part of its initialization. If set to
-TRUE, the Workspace is zeroed. Otherwise, it is not.
-
-@item idle_task_stack_size
-is the size of the RTEMS idle task stack in bytes.
-If this number is less than MINIMUM_STACK_SIZE, then the
-idle task's stack will be MINIMUM_STACK_SIZE in byte.
-
-@item interrupt_stack_size
-is the size of the RTEMS
-allocated interrupt stack in bytes. This value must be at least
-as large as MINIMUM_STACK_SIZE.
-
-@item extra_mpci_receive_server_stack
-is the extra stack space allocated for the RTEMS MPCI receive server task
-in bytes. The MPCI receive server may invoke nearly all directives and
-may require extra stack space on some targets.
-
-@item stack_allocate_hook
-is the address of the optional user provided routine which allocates
-memory for task stacks. If this hook is not NULL, then a stack_free_hook
-must be provided as well.
-
-@item stack_free_hook
-is the address of the optional user provided routine which frees
-memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
-must be provided as well.
-
-@item XXX
-is where the CPU family dependent stuff goes.
-
-@end table
diff --git a/doc/supplements/sh/fatalerr.t b/doc/supplements/sh/fatalerr.t
deleted file mode 100644
index 53efad0435..0000000000
--- a/doc/supplements/sh/fatalerr.t
+++ /dev/null
@@ -1,31 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Default Fatal Error Processing
-
-@section Introduction
-
-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.
-
-@section 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.
-
diff --git a/doc/supplements/sh/intr_NOTIMES.t b/doc/supplements/sh/intr_NOTIMES.t
deleted file mode 100644
index d642ce1ddf..0000000000
--- a/doc/supplements/sh/intr_NOTIMES.t
+++ /dev/null
@@ -1,196 +0,0 @@
-@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
-
-@chapter Interrupt Processing
-
-@section Introduction
-
-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 SH's
-interrupt response and control mechanisms as they pertain to
-RTEMS.
-
-@section 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.
-
-@subsection 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
-
-@subsection Models With Separate Interrupt Stacks
-
-Upon receipt of an interrupt the SH 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 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
-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
-
-@section 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.
-
-@section 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.
-
-@section 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.
-
-
diff --git a/doc/supplements/sh/memmodel.t b/doc/supplements/sh/memmodel.t
deleted file mode 100644
index ef35072230..0000000000
--- a/doc/supplements/sh/memmodel.t
+++ /dev/null
@@ -1,39 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@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 Flat Memory Model
-
-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.
-
-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.
-
diff --git a/doc/supplements/sh/preface.texi b/doc/supplements/sh/preface.texi
deleted file mode 100644
index 686a17b48d..0000000000
--- a/doc/supplements/sh/preface.texi
+++ /dev/null
@@ -1,55 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Preface, CPU Model Dependent Features, Top, Top
-@end ifinfo
-@unnumbered Preface
-
-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.
-
-@subheading Architecture Documents
-
-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
-
diff --git a/doc/supplements/sh/sh.texi b/doc/supplements/sh/sh.texi
deleted file mode 100644
index 50dff26ec6..0000000000
--- a/doc/supplements/sh/sh.texi
+++ /dev/null
@@ -1,114 +0,0 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename sh.info
-@setcontentsaftertitlepage
-@syncodeindex vr fn
-@synindex ky cp
-@paragraphindent 0
-@c %**end of header
-
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@c
-@c Master file for the Template Applications Supplement
-@c
-
-@include version.texi
-@include common/setup.texi
-@include common/rtems.texi
-
-@ifset use-ascii
-@dircategory RTEMS Target Supplements
-@direntry
-* RTEMS Hitachi SH Applications Supplement: (sh).
-@end direntry
-@end ifset
-
-@c
-@c Title Page Stuff
-@c
-
-@c
-@c I don't really like having a short title page. --joel
-@c
-@c @shorttitlepage RTEMS Hitachi SH Applications Supplement
-
-@setchapternewpage odd
-@settitle RTEMS Hitachi SH Applications Supplement
-@titlepage
-@finalout
-
-@title RTEMS Hitachi SH Applications Supplement
-@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION}
-@sp 1
-@subtitle @value{UPDATED}
-@author On-Line Applications Research Corporation
-@page
-
-@include common/cpright.texi
-@end titlepage
-
-@c This prevents a black box from being printed on "overflow" lines.
-@c The alternative is to rework a sentence to avoid this problem.
-
-@include preface.texi
-@include cpumodel.texi
-@include callconv.texi
-@include memmodel.texi
-@include intr.texi
-@include fatalerr.texi
-@include bsp.texi
-@include cputable.texi
-@include wksheets.texi
-@include timing.texi
-@include timeBSP.texi
-@ifinfo
-@node Top, Preface, (dir), (dir)
-@top sh
-
-This is the online version of the RTEMS Hitachi SH Applications Supplement.
-
-@menu
-* Preface::
-* CPU Model Dependent Features::
-* Calling Conventions::
-* Memory Model::
-* Interrupt Processing::
-* Default Fatal Error Processing::
-* Board Support Packages::
-* Processor Dependent Information Table::
-* Memory Requirements::
-* Timing Specification::
-* BSP_FOR_TIMES Timing Data::
-* Command and Variable Index::
-* Concept Index::
-@end menu
-
-@end ifinfo
-@c
-@c
-@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
-@c
-
-@node Command and Variable Index, Concept Index, BSP_FOR_TIMES Timing Data Rate Monotonic Manager, Top
-@unnumbered Command and Variable Index
-
-There are currently no Command and Variable Index entries.
-
-@c @printindex fn
-
-@node Concept Index, , Command and Variable Index, Top
-@unnumbered Concept Index
-
-There are currently no Concept Index entries.
-@c @printindex cp
-
-@contents
-@bye
-
diff --git a/doc/supplements/sh/timeBSP.t b/doc/supplements/sh/timeBSP.t
deleted file mode 100644
index 1439bb56bf..0000000000
--- a/doc/supplements/sh/timeBSP.t
+++ /dev/null
@@ -1,112 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@include common/timemac.texi
-@tex
-\global\advance \smallskipamount by -4pt
-@end tex
-
-@chapter BSP_FOR_TIMES Timing Data
-
-@section Introduction
-
-The timing data for the SH version of RTEMS is
-provided along with the target dependent aspects concerning the
-gathering of the timing data. The hardware platform used to
-gather the times is described to give the reader a better
-understanding of each directive time provided. Also, provided
-is a description of the interrupt latency and the context switch
-times as they pertain to the SH version of RTEMS.
-
-@section Hardware Platform
-
-All times reported except for the maximum period
-interrupts are disabled by RTEMS were measured using a Motorola
-BSP_FOR_TIMES CPU board. The BSP_FOR_TIMES is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz board with one wait
-state dynamic memory and a XXX numeric coprocessor. The
-Zilog 8036 countdown timer on this board was used to measure
-elapsed time with a one-half microsecond resolution. All
-sources of hardware interrupts were disabled, although the
-interrupt level of the XXX allows all interrupts.
-
-The maximum period interrupts are disabled was
-measured by summing the number of CPU cycles required by each
-assembly language instruction executed while interrupts were
-disabled. The worst case times of the XXX microprocessor
-were used for each instruction. Zero wait state memory was
-assumed. The total CPU cycles executed with interrupts
-disabled, including the instructions to disable and enable
-interrupts, was divided by 20 to simulate a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz processor. It
-should be noted that the worst case instruction times for the
-processor assume that the internal cache is disabled and that no
-instructions overlap.
-
-@section Interrupt Latency
-
-The maximum period with interrupts disabled within
-RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD
-microseconds including the instructions
-which disable and re-enable interrupts. The time required for
-the processor to vector an interrupt and for the RTEMS entry
-overhead before invoking the user's interrupt handler are a
-total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds. These combine to yield a worst case
-interrupt latency of less than
-RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz. [NOTE: The maximum period with interrupts
-disabled was last determined for Release
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-It should be noted again that the maximum period with
-interrupts disabled within RTEMS is hand-timed and based upon
-worst case (i.e. CPU cache disabled and no instruction overlap)
-times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz processor. The interrupt vector and entry
-overhead time was generated on an BSP_FOR_TIMES benchmark platform
-using the Multiprocessing Communications registers to generate
-as the interrupt source.
-
-@section Context Switch
-
-The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
-microseconds on the BSP_FOR_TIMES benchmark platform when no floating
-point context is saved or restored. Additional execution time
-is required when a TASK_SWITCH user extension is configured.
-The use of the TASK_SWITCH extension is application dependent.
-Thus, its execution time is not considered part of the raw
-context switch time.
-
-Since RTEMS was designed specifically for embedded
-missile applications which are floating point intensive, the
-executive is optimized to avoid unnecessarily saving and
-restoring the state of the numeric coprocessor. The state of
-the numeric coprocessor is only saved when an FLOATING_POINT
-task is dispatched and that task was not the last task to
-utilize the coprocessor. In a system with only one
-FLOATING_POINT task, the state of the numeric coprocessor will
-never be saved or restored. When the first FLOATING_POINT task
-is dispatched, RTEMS does not need to save the current state of
-the numeric coprocessor.
-
-The exact amount of time required to save and restore
-floating point context is dependent on whether an XXX or
-XXX is being used as well as the state of the numeric
-coprocessor. These numeric coprocessors define three operating
-states: initialized, idle, and busy. RTEMS places the
-coprocessor in the initialized state when a task is started or
-restarted. Once the task has utilized the coprocessor, it is in
-the idle state when floating point instructions are not
-executing and the busy state when floating point instructions
-are executing. The state of the coprocessor is task specific.
-
-The following table summarizes the context switch
-times for the BSP_FOR_TIMES benchmark platform:
-
diff --git a/doc/supplements/sparc/.cvsignore b/doc/supplements/sparc/.cvsignore
deleted file mode 100644
index 9bbd58773d..0000000000
--- a/doc/supplements/sparc/.cvsignore
+++ /dev/null
@@ -1,31 +0,0 @@
-index.html
-intr.t
-intr.texi
-Makefile
-Makefile.in
-mdate-sh
-rtems_footer.html
-rtems_header.html
-sparc
-sparc-?
-sparc-??
-sparc.aux
-sparc.cp
-sparc.dvi
-sparc.fn
-sparc*.html
-sparc.ky
-sparc.log
-sparc.pdf
-sparc.pg
-sparc.ps
-sparc.toc
-sparc.tp
-sparc.vr
-stamp-vti
-timeERC32_.t
-timing.t
-timing.texi
-version.texi
-wksheets.t
-wksheets.texi
diff --git a/doc/supplements/sparc/ChangeLog b/doc/supplements/sparc/ChangeLog
deleted file mode 100644
index ee5e300ac1..0000000000
--- a/doc/supplements/sparc/ChangeLog
+++ /dev/null
@@ -1,72 +0,0 @@
-2003-12-12 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-12-11 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-11-26 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Add *.info to CLEANFILES to accomodate
- automake-1.7f/1.8 breaking building infos.
-
-2003-09-26 Joel Sherrill <joel@OARcorp.com>
-
- * cpumodel.t: Obsoleting HP PA-RISC port and removing all references.
-
-2003-09-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Merger from rtems-4-6-branch.
-
-2003-09-19 Joel Sherrill <joel@OARcorp.com>
-
- * sparc.texi: Merge from branch.
-
-2003-05-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * cpumodel.t: Reflect c/src/exec having moved to cpukit.
-
-2003-01-25 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * sparc.texi: Set @setfilename sparc.info.
-
-2003-01-24 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Put GENERATED_FILES into $builddir.
-
-2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * version.texi: Remove from CVS.
- * stamp-vti: Remove from CVS.
- * .cvsignore: Add version.texi.
- Add stamp-vti.
- Re-sort.
-
-2003-01-21 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-11-13 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-10-24 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-03-27 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Remove AUTOMAKE_OPTIONS.
-
-2002-01-18 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Require automake-1.5.
-
-2001-01-17 Joel Sherrill <joel@OARcorp.com>
-
- * .cvsignore: Added rtems_header.html and rtems_footer.html.
-
-2000-08-10 Joel Sherrill <joel@OARcorp.com>
-
- * ChangeLog: New file.
diff --git a/doc/supplements/sparc/ERC32_TIMES b/doc/supplements/sparc/ERC32_TIMES
deleted file mode 100644
index 4f9ce4c98b..0000000000
--- a/doc/supplements/sparc/ERC32_TIMES
+++ /dev/null
@@ -1,247 +0,0 @@
-#
-# SPARC/ERC32/SIS Timing and Size Information
-#
-# $Id$
-#
-
-#
-# CPU Model Information
-#
-RTEMS_BSP ERC32
-RTEMS_CPU_MODEL ERC32
-#
-# Interrupt Latency
-#
-# NOTE: In general, the text says it is hand-calculated to be
-# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-# Mhz and this was last calculated for Release
-# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
-#
-RTEMS_MAXIMUM_DISABLE_PERIOD TBD
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 15.0
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.2.0-prerelease
-#
-# Context Switch Times
-#
-RTEMS_NO_FP_CONTEXTS 21
-RTEMS_RESTORE_1ST_FP_TASK 26
-RTEMS_SAVE_INIT_RESTORE_INIT 24
-RTEMS_SAVE_IDLE_RESTORE_INIT 23
-RTEMS_SAVE_IDLE_RESTORE_IDLE 33
-#
-# Task Manager Times
-#
-RTEMS_TASK_CREATE_ONLY 59
-RTEMS_TASK_IDENT_ONLY 163
-RTEMS_TASK_START_ONLY 30
-RTEMS_TASK_RESTART_CALLING_TASK 64
-RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 36
-RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 47
-RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 37
-RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 77
-RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 84
-RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 75
-RTEMS_TASK_DELETE_CALLING_TASK 91
-RTEMS_TASK_DELETE_SUSPENDED_TASK 47
-RTEMS_TASK_DELETE_BLOCKED_TASK 50
-RTEMS_TASK_DELETE_READY_TASK 51
-RTEMS_TASK_SUSPEND_CALLING_TASK 56
-RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 16
-RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 17
-RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 52
-RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 10
-RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 25
-RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 67
-RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 5
-RTEMS_TASK_MODE_NO_RESCHEDULE 6
-RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 9
-RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 42
-RTEMS_TASK_GET_NOTE_ONLY 10
-RTEMS_TASK_SET_NOTE_ONLY 10
-RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 6
-RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 49
-RTEMS_TASK_WAKE_WHEN_ONLY 75
-#
-# Interrupt Manager
-#
-RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 7
-RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 8
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 8
-RTEMS_INTR_EXIT_RETURNS_TO_NESTED 5
-RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 7
-RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 14
-#
-# Clock Manager
-#
-RTEMS_CLOCK_SET_ONLY 33
-RTEMS_CLOCK_GET_ONLY 4
-RTEMS_CLOCK_TICK_ONLY 6
-#
-# Timer Manager
-#
-RTEMS_TIMER_CREATE_ONLY 11
-RTEMS_TIMER_IDENT_ONLY 159
-RTEMS_TIMER_DELETE_INACTIVE 15
-RTEMS_TIMER_DELETE_ACTIVE 17
-RTEMS_TIMER_FIRE_AFTER_INACTIVE 21
-RTEMS_TIMER_FIRE_AFTER_ACTIVE 23
-RTEMS_TIMER_FIRE_WHEN_INACTIVE 34
-RTEMS_TIMER_FIRE_WHEN_ACTIVE 34
-RTEMS_TIMER_RESET_INACTIVE 20
-RTEMS_TIMER_RESET_ACTIVE 22
-RTEMS_TIMER_CANCEL_INACTIVE 10
-RTEMS_TIMER_CANCEL_ACTIVE 13
-#
-# Semaphore Manager
-#
-RTEMS_SEMAPHORE_CREATE_ONLY 19
-RTEMS_SEMAPHORE_IDENT_ONLY 171
-RTEMS_SEMAPHORE_DELETE_ONLY 19
-RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 12
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 12
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 67
-RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 14
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 23
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 57
-#
-# Message Manager
-#
-RTEMS_MESSAGE_QUEUE_CREATE_ONLY 114
-RTEMS_MESSAGE_QUEUE_IDENT_ONLY 159
-RTEMS_MESSAGE_QUEUE_DELETE_ONLY 25
-RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 36
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 38
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 76
-RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 36
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 38
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 76
-RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 15
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 42
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 83
-RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 30
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 13
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 67
-RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 9
-RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 13
-#
-# Event Manager
-#
-RTEMS_EVENT_SEND_NO_TASK_READIED 9
-RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 22
-RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 58
-RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1
-RTEMS_EVENT_RECEIVE_AVAILABLE 10
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 9
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 60
-#
-# Signal Manager
-#
-RTEMS_SIGNAL_CATCH_ONLY 6
-RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 14
-RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 22
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 27
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 56
-#
-# Partition Manager
-#
-RTEMS_PARTITION_CREATE_ONLY 34
-RTEMS_PARTITION_IDENT_ONLY 159
-RTEMS_PARTITION_DELETE_ONLY 14
-RTEMS_PARTITION_GET_BUFFER_AVAILABLE 12
-RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 10
-RTEMS_PARTITION_RETURN_BUFFER_ONLY 16
-#
-# Region Manager
-#
-RTEMS_REGION_CREATE_ONLY 22
-RTEMS_REGION_IDENT_ONLY 162
-RTEMS_REGION_DELETE_ONLY 14
-RTEMS_REGION_GET_SEGMENT_AVAILABLE 19
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 19
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 67
-RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 17
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 44
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 77
-#
-# Dual-Ported Memory Manager
-#
-RTEMS_PORT_CREATE_ONLY 14
-RTEMS_PORT_IDENT_ONLY 159
-RTEMS_PORT_DELETE_ONLY 13
-RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 9
-RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 9
-#
-# IO Manager
-#
-RTEMS_IO_INITIALIZE_ONLY 2
-RTEMS_IO_OPEN_ONLY 1
-RTEMS_IO_CLOSE_ONLY 1
-RTEMS_IO_READ_ONLY 1
-RTEMS_IO_WRITE_ONLY 1
-RTEMS_IO_CONTROL_ONLY 1
-#
-# Rate Monotonic Manager
-#
-RTEMS_RATE_MONOTONIC_CREATE_ONLY 12
-RTEMS_RATE_MONOTONIC_IDENT_ONLY 159
-RTEMS_RATE_MONOTONIC_CANCEL_ONLY 14
-RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 19
-RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 16
-RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 20
-RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 55
-RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 9
-#
-# Size Information
-#
-#
-# xxx alloted for numbers
-#
-RTEMS_DATA_SPACE 9059
-RTEMS_MINIMUM_CONFIGURATION 28,288
-RTEMS_MAXIMUM_CONFIGURATION 50,432
-# x,xxx alloted for numbers
-RTEMS_CORE_CODE_SIZE 20,336
-RTEMS_INITIALIZATION_CODE_SIZE 1,408
-RTEMS_TASK_CODE_SIZE 4,496
-RTEMS_INTERRUPT_CODE_SIZE 72
-RTEMS_CLOCK_CODE_SIZE 576
-RTEMS_TIMER_CODE_SIZE 1,336
-RTEMS_SEMAPHORE_CODE_SIZE 1,888
-RTEMS_MESSAGE_CODE_SIZE 2,032
-RTEMS_EVENT_CODE_SIZE 1,696
-RTEMS_SIGNAL_CODE_SIZE 664
-RTEMS_PARTITION_CODE_SIZE 1,368
-RTEMS_REGION_CODE_SIZE 1,736
-RTEMS_DPMEM_CODE_SIZE 872
-RTEMS_IO_CODE_SIZE 1,144
-RTEMS_FATAL_ERROR_CODE_SIZE 32
-RTEMS_RATE_MONOTONIC_CODE_SIZE 1,656
-RTEMS_MULTIPROCESSING_CODE_SIZE 8,328
-# xxx alloted for numbers
-RTEMS_TIMER_CODE_OPTSIZE 208
-RTEMS_SEMAPHORE_CODE_OPTSIZE 192
-RTEMS_MESSAGE_CODE_OPTSIZE 320
-RTEMS_EVENT_CODE_OPTSIZE 64
-RTEMS_SIGNAL_CODE_OPTSIZE 64
-RTEMS_PARTITION_CODE_OPTSIZE 152
-RTEMS_REGION_CODE_OPTSIZE 176
-RTEMS_DPMEM_CODE_OPTSIZE 152
-RTEMS_IO_CODE_OPTSIZE 00
-RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 208
-RTEMS_MULTIPROCESSING_CODE_OPTSIZE 408
-# xxx alloted for numbers
-RTEMS_BYTES_PER_TASK 488
-RTEMS_BYTES_PER_TIMER 68
-RTEMS_BYTES_PER_SEMAPHORE 124
-RTEMS_BYTES_PER_MESSAGE_QUEUE 148
-RTEMS_BYTES_PER_REGION 144
-RTEMS_BYTES_PER_PARTITION 56
-RTEMS_BYTES_PER_PORT 36
-RTEMS_BYTES_PER_PERIOD 36
-RTEMS_BYTES_PER_EXTENSION 64
-RTEMS_BYTES_PER_FP_TASK 136
-RTEMS_BYTES_PER_NODE 48
-RTEMS_BYTES_PER_GLOBAL_OBJECT 20
-RTEMS_BYTES_PER_PROXY 124
-# x,xxx alloted for numbers
-RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 10,072
diff --git a/doc/supplements/sparc/Makefile.am b/doc/supplements/sparc/Makefile.am
deleted file mode 100644
index 14ec898a66..0000000000
--- a/doc/supplements/sparc/Makefile.am
+++ /dev/null
@@ -1,108 +0,0 @@
-#
-# COPYRIGHT (c) 1988-2002.
-# On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# $Id$
-#
-
-PROJECT = sparc
-EDITION = 1
-
-include $(top_srcdir)/project.am
-include $(top_srcdir)/supplements/supplement.am
-
-GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \
- fatalerr.texi bsp.texi cputable.texi timing.texi wksheets.texi \
- timeERC32.texi
-
-COMMON_FILES += $(top_srcdir)/common/cpright.texi
-
-FILES = preface.texi
-
-info_TEXINFOS = sparc.texi
-sparc_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
-
-#
-# Chapters which get automatic processing
-#
-
-cpumodel.texi: cpumodel.t
- $(BMENU2) -p "Preface" \
- -u "Top" \
- -n "Calling Conventions" < $< > $@
-
-callconv.texi: callconv.t
- $(BMENU2) -p "CPU Model Dependent Features CPU Model Implementation Notes" \
- -u "Top" \
- -n "Memory Model" < $< > $@
-
-memmodel.texi: memmodel.t
- $(BMENU2) -p "Calling Conventions User-Provided Routines" \
- -u "Top" \
- -n "Interrupt Processing" < $< > $@
-
-# Interrupt Chapter:
-# 1. Replace Times and Sizes
-# 2. Build Node Structure
-intr.texi: intr_NOTIMES.t ERC32_TIMES
- ${REPLACE2} -p $(srcdir)/ERC32_TIMES $(srcdir)/intr_NOTIMES.t | \
- $(BMENU2) -p "Memory Model Flat Memory Model" \
- -u "Top" \
- -n "Default Fatal Error Processing" > $@
-
-fatalerr.texi: fatalerr.t
- $(BMENU2) -p "Interrupt Processing Interrupt Stack" \
- -u "Top" \
- -n "Board Support Packages" < $< > $@
-
-bsp.texi: bsp.t
- $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
- -u "Top" \
- -n "Processor Dependent Information Table" < $< > $@
-
-cputable.texi: cputable.t
- $(BMENU2) -p "Board Support Packages Processor Initialization" \
- -u "Top" \
- -n "Memory Requirements" < $< > $@
-
-# Worksheets Chapter:
-# 1. Obtain the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-wksheets.texi: $(top_srcdir)/common/wksheets.t ERC32_TIMES
- ${REPLACE2} -p $(srcdir)/ERC32_TIMES $(top_srcdir)/common/wksheets.t | \
- $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \
- -u "Top" \
- -n "Timing Specification" > $@
-
-# Timing Specification Chapter:
-# 1. Copy the Shared File
-# 3. Build Node Structure
-timing.texi: $(top_srcdir)/common/timing.t
- $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \
- -u "Top" \
- -n "ERC32 Timing Data" < $< > $@
-
-# Timing Data for ERC32 BSP Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-timeERC32.texi: $(top_srcdir)/common/timetbl.t timeERC32.t
- cat $(srcdir)/timeERC32.t $(top_srcdir)/common/timetbl.t >timeERC32_.t
- @echo >>timeERC32_.t
- @echo "@tex" >>timeERC32_.t
- @echo "\\global\\advance \\smallskipamount by 4pt" >>timeERC32_.t
- @echo "@end tex" >>timeERC32_.t
- ${REPLACE2} -p $(srcdir)/ERC32_TIMES timeERC32_.t | \
- $(BMENU2) -p "Timing Specification Terminology" \
- -u "Top" \
- -n "Command and Variable Index" > $@
-CLEANFILES += timeERC32_.t
-
-EXTRA_DIST = ERC32_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \
- intr_NOTIMES.t memmodel.t timeERC32.t
-
-CLEANFILES += sparc.info sparc.info-?
diff --git a/doc/supplements/sparc/bsp.t b/doc/supplements/sparc/bsp.t
deleted file mode 100644
index 8810614825..0000000000
--- a/doc/supplements/sparc/bsp.t
+++ /dev/null
@@ -1,87 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Board Support Packages
-
-@section Introduction
-
-An RTEMS Board Support Package (BSP) must be designed
-to support a particular processor and target board combination.
-This chapter presents a discussion of SPARC specific BSP issues.
-For more information on developing a BSP, refer to the chapter
-titled Board Support Packages in the RTEMS
-Applications User's Guide.
-
-@section System Reset
-
-An RTEMS based application is initiated or
-re-initiated when the SPARC processor is reset. When the SPARC
-is reset, the processor performs the following actions:
-
-@itemize @bullet
-@item the enable trap (ET) of the psr is set to 0 to disable
-traps,
-
-@item the supervisor bit (S) of the psr is set to 1 to enter
-supervisor mode, and
-
-@item the PC is set 0 and the nPC is set to 4.
-@end itemize
-
-The processor then begins to execute the code at
-location 0. It is important to note that all fields in the psr
-are not explicitly set by the above steps and all other
-registers retain their value from the previous execution mode.
-This is true even of the Trap Base Register (TBR) whose contents
-reflect the last trap which occurred before the reset.
-
-@section Processor Initialization
-
-It is the responsibility of the application's
-initialization code to initialize the TBR and install trap
-handlers for at least the register window overflow and register
-window underflow conditions. Traps should be enabled before
-invoking any subroutines to allow for register window
-management. However, interrupts should be disabled by setting
-the Processor Interrupt Level (pil) field of the psr to 15.
-RTEMS installs it's own Trap Table as part of initialization
-which is initialized with the contents of the Trap Table in
-place when the @code{rtems_initialize_executive} directive was invoked.
-Upon completion of executive initialization, interrupts are
-enabled.
-
-If this SPARC implementation supports on-chip caching
-and this is to be utilized, then it should be enabled during the
-reset application initialization code.
-
-In addition to the requirements described in the
-Board Support Packages chapter of the @value{LANGUAGE}
-Applications User's Manual for the reset code
-which is executed before the call to
-@code{rtems_initialize_executive}, the SPARC version has the following
-specific requirements:
-
-@itemize @bullet
-@item Must leave the S bit of the status register set so that
-the SPARC remains in the supervisor state.
-
-@item Must set stack pointer (sp) such that a minimum stack
-size of MINIMUM_STACK_SIZE bytes is provided for the
-@code{rtems_initialize_executive} directive.
-
-@item Must disable all external interrupts (i.e. set the pil
-to 15).
-
-@item Must enable traps so window overflow and underflow
-conditions can be properly handled.
-
-@item Must initialize the SPARC's initial trap table with at
-least trap handlers for register window overflow and register
-window underflow.
-@end itemize
-
diff --git a/doc/supplements/sparc/callconv.t b/doc/supplements/sparc/callconv.t
deleted file mode 100644
index 2b968ebb0b..0000000000
--- a/doc/supplements/sparc/callconv.t
+++ /dev/null
@@ -1,392 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Calling Conventions
-
-@section Introduction
-
-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.
-
-@section Programming Model
-
-This section discusses the programming model for the
-SPARC architecture.
-
-@subsection Non-Floating Point Registers
-
-The SPARC architecture defines thirty-two
-non-floating point registers directly visible to the programmer.
-These are divided into four sets:
-
-@itemize @bullet
-@item input registers
-
-@item local registers
-
-@item output registers
-
-@item global registers
-@end itemize
-
-Each register is referred to by either two or three
-names in the SPARC reference manuals. First, the registers are
-referred to as r0 through r31 or with the alternate notation
-r[0] through r[31]. Second, each register is a member of one of
-the four sets listed above. Finally, some registers have an
-architecturally defined role in the programming model which
-provides an alternate name. The following table describes the
-mapping between the 32 registers and the register sets:
-
-@ifset use-ascii
-@example
-@group
- +-----------------+----------------+------------------+
- | Register Number | Register Names | Description |
- +-----------------+----------------+------------------+
- | 0 - 7 | g0 - g7 | Global Registers |
- +-----------------+----------------+------------------+
- | 8 - 15 | o0 - o7 | Output Registers |
- +-----------------+----------------+------------------+
- | 16 - 23 | l0 - l7 | Local Registers |
- +-----------------+----------------+------------------+
- | 24 - 31 | i0 - i7 | Input Registers |
- +-----------------+----------------+------------------+
-@end group
-@end example
-@end ifset
-
-@ifset use-tex
-@sp 1
-@tex
-\centerline{\vbox{\offinterlineskip\halign{
-\vrule\strut#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#\cr
-\noalign{\hrule}
-&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule}
-&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule}
-&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule}
-&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule}
-&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule}
-}}\hfil}
-@end tex
-@end ifset
-
-@ifset use-html
-@html
-<CENTER>
- <TABLE COLS=3 WIDTH="80%" BORDER=2>
-<TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD>
- <TD ALIGN=center><STRONG>Register Names</STRONG></TD>
- <TD ALIGN=center><STRONG>Description</STRONG></TD>
-<TR><TD ALIGN=center>0 - 7</TD>
- <TD ALIGN=center>g0 - g7</TD>
- <TD ALIGN=center>Global Registers</TD></TR>
-<TR><TD ALIGN=center>8 - 15</TD>
- <TD ALIGN=center>o0 - o7</TD>
- <TD ALIGN=center>Output Registers</TD></TR>
-<TR><TD ALIGN=center>16 - 23</TD>
- <TD ALIGN=center>l0 - l7</TD>
- <TD ALIGN=center>Local Registers</TD></TR>
-<TR><TD ALIGN=center>24 - 31</TD>
- <TD ALIGN=center>i0 - i7</TD>
- <TD ALIGN=center>Input Registers</TD></TR>
- </TABLE>
-</CENTER>
-@end html
-@end ifset
-
-As mentioned above, some of the registers serve
-defined roles in the programming model. The following table
-describes the role of each of these registers:
-
-@ifset use-ascii
-@example
-@group
- +---------------+----------------+----------------------+
- | Register Name | Alternate Name | Description |
- +---------------+----------------+----------------------+
- | g0 | na | reads return 0 |
- | | | writes are ignored |
- +---------------+----------------+----------------------+
- | o6 | sp | stack pointer |
- +---------------+----------------+----------------------+
- | i6 | fp | frame pointer |
- +---------------+----------------+----------------------+
- | i7 | na | return address |
- +---------------+----------------+----------------------+
-@end group
-@end example
-@end ifset
-
-@ifset use-tex
-@sp 1
-@tex
-\centerline{\vbox{\offinterlineskip\halign{
-\vrule\strut#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#\cr
-\noalign{\hrule}
-&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule}
-&g0&&NA&&reads return 0; &\cr
-&&&&&writes are ignored&\cr\noalign{\hrule}
-&o6&&sp&&stack pointer&\cr\noalign{\hrule}
-&i6&&fp&&frame pointer&\cr\noalign{\hrule}
-&i7&&NA&&return address&\cr\noalign{\hrule}
-}}\hfil}
-@end tex
-@end ifset
-
-@ifset use-html
-@html
-<CENTER>
- <TABLE COLS=3 WIDTH="80%" BORDER=2>
-<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD>
- <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD>
- <TD ALIGN=center><STRONG>Description</STRONG></TD></TR>
-<TR><TD ALIGN=center>g0</TD>
- <TD ALIGN=center>NA</TD>
- <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR>
-<TR><TD ALIGN=center>o6</TD>
- <TD ALIGN=center>sp</TD>
- <TD ALIGN=center>stack pointer</TD></TR>
-<TR><TD ALIGN=center>i6</TD>
- <TD ALIGN=center>fp</TD>
- <TD ALIGN=center>frame pointer</TD></TR>
-<TR><TD ALIGN=center>i7</TD>
- <TD ALIGN=center>NA</TD>
- <TD ALIGN=center>return address</TD></TR>
- </TABLE>
-</CENTER>
-@end html
-@end ifset
-
-
-@subsection Floating Point Registers
-
-The SPARC V7 architecture includes thirty-two,
-thirty-two bit registers. These registers may be viewed as
-follows:
-
-@itemize @bullet
-@item 32 single precision floating point or integer registers
-(f0, f1, ... f31)
-
-@item 16 double precision floating point registers (f0, f2,
-f4, ... f30)
-
-@item 8 extended precision floating point registers (f0, f4,
-f8, ... f28)
-@end itemize
-
-The floating point status register (fpsr) specifies
-the behavior of the floating point unit for rounding, contains
-its condition codes, version specification, and trap information.
-
-A queue of the floating point instructions which have
-started execution but not yet completed is maintained. This
-queue is needed to support the multiple cycle nature of floating
-point operations and to aid floating point exception trap
-handlers. Once a floating point exception has been encountered,
-the queue is frozen until it is emptied by the trap handler.
-The floating point queue is loaded by launching instructions.
-It is emptied normally when the floating point completes all
-outstanding instructions and by floating point exception
-handlers with the store double floating point queue (stdfq)
-instruction.
-
-@subsection Special Registers
-
-The SPARC architecture includes two special registers
-which are critical to the programming model: the Processor State
-Register (psr) and the Window Invalid Mask (wim). The psr
-contains the condition codes, processor interrupt level, trap
-enable bit, supervisor mode and previous supervisor mode bits,
-version information, floating point unit and coprocessor enable
-bits, and the current window pointer (cwp). The cwp field of
-the psr and wim register are used to manage the register windows
-in the SPARC architecture. The register windows are discussed
-in more detail below.
-
-@section Register Windows
-
-The SPARC architecture includes the concept of
-register windows. An overly simplistic way to think of these
-windows is to imagine them as being an infinite supply of
-"fresh" register sets available for each subroutine to use. In
-reality, they are much more complicated.
-
-The save instruction is used to obtain a new register
-window. This instruction decrements the current window pointer,
-thus providing a new set of registers for use. This register
-set includes eight fresh local registers for use exclusively by
-this subroutine. When done with a register set, the restore
-instruction increments the current window pointer and the
-previous register set is once again available.
-
-The two primary issues complicating the use of
-register windows are that (1) the set of register windows is
-finite, and (2) some registers are shared between adjacent
-registers windows.
-
-Because the set of register windows is finite, it is
-possible to execute enough save instructions without
-corresponding restore's to consume all of the register windows.
-This is easily accomplished in a high level language because
-each subroutine typically performs a save instruction upon
-entry. Thus having a subroutine call depth greater than the
-number of register windows will result in a window overflow
-condition. The window overflow condition generates a trap which
-must be handled in software. The window overflow trap handler
-is responsible for saving the contents of the oldest register
-window on the program stack.
-
-Similarly, the subroutines will eventually complete
-and begin to perform restore's. If the restore results in the
-need for a register window which has previously been written to
-memory as part of an overflow, then a window underflow condition
-results. Just like the window overflow, the window underflow
-condition must be handled in software by a trap handler. The
-window underflow trap handler is responsible for reloading the
-contents of the register window requested by the restore
-instruction from the program stack.
-
-The Window Invalid Mask (wim) and the Current Window
-Pointer (cwp) field in the psr are used in conjunction to manage
-the finite set of register windows and detect the window
-overflow and underflow conditions. The cwp contains the index
-of the register window currently in use. The save instruction
-decrements the cwp modulo the number of register windows.
-Similarly, the restore instruction increments the cwp modulo the
-number of register windows. Each bit in the wim represents
-represents whether a register window contains valid information.
-The value of 0 indicates the register window is valid and 1
-indicates it is invalid. When a save instruction causes the cwp
-to point to a register window which is marked as invalid, a
-window overflow condition results. Conversely, the restore
-instruction may result in a window underflow condition.
-
-Other than the assumption that a register window is
-always available for trap (i.e. interrupt) handlers, the SPARC
-architecture places no limits on the number of register windows
-simultaneously marked as invalid (i.e. number of bits set in the
-wim). However, RTEMS assumes that only one register window is
-marked invalid at a time (i.e. only one bit set in the wim).
-This makes the maximum possible number of register windows
-available to the user while still meeting the requirement that
-window overflow and underflow conditions can be detected.
-
-The window overflow and window underflow trap
-handlers are a critical part of the run-time environment for a
-SPARC application. The SPARC architectural specification allows
-for the number of register windows to be any power of two less
-than or equal to 32. The most common choice for SPARC
-implementations appears to be 8 register windows. This results
-in the cwp ranging in value from 0 to 7 on most implementations.
-
-
-The second complicating factor is the sharing of
-registers between adjacent register windows. While each
-register window has its own set of local registers, the input
-and output registers are shared between adjacent windows. The
-output registers for register window N are the same as the input
-registers for register window ((N - 1) modulo RW) where RW is
-the number of register windows. An alternative way to think of
-this is to remember how parameters are passed to a subroutine on
-the SPARC. The caller loads values into what are its output
-registers. Then after the callee executes a save instruction,
-those parameters are available in its input registers. This is
-a very efficient way to pass parameters as no data is actually
-moved by the save or restore instructions.
-
-@section Call and Return Mechanism
-
-The SPARC architecture supports a simple yet
-effective call and return mechanism. A subroutine is invoked
-via the call (call) instruction. This instruction places the
-return address in the caller's output register 7 (o7). After
-the callee executes a save instruction, this value is available
-in input register 7 (i7) until the corresponding restore
-instruction is executed.
-
-The callee returns to the caller via a jmp to the
-return address. There is a delay slot following this
-instruction which is commonly used to execute a restore
-instruction -- if a register window was allocated by this
-subroutine.
-
-It is important to note that the SPARC subroutine
-call and return mechanism does not automatically save and
-restore any registers. This is accomplished via the save and
-restore instructions which manage the set of registers windows.
-
-@section Calling Mechanism
-
-All RTEMS directives are invoked using the regular
-SPARC calling convention via the call instruction.
-
-@section Register Usage
-
-As discussed above, the call instruction does not
-automatically save any registers. The save and restore
-instructions are used to allocate and deallocate register
-windows. When a register window is allocated, the new set of
-local registers are available for the exclusive use of the
-subroutine which allocated this register set.
-
-@section Parameter Passing
-
-RTEMS assumes that arguments are placed in the
-caller's output registers with the first argument in output
-register 0 (o0), the second argument in output register 1 (o1),
-and so forth. Until the callee executes a save instruction, the
-parameters are still visible in the output registers. After the
-callee executes a save instruction, the parameters are visible
-in the corresponding input registers. The following pseudo-code
-illustrates the typical sequence used to call a RTEMS directive
-with three (3) arguments:
-
-@example
-load third argument into o2
-load second argument into o1
-load first argument into o0
-invoke directive
-@end example
-
-@section 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.
-
diff --git a/doc/supplements/sparc/cpumodel.t b/doc/supplements/sparc/cpumodel.t
deleted file mode 100644
index d676fcc480..0000000000
--- a/doc/supplements/sparc/cpumodel.t
+++ /dev/null
@@ -1,128 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter CPU Model Dependent Features
-
-@section Introduction
-
-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.
-
-@section 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 SPARC implementations and are of importance to RTEMS.
-The set of CPU model feature macros are defined in the file
-cpukit/score/cpu/sparc/sparc.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 European Space
-Agency's ERC32 SPARC model, this macro is set to the string
-"erc32".
-
-@subsection Floating Point Unit
-
-The macro SPARC_HAS_FPU is set to 1 to indicate that
-this CPU model has a hardware floating point unit and 0
-otherwise.
-
-@subsection Bitscan Instruction
-
-The macro SPARC_HAS_BITSCAN is set to 1 to indicate
-that this CPU model has the bitscan instruction. For example,
-this instruction is supported by the Fujitsu SPARClite family.
-
-@subsection Number of Register Windows
-
-The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to
-indicate the number of register window sets implemented by this
-CPU model. The SPARC architecture allows a for a maximum of
-thirty-two register window sets although most implementations
-only include eight.
-
-@subsection Low Power Mode
-
-The macro SPARC_HAS_LOW_POWER_MODE is set to one to
-indicate that this CPU model has a low power mode. If low power
-is enabled, then there must be CPU model specific implementation
-of the IDLE task in cpukit/score/cpu/sparc/cpu.c. The low
-power mode IDLE task should be of the form:
-
-@example
-while ( TRUE ) @{
- enter low power mode
-@}
-@end example
-
-The code required to enter low power mode is CPU model specific.
-
-@section CPU Model Implementation Notes
-
-The ERC32 is a custom SPARC V7 implementation based on the Cypress 601/602
-chipset. This CPU has a number of on-board peripherals and was developed by
-the European Space Agency to target space applications. RTEMS currently
-provides support for the following peripherals:
-
-@itemize @bullet
-@item UART Channels A and B
-@item General Purpose Timer
-@item Real Time Clock
-@item Watchdog Timer (so it can be disabled)
-@item Control Register (so powerdown mode can be enabled)
-@item Memory Control Register
-@item Interrupt Control
-@end itemize
-
-The General Purpose Timer and Real Time Clock Timer provided with the ERC32
-share the Timer Control Register. Because the Timer Control Register is write
-only, we must mirror it in software and insure that writes to one timer do not
-alter the current settings and status of the other timer. Routines are
-provided in erc32.h which promote the view that the two timers are completely
-independent. By exclusively using these routines to access the Timer Control
-Register, the application can view the system as having a General Purpose
-Timer Control Register and a Real Time Clock Timer Control Register
-rather than the single shared value.
-
-The RTEMS Idle thread take advantage of the low power mode provided by the
-ERC32. Low power mode is entered during idle loops and is enabled at
-initialization time.
diff --git a/doc/supplements/sparc/cputable.t b/doc/supplements/sparc/cputable.t
deleted file mode 100644
index 22873590c1..0000000000
--- a/doc/supplements/sparc/cputable.t
+++ /dev/null
@@ -1,102 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Processor Dependent Information Table
-
-@section Introduction
-
-Any highly processor dependent information required
-to describe a processor to RTEMS is provided in the CPU
-Dependent Information Table. This table is not required for all
-processors supported by RTEMS. This chapter describes the
-contents, if any, for a particular processor type.
-
-@section CPU Dependent Information Table
-
-The SPARC version of the RTEMS CPU Dependent
-Information Table is given by the C structure definition is
-shown below:
-
-@example
-@group
-typedef struct @{
- void (*pretasking_hook)( void );
- void (*predriver_hook)( void );
- void (*postdriver_hook)( void );
- void (*idle_task)( void );
- boolean do_zero_of_workspace;
- unsigned32 idle_task_stack_size;
- unsigned32 interrupt_stack_size;
- unsigned32 extra_mpci_receive_server_stack;
- void * (*stack_allocate_hook)( unsigned32 );
- void (*stack_free_hook)( void* );
- /* end of fields required on all CPUs */
-
-@} rtems_cpu_table;
-@end group
-@end example
-
-@table @code
-@item pretasking_hook
-is the address of the user provided routine which is invoked
-once RTEMS APIs are initialized. This routine will be invoked
-before any system tasks are created. Interrupts are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item predriver_hook
-is the address of the user provided
-routine that is invoked immediately before the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item postdriver_hook
-is the address of the user provided
-routine that is invoked immediately after the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item idle_task
-is the address of the optional user
-provided routine which is used as the system's IDLE task. If
-this field is not NULL, then the RTEMS default IDLE task is not
-used. This field may be NULL to indicate that the default IDLE
-is to be used.
-
-@item do_zero_of_workspace
-indicates whether RTEMS should
-zero the Workspace as part of its initialization. If set to
-TRUE, the Workspace is zeroed. Otherwise, it is not.
-
-@item idle_task_stack_size
-is the size of the RTEMS idle task stack in bytes.
-If this number is less than MINIMUM_STACK_SIZE, then the
-idle task's stack will be MINIMUM_STACK_SIZE in byte.
-
-@item interrupt_stack_size
-is the size of the RTEMS allocated interrupt stack in bytes.
-This value must be at least as large as MINIMUM_STACK_SIZE.
-
-@item extra_mpci_receive_server_stack
-is the extra stack space allocated for the RTEMS MPCI receive server task
-in bytes. The MPCI receive server may invoke nearly all directives and
-may require extra stack space on some targets.
-
-@item stack_allocate_hook
-is the address of the optional user provided routine which allocates
-memory for task stacks. If this hook is not NULL, then a stack_free_hook
-must be provided as well.
-
-@item stack_free_hook
-is the address of the optional user provided routine which frees
-memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
-must be provided as well.
-
-@end table
-
diff --git a/doc/supplements/sparc/fatalerr.t b/doc/supplements/sparc/fatalerr.t
deleted file mode 100644
index 6de94ba8f4..0000000000
--- a/doc/supplements/sparc/fatalerr.t
+++ /dev/null
@@ -1,32 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Default Fatal Error Processing
-
-@section Introduction
-
-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.
-
-@section Default Fatal Error Handler Operations
-
-The default fatal error handler which is invoked by
-the fatal_error_occurred directive when there is no user handler
-configured or the user handler returns control to RTEMS. The
-default fatal error handler disables processor interrupts to
-level 15, places the error code in g1, and goes into an infinite
-loop to simulate a halt processor instruction.
-
-
diff --git a/doc/supplements/sparc/intr_NOTIMES.t b/doc/supplements/sparc/intr_NOTIMES.t
deleted file mode 100644
index a66ccc981d..0000000000
--- a/doc/supplements/sparc/intr_NOTIMES.t
+++ /dev/null
@@ -1,199 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Interrupt Processing
-
-@section Introduction
-
-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 SPARC's
-interrupt response and control mechanisms as they pertain to
-RTEMS.
-
-RTEMS and associated documentation uses the terms
-interrupt and vector. In the SPARC architecture, these terms
-correspond to traps and trap type, respectively. The terms will
-be used interchangeably in this manual.
-
-@section Synchronous Versus Asynchronous Traps
-
-The SPARC architecture includes two classes of traps:
-synchronous and asynchronous. Asynchronous traps occur when an
-external event interrupts the processor. These traps are not
-associated with any instruction executed by the processor and
-logically occur between instructions. The instruction currently
-in the execute stage of the processor is allowed to complete
-although subsequent instructions are annulled. The return
-address reported by the processor for asynchronous traps is the
-pair of instructions following the current instruction.
-
-Synchronous traps are caused by the actions of an
-instruction. The trap stimulus in this case either occurs
-internally to the processor or is from an external signal that
-was provoked by the instruction. These traps are taken
-immediately and the instruction that caused the trap is aborted
-before any state changes occur in the processor itself. The
-return address reported by the processor for synchronous traps
-is the instruction which caused the trap and the following
-instruction.
-
-@section Vectoring of Interrupt Handler
-
-Upon receipt of an interrupt the SPARC automatically
-performs the following actions:
-
-@itemize @bullet
-@item disables traps (sets the ET bit of the psr to 0),
-
-@item the S bit of the psr is copied into the Previous
-Supervisor Mode (PS) bit of the psr,
-
-@item the cwp is decremented by one (modulo the number of
-register windows) to activate a trap window,
-
-@item the PC and nPC are loaded into local register 1 and 2
-(l0 and l1),
-
-@item the trap type (tt) field of the Trap Base Register (TBR)
-is set to the appropriate value, and
-
-@item if the trap is not a reset, then the PC is written with
-the contents of the TBR and the nPC is written with TBR + 4. If
-the trap is a reset, then the PC is set to zero and the nPC is
-set to 4.
-@end itemize
-
-Trap processing on the SPARC has two features which
-are noticeably different than interrupt processing on other
-architectures. First, the value of psr register in effect
-immediately before the trap occurred is not explicitly saved.
-Instead only reversible alterations are made to it. Second, the
-Processor Interrupt Level (pil) is not set to correspond to that
-of the interrupt being processed. When a trap occurs, ALL
-subsequent traps are disabled. In order to safely invoke a
-subroutine during trap handling, traps must be enabled to allow
-for the possibility of register window overflow and underflow
-traps.
-
-If the interrupt handler was installed as an RTEMS
-interrupt handler, then upon receipt of the interrupt, the
-processor passes control to the RTEMS interrupt handler which
-performs the following actions:
-
-@itemize @bullet
-@item saves the state of the interrupted task on it's stack,
-
-@item insures that a register window is available for
-subsequent traps,
-
-@item if this is the outermost (i.e. non-nested) interrupt,
-then the RTEMS interrupt handler switches from the current stack
-to the interrupt stack,
-
-@item enables traps,
-
-@item invokes the vectors to a user interrupt service routine (ISR).
-@end itemize
-
-Asynchronous interrupts are ignored while traps are
-disabled. Synchronous traps which occur while traps are
-disabled result in the CPU being forced into an error mode.
-
-A nested interrupt is processed similarly with the
-exception that the current stack need not be switched to the
-interrupt stack.
-
-@section Traps and Register Windows
-
-One of the register windows must be reserved at all
-times for trap processing. This is critical to the proper
-operation of the trap mechanism in the SPARC architecture. It
-is the responsibility of the trap handler to insure that there
-is a register window available for a subsequent trap before
-re-enabling traps. It is likely that any high level language
-routines invoked by the trap handler (such as a user-provided
-RTEMS interrupt handler) will allocate a new register window.
-The save operation could result in a window overflow trap. This
-trap cannot be correctly processed unless (1) traps are enabled
-and (2) a register window is reserved for traps. Thus, the
-RTEMS interrupt handler insures that a register window is
-available for subsequent traps before enabling traps and
-invoking the user's interrupt handler.
-
-@section Interrupt Levels
-
-Sixteen levels (0-15) of interrupt priorities are
-supported by the SPARC architecture with level fifteen (15)
-being the highest priority. Level zero (0) indicates that
-interrupts are fully enabled. Interrupt requests for interrupts
-with priorities less than or equal to the current interrupt mask
-level are ignored.
-
-Although RTEMS supports 256 interrupt levels, the
-SPARC only supports sixteen. RTEMS interrupt levels 0 through
-15 directly correspond to SPARC processor interrupt levels. All
-other RTEMS interrupt levels are undefined and their behavior is
-unpredictable.
-
-@section 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 (15)
-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 ERC32 with zero wait states.
-These numbers will vary based the number of wait states and
-processor speed present on the target board.
-[NOTE: The maximum period with interrupts disabled is hand calculated. This
-calculation was last performed for Release
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-[NOTE: It is thought that the length of time at which
-the processor interrupt level is elevated to fifteen by RTEMS is
-not anywhere near as long as the length of time ALL traps are
-disabled as part of the "flush all register windows" operation.]
-
-Non-maskable interrupts (NMI) cannot be disabled, and
-ISRs which execute at this level MUST NEVER issue RTEMS system
-calls. If a directive is invoked, unpredictable results may
-occur due to the inability of RTEMS to protect its critical
-sections. However, ISRs that make no system calls may safely
-execute as non-maskable interrupts.
-
-@section Interrupt Stack
-
-The SPARC architecture does not provide for a
-dedicated interrupt stack. Thus by default, trap handlers would
-execute on the stack of the RTEMS task which they interrupted.
-This artificially inflates the stack requirements for each task
-since EVERY task stack would have to include enough space to
-account for the worst case interrupt stack requirements in
-addition to it's own worst case usage. RTEMS addresses this
-problem on the SPARC by providing a dedicated interrupt stack
-managed by software.
-
-During system initialization, RTEMS allocates the
-interrupt stack from the Workspace Area. The amount of memory
-allocated for the interrupt stack is determined by the
-interrupt_stack_size field in the CPU Configuration Table. As
-part of processing a non-nested interrupt, RTEMS will switch to
-the interrupt stack before invoking the installed handler.
-
diff --git a/doc/supplements/sparc/memmodel.t b/doc/supplements/sparc/memmodel.t
deleted file mode 100644
index 7bf814ffa8..0000000000
--- a/doc/supplements/sparc/memmodel.t
+++ /dev/null
@@ -1,104 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@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 Flat Memory Model
-
-The SPARC architecture 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, half-word (2-bytes), word (4 bytes), or doubleword
-(8 bytes). Memory accesses within this address space are
-performed in big endian fashion by the SPARC. Memory accesses
-which are not properly aligned generate a "memory address not
-aligned" trap (type number 7). The following table lists the
-alignment requirements for a variety of data accesses:
-
-@ifset use-ascii
-@example
-@group
- +--------------+-----------------------+
- | Data Type | Alignment Requirement |
- +--------------+-----------------------+
- | byte | 1 |
- | half-word | 2 |
- | word | 4 |
- | doubleword | 8 |
- +--------------+-----------------------+
-@end group
-@end example
-@end ifset
-
-@ifset use-tex
-@sp 1
-@tex
-\centerline{\vbox{\offinterlineskip\halign{
-\vrule\strut#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#&
-\hbox to 1.75in{\enskip\hfil#\hfil}&
-\vrule#\cr
-\noalign{\hrule}
-&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule}
-&byte&&1&\cr\noalign{\hrule}
-&half-word&&2&\cr\noalign{\hrule}
-&word&&4&\cr\noalign{\hrule}
-&doubleword&&8&\cr\noalign{\hrule}
-}}\hfil}
-@end tex
-@end ifset
-
-@ifset use-html
-@html
-<CENTER>
- <TABLE COLS=2 WIDTH="60%" BORDER=2>
-<TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD>
- <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR>
-<TR><TD ALIGN=center>byte</TD>
- <TD ALIGN=center>1</TD></TR>
-<TR><TD ALIGN=center>half-word</TD>
- <TD ALIGN=center>2</TD></TR>
-<TR><TD ALIGN=center>word</TD>
- <TD ALIGN=center>4</TD></TR>
-<TR><TD ALIGN=center>doubleword</TD>
- <TD ALIGN=center>8</TD></TR>
- </TABLE>
-</CENTER>
-@end html
-@end ifset
-
-Doubleword load and store operations must use a pair
-of registers as their source or destination. This pair of
-registers must be an adjacent pair of registers with the first
-of the pair being even numbered. For example, a valid
-destination for a doubleword load might be input registers 0 and
-1 (i0 and i1). The pair i1 and i2 would be invalid. [NOTE:
-Some assemblers for the SPARC do not generate an error if an odd
-numbered register is specified as the beginning register of the
-pair. In this case, the assembler assumes that what the
-programmer meant was to use the even-odd pair which ends at the
-specified register. This may or may not have been a correct
-assumption.]
-
-RTEMS does not support any SPARC Memory Management
-Units, therefore, virtual memory or segmentation systems
-involving the SPARC are not supported.
-
diff --git a/doc/supplements/sparc/preface.texi b/doc/supplements/sparc/preface.texi
deleted file mode 100644
index c3415236cf..0000000000
--- a/doc/supplements/sparc/preface.texi
+++ /dev/null
@@ -1,91 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Preface, CPU Model Dependent Features, Top, Top
-@end ifinfo
-@unnumbered Preface
-
-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 SPARC architecture
-dependencies in this port of RTEMS. Currently, only
-implementations of SPARC Version 7 are supported by RTEMS.
-
-It is highly recommended that the SPARC RTEMS
-application developer obtain and become familiar with the
-documentation for the processor being used as well as the
-specification for the revision of the SPARC architecture which
-corresponds to that processor.
-
-@subheading SPARC Architecture Documents
-
-For information on the SPARC architecture, refer to
-the following documents available from SPARC International, Inc.
-(http://www.sparc.com):
-
-@itemize @bullet
-@item SPARC Standard Version 7.
-
-@item SPARC Standard Version 8.
-
-@item SPARC Standard Version 9.
-@end itemize
-
-@subheading ERC32 Specific Information
-
-The European Space Agency's ERC32 is a three chip
-computing core implementing a SPARC V7 processor and associated
-support circuitry for embedded space applications. The integer
-and floating-point units (90C601E & 90C602E) are based on the
-Cypress 7C601 and 7C602, with additional error-detection and
-recovery functions. The memory controller (MEC) implements
-system support functions such as address decoding, memory
-interface, DMA interface, UARTs, timers, interrupt control,
-write-protection, memory reconfiguration and error-detection.
-The core is designed to work at 25MHz, but using space qualified
-memories limits the system frequency to around 15 MHz, resulting
-in a performance of 10 MIPS and 2 MFLOPS.
-
-Information on the ERC32 and a number of development
-support tools, such as the SPARC Instruction Simulator (SIS),
-are freely available on the Internet. The following documents
-and SIS are available via anonymous ftp or pointing your web
-browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32.
-
-@itemize @bullet
-@item ERC32 System Design Document
-
-@item MEC Device Specification
-@end itemize
-
-Additionally, the SPARC RISC User's Guide from Matra
-MHS documents the functionality of the integer and floating
-point units including the instruction set information. To
-obtain this document as well as ERC32 components and VHDL models
-contact:
-
-@example
-Matra MHS SA
-3 Avenue du Centre, BP 309,
-78054 St-Quentin-en-Yvelines,
-Cedex, France
-VOICE: +31-1-30607087
-FAX: +31-1-30640693
-@end example
-
-Amar Guennon (amar.guennon@@matramhs.fr) is familiar with the ERC32.
-
diff --git a/doc/supplements/sparc/sparc.texi b/doc/supplements/sparc/sparc.texi
deleted file mode 100644
index 2ed4c3ab1c..0000000000
--- a/doc/supplements/sparc/sparc.texi
+++ /dev/null
@@ -1,113 +0,0 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename sparc.info
-@setcontentsaftertitlepage
-@syncodeindex vr fn
-@synindex ky cp
-@paragraphindent 0
-@c %**end of header
-
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@c
-@c Master file for the SPARC Applications Supplement
-@c
-
-@include version.texi
-@include common/setup.texi
-@include common/rtems.texi
-
-@ifset use-ascii
-@dircategory RTEMS Target Supplements
-@direntry
-* RTEMS SPARC Applications Supplement: (sparc).
-@end direntry
-@end ifset
-
-@c
-@c Title Page Stuff
-@c
-
-@c
-@c I don't really like having a short title page. --joel
-@c
-@c @shorttitlepage RTEMS SPARC Applications Supplement
-
-@setchapternewpage odd
-@settitle RTEMS SPARC Applications Supplement
-@titlepage
-@finalout
-
-@title RTEMS SPARC Applications Supplement
-@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION}
-@sp 1
-@subtitle @value{UPDATED}
-@author On-Line Applications Research Corporation
-@page
-@include common/cpright.texi
-@end titlepage
-
-@c This prevents a black box from being printed on "overflow" lines.
-@c The alternative is to rework a sentence to avoid this problem.
-
-@include preface.texi
-@include cpumodel.texi
-@include callconv.texi
-@include memmodel.texi
-@include intr.texi
-@include fatalerr.texi
-@include bsp.texi
-@include cputable.texi
-@include wksheets.texi
-@include timing.texi
-@include timeERC32.texi
-@ifinfo
-@node Top, Preface, (dir), (dir)
-@top sparc
-
-This is the online version of the RTEMS SPARC Applications Supplement.
-
-@menu
-* Preface::
-* CPU Model Dependent Features::
-* Calling Conventions::
-* Memory Model::
-* Interrupt Processing::
-* Default Fatal Error Processing::
-* Board Support Packages::
-* Processor Dependent Information Table::
-* Memory Requirements::
-* Timing Specification::
-* ERC32 Timing Data::
-* Command and Variable Index::
-* Concept Index::
-@end menu
-
-@end ifinfo
-@c
-@c
-@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
-@c
-
-@node Command and Variable Index, Concept Index, ERC32 Timing Data Rate Monotonic Manager, Top
-@unnumbered Command and Variable Index
-
-There are currently no Command and Variable Index entries.
-
-@c @printindex fn
-
-@node Concept Index, , Command and Variable Index, Top
-@unnumbered Concept Index
-
-There are currently no Concept Index entries.
-@c @printindex cp
-
-@contents
-@bye
-
diff --git a/doc/supplements/sparc/timeERC32.t b/doc/supplements/sparc/timeERC32.t
deleted file mode 100644
index acece2b675..0000000000
--- a/doc/supplements/sparc/timeERC32.t
+++ /dev/null
@@ -1,120 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@include common/timemac.texi
-@tex
-\global\advance \smallskipamount by -4pt
-@end tex
-
-@chapter ERC32 Timing Data
-
-@section Introduction
-
-The timing data for RTEMS on the ERC32 implementation
-of the SPARC architecture is provided along with the target
-dependent aspects concerning the gathering of the timing data.
-The hardware platform used to gather the times is described to
-give the reader a better understanding of each directive time
-provided. Also, provided is a description of the interrupt
-latency and the context switch times as they pertain to the
-SPARC version of RTEMS.
-
-@section Hardware Platform
-
-All times reported in this chapter were measured
-using the SPARC Instruction Simulator (SIS) developed by the
-European Space Agency. SIS simulates the ERC32 -- a custom low
-power implementation combining the Cypress 90C601 integer unit,
-the Cypress 90C602 floating point unit, and a number of
-peripherals such as counter timers, interrupt controller and a
-memory controller.
-
-For the RTEMS tests, SIS is configured with the
-following characteristics:
-
-@itemize @bullet
-@item 15 Mhz clock speed
-
-@item 0 wait states for PROM accesses
-
-@item 0 wait states for RAM accesses
-@end itemize
-
-The ERC32's General Purpose Timer was used to gather
-all timing information. This timer was programmed to operate
-with one microsecond accuracy. All sources of hardware
-interrupts were disabled, although traps were enabled and the
-interrupt level of the SPARC allows all interrupts.
-
-@section Interrupt Latency
-
-The maximum period with traps disabled or the
-processor interrupt level set to it's highest value inside RTEMS
-is less than RTEMS_MAXIMUM_DISABLE_PERIOD
-microseconds including the instructions which
-disable and re-enable interrupts. The time required for the
-ERC32 to vector an interrupt and for the RTEMS entry overhead
-before invoking the user's trap handler are a total of
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds. These combine to yield a worst case interrupt
-latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD +
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz.
-[NOTE: The maximum period with interrupts disabled was last
-determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-The maximum period with interrupts disabled within
-RTEMS is hand-timed with some assistance from SIS. The maximum
-period with interrupts disabled with RTEMS occurs during a
-context switch when traps are disabled to flush all the register
-windows to memory. The length of time spent flushing the
-register windows varies based on the number of windows which
-must be flushed. Based on the information reported by SIS, it
-takes from 4.0 to 18.0 microseconds (37 to 122 instructions) to
-flush the register windows. It takes approximately 41 CPU
-cycles (2.73 microseconds) to flush each register window set to
-memory. The register window flush operation is heavily memory
-bound.
-
-[NOTE: All traps are disabled during the register
-window flush thus disabling both software generate traps and
-external interrupts. During a normal RTEMS critical section,
-the processor interrupt level (pil) is raised to level 15 and
-traps are left enabled. The longest path for a normal critical
-section within RTEMS is less than 50 instructions.]
-
-The interrupt vector and entry overhead time was
-generated on the SIS benchmark platform using the ERC32's
-ability to forcibly generate an arbitrary interrupt as the
-source of the "benchmark" interrupt.
-
-@section Context Switch
-
-The RTEMS processor context switch time is 10
-microseconds on the SIS benchmark platform when no floating
-point context is saved or restored. Additional execution time
-is required when a TASK_SWITCH user extension is configured.
-The use of the TASK_SWITCH extension is application dependent.
-Thus, its execution time is not considered part of the raw
-context switch time.
-
-Since RTEMS was designed specifically for embedded
-missile applications which are floating point intensive, the
-executive is optimized to avoid unnecessarily saving and
-restoring the state of the numeric coprocessor. The state of
-the numeric coprocessor is only saved when an FLOATING_POINT
-task is dispatched and that task was not the last task to
-utilize the coprocessor. In a system with only one
-FLOATING_POINT task, the state of the numeric coprocessor will
-never be saved or restored. When the first FLOATING_POINT task
-is dispatched, RTEMS does not need to save the current state of
-the numeric coprocessor.
-
-The following table summarizes the context switch
-times for the ERC32 benchmark platform:
-
diff --git a/doc/supplements/supplement.am b/doc/supplements/supplement.am
deleted file mode 100644
index 62542391d1..0000000000
--- a/doc/supplements/supplement.am
+++ /dev/null
@@ -1,16 +0,0 @@
-## $Id$
-
-##
-## Makefile fragment common to all supplements/<cpu>/Makefile.ams
-##
-
-REPLACE2 = $(PERL) $(top_srcdir)/tools/word-replace2
-
-html_projectdir = $(htmldir)/supplements/$(PROJECT)
-
-TEXI2WWW_ARGS=\
--I $(srcdir) -I $(top_srcdir) -I $(top_builddir) \
--dirfile ../../index.html \
--header rtems_header.html \
--footer rtems_footer.html \
--icons ../../images
diff --git a/doc/supplements/template/.cvsignore b/doc/supplements/template/.cvsignore
deleted file mode 100644
index 8407ae75d6..0000000000
--- a/doc/supplements/template/.cvsignore
+++ /dev/null
@@ -1,31 +0,0 @@
-index.html
-intr.t
-intr.texi
-Makefile
-Makefile.in
-mdate-sh
-rtems_footer.html
-rtems_header.html
-stamp-vti
-template
-template-?
-template-??
-template.aux
-template.cp
-template.dvi
-template.fn
-template*.html
-template.ky
-template.log
-template.pdf
-template.pg
-template.ps
-template.toc
-template.tp
-template.vr
-timeBSP_.t
-timing.t
-timing.texi
-version.texi
-wksheets.t
-wksheets.texi
diff --git a/doc/supplements/template/BSP_TIMES b/doc/supplements/template/BSP_TIMES
deleted file mode 100644
index 10a86f288f..0000000000
--- a/doc/supplements/template/BSP_TIMES
+++ /dev/null
@@ -1,247 +0,0 @@
-#
-# CPU MODEL/BSP Timing and Size Information
-#
-# $Id$
-#
-
-#
-# CPU Model Information
-#
-RTEMS_BSP MYBSP
-RTEMS_CPU_MODEL MYCPU
-#
-# Interrupt Latency
-#
-# NOTE: In general, the text says it is hand-calculated to be
-# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-# Mhz and this was last calculated for Release
-# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
-#
-RTEMS_MAXIMUM_DISABLE_PERIOD TBD
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0
-#
-# Context Switch Times
-#
-RTEMS_NO_FP_CONTEXTS 35
-RTEMS_RESTORE_1ST_FP_TASK 39
-RTEMS_SAVE_INIT_RESTORE_INIT 66
-RTEMS_SAVE_IDLE_RESTORE_INIT 66
-RTEMS_SAVE_IDLE_RESTORE_IDLE 68
-#
-# Task Manager Times
-#
-RTEMS_TASK_CREATE_ONLY 148
-RTEMS_TASK_IDENT_ONLY 350
-RTEMS_TASK_START_ONLY 76
-RTEMS_TASK_RESTART_CALLING_TASK 95
-RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89
-RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124
-RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92
-RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125
-RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149
-RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142
-RTEMS_TASK_DELETE_CALLING_TASK 170
-RTEMS_TASK_DELETE_SUSPENDED_TASK 138
-RTEMS_TASK_DELETE_BLOCKED_TASK 143
-RTEMS_TASK_DELETE_READY_TASK 144
-RTEMS_TASK_SUSPEND_CALLING_TASK 71
-RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43
-RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45
-RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67
-RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31
-RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64
-RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106
-RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14
-RTEMS_TASK_MODE_NO_RESCHEDULE 16
-RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23
-RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60
-RTEMS_TASK_GET_NOTE_ONLY 33
-RTEMS_TASK_SET_NOTE_ONLY 33
-RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16
-RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56
-RTEMS_TASK_WAKE_WHEN_ONLY 117
-#
-# Interrupt Manager
-#
-RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12
-RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9
-RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1
-RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8
-RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54
-#
-# Clock Manager
-#
-RTEMS_CLOCK_SET_ONLY 86
-RTEMS_CLOCK_GET_ONLY 1
-RTEMS_CLOCK_TICK_ONLY 17
-#
-# Timer Manager
-#
-RTEMS_TIMER_CREATE_ONLY 28
-RTEMS_TIMER_IDENT_ONLY 343
-RTEMS_TIMER_DELETE_INACTIVE 43
-RTEMS_TIMER_DELETE_ACTIVE 47
-RTEMS_TIMER_FIRE_AFTER_INACTIVE 58
-RTEMS_TIMER_FIRE_AFTER_ACTIVE 61
-RTEMS_TIMER_FIRE_WHEN_INACTIVE 88
-RTEMS_TIMER_FIRE_WHEN_ACTIVE 88
-RTEMS_TIMER_RESET_INACTIVE 54
-RTEMS_TIMER_RESET_ACTIVE 58
-RTEMS_TIMER_CANCEL_INACTIVE 31
-RTEMS_TIMER_CANCEL_ACTIVE 34
-#
-# Semaphore Manager
-#
-RTEMS_SEMAPHORE_CREATE_ONLY 60
-RTEMS_SEMAPHORE_IDENT_ONLY 367
-RTEMS_SEMAPHORE_DELETE_ONLY 58
-RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109
-RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87
-#
-# Message Manager
-#
-RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200
-RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341
-RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80
-RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123
-RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123
-RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133
-RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114
-RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29
-RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39
-#
-# Event Manager
-#
-RTEMS_EVENT_SEND_NO_TASK_READIED 24
-RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60
-RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84
-RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1
-RTEMS_EVENT_RECEIVE_AVAILABLE 28
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84
-#
-# Signal Manager
-#
-RTEMS_SIGNAL_CATCH_ONLY 15
-RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37
-RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54
-#
-# Partition Manager
-#
-RTEMS_PARTITION_CREATE_ONLY 70
-RTEMS_PARTITION_IDENT_ONLY 341
-RTEMS_PARTITION_DELETE_ONLY 42
-RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35
-RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33
-RTEMS_PARTITION_RETURN_BUFFER_ONLY 43
-#
-# Region Manager
-#
-RTEMS_REGION_CREATE_ONLY 63
-RTEMS_REGION_IDENT_ONLY 348
-RTEMS_REGION_DELETE_ONLY 39
-RTEMS_REGION_GET_SEGMENT_AVAILABLE 52
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123
-RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136
-#
-# Dual-Ported Memory Manager
-#
-RTEMS_PORT_CREATE_ONLY 35
-RTEMS_PORT_IDENT_ONLY 340
-RTEMS_PORT_DELETE_ONLY 39
-RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26
-RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27
-#
-# IO Manager
-#
-RTEMS_IO_INITIALIZE_ONLY 4
-RTEMS_IO_OPEN_ONLY 2
-RTEMS_IO_CLOSE_ONLY 1
-RTEMS_IO_READ_ONLY 2
-RTEMS_IO_WRITE_ONLY 3
-RTEMS_IO_CONTROL_ONLY 2
-#
-# Rate Monotonic Manager
-#
-RTEMS_RATE_MONOTONIC_CREATE_ONLY 32
-RTEMS_RATE_MONOTONIC_IDENT_ONLY 341
-RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39
-RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51
-RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48
-RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54
-RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74
-RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31
-#
-# Size Information
-#
-#
-# xxx alloted for numbers
-#
-RTEMS_DATA_SPACE 723
-RTEMS_MINIMUM_CONFIGURATION 18,980
-RTEMS_MAXIMUM_CONFIGURATION 36,438
-# x,xxx alloted for numbers
-RTEMS_CORE_CODE_SIZE 12,674
-RTEMS_INITIALIZATION_CODE_SIZE 970
-RTEMS_TASK_CODE_SIZE 3,562
-RTEMS_INTERRUPT_CODE_SIZE 54
-RTEMS_CLOCK_CODE_SIZE 334
-RTEMS_TIMER_CODE_SIZE 1,110
-RTEMS_SEMAPHORE_CODE_SIZE 1,632
-RTEMS_MESSAGE_CODE_SIZE 1,754
-RTEMS_EVENT_CODE_SIZE 1,000
-RTEMS_SIGNAL_CODE_SIZE 418
-RTEMS_PARTITION_CODE_SIZE 1,164
-RTEMS_REGION_CODE_SIZE 1,494
-RTEMS_DPMEM_CODE_SIZE 724
-RTEMS_IO_CODE_SIZE 686
-RTEMS_FATAL_ERROR_CODE_SIZE 24
-RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212
-RTEMS_MULTIPROCESSING_CODE_SIZE 6.952
-# xxx alloted for numbers
-RTEMS_TIMER_CODE_OPTSIZE 184
-RTEMS_SEMAPHORE_CODE_OPTSIZE 172
-RTEMS_MESSAGE_CODE_OPTSIZE 288
-RTEMS_EVENT_CODE_OPTSIZE 56
-RTEMS_SIGNAL_CODE_OPTSIZE 56
-RTEMS_PARTITION_CODE_OPTSIZE 132
-RTEMS_REGION_CODE_OPTSIZE 160
-RTEMS_DPMEM_CODE_OPTSIZE 132
-RTEMS_IO_CODE_OPTSIZE 00
-RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184
-RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332
-# xxx alloted for numbers
-RTEMS_BYTES_PER_TASK 400
-RTEMS_BYTES_PER_TIMER 68
-RTEMS_BYTES_PER_SEMAPHORE 124
-RTEMS_BYTES_PER_MESSAGE_QUEUE 148
-RTEMS_BYTES_PER_REGION 144
-RTEMS_BYTES_PER_PARTITION 56
-RTEMS_BYTES_PER_PORT 36
-RTEMS_BYTES_PER_PERIOD 36
-RTEMS_BYTES_PER_EXTENSION 64
-RTEMS_BYTES_PER_FP_TASK 332
-RTEMS_BYTES_PER_NODE 48
-RTEMS_BYTES_PER_GLOBAL_OBJECT 20
-RTEMS_BYTES_PER_PROXY 124
-# x,xxx alloted for numbers
-RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872
diff --git a/doc/supplements/template/ChangeLog b/doc/supplements/template/ChangeLog
deleted file mode 100644
index 7df694a6cc..0000000000
--- a/doc/supplements/template/ChangeLog
+++ /dev/null
@@ -1,76 +0,0 @@
-2003-12-12 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-12-11 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Cosmetics.
-
-2003-11-26 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Add *.info to CLEANFILES to accomodate
- automake-1.7f/1.8 breaking building infos.
-
-2003-09-26 Joel Sherrill <joel@OARcorp.com>
-
- * cpumodel.t: Obsoleting HP PA-RISC port and removing all references.
-
-2003-09-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Merger from rtems-4-6-branch.
-
-2003-09-19 Joel Sherrill <joel@OARcorp.com>
-
- * template.texi: Merge from branch.
-
-2003-05-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * cpumodel.t: Reflect c/src/exec having moved to cpukit.
-
-2003-01-25 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * template.texi: Set @setfilename template.info.
-
-2003-01-24 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Put GENERATED_FILES into $builddir.
-
-2003-01-22 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * version.texi: Remove from CVS.
- * stamp-vti: Remove from CVS.
- * .cvsignore: Add version.texi.
- Add stamp-vti.
- Re-sort.
-
-2003-01-21 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-11-13 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-10-24 Joel Sherrill <joel@OARcorp.com>
-
- * stamp-vti, version.texi: Regenerated.
-
-2002-07-30 Joel Sherrill <joel@OARcorp.com>
-
- * intr_NOTIMES.t, timeBSP.t: Replaced XXX's with real info.
-
-2002-03-27 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Remove AUTOMAKE_OPTIONS.
-
-2002-01-18 Ralf Corsepius <corsepiu@faw.uni-ulm.de>
-
- * Makefile.am: Require automake-1.5.
-
-2001-01-17 Joel Sherrill <joel@OARcorp.com>
-
- * .cvsignore: Added rtems_header.html and rtems_footer.html.
-
-2000-08-10 Joel Sherrill <joel@OARcorp.com>
-
- * ChangeLog: New file.
diff --git a/doc/supplements/template/Makefile.am b/doc/supplements/template/Makefile.am
deleted file mode 100644
index 27ecc24457..0000000000
--- a/doc/supplements/template/Makefile.am
+++ /dev/null
@@ -1,110 +0,0 @@
-#
-# COPYRIGHT (c) 1988-2002.
-# On-Line Applications Research Corporation (OAR).
-# All rights reserved.
-#
-# $Id$
-#
-
-PROJECT = template
-EDITION = 1
-
-include $(top_srcdir)/project.am
-include $(top_srcdir)/supplements/supplement.am
-
-GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \
- fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \
- timeBSP.texi
-COMMON_FILES += $(top_srcdir)/common/cpright.texi \
- $(top_srcdir)/common/timemac.texi
-
-FILES = preface.texi
-
-info_TEXINFOS = template.texi
-template_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
-
-#
-# Chapters which get automatic processing
-#
-
-cpumodel.texi: cpumodel.t
- $(BMENU2) -p "Preface" \
- -u "Top" \
- -n "Calling Conventions" < $< > $@
-
-callconv.texi: callconv.t
- $(BMENU2) -p "CPU Model Dependent Features Another Optional Feature" \
- -u "Top" \
- -n "Memory Model" < $< > $@
-
-memmodel.texi: memmodel.t
- $(BMENU2) -p "Calling Conventions User-Provided Routines" \
- -u "Top" \
- -n "Interrupt Processing" < $< > $@
-
-# Interrupt Chapter:
-# 1. Replace Times and Sizes
-# 2. Build Node Structure
-intr.texi: intr_NOTIMES.t BSP_TIMES
- ${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \
- $(BMENU2) -p "Memory Model Flat Memory Model" \
- -u "Top" \
- -n "Default Fatal Error Processing" > $@
-
-fatalerr.texi: fatalerr.t
- $(BMENU2) -p "Interrupt Processing Interrupt Stack" \
- -u "Top" \
- -n "Board Support Packages" < $< > $@
-
-bsp.texi: bsp.t
- $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
- -u "Top" \
- -n "Processor Dependent Information Table" < $< > $@
-
-cputable.texi: cputable.t
- $(BMENU2) -p "Board Support Packages Processor Initialization" \
- -u "Top" \
- -n "Memory Requirements" < $< > $@
-
-# Worksheets Chapter:
-# 1. Obtain the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES
- ${REPLACE2} -p $(srcdir)/BSP_TIMES \
- $(top_srcdir)/common/wksheets.t | \
- $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \
- -u "Top" \
- -n "Timing Specification" > $@
-
-# Timing Specification Chapter:
-# 1. Copy the Shared File
-# 3. Build Node Structure
-
-timing.texi: $(top_srcdir)/common/timing.t
- $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \
- -u "Top" \
- -n "MYBSP Timing Data" < $< > $@
-
-# Timing Data for BSP BSP Chapter:
-# 1. Copy the Shared File
-# 2. Replace Times and Sizes
-# 3. Build Node Structure
-
-timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t
- cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t
- @echo >>timeBSP_.t
- @echo "@tex" >>timeBSP_.t
- @echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t
- @echo "@end tex" >>timeBSP_.t
- ${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \
- $(BMENU2) -p "Timing Specification Terminology" \
- -u "Top" \
- -n "Command and Variable Index" > $@
-CLEANFILES += timeBSP_.t
-
-EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \
- intr_NOTIMES.t memmodel.t timeBSP.t
-
-CLEANFILES += template.info template.info-?
diff --git a/doc/supplements/template/bsp.t b/doc/supplements/template/bsp.t
deleted file mode 100644
index 657c359a96..0000000000
--- a/doc/supplements/template/bsp.t
+++ /dev/null
@@ -1,93 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Board Support Packages
-
-@section Introduction
-
-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.
-
-@section 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:
-
-@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 The processor begins execution at the address stored in
-the PC.
-@end itemize
-
-@section 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.
-
diff --git a/doc/supplements/template/callconv.t b/doc/supplements/template/callconv.t
deleted file mode 100644
index 5387032c60..0000000000
--- a/doc/supplements/template/callconv.t
+++ /dev/null
@@ -1,92 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Calling Conventions
-
-@section Introduction
-
-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.
-
-@section 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.
-
-@section 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.
-
-@section 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.
-
-@section 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.
-
-@section 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.
-
diff --git a/doc/supplements/template/cpumodel.t b/doc/supplements/template/cpumodel.t
deleted file mode 100644
index c366970ae1..0000000000
--- a/doc/supplements/template/cpumodel.t
+++ /dev/null
@@ -1,68 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter CPU Model Dependent Features
-
-@section Introduction
-
-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.
-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.
-
-@section 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".
-
-@section 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.
-
-@section Another Optional Feature
-
-The macro XXX
diff --git a/doc/supplements/template/cputable.t b/doc/supplements/template/cputable.t
deleted file mode 100644
index 75d0fc15f6..0000000000
--- a/doc/supplements/template/cputable.t
+++ /dev/null
@@ -1,109 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Processor Dependent Information Table
-
-@section Introduction
-
-Any highly processor dependent information required
-to describe a processor to RTEMS is provided in the CPU
-Dependent Information Table. This table is not required for all
-processors supported by RTEMS. This chapter describes the
-contents, if any, for a particular processor type.
-
-@section CPU Dependent Information Table
-
-The XXX version of the RTEMS CPU Dependent
-Information Table contains the information required to interface
-a Board Support Package and RTEMS on the XXX. This
-information is provided to allow RTEMS to interoperate
-effectively with the BSP. The C structure definition is given
-here:
-
-@example
-@group
-typedef struct @{
- void (*pretasking_hook)( void );
- void (*predriver_hook)( void );
- void (*postdriver_hook)( void );
- void (*idle_task)( void );
- boolean do_zero_of_workspace;
- unsigned32 idle_task_stack_size;
- unsigned32 interrupt_stack_size;
- unsigned32 extra_mpci_receive_server_stack;
- void * (*stack_allocate_hook)( unsigned32 );
- void (*stack_free_hook)( void* );
- /* end of fields required on all CPUs */
-
- /* XXX CPU family dependent stuff */
-@} rtems_cpu_table;
-@end group
-@end example
-
-@table @code
-@item pretasking_hook
-is the address of the user provided routine which is invoked
-once RTEMS APIs are initialized. This routine will be invoked
-before any system tasks are created. Interrupts are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item predriver_hook
-is the address of the user provided
-routine that is invoked immediately before the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item postdriver_hook
-is the address of the user provided
-routine that is invoked immediately after the
-the device drivers and MPCI are initialized. RTEMS
-initialization is complete but interrupts and tasking are disabled.
-This field may be NULL to indicate that the hook is not utilized.
-
-@item idle_task
-is the address of the optional user
-provided routine which is used as the system's IDLE task. If
-this field is not NULL, then the RTEMS default IDLE task is not
-used. This field may be NULL to indicate that the default IDLE
-is to be used.
-
-@item do_zero_of_workspace
-indicates whether RTEMS should
-zero the Workspace as part of its initialization. If set to
-TRUE, the Workspace is zeroed. Otherwise, it is not.
-
-@item idle_task_stack_size
-is the size of the RTEMS idle task stack in bytes.
-If this number is less than MINIMUM_STACK_SIZE, then the
-idle task's stack will be MINIMUM_STACK_SIZE in byte.
-
-@item interrupt_stack_size
-is the size of the RTEMS
-allocated interrupt stack in bytes. This value must be at least
-as large as MINIMUM_STACK_SIZE.
-
-@item extra_mpci_receive_server_stack
-is the extra stack space allocated for the RTEMS MPCI receive server task
-in bytes. The MPCI receive server may invoke nearly all directives and
-may require extra stack space on some targets.
-
-@item stack_allocate_hook
-is the address of the optional user provided routine which allocates
-memory for task stacks. If this hook is not NULL, then a stack_free_hook
-must be provided as well.
-
-@item stack_free_hook
-is the address of the optional user provided routine which frees
-memory for task stacks. If this hook is not NULL, then a stack_allocate_hook
-must be provided as well.
-
-@item XXX
-is where the CPU family dependent stuff goes.
-
-@end table
diff --git a/doc/supplements/template/fatalerr.t b/doc/supplements/template/fatalerr.t
deleted file mode 100644
index 53efad0435..0000000000
--- a/doc/supplements/template/fatalerr.t
+++ /dev/null
@@ -1,31 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@chapter Default Fatal Error Processing
-
-@section Introduction
-
-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.
-
-@section 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.
-
diff --git a/doc/supplements/template/intr_NOTIMES.t b/doc/supplements/template/intr_NOTIMES.t
deleted file mode 100644
index 13e4921ea9..0000000000
--- a/doc/supplements/template/intr_NOTIMES.t
+++ /dev/null
@@ -1,196 +0,0 @@
-@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
-
-@chapter Interrupt Processing
-
-@section Introduction
-
-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 processor's
-interrupt response and control mechanisms as they pertain to
-RTEMS.
-
-@section 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.
-
-@subsection 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
-
-@subsection 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 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
-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
-
-@section 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.
-
-@section 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.
-
-@section 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.
-
-
diff --git a/doc/supplements/template/memmodel.t b/doc/supplements/template/memmodel.t
deleted file mode 100644
index ef35072230..0000000000
--- a/doc/supplements/template/memmodel.t
+++ /dev/null
@@ -1,39 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@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 Flat Memory Model
-
-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.
-
-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.
-
diff --git a/doc/supplements/template/preface.texi b/doc/supplements/template/preface.texi
deleted file mode 100644
index 686a17b48d..0000000000
--- a/doc/supplements/template/preface.texi
+++ /dev/null
@@ -1,55 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Preface, CPU Model Dependent Features, Top, Top
-@end ifinfo
-@unnumbered Preface
-
-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.
-
-@subheading Architecture Documents
-
-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
-
diff --git a/doc/supplements/template/template.texi b/doc/supplements/template/template.texi
deleted file mode 100644
index a2b655fd63..0000000000
--- a/doc/supplements/template/template.texi
+++ /dev/null
@@ -1,115 +0,0 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename template.info
-@setcontentsaftertitlepage
-@syncodeindex vr fn
-@synindex ky cp
-@paragraphindent 0
-@c %**end of header
-
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@c
-@c Master file for the Template Applications Supplement
-@c
-
-@include version.texi
-@include common/setup.texi
-@include common/rtems.texi
-
-@ifset use-ascii
-@dircategory RTEMS Target Supplements
-@direntry
-* RTEMS Template Applications Supplement: (template).
-@end direntry
-@end ifset
-
-@c
-@c Title Page Stuff
-@c
-
-@c
-@c I don't really like having a short title page. --joel
-@c
-@c @shorttitlepage RTEMS Template Applications Supplement
-
-@setchapternewpage odd
-@settitle RTEMS Template Applications Supplement
-@titlepage
-@finalout
-
-@title RTEMS Template Applications Supplement
-@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION}
-@sp 1
-@subtitle @value{UPDATED}
-@author On-Line Applications Research Corporation
-@page
-
-@include common/cpright.texi
-@end titlepage
-
-@c This prevents a black box from being printed on "overflow" lines.
-@c The alternative is to rework a sentence to avoid this problem.
-
-@include preface.texi
-@include cpumodel.texi
-@include callconv.texi
-@include memmodel.texi
-@include intr.texi
-@include fatalerr.texi
-@include bsp.texi
-@include cputable.texi
-@include wksheets.texi
-@include timing.texi
-@include timeBSP.texi
-@ifinfo
-@node Top, Preface, (dir), (dir)
-@top template
-
-This is the online version of the RTEMS Template
-Applications Supplement.
-
-@menu
-* Preface::
-* CPU Model Dependent Features::
-* Calling Conventions::
-* Memory Model::
-* Interrupt Processing::
-* Default Fatal Error Processing::
-* Board Support Packages::
-* Processor Dependent Information Table::
-* Memory Requirements::
-* Timing Specification::
-* MYBSP Timing Data::
-* Command and Variable Index::
-* Concept Index::
-@end menu
-
-@end ifinfo
-@c
-@c
-@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
-@c
-
-@node Command and Variable Index, Concept Index, MYBSP Timing Data Rate Monotonic Manager, Top
-@unnumbered Command and Variable Index
-
-There are currently no Command and Variable Index entries.
-
-@c @printindex fn
-
-@node Concept Index, , Command and Variable Index, Top
-@unnumbered Concept Index
-
-There are currently no Concept Index entries.
-@c @printindex cp
-
-@contents
-@bye
-
diff --git a/doc/supplements/template/timeBSP.t b/doc/supplements/template/timeBSP.t
deleted file mode 100644
index 85e5ea44aa..0000000000
--- a/doc/supplements/template/timeBSP.t
+++ /dev/null
@@ -1,112 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-2002.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@include common/timemac.texi
-@tex
-\global\advance \smallskipamount by -4pt
-@end tex
-
-@chapter MYBSP Timing Data
-
-@section Introduction
-
-The timing data for the XXX version of RTEMS is
-provided along with the target dependent aspects concerning the
-gathering of the timing data. The hardware platform used to
-gather the times is described to give the reader a better
-understanding of each directive time provided. Also, provided
-is a description of the interrupt latency and the context switch
-times as they pertain to the XXX version of RTEMS.
-
-@section Hardware Platform
-
-All times reported except for the maximum period
-interrupts are disabled by RTEMS were measured using a Motorola
-MYBSP CPU board. The MYBSP is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz board with one wait
-state dynamic memory and a XXX numeric coprocessor. The
-Zilog 8036 countdown timer on this board was used to measure
-elapsed time with a one-half microsecond resolution. All
-sources of hardware interrupts were disabled, although the
-interrupt level of the processor allows all interrupts.
-
-The maximum period interrupts are disabled was
-measured by summing the number of CPU cycles required by each
-assembly language instruction executed while interrupts were
-disabled. The worst case times of the XXX microprocessor
-were used for each instruction. Zero wait state memory was
-assumed. The total CPU cycles executed with interrupts
-disabled, including the instructions to disable and enable
-interrupts, was divided by 20 to simulate a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz processor. It
-should be noted that the worst case instruction times for the
-processor assume that the internal cache is disabled and that no
-instructions overlap.
-
-@section Interrupt Latency
-
-The maximum period with interrupts disabled within
-RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD
-microseconds including the instructions
-which disable and re-enable interrupts. The time required for
-the processor to vector an interrupt and for the RTEMS entry
-overhead before invoking the user's interrupt handler are a
-total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds. These combine to yield a worst case
-interrupt latency of less than
-RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
-microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz. [NOTE: The maximum period with interrupts
-disabled was last determined for Release
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-It should be noted again that the maximum period with
-interrupts disabled within RTEMS is hand-timed and based upon
-worst case (i.e. CPU cache disabled and no instruction overlap)
-times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-Mhz processor. The interrupt vector and entry
-overhead time was generated on an MYBSP benchmark platform
-using the Multiprocessing Communications registers to generate
-as the interrupt source.
-
-@section Context Switch
-
-The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
-microseconds on the MYBSP benchmark platform when no floating
-point context is saved or restored. Additional execution time
-is required when a TASK_SWITCH user extension is configured.
-The use of the TASK_SWITCH extension is application dependent.
-Thus, its execution time is not considered part of the raw
-context switch time.
-
-Since RTEMS was designed specifically for embedded
-missile applications which are floating point intensive, the
-executive is optimized to avoid unnecessarily saving and
-restoring the state of the numeric coprocessor. The state of
-the numeric coprocessor is only saved when an FLOATING_POINT
-task is dispatched and that task was not the last task to
-utilize the coprocessor. In a system with only one
-FLOATING_POINT task, the state of the numeric coprocessor will
-never be saved or restored. When the first FLOATING_POINT task
-is dispatched, RTEMS does not need to save the current state of
-the numeric coprocessor.
-
-The exact amount of time required to save and restore
-floating point context is dependent on whether an XXX or
-XXX is being used as well as the state of the numeric
-coprocessor. These numeric coprocessors define three operating
-states: initialized, idle, and busy. RTEMS places the
-coprocessor in the initialized state when a task is started or
-restarted. Once the task has utilized the coprocessor, it is in
-the idle state when floating point instructions are not
-executing and the busy state when floating point instructions
-are executing. The state of the coprocessor is task specific.
-
-The following table summarizes the context switch
-times for the MYBSP benchmark platform:
-