From 83fb86f32b73942be758c22423c0bfe506fd4ff6 Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Wed, 23 Aug 2006 19:11:14 +0000 Subject: 2006-08-23 Joel Sherrill * Makefile.am, configure.ac, FAQ/stamp-vti, FAQ/version.texi, common/cpright.texi: Merging CPU Supplements into a single document. As part of this removed the obsolete and impossible to maintain size and timing information. * cpu_supplement/.cvsignore, cpu_supplement/Makefile.am, cpu_supplement/arm.t, cpu_supplement/i386.t, cpu_supplement/m68k.t, cpu_supplement/mips.t, cpu_supplement/powerpc.t, cpu_supplement/preface.texi, cpu_supplement/sh.t, cpu_supplement/sparc.t, cpu_supplement/tic4x.t: New files. * supplements/.cvsignore, supplements/Makefile.am, supplements/supplement.am, supplements/arm/.cvsignore, supplements/arm/BSP_TIMES, supplements/arm/ChangeLog, supplements/arm/Makefile.am, supplements/arm/arm.texi, supplements/arm/bsp.t, supplements/arm/callconv.t, supplements/arm/cpumodel.t, supplements/arm/cputable.t, supplements/arm/fatalerr.t, supplements/arm/intr_NOTIMES.t, supplements/arm/memmodel.t, supplements/arm/preface.texi, supplements/arm/timeBSP.t, supplements/c4x/.cvsignore, supplements/c4x/BSP_TIMES, supplements/c4x/ChangeLog, supplements/c4x/Makefile.am, supplements/c4x/bsp.t, supplements/c4x/c4x.texi, supplements/c4x/callconv.t, supplements/c4x/cpumodel.t, supplements/c4x/cputable.t, supplements/c4x/fatalerr.t, supplements/c4x/intr_NOTIMES.t, supplements/c4x/memmodel.t, supplements/c4x/preface.texi, supplements/c4x/timeBSP.t, supplements/i386/.cvsignore, supplements/i386/ChangeLog, supplements/i386/FORCE386_TIMES, supplements/i386/Makefile.am, supplements/i386/bsp.t, supplements/i386/callconv.t, supplements/i386/cpumodel.t, supplements/i386/cputable.t, supplements/i386/fatalerr.t, supplements/i386/i386.texi, supplements/i386/intr_NOTIMES.t, supplements/i386/memmodel.t, supplements/i386/preface.texi, supplements/i386/timeFORCE386.t, supplements/m68k/.cvsignore, supplements/m68k/ChangeLog, supplements/m68k/MVME136_TIMES, supplements/m68k/Makefile.am, supplements/m68k/bsp.t, supplements/m68k/callconv.t, supplements/m68k/cpumodel.t, supplements/m68k/cputable.t, supplements/m68k/fatalerr.t, supplements/m68k/intr_NOTIMES.t, supplements/m68k/m68k.texi, supplements/m68k/memmodel.t, supplements/m68k/preface.texi, supplements/m68k/timeMVME136.t, supplements/m68k/timedata.t, supplements/mips/.cvsignore, supplements/mips/BSP_TIMES, supplements/mips/ChangeLog, supplements/mips/Makefile.am, supplements/mips/bsp.t, supplements/mips/callconv.t, supplements/mips/cpumodel.t, supplements/mips/cputable.t, supplements/mips/fatalerr.t, supplements/mips/intr_NOTIMES.t, supplements/mips/memmodel.t, supplements/mips/mips.texi, supplements/mips/preface.texi, supplements/mips/timeBSP.t, supplements/powerpc/.cvsignore, supplements/powerpc/ChangeLog, supplements/powerpc/DMV177_TIMES, supplements/powerpc/Makefile.am, supplements/powerpc/PSIM_TIMES, supplements/powerpc/bsp.t, supplements/powerpc/callconv.t, supplements/powerpc/cpumodel.t, supplements/powerpc/cputable.t, supplements/powerpc/fatalerr.t, supplements/powerpc/intr_NOTIMES.t, supplements/powerpc/memmodel.t, supplements/powerpc/powerpc.texi, supplements/powerpc/preface.texi, supplements/powerpc/timeDMV177.t, supplements/powerpc/timePSIM.t, supplements/sh/.cvsignore, supplements/sh/BSP_TIMES, supplements/sh/ChangeLog, supplements/sh/Makefile.am, supplements/sh/bsp.t, supplements/sh/callconv.t, supplements/sh/cpumodel.t, supplements/sh/cputable.t, supplements/sh/fatalerr.t, supplements/sh/intr_NOTIMES.t, supplements/sh/memmodel.t, supplements/sh/preface.texi, supplements/sh/sh.texi, supplements/sh/timeBSP.t, supplements/sparc/.cvsignore, supplements/sparc/ChangeLog, supplements/sparc/ERC32_TIMES, supplements/sparc/Makefile.am, supplements/sparc/bsp.t, supplements/sparc/callconv.t, supplements/sparc/cpumodel.t, supplements/sparc/cputable.t, supplements/sparc/fatalerr.t, supplements/sparc/intr_NOTIMES.t, supplements/sparc/memmodel.t, supplements/sparc/preface.texi, supplements/sparc/sparc.texi, supplements/sparc/timeERC32.t, supplements/template/.cvsignore, supplements/template/BSP_TIMES, supplements/template/ChangeLog, supplements/template/Makefile.am, supplements/template/bsp.t, supplements/template/callconv.t, supplements/template/cpumodel.t, supplements/template/cputable.t, supplements/template/fatalerr.t, supplements/template/intr_NOTIMES.t, supplements/template/memmodel.t, supplements/template/preface.texi, supplements/template/template.texi, supplements/template/timeBSP.t: Removed. --- doc/supplements/sparc/intr_NOTIMES.t | 199 ----------------------------------- 1 file changed, 199 deletions(-) delete mode 100644 doc/supplements/sparc/intr_NOTIMES.t (limited to 'doc/supplements/sparc/intr_NOTIMES.t') diff --git a/doc/supplements/sparc/intr_NOTIMES.t b/doc/supplements/sparc/intr_NOTIMES.t deleted file mode 100644 index a66ccc981d..0000000000 --- a/doc/supplements/sparc/intr_NOTIMES.t +++ /dev/null @@ -1,199 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Interrupt Processing - -@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. - -@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. - -@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. - -@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. - -@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. - -@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. - -@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. - -- cgit v1.2.3