source: rtems/doc/supplements/powerpc/intr.t @ 563f7e0

4.104.114.84.95
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
Line 
1@c
2@c  COPYRIGHT (c) 1988-1997.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
5@c
6@c  $Id$
7@c
8
9@ifinfo
10@node Interrupt Processing, Interrupt Processing Introduction, Memory Model Flat Memory Model, Top
11@end ifinfo
12@chapter Interrupt Processing
13@ifinfo
14@menu
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
24
25@ifinfo
26@node Interrupt Processing Introduction, Interrupt Processing Synchronous Versus Asynchronous Traps, Interrupt Processing, Interrupt Processing
27@end ifinfo
28@section Introduction
29
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
43RTEMS.
44
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.
49
50@ifinfo
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
54
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.
64
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
73instruction.
74
75@ifinfo
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
79
80Upon receipt of an interrupt the SPARC automatically
81performs the following actions:
82
83@itemize @bullet
84@item disables traps (sets the ET bit of the psr to 0),
85
86@item the S bit of the psr is copied into the Previous
87Supervisor Mode (PS) bit of the psr,
88
89@item the cwp is decremented by one (modulo the number of
90register windows) to activate a trap window,
91
92@item the PC and nPC are loaded into local register 1 and 2
93(l0 and l1),
94
95@item the trap type (tt) field of the Trap Base Register (TBR)
96is set to the appropriate value, and
97
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
103
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
114traps.
115
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:
120
121@itemize @bullet
122@item saves the state of the interrupted task on it's stack,
123
124@item insures that a register window is available for
125subsequent traps,
126
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,
130
131@item enables traps,
132
133@item invokes the vectors to a user interrupt service routine (ISR).
134@end itemize
135
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.
139
140A nested interrupt is processed similarly with the
141exception that the current stack need not be switched to the
142interrupt stack.
143
144@ifinfo
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
148
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.
163
164@ifinfo
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
168
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.
175
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
180unpredictable.
181
182@ifinfo
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
186
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
193RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
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
199RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
200
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.]
205
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.
212
213@ifinfo
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
217
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.
227
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.
234
Note: See TracBrowser for help on using the repository browser.