diff options
Diffstat (limited to 'doc/supplements/powerpc/intr.t')
| -rw-r--r-- | doc/supplements/powerpc/intr.t | 151 |
1 files changed, 57 insertions, 94 deletions
diff --git a/doc/supplements/powerpc/intr.t b/doc/supplements/powerpc/intr.t index 941cd1c2b7..1530dad5e4 100644 --- a/doc/supplements/powerpc/intr.t +++ b/doc/supplements/powerpc/intr.t @@ -13,9 +13,8 @@ @ifinfo @menu * Interrupt Processing Introduction:: -* Interrupt Processing Synchronous Versus Asynchronous Traps:: +* Interrupt Processing Synchronous Versus Asynchronous Exceptions:: * 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:: @@ -23,7 +22,7 @@ @end ifinfo @ifinfo -@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing +@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing, Interrupt Processing @end ifinfo @section Introduction @@ -38,80 +37,64 @@ 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 +unique architecture. Discussed in this chapter are the PPC'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 +interrupt and vector. In the PPC architecture, these terms +correspond to exception and exception handler, 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 +@node Interrupt Processing Synchronous Versus Asynchronous Exceptions, 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. +@section Synchronous Versus Asynchronous Exceptions + +In the PPC architecture exceptions can be either precise or +imprecise and either synchronous or asynchronous. Asynchronous +exceptions occur when an external event interrupts the processor. +Synchronous exceptions are caused by the actions of an +instruction. During an exception SRR0 is used to calculate where +instruction processing should resume. All instructions prior to +the resume instruction will have completed execution. SRR1 is used to +store the machine status. + +There are two asynchronous nonmaskable, highest-priority exceptions +system reset and machine check. There are two asynchrononous maskable +low-priority exceptions external interrupt and decrementer. Nonmaskable +execptions are never delayed, therefore if two nonmaskable, asynchronous +exceptions occur in immediate succession, the state information saved by +the first exception may be overwritten when the subsequent exception occurs. + +The PowerPC arcitecure defines one imprecise exception, the imprecise +floating point enabled exception. All other synchronous exceptions are +precise. The synchronization occuring during asynchronous precise +exceptions conforms to the requirements for context synchronization. @ifinfo -@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing +@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Interrupt Levels, Interrupt Processing Synchronous Versus Asynchronous Exceptions, Interrupt Processing @end ifinfo @section Vectoring of Interrupt Handler -Upon receipt of an interrupt the SPARC automatically +Upon determining that an exception can be taken the PPC automatically performs the following actions: @itemize @bullet -@item disables traps (sets the ET bit of the psr to 0), +@item an instruction address is loaded into SRR0 -@item the S bit of the psr is copied into the Previous -Supervisor Mode (PS) bit of the psr, +@item bits 33-36 and 42-47 of SRR1 are loaded with information +specific to the exception. -@item the cwp is decremented by one (modulo the number of -register windows) to activate a trap window, +@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding +bits from the MSR. -@item the PC and nPC are loaded into local register 1 and 2 -(l0 and l1), +@item the MSR is set based upon the exception type. -@item the trap type (tt) field of the Trap Base Register (TBR) -is set to the appropriate value, and +@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type. -@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 @@ -122,19 +105,19 @@ performs the following actions: @item saves the state of the interrupted task on it's stack, @item insures that a register window is available for -subsequent traps, +subsequent exceptions, @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 enables exceptions, @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 +Asynchronous interrupts are ignored while exceptions are +disabled. Synchronous interrupts which occur while are disabled result in the CPU being forced into an error mode. A nested interrupt is processed similarly with the @@ -142,41 +125,19 @@ 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 +@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing @end ifinfo @section Interrupt Levels -Sixteen levels (0-15) of interrupt priorities are -supported by the SPARC architecture with level fifteen (15) +TBD levels (0-TBD) of interrupt priorities are +supported by the PowerPC architecture with level TBD (TBD) 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 +TBD +All other RTEMS interrupt levels are undefined and their behavior is unpredictable. @ifinfo @@ -186,21 +147,21 @@ unpredictable. 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) +encountered, RTEMS disables interrupts to level TBD (TBD) 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 PowerPC 603e with zero wait states. -These numbers will vary based the number of wait states and -processor speed present on the target board. +RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a +RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz PowerPC 603e 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 +not anywhere near as long as the length of time ALL exceptions are disabled as part of the "flush all register windows" operation.] Non-maskable interrupts (NMI) cannot be disabled, and @@ -215,14 +176,14 @@ execute as non-maskable interrupts. @end ifinfo @section Interrupt Stack -The SPARC architecture does not provide for a -dedicated interrupt stack. Thus by default, trap handlers would +The PowerPC architecture does not provide for a +dedicated interrupt stack. Thus by default, exception 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 +problem on the PowerPC by providing a dedicated interrupt stack managed by software. During system initialization, RTEMS allocates the @@ -232,3 +193,5 @@ 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. + + |