Imagelibrary/rtems
1
0
Fork 1
mirror of https://gitlab.rtems.org/rtems/rtos/rtems.git synced 2025-12-06 07:33:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

updated to properly reflect powerpc

Browse Source
This commit is contained in:
Joel Sherrill
1997-07-02 17:49:23 +00:00
parent 563f7e0f1c
commit ce90366e29
6 changed files with 86 additions and 228 deletions
Download Patch File Download Diff File Expand all files Collapse all files

100
doc/supplements/powerpc/callconv.t
View File

@@ -48,6 +48,10 @@ target processor are the same, different compilers may use
different calling conventions. As a result, calling conventions
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
@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
@end ifinfo
@@ -61,102 +65,22 @@ are both processor and compiler dependent.
@end ifinfo
This section discusses the programming model for the
SPARC architecture.
PowerPC architecture.
@ifinfo
@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
@end ifinfo
@subsection Non-Floating Point Registers
The SPARC architecture defines thirty-two
non-floating point registers directly visible to the programmer.
These are divided into four sets:
The PowerPC architecture defines thirty-two non-floating point registers
directly visible to the programmer. In thirty-two bit implementations, each
register is thirty-two bits wide. In sixty-four bit implementations, each
register is sixty-four bits wide.
@itemize @bullet
@item input registers
These registers are referred to as @code{gpr0} to @code{gpr31}.
@item local 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:
Some of the registers serve defined roles in the EABI programming model.
The following table describes the role of each of these registers:
@ifset use-ascii
@example

100
doc/supplements/powerpc/callconv.texi
View File

@@ -48,6 +48,10 @@ target processor are the same, different compilers may use
different calling conventions. As a result, calling conventions
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
@node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions
@end ifinfo
@@ -61,102 +65,22 @@ are both processor and compiler dependent.
@end ifinfo
This section discusses the programming model for the
SPARC architecture.
PowerPC architecture.
@ifinfo
@node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model
@end ifinfo
@subsection Non-Floating Point Registers
The SPARC architecture defines thirty-two
non-floating point registers directly visible to the programmer.
These are divided into four sets:
The PowerPC architecture defines thirty-two non-floating point registers
directly visible to the programmer. In thirty-two bit implementations, each
register is thirty-two bits wide. In sixty-four bit implementations, each
register is sixty-four bits wide.
@itemize @bullet
@item input registers
These registers are referred to as @code{gpr0} to @code{gpr31}.
@item local 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:
Some of the registers serve defined roles in the EABI programming model.
The following table describes the role of each of these registers:
@ifset use-ascii
@example

5
doc/supplements/powerpc/fatalerr.t
View File

@@ -40,8 +40,7 @@ handler.
The default fatal error handler which is invoked by
the 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 processor interrupts to
level 15, places the error code in g1, and goes into an infinite
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.

5
doc/supplements/powerpc/fatalerr.texi
View File

@@ -40,8 +40,7 @@ handler.
The default fatal error handler which is invoked by
the 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 processor interrupts to
level 15, places the error code in g1, and goes into an infinite
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.

52
doc/supplements/powerpc/memmodel.t
View File

@@ -36,16 +36,32 @@ of that model are described in this chapter.
@end ifinfo
@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
gigabytes). Each address is represented by a 32-bit value and
is byte addressable. The address may be used to reference a
single byte, half-word (2-bytes), word (4 bytes), or doubleword
(8 bytes). Memory accesses within this address space are
performed in big endian fashion by the SPARC. Memory accesses
which are not properly aligned generate a "memory address not
aligned" trap (type number 7). The following table lists the
alignment requirements for a variety of data accesses:
gigabytes) in thirty-two bit implementations or 0xFFFFFFFFFFFFFFFF
(XXX) in sixty-four bit implementations. Each address is represented
by either a thirty-two bit or sixty-four bit value and is byte addressable.
The address may be used to reference a single byte, half-word
(2-bytes), word (4 bytes), or in sixty-four bit implementations a
doubleword (8 bytes). Memory accesses within the address space are
performed in big or little endian fashion by the PowerPC based
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
@example
@@ -100,20 +116,10 @@ alignment requirements for a variety of data accesses:
@end html
@end ifset
Doubleword load and store operations must use a pair
of registers as their source or destination. This pair of
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.]
Doubleword load and store operations are only available in
PowerPC CPU models which are sixty-four bit implementations.
RTEMS does not support any SPARC Memory Management
RTEMS does not directly support any PowerPC Memory Management
Units, therefore, virtual memory or segmentation systems
involving the SPARC are not supported.
involving the PowerPC are not supported.

52
doc/supplements/powerpc/memmodel.texi
View File

@@ -36,16 +36,32 @@ of that model are described in this chapter.
@end ifinfo
@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
gigabytes). Each address is represented by a 32-bit value and
is byte addressable. The address may be used to reference a
single byte, half-word (2-bytes), word (4 bytes), or doubleword
(8 bytes). Memory accesses within this address space are
performed in big endian fashion by the SPARC. Memory accesses
which are not properly aligned generate a "memory address not
aligned" trap (type number 7). The following table lists the
alignment requirements for a variety of data accesses:
gigabytes) in thirty-two bit implementations or 0xFFFFFFFFFFFFFFFF
(XXX) in sixty-four bit implementations. Each address is represented
by either a thirty-two bit or sixty-four bit value and is byte addressable.
The address may be used to reference a single byte, half-word
(2-bytes), word (4 bytes), or in sixty-four bit implementations a
doubleword (8 bytes). Memory accesses within the address space are
performed in big or little endian fashion by the PowerPC based
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
@example
@@ -100,20 +116,10 @@ alignment requirements for a variety of data accesses:
@end html
@end ifset
Doubleword load and store operations must use a pair
of registers as their source or destination. This pair of
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.]
Doubleword load and store operations are only available in
PowerPC CPU models which are sixty-four bit implementations.
RTEMS does not support any SPARC Memory Management
RTEMS does not directly support any PowerPC Memory Management
Units, therefore, virtual memory or segmentation systems
involving the SPARC are not supported.
involving the PowerPC are not supported.