Renamed.

3 files changed, 0 insertions, 645 deletions

diff --git a/doc/supplements/sparc/SIS_TIMES b/doc/supplements/sparc/SIS_TIMES
deleted file mode 100644
index 4f9ce4c98b..0000000000
--- a/doc/supplements/sparc/SIS_TIMES
+++ /dev/null
@@ -1,247 +0,0 @@
-#
-#  SPARC/ERC32/SIS Timing and Size Information
-#
-#  $Id$
-#
-
-#
-#  CPU Model Information
-#
-RTEMS_BSP       ERC32
-RTEMS_CPU_MODEL ERC32
-#
-#  Interrupt Latency
-#
-#  NOTE:  In general, the text says it is hand-calculated to be
-#         RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
-#         Mhz and this was last calculated for Release 
-#         RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD.
-#
-RTEMS_MAXIMUM_DISABLE_PERIOD TBD
-RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 15.0
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.2.0-prerelease
-#
-#  Context Switch Times
-#
-RTEMS_NO_FP_CONTEXTS 21
-RTEMS_RESTORE_1ST_FP_TASK 26
-RTEMS_SAVE_INIT_RESTORE_INIT 24
-RTEMS_SAVE_IDLE_RESTORE_INIT 23
-RTEMS_SAVE_IDLE_RESTORE_IDLE 33
-#
-#  Task Manager Times
-#
-RTEMS_TASK_CREATE_ONLY 59
-RTEMS_TASK_IDENT_ONLY 163
-RTEMS_TASK_START_ONLY 30
-RTEMS_TASK_RESTART_CALLING_TASK 64
-RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 36
-RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 47
-RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 37
-RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 77
-RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 84
-RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 75
-RTEMS_TASK_DELETE_CALLING_TASK 91
-RTEMS_TASK_DELETE_SUSPENDED_TASK 47
-RTEMS_TASK_DELETE_BLOCKED_TASK 50
-RTEMS_TASK_DELETE_READY_TASK 51
-RTEMS_TASK_SUSPEND_CALLING_TASK 56
-RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 16
-RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 17
-RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 52
-RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 10
-RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 25
-RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 67
-RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 5
-RTEMS_TASK_MODE_NO_RESCHEDULE 6
-RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 9
-RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 42
-RTEMS_TASK_GET_NOTE_ONLY 10
-RTEMS_TASK_SET_NOTE_ONLY 10
-RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 6
-RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 49
-RTEMS_TASK_WAKE_WHEN_ONLY 75
-#
-#  Interrupt Manager
-#
-RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 7
-RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 8
-RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 8
-RTEMS_INTR_EXIT_RETURNS_TO_NESTED 5
-RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 7
-RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 14
-#
-#  Clock Manager
-#
-RTEMS_CLOCK_SET_ONLY 33
-RTEMS_CLOCK_GET_ONLY 4
-RTEMS_CLOCK_TICK_ONLY 6
-#
-#  Timer Manager
-#
-RTEMS_TIMER_CREATE_ONLY 11
-RTEMS_TIMER_IDENT_ONLY 159
-RTEMS_TIMER_DELETE_INACTIVE 15
-RTEMS_TIMER_DELETE_ACTIVE 17
-RTEMS_TIMER_FIRE_AFTER_INACTIVE 21
-RTEMS_TIMER_FIRE_AFTER_ACTIVE 23
-RTEMS_TIMER_FIRE_WHEN_INACTIVE 34
-RTEMS_TIMER_FIRE_WHEN_ACTIVE 34
-RTEMS_TIMER_RESET_INACTIVE 20
-RTEMS_TIMER_RESET_ACTIVE 22
-RTEMS_TIMER_CANCEL_INACTIVE 10
-RTEMS_TIMER_CANCEL_ACTIVE 13
-#
-#  Semaphore Manager
-#
-RTEMS_SEMAPHORE_CREATE_ONLY 19
-RTEMS_SEMAPHORE_IDENT_ONLY 171
-RTEMS_SEMAPHORE_DELETE_ONLY 19
-RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 12
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 12
-RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 67
-RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 14
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 23
-RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 57
-#
-#  Message Manager
-#
-RTEMS_MESSAGE_QUEUE_CREATE_ONLY 114
-RTEMS_MESSAGE_QUEUE_IDENT_ONLY 159
-RTEMS_MESSAGE_QUEUE_DELETE_ONLY 25
-RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 36
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 38
-RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 76
-RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 36
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 38
-RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 76
-RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 15
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 42
-RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 83
-RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 30
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 13
-RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 67
-RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 9
-RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 13
-#
-#  Event Manager
-#
-RTEMS_EVENT_SEND_NO_TASK_READIED 9
-RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 22
-RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 58
-RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1
-RTEMS_EVENT_RECEIVE_AVAILABLE 10
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 9
-RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 60
-#
-#  Signal Manager
-#
-RTEMS_SIGNAL_CATCH_ONLY 6
-RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 14
-RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 22
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 27
-RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 56
-#
-#  Partition Manager
-#
-RTEMS_PARTITION_CREATE_ONLY 34
-RTEMS_PARTITION_IDENT_ONLY 159
-RTEMS_PARTITION_DELETE_ONLY 14
-RTEMS_PARTITION_GET_BUFFER_AVAILABLE 12
-RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 10
-RTEMS_PARTITION_RETURN_BUFFER_ONLY 16
-#
-#  Region Manager
-#
-RTEMS_REGION_CREATE_ONLY 22
-RTEMS_REGION_IDENT_ONLY 162
-RTEMS_REGION_DELETE_ONLY 14
-RTEMS_REGION_GET_SEGMENT_AVAILABLE 19
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 19
-RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 67
-RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 17
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 44
-RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 77
-#
-#  Dual-Ported Memory Manager
-#
-RTEMS_PORT_CREATE_ONLY 14
-RTEMS_PORT_IDENT_ONLY 159
-RTEMS_PORT_DELETE_ONLY 13
-RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 9
-RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 9
-#
-#  IO Manager
-#
-RTEMS_IO_INITIALIZE_ONLY 2
-RTEMS_IO_OPEN_ONLY 1
-RTEMS_IO_CLOSE_ONLY 1
-RTEMS_IO_READ_ONLY 1
-RTEMS_IO_WRITE_ONLY 1
-RTEMS_IO_CONTROL_ONLY 1
-#
-#  Rate Monotonic Manager
-#
-RTEMS_RATE_MONOTONIC_CREATE_ONLY 12
-RTEMS_RATE_MONOTONIC_IDENT_ONLY 159
-RTEMS_RATE_MONOTONIC_CANCEL_ONLY 14
-RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 19
-RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 16
-RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 20
-RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 55
-RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 9
-#
-#  Size Information
-#
-#
-#  xxx alloted for numbers
-#
-RTEMS_DATA_SPACE 9059
-RTEMS_MINIMUM_CONFIGURATION 28,288
-RTEMS_MAXIMUM_CONFIGURATION 50,432
-#  x,xxx alloted for numbers
-RTEMS_CORE_CODE_SIZE 20,336
-RTEMS_INITIALIZATION_CODE_SIZE 1,408
-RTEMS_TASK_CODE_SIZE 4,496
-RTEMS_INTERRUPT_CODE_SIZE 72
-RTEMS_CLOCK_CODE_SIZE 576
-RTEMS_TIMER_CODE_SIZE 1,336
-RTEMS_SEMAPHORE_CODE_SIZE 1,888
-RTEMS_MESSAGE_CODE_SIZE 2,032
-RTEMS_EVENT_CODE_SIZE 1,696
-RTEMS_SIGNAL_CODE_SIZE 664
-RTEMS_PARTITION_CODE_SIZE 1,368
-RTEMS_REGION_CODE_SIZE 1,736
-RTEMS_DPMEM_CODE_SIZE 872
-RTEMS_IO_CODE_SIZE 1,144
-RTEMS_FATAL_ERROR_CODE_SIZE 32
-RTEMS_RATE_MONOTONIC_CODE_SIZE 1,656
-RTEMS_MULTIPROCESSING_CODE_SIZE 8,328
-#  xxx alloted for numbers
-RTEMS_TIMER_CODE_OPTSIZE 208
-RTEMS_SEMAPHORE_CODE_OPTSIZE 192
-RTEMS_MESSAGE_CODE_OPTSIZE 320
-RTEMS_EVENT_CODE_OPTSIZE 64
-RTEMS_SIGNAL_CODE_OPTSIZE 64
-RTEMS_PARTITION_CODE_OPTSIZE 152
-RTEMS_REGION_CODE_OPTSIZE 176
-RTEMS_DPMEM_CODE_OPTSIZE 152
-RTEMS_IO_CODE_OPTSIZE 00
-RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 208
-RTEMS_MULTIPROCESSING_CODE_OPTSIZE 408
-#  xxx alloted for numbers
-RTEMS_BYTES_PER_TASK 488
-RTEMS_BYTES_PER_TIMER 68
-RTEMS_BYTES_PER_SEMAPHORE 124
-RTEMS_BYTES_PER_MESSAGE_QUEUE 148
-RTEMS_BYTES_PER_REGION 144
-RTEMS_BYTES_PER_PARTITION 56
-RTEMS_BYTES_PER_PORT 36
-RTEMS_BYTES_PER_PERIOD 36
-RTEMS_BYTES_PER_EXTENSION 64
-RTEMS_BYTES_PER_FP_TASK 136
-RTEMS_BYTES_PER_NODE 48
-RTEMS_BYTES_PER_GLOBAL_OBJECT 20
-RTEMS_BYTES_PER_PROXY 124
-#  x,xxx alloted for numbers
-RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 10,072
diff --git a/doc/supplements/sparc/intr.t b/doc/supplements/sparc/intr.t
deleted file mode 100644
index 2b816feb28..0000000000
--- a/doc/supplements/sparc/intr.t
+++ /dev/null
@@ -1,234 +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 Synchronous Versus Asynchronous Traps::
-* Interrupt Processing Vectoring of Interrupt Handler::
-* Interrupt Processing Traps and Register Windows::
-* 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 Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing
-@end ifinfo
-@section Introduction
-
-Different types of processors respond to the
-occurrence of an interrupt in its own unique fashion. In
-addition, each processor type provides a control mechanism to
-allow for the proper handling of an interrupt.  The processor
-dependent response to the interrupt modifies the current
-execution state and results in a change in the execution stream.
-Most processors require that an interrupt handler utilize some
-special 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 SPARC's
-interrupt response and control mechanisms as they pertain to
-RTEMS.
-
-RTEMS and associated documentation uses the terms
-interrupt and vector.  In the SPARC architecture, these terms
-correspond to traps and trap type, respectively.  The terms will
-be used interchangeably in this manual.
-
-@ifinfo
-@node Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
-@end ifinfo
-@section Synchronous Versus Asynchronous Traps
-
-The SPARC architecture includes two classes of traps:
-synchronous and asynchronous.  Asynchronous traps occur when an
-external event interrupts the processor.  These traps are not
-associated with any instruction executed by the processor and
-logically occur between instructions.  The instruction currently
-in the execute stage of the processor is allowed to complete
-although subsequent instructions are annulled.  The return
-address reported by the processor for asynchronous traps is the
-pair of instructions following the current instruction.
-
-Synchronous traps are caused by the actions of an
-instruction.  The trap stimulus in this case either occurs
-internally to the processor or is from an external signal that
-was provoked by the instruction.  These traps are taken
-immediately and the instruction that caused the trap is aborted
-before any state changes occur in the processor itself.   The
-return address reported by the processor for synchronous traps
-is the instruction which caused the trap and the following
-instruction.
-
-@ifinfo
-@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing
-@end ifinfo
-@section Vectoring of Interrupt Handler
-
-Upon receipt of an interrupt the SPARC automatically
-performs the following actions:
-
-@itemize @bullet
-@item disables traps (sets the ET bit of the psr to 0),
-
-@item the S bit of the psr is copied into the Previous
-Supervisor Mode (PS) bit of the psr,
-
-@item the cwp is decremented by one (modulo the number of
-register windows) to activate a trap window,
-
-@item the PC and nPC are loaded into local register 1 and 2
-(l0 and l1),
-
-@item the trap type (tt) field of the Trap Base Register (TBR)
-is set to the appropriate value, and
-
-@item if the trap is not a reset, then the PC is written with
-the contents of the TBR and the nPC is written with TBR + 4.  If
-the trap is a reset, then the PC is set to zero and the nPC is
-set to 4.
-@end itemize
-
-Trap processing on the SPARC has two features which
-are noticeably different than interrupt processing on other
-architectures.  First, the value of psr register in effect
-immediately before the trap occurred is not explicitly saved.
-Instead only reversible alterations are made to it.  Second, the
-Processor Interrupt Level (pil) is not set to correspond to that
-of the interrupt being processed.  When a trap occurs, ALL
-subsequent traps are disabled.  In order to safely invoke a
-subroutine during trap handling, traps must be enabled to allow
-for the possibility of register window overflow and underflow
-traps.
-
-If the interrupt handler was installed as an RTEMS
-interrupt handler, then upon receipt of the interrupt, the
-processor passes control to the RTEMS interrupt handler which
-performs the following actions:
-
-@itemize @bullet
-@item saves the state of the interrupted task on it's stack,
-
-@item insures that a register window is available for
-subsequent traps,
-
-@item if this is the outermost (i.e. non-nested) interrupt,
-then the RTEMS interrupt handler switches from the current stack
-to the interrupt stack,
-
-@item enables traps,
-
-@item invokes the vectors to a user interrupt service routine (ISR).
-@end itemize
-
-Asynchronous interrupts are ignored while traps are
-disabled.  Synchronous traps which occur while traps are
-disabled result in the CPU being forced into an error mode.
-
-A nested interrupt is processed similarly with the
-exception that the current stack need not be switched to the
-interrupt stack.
-
-@ifinfo
-@node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
-@end ifinfo
-@section Traps and Register Windows
-
-One of the register windows must be reserved at all
-times for trap processing.  This is critical to the proper
-operation of the trap mechanism in the SPARC architecture.  It
-is the responsibility of the trap handler to insure that there
-is a register window available for a subsequent trap before
-re-enabling traps.  It is likely that any high level language
-routines invoked by the trap handler (such as a user-provided
-RTEMS interrupt handler) will allocate a new register window.
-The save operation could result in a window overflow trap.  This
-trap cannot be correctly processed unless (1) traps are enabled
-and (2) a register window is reserved for traps.  Thus, the
-RTEMS interrupt handler insures that a register window is
-available for subsequent traps before enabling traps and
-invoking the user's interrupt handler.
-
-@ifinfo
-@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing
-@end ifinfo
-@section Interrupt Levels
-
-Sixteen levels (0-15) of interrupt priorities are
-supported by the SPARC architecture with level fifteen (15)
-being the highest priority.  Level zero (0) indicates that
-interrupts are fully enabled.  Interrupt requests for interrupts
-with priorities less than or equal to the current interrupt mask
-level are ignored.
-
-Although RTEMS supports 256 interrupt levels, the
-SPARC only supports sixteen.  RTEMS interrupt levels 0 through
-15 directly correspond to SPARC processor interrupt levels.  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 to level seven (15)
-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 ERC32 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 is hand calculated.  This
-calculation was last performed for Release 
-RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
-
-[NOTE: It is thought that the length of time at which
-the processor interrupt level is elevated to fifteen by RTEMS is
-not anywhere near as long as the length of time ALL traps are
-disabled as part of the "flush all register windows" operation.]
-
-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 SPARC architecture does not provide for a
-dedicated interrupt stack.  Thus by default, trap handlers would
-execute on the stack of the RTEMS task which they interrupted.
-This artificially inflates the stack requirements for each task
-since EVERY task stack would have to include enough space to
-account for the worst case interrupt stack requirements in
-addition to it's own worst case usage.  RTEMS addresses this
-problem on the SPARC by providing a dedicated interrupt stack
-managed by software.
-
-During system initialization, RTEMS allocates the
-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.  As
-part of processing a non-nested interrupt, RTEMS will switch to
-the interrupt stack before invoking the installed handler.
-
diff --git a/doc/supplements/sparc/timedata.t b/doc/supplements/sparc/timedata.t
deleted file mode 100644
index 0fcbc748c9..0000000000
--- a/doc/supplements/sparc/timedata.t
+++ /dev/null
@@ -1,164 +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 ERC32 Timing Data, ERC32 Timing Data Introduction, Timing Specification Terminology, Top
-@end ifinfo
-@chapter ERC32 Timing Data
-@ifinfo
-@menu
-* ERC32 Timing Data Introduction::
-* ERC32 Timing Data Hardware Platform::
-* ERC32 Timing Data Interrupt Latency::
-* ERC32 Timing Data Context Switch::
-* ERC32 Timing Data Directive Times::
-* ERC32 Timing Data Task Manager::
-* ERC32 Timing Data Interrupt Manager::
-* ERC32 Timing Data Clock Manager::
-* ERC32 Timing Data Timer Manager::
-* ERC32 Timing Data Semaphore Manager::
-* ERC32 Timing Data Message Manager::
-* ERC32 Timing Data Event Manager::
-* ERC32 Timing Data Signal Manager::
-* ERC32 Timing Data Partition Manager::
-* ERC32 Timing Data Region Manager::
-* ERC32 Timing Data Dual-Ported Memory Manager::
-* ERC32 Timing Data I/O Manager::
-* ERC32 Timing Data Rate Monotonic Manager::
-@end menu
-@end ifinfo
-
-@ifinfo
-@node ERC32 Timing Data Introduction, ERC32 Timing Data Hardware Platform, ERC32 Timing Data, ERC32 Timing Data
-@end ifinfo
-@section Introduction
-
-The timing data for RTEMS on the ERC32 implementation
-of the SPARC architecture 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
-SPARC version of RTEMS.
-
-@ifinfo
-@node ERC32 Timing Data Hardware Platform, ERC32 Timing Data Interrupt Latency, ERC32 Timing Data Introduction, ERC32 Timing Data
-@end ifinfo
-@section Hardware Platform
-
-All times reported in this chapter were measured
-using the SPARC Instruction Simulator (SIS) developed by the
-European Space Agency.  SIS simulates the ERC32 -- a custom low
-power implementation combining the Cypress 90C601 integer unit,
-the Cypress 90C602 floating point unit, and a number of
-peripherals such as counter timers, interrupt controller and a
-memory controller.
-
-For the RTEMS tests, SIS is configured with the
-following characteristics:
-
-@itemize @bullet
-@item 15 Mhz clock speed
-
-@item 0 wait states for PROM accesses
-
-@item 0 wait states for RAM accesses
-@end itemize
-
-The ERC32's General Purpose Timer was used to gather
-all timing information.  This timer was programmed to operate
-with one microsecond accuracy.  All sources of hardware
-interrupts were disabled, although traps were enabled and the
-interrupt level of the SPARC allows all interrupts.
-
-@ifinfo
-@node ERC32 Timing Data Interrupt Latency, ERC32 Timing Data Context Switch, ERC32 Timing Data Hardware Platform, ERC32 Timing Data
-@end ifinfo
-@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
-ERC32 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 SIS.  The maximum
-period with interrupts disabled with RTEMS occurs during a
-context switch when traps are disabled to flush all the register
-windows to memory.  The length of time spent flushing the
-register windows varies based on the number of windows which
-must be flushed.  Based on the information reported by SIS, it
-takes from 4.0 to 18.0 microseconds (37 to 122 instructions) to
-flush the register windows.  It takes approximately 41 CPU
-cycles (2.73 microseconds) to flush each register window set to
-memory.  The register window flush operation is heavily memory
-bound.
-
-[NOTE: All traps are disabled during the register
-window flush thus disabling both software generate traps and
-external interrupts.  During a normal RTEMS critical section,
-the processor interrupt level (pil) is raised to level 15 and
-traps are left enabled.  The longest path for a normal critical
-section within RTEMS is less than 50 instructions.]
-
-The interrupt vector and entry overhead time was
-generated on the SIS benchmark platform using the ERC32's
-ability to forcibly generate an arbitrary interrupt as the
-source of the "benchmark" interrupt.
-
-@ifinfo
-@node ERC32 Timing Data Context Switch, RTEMS_CPU_MODEL Timing Data Directive Times, ERC32 Timing Data Interrupt Latency, ERC32 Timing Data
-@end ifinfo
-@section Context Switch
-
-The RTEMS processor context switch time is 10
-microseconds on the SIS 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 ERC32 benchmark platform:
-
-@include timetbl.texi
-
-@tex
-\global\advance \smallskipamount by 4pt
-@end tex
-
-