summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJoel Sherrill <joel.sherrill@OARcorp.com>1998-10-19 18:25:16 +0000
committerJoel Sherrill <joel.sherrill@OARcorp.com>1998-10-19 18:25:16 +0000
commit8eba4708f068826fd826db22f6bcdff69aae908a (patch)
tree0f8036edcefd19bc582f28e3028b685d0572090c
parent3a5676e7212a9214397e05bfe99efc8326a3cbec (diff)
downloadrtems-8eba4708f068826fd826db22f6bcdff69aae908a.tar.bz2
Nearly everything that can be is now automatically generated.
-rw-r--r--doc/supplements/i386/Makefile117
-rw-r--r--doc/supplements/i386/bsp.t21
-rw-r--r--doc/supplements/i386/bsp.texi128
-rw-r--r--doc/supplements/i386/callconv.t33
-rw-r--r--doc/supplements/i386/callconv.texi121
-rw-r--r--doc/supplements/i386/cpumodel.t24
-rw-r--r--doc/supplements/i386/cpumodel.texi96
-rw-r--r--doc/supplements/i386/cputable.t17
-rw-r--r--doc/supplements/i386/cputable.texi136
-rw-r--r--doc/supplements/i386/fatalerr.t15
-rw-r--r--doc/supplements/i386/fatalerr.texi46
-rw-r--r--doc/supplements/i386/i386.texi2
-rw-r--r--doc/supplements/i386/intr.t199
-rw-r--r--doc/supplements/i386/intr_NOTIMES.t33
-rw-r--r--doc/supplements/i386/memmodel.t15
-rw-r--r--doc/supplements/i386/memmodel.texi87
-rw-r--r--doc/supplements/i386/timeFORCE386.t42
-rw-r--r--doc/supplements/i386/timedata.t143
18 files changed, 92 insertions, 1183 deletions
diff --git a/doc/supplements/i386/Makefile b/doc/supplements/i386/Makefile
index 7af3f7c92a..440f36d8c8 100644
--- a/doc/supplements/i386/Makefile
+++ b/doc/supplements/i386/Makefile
@@ -15,21 +15,23 @@ REPLACE=../../tools/word-replace
all: html info ps
+GENERATED_FILES=\
+ cpumodel.texi callconv.texi memmodel.texi intr.texi fatalerr.texi \
+ bsp.texi cputable.texi timing.texi wksheets.texi timeFORCE386.texi
+
+FILES= $(PROJECT).texi \
+ preface.texi \
+ $(GENERATED_FILES)
+
+
dirs:
$(make-dirs)
COMMON_FILES=../../common/cpright.texi ../../common/setup.texi
-GENERATED_FILES= \
- timing.texi wksheets.texi
-
-FILES= $(PROJECT).texi \
- bsp.texi callconv.texi cpumodel.texi cputable.texi fatalerr.texi \
- intr.texi memmodel.texi preface.texi timetbl.texi timedata.texi \
- $(GENERATED_FILES)
-
info: dirs c_i386
- cp c_$(PROJECT) c_$(PROJECT)-* $(INFO_INSTALL)
+ cp c_$(PROJECT) $(INFO_INSTALL)
+ #cp c_$(PROJECT) c_$(PROJECT)-* $(INFO_INSTALL)
c_i386: $(FILES)
$(MAKEINFO) $(PROJECT).texi
@@ -50,21 +52,55 @@ replace: timedata.texi
# Chapters which get automatic processing
#
-# CPU Model
-# Calling Conventions
-# Memory Model
+cpumodel.texi: cpumodel.t Makefile
+ $(BMENU) -p "Preface" \
+ -u "Top" \
+ -n "Calling Conventions" ${*}.t
+
+callconv.texi: callconv.t Makefile
+ $(BMENU) -p "CPU Model Dependent Features Floating Point Unit" \
+ -u "Top" \
+ -n "Memory Model" ${*}.t
+
+memmodel.texi: memmodel.t Makefile
+ $(BMENU) -p "Calling Conventions User-Provided Routines" \
+ -u "Top" \
+ -n "Interrupt Processing" ${*}.t
# Interrupt Chapter:
# 1. Replace Times and Sizes
# 2. Build Node Structure
-intr.texi: intr.t FORCE386_TIMES
- ${REPLACE} -p FORCE386_TIMES intr.t
- mv intr.t.fixed intr.texi
+#intr.texi: intr.t FORCE386_TIMES
+# ${REPLACE} -p FORCE386_TIMES intr.t
+# mv intr.t.fixed intr.texi
-# Fatal Error
-# BSP
-# CPU Table
+# Interrupt Chapter:
+# 1. Replace Times and Sizes
+# 2. Build Node Structure
+intr.t: intr_NOTIMES.t FORCE386_TIMES
+ ${REPLACE} -p FORCE386_TIMES intr_NOTIMES.t
+ mv intr_NOTIMES.t.fixed intr.t
+
+intr.texi: intr.t Makefile
+ $(BMENU) -p "Memory Model Flat Memory Model" \
+ -u "Top" \
+ -n "Default Fatal Error Processing" ${*}.t
+
+fatalerr.texi: fatalerr.t Makefile
+ $(BMENU) -p "Interrupt Processing Interrupt Stack" \
+ -u "Top" \
+ -n "Board Support Packages" ${*}.t
+
+bsp.texi: bsp.t Makefile
+ $(BMENU) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \
+ -u "Top" \
+ -n "Processor Dependent Information Table" ${*}.t
+
+cputable.texi: cputable.t Makefile
+ $(BMENU) -p "Board Support Packages Processor Initialization" \
+ -u "Top" \
+ -n "Memory Requirements" ${*}.t
# Worksheets Chapter:
# 1. Obtain the Shared File
@@ -95,19 +131,39 @@ timing.texi: timing.t Makefile
-u "Top" \
-n "CPU386 Timing Data" ${*}.t
-# Timing Chapter
-
-timetbl.t: ../../common/timetbl.t
- sed -e 's/TIMETABLE_NEXT_LINK/Command and Variable Index/' \
- <../../common/timetbl.t >timetbl.t
+# Timing Data for BSP Chapter:
+# 1. Copy the Shared File
+# 2. Replace Times and Sizes
+# 3. Build Node Structure
-timetbl.texi: timetbl.t FORCE386_TIMES
- ${REPLACE} -p FORCE386_TIMES timetbl.t
- mv timetbl.t.fixed timetbl.texi
+timeFORCE386_.t: ../../common/timetbl.t timeFORCE386.t
+ cat timeFORCE386.t ../../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
+ ${REPLACE} -p FORCE386_TIMES timeFORCE386_.t
+ mv timeFORCE386_.t.fixed timeFORCE386_.t
+
+timeFORCE386.texi: timeFORCE386_.t Makefile
+ $(BMENU) -p "Timing Specification Terminology" \
+ -u "Top" \
+ -n "Command and Variable Index" timeFORCE386_.t
+ mv timeFORCE386_.texi timeFORCE386.texi
-timedata.texi: timedata.t FORCE386_TIMES
- ${REPLACE} -p FORCE386_TIMES timedata.t
- mv timedata.t.fixed timedata.texi
+## Timing Chapter
+#
+#timetbl.t: ../../common/timetbl.t
+# sed -e 's/TIMETABLE_NEXT_LINK/Command and Variable Index/' \
+# <../../common/timetbl.t >timetbl.t
+#
+#timetbl.texi: timetbl.t FORCE386_TIMES
+# ${REPLACE} -p FORCE386_TIMES timetbl.t
+# mv timetbl.t.fixed timetbl.texi
+#
+#timedata.texi: timedata.t FORCE386_TIMES
+# ${REPLACE} -p FORCE386_TIMES timedata.t
+# mv timedata.t.fixed timedata.texi
html: dirs $(FILES)
-mkdir -p $(WWW_INSTALL)/c_i386
@@ -120,6 +176,7 @@ clean:
rm -f $(PROJECT) $(PROJECT)-*
rm -f c_i386 c_i386-*
rm -f timedata.texi timetbl.texi intr.texi $(GENERATED_FILES)
- rm -f timetbl.t wksheets.t wksheets_NOTIMES.t timing.t
+ rm -f timetbl.t wksheets.t wksheets_NOTIMES.t timing.t intr.t
+ rm -f timeFORCE386_.t
rm -f *.fixed _*
diff --git a/doc/supplements/i386/bsp.t b/doc/supplements/i386/bsp.t
index 6ec6b23eca..c15fb24835 100644
--- a/doc/supplements/i386/bsp.t
+++ b/doc/supplements/i386/bsp.t
@@ -6,21 +6,8 @@
@c $Id$
@c
-@ifinfo
-@node Board Support Packages, Board Support Packages Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Top
-@end ifinfo
@chapter Board Support Packages
-@ifinfo
-@menu
-* Board Support Packages Introduction::
-* Board Support Packages System Reset::
-* Board Support Packages Processor Initialization::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node Board Support Packages Introduction, Board Support Packages System Reset, Board Support Packages, Board Support Packages
-@end ifinfo
+
@section Introduction
An RTEMS Board Support Package (BSP) must be designed to support a
@@ -29,9 +16,6 @@ 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.
-@ifinfo
-@node Board Support Packages System Reset, Board Support Packages Processor Initialization, Board Support Packages Introduction, Board Support Packages
-@end ifinfo
@section System Reset
An RTEMS based application is initiated when the i386
@@ -72,9 +56,6 @@ of memory.
Typically, an intersegment JMP to the application's initialization code is
placed at address 0xFFFFFFF0.
-@ifinfo
-@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages
-@end ifinfo
@section Processor Initialization
This initialization code is responsible for initializing all data
diff --git a/doc/supplements/i386/bsp.texi b/doc/supplements/i386/bsp.texi
deleted file mode 100644
index 6ec6b23eca..0000000000
--- a/doc/supplements/i386/bsp.texi
+++ /dev/null
@@ -1,128 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1998.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Board Support Packages, Board Support Packages Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Top
-@end ifinfo
-@chapter Board Support Packages
-@ifinfo
-@menu
-* Board Support Packages Introduction::
-* Board Support Packages System Reset::
-* Board Support Packages Processor Initialization::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node Board Support Packages Introduction, Board Support Packages System Reset, Board Support Packages, Board Support Packages
-@end ifinfo
-@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.
-
-@ifinfo
-@node Board Support Packages System Reset, Board Support Packages Processor Initialization, Board Support Packages Introduction, Board Support Packages
-@end ifinfo
-@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.
-
-@ifinfo
-@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages
-@end ifinfo
-@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
index 1846c810a4..22415238f4 100644
--- a/doc/supplements/i386/callconv.t
+++ b/doc/supplements/i386/callconv.t
@@ -6,24 +6,8 @@
@c $Id$
@c
-@ifinfo
-@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Floating Point Unit, Top
-@end ifinfo
@chapter Calling Conventions
-@ifinfo
-@menu
-* Calling Conventions Introduction::
-* Calling Conventions Processor Background::
-* Calling Conventions Calling Mechanism::
-* Calling Conventions Register Usage::
-* Calling Conventions Parameter Passing::
-* Calling Conventions User-Provided Routines::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node Calling Conventions Introduction, Calling Conventions Processor Background, Calling Conventions, Calling Conventions
-@end ifinfo
+
@section Introduction
Each high-level language compiler generates
@@ -46,9 +30,6 @@ target processor are the same, different compilers may use
different calling conventions. As a result, calling conventions
are both processor and compiler dependent.
-@ifinfo
-@node Calling Conventions Processor Background, Calling Conventions Calling Mechanism, Calling Conventions Introduction, Calling Conventions
-@end ifinfo
@section Processor Background
The i386 architecture supports a simple yet effective
@@ -62,18 +43,12 @@ any registers. It is the responsibility of the high-level
language compiler to define the register preservation and usage
convention.
-@ifinfo
-@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions
-@end ifinfo
@section Calling Mechanism
All RTEMS directives are invoked using a call
instruction and return to the user application via the ret
instruction.
-@ifinfo
-@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions
-@end ifinfo
@section Register Usage
As discussed above, the call instruction does not
@@ -83,9 +58,6 @@ preserved by RTEMS directives therefore, the contents of these
registers should not be assumed upon return from any RTEMS
directive.
-@ifinfo
-@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions
-@end ifinfo
@section Parameter Passing
RTEMS assumes that arguments are placed on the
@@ -110,9 +82,6 @@ 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.
-@ifinfo
-@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions
-@end ifinfo
@section User-Provided Routines
All user-provided routines invoked by RTEMS, such as
diff --git a/doc/supplements/i386/callconv.texi b/doc/supplements/i386/callconv.texi
deleted file mode 100644
index 1846c810a4..0000000000
--- a/doc/supplements/i386/callconv.texi
+++ /dev/null
@@ -1,121 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1998.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Floating Point Unit, Top
-@end ifinfo
-@chapter Calling Conventions
-@ifinfo
-@menu
-* Calling Conventions Introduction::
-* Calling Conventions Processor Background::
-* Calling Conventions Calling Mechanism::
-* Calling Conventions Register Usage::
-* Calling Conventions Parameter Passing::
-* Calling Conventions User-Provided Routines::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node Calling Conventions Introduction, Calling Conventions Processor Background, Calling Conventions, Calling Conventions
-@end ifinfo
-@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.
-
-@ifinfo
-@node Calling Conventions Processor Background, Calling Conventions Calling Mechanism, Calling Conventions Introduction, Calling Conventions
-@end ifinfo
-@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.
-
-@ifinfo
-@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions
-@end ifinfo
-@section Calling Mechanism
-
-All RTEMS directives are invoked using a call
-instruction and return to the user application via the ret
-instruction.
-
-@ifinfo
-@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions
-@end ifinfo
-@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.
-
-@ifinfo
-@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions
-@end ifinfo
-@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.
-
-@ifinfo
-@node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions
-@end ifinfo
-@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
index d10ccf85f7..9b65e1d61d 100644
--- a/doc/supplements/i386/cpumodel.t
+++ b/doc/supplements/i386/cpumodel.t
@@ -6,22 +6,8 @@
@c $Id$
@c
-@ifinfo
-@node CPU Model Dependent Features, CPU Model Dependent Features Introduction, Preface, Top
-@end ifinfo
@chapter CPU Model Dependent Features
-@ifinfo
-@menu
-* CPU Model Dependent Features Introduction::
-* CPU Model Dependent Features CPU Model Name::
-* CPU Model Dependent Features bswap Instruction::
-* CPU Model Dependent Features Floating Point Unit::
-@end menu
-@end ifinfo
-@ifinfo
-@node CPU Model Dependent Features Introduction, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features, CPU Model Dependent Features
-@end ifinfo
@section Introduction
Microprocessors are generally classified into
@@ -63,18 +49,12 @@ The set of CPU model feature macros are defined in the file
c/src/exec/score/cpu/i386/i386.h based upon the particular CPU
model defined on the compilation command line.
-@ifinfo
-@node CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features bswap Instruction, CPU Model Dependent Features Introduction, CPU Model Dependent Features
-@end ifinfo
@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".
-@ifinfo
-@node CPU Model Dependent Features bswap Instruction, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features
-@end ifinfo
@section bswap Instruction
The macro I386_HAS_BSWAP is set to 1 to indicate that
@@ -83,10 +63,6 @@ endian swaps a thirty-two bit quantity. This instruction
appears to be present in all CPU models
i486's and above.
-
-@ifinfo
-@node CPU Model Dependent Features Floating Point Unit, Calling Conventions, CPU Model Dependent Features bswap Instruction , CPU Model Dependent Features
-@end ifinfo
@section Floating Point Unit
The macro I386_HAS_FPU is set to 1 to indicate that
diff --git a/doc/supplements/i386/cpumodel.texi b/doc/supplements/i386/cpumodel.texi
deleted file mode 100644
index d10ccf85f7..0000000000
--- a/doc/supplements/i386/cpumodel.texi
+++ /dev/null
@@ -1,96 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1998.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node CPU Model Dependent Features, CPU Model Dependent Features Introduction, Preface, Top
-@end ifinfo
-@chapter CPU Model Dependent Features
-@ifinfo
-@menu
-* CPU Model Dependent Features Introduction::
-* CPU Model Dependent Features CPU Model Name::
-* CPU Model Dependent Features bswap Instruction::
-* CPU Model Dependent Features Floating Point Unit::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node CPU Model Dependent Features Introduction, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features, CPU Model Dependent Features
-@end ifinfo
-@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 PA-RISC 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
-c/src/exec/score/cpu/i386/i386.h based upon the particular CPU
-model defined on the compilation command line.
-
-@ifinfo
-@node CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features bswap Instruction, CPU Model Dependent Features Introduction, CPU Model Dependent Features
-@end ifinfo
-@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".
-
-@ifinfo
-@node CPU Model Dependent Features bswap Instruction, CPU Model Dependent Features Floating Point Unit, CPU Model Dependent Features CPU Model Name, CPU Model Dependent Features
-@end ifinfo
-@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.
-
-
-@ifinfo
-@node CPU Model Dependent Features Floating Point Unit, Calling Conventions, CPU Model Dependent Features bswap Instruction , CPU Model Dependent Features
-@end ifinfo
-@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
index 25ae4db63a..9da005f732 100644
--- a/doc/supplements/i386/cputable.t
+++ b/doc/supplements/i386/cputable.t
@@ -6,20 +6,8 @@
@c $Id$
@c
-@ifinfo
-@node Processor Dependent Information Table, Processor Dependent Information Table Introduction, Board Support Packages Processor Initialization, Top
-@end ifinfo
@chapter Processor Dependent Information Table
-@ifinfo
-@menu
-* Processor Dependent Information Table Introduction::
-* Processor Dependent Information Table CPU Dependent Information Table::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node Processor Dependent Information Table Introduction, Processor Dependent Information Table CPU Dependent Information Table, Processor Dependent Information Table, Processor Dependent Information Table
-@end ifinfo
+
@section Introduction
Any highly processor dependent information required
@@ -28,9 +16,6 @@ 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.
-@ifinfo
-@node Processor Dependent Information Table CPU Dependent Information Table, Memory Requirements, Processor Dependent Information Table Introduction, Processor Dependent Information Table
-@end ifinfo
@section CPU Dependent Information Table
The i386 version of the RTEMS CPU Dependent
diff --git a/doc/supplements/i386/cputable.texi b/doc/supplements/i386/cputable.texi
deleted file mode 100644
index 25ae4db63a..0000000000
--- a/doc/supplements/i386/cputable.texi
+++ /dev/null
@@ -1,136 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1998.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Processor Dependent Information Table, Processor Dependent Information Table Introduction, Board Support Packages Processor Initialization, Top
-@end ifinfo
-@chapter Processor Dependent Information Table
-@ifinfo
-@menu
-* Processor Dependent Information Table Introduction::
-* Processor Dependent Information Table CPU Dependent Information Table::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node Processor Dependent Information Table Introduction, Processor Dependent Information Table CPU Dependent Information Table, Processor Dependent Information Table, Processor Dependent Information Table
-@end ifinfo
-@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.
-
-@ifinfo
-@node Processor Dependent Information Table CPU Dependent Information Table, Memory Requirements, Processor Dependent Information Table Introduction, Processor Dependent Information Table
-@end ifinfo
-@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 initialization
-is complete but before interrupts and tasking are enabled. This
-field may be NULL to indicate that the hook is not utilized.
-
-@item predriver_hook
-is the address of the user provided
-routine which is invoked with tasking enabled immediately before
-the MPCI and device drivers are initialized. RTEMS
-initialization is complete, interrupts and tasking are enabled,
-but no device drivers are initialized. This field may be NULL to
-indicate that the hook is not utilized.
-
-@item postdriver_hook
-is the address of the user provided
-routine which is invoked with tasking enabled immediately after
-the MPCI and device drivers are initialized. RTEMS
-initialization is complete, interrupts and tasking are enabled,
-and the device drivers are initialized. 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
index c19d98cb0e..7f9e0f3c56 100644
--- a/doc/supplements/i386/fatalerr.t
+++ b/doc/supplements/i386/fatalerr.t
@@ -6,20 +6,8 @@
@c $Id$
@c
-@ifinfo
-@node Default Fatal Error Processing, Default Fatal Error Processing Introduction, Interrupt Processing Interrupt Stack, Top
-@end ifinfo
@chapter Default Fatal Error Processing
-@ifinfo
-@menu
-* Default Fatal Error Processing Introduction::
-* Default Fatal Error Processing Default Fatal Error Handler Operations::
-@end menu
-@end ifinfo
-@ifinfo
-@node Default Fatal Error Processing Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Default Fatal Error Processing, Default Fatal Error Processing
-@end ifinfo
@section Introduction
Upon detection of a fatal error by either the
@@ -32,9 +20,6 @@ default fatal error handler is then invoked. This chapter
describes the precise operations of the default fatal error
handler.
-@ifinfo
-@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing
-@end ifinfo
@section Default Fatal Error Handler Operations
The default fatal error handler which is invoked by
diff --git a/doc/supplements/i386/fatalerr.texi b/doc/supplements/i386/fatalerr.texi
deleted file mode 100644
index c19d98cb0e..0000000000
--- a/doc/supplements/i386/fatalerr.texi
+++ /dev/null
@@ -1,46 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1998.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Default Fatal Error Processing, Default Fatal Error Processing Introduction, Interrupt Processing Interrupt Stack, Top
-@end ifinfo
-@chapter Default Fatal Error Processing
-@ifinfo
-@menu
-* Default Fatal Error Processing Introduction::
-* Default Fatal Error Processing Default Fatal Error Handler Operations::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node Default Fatal Error Processing Introduction, Default Fatal Error Processing Default Fatal Error Handler Operations, Default Fatal Error Processing, Default Fatal Error Processing
-@end ifinfo
-@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.
-
-@ifinfo
-@node Default Fatal Error Processing Default Fatal Error Handler Operations, Board Support Packages, Default Fatal Error Processing Introduction, Default Fatal Error Processing
-@end ifinfo
-@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
index 114432bce1..5e051828fe 100644
--- a/doc/supplements/i386/i386.texi
+++ b/doc/supplements/i386/i386.texi
@@ -72,7 +72,7 @@ END-INFO-DIR-ENTRY
@include cputable.texi
@include wksheets.texi
@include timing.texi
-@include timedata.texi
+@include timeFORCE386.texi
@ifinfo
@node Top, Preface, (dir), (dir)
@top c_i386
diff --git a/doc/supplements/i386/intr.t b/doc/supplements/i386/intr.t
deleted file mode 100644
index f14b2eac19..0000000000
--- a/doc/supplements/i386/intr.t
+++ /dev/null
@@ -1,199 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1998.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top
-@end ifinfo
-@chapter Interrupt Processing
-@ifinfo
-@menu
-* Interrupt Processing Introduction::
-* Interrupt Processing Vectoring of Interrupt Handler::
-* Interrupt Processing Interrupt Stack Frame::
-* Interrupt Processing Interrupt Levels::
-* Interrupt Processing Disabling of Interrupts by RTEMS::
-* Interrupt Processing Interrupt Stack::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node Interrupt Processing Introduction, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing, Interrupt Processing
-@end ifinfo
-@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.
-
-@ifinfo
-@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Stack Frame, Interrupt Processing Introduction, Interrupt Processing
-@end ifinfo
-@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.
-
-@ifinfo
-@node Interrupt Processing Interrupt Stack Frame, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
-@end ifinfo
-@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
-
-@ifinfo
-@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack Frame, Interrupt Processing
-@end ifinfo
-@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.
-
-@ifinfo
-@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
-@end ifinfo
-@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.
-
-@ifinfo
-@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing
-@end ifinfo
-@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/intr_NOTIMES.t b/doc/supplements/i386/intr_NOTIMES.t
index f14b2eac19..933973daa7 100644
--- a/doc/supplements/i386/intr_NOTIMES.t
+++ b/doc/supplements/i386/intr_NOTIMES.t
@@ -6,24 +6,8 @@
@c $Id$
@c
-@ifinfo
-@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top
-@end ifinfo
@chapter Interrupt Processing
-@ifinfo
-@menu
-* Interrupt Processing Introduction::
-* Interrupt Processing Vectoring of Interrupt Handler::
-* Interrupt Processing Interrupt Stack Frame::
-* Interrupt Processing Interrupt Levels::
-* Interrupt Processing Disabling of Interrupts by RTEMS::
-* Interrupt Processing Interrupt Stack::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node Interrupt Processing Introduction, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing, Interrupt Processing
-@end ifinfo
+
@section Introduction
Different types of processors respond to the
@@ -41,9 +25,6 @@ processor's unique architecture. Discussed in this chapter are
the the processor's response and control mechanisms as they
pertain to RTEMS.
-@ifinfo
-@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Stack Frame, Interrupt Processing Introduction, Interrupt Processing
-@end ifinfo
@section Vectoring of Interrupt Handler
Although the i386 supports multiple privilege levels,
@@ -68,9 +49,6 @@ performs the following actions:
A nested interrupt is processed similarly by the
i386.
-@ifinfo
-@node Interrupt Processing Interrupt Stack Frame, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
-@end ifinfo
@section Interrupt Stack Frame
The structure of the Interrupt Stack Frame for the
@@ -129,9 +107,6 @@ response to an interrupt is as follows:
@end html
@end ifset
-@ifinfo
-@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack Frame, Interrupt Processing
-@end ifinfo
@section Interrupt Levels
Although RTEMS supports 256 interrupt levels, the
@@ -147,9 +122,6 @@ RTEMS interrupt levels 0 and 1 such that level zero
that interrupts are disabled. All other RTEMS interrupt levels
are undefined and their behavior is unpredictable.
-@ifinfo
-@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
-@end ifinfo
@section Disabling of Interrupts by RTEMS
During the execution of directive calls, critical
@@ -171,9 +143,6 @@ occur due to the inability of RTEMS to protect its critical
sections. However, ISRs that make no system calls may safely
execute as non-maskable interrupts.
-@ifinfo
-@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing
-@end ifinfo
@section Interrupt Stack
The i386 family does not support a dedicated hardware
diff --git a/doc/supplements/i386/memmodel.t b/doc/supplements/i386/memmodel.t
index 6a16cbb35f..e8bb2ab48d 100644
--- a/doc/supplements/i386/memmodel.t
+++ b/doc/supplements/i386/memmodel.t
@@ -6,20 +6,8 @@
@c $Id$
@c
-@ifinfo
-@node Memory Model, Memory Model Introduction, Calling Conventions User-Provided Routines, Top
-@end ifinfo
@chapter Memory Model
-@ifinfo
-@menu
-* Memory Model Introduction::
-* Memory Model Flat Memory Model::
-@end menu
-@end ifinfo
-@ifinfo
-@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model
-@end ifinfo
@section Introduction
A processor may support any combination of memory
@@ -31,9 +19,6 @@ 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.
-@ifinfo
-@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model
-@end ifinfo
@section Flat Memory Model
RTEMS supports the i386 protected mode, flat memory
diff --git a/doc/supplements/i386/memmodel.texi b/doc/supplements/i386/memmodel.texi
deleted file mode 100644
index 6a16cbb35f..0000000000
--- a/doc/supplements/i386/memmodel.texi
+++ /dev/null
@@ -1,87 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1998.
-@c On-Line Applications Research Corporation (OAR).
-@c All rights reserved.
-@c
-@c $Id$
-@c
-
-@ifinfo
-@node Memory Model, Memory Model Introduction, Calling Conventions User-Provided Routines, Top
-@end ifinfo
-@chapter Memory Model
-@ifinfo
-@menu
-* Memory Model Introduction::
-* Memory Model Flat Memory Model::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node Memory Model Introduction, Memory Model Flat Memory Model, Memory Model, Memory Model
-@end ifinfo
-@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.
-
-@ifinfo
-@node Memory Model Flat Memory Model, Interrupt Processing, Memory Model Introduction, Memory Model
-@end ifinfo
-@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/timeFORCE386.t b/doc/supplements/i386/timeFORCE386.t
index 0049c1fdcd..88d8ea09cf 100644
--- a/doc/supplements/i386/timeFORCE386.t
+++ b/doc/supplements/i386/timeFORCE386.t
@@ -11,36 +11,8 @@
\global\advance \smallskipamount by -4pt
@end tex
-@ifinfo
-@node CPU386 Timing Data, CPU386 Timing Data Introduction, Timing Specification Terminology, Top
-@end ifinfo
@chapter CPU386 Timing Data
-@ifinfo
-@menu
-* CPU386 Timing Data Introduction::
-* CPU386 Timing Data Hardware Platform::
-* CPU386 Timing Data Interrupt Latency::
-* CPU386 Timing Data Context Switch::
-* CPU386 Timing Data Directive Times::
-* CPU386 Timing Data Task Manager::
-* CPU386 Timing Data Interrupt Manager::
-* CPU386 Timing Data Clock Manager::
-* CPU386 Timing Data Timer Manager::
-* CPU386 Timing Data Semaphore Manager::
-* CPU386 Timing Data Message Manager::
-* CPU386 Timing Data Event Manager::
-* CPU386 Timing Data Signal Manager::
-* CPU386 Timing Data Partition Manager::
-* CPU386 Timing Data Region Manager::
-* CPU386 Timing Data Dual-Ported Memory Manager::
-* CPU386 Timing Data I/O Manager::
-* CPU386 Timing Data Rate Monotonic Manager::
-@end menu
-@end ifinfo
-@ifinfo
-@node CPU386 Timing Data Introduction, CPU386 Timing Data Hardware Platform, CPU386 Timing Data, CPU386 Timing Data
-@end ifinfo
@section Introduction
The timing data for the i386 version of RTEMS is
@@ -51,9 +23,6 @@ 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.
-@ifinfo
-@node CPU386 Timing Data Hardware Platform, CPU386 Timing Data Interrupt Latency, CPU386 Timing Data Introduction, CPU386 Timing Data
-@end ifinfo
@section Hardware Platform
All times reported except for the maximum period
@@ -73,9 +42,6 @@ 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.
-@ifinfo
-@node CPU386 Timing Data Interrupt Latency, CPU386 Timing Data Context Switch, CPU386 Timing Data Hardware Platform, CPU386 Timing Data
-@end ifinfo
@section Interrupt Latency
The maximum period with interrupts disabled within
@@ -98,9 +64,6 @@ vector and entry overhead time was generated on the Force
Computers CPU386 benchmark platform using the int instruction as
the interrupt source.
-@ifinfo
-@node CPU386 Timing Data Context Switch, CPU386 Timing Data Directive Times, CPU386 Timing Data Interrupt Latency, CPU386 Timing Data
-@end ifinfo
@section Context Switch
The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
@@ -136,8 +99,3 @@ coprocessor is task specific.
The following table summarizes the context switch
times for the Force Computers CPU386 benchmark platform:
-@include timetbl.texi
-
-@tex
-\global\advance \smallskipamount by 4pt
-@end tex
diff --git a/doc/supplements/i386/timedata.t b/doc/supplements/i386/timedata.t
deleted file mode 100644
index 0049c1fdcd..0000000000
--- a/doc/supplements/i386/timedata.t
+++ /dev/null
@@ -1,143 +0,0 @@
-@c
-@c COPYRIGHT (c) 1988-1998.
-@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 CPU386 Timing Data, CPU386 Timing Data Introduction, Timing Specification Terminology, Top
-@end ifinfo
-@chapter CPU386 Timing Data
-@ifinfo
-@menu
-* CPU386 Timing Data Introduction::
-* CPU386 Timing Data Hardware Platform::
-* CPU386 Timing Data Interrupt Latency::
-* CPU386 Timing Data Context Switch::
-* CPU386 Timing Data Directive Times::
-* CPU386 Timing Data Task Manager::
-* CPU386 Timing Data Interrupt Manager::
-* CPU386 Timing Data Clock Manager::
-* CPU386 Timing Data Timer Manager::
-* CPU386 Timing Data Semaphore Manager::
-* CPU386 Timing Data Message Manager::
-* CPU386 Timing Data Event Manager::
-* CPU386 Timing Data Signal Manager::
-* CPU386 Timing Data Partition Manager::
-* CPU386 Timing Data Region Manager::
-* CPU386 Timing Data Dual-Ported Memory Manager::
-* CPU386 Timing Data I/O Manager::
-* CPU386 Timing Data Rate Monotonic Manager::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node CPU386 Timing Data Introduction, CPU386 Timing Data Hardware Platform, CPU386 Timing Data, CPU386 Timing Data
-@end ifinfo
-@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.
-
-@ifinfo
-@node CPU386 Timing Data Hardware Platform, CPU386 Timing Data Interrupt Latency, CPU386 Timing Data Introduction, CPU386 Timing Data
-@end ifinfo
-@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.
-
-@ifinfo
-@node CPU386 Timing Data Interrupt Latency, CPU386 Timing Data Context Switch, CPU386 Timing Data Hardware Platform, CPU386 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 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.
-
-@ifinfo
-@node CPU386 Timing Data Context Switch, CPU386 Timing Data Directive Times, CPU386 Timing Data Interrupt Latency, CPU386 Timing Data
-@end ifinfo
-@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:
-
-@include timetbl.texi
-
-@tex
-\global\advance \smallskipamount by 4pt
-@end tex