forked from Imagelibrary/rtems
updated to properly reflect powerpc
This commit is contained in:
@@ -48,6 +48,10 @@ target processor are the same, different compilers may use
|
|||||||
different calling conventions. As a result, calling conventions
|
different calling conventions. As a result, calling conventions
|
||||||
are both processor and compiler dependent.
|
are both processor and compiler dependent.
|
||||||
|
|
||||||
|
RTEMS supports the Embedded Application Binary Interface (EABI)
|
||||||
|
calling convention. Documentation for EABI is available by sending
|
||||||
|
a message with a subject line of "EABI" to eabi@@goth.sis.mot.com.
|
||||||
|
|
||||||
@ifinfo
|
@ifinfo
|
||||||
@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
|
@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
|
||||||
@end ifinfo
|
@end ifinfo
|
||||||
@@ -61,102 +65,22 @@ are both processor and compiler dependent.
|
|||||||
@end ifinfo
|
@end ifinfo
|
||||||
|
|
||||||
This section discusses the programming model for the
|
This section discusses the programming model for the
|
||||||
SPARC architecture.
|
PowerPC architecture.
|
||||||
|
|
||||||
@ifinfo
|
@ifinfo
|
||||||
@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
|
@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
|
||||||
@end ifinfo
|
@end ifinfo
|
||||||
@subsection Non-Floating Point Registers
|
@subsection Non-Floating Point Registers
|
||||||
|
|
||||||
The SPARC architecture defines thirty-two
|
The PowerPC architecture defines thirty-two non-floating point registers
|
||||||
non-floating point registers directly visible to the programmer.
|
directly visible to the programmer. In thirty-two bit implementations, each
|
||||||
These are divided into four sets:
|
register is thirty-two bits wide. In sixty-four bit implementations, each
|
||||||
|
register is sixty-four bits wide.
|
||||||
|
|
||||||
@itemize @bullet
|
These registers are referred to as @code{gpr0} to @code{gpr31}.
|
||||||
@item input registers
|
|
||||||
|
|
||||||
@item local registers
|
Some of the registers serve defined roles in the EABI programming model.
|
||||||
|
The following table describes the role of each of these registers:
|
||||||
@item output registers
|
|
||||||
|
|
||||||
@item global registers
|
|
||||||
@end itemize
|
|
||||||
|
|
||||||
Each register is referred to by either two or three
|
|
||||||
names in the SPARC reference manuals. First, the registers are
|
|
||||||
referred to as r0 through r31 or with the alternate notation
|
|
||||||
r[0] through r[31]. Second, each register is a member of one of
|
|
||||||
the four sets listed above. Finally, some registers have an
|
|
||||||
architecturally defined role in the programming model which
|
|
||||||
provides an alternate name. The following table describes the
|
|
||||||
mapping between the 32 registers and the register sets:
|
|
||||||
|
|
||||||
@ifset use-ascii
|
|
||||||
@example
|
|
||||||
@group
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
| Register Number | Register Names | Description |
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
| 0 - 7 | g0 - g7 | Global Registers |
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
| 8 - 15 | o0 - o7 | Output Registers |
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
| 16 - 23 | l0 - l7 | Local Registers |
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
| 24 - 31 | i0 - i7 | Input Registers |
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
@end group
|
|
||||||
@end example
|
|
||||||
@end ifset
|
|
||||||
|
|
||||||
@ifset use-tex
|
|
||||||
@sp 1
|
|
||||||
@tex
|
|
||||||
\centerline{\vbox{\offinterlineskip\halign{
|
|
||||||
\vrule\strut#&
|
|
||||||
\hbox to 1.75in{\enskip\hfil#\hfil}&
|
|
||||||
\vrule#&
|
|
||||||
\hbox to 1.75in{\enskip\hfil#\hfil}&
|
|
||||||
\vrule#&
|
|
||||||
\hbox to 1.75in{\enskip\hfil#\hfil}&
|
|
||||||
\vrule#\cr
|
|
||||||
\noalign{\hrule}
|
|
||||||
&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule}
|
|
||||||
&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule}
|
|
||||||
&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule}
|
|
||||||
&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule}
|
|
||||||
&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule}
|
|
||||||
}}\hfil}
|
|
||||||
@end tex
|
|
||||||
@end ifset
|
|
||||||
|
|
||||||
@ifset use-html
|
|
||||||
@html
|
|
||||||
<CENTER>
|
|
||||||
<TABLE COLS=3 WIDTH="80%" BORDER=2>
|
|
||||||
<TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD>
|
|
||||||
<TD ALIGN=center><STRONG>Register Names</STRONG></TD>
|
|
||||||
<TD ALIGN=center><STRONG>Description</STRONG></TD>
|
|
||||||
<TR><TD ALIGN=center>0 - 7</TD>
|
|
||||||
<TD ALIGN=center>g0 - g7</TD>
|
|
||||||
<TD ALIGN=center>Global Registers</TD></TR>
|
|
||||||
<TR><TD ALIGN=center>8 - 15</TD>
|
|
||||||
<TD ALIGN=center>o0 - o7</TD>
|
|
||||||
<TD ALIGN=center>Output Registers</TD></TR>
|
|
||||||
<TR><TD ALIGN=center>16 - 23</TD>
|
|
||||||
<TD ALIGN=center>l0 - l7</TD>
|
|
||||||
<TD ALIGN=center>Local Registers</TD></TR>
|
|
||||||
<TR><TD ALIGN=center>24 - 31</TD>
|
|
||||||
<TD ALIGN=center>i0 - i7</TD>
|
|
||||||
<TD ALIGN=center>Input Registers</TD></TR>
|
|
||||||
</TABLE>
|
|
||||||
</CENTER>
|
|
||||||
@end html
|
|
||||||
@end ifset
|
|
||||||
|
|
||||||
As mentioned above, some of the registers serve
|
|
||||||
defined roles in the programming model. The following table
|
|
||||||
describes the role of each of these registers:
|
|
||||||
|
|
||||||
@ifset use-ascii
|
@ifset use-ascii
|
||||||
@example
|
@example
|
||||||
|
|||||||
@@ -48,6 +48,10 @@ target processor are the same, different compilers may use
|
|||||||
different calling conventions. As a result, calling conventions
|
different calling conventions. As a result, calling conventions
|
||||||
are both processor and compiler dependent.
|
are both processor and compiler dependent.
|
||||||
|
|
||||||
|
RTEMS supports the Embedded Application Binary Interface (EABI)
|
||||||
|
calling convention. Documentation for EABI is available by sending
|
||||||
|
a message with a subject line of "EABI" to eabi@@goth.sis.mot.com.
|
||||||
|
|
||||||
@ifinfo
|
@ifinfo
|
||||||
@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
|
@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
|
||||||
@end ifinfo
|
@end ifinfo
|
||||||
@@ -61,102 +65,22 @@ are both processor and compiler dependent.
|
|||||||
@end ifinfo
|
@end ifinfo
|
||||||
|
|
||||||
This section discusses the programming model for the
|
This section discusses the programming model for the
|
||||||
SPARC architecture.
|
PowerPC architecture.
|
||||||
|
|
||||||
@ifinfo
|
@ifinfo
|
||||||
@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
|
@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
|
||||||
@end ifinfo
|
@end ifinfo
|
||||||
@subsection Non-Floating Point Registers
|
@subsection Non-Floating Point Registers
|
||||||
|
|
||||||
The SPARC architecture defines thirty-two
|
The PowerPC architecture defines thirty-two non-floating point registers
|
||||||
non-floating point registers directly visible to the programmer.
|
directly visible to the programmer. In thirty-two bit implementations, each
|
||||||
These are divided into four sets:
|
register is thirty-two bits wide. In sixty-four bit implementations, each
|
||||||
|
register is sixty-four bits wide.
|
||||||
|
|
||||||
@itemize @bullet
|
These registers are referred to as @code{gpr0} to @code{gpr31}.
|
||||||
@item input registers
|
|
||||||
|
|
||||||
@item local registers
|
Some of the registers serve defined roles in the EABI programming model.
|
||||||
|
The following table describes the role of each of these registers:
|
||||||
@item output registers
|
|
||||||
|
|
||||||
@item global registers
|
|
||||||
@end itemize
|
|
||||||
|
|
||||||
Each register is referred to by either two or three
|
|
||||||
names in the SPARC reference manuals. First, the registers are
|
|
||||||
referred to as r0 through r31 or with the alternate notation
|
|
||||||
r[0] through r[31]. Second, each register is a member of one of
|
|
||||||
the four sets listed above. Finally, some registers have an
|
|
||||||
architecturally defined role in the programming model which
|
|
||||||
provides an alternate name. The following table describes the
|
|
||||||
mapping between the 32 registers and the register sets:
|
|
||||||
|
|
||||||
@ifset use-ascii
|
|
||||||
@example
|
|
||||||
@group
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
| Register Number | Register Names | Description |
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
| 0 - 7 | g0 - g7 | Global Registers |
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
| 8 - 15 | o0 - o7 | Output Registers |
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
| 16 - 23 | l0 - l7 | Local Registers |
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
| 24 - 31 | i0 - i7 | Input Registers |
|
|
||||||
+-----------------+----------------+------------------+
|
|
||||||
@end group
|
|
||||||
@end example
|
|
||||||
@end ifset
|
|
||||||
|
|
||||||
@ifset use-tex
|
|
||||||
@sp 1
|
|
||||||
@tex
|
|
||||||
\centerline{\vbox{\offinterlineskip\halign{
|
|
||||||
\vrule\strut#&
|
|
||||||
\hbox to 1.75in{\enskip\hfil#\hfil}&
|
|
||||||
\vrule#&
|
|
||||||
\hbox to 1.75in{\enskip\hfil#\hfil}&
|
|
||||||
\vrule#&
|
|
||||||
\hbox to 1.75in{\enskip\hfil#\hfil}&
|
|
||||||
\vrule#\cr
|
|
||||||
\noalign{\hrule}
|
|
||||||
&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule}
|
|
||||||
&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule}
|
|
||||||
&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule}
|
|
||||||
&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule}
|
|
||||||
&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule}
|
|
||||||
}}\hfil}
|
|
||||||
@end tex
|
|
||||||
@end ifset
|
|
||||||
|
|
||||||
@ifset use-html
|
|
||||||
@html
|
|
||||||
<CENTER>
|
|
||||||
<TABLE COLS=3 WIDTH="80%" BORDER=2>
|
|
||||||
<TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD>
|
|
||||||
<TD ALIGN=center><STRONG>Register Names</STRONG></TD>
|
|
||||||
<TD ALIGN=center><STRONG>Description</STRONG></TD>
|
|
||||||
<TR><TD ALIGN=center>0 - 7</TD>
|
|
||||||
<TD ALIGN=center>g0 - g7</TD>
|
|
||||||
<TD ALIGN=center>Global Registers</TD></TR>
|
|
||||||
<TR><TD ALIGN=center>8 - 15</TD>
|
|
||||||
<TD ALIGN=center>o0 - o7</TD>
|
|
||||||
<TD ALIGN=center>Output Registers</TD></TR>
|
|
||||||
<TR><TD ALIGN=center>16 - 23</TD>
|
|
||||||
<TD ALIGN=center>l0 - l7</TD>
|
|
||||||
<TD ALIGN=center>Local Registers</TD></TR>
|
|
||||||
<TR><TD ALIGN=center>24 - 31</TD>
|
|
||||||
<TD ALIGN=center>i0 - i7</TD>
|
|
||||||
<TD ALIGN=center>Input Registers</TD></TR>
|
|
||||||
</TABLE>
|
|
||||||
</CENTER>
|
|
||||||
@end html
|
|
||||||
@end ifset
|
|
||||||
|
|
||||||
As mentioned above, some of the registers serve
|
|
||||||
defined roles in the programming model. The following table
|
|
||||||
describes the role of each of these registers:
|
|
||||||
|
|
||||||
@ifset use-ascii
|
@ifset use-ascii
|
||||||
@example
|
@example
|
||||||
|
|||||||
@@ -40,8 +40,7 @@ handler.
|
|||||||
The default fatal error handler which is invoked by
|
The default fatal error handler which is invoked by
|
||||||
the fatal_error_occurred directive when there is no user handler
|
the fatal_error_occurred directive when there is no user handler
|
||||||
configured or the user handler returns control to RTEMS. The
|
configured or the user handler returns control to RTEMS. The
|
||||||
default fatal error handler disables processor interrupts to
|
default fatal error handler disables all processor exceptions,
|
||||||
level 15, places the error code in g1, and goes into an infinite
|
places the error code in r5, and goes into an infinite
|
||||||
loop to simulate a halt processor instruction.
|
loop to simulate a halt processor instruction.
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@@ -40,8 +40,7 @@ handler.
|
|||||||
The default fatal error handler which is invoked by
|
The default fatal error handler which is invoked by
|
||||||
the fatal_error_occurred directive when there is no user handler
|
the fatal_error_occurred directive when there is no user handler
|
||||||
configured or the user handler returns control to RTEMS. The
|
configured or the user handler returns control to RTEMS. The
|
||||||
default fatal error handler disables processor interrupts to
|
default fatal error handler disables all processor exceptions,
|
||||||
level 15, places the error code in g1, and goes into an infinite
|
places the error code in r5, and goes into an infinite
|
||||||
loop to simulate a halt processor instruction.
|
loop to simulate a halt processor instruction.
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@@ -36,16 +36,32 @@ of that model are described in this chapter.
|
|||||||
@end ifinfo
|
@end ifinfo
|
||||||
@section Flat Memory Model
|
@section Flat Memory Model
|
||||||
|
|
||||||
The SPARC architecture supports a flat 32-bit address
|
The PowerPC architecture supports a variety of memory models.
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
|
space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
|
||||||
gigabytes). Each address is represented by a 32-bit value and
|
gigabytes) in thirty-two bit implementations or 0xFFFFFFFFFFFFFFFF
|
||||||
is byte addressable. The address may be used to reference a
|
(XXX) in sixty-four bit implementations. Each address is represented
|
||||||
single byte, half-word (2-bytes), word (4 bytes), or doubleword
|
by either a thirty-two bit or sixty-four bit value and is byte addressable.
|
||||||
(8 bytes). Memory accesses within this address space are
|
The address may be used to reference a single byte, half-word
|
||||||
performed in big endian fashion by the SPARC. Memory accesses
|
(2-bytes), word (4 bytes), or in sixty-four bit implementations a
|
||||||
which are not properly aligned generate a "memory address not
|
doubleword (8 bytes). Memory accesses within the address space are
|
||||||
aligned" trap (type number 7). The following table lists the
|
performed in big or little endian fashion by the PowerPC based
|
||||||
alignment requirements for a variety of data accesses:
|
upon the current setting of the Little-endian mode enable bit (LE)
|
||||||
|
in the Machine State Register (MSR). While the processor is in
|
||||||
|
big endian mode, memory accesses which are not properly aligned
|
||||||
|
generate an "alignment exception" (vector offset 0x00600). In
|
||||||
|
little endian mode, the PowerPC architecture does not require
|
||||||
|
the processor to generate alignment exceptions.
|
||||||
|
|
||||||
|
The following table lists the alignment requirements for a variety
|
||||||
|
of data accesses:
|
||||||
|
|
||||||
@ifset use-ascii
|
@ifset use-ascii
|
||||||
@example
|
@example
|
||||||
@@ -100,20 +116,10 @@ alignment requirements for a variety of data accesses:
|
|||||||
@end html
|
@end html
|
||||||
@end ifset
|
@end ifset
|
||||||
|
|
||||||
Doubleword load and store operations must use a pair
|
Doubleword load and store operations are only available in
|
||||||
of registers as their source or destination. This pair of
|
PowerPC CPU models which are sixty-four bit implementations.
|
||||||
registers must be an adjacent pair of registers with the first
|
|
||||||
of the pair being even numbered. For example, a valid
|
|
||||||
destination for a doubleword load might be input registers 0 and
|
|
||||||
1 (i0 and i1). The pair i1 and i2 would be invalid. [NOTE:
|
|
||||||
Some assemblers for the SPARC do not generate an error if an odd
|
|
||||||
numbered register is specified as the beginning register of the
|
|
||||||
pair. In this case, the assembler assumes that what the
|
|
||||||
programmer meant was to use the even-odd pair which ends at the
|
|
||||||
specified register. This may or may not have been a correct
|
|
||||||
assumption.]
|
|
||||||
|
|
||||||
RTEMS does not support any SPARC Memory Management
|
RTEMS does not directly support any PowerPC Memory Management
|
||||||
Units, therefore, virtual memory or segmentation systems
|
Units, therefore, virtual memory or segmentation systems
|
||||||
involving the SPARC are not supported.
|
involving the PowerPC are not supported.
|
||||||
|
|
||||||
|
|||||||
@@ -36,16 +36,32 @@ of that model are described in this chapter.
|
|||||||
@end ifinfo
|
@end ifinfo
|
||||||
@section Flat Memory Model
|
@section Flat Memory Model
|
||||||
|
|
||||||
The SPARC architecture supports a flat 32-bit address
|
The PowerPC architecture supports a variety of memory models.
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
|
space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
|
||||||
gigabytes). Each address is represented by a 32-bit value and
|
gigabytes) in thirty-two bit implementations or 0xFFFFFFFFFFFFFFFF
|
||||||
is byte addressable. The address may be used to reference a
|
(XXX) in sixty-four bit implementations. Each address is represented
|
||||||
single byte, half-word (2-bytes), word (4 bytes), or doubleword
|
by either a thirty-two bit or sixty-four bit value and is byte addressable.
|
||||||
(8 bytes). Memory accesses within this address space are
|
The address may be used to reference a single byte, half-word
|
||||||
performed in big endian fashion by the SPARC. Memory accesses
|
(2-bytes), word (4 bytes), or in sixty-four bit implementations a
|
||||||
which are not properly aligned generate a "memory address not
|
doubleword (8 bytes). Memory accesses within the address space are
|
||||||
aligned" trap (type number 7). The following table lists the
|
performed in big or little endian fashion by the PowerPC based
|
||||||
alignment requirements for a variety of data accesses:
|
upon the current setting of the Little-endian mode enable bit (LE)
|
||||||
|
in the Machine State Register (MSR). While the processor is in
|
||||||
|
big endian mode, memory accesses which are not properly aligned
|
||||||
|
generate an "alignment exception" (vector offset 0x00600). In
|
||||||
|
little endian mode, the PowerPC architecture does not require
|
||||||
|
the processor to generate alignment exceptions.
|
||||||
|
|
||||||
|
The following table lists the alignment requirements for a variety
|
||||||
|
of data accesses:
|
||||||
|
|
||||||
@ifset use-ascii
|
@ifset use-ascii
|
||||||
@example
|
@example
|
||||||
@@ -100,20 +116,10 @@ alignment requirements for a variety of data accesses:
|
|||||||
@end html
|
@end html
|
||||||
@end ifset
|
@end ifset
|
||||||
|
|
||||||
Doubleword load and store operations must use a pair
|
Doubleword load and store operations are only available in
|
||||||
of registers as their source or destination. This pair of
|
PowerPC CPU models which are sixty-four bit implementations.
|
||||||
registers must be an adjacent pair of registers with the first
|
|
||||||
of the pair being even numbered. For example, a valid
|
|
||||||
destination for a doubleword load might be input registers 0 and
|
|
||||||
1 (i0 and i1). The pair i1 and i2 would be invalid. [NOTE:
|
|
||||||
Some assemblers for the SPARC do not generate an error if an odd
|
|
||||||
numbered register is specified as the beginning register of the
|
|
||||||
pair. In this case, the assembler assumes that what the
|
|
||||||
programmer meant was to use the even-odd pair which ends at the
|
|
||||||
specified register. This may or may not have been a correct
|
|
||||||
assumption.]
|
|
||||||
|
|
||||||
RTEMS does not support any SPARC Memory Management
|
RTEMS does not directly support any PowerPC Memory Management
|
||||||
Units, therefore, virtual memory or segmentation systems
|
Units, therefore, virtual memory or segmentation systems
|
||||||
involving the SPARC are not supported.
|
involving the PowerPC are not supported.
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user