RTOS/rtems
1
0
Fork 0
forked from Imagelibrary/rtems
Code Pull Requests Activity

Nearly everything that can be is now automatically generated.

Browse Source
This commit is contained in:
Joel Sherrill
1998-10-19 18:25:16 +00:00
parent 3a5676e721
commit 8eba4708f0
18 changed files with 87 additions and 1178 deletions
Download Patch File Download Diff File Expand all files Collapse all files

115
doc/supplements/i386/Makefile
View File

@@ -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
# Timing Data for BSP Chapter:
# 1. Copy the Shared File
# 2. Replace Times and Sizes
# 3. Build Node Structure
timetbl.t: ../../common/timetbl.t
sed -e 's/TIMETABLE_NEXT_LINK/Command and Variable Index/' \
<../../common/timetbl.t >timetbl.t
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
timetbl.texi: timetbl.t FORCE386_TIMES
${REPLACE} -p FORCE386_TIMES timetbl.t
mv timetbl.t.fixed timetbl.texi
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 _*

19
doc/supplements/i386/bsp.t
View File

@@ -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

128
doc/supplements/i386/bsp.texi
View File

@@ -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.

31
doc/supplements/i386/callconv.t
View File

@@ -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

121
doc/supplements/i386/callconv.texi
View File

@@ -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.

24
doc/supplements/i386/cpumodel.t
View File

@@ -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

96
doc/supplements/i386/cpumodel.texi
View File

@@ -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).

15
doc/supplements/i386/cputable.t
View File

@@ -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

136
doc/supplements/i386/cputable.texi
View File

@@ -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.

15
doc/supplements/i386/fatalerr.t
View File

@@ -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

46
doc/supplements/i386/fatalerr.texi
View File

@@ -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.

2
doc/supplements/i386/i386.texi
View File

@@ -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

199
doc/supplements/i386/intr.t
View File

@@ -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.

31
doc/supplements/i386/intr_NOTIMES.t
View File

@@ -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

15
doc/supplements/i386/memmodel.t
View File

@@ -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

87
doc/supplements/i386/memmodel.texi
View File

@@ -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.

42
doc/supplements/i386/timeFORCE386.t
View File

@@ -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

143
doc/supplements/i386/timedata.t
View File

@@ -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