forked from Imagelibrary/rtems
110445cba5
which splits the current monolithic specs files into a sequence of
subparts. These can be concatenated togather to make a the whole .spec
file. This cleans up the maintenance problem of having "all languages"
and a "C/C++ only" gccnewlib spec files. Plus it should make it easier
to produce variants like the gdb-m68k-bdm which require special hackery. :)
Ralf's comments:
It addresses the way *.spec.in get composed inside of the source
tree.
Changes:
* Each spec.in is broken into several files (*.add), one *.add file
per sub-package.
* Each Makefile.am composes spec.ins from the *.add files
* Removal of redundant automake support files.
* Default value for BuildRoot changed to /tmp/<spec-file-name>
* %clean stage added to *specs
Advantages (IMHO).
* The *.add files are easier to adminstrate and more flexible in
comparison to the former *.specs.ins.
* gccnewlib_c_only.spec.in now is composed from the same sources as
gccnewlib.spec.in (less errors)
* If using the default BuildRoot --clean now deletes all files that
were generated while building.
Notes:
* rtems.spec.in has not yet been adapted to the scheme used for the
other *spec.ins
* Except for cosmetical changes the internals of the *.spec files
should not have changed.
To Apply:
cvs rm -f scripts/binutils/binutils.spec.in
cvs rm -f scripts/gccnewlib/gccnewlib.spec.in
cvs rm -f scripts/gccnewlib/gccnewlib_c_only.spec.in
cvs rm -f scripts/gdb/gdb.spec.in
cvs rm -f scripts/config.sub
cvs rm -f scripts/config.guess
cvs rm -f scripts/install-sh
cvs rm -f scripts/mkinstalldirs
cvs rm -f scripts/missing
patch -p1 < rtems-rc-4.5.0-21.diff
cvs add scripts/*/*.add
cvs add scripts/*/README
102 lines
4.1 KiB
Perl
102 lines
4.1 KiB
Perl
@c
|
|
@c COPYRIGHT (c) 1988-1999.
|
|
@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 CPU386 Timing Data
|
|
|
|
@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.
|
|
|
|
@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.
|
|
|
|
@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.
|
|
|
|
@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:
|
|
|