1 files changed, 113 insertions, 0 deletions
diff --git a/doc/supplements/powerpc/timeDMV177.t b/doc/supplements/powerpc/timeDMV177.t
new file mode 100644
index 0000000000..301bfee4c1
--- /dev/null
+++ b/doc/supplements/powerpc/timeDMV177.t
@@ -0,0 +1,113 @@
+@c
+@c  Timing information for the DMV177
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+
+@include common/timemac.texi
+@tex
+\global\advance \smallskipamount by -4pt
+@end tex
+
+@chapter RTEMS_BSP Timing Data
+
+@section Introduction
+
+The timing data for RTEMS on the DY-4 RTEMS_BSP board
+is provided along with the target
+dependent aspects concerning the gathering of the timing data.
+The hardware platform used to gather the times is described to
+give the reader a better understanding of each directive time
+provided.  Also, provided is a description of the interrupt
+latency and the context switch times as they pertain to the
+PowerPC version of RTEMS.
+
+@section Hardware Platform
+
+All times reported in this chapter were measured using a RTEMS_BSP board.
+All data and code caching was disabled.  This results in very deterministic
+times which represent the worst possible performance.  Many embedded 
+applications disable caching to insure that execution times are
+repeatable.  Moreover, the JTAG port on certain revisions of the PowerPC
+603e does not operate properly if caching is enabled.  Thus during 
+development and debug, caching must be off.
+
+The PowerPC decrementer register was was used to gather
+all timing information.  In the PowerPC architecture,
+this register typically counts
+something like CPU cycles or is a function of the clock
+speed.  On the PPC603e decrements once for every four (4) bus cycles.
+On the RTEMS_BSP, the bus operates at a clock speed of 
+33 Mhz.  This result in a very accurate number since it is a function of the 
+microprocessor itself.  Thus all measurements in this 
+chapter are reported as the actual number of decrementer
+clicks reported.  
+
+To convert the numbers reported to microseconds, one should
+divide the number reported by 8.650752.  This number was derived as
+shown below:
+
+@example
+((33 * 1048576) / 1000000) / 4 = 8.650752
+@end example
+
+All sources of hardware interrupts were disabled,
+although traps were enabled and the interrupt level of the
+PowerPC allows all interrupts.
+
+@section Interrupt Latency
+
+The maximum period with traps disabled or the
+processor interrupt level set to it's highest value inside RTEMS
+is less than RTEMS_MAXIMUM_DISABLE_PERIOD
+microseconds including the instructions which
+disable and re-enable interrupts.  The time required for the
+PowerPC to vector an interrupt and for the RTEMS entry overhead
+before invoking the user's trap handler are a total of 
+RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
+microseconds.  These combine to yield a worst case interrupt
+latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD +
+RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at 
+RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz.
+[NOTE:  The maximum period with interrupts disabled was last
+determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
+
+The maximum period with interrupts disabled within
+RTEMS is hand-timed with some assistance from the PowerPC simulator.
+The maximum period with interrupts disabled with RTEMS has not
+been calculated on this target.
+
+The interrupt vector and entry overhead time was
+generated on the PSIM benchmark platform using the PowerPC's
+decrementer register.  This register was programmed to generate
+an interrupt after one countdown.
+
+@section Context Switch
+
+The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
+bus cycle on the RTEMS_BSP benchmark platform when no floating
+point context is saved or restored.  Additional execution time
+is required when a TASK_SWITCH user extension is configured.
+The use of the TASK_SWITCH extension is application dependent.
+Thus, its execution time is not considered part of the raw
+context switch time.
+
+Since RTEMS was designed specifically for embedded
+missile applications which are floating point intensive, the
+executive is optimized to avoid unnecessarily saving and
+restoring the state of the numeric coprocessor.  The state of
+the numeric coprocessor is only saved when an FLOATING_POINT
+task is dispatched and that task was not the last task to
+utilize the coprocessor.  In a system with only one
+FLOATING_POINT task, the state of the numeric coprocessor will
+never be saved or restored.  When the first FLOATING_POINT task
+is dispatched, RTEMS does not need to save the current state of
+the numeric coprocessor.
+
+The following table summarizes the context switch
+times for the RTEMS_BSP benchmark platform:
+