mirror of
https://gitlab.rtems.org/rtems/rtos/rtems.git
synced 2025-12-26 22:48:23 +00:00
updates
This commit is contained in:
Joel Sherrill
@@ -36,26 +36,17 @@ Applications User's Guide.
|
||||
@section System Reset
|
||||
|
||||
An RTEMS based application is initiated or
|
||||
re-initiated when the PowerPC processor is reset. When the PowerPC
|
||||
is reset, the processor performs the following actions:
|
||||
re-initiated when the PowerPC processor is reset. The PowerPC
|
||||
architecture defines a Reset Exception, but leaves the
|
||||
details of the CPU state as implementation specific. Please
|
||||
refer to the User's Manual for the CPU model in question.
|
||||
|
||||
@itemize @bullet
|
||||
@item TBD
|
||||
|
||||
@item TBD
|
||||
|
||||
@item TBD
|
||||
@end itemize
|
||||
|
||||
The processor then begins to execute the code at location 0x00100.
|
||||
By using the SRR1 bit corresponding to MSR[RI] the softwere may
|
||||
distinguish between power-on reset and other types of system resets.
|
||||
|
||||
It is important to note that all fields in the psr
|
||||
are not explicitly set by the above steps and all other
|
||||
registers retain their value from the previous execution mode.
|
||||
This is true even of the Trap Base Register (TBR) whose contents
|
||||
reflect the last trap which occurred before the reset.
|
||||
In general, at power-up the PowerPC begin execution at address
|
||||
0xFFF00100 in supervisor mode with all exceptions disabled. For
|
||||
soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100
|
||||
depending upon the setting of the Exception Prefix bit in the MSR.
|
||||
If during a soft reset, a Machine Check Exception occurs, then the
|
||||
CPU may execute a hard reset.
|
||||
|
||||
@ifinfo
|
||||
@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages
|
||||
@@ -63,36 +54,33 @@ reflect the last trap which occurred before the reset.
|
||||
@section Processor Initialization
|
||||
|
||||
It is the responsibility of the application's
|
||||
initialization code to initialize the TBR and install trap
|
||||
handlers for at least the register window overflow and register
|
||||
window underflow conditions. Traps should be enabled before
|
||||
invoking any subroutines to allow for register window
|
||||
management. However, interrupts should be disabled by setting
|
||||
the Processor Interrupt Level (pil) field of the psr to 15.
|
||||
RTEMS installs it's own Trap Table as part of initialization
|
||||
which is initialized with the contents of the Trap Table in
|
||||
place when the rtems_initialize_executive directive was invoked.
|
||||
Upon completion of executive initialization, interrupts are
|
||||
enabled.
|
||||
initialization code to initialize the CPU and board
|
||||
to a quiescent state before invoking the @code{rtems_initialize_executive}
|
||||
directive. It is recommended that the BSP utilize the @code{predriver_hook}
|
||||
to install default handlers for all exceptions. These default handlers
|
||||
may be overwritten as various device drivers and subsystems install
|
||||
their own exception handlers. Upon completion of RTEMS executive
|
||||
initialization, all interrupts are enabled.
|
||||
|
||||
If this PowerPC implementation supports on-chip caching
|
||||
and this is to be utilized, then it should be enabled during the
|
||||
reset application initialization code.
|
||||
reset application initialization code. On-chip caching has been
|
||||
observed to prevent some emulators from working properly, so it
|
||||
may be necessary to run with caching disabled to use these emulators.
|
||||
|
||||
In addition to the requirements described in the
|
||||
Board Support Packages chapter of the @value{LANGUAGE}
|
||||
Applications User's Manual for the reset code
|
||||
which is executed before the call to
|
||||
rtems_initialize executive, the PowrePC version has the following
|
||||
specific requirements:
|
||||
@b{Board Support Packages} chapter of the @b{@value{LANGUAGE}
|
||||
Applications User's Manual} for the reset code
|
||||
which is executed before the call to @code{rtems_initialize_executive},
|
||||
the PowrePC version has the following specific requirements:
|
||||
|
||||
@itemize @bullet
|
||||
@item Must leave the PR bit of the machine state register set so that
|
||||
the PowerPC remains in the supervisor state.
|
||||
@item Must leave the PR bit of the Machine State Register (MSR) set
|
||||
to 0 so the PowerPC remains in the supervisor state.
|
||||
|
||||
@item Must set stack pointer (sp) such that a minimum stack
|
||||
@item Must set stack pointer (sp or r1) such that a minimum stack
|
||||
size of MINIMUM_STACK_SIZE bytes is provided for the
|
||||
rtems_initialize executive directive.
|
||||
@code{rtems_initialize_executive} directive.
|
||||
|
||||
@item Must disable all external interrupts (i.e. clear the EI (EE)
|
||||
bit of the machine state register).
|
||||
@@ -100,8 +88,8 @@ bit of the machine state register).
|
||||
@item Must enable traps so window overflow and underflow
|
||||
conditions can be properly handled.
|
||||
|
||||
@item Must initialize the PowerPC's initial trap table with at
|
||||
least trap handlers for register window overflow and register
|
||||
window underflow.
|
||||
@item Must initialize the PowerPC's initial Exception Table with default
|
||||
handlers.
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@@ -36,26 +36,17 @@ Applications User's Guide.
|
||||
@section System Reset
|
||||
|
||||
An RTEMS based application is initiated or
|
||||
re-initiated when the PowerPC processor is reset. When the PowerPC
|
||||
is reset, the processor performs the following actions:
|
||||
re-initiated when the PowerPC processor is reset. The PowerPC
|
||||
architecture defines a Reset Exception, but leaves the
|
||||
details of the CPU state as implementation specific. Please
|
||||
refer to the User's Manual for the CPU model in question.
|
||||
|
||||
@itemize @bullet
|
||||
@item TBD
|
||||
|
||||
@item TBD
|
||||
|
||||
@item TBD
|
||||
@end itemize
|
||||
|
||||
The processor then begins to execute the code at location 0x00100.
|
||||
By using the SRR1 bit corresponding to MSR[RI] the softwere may
|
||||
distinguish between power-on reset and other types of system resets.
|
||||
|
||||
It is important to note that all fields in the psr
|
||||
are not explicitly set by the above steps and all other
|
||||
registers retain their value from the previous execution mode.
|
||||
This is true even of the Trap Base Register (TBR) whose contents
|
||||
reflect the last trap which occurred before the reset.
|
||||
In general, at power-up the PowerPC begin execution at address
|
||||
0xFFF00100 in supervisor mode with all exceptions disabled. For
|
||||
soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100
|
||||
depending upon the setting of the Exception Prefix bit in the MSR.
|
||||
If during a soft reset, a Machine Check Exception occurs, then the
|
||||
CPU may execute a hard reset.
|
||||
|
||||
@ifinfo
|
||||
@node Board Support Packages Processor Initialization, Processor Dependent Information Table, Board Support Packages System Reset, Board Support Packages
|
||||
@@ -63,36 +54,33 @@ reflect the last trap which occurred before the reset.
|
||||
@section Processor Initialization
|
||||
|
||||
It is the responsibility of the application's
|
||||
initialization code to initialize the TBR and install trap
|
||||
handlers for at least the register window overflow and register
|
||||
window underflow conditions. Traps should be enabled before
|
||||
invoking any subroutines to allow for register window
|
||||
management. However, interrupts should be disabled by setting
|
||||
the Processor Interrupt Level (pil) field of the psr to 15.
|
||||
RTEMS installs it's own Trap Table as part of initialization
|
||||
which is initialized with the contents of the Trap Table in
|
||||
place when the rtems_initialize_executive directive was invoked.
|
||||
Upon completion of executive initialization, interrupts are
|
||||
enabled.
|
||||
initialization code to initialize the CPU and board
|
||||
to a quiescent state before invoking the @code{rtems_initialize_executive}
|
||||
directive. It is recommended that the BSP utilize the @code{predriver_hook}
|
||||
to install default handlers for all exceptions. These default handlers
|
||||
may be overwritten as various device drivers and subsystems install
|
||||
their own exception handlers. Upon completion of RTEMS executive
|
||||
initialization, all interrupts are enabled.
|
||||
|
||||
If this PowerPC implementation supports on-chip caching
|
||||
and this is to be utilized, then it should be enabled during the
|
||||
reset application initialization code.
|
||||
reset application initialization code. On-chip caching has been
|
||||
observed to prevent some emulators from working properly, so it
|
||||
may be necessary to run with caching disabled to use these emulators.
|
||||
|
||||
In addition to the requirements described in the
|
||||
Board Support Packages chapter of the @value{LANGUAGE}
|
||||
Applications User's Manual for the reset code
|
||||
which is executed before the call to
|
||||
rtems_initialize executive, the PowrePC version has the following
|
||||
specific requirements:
|
||||
@b{Board Support Packages} chapter of the @b{@value{LANGUAGE}
|
||||
Applications User's Manual} for the reset code
|
||||
which is executed before the call to @code{rtems_initialize_executive},
|
||||
the PowrePC version has the following specific requirements:
|
||||
|
||||
@itemize @bullet
|
||||
@item Must leave the PR bit of the machine state register set so that
|
||||
the PowerPC remains in the supervisor state.
|
||||
@item Must leave the PR bit of the Machine State Register (MSR) set
|
||||
to 0 so the PowerPC remains in the supervisor state.
|
||||
|
||||
@item Must set stack pointer (sp) such that a minimum stack
|
||||
@item Must set stack pointer (sp or r1) such that a minimum stack
|
||||
size of MINIMUM_STACK_SIZE bytes is provided for the
|
||||
rtems_initialize executive directive.
|
||||
@code{rtems_initialize_executive} directive.
|
||||
|
||||
@item Must disable all external interrupts (i.e. clear the EI (EE)
|
||||
bit of the machine state register).
|
||||
@@ -100,8 +88,8 @@ bit of the machine state register).
|
||||
@item Must enable traps so window overflow and underflow
|
||||
conditions can be properly handled.
|
||||
|
||||
@item Must initialize the PowerPC's initial trap table with at
|
||||
least trap handlers for register window overflow and register
|
||||
window underflow.
|
||||
@item Must initialize the PowerPC's initial Exception Table with default
|
||||
handlers.
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@@ -7,14 +7,13 @@
|
||||
@c
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features CPU Model Implementation Notes, Top
|
||||
@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Low Power Model, Top
|
||||
@end ifinfo
|
||||
@chapter Calling Conventions
|
||||
@ifinfo
|
||||
@menu
|
||||
* Calling Conventions Introduction::
|
||||
* Calling Conventions Programming Model::
|
||||
* Calling Conventions Register Windows::
|
||||
* Calling Conventions Call and Return Mechanism::
|
||||
* Calling Conventions Calling Mechanism::
|
||||
* Calling Conventions Register Usage::
|
||||
@@ -53,14 +52,14 @@ calling convention. Documentation for EABI is available by sending
|
||||
a message with a subject line of "EABI" to eabi@@goth.sis.mot.com.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
|
||||
@node Calling Conventions Programming Model, Calling Conventions Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
|
||||
@end ifinfo
|
||||
@section Programming Model
|
||||
@ifinfo
|
||||
@menu
|
||||
* Non-Floating Point Registers::
|
||||
* Floating Point Registers::
|
||||
* Special Registers::
|
||||
* Calling Conventions Non-Floating Point Registers::
|
||||
* Calling Conventions Floating Point Registers::
|
||||
* Calling Conventions Special Registers::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
@@ -68,7 +67,7 @@ This section discusses the programming model for the
|
||||
PowerPC architecture.
|
||||
|
||||
@ifinfo
|
||||
@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
|
||||
@node Calling Conventions Non-Floating Point Registers, Calling Conventions Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
|
||||
@end ifinfo
|
||||
@subsection Non-Floating Point Registers
|
||||
|
||||
@@ -85,18 +84,19 @@ The following table describes the role of each of these registers:
|
||||
@ifset use-ascii
|
||||
@example
|
||||
@group
|
||||
+---------------+----------------+----------------------+
|
||||
| Register Name | Alternate Name | Description |
|
||||
+---------------+----------------+----------------------+
|
||||
| g0 | na | reads return 0 |
|
||||
| | | writes are ignored |
|
||||
+---------------+----------------+----------------------+
|
||||
| o6 | sp | stack pointer |
|
||||
+---------------+----------------+----------------------+
|
||||
| i6 | fp | frame pointer |
|
||||
+---------------+----------------+----------------------+
|
||||
| i7 | na | return address |
|
||||
+---------------+----------------+----------------------+
|
||||
+---------------+----------------+------------------------------+
|
||||
| Register Name | Alternate Name | Description |
|
||||
+---------------+----------------+------------------------------+
|
||||
| r1 | sp | stack pointer |
|
||||
+---------------+----------------+------------------------------+
|
||||
| | | global pointer to the Small |
|
||||
| r2 | na | Constant Area (SDA2) |
|
||||
+---------------+----------------+------------------------------+
|
||||
| r3 - r12 | na | parameter and result passing |
|
||||
+---------------+----------------+------------------------------+
|
||||
| | | global pointer to the Small |
|
||||
| r13 | na | Data Area (SDA) |
|
||||
+---------------+----------------+------------------------------+
|
||||
@end group
|
||||
@end example
|
||||
@end ifset
|
||||
@@ -110,15 +110,16 @@ The following table describes the role of each of these registers:
|
||||
\vrule#&
|
||||
\hbox to 1.75in{\enskip\hfil#\hfil}&
|
||||
\vrule#&
|
||||
\hbox to 1.75in{\enskip\hfil#\hfil}&
|
||||
\hbox to 2.50in{\enskip\hfil#\hfil}&
|
||||
\vrule#\cr
|
||||
\noalign{\hrule}
|
||||
&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule}
|
||||
&g0&&NA&&reads return 0; &\cr
|
||||
&&&&&writes are ignored&\cr\noalign{\hrule}
|
||||
&o6&&sp&&stack pointer&\cr\noalign{\hrule}
|
||||
&i6&&fp&&frame pointer&\cr\noalign{\hrule}
|
||||
&i7&&NA&&return address&\cr\noalign{\hrule}
|
||||
&r1&&sp&&stack pointer&\cr\noalign{\hrule}
|
||||
&r2&&NA&&global pointer to the Small&\cr
|
||||
&&&&&Constant Area (SDA2)&\cr\noalign{\hrule}
|
||||
&r3 - r12&&NA&¶meter and result passing&\cr\noalign{\hrule}
|
||||
&r13&&NA&&global pointer to the Small&\cr
|
||||
&&&&&Data Area (SDA2)&\cr\noalign{\hrule}
|
||||
}}\hfil}
|
||||
@end tex
|
||||
@end ifset
|
||||
@@ -130,18 +131,18 @@ The following table describes the role of each of these registers:
|
||||
<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD>
|
||||
<TD ALIGN=center><STRONG>Alternate Name</STRONG></TD>
|
||||
<TD ALIGN=center><STRONG>Description</STRONG></TD></TR>
|
||||
<TR><TD ALIGN=center>g0</TD>
|
||||
<TD ALIGN=center>NA</TD>
|
||||
<TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR>
|
||||
<TR><TD ALIGN=center>o6</TD>
|
||||
<TR><TD ALIGN=center>r1</TD>
|
||||
<TD ALIGN=center>sp</TD>
|
||||
<TD ALIGN=center>stack pointer</TD></TR>
|
||||
<TR><TD ALIGN=center>i6</TD>
|
||||
<TD ALIGN=center>fp</TD>
|
||||
<TD ALIGN=center>frame pointer</TD></TR>
|
||||
<TR><TD ALIGN=center>i7</TD>
|
||||
<TR><TD ALIGN=center>r2</TD>
|
||||
<TD ALIGN=center>na</TD>
|
||||
<TD ALIGN=center>global pointer to the Small Constant Area (SDA2)</TD></TR>
|
||||
<TR><TD ALIGN=center>r3 - r12</TD>
|
||||
<TD ALIGN=center>NA</TD>
|
||||
<TD ALIGN=center>return address</TD></TR>
|
||||
<TD ALIGN=center>parameter and result passing</TD></TR>
|
||||
<TR><TD ALIGN=center>r13</TD>
|
||||
<TD ALIGN=center>NA</TD>
|
||||
<TD ALIGN=center>global pointer to the Small Data Area (SDA)</TD></TR>
|
||||
</TABLE>
|
||||
</CENTER>
|
||||
@end html
|
||||
@@ -149,13 +150,13 @@ The following table describes the role of each of these registers:
|
||||
|
||||
|
||||
@ifinfo
|
||||
@node Floating Point Registers, Special Registers, Non-Floating Point Registers, Calling Conventions Programming Model
|
||||
@node Calling Conventions Floating Point Registers, Calling Conventions Special Registers, Calling Conventions Non-Floating Point Registers, Calling Conventions Programming Model
|
||||
@end ifinfo
|
||||
@subsection Floating Point Registers
|
||||
|
||||
The PowerPC architecture includes thirty-two,
|
||||
sixty-four bit registers. All PowwerPC floating point instructions
|
||||
interprete these registers as 32 double precision floating point registers,
|
||||
The PowerPC architecture includes thirty-two, sixty-four bit
|
||||
floating point registers. All PowerPC floating point instructions
|
||||
interpret these registers as 32 double precision floating point registers,
|
||||
regardless of whether the processor has 64-bit or 32-bit implementation.
|
||||
|
||||
The floating point status and control register (fpscr) records exceptions
|
||||
@@ -163,159 +164,66 @@ and the type of result generated by floating-point operations.
|
||||
Additionally, it controls the rounding mode of operations and allows the
|
||||
reporting of floating exceptions to be enabled or disabled.
|
||||
|
||||
XXXXXX
|
||||
A queue of the floating point instructions which have
|
||||
started execution but not yet completed is maintained. This
|
||||
queue is needed to support the multiple cycle nature of floating
|
||||
point operations and to aid floating point exception trap
|
||||
handlers. Once a floating point exception has been encountered,
|
||||
the queue is frozen until it is emptied by the trap handler.
|
||||
The floating point queue is loaded by launching instructions.
|
||||
It is emptied normally when the floating point completes all
|
||||
outstanding instructions and by floating point exception
|
||||
handlers with the store double floating point queue (stdfq)
|
||||
instruction.
|
||||
XXX
|
||||
|
||||
@ifinfo
|
||||
@node Special Registers, Calling Conventions Register Windows, Floating Point Registers, Calling Conventions Programming Model
|
||||
@node Calling Conventions Special Registers, Calling Conventions Call and Return Mechanism, Calling Conventions Floating Point Registers, Calling Conventions Programming Model
|
||||
@end ifinfo
|
||||
@subsection Special Registers
|
||||
|
||||
The PowerPC architecture includes XXX special registers
|
||||
which are critical to the programming model: the Machine State
|
||||
Register (msr) and XXX the Window Invalid Mask (wim) XXX. The msr
|
||||
contains the processor mode, power management mode, endian mode, exception
|
||||
information, privlige level, floating point available and floating point
|
||||
excepiton mode, address translation information and the exception prefix.
|
||||
The PowerPC architecture includes a number of special registers
|
||||
which are critical to the programming model:
|
||||
|
||||
XXX
|
||||
condition codes, processor interrupt level, trap
|
||||
enable bit, supervisor mode and previous supervisor mode bits,
|
||||
version information, floating point unit and coprocessor enable
|
||||
bits, and the current window pointer (cwp). The cwp field of
|
||||
the psr and wim register are used to manage the register windows
|
||||
in the SPARC architecture. The register windows are discussed
|
||||
in more detail below.
|
||||
XXX
|
||||
@table @b
|
||||
|
||||
@item Machine State Register
|
||||
|
||||
The MSR contains the processor mode, power management mode, endian mode,
|
||||
exception information, privilege level, floating point available and
|
||||
floating point excepiton mode, address translation information and
|
||||
the exception prefix.
|
||||
|
||||
@item Link Register
|
||||
|
||||
The LR contains the return address after a function call. This register
|
||||
must be saved before a subsequent subroutine call can be made. The
|
||||
use of this register is discussed further in the @b{Call and Return
|
||||
Mechanism} section below.
|
||||
|
||||
@item Count Register
|
||||
|
||||
The CTR contains the iteration variable for some loops. It may also be used
|
||||
for indirect function calls and jumps.
|
||||
|
||||
@end table
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Register Windows, Calling Conventions Call and Return Mechanism, Special Registers, Calling Conventions
|
||||
@end ifinfo
|
||||
@section Register Windows
|
||||
|
||||
The SPARC architecture includes the concept of
|
||||
register windows. An overly simplistic way to think of these
|
||||
windows is to imagine them as being an infinite supply of
|
||||
"fresh" register sets available for each subroutine to use. In
|
||||
reality, they are much more complicated.
|
||||
|
||||
The save instruction is used to obtain a new register
|
||||
window. This instruction decrements the current window pointer,
|
||||
thus providing a new set of registers for use. This register
|
||||
set includes eight fresh local registers for use exclusively by
|
||||
this subroutine. When done with a register set, the restore
|
||||
instruction increments the current window pointer and the
|
||||
previous register set is once again available.
|
||||
|
||||
The two primary issues complicating the use of
|
||||
register windows are that (1) the set of register windows is
|
||||
finite, and (2) some registers are shared between adjacent
|
||||
registers windows.
|
||||
|
||||
Because the set of register windows is finite, it is
|
||||
possible to execute enough save instructions without
|
||||
corresponding restore's to consume all of the register windows.
|
||||
This is easily accomplished in a high level language because
|
||||
each subroutine typically performs a save instruction upon
|
||||
entry. Thus having a subroutine call depth greater than the
|
||||
number of register windows will result in a window overflow
|
||||
condition. The window overflow condition generates a trap which
|
||||
must be handled in software. The window overflow trap handler
|
||||
is responsible for saving the contents of the oldest register
|
||||
window on the program stack.
|
||||
|
||||
Similarly, the subroutines will eventually complete
|
||||
and begin to perform restore's. If the restore results in the
|
||||
need for a register window which has previously been written to
|
||||
memory as part of an overflow, then a window underflow condition
|
||||
results. Just like the window overflow, the window underflow
|
||||
condition must be handled in software by a trap handler. The
|
||||
window underflow trap handler is responsible for reloading the
|
||||
contents of the register window requested by the restore
|
||||
instruction from the program stack.
|
||||
|
||||
The Window Invalid Mask (wim) and the Current Window
|
||||
Pointer (cwp) field in the psr are used in conjunction to manage
|
||||
the finite set of register windows and detect the window
|
||||
overflow and underflow conditions. The cwp contains the index
|
||||
of the register window currently in use. The save instruction
|
||||
decrements the cwp modulo the number of register windows.
|
||||
Similarly, the restore instruction increments the cwp modulo the
|
||||
number of register windows. Each bit in the wim represents
|
||||
represents whether a register window contains valid information.
|
||||
The value of 0 indicates the register window is valid and 1
|
||||
indicates it is invalid. When a save instruction causes the cwp
|
||||
to point to a register window which is marked as invalid, a
|
||||
window overflow condition results. Conversely, the restore
|
||||
instruction may result in a window underflow condition.
|
||||
|
||||
Other than the assumption that a register window is
|
||||
always available for trap (i.e. interrupt) handlers, the SPARC
|
||||
architecture places no limits on the number of register windows
|
||||
simultaneously marked as invalid (i.e. number of bits set in the
|
||||
wim). However, RTEMS assumes that only one register window is
|
||||
marked invalid at a time (i.e. only one bit set in the wim).
|
||||
This makes the maximum possible number of register windows
|
||||
available to the user while still meeting the requirement that
|
||||
window overflow and underflow conditions can be detected.
|
||||
|
||||
The window overflow and window underflow trap
|
||||
handlers are a critical part of the run-time environment for a
|
||||
SPARC application. The SPARC architectural specification allows
|
||||
for the number of register windows to be any power of two less
|
||||
than or equal to 32. The most common choice for SPARC
|
||||
implementations appears to be 8 register windows. This results
|
||||
in the cwp ranging in value from 0 to 7 on most implementations.
|
||||
|
||||
|
||||
The second complicating factor is the sharing of
|
||||
registers between adjacent register windows. While each
|
||||
register window has its own set of local registers, the input
|
||||
and output registers are shared between adjacent windows. The
|
||||
output registers for register window N are the same as the input
|
||||
registers for register window ((N - 1) modulo RW) where RW is
|
||||
the number of register windows. An alternative way to think of
|
||||
this is to remember how parameters are passed to a subroutine on
|
||||
the SPARC. The caller loads values into what are its output
|
||||
registers. Then after the callee executes a save instruction,
|
||||
those parameters are available in its input registers. This is
|
||||
a very efficient way to pass parameters as no data is actually
|
||||
moved by the save or restore instructions.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Register Windows, Calling Conventions
|
||||
@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Special Registers, Calling Conventions
|
||||
@end ifinfo
|
||||
@section Call and Return Mechanism
|
||||
|
||||
The SPARC architecture supports a simple yet
|
||||
effective call and return mechanism. A subroutine is invoked
|
||||
via the call (call) instruction. This instruction places the
|
||||
return address in the caller's output register 7 (o7). After
|
||||
the callee executes a save instruction, this value is available
|
||||
in input register 7 (i7) until the corresponding restore
|
||||
instruction is executed.
|
||||
The PowerPC architecture supports a simple yet effective call
|
||||
and return mechanism. A subroutine is invoked
|
||||
via the "branch and link" (@code{bl}) and
|
||||
"brank and link absolute" (@code{bla})
|
||||
instructions. This instructions place the return address
|
||||
in the Link Register (LR). The callee returns to the caller by
|
||||
executing a "branch unconditional to the link register" (@code{blr})
|
||||
instruction. Thus the callee returns to the caller via a jump
|
||||
to the return address which is stored in the LR.
|
||||
|
||||
The callee returns to the caller via a jmp to the
|
||||
return address. There is a delay slot following this
|
||||
instruction which is commonly used to execute a restore
|
||||
instruction -- if a register window was allocated by this
|
||||
subroutine.
|
||||
The previous contents of the LR are not automatically saved
|
||||
by either the @code{bl} or @code{bla}. It is the responsibility
|
||||
of the callee to save the contents of the LR before invoking
|
||||
another subroutine. If the callee invokes another subroutine,
|
||||
it must restore the LR before executing the @code{blr} instruction
|
||||
to return to the caller.
|
||||
|
||||
It is important to note that the SPARC subroutine
|
||||
It is important to note that the PowerPC subroutine
|
||||
call and return mechanism does not automatically save and
|
||||
restore any registers. This is accomplished via the save and
|
||||
restore instructions which manage the set of registers windows.
|
||||
restore any registers.
|
||||
|
||||
The LR may be accessed as special purpose register 8 (@code{SPR8}) using the
|
||||
"move from special register" (@code{mfspr}) and
|
||||
"move to special register" (@code{mtspr}) instructions.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Call and Return Mechanism, Calling Conventions
|
||||
@@ -323,7 +231,8 @@ restore instructions which manage the set of registers windows.
|
||||
@section Calling Mechanism
|
||||
|
||||
All RTEMS directives are invoked using the regular
|
||||
SPARC calling convention via the call instruction.
|
||||
PowerPC EABI calling convention via the @code{bl} or
|
||||
@code{bla} instructions.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions
|
||||
@@ -331,11 +240,11 @@ SPARC calling convention via the call instruction.
|
||||
@section Register Usage
|
||||
|
||||
As discussed above, the call instruction does not
|
||||
automatically save any registers. The save and restore
|
||||
instructions are used to allocate and deallocate register
|
||||
windows. When a register window is allocated, the new set of
|
||||
local registers are available for the exclusive use of the
|
||||
subroutine which allocated this register set.
|
||||
automatically save any registers. It is the responsibility
|
||||
of the callee to save and restore any registers which must be preserved
|
||||
across subroutine calls. The callee is responsible for saving
|
||||
callee-preserved registers to the program stack and restoring them
|
||||
before returning to the caller.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions
|
||||
@@ -343,19 +252,19 @@ subroutine which allocated this register set.
|
||||
@section Parameter Passing
|
||||
|
||||
RTEMS assumes that arguments are placed in the
|
||||
caller's output registers with the first argument in output
|
||||
register 0 (o0), the second argument in output register 1 (o1),
|
||||
and so forth. Until the callee executes a save instruction, the
|
||||
parameters are still visible in the output registers. After the
|
||||
callee executes a save instruction, the parameters are visible
|
||||
in the corresponding input registers. The following pseudo-code
|
||||
general purpose registers with the first argument in
|
||||
register 3 (@code{r3}), the second argument in general purpose
|
||||
register 4 (@code{r4}), and so forth until the seventh
|
||||
argument is in general purpose register 10 (@code{r10}).
|
||||
If there are more than seven arguments, then subsequent arguments
|
||||
are placed on the program stack. The following pseudo-code
|
||||
illustrates the typical sequence used to call a RTEMS directive
|
||||
with three (3) arguments:
|
||||
|
||||
@example
|
||||
load third argument into o2
|
||||
load second argument into o1
|
||||
load first argument into o0
|
||||
load third argument into r5
|
||||
load second argument into r4
|
||||
load first argument into r3
|
||||
invoke directive
|
||||
@end example
|
||||
|
||||
@@ -366,7 +275,6 @@ invoke directive
|
||||
|
||||
All user-provided routines invoked by RTEMS, such as
|
||||
user extensions, device drivers, and MPCI routines, must also
|
||||
adhere to these calling conventions.
|
||||
|
||||
adhere to these same calling conventions.
|
||||
|
||||
|
||||
|
||||
@@ -7,14 +7,13 @@
|
||||
@c
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features CPU Model Implementation Notes, Top
|
||||
@node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features Low Power Model, Top
|
||||
@end ifinfo
|
||||
@chapter Calling Conventions
|
||||
@ifinfo
|
||||
@menu
|
||||
* Calling Conventions Introduction::
|
||||
* Calling Conventions Programming Model::
|
||||
* Calling Conventions Register Windows::
|
||||
* Calling Conventions Call and Return Mechanism::
|
||||
* Calling Conventions Calling Mechanism::
|
||||
* Calling Conventions Register Usage::
|
||||
@@ -53,14 +52,14 @@ calling convention. Documentation for EABI is available by sending
|
||||
a message with a subject line of "EABI" to eabi@@goth.sis.mot.com.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
|
||||
@node Calling Conventions Programming Model, Calling Conventions Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
|
||||
@end ifinfo
|
||||
@section Programming Model
|
||||
@ifinfo
|
||||
@menu
|
||||
* Non-Floating Point Registers::
|
||||
* Floating Point Registers::
|
||||
* Special Registers::
|
||||
* Calling Conventions Non-Floating Point Registers::
|
||||
* Calling Conventions Floating Point Registers::
|
||||
* Calling Conventions Special Registers::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
@@ -68,7 +67,7 @@ This section discusses the programming model for the
|
||||
PowerPC architecture.
|
||||
|
||||
@ifinfo
|
||||
@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
|
||||
@node Calling Conventions Non-Floating Point Registers, Calling Conventions Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
|
||||
@end ifinfo
|
||||
@subsection Non-Floating Point Registers
|
||||
|
||||
@@ -85,18 +84,19 @@ The following table describes the role of each of these registers:
|
||||
@ifset use-ascii
|
||||
@example
|
||||
@group
|
||||
+---------------+----------------+----------------------+
|
||||
| Register Name | Alternate Name | Description |
|
||||
+---------------+----------------+----------------------+
|
||||
| g0 | na | reads return 0 |
|
||||
| | | writes are ignored |
|
||||
+---------------+----------------+----------------------+
|
||||
| o6 | sp | stack pointer |
|
||||
+---------------+----------------+----------------------+
|
||||
| i6 | fp | frame pointer |
|
||||
+---------------+----------------+----------------------+
|
||||
| i7 | na | return address |
|
||||
+---------------+----------------+----------------------+
|
||||
+---------------+----------------+------------------------------+
|
||||
| Register Name | Alternate Name | Description |
|
||||
+---------------+----------------+------------------------------+
|
||||
| r1 | sp | stack pointer |
|
||||
+---------------+----------------+------------------------------+
|
||||
| | | global pointer to the Small |
|
||||
| r2 | na | Constant Area (SDA2) |
|
||||
+---------------+----------------+------------------------------+
|
||||
| r3 - r12 | na | parameter and result passing |
|
||||
+---------------+----------------+------------------------------+
|
||||
| | | global pointer to the Small |
|
||||
| r13 | na | Data Area (SDA) |
|
||||
+---------------+----------------+------------------------------+
|
||||
@end group
|
||||
@end example
|
||||
@end ifset
|
||||
@@ -110,15 +110,16 @@ The following table describes the role of each of these registers:
|
||||
\vrule#&
|
||||
\hbox to 1.75in{\enskip\hfil#\hfil}&
|
||||
\vrule#&
|
||||
\hbox to 1.75in{\enskip\hfil#\hfil}&
|
||||
\hbox to 2.50in{\enskip\hfil#\hfil}&
|
||||
\vrule#\cr
|
||||
\noalign{\hrule}
|
||||
&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule}
|
||||
&g0&&NA&&reads return 0; &\cr
|
||||
&&&&&writes are ignored&\cr\noalign{\hrule}
|
||||
&o6&&sp&&stack pointer&\cr\noalign{\hrule}
|
||||
&i6&&fp&&frame pointer&\cr\noalign{\hrule}
|
||||
&i7&&NA&&return address&\cr\noalign{\hrule}
|
||||
&r1&&sp&&stack pointer&\cr\noalign{\hrule}
|
||||
&r2&&NA&&global pointer to the Small&\cr
|
||||
&&&&&Constant Area (SDA2)&\cr\noalign{\hrule}
|
||||
&r3 - r12&&NA&¶meter and result passing&\cr\noalign{\hrule}
|
||||
&r13&&NA&&global pointer to the Small&\cr
|
||||
&&&&&Data Area (SDA2)&\cr\noalign{\hrule}
|
||||
}}\hfil}
|
||||
@end tex
|
||||
@end ifset
|
||||
@@ -130,18 +131,18 @@ The following table describes the role of each of these registers:
|
||||
<TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD>
|
||||
<TD ALIGN=center><STRONG>Alternate Name</STRONG></TD>
|
||||
<TD ALIGN=center><STRONG>Description</STRONG></TD></TR>
|
||||
<TR><TD ALIGN=center>g0</TD>
|
||||
<TD ALIGN=center>NA</TD>
|
||||
<TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR>
|
||||
<TR><TD ALIGN=center>o6</TD>
|
||||
<TR><TD ALIGN=center>r1</TD>
|
||||
<TD ALIGN=center>sp</TD>
|
||||
<TD ALIGN=center>stack pointer</TD></TR>
|
||||
<TR><TD ALIGN=center>i6</TD>
|
||||
<TD ALIGN=center>fp</TD>
|
||||
<TD ALIGN=center>frame pointer</TD></TR>
|
||||
<TR><TD ALIGN=center>i7</TD>
|
||||
<TR><TD ALIGN=center>r2</TD>
|
||||
<TD ALIGN=center>na</TD>
|
||||
<TD ALIGN=center>global pointer to the Small Constant Area (SDA2)</TD></TR>
|
||||
<TR><TD ALIGN=center>r3 - r12</TD>
|
||||
<TD ALIGN=center>NA</TD>
|
||||
<TD ALIGN=center>return address</TD></TR>
|
||||
<TD ALIGN=center>parameter and result passing</TD></TR>
|
||||
<TR><TD ALIGN=center>r13</TD>
|
||||
<TD ALIGN=center>NA</TD>
|
||||
<TD ALIGN=center>global pointer to the Small Data Area (SDA)</TD></TR>
|
||||
</TABLE>
|
||||
</CENTER>
|
||||
@end html
|
||||
@@ -149,13 +150,13 @@ The following table describes the role of each of these registers:
|
||||
|
||||
|
||||
@ifinfo
|
||||
@node Floating Point Registers, Special Registers, Non-Floating Point Registers, Calling Conventions Programming Model
|
||||
@node Calling Conventions Floating Point Registers, Calling Conventions Special Registers, Calling Conventions Non-Floating Point Registers, Calling Conventions Programming Model
|
||||
@end ifinfo
|
||||
@subsection Floating Point Registers
|
||||
|
||||
The PowerPC architecture includes thirty-two,
|
||||
sixty-four bit registers. All PowwerPC floating point instructions
|
||||
interprete these registers as 32 double precision floating point registers,
|
||||
The PowerPC architecture includes thirty-two, sixty-four bit
|
||||
floating point registers. All PowerPC floating point instructions
|
||||
interpret these registers as 32 double precision floating point registers,
|
||||
regardless of whether the processor has 64-bit or 32-bit implementation.
|
||||
|
||||
The floating point status and control register (fpscr) records exceptions
|
||||
@@ -163,159 +164,66 @@ and the type of result generated by floating-point operations.
|
||||
Additionally, it controls the rounding mode of operations and allows the
|
||||
reporting of floating exceptions to be enabled or disabled.
|
||||
|
||||
XXXXXX
|
||||
A queue of the floating point instructions which have
|
||||
started execution but not yet completed is maintained. This
|
||||
queue is needed to support the multiple cycle nature of floating
|
||||
point operations and to aid floating point exception trap
|
||||
handlers. Once a floating point exception has been encountered,
|
||||
the queue is frozen until it is emptied by the trap handler.
|
||||
The floating point queue is loaded by launching instructions.
|
||||
It is emptied normally when the floating point completes all
|
||||
outstanding instructions and by floating point exception
|
||||
handlers with the store double floating point queue (stdfq)
|
||||
instruction.
|
||||
XXX
|
||||
|
||||
@ifinfo
|
||||
@node Special Registers, Calling Conventions Register Windows, Floating Point Registers, Calling Conventions Programming Model
|
||||
@node Calling Conventions Special Registers, Calling Conventions Call and Return Mechanism, Calling Conventions Floating Point Registers, Calling Conventions Programming Model
|
||||
@end ifinfo
|
||||
@subsection Special Registers
|
||||
|
||||
The PowerPC architecture includes XXX special registers
|
||||
which are critical to the programming model: the Machine State
|
||||
Register (msr) and XXX the Window Invalid Mask (wim) XXX. The msr
|
||||
contains the processor mode, power management mode, endian mode, exception
|
||||
information, privlige level, floating point available and floating point
|
||||
excepiton mode, address translation information and the exception prefix.
|
||||
The PowerPC architecture includes a number of special registers
|
||||
which are critical to the programming model:
|
||||
|
||||
XXX
|
||||
condition codes, processor interrupt level, trap
|
||||
enable bit, supervisor mode and previous supervisor mode bits,
|
||||
version information, floating point unit and coprocessor enable
|
||||
bits, and the current window pointer (cwp). The cwp field of
|
||||
the psr and wim register are used to manage the register windows
|
||||
in the SPARC architecture. The register windows are discussed
|
||||
in more detail below.
|
||||
XXX
|
||||
@table @b
|
||||
|
||||
@item Machine State Register
|
||||
|
||||
The MSR contains the processor mode, power management mode, endian mode,
|
||||
exception information, privilege level, floating point available and
|
||||
floating point excepiton mode, address translation information and
|
||||
the exception prefix.
|
||||
|
||||
@item Link Register
|
||||
|
||||
The LR contains the return address after a function call. This register
|
||||
must be saved before a subsequent subroutine call can be made. The
|
||||
use of this register is discussed further in the @b{Call and Return
|
||||
Mechanism} section below.
|
||||
|
||||
@item Count Register
|
||||
|
||||
The CTR contains the iteration variable for some loops. It may also be used
|
||||
for indirect function calls and jumps.
|
||||
|
||||
@end table
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Register Windows, Calling Conventions Call and Return Mechanism, Special Registers, Calling Conventions
|
||||
@end ifinfo
|
||||
@section Register Windows
|
||||
|
||||
The SPARC architecture includes the concept of
|
||||
register windows. An overly simplistic way to think of these
|
||||
windows is to imagine them as being an infinite supply of
|
||||
"fresh" register sets available for each subroutine to use. In
|
||||
reality, they are much more complicated.
|
||||
|
||||
The save instruction is used to obtain a new register
|
||||
window. This instruction decrements the current window pointer,
|
||||
thus providing a new set of registers for use. This register
|
||||
set includes eight fresh local registers for use exclusively by
|
||||
this subroutine. When done with a register set, the restore
|
||||
instruction increments the current window pointer and the
|
||||
previous register set is once again available.
|
||||
|
||||
The two primary issues complicating the use of
|
||||
register windows are that (1) the set of register windows is
|
||||
finite, and (2) some registers are shared between adjacent
|
||||
registers windows.
|
||||
|
||||
Because the set of register windows is finite, it is
|
||||
possible to execute enough save instructions without
|
||||
corresponding restore's to consume all of the register windows.
|
||||
This is easily accomplished in a high level language because
|
||||
each subroutine typically performs a save instruction upon
|
||||
entry. Thus having a subroutine call depth greater than the
|
||||
number of register windows will result in a window overflow
|
||||
condition. The window overflow condition generates a trap which
|
||||
must be handled in software. The window overflow trap handler
|
||||
is responsible for saving the contents of the oldest register
|
||||
window on the program stack.
|
||||
|
||||
Similarly, the subroutines will eventually complete
|
||||
and begin to perform restore's. If the restore results in the
|
||||
need for a register window which has previously been written to
|
||||
memory as part of an overflow, then a window underflow condition
|
||||
results. Just like the window overflow, the window underflow
|
||||
condition must be handled in software by a trap handler. The
|
||||
window underflow trap handler is responsible for reloading the
|
||||
contents of the register window requested by the restore
|
||||
instruction from the program stack.
|
||||
|
||||
The Window Invalid Mask (wim) and the Current Window
|
||||
Pointer (cwp) field in the psr are used in conjunction to manage
|
||||
the finite set of register windows and detect the window
|
||||
overflow and underflow conditions. The cwp contains the index
|
||||
of the register window currently in use. The save instruction
|
||||
decrements the cwp modulo the number of register windows.
|
||||
Similarly, the restore instruction increments the cwp modulo the
|
||||
number of register windows. Each bit in the wim represents
|
||||
represents whether a register window contains valid information.
|
||||
The value of 0 indicates the register window is valid and 1
|
||||
indicates it is invalid. When a save instruction causes the cwp
|
||||
to point to a register window which is marked as invalid, a
|
||||
window overflow condition results. Conversely, the restore
|
||||
instruction may result in a window underflow condition.
|
||||
|
||||
Other than the assumption that a register window is
|
||||
always available for trap (i.e. interrupt) handlers, the SPARC
|
||||
architecture places no limits on the number of register windows
|
||||
simultaneously marked as invalid (i.e. number of bits set in the
|
||||
wim). However, RTEMS assumes that only one register window is
|
||||
marked invalid at a time (i.e. only one bit set in the wim).
|
||||
This makes the maximum possible number of register windows
|
||||
available to the user while still meeting the requirement that
|
||||
window overflow and underflow conditions can be detected.
|
||||
|
||||
The window overflow and window underflow trap
|
||||
handlers are a critical part of the run-time environment for a
|
||||
SPARC application. The SPARC architectural specification allows
|
||||
for the number of register windows to be any power of two less
|
||||
than or equal to 32. The most common choice for SPARC
|
||||
implementations appears to be 8 register windows. This results
|
||||
in the cwp ranging in value from 0 to 7 on most implementations.
|
||||
|
||||
|
||||
The second complicating factor is the sharing of
|
||||
registers between adjacent register windows. While each
|
||||
register window has its own set of local registers, the input
|
||||
and output registers are shared between adjacent windows. The
|
||||
output registers for register window N are the same as the input
|
||||
registers for register window ((N - 1) modulo RW) where RW is
|
||||
the number of register windows. An alternative way to think of
|
||||
this is to remember how parameters are passed to a subroutine on
|
||||
the SPARC. The caller loads values into what are its output
|
||||
registers. Then after the callee executes a save instruction,
|
||||
those parameters are available in its input registers. This is
|
||||
a very efficient way to pass parameters as no data is actually
|
||||
moved by the save or restore instructions.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Register Windows, Calling Conventions
|
||||
@node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Special Registers, Calling Conventions
|
||||
@end ifinfo
|
||||
@section Call and Return Mechanism
|
||||
|
||||
The SPARC architecture supports a simple yet
|
||||
effective call and return mechanism. A subroutine is invoked
|
||||
via the call (call) instruction. This instruction places the
|
||||
return address in the caller's output register 7 (o7). After
|
||||
the callee executes a save instruction, this value is available
|
||||
in input register 7 (i7) until the corresponding restore
|
||||
instruction is executed.
|
||||
The PowerPC architecture supports a simple yet effective call
|
||||
and return mechanism. A subroutine is invoked
|
||||
via the "branch and link" (@code{bl}) and
|
||||
"brank and link absolute" (@code{bla})
|
||||
instructions. This instructions place the return address
|
||||
in the Link Register (LR). The callee returns to the caller by
|
||||
executing a "branch unconditional to the link register" (@code{blr})
|
||||
instruction. Thus the callee returns to the caller via a jump
|
||||
to the return address which is stored in the LR.
|
||||
|
||||
The callee returns to the caller via a jmp to the
|
||||
return address. There is a delay slot following this
|
||||
instruction which is commonly used to execute a restore
|
||||
instruction -- if a register window was allocated by this
|
||||
subroutine.
|
||||
The previous contents of the LR are not automatically saved
|
||||
by either the @code{bl} or @code{bla}. It is the responsibility
|
||||
of the callee to save the contents of the LR before invoking
|
||||
another subroutine. If the callee invokes another subroutine,
|
||||
it must restore the LR before executing the @code{blr} instruction
|
||||
to return to the caller.
|
||||
|
||||
It is important to note that the SPARC subroutine
|
||||
It is important to note that the PowerPC subroutine
|
||||
call and return mechanism does not automatically save and
|
||||
restore any registers. This is accomplished via the save and
|
||||
restore instructions which manage the set of registers windows.
|
||||
restore any registers.
|
||||
|
||||
The LR may be accessed as special purpose register 8 (@code{SPR8}) using the
|
||||
"move from special register" (@code{mfspr}) and
|
||||
"move to special register" (@code{mtspr}) instructions.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Call and Return Mechanism, Calling Conventions
|
||||
@@ -323,7 +231,8 @@ restore instructions which manage the set of registers windows.
|
||||
@section Calling Mechanism
|
||||
|
||||
All RTEMS directives are invoked using the regular
|
||||
SPARC calling convention via the call instruction.
|
||||
PowerPC EABI calling convention via the @code{bl} or
|
||||
@code{bla} instructions.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions
|
||||
@@ -331,11 +240,11 @@ SPARC calling convention via the call instruction.
|
||||
@section Register Usage
|
||||
|
||||
As discussed above, the call instruction does not
|
||||
automatically save any registers. The save and restore
|
||||
instructions are used to allocate and deallocate register
|
||||
windows. When a register window is allocated, the new set of
|
||||
local registers are available for the exclusive use of the
|
||||
subroutine which allocated this register set.
|
||||
automatically save any registers. It is the responsibility
|
||||
of the callee to save and restore any registers which must be preserved
|
||||
across subroutine calls. The callee is responsible for saving
|
||||
callee-preserved registers to the program stack and restoring them
|
||||
before returning to the caller.
|
||||
|
||||
@ifinfo
|
||||
@node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions
|
||||
@@ -343,19 +252,19 @@ subroutine which allocated this register set.
|
||||
@section Parameter Passing
|
||||
|
||||
RTEMS assumes that arguments are placed in the
|
||||
caller's output registers with the first argument in output
|
||||
register 0 (o0), the second argument in output register 1 (o1),
|
||||
and so forth. Until the callee executes a save instruction, the
|
||||
parameters are still visible in the output registers. After the
|
||||
callee executes a save instruction, the parameters are visible
|
||||
in the corresponding input registers. The following pseudo-code
|
||||
general purpose registers with the first argument in
|
||||
register 3 (@code{r3}), the second argument in general purpose
|
||||
register 4 (@code{r4}), and so forth until the seventh
|
||||
argument is in general purpose register 10 (@code{r10}).
|
||||
If there are more than seven arguments, then subsequent arguments
|
||||
are placed on the program stack. The following pseudo-code
|
||||
illustrates the typical sequence used to call a RTEMS directive
|
||||
with three (3) arguments:
|
||||
|
||||
@example
|
||||
load third argument into o2
|
||||
load second argument into o1
|
||||
load first argument into o0
|
||||
load third argument into r5
|
||||
load second argument into r4
|
||||
load first argument into r3
|
||||
invoke directive
|
||||
@end example
|
||||
|
||||
@@ -366,7 +275,6 @@ invoke directive
|
||||
|
||||
All user-provided routines invoked by RTEMS, such as
|
||||
user extensions, device drivers, and MPCI routines, must also
|
||||
adhere to these calling conventions.
|
||||
|
||||
adhere to these same calling conventions.
|
||||
|
||||
|
||||
|
||||
@@ -14,7 +14,6 @@
|
||||
@menu
|
||||
* CPU Model Dependent Features Introduction::
|
||||
* CPU Model Dependent Features CPU Model Feature Flags::
|
||||
* CPU Model Dependent Features CPU Model Implementation Notes::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
@@ -55,7 +54,6 @@ across the entire family.
|
||||
* CPU Model Dependent Features Maximum Interrupts::
|
||||
* CPU Model Dependent Features Has Double Precision Floating Point::
|
||||
* CPU Model Dependent Features Critical Interrupts::
|
||||
* CPU Model Dependent Features MSR Values::
|
||||
* CPU Model Dependent Features Use Multiword Load/Store Instructions::
|
||||
* CPU Model Dependent Features Instruction Cache Size::
|
||||
* CPU Model Dependent Features Data Cache Size::
|
||||
@@ -146,7 +144,7 @@ important because the floating point registers need only be four bytes
|
||||
wide (not eight) if double precision is not supported.
|
||||
|
||||
@ifinfo
|
||||
@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features MSR Values, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@end ifinfo
|
||||
@subsection Critical Interrupts
|
||||
|
||||
@@ -154,14 +152,7 @@ The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model
|
||||
has the Critical Interrupt capability as defined by the IBM 403 models.
|
||||
|
||||
@ifinfo
|
||||
@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@end ifinfo
|
||||
@subsection MSR Values
|
||||
|
||||
The macro PPC_MSR_INITIAL is set to
|
||||
|
||||
@ifinfo
|
||||
@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@end ifinfo
|
||||
@subsection Use Multiword Load/Store Instructions
|
||||
|
||||
@@ -190,42 +181,43 @@ The macro PPC_D_CACHE is set to the size in bytes of the data cache.
|
||||
@end ifinfo
|
||||
@subsection Debug Model
|
||||
|
||||
The macro PPC_DEBUG_MODEL
|
||||
The macro PPC_DEBUG_MODEL is set to indicate the debug support features
|
||||
present in this CPU model. The following debug support feature sets
|
||||
are currently supported:
|
||||
|
||||
@table @b
|
||||
|
||||
@item @code{PPC_DEBUG_MODEL_STANDARD}
|
||||
indicates XXX
|
||||
indicates that the single-step trace enable (SE) and branch trace
|
||||
enable (BE) bits in the MSR are supported by this CPU model.
|
||||
|
||||
@item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
|
||||
indicates XXX
|
||||
indicates that only the single-step trace enable (SE) bit in the MSR
|
||||
is supported by this CPU model.
|
||||
|
||||
@item @code{PPC_DEBUG_MODEL_IBM4xx}
|
||||
indicates XXX
|
||||
indicates that the debug exception enable (DE) bit in the MSR is supported
|
||||
by this CPU model. At this time, this particular debug feature set
|
||||
has only been seen in the IBM 4xx series.
|
||||
|
||||
@end table
|
||||
|
||||
@ifinfo
|
||||
@node CPU Model Dependent Features Low Power Model, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@node CPU Model Dependent Features Low Power Model, Calling Conventions, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@end ifinfo
|
||||
@subsection Low Power Model
|
||||
|
||||
The macro PPC_LOW_POWER_MODE
|
||||
The macro PPC_LOW_POWER_MODE is set to indicate the low power model
|
||||
supported by this CPU model. The following low power modes are currently
|
||||
supported.
|
||||
|
||||
@table @b
|
||||
|
||||
@item @code{PPC_LOW_POWER_MODE_NONE}
|
||||
indicates XXX
|
||||
indicates that this CPU model has no low power mode support.
|
||||
|
||||
@item @code{PPC_LOW_POWER_MODE_STANDARD}
|
||||
indicates XXX
|
||||
indicates that this CPU model follows the low power model defined for
|
||||
the PPC603e.
|
||||
|
||||
@end table
|
||||
|
||||
|
||||
@ifinfo
|
||||
@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features
|
||||
@end ifinfo
|
||||
@section CPU Model Implementation Notes
|
||||
|
||||
TBD
|
||||
|
||||
@@ -14,7 +14,6 @@
|
||||
@menu
|
||||
* CPU Model Dependent Features Introduction::
|
||||
* CPU Model Dependent Features CPU Model Feature Flags::
|
||||
* CPU Model Dependent Features CPU Model Implementation Notes::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
@@ -55,7 +54,6 @@ across the entire family.
|
||||
* CPU Model Dependent Features Maximum Interrupts::
|
||||
* CPU Model Dependent Features Has Double Precision Floating Point::
|
||||
* CPU Model Dependent Features Critical Interrupts::
|
||||
* CPU Model Dependent Features MSR Values::
|
||||
* CPU Model Dependent Features Use Multiword Load/Store Instructions::
|
||||
* CPU Model Dependent Features Instruction Cache Size::
|
||||
* CPU Model Dependent Features Data Cache Size::
|
||||
@@ -146,7 +144,7 @@ important because the floating point registers need only be four bytes
|
||||
wide (not eight) if double precision is not supported.
|
||||
|
||||
@ifinfo
|
||||
@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features MSR Values, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@node CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Has Double Precision Floating Point, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@end ifinfo
|
||||
@subsection Critical Interrupts
|
||||
|
||||
@@ -154,14 +152,7 @@ The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model
|
||||
has the Critical Interrupt capability as defined by the IBM 403 models.
|
||||
|
||||
@ifinfo
|
||||
@node CPU Model Dependent Features MSR Values, CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@end ifinfo
|
||||
@subsection MSR Values
|
||||
|
||||
The macro PPC_MSR_INITIAL is set to
|
||||
|
||||
@ifinfo
|
||||
@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features MSR Values, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@node CPU Model Dependent Features Use Multiword Load/Store Instructions, CPU Model Dependent Features Instruction Cache Size, CPU Model Dependent Features Critical Interrupts, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@end ifinfo
|
||||
@subsection Use Multiword Load/Store Instructions
|
||||
|
||||
@@ -190,42 +181,43 @@ The macro PPC_D_CACHE is set to the size in bytes of the data cache.
|
||||
@end ifinfo
|
||||
@subsection Debug Model
|
||||
|
||||
The macro PPC_DEBUG_MODEL
|
||||
The macro PPC_DEBUG_MODEL is set to indicate the debug support features
|
||||
present in this CPU model. The following debug support feature sets
|
||||
are currently supported:
|
||||
|
||||
@table @b
|
||||
|
||||
@item @code{PPC_DEBUG_MODEL_STANDARD}
|
||||
indicates XXX
|
||||
indicates that the single-step trace enable (SE) and branch trace
|
||||
enable (BE) bits in the MSR are supported by this CPU model.
|
||||
|
||||
@item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY}
|
||||
indicates XXX
|
||||
indicates that only the single-step trace enable (SE) bit in the MSR
|
||||
is supported by this CPU model.
|
||||
|
||||
@item @code{PPC_DEBUG_MODEL_IBM4xx}
|
||||
indicates XXX
|
||||
indicates that the debug exception enable (DE) bit in the MSR is supported
|
||||
by this CPU model. At this time, this particular debug feature set
|
||||
has only been seen in the IBM 4xx series.
|
||||
|
||||
@end table
|
||||
|
||||
@ifinfo
|
||||
@node CPU Model Dependent Features Low Power Model, CPU Model Dependent Features CPU Model Implementation Notes, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@node CPU Model Dependent Features Low Power Model, Calling Conventions, CPU Model Dependent Features Debug Model, CPU Model Dependent Features CPU Model Feature Flags
|
||||
@end ifinfo
|
||||
@subsection Low Power Model
|
||||
|
||||
The macro PPC_LOW_POWER_MODE
|
||||
The macro PPC_LOW_POWER_MODE is set to indicate the low power model
|
||||
supported by this CPU model. The following low power modes are currently
|
||||
supported.
|
||||
|
||||
@table @b
|
||||
|
||||
@item @code{PPC_LOW_POWER_MODE_NONE}
|
||||
indicates XXX
|
||||
indicates that this CPU model has no low power mode support.
|
||||
|
||||
@item @code{PPC_LOW_POWER_MODE_STANDARD}
|
||||
indicates XXX
|
||||
indicates that this CPU model follows the low power model defined for
|
||||
the PPC603e.
|
||||
|
||||
@end table
|
||||
|
||||
|
||||
@ifinfo
|
||||
@node CPU Model Dependent Features CPU Model Implementation Notes, Calling Conventions, CPU Model Dependent Features Low Power Model, CPU Model Dependent Features
|
||||
@end ifinfo
|
||||
@section CPU Model Implementation Notes
|
||||
|
||||
TBD
|
||||
|
||||
@@ -50,18 +50,19 @@ typedef struct @{
|
||||
void (*stack_free_hook)( void* );
|
||||
/* end of fields required on all CPUs */
|
||||
|
||||
unsigned32 clicks_per_usec; /* Timer clicks per microsecond */
|
||||
unsigned32 clicks_per_usec; /* Timer clicks per microsecond */
|
||||
void (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
|
||||
boolean exceptions_in_RAM; /* TRUE if in RAM */
|
||||
unsigned32 serial_per_sec; /* Serial clocks per second */
|
||||
|
||||
#if defined(ppc403)
|
||||
unsigned32 serial_per_sec; /* Serial clocks per second */
|
||||
boolean serial_external_clock;
|
||||
boolean serial_xon_xoff;
|
||||
boolean serial_cts_rts;
|
||||
unsigned32 serial_rate;
|
||||
unsigned32 timer_average_overhead; /* Average overhead of timer in ticks */
|
||||
unsigned32 timer_least_valid; /* Least valid number from timer */
|
||||
void (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
|
||||
|
||||
unsigned32 timer_average_overhead; /* in ticks */
|
||||
unsigned32 timer_least_valid; /* Least valid number from timer */
|
||||
#endif
|
||||
@};
|
||||
@end example
|
||||
|
||||
@@ -132,31 +133,33 @@ they are located in RAM dynamic vector installation occurs, otherwise
|
||||
it does not.
|
||||
|
||||
@item serial_per_sec
|
||||
is the number of clock ticks per second for the PPC403 serial timer.
|
||||
is a PPC403 specific field which specifies the number of clock
|
||||
ticks per second for the PPC403 serial timer.
|
||||
|
||||
@item serial_rate
|
||||
is the baud rate for the PPC403 serial timer.
|
||||
is a PPC403 specific field which specifies the baud rate for the
|
||||
PPC403 serial port.
|
||||
|
||||
@item serial_external_clock
|
||||
is a flag used by the BSP to indicate whether or not to mask in a 0x2 into
|
||||
is a PPC403 specific field which indicates whether or not to mask in a 0x2 into
|
||||
the Input/Output Configuration Register (IOCR) during initialization of the
|
||||
PPC403 console. XXX This bit is defined as "reserved" 6-12?
|
||||
PPC403 console. (NOTE: This bit is defined as "reserved" 6-12?)
|
||||
|
||||
@item serial_xon_xoff
|
||||
is a flag used by the BSP to indicate whether or not XON/XOFF flow control
|
||||
is supported for the PPC403 serial timer.
|
||||
is a PPC403 specific field which indicates whether or not
|
||||
XON/XOFF flow control is supported for the PPC403 serial port.
|
||||
|
||||
@item serial_cts_rts
|
||||
is a flag used by the BSP to indicate whether or not to set the lsb of the
|
||||
Input/Output Configuration Register (IOCR) during initialization of the
|
||||
PPC403 console. XXX This bit is defined as "reserved" 6-12?
|
||||
|
||||
is a PPC403 specific field which indicates whether or not to set the
|
||||
least significant bit of the Input/Output Configuration Register
|
||||
(IOCR) during initialization of the PPC403 console. (NOTE: This
|
||||
bit is defined as "reserved" 6-12?)
|
||||
|
||||
@item timer_average_overhead
|
||||
is the average number of overhead ticks that occur on the PPC403 timer.
|
||||
is a PPC403 specific field which specifies the average number of overhead ticks that occur on the PPC403 timer.
|
||||
|
||||
@item timer_least_valid
|
||||
is the maximum valid PPC403 timer value.
|
||||
is a PPC403 specific field which specifies the maximum valid PPC403 timer value.
|
||||
|
||||
@end table
|
||||
|
||||
|
||||
@@ -50,18 +50,19 @@ typedef struct @{
|
||||
void (*stack_free_hook)( void* );
|
||||
/* end of fields required on all CPUs */
|
||||
|
||||
unsigned32 clicks_per_usec; /* Timer clicks per microsecond */
|
||||
unsigned32 clicks_per_usec; /* Timer clicks per microsecond */
|
||||
void (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
|
||||
boolean exceptions_in_RAM; /* TRUE if in RAM */
|
||||
unsigned32 serial_per_sec; /* Serial clocks per second */
|
||||
|
||||
#if defined(ppc403)
|
||||
unsigned32 serial_per_sec; /* Serial clocks per second */
|
||||
boolean serial_external_clock;
|
||||
boolean serial_xon_xoff;
|
||||
boolean serial_cts_rts;
|
||||
unsigned32 serial_rate;
|
||||
unsigned32 timer_average_overhead; /* Average overhead of timer in ticks */
|
||||
unsigned32 timer_least_valid; /* Least valid number from timer */
|
||||
void (*spurious_handler)(unsigned32 vector, CPU_Interrupt_frame *);
|
||||
|
||||
unsigned32 timer_average_overhead; /* in ticks */
|
||||
unsigned32 timer_least_valid; /* Least valid number from timer */
|
||||
#endif
|
||||
@};
|
||||
@end example
|
||||
|
||||
@@ -132,31 +133,33 @@ they are located in RAM dynamic vector installation occurs, otherwise
|
||||
it does not.
|
||||
|
||||
@item serial_per_sec
|
||||
is the number of clock ticks per second for the PPC403 serial timer.
|
||||
is a PPC403 specific field which specifies the number of clock
|
||||
ticks per second for the PPC403 serial timer.
|
||||
|
||||
@item serial_rate
|
||||
is the baud rate for the PPC403 serial timer.
|
||||
is a PPC403 specific field which specifies the baud rate for the
|
||||
PPC403 serial port.
|
||||
|
||||
@item serial_external_clock
|
||||
is a flag used by the BSP to indicate whether or not to mask in a 0x2 into
|
||||
is a PPC403 specific field which indicates whether or not to mask in a 0x2 into
|
||||
the Input/Output Configuration Register (IOCR) during initialization of the
|
||||
PPC403 console. XXX This bit is defined as "reserved" 6-12?
|
||||
PPC403 console. (NOTE: This bit is defined as "reserved" 6-12?)
|
||||
|
||||
@item serial_xon_xoff
|
||||
is a flag used by the BSP to indicate whether or not XON/XOFF flow control
|
||||
is supported for the PPC403 serial timer.
|
||||
is a PPC403 specific field which indicates whether or not
|
||||
XON/XOFF flow control is supported for the PPC403 serial port.
|
||||
|
||||
@item serial_cts_rts
|
||||
is a flag used by the BSP to indicate whether or not to set the lsb of the
|
||||
Input/Output Configuration Register (IOCR) during initialization of the
|
||||
PPC403 console. XXX This bit is defined as "reserved" 6-12?
|
||||
|
||||
is a PPC403 specific field which indicates whether or not to set the
|
||||
least significant bit of the Input/Output Configuration Register
|
||||
(IOCR) during initialization of the PPC403 console. (NOTE: This
|
||||
bit is defined as "reserved" 6-12?)
|
||||
|
||||
@item timer_average_overhead
|
||||
is the average number of overhead ticks that occur on the PPC403 timer.
|
||||
is a PPC403 specific field which specifies the average number of overhead ticks that occur on the PPC403 timer.
|
||||
|
||||
@item timer_least_valid
|
||||
is the maximum valid PPC403 timer value.
|
||||
is a PPC403 specific field which specifies the maximum valid PPC403 timer value.
|
||||
|
||||
@end table
|
||||
|
||||
|
||||
@@ -38,9 +38,25 @@ handler.
|
||||
@section Default Fatal Error Handler Operations
|
||||
|
||||
The default fatal error handler which is invoked by
|
||||
the fatal_error_occurred directive when there is no user handler
|
||||
the @code{rtems_fatal_error_occurred} directive when there is no user handler
|
||||
configured or the user handler returns control to RTEMS. The
|
||||
default fatal error handler disables all processor exceptions,
|
||||
places the error code in r5, and goes into an infinite
|
||||
loop to simulate a halt processor instruction.
|
||||
default fatal error handler performs the following actions:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item places the error code in r3, and
|
||||
|
||||
@item executes a trap instruction which results in a Program Exception.
|
||||
|
||||
@end itemize
|
||||
|
||||
If the Program Exception returns, then the following actions are performed:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item disables all processor exceptions by loading a 0 into the MSR, and
|
||||
|
||||
@item goes into an infinite loop to simulate a halt processor instruction.
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@@ -38,9 +38,25 @@ handler.
|
||||
@section Default Fatal Error Handler Operations
|
||||
|
||||
The default fatal error handler which is invoked by
|
||||
the fatal_error_occurred directive when there is no user handler
|
||||
the @code{rtems_fatal_error_occurred} directive when there is no user handler
|
||||
configured or the user handler returns control to RTEMS. The
|
||||
default fatal error handler disables all processor exceptions,
|
||||
places the error code in r5, and goes into an infinite
|
||||
loop to simulate a halt processor instruction.
|
||||
default fatal error handler performs the following actions:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item places the error code in r3, and
|
||||
|
||||
@item executes a trap instruction which results in a Program Exception.
|
||||
|
||||
@end itemize
|
||||
|
||||
If the Program Exception returns, then the following actions are performed:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item disables all processor exceptions by loading a 0 into the MSR, and
|
||||
|
||||
@item goes into an infinite loop to simulate a halt processor instruction.
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@@ -37,12 +37,12 @@ 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 PPC's
|
||||
unique architecture. Discussed in this chapter are the PowerPC's
|
||||
interrupt response and control mechanisms as they pertain to
|
||||
RTEMS.
|
||||
|
||||
RTEMS and associated documentation uses the terms
|
||||
interrupt and vector. In the PPC architecture, these terms
|
||||
interrupt and vector. In the PowerPC architecture, these terms
|
||||
correspond to exception and exception handler, respectively. The terms will
|
||||
be used interchangeably in this manual.
|
||||
|
||||
@@ -51,7 +51,7 @@ be used interchangeably in this manual.
|
||||
@end ifinfo
|
||||
@section Synchronous Versus Asynchronous Exceptions
|
||||
|
||||
In the PPC architecture exceptions can be either precise or
|
||||
In the PowerPC 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
|
||||
@@ -77,7 +77,7 @@ exceptions conforms to the requirements for context synchronization.
|
||||
@end ifinfo
|
||||
@section Vectoring of Interrupt Handler
|
||||
|
||||
Upon determining that an exception can be taken the PPC automatically
|
||||
Upon determining that an exception can be taken the PowerPC automatically
|
||||
performs the following actions:
|
||||
|
||||
@itemize @bullet
|
||||
@@ -95,7 +95,6 @@ bits from the MSR.
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
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
|
||||
@@ -104,8 +103,9 @@ 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 exceptions,
|
||||
@item saves all registers which are not normally preserved
|
||||
by the calling sequence so the user's interrupt service
|
||||
routine can be written in a high-level language.
|
||||
|
||||
@item if this is the outermost (i.e. non-nested) interrupt,
|
||||
then the RTEMS interrupt handler switches from the current stack
|
||||
@@ -117,7 +117,7 @@ to the interrupt stack,
|
||||
@end itemize
|
||||
|
||||
Asynchronous interrupts are ignored while exceptions are
|
||||
disabled. Synchronous interrupts which occur while 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
|
||||
@@ -129,16 +129,39 @@ interrupt stack.
|
||||
@end ifinfo
|
||||
@section Interrupt Levels
|
||||
|
||||
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.
|
||||
The PowerPC architecture supports only a single external
|
||||
asynchronous interrupt source. This interrupt source
|
||||
may be enabled and disabled via the External Interrupt Enable (EE)
|
||||
bit in the Machine State Register (MSR). Thus only two level (enabled
|
||||
and disabled) of external device interrupt priorities are
|
||||
directly supported by the PowerPC architecture.
|
||||
|
||||
TBD
|
||||
All other RTEMS interrupt levels are undefined and their behavior is
|
||||
unpredictable.
|
||||
Some PowerPC implementations include a Critical Interrupt capability
|
||||
which is often used to receive interrupts from high priority external
|
||||
devices.
|
||||
|
||||
The RTEMS interrupt level mapping scheme for the PowerPC is not
|
||||
a numeric level as on most RTEMS ports. It is a bit mapping in
|
||||
which the least three significiant bits of the interrupt level
|
||||
are mapped directly to the enabling of specific interrupt
|
||||
sources as follows:
|
||||
|
||||
@table @b
|
||||
|
||||
@item Critical Interrupt
|
||||
Setting bit 0 (the least significant bit) of the interrupt level
|
||||
enables the Critical Interrupt source, if it is available on this
|
||||
CPU model.
|
||||
|
||||
@item Machine Check
|
||||
Setting bit 1 of the interrupt level enables Machine Check execptions.
|
||||
|
||||
@item External Interrupt
|
||||
Setting bit 2 of the interrupt level enables External Interrupt execptions.
|
||||
|
||||
@end table
|
||||
|
||||
All other bits in the RTEMS task interrupt level are ignored.
|
||||
|
||||
@ifinfo
|
||||
@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
|
||||
@@ -147,9 +170,9 @@ unpredictable.
|
||||
|
||||
During the execution of directive calls, critical
|
||||
sections of code may be executed. When these sections are
|
||||
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
|
||||
encountered, RTEMS disables Critical Interrupts, External Interrupts
|
||||
and Machine Checks 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
|
||||
@@ -159,17 +182,12 @@ states and processor speed present on the target board.
|
||||
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 exceptions 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.
|
||||
If a PowerPC implementation provides non-maskable interrupts (NMI)
|
||||
which cannot be disabled, ISRs which process these interrupts
|
||||
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.
|
||||
|
||||
@ifinfo
|
||||
@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing
|
||||
|
||||
@@ -37,12 +37,12 @@ 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 PPC's
|
||||
unique architecture. Discussed in this chapter are the PowerPC's
|
||||
interrupt response and control mechanisms as they pertain to
|
||||
RTEMS.
|
||||
|
||||
RTEMS and associated documentation uses the terms
|
||||
interrupt and vector. In the PPC architecture, these terms
|
||||
interrupt and vector. In the PowerPC architecture, these terms
|
||||
correspond to exception and exception handler, respectively. The terms will
|
||||
be used interchangeably in this manual.
|
||||
|
||||
@@ -51,7 +51,7 @@ be used interchangeably in this manual.
|
||||
@end ifinfo
|
||||
@section Synchronous Versus Asynchronous Exceptions
|
||||
|
||||
In the PPC architecture exceptions can be either precise or
|
||||
In the PowerPC 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
|
||||
@@ -77,7 +77,7 @@ exceptions conforms to the requirements for context synchronization.
|
||||
@end ifinfo
|
||||
@section Vectoring of Interrupt Handler
|
||||
|
||||
Upon determining that an exception can be taken the PPC automatically
|
||||
Upon determining that an exception can be taken the PowerPC automatically
|
||||
performs the following actions:
|
||||
|
||||
@itemize @bullet
|
||||
@@ -95,7 +95,6 @@ bits from the MSR.
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
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
|
||||
@@ -104,8 +103,9 @@ 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 exceptions,
|
||||
@item saves all registers which are not normally preserved
|
||||
by the calling sequence so the user's interrupt service
|
||||
routine can be written in a high-level language.
|
||||
|
||||
@item if this is the outermost (i.e. non-nested) interrupt,
|
||||
then the RTEMS interrupt handler switches from the current stack
|
||||
@@ -117,7 +117,7 @@ to the interrupt stack,
|
||||
@end itemize
|
||||
|
||||
Asynchronous interrupts are ignored while exceptions are
|
||||
disabled. Synchronous interrupts which occur while 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
|
||||
@@ -129,16 +129,39 @@ interrupt stack.
|
||||
@end ifinfo
|
||||
@section Interrupt Levels
|
||||
|
||||
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.
|
||||
The PowerPC architecture supports only a single external
|
||||
asynchronous interrupt source. This interrupt source
|
||||
may be enabled and disabled via the External Interrupt Enable (EE)
|
||||
bit in the Machine State Register (MSR). Thus only two level (enabled
|
||||
and disabled) of external device interrupt priorities are
|
||||
directly supported by the PowerPC architecture.
|
||||
|
||||
TBD
|
||||
All other RTEMS interrupt levels are undefined and their behavior is
|
||||
unpredictable.
|
||||
Some PowerPC implementations include a Critical Interrupt capability
|
||||
which is often used to receive interrupts from high priority external
|
||||
devices.
|
||||
|
||||
The RTEMS interrupt level mapping scheme for the PowerPC is not
|
||||
a numeric level as on most RTEMS ports. It is a bit mapping in
|
||||
which the least three significiant bits of the interrupt level
|
||||
are mapped directly to the enabling of specific interrupt
|
||||
sources as follows:
|
||||
|
||||
@table @b
|
||||
|
||||
@item Critical Interrupt
|
||||
Setting bit 0 (the least significant bit) of the interrupt level
|
||||
enables the Critical Interrupt source, if it is available on this
|
||||
CPU model.
|
||||
|
||||
@item Machine Check
|
||||
Setting bit 1 of the interrupt level enables Machine Check execptions.
|
||||
|
||||
@item External Interrupt
|
||||
Setting bit 2 of the interrupt level enables External Interrupt execptions.
|
||||
|
||||
@end table
|
||||
|
||||
All other bits in the RTEMS task interrupt level are ignored.
|
||||
|
||||
@ifinfo
|
||||
@node Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing Interrupt Stack, Interrupt Processing Interrupt Levels, Interrupt Processing
|
||||
@@ -147,9 +170,9 @@ unpredictable.
|
||||
|
||||
During the execution of directive calls, critical
|
||||
sections of code may be executed. When these sections are
|
||||
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
|
||||
encountered, RTEMS disables Critical Interrupts, External Interrupts
|
||||
and Machine Checks 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
|
||||
@@ -159,17 +182,12 @@ states and processor speed present on the target board.
|
||||
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 exceptions 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.
|
||||
If a PowerPC implementation provides non-maskable interrupts (NMI)
|
||||
which cannot be disabled, ISRs which process these interrupts
|
||||
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.
|
||||
|
||||
@ifinfo
|
||||
@node Interrupt Processing Interrupt Stack, Default Fatal Error Processing, Interrupt Processing Disabling of Interrupts by RTEMS, Interrupt Processing
|
||||
|
||||
@@ -41,7 +41,7 @@ RTEMS supports the PowerPC using a flat memory model with
|
||||
paging disabled. In this mode, the PowerPC automatically
|
||||
converts every address from a logical to a physical address
|
||||
each time it is used. The PowerPC uses information provided
|
||||
in the XXX to convert these addresses.
|
||||
in the Block Address Translation (BAT) to convert these addresses.
|
||||
|
||||
Implementations of the PowerPC architecture may be thirty-two or sixty-four bit.
|
||||
The PowerPC architecture supports a flat thirty-two or sixty-four bit address
|
||||
@@ -119,7 +119,7 @@ of data accesses:
|
||||
Doubleword load and store operations are only available in
|
||||
PowerPC CPU models which are sixty-four bit implementations.
|
||||
|
||||
RTEMS does not directly support any PowerPC Memory Management
|
||||
RTEMS does not directly support any PowerPC Memory Management
|
||||
Units, therefore, virtual memory or segmentation systems
|
||||
involving the PowerPC are not supported.
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ RTEMS supports the PowerPC using a flat memory model with
|
||||
paging disabled. In this mode, the PowerPC automatically
|
||||
converts every address from a logical to a physical address
|
||||
each time it is used. The PowerPC uses information provided
|
||||
in the XXX to convert these addresses.
|
||||
in the Block Address Translation (BAT) to convert these addresses.
|
||||
|
||||
Implementations of the PowerPC architecture may be thirty-two or sixty-four bit.
|
||||
The PowerPC architecture supports a flat thirty-two or sixty-four bit address
|
||||
@@ -119,7 +119,7 @@ of data accesses:
|
||||
Doubleword load and store operations are only available in
|
||||
PowerPC CPU models which are sixty-four bit implementations.
|
||||
|
||||
RTEMS does not directly support any PowerPC Memory Management
|
||||
RTEMS does not directly support any PowerPC Memory Management
|
||||
Units, therefore, virtual memory or segmentation systems
|
||||
involving the PowerPC are not supported.
|
||||
|
||||
|
||||
@@ -33,13 +33,48 @@ corresponds to that processor.
|
||||
@subheading PowerPC Architecture Documents
|
||||
|
||||
For information on the PowerPC architecture, refer to
|
||||
the following documents available from Motorola
|
||||
(http://www.moto.com):
|
||||
the following documents available from Motorola and IBM:
|
||||
|
||||
@itemize @bullet
|
||||
@item some PowerPC document shere
|
||||
|
||||
@item @cite{PowerPC Microprocessor Family: The Programming Environment}
|
||||
(Motorola Document MPRPPCFPE-01).
|
||||
|
||||
@item @cite{IBM PPC403GB Embedded Controller User's Manual}.
|
||||
|
||||
@item @cite{PoweRisControl MPC500 Family RCPU RISC Central Processing
|
||||
Unit Reference Manual} (Motorola Document RCPUURM/AD).
|
||||
|
||||
@item @cite{PowerPC 601 RISC Microprocessor User's Manual}
|
||||
(Motorola Document MPR601UM/AD).
|
||||
|
||||
@item @cite{PowerPC 603 RISC Microprocessor User's Manual}
|
||||
(Motorola Document MPR603UM/AD).
|
||||
|
||||
@item @cite{PowerPC 603e RISC Microprocessor User's Manual}
|
||||
(Motorola Document MPR603EUM/AD).
|
||||
|
||||
@item @cite{PowerPC 604 RISC Microprocessor User's Manual}
|
||||
(Motorola Document MPR604UM/AD).
|
||||
|
||||
@item @cite{PowerPC MPC821 Portable Systems Microprocessor User's Manual}
|
||||
(Motorola Document MPC821UM/AD).
|
||||
|
||||
@item @cite{PowerQUICC MPC860 User's Manual} (Motorola Document MPC860UM/AD).
|
||||
|
||||
|
||||
@end itemize
|
||||
|
||||
Motorola maintains an on-line electronic library for the PowerPC
|
||||
at the following URL:
|
||||
|
||||
@itemize @code{ }
|
||||
@item @cite{http://www.mot.com/powerpc/library/library.html}
|
||||
@end itemize
|
||||
|
||||
This site has a a wealth of information and examples. Many of the
|
||||
manuals are available from that site in electronic format.
|
||||
|
||||
@subheading PowerPC Processor Simulator Information
|
||||
|
||||
PSIM is a program which emulates the Instruction Set Architecture
|
||||
|
||||
@@ -70,7 +70,7 @@ management. However, interrupts should be disabled by setting
|
||||
the Processor Interrupt Level (pil) field of the psr to 15.
|
||||
RTEMS installs it's own Trap Table as part of initialization
|
||||
which is initialized with the contents of the Trap Table in
|
||||
place when the rtems_initialize_executive directive was invoked.
|
||||
place when the @code{rtems_initialize_executive} directive was invoked.
|
||||
Upon completion of executive initialization, interrupts are
|
||||
enabled.
|
||||
|
||||
@@ -82,7 +82,7 @@ In addition to the requirements described in the
|
||||
Board Support Packages chapter of the @value{LANGUAGE}
|
||||
Applications User's Manual for the reset code
|
||||
which is executed before the call to
|
||||
rtems_initialize executive, the SPARC version has the following
|
||||
@code{rtems_initialize_executive}, the SPARC version has the following
|
||||
specific requirements:
|
||||
|
||||
@itemize @bullet
|
||||
@@ -91,7 +91,7 @@ the SPARC remains in the supervisor state.
|
||||
|
||||
@item Must set stack pointer (sp) such that a minimum stack
|
||||
size of MINIMUM_STACK_SIZE bytes is provided for the
|
||||
rtems_initialize executive directive.
|
||||
@code{rtems_initialize_executive} directive.
|
||||
|
||||
@item Must disable all external interrupts (i.e. set the pil
|
||||
to 15).
|
||||
|
||||
@@ -70,7 +70,7 @@ management. However, interrupts should be disabled by setting
|
||||
the Processor Interrupt Level (pil) field of the psr to 15.
|
||||
RTEMS installs it's own Trap Table as part of initialization
|
||||
which is initialized with the contents of the Trap Table in
|
||||
place when the rtems_initialize_executive directive was invoked.
|
||||
place when the @code{rtems_initialize_executive} directive was invoked.
|
||||
Upon completion of executive initialization, interrupts are
|
||||
enabled.
|
||||
|
||||
@@ -82,7 +82,7 @@ In addition to the requirements described in the
|
||||
Board Support Packages chapter of the @value{LANGUAGE}
|
||||
Applications User's Manual for the reset code
|
||||
which is executed before the call to
|
||||
rtems_initialize executive, the SPARC version has the following
|
||||
@code{rtems_initialize_executive}, the SPARC version has the following
|
||||
specific requirements:
|
||||
|
||||
@itemize @bullet
|
||||
@@ -91,7 +91,7 @@ the SPARC remains in the supervisor state.
|
||||
|
||||
@item Must set stack pointer (sp) such that a minimum stack
|
||||
size of MINIMUM_STACK_SIZE bytes is provided for the
|
||||
rtems_initialize executive directive.
|
||||
@code{rtems_initialize_executive} directive.
|
||||
|
||||
@item Must disable all external interrupts (i.e. set the pil
|
||||
to 15).
|
||||
|
||||
Reference in New Issue
Block a user