path: root/doc/supplements/i386/timeFORCE386.t
diff options
authorJoel Sherrill <>1997-05-27 12:40:11 +0000
committerJoel Sherrill <>1997-05-27 12:40:11 +0000
commitae68ff085724dd35d60151bd153e80b8b0776873 (patch)
tree2f1535a0497f5b872a4744ae13c9264b77e89c11 /doc/supplements/i386/timeFORCE386.t
parentThis commit was generated by cvs2svn to compensate for changes in r832, (diff)
Initial revision
Diffstat (limited to 'doc/supplements/i386/timeFORCE386.t')
1 files changed, 135 insertions, 0 deletions
diff --git a/doc/supplements/i386/timeFORCE386.t b/doc/supplements/i386/timeFORCE386.t
new file mode 100644
index 0000000000..03362e3c88
--- /dev/null
+++ b/doc/supplements/i386/timeFORCE386.t
@@ -0,0 +1,135 @@
+@include ../common/timemac.texi
+\global\advance \smallskipamount by -4pt
+@end tex
+@node i386 Timing Data, i386 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top
+@end ifinfo
+@chapter i386 Timing Data
+* i386 Timing Data Introduction::
+* i386 Timing Data Hardware Platform::
+* i386 Timing Data Interrupt Latency::
+* i386 Timing Data Context Switch::
+* i386 Timing Data Directive Times::
+* i386 Timing Data Task Manager::
+* i386 Timing Data Interrupt Manager::
+* i386 Timing Data Clock Manager::
+* i386 Timing Data Timer Manager::
+* i386 Timing Data Semaphore Manager::
+* i386 Timing Data Message Manager::
+* i386 Timing Data Event Manager::
+* i386 Timing Data Signal Manager::
+* i386 Timing Data Partition Manager::
+* i386 Timing Data Region Manager::
+* i386 Timing Data Dual-Ported Memory Manager::
+* i386 Timing Data I/O Manager::
+* i386 Timing Data Rate Monotonic Manager::
+@end menu
+@end ifinfo
+@node i386 Timing Data Introduction, i386 Timing Data Hardware Platform, i386 Timing Data, i386 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.
+@node i386 Timing Data Hardware Platform, i386 Timing Data Interrupt Latency, i386 Timing Data Introduction, i386 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.
+@node i386 Timing Data Interrupt Latency, i386 Timing Data Context Switch, i386 Timing Data Hardware Platform, i386 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
+microseconds. [NOTE: The
+maximum period with interrupts disabled within RTEMS was last
+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.
+@node i386 Timing Data Context Switch, i386 Timing Data Directive Times, i386 Timing Data Interrupt Latency, i386 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
+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
+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
+\global\advance \smallskipamount by 4pt
+@end tex