1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-2002. |
---|
3 | @c On-Line Applications Research Corporation (OAR). |
---|
4 | @c All rights reserved. |
---|
5 | @c |
---|
6 | @c $Id$ |
---|
7 | @c |
---|
8 | |
---|
9 | @include common/timemac.texi |
---|
10 | @tex |
---|
11 | \global\advance \smallskipamount by -4pt |
---|
12 | @end tex |
---|
13 | |
---|
14 | @chapter CPU386 Timing Data |
---|
15 | |
---|
16 | @section Introduction |
---|
17 | |
---|
18 | The timing data for the i386 version of RTEMS is |
---|
19 | provided along with the target dependent aspects concerning the |
---|
20 | gathering of the timing data. The hardware platform used to |
---|
21 | gather the times is described to give the reader a better |
---|
22 | understanding of each directive time provided. Also, provided |
---|
23 | is a description of the interrupt latency and the context |
---|
24 | switch times as they pertain to the i386 version of RTEMS. |
---|
25 | |
---|
26 | @section Hardware Platform |
---|
27 | |
---|
28 | All times reported except for the maximum period |
---|
29 | interrupts are disabled by RTEMS were measured using a Force |
---|
30 | Computers CPU386 board. The CPU386 is a 16 Mhz board with zero |
---|
31 | wait state dynamic memory and an i80387 numeric coprocessor. |
---|
32 | One of the count-down timers provided by a Motorola MC68901 was |
---|
33 | used to measure elapsed time with one microsecond resolution. |
---|
34 | All sources of hardware interrupts are disabled, although the |
---|
35 | interrupt level of the i386 allows all interrupts. |
---|
36 | |
---|
37 | The maximum period interrupts are disabled was |
---|
38 | measured by summing the number of CPU cycles required by each |
---|
39 | assembly language instruction executed while interrupts were |
---|
40 | disabled. Zero wait state memory was assumed. The total CPU |
---|
41 | cycles executed with interrupts disabled, including the |
---|
42 | instructions to disable and enable interrupts, was divided by 16 |
---|
43 | to simulate a i386 executing at 16 Mhz. |
---|
44 | |
---|
45 | @section Interrupt Latency |
---|
46 | |
---|
47 | The maximum period with interrupts disabled within |
---|
48 | RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD microseconds |
---|
49 | including the instructions |
---|
50 | which disable and re-enable interrupts. The time required for |
---|
51 | the i386 to generate an interrupt using the int instruction, |
---|
52 | vectoring to an interrupt handler, and for the RTEMS entry |
---|
53 | overhead before invoking the user's interrupt handler are a |
---|
54 | total of 12 microseconds. These combine to yield a worst case |
---|
55 | interrupt latency of less |
---|
56 | RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK |
---|
57 | microseconds. [NOTE: The |
---|
58 | maximum period with interrupts disabled within RTEMS was last |
---|
59 | calculated for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] |
---|
60 | |
---|
61 | It should be noted again that the maximum period with |
---|
62 | interrupts disabled within RTEMS is hand-timed. The interrupt |
---|
63 | vector and entry overhead time was generated on the Force |
---|
64 | Computers CPU386 benchmark platform using the int instruction as |
---|
65 | the interrupt source. |
---|
66 | |
---|
67 | @section Context Switch |
---|
68 | |
---|
69 | The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS |
---|
70 | microseconds on the Force Computers CPU386 benchmark platform. |
---|
71 | This time represents the raw context switch time with no user |
---|
72 | extensions configured. Additional execution time is required |
---|
73 | when a TASK_SWITCH user extension is configured. The use of the |
---|
74 | TASK_SWITCH extension is application dependent. Thus, its |
---|
75 | execution time is not considered part of the base context switch |
---|
76 | time. |
---|
77 | |
---|
78 | Since RTEMS was designed specifically for embedded |
---|
79 | missile applications which are floating point intensive, the |
---|
80 | executive is optimized to avoid unnecessarily saving and |
---|
81 | restoring the state of the numeric coprocessor. The state of |
---|
82 | the numeric coprocessor is only saved when a FLOATING_POINT task |
---|
83 | is dispatched and that task was not the last task to utilize the |
---|
84 | coprocessor. In a system with only one FLOATING_POINT task, the |
---|
85 | state of the numeric coprocessor will never be saved or |
---|
86 | restored. When the first FLOATING_POINT task is dispatched, |
---|
87 | RTEMS does not need to save the current state of the numeric |
---|
88 | coprocessor. |
---|
89 | |
---|
90 | The exact amount of time required to save and restore |
---|
91 | floating point context is dependent on the state of the numeric |
---|
92 | coprocessor. RTEMS places the coprocessor in the initialized |
---|
93 | state when a task is started or restarted. Once the task has |
---|
94 | utilized the coprocessor, it is in the idle state when floating |
---|
95 | point instructions are not executing and the busy state when |
---|
96 | floating point instructions are executing. The state of the |
---|
97 | coprocessor is task specific. |
---|
98 | |
---|
99 | The following table summarizes the context switch |
---|
100 | times for the Force Computers CPU386 benchmark platform: |
---|
101 | |
---|