source: rtems/doc/supplements/powerpc/intr.t @ 563f7e0
Last change on this file since 563f7e0 was 563f7e0, checked in by Joel Sherrill <joel.sherrill@…>, on Jul 1, 1997 at 6:39:44 PM

New files -- PowerPC supplement is based on the SPARC supplement.
This version has had some initial work done to convert it to
be PowerPC specific.

  • Property mode set to 100644
File size: 9.9 KB
2@c  COPYRIGHT (c) 1988-1997.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
6@c  $Id$
10@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top
11@end ifinfo
12@chapter Interrupt Processing
15* Interrupt Processing Introduction::
16* Interrupt Processing Synchronous Versus Asynchronous Traps::
17* Interrupt Processing Vectoring of Interrupt Handler::
18* Interrupt Processing Traps and Register Windows::
19* Interrupt Processing Interrupt Levels::
20* Interrupt Processing Disabling of Interrupts by RTEMS::
21* Interrupt Processing Interrupt Stack::
22@end menu
23@end ifinfo
26@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing
27@end ifinfo
28@section Introduction
30Different types of processors respond to the
31occurrence of an interrupt in its own unique fashion. In
32addition, each processor type provides a control mechanism to
33allow for the proper handling of an interrupt.  The processor
34dependent response to the interrupt modifies the current
35execution state and results in a change in the execution stream.
36Most processors require that an interrupt handler utilize some
37special control mechanisms to return to the normal processing
38stream.  Although RTEMS hides many of the processor dependent
39details of interrupt processing, it is important to understand
40how the RTEMS interrupt manager is mapped onto the processor's
41unique architecture. Discussed in this chapter are the SPARC's
42interrupt response and control mechanisms as they pertain to
45RTEMS and associated documentation uses the terms
46interrupt and vector.  In the SPARC architecture, these terms
47correspond to traps and trap type, respectively.  The terms will
48be used interchangeably in this manual.
51@node Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Introduction, Interrupt Processing
52@end ifinfo
53@section Synchronous Versus Asynchronous Traps
55The SPARC architecture includes two classes of traps:
56synchronous and asynchronous.  Asynchronous traps occur when an
57external event interrupts the processor.  These traps are not
58associated with any instruction executed by the processor and
59logically occur between instructions.  The instruction currently
60in the execute stage of the processor is allowed to complete
61although subsequent instructions are annulled.  The return
62address reported by the processor for asynchronous traps is the
63pair of instructions following the current instruction.
65Synchronous traps are caused by the actions of an
66instruction.  The trap stimulus in this case either occurs
67internally to the processor or is from an external signal that
68was provoked by the instruction.  These traps are taken
69immediately and the instruction that caused the trap is aborted
70before any state changes occur in the processor itself.   The
71return address reported by the processor for synchronous traps
72is the instruction which caused the trap and the following
76@node Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing Traps and Register Windows, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing
77@end ifinfo
78@section Vectoring of Interrupt Handler
80Upon receipt of an interrupt the SPARC automatically
81performs the following actions:
83@itemize @bullet
84@item disables traps (sets the ET bit of the psr to 0),
86@item the S bit of the psr is copied into the Previous
87Supervisor Mode (PS) bit of the psr,
89@item the cwp is decremented by one (modulo the number of
90register windows) to activate a trap window,
92@item the PC and nPC are loaded into local register 1 and 2
93(l0 and l1),
95@item the trap type (tt) field of the Trap Base Register (TBR)
96is set to the appropriate value, and
98@item if the trap is not a reset, then the PC is written with
99the contents of the TBR and the nPC is written with TBR + 4.  If
100the trap is a reset, then the PC is set to zero and the nPC is
101set to 4.
102@end itemize
104Trap processing on the SPARC has two features which
105are noticeably different than interrupt processing on other
106architectures.  First, the value of psr register in effect
107immediately before the trap occurred is not explicitly saved.
108Instead only reversible alterations are made to it.  Second, the
109Processor Interrupt Level (pil) is not set to correspond to that
110of the interrupt being processed.  When a trap occurs, ALL
111subsequent traps are disabled.  In order to safely invoke a
112subroutine during trap handling, traps must be enabled to allow
113for the possibility of register window overflow and underflow
116If the interrupt handler was installed as an RTEMS
117interrupt handler, then upon receipt of the interrupt, the
118processor passes control to the RTEMS interrupt handler which
119performs the following actions:
121@itemize @bullet
122@item saves the state of the interrupted task on it's stack,
124@item insures that a register window is available for
125subsequent traps,
127@item if this is the outermost (i.e. non-nested) interrupt,
128then the RTEMS interrupt handler switches from the current stack
129to the interrupt stack,
131@item enables traps,
133@item invokes the vectors to a user interrupt service routine (ISR).
134@end itemize
136Asynchronous interrupts are ignored while traps are
137disabled.  Synchronous traps which occur while traps are
138disabled result in the CPU being forced into an error mode.
140A nested interrupt is processed similarly with the
141exception that the current stack need not be switched to the
142interrupt stack.
145@node Interrupt Processing Traps and Register Windows, Interrupt Processing Interrupt Levels, Interrupt Processing Vectoring of Interrupt Handler, Interrupt Processing
146@end ifinfo
147@section Traps and Register Windows
149One of the register windows must be reserved at all
150times for trap processing.  This is critical to the proper
151operation of the trap mechanism in the SPARC architecture.  It
152is the responsibility of the trap handler to insure that there
153is a register window available for a subsequent trap before
154re-enabling traps.  It is likely that any high level language
155routines invoked by the trap handler (such as a user-provided
156RTEMS interrupt handler) will allocate a new register window.
157The save operation could result in a window overflow trap.  This
158trap cannot be correctly processed unless (1) traps are enabled
159and (2) a register window is reserved for traps.  Thus, the
160RTEMS interrupt handler insures that a register window is
161available for subsequent traps before enabling traps and
162invoking the user's interrupt handler.
165@node Interrupt Processing Interrupt Levels, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Traps and Register Windows, Interrupt Processing
166@end ifinfo
167@section Interrupt Levels
169Sixteen levels (0-15) of interrupt priorities are
170supported by the SPARC architecture with level fifteen (15)
171being the highest priority.  Level zero (0) indicates that
172interrupts are fully enabled.  Interrupt requests for interrupts
173with priorities less than or equal to the current interrupt mask
174level are ignored.
176Although RTEMS supports 256 interrupt levels, the
177SPARC only supports sixteen.  RTEMS interrupt levels 0 through
17815 directly correspond to SPARC processor interrupt levels.  All
179other RTEMS interrupt levels are undefined and their behavior is
183@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
184@end ifinfo
185@section Disabling of Interrupts by RTEMS
187During the execution of directive calls, critical
188sections of code may be executed.  When these sections are
189encountered, RTEMS disables interrupts to level seven (15)
190before the execution of this section and restores them to the
191previous level upon completion of the section.  RTEMS has been
192optimized to insure that interrupts are disabled for less than
194Mhz PowerPC 603e with zero wait states.
195These numbers will vary based the number of wait states and
196processor speed present on the target board.
197[NOTE:  The maximum period with interrupts disabled is hand calculated.  This
198calculation was last performed for Release
201[NOTE: It is thought that the length of time at which
202the processor interrupt level is elevated to fifteen by RTEMS is
203not anywhere near as long as the length of time ALL traps are
204disabled as part of the "flush all register windows" operation.]
206Non-maskable interrupts (NMI) cannot be disabled, and
207ISRs which execute at this level MUST NEVER issue RTEMS system
208calls.  If a directive is invoked, unpredictable results may
209occur due to the inability of RTEMS to protect its critical
210sections.  However, ISRs that make no system calls may safely
211execute as non-maskable interrupts.
214@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing
215@end ifinfo
216@section Interrupt Stack
218The SPARC architecture does not provide for a
219dedicated interrupt stack.  Thus by default, trap handlers would
220execute on the stack of the RTEMS task which they interrupted.
221This artificially inflates the stack requirements for each task
222since EVERY task stack would have to include enough space to
223account for the worst case interrupt stack requirements in
224addition to it's own worst case usage.  RTEMS addresses this
225problem on the SPARC by providing a dedicated interrupt stack
226managed by software.
228During system initialization, RTEMS allocates the
229interrupt stack from the Workspace Area.  The amount of memory
230allocated for the interrupt stack is determined by the
231interrupt_stack_size field in the CPU Configuration Table.  As
232part of processing a non-nested interrupt, RTEMS will switch to
233the interrupt stack before invoking the installed handler.
Note: See TracBrowser for help on using the repository browser.