From 17c26806a46ff3e468f4a8fae2483478452a4cd8 Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Mon, 19 Oct 1998 19:46:30 +0000 Subject: Renamed. --- doc/supplements/sparc/SIS_TIMES | 247 --------------------------------------- doc/supplements/sparc/intr.t | 234 ------------------------------------- doc/supplements/sparc/timedata.t | 164 -------------------------- 3 files changed, 645 deletions(-) delete mode 100644 doc/supplements/sparc/SIS_TIMES delete mode 100644 doc/supplements/sparc/intr.t delete mode 100644 doc/supplements/sparc/timedata.t (limited to 'doc/supplements') 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 - - -- cgit v1.2.3