source: rtems/doc/cpu_supplement/sparc.t @ dff1803

Last change on this file since dff1803 was dff1803, checked in by Daniel Hellstrom <daniel@…>, on Dec 3, 2014 at 10:35:52 AM

SPARC: optimize IRQ enable & disable

  • Coding style cleanups.
  • Use OS reserved trap 0x89 for IRQ Disable
  • Use OS reserved trap 0x8A for IRQ Enable
  • Add to SPARC CPU supplement documentation

This will result in faster Disable/Enable? code since the
system trap handler does not need to decode which function
the user wants. Besides the IRQ disable/enabled can now
be inline which avoids the caller to take into account that
o0-o7+g1-g4 registers are destroyed by trap handler.

It was also possible to reduce the interrupt trap handler by
five instructions due to this.

  • Property mode set to 100644
File size: 39.9 KB
2@c  COPYRIGHT (c) 1988-2002.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
7@end ifinfo
8@chapter SPARC Specific Information
10The Real Time Executive for Multiprocessor Systems
11(RTEMS) is designed to be portable across multiple processor
12architectures.  However, the nature of real-time systems makes
13it essential that the application designer understand certain
14processor dependent implementation details.  These processor
15dependencies include calling convention, board support package
16issues, interrupt processing, exact RTEMS memory requirements,
17performance data, header files, and the assembly language
18interface to the executive.
20This document discusses the SPARC architecture dependencies in this
21port of RTEMS.  This architectural port is for SPARC Version 7 and
228. Implementations for SPARC V9 are in the sparc64 target.
24It is highly recommended that the SPARC RTEMS
25application developer obtain and become familiar with the
26documentation for the processor being used as well as the
27specification for the revision of the SPARC architecture which
28corresponds to that processor.
30@subheading SPARC Architecture Documents
32For information on the SPARC architecture, refer to
33the following documents available from SPARC International, Inc.
36@itemize @bullet
37@item SPARC Standard Version 7.
39@item SPARC Standard Version 8.
40@end itemize
42@subheading ERC32 Specific Information
44The European Space Agency's ERC32 is a three chip
45computing core implementing a SPARC V7 processor and associated
46support circuitry for embedded space applications. The integer
47and floating-point units (90C601E & 90C602E) are based on the
48Cypress 7C601 and 7C602, with additional error-detection and
49recovery functions. The memory controller (MEC) implements
50system support functions such as address decoding, memory
51interface, DMA interface, UARTs, timers, interrupt control,
52write-protection, memory reconfiguration and error-detection.
53The core is designed to work at 25MHz, but using space qualified
54memories limits the system frequency to around 15 MHz, resulting
55in a performance of 10 MIPS and 2 MFLOPS.
57Information on the ERC32 and a number of development
58support tools, such as the SPARC Instruction Simulator (SIS),
59are freely available on the Internet.  The following documents
60and SIS are available via anonymous ftp or pointing your web
61browser at
63@itemize @bullet
64@item ERC32 System Design Document
66@item MEC Device Specification
67@end itemize
69Additionally, the SPARC RISC User's Guide from Matra
70MHS documents the functionality of the integer and floating
71point units including the instruction set information.  To
72obtain this document as well as ERC32 components and VHDL models
76Matra MHS SA
773 Avenue du Centre, BP 309,
7878054 St-Quentin-en-Yvelines,
79Cedex, France
80VOICE: +31-1-30607087
81FAX: +31-1-30640693
82@end example
84Amar Guennon ( is familiar with the ERC32.
87@c  COPYRIGHT (c) 1988-2002.
88@c  On-Line Applications Research Corporation (OAR).
89@c  All rights reserved.
91@section CPU Model Dependent Features
94Microprocessors are generally classified into
95families with a variety of CPU models or implementations within
96that family.  Within a processor family, there is a high level
97of binary compatibility.  This family may be based on either an
98architectural specification or on maintaining compatibility with
99a popular processor.  Recent microprocessor families such as the
100SPARC or PowerPC are based on an architectural specification
101which is independent or any particular CPU model or
102implementation.  Older families such as the M68xxx and the iX86
103evolved as the manufacturer strived to produce higher
104performance processor models which maintained binary
105compatibility with older models.
107RTEMS takes advantage of the similarity of the
108various models within a CPU family.  Although the models do vary
109in significant ways, the high level of compatibility makes it
110possible to share the bulk of the CPU dependent executive code
111across the entire family.
113@subsection CPU Model Feature Flags
115Each processor family supported by RTEMS has a
116list of features which vary between CPU models
117within a family.  For example, the most common model dependent
118feature regardless of CPU family is the presence or absence of a
119floating point unit or coprocessor.  When defining the list of
120features present on a particular CPU model, one simply notes
121that floating point hardware is or is not present and defines a
122single constant appropriately.  Conditional compilation is
123utilized to include the appropriate source code for this CPU
124model's feature set.  It is important to note that this means
125that RTEMS is thus compiled using the appropriate feature set
126and compilation flags optimal for this CPU model used.  The
127alternative would be to generate a binary which would execute on
128all family members using only the features which were always
131This section presents the set of features which vary
132across SPARC implementations and are of importance to RTEMS.
133The set of CPU model feature macros are defined in the file
134cpukit/score/cpu/sparc/sparc.h based upon the particular CPU
135model defined on the compilation command line.
137@subsubsection CPU Model Name
139The macro CPU_MODEL_NAME is a string which designates
140the name of this CPU model.  For example, for the European Space
141Agency's ERC32 SPARC model, this macro is set to the string
144@subsubsection Floating Point Unit
146The macro SPARC_HAS_FPU is set to 1 to indicate that
147this CPU model has a hardware floating point unit and 0
150@subsubsection Bitscan Instruction
152The macro SPARC_HAS_BITSCAN is set to 1 to indicate
153that this CPU model has the bitscan instruction.  For example,
154this instruction is supported by the Fujitsu SPARClite family.
156@subsubsection Number of Register Windows
159indicate the number of register window sets implemented by this
160CPU model.  The SPARC architecture allows a for a maximum of
161thirty-two register window sets although most implementations
162only include eight.
164@subsubsection Low Power Mode
166The macro SPARC_HAS_LOW_POWER_MODE is set to one to
167indicate that this CPU model has a low power mode.  If low power
168is enabled, then there must be CPU model specific implementation
169of the IDLE task in cpukit/score/cpu/sparc/cpu.c.  The low
170power mode IDLE task should be of the form:
173while ( TRUE ) @{
174  enter low power mode
176@end example
178The code required to enter low power mode is CPU model specific.
180@subsection CPU Model Implementation Notes
182The ERC32 is a custom SPARC V7 implementation based on the Cypress 601/602
183chipset.  This CPU has a number of on-board peripherals and was developed by
184the European Space Agency to target space applications.  RTEMS currently
185provides support for the following peripherals:
187@itemize @bullet
188@item UART Channels A and B
189@item General Purpose Timer
190@item Real Time Clock
191@item Watchdog Timer (so it can be disabled)
192@item Control Register (so powerdown mode can be enabled)
193@item Memory Control Register
194@item Interrupt Control
195@end itemize
197The General Purpose Timer and Real Time Clock Timer provided with the ERC32
198share the Timer Control Register.  Because the Timer Control Register is write
199only, we must mirror it in software and insure that writes to one timer do not
200alter the current settings and status of the other timer.  Routines are
201provided in erc32.h which promote the view that the two timers are completely
202independent.  By exclusively using these routines to access the Timer Control
203Register, the application can view the system as having a General Purpose
204Timer Control Register and a Real Time Clock Timer Control Register
205rather than the single shared value.
207The RTEMS Idle thread take advantage of the low power mode provided by the
208ERC32.  Low power mode is entered during idle loops and is enabled at
209initialization time.
211@c  COPYRIGHT (c) 1988-2002.
212@c  On-Line Applications Research Corporation (OAR).
213@c  All rights reserved.
215@section Calling Conventions
217Each high-level language compiler generates subroutine entry and exit code
218based upon a set of rules known as the application binary interface (ABI)
219calling convention.   These rules address the following issues:
221@itemize @bullet
222@item register preservation and usage
224@item parameter passing
226@item call and return mechanism
227@end itemize
229An ABI calling convention is of importance when interfacing to subroutines
230written in another language either assembly or high-level.  It determines also
231the set of registers to be saved or restored during a context switch and
232interrupt processing.
234The ABI relevant for RTEMS on SPARC is defined by SYSTEM V APPLICATION BINARY
235INTERFACE, SPARC Processor Supplement, Third Edition.
237@subsection Programming Model
239This section discusses the programming model for the
240SPARC architecture.
242@subsubsection Non-Floating Point Registers
244The SPARC architecture defines thirty-two
245non-floating point registers directly visible to the programmer.
246These are divided into four sets:
248@itemize @bullet
249@item input registers
251@item local registers
253@item output registers
255@item global registers
256@end itemize
258Each register is referred to by either two or three
259names in the SPARC reference manuals.  First, the registers are
260referred to as r0 through r31 or with the alternate notation
261r[0] through r[31].  Second, each register is a member of one of
262the four sets listed above.  Finally, some registers have an
263architecturally defined role in the programming model which
264provides an alternate name.  The following table describes the
265mapping between the 32 registers and the register sets:
267@ifset use-ascii
270     +-----------------+----------------+------------------+
271     | Register Number | Register Names |   Description    |
272     +-----------------+----------------+------------------+
273     |     0 - 7       |    g0 - g7     | Global Registers |
274     +-----------------+----------------+------------------+
275     |     8 - 15      |    o0 - o7     | Output Registers |
276     +-----------------+----------------+------------------+
277     |    16 - 23      |    l0 - l7     | Local Registers  |
278     +-----------------+----------------+------------------+
279     |    24 - 31      |    i0 - i7     | Input Registers  |
280     +-----------------+----------------+------------------+
281@end group
282@end example
283@end ifset
285@ifset use-tex
286@sp 1
290\hbox to 1.75in{\enskip\hfil#\hfil}&
292\hbox to 1.75in{\enskip\hfil#\hfil}&
294\hbox to 1.75in{\enskip\hfil#\hfil}&
297&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule}
298&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule}
299&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule}
300&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule}
301&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule}
303@end tex
304@end ifset
306@ifset use-html
309  <TABLE COLS=3 WIDTH="80%" BORDER=2>
310<TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD>
311    <TD ALIGN=center><STRONG>Register Names</STRONG></TD>
312    <TD ALIGN=center><STRONG>Description</STRONG></TD>
313<TR><TD ALIGN=center>0 - 7</TD>
314    <TD ALIGN=center>g0 - g7</TD>
315    <TD ALIGN=center>Global Registers</TD></TR>
316<TR><TD ALIGN=center>8 - 15</TD>
317    <TD ALIGN=center>o0 - o7</TD>
318    <TD ALIGN=center>Output Registers</TD></TR>
319<TR><TD ALIGN=center>16 - 23</TD>
320    <TD ALIGN=center>l0 - l7</TD>
321    <TD ALIGN=center>Local Registers</TD></TR>
322<TR><TD ALIGN=center>24 - 31</TD>
323    <TD ALIGN=center>i0 - i7</TD>
324    <TD ALIGN=center>Input Registers</TD></TR>
325  </TABLE>
327@end html
328@end ifset
330As mentioned above, some of the registers serve
331defined roles in the programming model.  The following table
332describes the role of each of these registers:
334@ifset use-ascii
337     +---------------+----------------+----------------------+
338     | Register Name | Alternate Name |      Description     |
339     +---------------+----------------+----------------------+
340     |     g0        |      na        |    reads return 0    |
341     |               |                |  writes are ignored  |
342     +---------------+----------------+----------------------+
343     |     o6        |      sp        |     stack pointer    |
344     +---------------+----------------+----------------------+
345     |     i6        |      fp        |     frame pointer    |
346     +---------------+----------------+----------------------+
347     |     i7        |      na        |    return address    |
348     +---------------+----------------+----------------------+
349@end group
350@end example
351@end ifset
353@ifset use-tex
354@sp 1
358\hbox to 1.75in{\enskip\hfil#\hfil}&
360\hbox to 1.75in{\enskip\hfil#\hfil}&
362\hbox to 1.75in{\enskip\hfil#\hfil}&
365&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule}
366&g0&&NA&&reads return 0; &\cr
367&&&&&writes are ignored&\cr\noalign{\hrule}
368&o6&&sp&&stack pointer&\cr\noalign{\hrule}
369&i6&&fp&&frame pointer&\cr\noalign{\hrule}
370&i7&&NA&&return address&\cr\noalign{\hrule}
372@end tex
373@end ifset
375@ifset use-html
378  <TABLE COLS=3 WIDTH="80%" BORDER=2>
379<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD>
380    <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD>
381    <TD ALIGN=center><STRONG>Description</STRONG></TD></TR>
382<TR><TD ALIGN=center>g0</TD>
383    <TD ALIGN=center>NA</TD>
384    <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR>
385<TR><TD ALIGN=center>o6</TD>
386    <TD ALIGN=center>sp</TD>
387    <TD ALIGN=center>stack pointer</TD></TR>
388<TR><TD ALIGN=center>i6</TD>
389    <TD ALIGN=center>fp</TD>
390    <TD ALIGN=center>frame pointer</TD></TR>
391<TR><TD ALIGN=center>i7</TD>
392    <TD ALIGN=center>NA</TD>
393    <TD ALIGN=center>return address</TD></TR>
394  </TABLE>
396@end html
397@end ifset
399The registers g2 through g4 are reserved for applications.  GCC uses them as
400volatile registers by default.  So they are treated like volatile registers in
401RTEMS as well.
403The register g6 is reserved for the operating system and contains the address
404of the per-CPU control block of the current processor.  This register is
405initialized during system start and then remains unchanged.  It is not
406saved/restored by the context switch or interrupt processing code.
408The register g7 is reserved for the operating system and contains the thread
409pointer used for thread-local storage (TLS) as mandated by the SPARC ABI.
411@subsubsection Floating Point Registers
413The SPARC V7 architecture includes thirty-two,
414thirty-two bit registers.  These registers may be viewed as
417@itemize @bullet
418@item 32 single precision floating point or integer registers
419(f0, f1,  ... f31)
421@item 16 double precision floating point registers (f0, f2,
422f4, ... f30)
424@item 8 extended precision floating point registers (f0, f4,
425f8, ... f28)
426@end itemize
428The floating point status register (fpsr) specifies
429the behavior of the floating point unit for rounding, contains
430its condition codes, version specification, and trap information.
432A queue of the floating point instructions which have
433started execution but not yet completed is maintained.  This
434queue is needed to support the multiple cycle nature of floating
435point operations and to aid floating point exception trap
436handlers.  Once a floating point exception has been encountered,
437the queue is frozen until it is emptied by the trap handler.
438The floating point queue is loaded by launching instructions.
439It is emptied normally when the floating point completes all
440outstanding instructions and by floating point exception
441handlers with the store double floating point queue (stdfq)
444@subsubsection Special Registers
446The SPARC architecture includes two special registers
447which are critical to the programming model: the Processor State
448Register (psr) and the Window Invalid Mask (wim).  The psr
449contains the condition codes, processor interrupt level, trap
450enable bit, supervisor mode and previous supervisor mode bits,
451version information, floating point unit and coprocessor enable
452bits, and the current window pointer (cwp).  The cwp field of
453the psr and wim register are used to manage the register windows
454in the SPARC architecture.  The register windows are discussed
455in more detail below.
457@subsection Register Windows
459The SPARC architecture includes the concept of
460register windows.  An overly simplistic way to think of these
461windows is to imagine them as being an infinite supply of
462"fresh" register sets available for each subroutine to use.  In
463reality, they are much more complicated.
465The save instruction is used to obtain a new register
466window.  This instruction decrements the current window pointer,
467thus providing a new set of registers for use.  This register
468set includes eight fresh local registers for use exclusively by
469this subroutine.  When done with a register set, the restore
470instruction increments the current window pointer and the
471previous register set is once again available.
473The two primary issues complicating the use of
474register windows are that (1) the set of register windows is
475finite, and (2) some registers are shared between adjacent
476registers windows.
478Because the set of register windows is finite, it is
479possible to execute enough save instructions without
480corresponding restore's to consume all of the register windows.
481This is easily accomplished in a high level language because
482each subroutine typically performs a save instruction upon
483entry.  Thus having a subroutine call depth greater than the
484number of register windows will result in a window overflow
485condition.  The window overflow condition generates a trap which
486must be handled in software.  The window overflow trap handler
487is responsible for saving the contents of the oldest register
488window on the program stack.
490Similarly, the subroutines will eventually complete
491and begin to perform restore's.  If the restore results in the
492need for a register window which has previously been written to
493memory as part of an overflow, then a window underflow condition
494results.  Just like the window overflow, the window underflow
495condition must be handled in software by a trap handler.  The
496window underflow trap handler is responsible for reloading the
497contents of the register window requested by the restore
498instruction from the program stack.
500The Window Invalid Mask (wim) and the Current Window
501Pointer (cwp) field in the psr are used in conjunction to manage
502the finite set of register windows and detect the window
503overflow and underflow conditions.  The cwp contains the index
504of the register window currently in use.  The save instruction
505decrements the cwp modulo the number of register windows.
506Similarly, the restore instruction increments the cwp modulo the
507number of register windows.  Each bit in the  wim represents
508represents whether a register window contains valid information.
509The value of 0 indicates the register window is valid and 1
510indicates it is invalid.  When a save instruction causes the cwp
511to point to a register window which is marked as invalid, a
512window overflow condition results.  Conversely, the restore
513instruction may result in a window underflow condition.
515Other than the assumption that a register window is
516always available for trap (i.e. interrupt) handlers, the SPARC
517architecture places no limits on the number of register windows
518simultaneously marked as invalid (i.e. number of bits set in the
519wim).  However, RTEMS assumes that only one register window is
520marked invalid at a time (i.e. only one bit set in the wim).
521This makes the maximum possible number of register windows
522available to the user while still meeting the requirement that
523window overflow and underflow conditions can be detected.
525The window overflow and window underflow trap
526handlers are a critical part of the run-time environment for a
527SPARC application.  The SPARC architectural specification allows
528for the number of register windows to be any power of two less
529than or equal to 32.  The most common choice for SPARC
530implementations appears to be 8 register windows.  This results
531in the cwp ranging in value from 0 to 7 on most implementations.
534The second complicating factor is the sharing of
535registers between adjacent register windows.  While each
536register window has its own set of local registers, the input
537and output registers are shared between adjacent windows.  The
538output registers for register window N are the same as the input
539registers for register window ((N - 1) modulo RW) where RW is
540the number of register windows.  An alternative way to think of
541this is to remember how parameters are passed to a subroutine on
542the SPARC.  The caller loads values into what are its output
543registers.  Then after the callee executes a save instruction,
544those parameters are available in its input registers.  This is
545a very efficient way to pass parameters as no data is actually
546moved by the save or restore instructions.
548@subsection Call and Return Mechanism
550The SPARC architecture supports a simple yet
551effective call and return mechanism.  A subroutine is invoked
552via the call (call) instruction.  This instruction places the
553return address in the caller's output register 7 (o7).  After
554the callee executes a save instruction, this value is available
555in input register 7 (i7) until the corresponding restore
556instruction is executed.
558The callee returns to the caller via a jmp to the
559return address.  There is a delay slot following this
560instruction which is commonly used to execute a restore
561instruction -- if a register window was allocated by this
564It is important to note that the SPARC subroutine
565call and return mechanism does not automatically save and
566restore any registers.  This is accomplished via the save and
567restore instructions which manage the set of registers windows.
569In case a floating-point unit is supported, then floating-point return values
570appear in the floating-point registers.  Single-precision values occupy %f0;
571double-precision values occupy %f0 and %f1.  Otherwise, these are scratch
572registers.  Due to this the hardware and software floating-point ABIs are
575@subsection Calling Mechanism
577All RTEMS directives are invoked using the regular
578SPARC calling convention via the call instruction.
580@subsection Register Usage
582As discussed above, the call instruction does not
583automatically save any registers.  The save and restore
584instructions are used to allocate and deallocate register
585windows.  When a register window is allocated, the new set of
586local registers are available for the exclusive use of the
587subroutine which allocated this register set.
589@subsection Parameter Passing
591RTEMS assumes that arguments are placed in the
592caller's output registers with the first argument in output
593register 0 (o0), the second argument in output register 1 (o1),
594and so forth.  Until the callee executes a save instruction, the
595parameters are still visible in the output registers.  After the
596callee executes a save instruction, the parameters are visible
597in the corresponding input registers.  The following pseudo-code
598illustrates the typical sequence used to call a RTEMS directive
599with three (3) arguments:
602load third argument into o2
603load second argument into o1
604load first argument into o0
605invoke directive
606@end example
608@subsection User-Provided Routines
610All user-provided routines invoked by RTEMS, such as
611user extensions, device drivers, and MPCI routines, must also
612adhere to these calling conventions.
615@c  COPYRIGHT (c) 1988-2002.
616@c  On-Line Applications Research Corporation (OAR).
617@c  All rights reserved.
619@section Memory Model
622A processor may support any combination of memory
623models ranging from pure physical addressing to complex demand
624paged virtual memory systems.  RTEMS supports a flat memory
625model which ranges contiguously over the processor's allowable
626address space.  RTEMS does not support segmentation or virtual
627memory of any kind.  The appropriate memory model for RTEMS
628provided by the targeted processor and related characteristics
629of that model are described in this chapter.
631@subsection Flat Memory Model
633The SPARC architecture supports a flat 32-bit address
634space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
635gigabytes).  Each address is represented by a 32-bit value and
636is byte addressable.  The address may be used to reference a
637single byte, half-word (2-bytes), word (4 bytes), or doubleword
638(8 bytes).  Memory accesses within this address space are
639performed in big endian fashion by the SPARC.  Memory accesses
640which are not properly aligned generate a "memory address not
641aligned" trap (type number 7).  The following table lists the
642alignment requirements for a variety of data accesses:
644@ifset use-ascii
647          +--------------+-----------------------+
648          |   Data Type  | Alignment Requirement |
649          +--------------+-----------------------+
650          |     byte     |          1            |
651          |   half-word  |          2            |
652          |     word     |          4            |
653          |  doubleword  |          8            |
654          +--------------+-----------------------+
655@end group
656@end example
657@end ifset
659@ifset use-tex
660@sp 1
664\hbox to 1.75in{\enskip\hfil#\hfil}&
666\hbox to 1.75in{\enskip\hfil#\hfil}&
669&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule}
675@end tex
676@end ifset
678@ifset use-html
681  <TABLE COLS=2 WIDTH="60%" BORDER=2>
682<TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD>
683    <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR>
684<TR><TD ALIGN=center>byte</TD>
685    <TD ALIGN=center>1</TD></TR>
686<TR><TD ALIGN=center>half-word</TD>
687    <TD ALIGN=center>2</TD></TR>
688<TR><TD ALIGN=center>word</TD>
689    <TD ALIGN=center>4</TD></TR>
690<TR><TD ALIGN=center>doubleword</TD>
691    <TD ALIGN=center>8</TD></TR>
692  </TABLE>
694@end html
695@end ifset
697Doubleword load and store operations must use a pair
698of registers as their source or destination.  This pair of
699registers must be an adjacent pair of registers with the first
700of the pair being even numbered.  For example, a valid
701destination for a doubleword load might be input registers 0 and
7021 (i0 and i1).  The pair i1 and i2 would be invalid.  [NOTE:
703Some assemblers for the SPARC do not generate an error if an odd
704numbered register is specified as the beginning register of the
705pair.  In this case, the assembler assumes that what the
706programmer meant was to use the even-odd pair which ends at the
707specified register.  This may or may not have been a correct
710RTEMS does not support any SPARC Memory Management
711Units, therefore, virtual memory or segmentation systems
712involving the SPARC are not supported.
715@c  COPYRIGHT (c) 1988-2002.
716@c  On-Line Applications Research Corporation (OAR).
717@c  All rights reserved.
719@section Interrupt Processing
722Different types of processors respond to the
723occurrence of an interrupt in its own unique fashion. In
724addition, each processor type provides a control mechanism to
725allow for the proper handling of an interrupt.  The processor
726dependent response to the interrupt modifies the current
727execution state and results in a change in the execution stream.
728Most processors require that an interrupt handler utilize some
729special control mechanisms to return to the normal processing
730stream.  Although RTEMS hides many of the processor dependent
731details of interrupt processing, it is important to understand
732how the RTEMS interrupt manager is mapped onto the processor's
733unique architecture. Discussed in this chapter are the SPARC's
734interrupt response and control mechanisms as they pertain to
737RTEMS and associated documentation uses the terms
738interrupt and vector.  In the SPARC architecture, these terms
739correspond to traps and trap type, respectively.  The terms will
740be used interchangeably in this manual.
742@subsection Synchronous Versus Asynchronous Traps
744The SPARC architecture includes two classes of traps:
745synchronous and asynchronous.  Asynchronous traps occur when an
746external event interrupts the processor.  These traps are not
747associated with any instruction executed by the processor and
748logically occur between instructions.  The instruction currently
749in the execute stage of the processor is allowed to complete
750although subsequent instructions are annulled.  The return
751address reported by the processor for asynchronous traps is the
752pair of instructions following the current instruction.
754Synchronous traps are caused by the actions of an
755instruction.  The trap stimulus in this case either occurs
756internally to the processor or is from an external signal that
757was provoked by the instruction.  These traps are taken
758immediately and the instruction that caused the trap is aborted
759before any state changes occur in the processor itself.   The
760return address reported by the processor for synchronous traps
761is the instruction which caused the trap and the following
764@subsection Vectoring of Interrupt Handler
766Upon receipt of an interrupt the SPARC automatically
767performs the following actions:
769@itemize @bullet
770@item disables traps (sets the ET bit of the psr to 0),
772@item the S bit of the psr is copied into the Previous
773Supervisor Mode (PS) bit of the psr,
775@item the cwp is decremented by one (modulo the number of
776register windows) to activate a trap window,
778@item the PC and nPC are loaded into local register 1 and 2
779(l0 and l1),
781@item the trap type (tt) field of the Trap Base Register (TBR)
782is set to the appropriate value, and
784@item if the trap is not a reset, then the PC is written with
785the contents of the TBR and the nPC is written with TBR + 4.  If
786the trap is a reset, then the PC is set to zero and the nPC is
787set to 4.
788@end itemize
790Trap processing on the SPARC has two features which
791are noticeably different than interrupt processing on other
792architectures.  First, the value of psr register in effect
793immediately before the trap occurred is not explicitly saved.
794Instead only reversible alterations are made to it.  Second, the
795Processor Interrupt Level (pil) is not set to correspond to that
796of the interrupt being processed.  When a trap occurs, ALL
797subsequent traps are disabled.  In order to safely invoke a
798subroutine during trap handling, traps must be enabled to allow
799for the possibility of register window overflow and underflow
802If the interrupt handler was installed as an RTEMS
803interrupt handler, then upon receipt of the interrupt, the
804processor passes control to the RTEMS interrupt handler which
805performs the following actions:
807@itemize @bullet
808@item saves the state of the interrupted task on it's stack,
810@item insures that a register window is available for
811subsequent traps,
813@item if this is the outermost (i.e. non-nested) interrupt,
814then the RTEMS interrupt handler switches from the current stack
815to the interrupt stack,
817@item enables traps,
819@item invokes the vectors to a user interrupt service routine (ISR).
820@end itemize
822Asynchronous interrupts are ignored while traps are
823disabled.  Synchronous traps which occur while traps are
824disabled result in the CPU being forced into an error mode.
826A nested interrupt is processed similarly with the
827exception that the current stack need not be switched to the
828interrupt stack.
830@subsection Traps and Register Windows
832One of the register windows must be reserved at all
833times for trap processing.  This is critical to the proper
834operation of the trap mechanism in the SPARC architecture.  It
835is the responsibility of the trap handler to insure that there
836is a register window available for a subsequent trap before
837re-enabling traps.  It is likely that any high level language
838routines invoked by the trap handler (such as a user-provided
839RTEMS interrupt handler) will allocate a new register window.
840The save operation could result in a window overflow trap.  This
841trap cannot be correctly processed unless (1) traps are enabled
842and (2) a register window is reserved for traps.  Thus, the
843RTEMS interrupt handler insures that a register window is
844available for subsequent traps before enabling traps and
845invoking the user's interrupt handler.
847@subsection Interrupt Levels
849Sixteen levels (0-15) of interrupt priorities are
850supported by the SPARC architecture with level fifteen (15)
851being the highest priority.  Level zero (0) indicates that
852interrupts are fully enabled.  Interrupt requests for interrupts
853with priorities less than or equal to the current interrupt mask
854level are ignored. Level fifteen (15) is a non-maskable interrupt
855(NMI), which makes it unsuitable for standard usage since it can
856affect the real-time behaviour by interrupting critical sections
857and spinlocks. Disabling traps stops also the NMI interrupt from
858happening. It can however be used for power-down or other
859critical events.
861Although RTEMS supports 256 interrupt levels, the
862SPARC only supports sixteen.  RTEMS interrupt levels 0 through
86315 directly correspond to SPARC processor interrupt levels.  All
864other RTEMS interrupt levels are undefined and their behavior is
867Many LEON SPARC v7/v8 systems features an extended interrupt controller
868which adds an extra step of interrupt decoding to allow handling of
869interrupt 16-31. When such an extended interrupt is generated the CPU
870traps into a specific interrupt trap level 1-14 and software reads out from
871the interrupt controller which extended interrupt source actually caused the
874@subsection Disabling of Interrupts by RTEMS
876During the execution of directive calls, critical
877sections of code may be executed.  When these sections are
878encountered, RTEMS disables interrupts to level fifteen (15)
879before the execution of the section and restores them to the
880previous level upon completion of the section.  RTEMS has been
881optimized to ensure that interrupts are disabled for less than
883Mhz ERC32 with zero wait states.
884These numbers will vary based the number of wait states and
885processor speed present on the target board.
886[NOTE:  The maximum period with interrupts disabled is hand calculated.  This
887calculation was last performed for Release
890[NOTE: It is thought that the length of time at which
891the processor interrupt level is elevated to fifteen by RTEMS is
892not anywhere near as long as the length of time ALL traps are
893disabled as part of the "flush all register windows" operation.]
895Non-maskable interrupts (NMI) cannot be disabled, and
896ISRs which execute at this level MUST NEVER issue RTEMS system
897calls.  If a directive is invoked, unpredictable results may
898occur due to the inability of RTEMS to protect its critical
899sections.  However, ISRs that make no system calls may safely
900execute as non-maskable interrupts.
902Interrupts are disabled or enabled by performing a system call
903to the Operating System reserved software traps 9
905generated by the software trap (Ticc) instruction or indirectly
906by calling sparc_disable_interrupts() or sparc_enable_interrupts()
907functions. Disabling interrupts return the previous interrupt level
908(on trap entry) in register G1 and sets PSR.PIL to 15 to disable
909all maskable interrupts. The interrupt level can be restored by
910trapping into the enable interrupt handler with G1 containing the
911new interrupt level.
913@subsection Interrupt Stack
915The SPARC architecture does not provide for a
916dedicated interrupt stack.  Thus by default, trap handlers would
917execute on the stack of the RTEMS task which they interrupted.
918This artificially inflates the stack requirements for each task
919since EVERY task stack would have to include enough space to
920account for the worst case interrupt stack requirements in
921addition to it's own worst case usage.  RTEMS addresses this
922problem on the SPARC by providing a dedicated interrupt stack
923managed by software.
925During system initialization, RTEMS allocates the
926interrupt stack from the Workspace Area.  The amount of memory
927allocated for the interrupt stack is determined by the
928interrupt_stack_size field in the CPU Configuration Table.  As
929part of processing a non-nested interrupt, RTEMS will switch to
930the interrupt stack before invoking the installed handler.
933@c  COPYRIGHT (c) 1988-2002.
934@c  On-Line Applications Research Corporation (OAR).
935@c  All rights reserved.
937@section Default Fatal Error Processing
940Upon detection of a fatal error by either the
941application or RTEMS the fatal error manager is invoked.  The
942fatal error manager will invoke the user-supplied fatal error
943handlers.  If no user-supplied handlers are configured,  the
944RTEMS provided default fatal error handler is invoked.  If the
945user-supplied fatal error handlers return to the executive the
946default fatal error handler is then invoked.  This chapter
947describes the precise operations of the default fatal error
950@subsection Default Fatal Error Handler Operations
952The default fatal error handler which is invoked by
953the fatal_error_occurred directive when there is no user handler
954configured or the user handler returns control to RTEMS.  The
955default fatal error handler disables processor interrupts to
956level 15, places the error code in g1, and goes into an infinite
957loop to simulate a halt processor instruction.
959@section Thread-Local Storage
961Thread-local storage is supported.
964@c  COPYRIGHT (c) 1988-2002.
965@c  On-Line Applications Research Corporation (OAR).
966@c  All rights reserved.
968@section Board Support Packages
971An RTEMS Board Support Package (BSP) must be designed
972to support a particular processor and target board combination.
973This chapter presents a discussion of SPARC specific BSP issues.
974For more information on developing a BSP, refer to the chapter
975titled Board Support Packages in the RTEMS
976Applications User's Guide.
978@subsection System Reset
980An RTEMS based application is initiated or
981re-initiated when the SPARC processor is reset.  When the SPARC
982is reset, the processor performs the following actions:
984@itemize @bullet
985@item the enable trap (ET) of the psr is set to 0 to disable
988@item the supervisor bit (S) of the psr is set to 1 to enter
989supervisor mode, and
991@item the PC is set 0 and the nPC is set to 4.
992@end itemize
994The processor then begins to execute the code at
995location 0.  It is important to note that all fields in the psr
996are not explicitly set by the above steps and all other
997registers retain their value from the previous execution mode.
998This is true even of the Trap Base Register (TBR) whose contents
999reflect the last trap which occurred before the reset.
1001@subsection Processor Initialization
1003It is the responsibility of the application's
1004initialization code to initialize the TBR and install trap
1005handlers for at least the register window overflow and register
1006window underflow conditions.  Traps should be enabled before
1007invoking any subroutines to allow for register window
1008management.  However, interrupts should be disabled by setting
1009the Processor Interrupt Level (pil) field of the psr to 15.
1010RTEMS installs it's own Trap Table as part of initialization
1011which is initialized with the contents of the Trap Table in
1012place when the @code{rtems_initialize_executive} directive was invoked.
1013Upon completion of executive initialization, interrupts are
1016If this SPARC implementation supports on-chip caching
1017and this is to be utilized, then it should be enabled during the
1018reset application initialization code.
1020In addition to the requirements described in the
1021Board Support Packages chapter of the C
1022Applications Users Manual for the reset code
1023which is executed before the call to
1024@code{rtems_initialize_executive}, the SPARC version has the following
1025specific requirements:
1027@itemize @bullet
1028@item Must leave the S bit of the status register set so that
1029the SPARC remains in the supervisor state.
1031@item Must set stack pointer (sp) such that a minimum stack
1032size of MINIMUM_STACK_SIZE bytes is provided for the
1033@code{rtems_initialize_executive} directive.
1035@item Must disable all external interrupts (i.e. set the pil
1036to 15).
1038@item Must enable traps so window overflow and underflow
1039conditions can be properly handled.
1041@item Must initialize the SPARC's initial trap table with at
1042least trap handlers for register window overflow and register
1043window underflow.
1044@end itemize
Note: See TracBrowser for help on using the repository browser.