systemsoftware
/
ELFv2-ABI
30
1
Fork 0
Code Issues 10 Pull Requests Projects Releases Wiki Activity

Round 2 documentation review updates

Browse Source 
Pervasive corrections:
- Miscellaneous formating
- Insert space in () and []
- Correct footnote spacing
- Use <note> tag for notes
- Cleanup spacing around <anchor> tags
- Add a couple missing paragraphs
- Correct list nesting in a couple places
- Correct subsection nesting
- Correct spacing around subscript, superscripts, and emphasis tags
- Bolding of some <emphasis> statements
- Build xref links for manual footnotes in a couple tables and remove explicit numerals.
- Return POWER ISA 3.0 text

Specific updates:
- Update a couple tables on bit/byte positions in chapter 2
- Return figures in place of some tables for the coding examples in
  chapter 2

Signed-off-by: Jeff Scheel <scheel@us.ibm.com>
master
Jeff Scheel 8 years ago
parent 2cb6450f10
commit 5eba3e1cb1
8 changed files with 2697 additions and 1381 deletions
Show Stats Download Patch File Download Diff File

2163
specification/app_a.xml
View File

File diff suppressed because it is too large Load Diff

14
specification/app_b.xml
Unescape Escape View File

@ -18,9 +18,8 @@ xml:id="dbdoclet.50655245_pgfId-1450875" revisionflag="added">
BCD values are stored in memory as contiguous arrays of 1 - 16
bytes.</para>
<note>
<para>BCD built-in functions are valid only when -
<emphasis role="bold">march</emphasis> or -
<emphasis role="bold">qarch</emphasis> is set to target POWER8 processors or
<para>BCD built-in functions are valid only when -<emphasis role="bold">march</emphasis> or
-<emphasis role="bold">qarch</emphasis> is set to target POWER8 processors or
later.</para>
</note>
<para>
@ -424,8 +423,7 @@ xml:id="dbdoclet.50655245_pgfId-1450875" revisionflag="added">
<row>
<entry align="center">
<para>
<emphasis role="bold">Macro
<footnote xml:id="tabb2fna"><para>Or static inline function.</para></footnote></emphasis>
<emphasis role="bold">Macro<footnote xml:id="tabb2fna"><para>Or static inline function.</para></footnote></emphasis>
</para>
</entry>
<entry>
@ -529,8 +527,7 @@ xml:id="dbdoclet.50655245_pgfId-1450875" revisionflag="added">
<para>bcd_xl(a,b)</para>
</entry>
<entry>
<para>(bcd)vec_xl_len_r(a,b)
<footnote xml:id="tabb2fnb"><para>Optionaly, __builtin_ldrmb (a,b) for previous
<para>(bcd)vec_xl_len_r(a,b)<footnote xml:id="tabb2fnb"><para>Optionaly, __builtin_ldrmb (a,b) for previous
generations of XL compilers.</para></footnote>
</para>
</entry>
@ -540,8 +537,7 @@ xml:id="dbdoclet.50655245_pgfId-1450875" revisionflag="added">
<para>bcd_xst(a,b)</para>
</entry>
<entry>
<para>(bcd)vec_xst_len_r(a,b)
<footnote xml:id="tabb2fnc"><para>Optionaly, __builti_strmb (a,b) for previous
<para>(bcd)vec_xst_len_r(a,b)<footnote xml:id="tabb2fnc"><para>Optionaly, __builti_strmb (a,b) for previous
generatoin f XL compilers.</para></footnote>
</para>
</entry>

5
specification/ch_1.xml
Unescape Escape View File

@ -27,7 +27,7 @@
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640574" />).
OpenPOWER-compliant processors in the 64-bit Power Architecture can execute
in either big-endian or little-endian mode. Executables and
executable-generated data (in general) that subscribes to either byte
executable-generated data (in general) that subscribe to either byte
ordering is not portable to a system running in the other mode.</para>
<itemizedlist>
<listitem>
@ -155,8 +155,7 @@
</emphasis></para>
</listitem>
<listitem>
<para>ELF Assembly User’s Guide, Fourth edition, IBM, 2000.</para>
<para>
<para>ELF Assembly User’s Guide, Fourth edition, IBM, 2000.
<emphasis>
<link xl:href="https://www-03.ibm.com/technologyconnect/tgcm/TGCMFileServlet.wss/assem_um.pdf?id=109917A251EFD64C872569D900656D07&amp;linkid=1h3000&amp;c_t=md515o6ntgh671shz9ioar20oyfp1grs">


597
specification/ch_2.xml
Unescape Escape View File

@ -1588,16 +1588,16 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para></para>
</entry>
<entry align="right" colsep="1">
<para>3</para>
<para></para>
</entry>
<entry align="left" colsep="0">
<para></para>
<para>3</para>
</entry>
<entry align="center" colsep="0">
<para></para>
</entry>
<entry align="right" colsep="1">
<para>4</para>
<para></para>
</entry>
</row>
<row>
@ -2658,8 +2658,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para></para>
</entry>
<entry>
<para>vector unsigned long
<footnote xml:id="vlong">
<para>vector unsigned long<footnote xml:id="vlong">
<para>The vector long types are deprecated due to their
ambiguity between 32-bit and 64-bit environments. The use
of the vector long long types is preferred.</para>
@ -2681,8 +2680,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para></para>
</entry>
<entry>
<para>vector signed long
<footnoteref linkend="vlong" /></para>
<para>vector signed long<footnoteref linkend="vlong" /></para>
<para>vector signed long long</para>
</entry>
<entry>
@ -2700,8 +2698,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para></para>
</entry>
<entry>
<para>vector bool long
<footnoteref linkend="vlong" /></para>
<para>vector bool long<footnoteref linkend="vlong" /></para>
<para>vector bool long long</para>
</entry>
<entry>
@ -2807,8 +2804,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>Elements of Boolean vector data types must have a value
corresponding to all bits set to either 0 or 1. The result of
computations on Boolean vectors, where at least one element is not
well formed
<footnote xml:id="pgfId-1172304">
well formed<footnote xml:id="pgfId-1172304">
<para>An element is well formed if it has all bits set to 0 or all
bits set to 1.</para>
</footnote>, is undefined for all vector elements.</para>
@ -3517,16 +3513,16 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>6</para>
</entry>
<entry align="left" colsep="0">
<para>15</para>
<para></para>
</entry>
<entry align="center" colsep="0">
<para></para>
<para>5</para>
</entry>
<entry align="right" colsep="1">
<para></para>
</entry>
<entry align="left" colsep="0">
<para>5</para>
<para></para>
</entry>
<entry align="center" colsep="0">
<para></para>
@ -3637,7 +3633,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para></para>
</entry>
<entry align="right" colsep="1">
<para>2</para>
<para>1</para>
</entry>
<entry align="left" colsep="0">
<para></para>
@ -3646,7 +3642,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para></para>
</entry>
<entry align="right" colsep="1">
<para>1</para>
<para>0</para>
</entry>
</row>
<row>
@ -4214,8 +4210,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>r2</para>
</entry>
<entry>
<para>Nonvolatile
<footnote>
<para>Nonvolatile<footnote>
<para>Register r2 is nonvolatile with respect to calls
between functions in the same compilation unit. It is saved
and restored by code inserted by the linker resolving a
@ -4278,8 +4273,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</row>
<row>
<entry>
<para>r14 - r31
<footnote>
<para>r14 - r31<footnote>
<para>If a function needs a frame pointer, assigning r31 to
the role of the frame pointer is recommended.</para>
</footnote></para>
@ -4491,8 +4485,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</listitem>
</itemizedlist>

<para>
<emphasis role="bold"><phrase revisionflag="added">Note</phrase><phrase revisionflag="deleted">Erratum</phrase>:</emphasis>
<note>
<para><emphasis role="bold"><phrase revisionflag="deleted">Erratum:</phrase></emphasis>
When executing an
<emphasis role="bold">mfocr</emphasis> instruction, the POWER8 processor does not
implement the behavior described in the "Fixed-Point Invalid Forms
@ -4507,15 +4501,14 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<emphasis role="bold">mfocr</emphasis> to avoid corruption of the resulting
(partial) condition register word.</para>
<para>This erratum does not apply to the POWER9 processor.</para>
</note>

<para>
<anchor xml:id="dbdoclet.50655240_Power-ISA-version-and-the-user-s-manual"
<para><anchor xml:id="dbdoclet.50655240_Power-ISA-version-and-the-user-s-manual"
xreflabel="" />For more information, see
<citetitle>Power ISA</citetitle>, version 3.0 and "Fixed-Point Invalid
Forms and Undefined Conditions" in
<citetitle>POWER9 Processor User's Manual.</citetitle></para>
<para>
<anchor xml:id="dbdoclet.50655240_page33" xreflabel="" /> In
<para><anchor xml:id="dbdoclet.50655240_page33" xreflabel="" />In
OpenPOWER-compliant processors, floating-point and vector functions are
implemented using a unified vector-scalar model. As shown in
<xref linkend="dbdoclet.50655240_97144" /> and
@ -4528,310 +4521,26 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
with VMX instructions to refer to a 32-register subset of 128-bit wide
registers.</para>

<table frame="top" pgwide="1" colsep="1" rowsep="1"
xml:id="dbdoclet.50655240_97144">
<figure pgwide="1" xml:id="dbdoclet.50655240_97144">
<title>Floating-Point Registers as Part of VSRs</title>
<tgroup cols="6">
<colspec colname="c1" colwidth="10*" />
<colspec colname="c2" colwidth="22*" />
<colspec colname="c3" colwidth="22*" />
<colspec colname="c4" colwidth="22*" />
<colspec colname="c5" colwidth="22*" />
<colspec colname="c6" colwidth="0*" />
<tbody>
<row>
<entry align="right" rowsep="0">
<para>VSR(0)</para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>FPR[0]</para>
</entry>
<entry nameend="c5" namest="c4" colsep="1">
<para />
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(1)</para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>FPR1]</para>
</entry>
<entry nameend="c5" namest="c4" colsep="1">
<para />
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry rowsep="0">
<para></para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>
<emphasis role="bold">...</emphasis>
</para>
<para>
<emphasis role="bold">...</emphasis>
</para>
</entry>
<entry nameend="c5" namest="c4" colsep="1">
<para />
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(30)</para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>FPR[30]</para>
</entry>
<entry nameend="c5" namest="c4" colsep="1">
<para />
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(31)</para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>FP[31]</para>
</entry>
<entry nameend="c5" namest="c4" colsep="1">
<para />
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(32)</para>
</entry>
<entry nameend="c5" namest="c2" colsep="1">
<para></para>
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(33)</para>
</entry>
<entry nameend="c5" namest="c2" colsep="1">
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
<para></para>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para></para>
<para></para>
</entry>
<entry nameend="c5" namest="c2" align="center" colsep="1">
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
<para>
<emphasis role="bold">...</emphasis>
</para>
<para>
<emphasis role="bold">...</emphasis>
</para>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(62)</para>
</entry>
<entry nameend="c5" namest="c2" colsep="1">
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
<para></para>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right">
<para>VSR(63)</para>
</entry>
<entry nameend="c5" namest="c2" colsep="1">
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
<para />
</entry>
<entry></entry>
</row>
<row>
<entry rowsep="0">
<para></para>
</entry>
<entry align="left" colsep="0">
<para>0</para>
</entry>
<entry align="right">
<para>63</para>
</entry>
<entry align="left" colsep="0">
<para>127</para>
</entry>
<entry align="right" colsep="1">
<para>255</para>
</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-16.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>

<table frame="top" pgwide="1" xml:id="dbdoclet.50655240_56800" rowsep="1" colsep="1">
<figure pgwide="1" xml:id="dbdoclet.50655240_56800">
<title>Vector Registers as Part of VSRs</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="10*" />
<colspec colname="c2" colwidth="44*" />
<colspec colname="c3" colwidth="44*" />
<colspec colname="c4" colwidth="0*" />
<tbody>
<row>
<entry align="right" rowsep="0">
<para>VSR(0)</para>
</entry>
<entry nameend="c3" namest="c2">
<para></para>
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(1)</para>
</entry>
<entry nameend="c3" namest="c2">
<para></para>
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para></para>
<para></para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>
<emphasis role="bold">...</emphasis>
</para>
<para>
<emphasis role="bold">...</emphasis>
</para>
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(30)</para>
</entry>
<entry nameend="c3" namest="c2">
<para></para>
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(31)</para>
</entry>
<entry nameend="c3" namest="c2">
<para></para>
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(32)</para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>VR[0]</para>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(33)</para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>VR[1]</para>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para></para>
<para></para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>
<emphasis role="bold">...</emphasis>
</para>
<para>
<emphasis role="bold">...</emphasis>
</para>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right" rowsep="0">
<para>VSR(62)</para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>VR[30]</para>
</entry>
<entry rowsep="0"></entry>
</row>
<row>
<entry align="right">
<para>VSR(63)</para>
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>VR[31]</para>
</entry>
<entry></entry>
</row>
<row>
<entry>
<para></para>
</entry>
<entry align="left" colsep="0">
<para>0</para>
</entry>
<entry align="right">
<para>127</para>
</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-17.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>

<para>The classic floating-point repertoire consists of 32
floating-point registers, each 64 bits wide, and an associated
special-purpose register to provide floating-point status and control.
@ -5312,7 +5021,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</mediaobject>
</figure>
<para>In
<xref linkend="dbdoclet.50655240_page39" /> the white areas indicate an
<xref linkend="dbdoclet.50655240_97610" xrefstyle="select: nopage"/> the white areas indicate an
optional save area of the stack frame. For a description of the optional
save areas described by this ABI, see
<xref linkend="dbdoclet.50655240_15141" />.</para>
@ -5452,6 +5161,15 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>If a function changes the value in any nonvolatile floating-point
register fN, it shall first save the value in fN in the Floating-Point
Register Save Area and restore the register upon function exit.</para>
<para>If full unwind information such as
<emphasis role="underline">DWARF</emphasis> is present, registers can be
saved in arbitrary locations in the stack
frame. If the system floating-point register save and restore
functions are to be used, the floating-point registers
shall be saved in a contiguous range. Floating-point register fN
is saved in the doubleword located 8 × (32 – N) bytes before the back-chain
word of the previous frame, as shown in
<xref linkend="dbdoclet.50655240_97610" /></para>
<para>The Floating-Point Register Save Area is always doubleword
aligned. The size of the Floating-Point Register Save Area depends upon
the number of floating-point registers that must be saved. If no
@ -5464,15 +5182,14 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
general-purpose register rN, it shall first save the value in rN in the
General-Purpose Register Save Area and restore the register upon
function exit.</para>
<para>If full unwind information such as
<emphasis role="underline">DWARF</emphasis> is present, registers can be
<para>If full unwind information such as DWARF is present, registers can be
saved in arbitrary locations in the stack frame. If the system
floating-point register save and restore functions are to be used, the
floading-point registers shall be saved in a contiguous range.
floating-point registers shall be saved in a contiguous range.
Floating-point register fN is saved in the doubleword located 8 x
(32-N) bytes before the back-chain word of the previous frame, as shown
in
<xref linkend="dbdoclet.50655240_97610" /></para>
<xref linkend="dbdoclet.50655240_97610" />.</para>
<para>The General-Purpose Register Save Area is always doubleword
aligned. The size of the General-Purpose Register Save Area depends
upon the number of general registers that must be saved. If no
@ -5483,15 +5200,14 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>If a function changes the value in any nonvolatile vector
register vN, it shall first save the value in vN in the Vector Register
Save Area and restore the register upon function exit.</para>
<para>If full unwind information such as
<emphasis role="underline">DWARF</emphasis> is present, registers can be
<para>If full unwind information such as DWARF is present, registers can be
saved in arbitrary locations in the stack frame. If the system vector
register save and restore functions are to be used, the vector
registers shall be saved in a contiguous range. Vector register vN is
saved in the doubleword located 16 x (32-N) bytes before the
General-Purpose Register Save Areas plus alignment padding, as shown in
<xref linkend="dbdoclet.50655240_97610" /></para>
<xref linkend="dbdoclet.50655240_97610" />.</para>
<para>The Vector Register Save Area is always quadword aligned. If
necessary to ensure suitable alignment of the vector save area, a
padding doubleword may be introduced between the vector register and
@ -5599,8 +5315,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<listitem>
<para>When 128-bit integer types are passed by value, map each to
two consecutive GPRs, two consecutive doublewords, or a GPR and a
doubleword.
<footnote xml:id="pgfId-1151735">
doubleword.<footnote xml:id="pgfId-1151735">
<para>In big-endian environments, the most-significant doubleword
of the quadword (__int128) parameter is stored in the lower
numbered GPR or parameter word. The least-significant doubleword
@ -5653,8 +5368,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<listitem>
<para>Map fixed-size aggregates and unions passed by value to as
many doublewords of the Parameter Save Area as the value uses in
memory. Align aggregates and unions as follows:</para>
</listitem>
memory. Align aggregates and unions as follows:
<itemizedlist>
<listitem>
<para>Aggregates that contain qualified floating-point or vector
arguments are normally aligned at the alignment of their base type.
@ -5669,7 +5384,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>The alignment will never be larger than the stack frame
alignment (16 bytes).</para>
</listitem>
</itemizedlist>
</itemizedlist></para>
<para>This might result in doublewords being skipped for alignment.
When a doubleword in the Parameter Save Area (or its GPR copy) contains
at least a portion of a structure, that doubleword must contain all
@ -5677,7 +5392,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
can either be completely valid, or completely invalid, but not
partially valid and invalid, except in the last doubleword where
invalid padding may be present.)</para>
<itemizedlist>
</listitem>
<listitem>
<para>Pad an aggregate or union smaller than one doubleword in
size<phrase revisionflag="added">, but having a non-zero size,</phrase>
@ -5773,8 +5488,6 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<listitem>
<para>A member of a homogeneous aggregate of multiple like data types
passed in up to eight floating-point registers</para>
</listitem>
</itemizedlist>
<para>A homogeneous aggregate can consist of a variety of nested
constructs including structures, unions, and array members, which shall
be traversed to determine the types and number of members of the base
@ -5791,6 +5504,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
vector registers if parameters of that type would be passed in vector
registers. They are passed as if each member was specified as a separate
parameter.</para>
</listitem>
</itemizedlist>
<para>A qualified vector argument corresponds to:</para>
<itemizedlist>
<listitem>
@ -5804,8 +5519,6 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>Any future type requiring 16-byte alignment (see
<xref linkend="dbdoclet.50655240_15141" />) or processed in vector
registers</para>
</listitem>
</itemizedlist>
<para>For the purpose of determining a qualified floating-point argument,
_Float128 shall be considered a vector data type. In addition, _Float128
is like a vector data type for determining if multiple aggregate members
@ -5819,6 +5532,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
homogeneous unions, different union alternatives may have different
sizes, provided that all union members are homogeneous with respect to
each other.)</para>
</listitem>
</itemizedlist>
<note>
<para>Floating-point and vector aggregates that contain padding
words and integer fields with a width of 0 should not be treated as
@ -5851,8 +5566,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
size of the corresponding in-memory representation of the passed
argument's type.</para>
<para><phrase revisionflag="changed">The parameter size is always rounded up to the next multiple of a
doubleword.</phrase>
<footnote xml:id="pgfId-1184124" revisionflag="added">
doubleword.</phrase><footnote xml:id="pgfId-1184124" revisionflag="added">
<para>Consequently, each parameter of a non-zero size is allocated to
at least one doubleword.</para>
</footnote></para>
@ -6373,8 +6087,7 @@ s6 - 72 (stored)</programlisting>
architectures that pass some of the arguments in registers. The Power
Architecture is one of the architectures that passes some of the
arguments in registers.</para>
<para>
<anchor xml:id="dbdoclet.50655240_page61" xreflabel="" /> The parameter
<para><anchor xml:id="dbdoclet.50655240_page61" xreflabel="" />The parameter
list may be zero length and is only allocated when parameters are
spilled, when a function has unnamed parameters, or when no prototype is
provided. When the Parameter Save Area is allocated, the Parameter Save
@ -6387,8 +6100,7 @@ s6 - 72 (stored)</programlisting>
registers as if the return value was the first named input argument to a
function unless the return value is a nonhomogeneous aggregate larger
than 2 doublewords or a homogeneous aggregate with more than eight
registers.
<footnote xml:id="pgfId-1163117">
registers.<footnote xml:id="pgfId-1163117">
<para>For a definition of homogeneous aggregates, see
<xref linkend="dbdoclet.50655240_60588" />.</para>
</footnote> (Homogeneous aggregates are arrays, structs, or unions of a
@ -6572,9 +6284,13 @@ lvx v1, 0, r12</programlisting>
and branch instructions that use registers. In both cases, absolute
addressing is not required.</para>
</listitem>
<listitem xml:id="dbdoclet.50655240_page64">
<para>
<xref linkend="dbdoclet.50655242_page119" />
<listitem>
<para>Second, when absolute addressing is required, the value can be
computed with a Global Offset Table (GOT), which holds the information
for address computation. Static and const references can be
accessed using a TOC pointer relative addressing model, while (shared)
extern references must be accessed using the GOT-indirect addressing
scheme. Both addressing schemes require a TOC pointer to be initialized.
</para>
</listitem>
</itemizedlist>
@ -6892,23 +6608,20 @@ or r0, r0, r1</programlisting>
<xref linkend="dbdoclet.50655243_49403" />.</para>
<section xml:id="dbdoclet.50655240_41483">
<title>GPR Save and Restore Functions</title>
<para>Each _savegpr0_
<emphasis>N</emphasis> routine saves the general registers from r
<emphasis>N</emphasis>- r31, inclusive. Each routine also saves the LR.
<para>Each _savegpr0_<emphasis>N</emphasis> routine saves the general registers from
r<emphasis>N</emphasis>- r31, inclusive. Each routine also saves the LR.
The stack frame must not have been allocated yet. When the routine is
called, r1 contains the address of the word immediately beyond the end
of the general register save area, and r0 must contain the value of the
LR on function entry.</para>
<para>The _restgpr0_
<emphasis>N</emphasis> routines restore the general registers from r
<emphasis>N</emphasis>- r31, and then return to their caller's caller.
<para>The _restgpr0_<emphasis>N</emphasis> routines restore the general registers from
r<emphasis>N</emphasis>- r31, and then return to their caller's caller.
The caller's stack frame must already have been deallocated. When the
routine is called, r1 contains the address of the word immediately
beyond the end of the general register save area, and the LR must
contain the return address.</para>
<para>A sample implementation of _savegpr0_
<emphasis>N</emphasis> and _restgpr0_
<emphasis>N</emphasis> follows:</para>
<para>A sample implementation of _savegpr0_<emphasis>N</emphasis> and
_restgpr0_<emphasis>N</emphasis> follows:</para>
<programlisting> _savegpr0_14: std r14,-144(r1)
_savegpr0_15: std r15,-136(r1)
_savegpr0_16: std r16,-128(r1)
@ -7007,17 +6720,14 @@ or r0, r0, r1</programlisting>
</section>
<section xml:id="dbdoclet.50655240_56788">
<title>FPR Save and Restore Functions</title>
<para>Each _savefpr_
<emphasis>N</emphasis> routine saves the floating-point registers from f
<emphasis>N</emphasis>- f31, inclusive. When the routine is called, r1
<para>Each _savefpr_<emphasis>N</emphasis> routine saves the floating-point registers from
f<emphasis>N</emphasis>- f31, inclusive. When the routine is called, r1
contains the address of the word immediately beyond the end of the
Floating-Point Register Save Area, which means that the stack frame
must not have been allocated yet. Register r0 must contain the value of
the LR on function entry.</para>
<para>The _restfpr_
<emphasis>N</emphasis> routines restore the floating-point registers
from f
<emphasis>N</emphasis>- f31, inclusive. When the routine is called, r1
<para>The _restfpr_<emphasis>N</emphasis> routines restore the floating-point registers
from f<emphasis>N</emphasis>- f31, inclusive. When the routine is called, r1
contains the address of the word immediately beyond the end of the
Floating-Point Register Save Area, which means that the stack frame
must not have been allocated yet.</para>
@ -7025,9 +6735,8 @@ or r0, r0, r1</programlisting>
same prologue, or _restfpr_M and _restgpr0_M in the same epilogue. It
is correct to call _savegpr1_M and _savefpr_M in either order, and to
call _restgpr1_M and then _restfpr_M.</para>
<para>A sample implementation of _savefpr_
<emphasis>N</emphasis> and _restfpr_
<emphasis>N</emphasis> follows:</para>
<para>A sample implementation of _savefpr_<emphasis>N</emphasis> and
_restfpr_<emphasis>N</emphasis> follows:</para>
<programlisting> _savefpr_14: stfd f14,-144(r1)
_savefpr_15: stfd f15,-136(r1)
_savefpr_16: stfd f16,-128(r1)
@ -7450,8 +7159,7 @@ stw r0,0,(r7)</programlisting>
<itemizedlist>
<listitem>
<para>Due to fusion hardware support, the preferred code forms are
destructive
<footnote xml:id="pgfId-1139524">
destructive<footnote xml:id="pgfId-1139524">
<para>Destructive in this context refers to a code sequence where
the first intermediate result computed by a first instruction is
overwritten (that is, "destroyed") by the result of a second
@ -7520,13 +7228,10 @@ stw r0,0,(r7)</programlisting>
<para>Low part of the offset: symbol@l</para>
</listitem>
</itemizedlist>
<para>If the instruction using symbol@got@
<emphasis role="bold">l</emphasis> has a signed immediate operand (for example,
addi), use symbol@got@
<emphasis role="bold">ha</emphasis>(high adjusted) for the high part of the offset.
<para>If the instruction using symbol@got@<emphasis role="bold">l</emphasis> has a signed immediate operand (for example,
addi), use symbol@got@<emphasis role="bold">ha</emphasis>(high adjusted) for the high part of the offset.
If it has an unsigned immediate operand (for example, ori), use
symbol@got@
<emphasis role="bold">h</emphasis>. For a description of high-adjusted values, see
symbol@got@<emphasis role="bold">h</emphasis>. For a description of high-adjusted values, see
<xref linkend="dbdoclet.50655241_51269" />.</para>
</listitem>
</itemizedlist>
@ -7557,7 +7262,16 @@ stw r0,0,(r7)</programlisting>
<xref linkend="dbdoclet.50655240_85319" />.</para>
</listitem>
</orderedlist>
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_85319">
<figure xml:id="dbdoclet.50655240_85319">
<title>Direct Function Call</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-32.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1" xml:id="dbdoclet.50655240_85319">
<title>Direct Function Call</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="30*" />
@ -7590,7 +7304,7 @@ nop</programlisting>
</row>
</tbody>
</tgroup>
</table>
</table -->
<orderedlist continuation="continues">
<listitem>
<para>The called function is not in the same executable or shared
@ -7603,13 +7317,22 @@ nop</programlisting>
</orderedlist>
<para>For indirect function calls, the address of the function to be
called is placed in r12 and the CTR register. A bctrl instruction is used
to pereform the indirect branch as shown in
to perform the indirect branch as shown in
<xref linkend="dbdoclet.50655240_16744" />, and
<xref linkend="dbdoclet.50655240_95225" />. The ELF V2 ABI requires the
address of the called function to be in r12 when a cross-module function
call is made.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_95364">
<figure xml:id="dbdoclet.50655240_95364">
<title>Indirect Function Call (Absolute Medium Model)</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-33.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!-- table frame="all" pgwide="1" xml:id="dbdoclet.50655240_95364">
<title>Indirect Function Call (Absolute Medium Model)</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="30*" />
@ -7659,12 +7382,21 @@ bctrl</programlisting>
</row>
</tbody>
</tgroup>
</table>
</table -->
<para>
<xref linkend="dbdoclet.50655240_16744" /> shows how to make an indirect
function call using small-model position-independent code.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_16744">
<figure xml:id="dbdoclet.50655240_16744">
<title>Small-Model Position-Independent Indirect Function Call</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-34.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1" xml:id="dbdoclet.50655240_16744">
<title>Small-Model Position-Independent Indirect Function Call</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="30*" />
@ -7720,12 +7452,21 @@ ld r2,24(r1)</programlisting>
</row>
</tbody>
</tgroup>
</table>
</table -->
<para>
<xref linkend="dbdoclet.50655240_95225" /> shows how to make an indirect
function call using large-model position-independent code.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_95225">
<figure xml:id="dbdoclet.50655240_95225">
<title>Large-Model Position-Independent Indirect Function Call</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-35.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1" xml:id="dbdoclet.50655240_95225">
<title>Large-Model Position-Independent Indirect Function Call</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="30*" />
@ -7783,7 +7524,7 @@ ld r2,24(r1)</programlisting>
</row>
</tbody>
</tgroup>
</table>
</table -->
<para>Function calls need to be performed in conjunction with
establishing, maintaining, and restoring addressability through the TOC
pointer register, r2. When a function is called, the TOC pointer register
@ -7828,7 +7569,16 @@ bl target
<xref linkend="dbdoclet.50655240_66111" /> shows the model for branch
instructions.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_66111">
<figure xml:id="dbdoclet.50655240_66111">
<title>Branch Instruction Model</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-36.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1" xml:id="dbdoclet.50655240_66111">
<title>Branch Instruction Model</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="50*" />
@ -7862,7 +7612,7 @@ b .L01</programlisting>
</row>
</tbody>
</tgroup>
</table>
</table-->
<para>Selecting one of multiple branches is accomplished in C with switch
statements. An address table is used by the compiler to implement the
switch statement selections in cases where the case labels satisfy
@ -7886,7 +7636,17 @@ b .L01</programlisting>
application) loaded into the low or high address range, absolute
addressing of a branch table yields the best performance.</para>

<table frame="all" pgwide="1">
<figure>
<title>Absolute Switch Code (Within) for static modules located in low
or high 2 GB of address space</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-37.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1">
<title>Absolute Switch Code (Within) for static modules located in low
or high 2 GB of address space</title>
<tgroup cols="2">
@ -7943,13 +7703,24 @@ bctr
</row>
</tbody>
</tgroup>
</table>
</table-->
<note>
<para>A faster variant of this code may be used to locate branch
targets in the bottom 2 GB of the address space in conjunction with the
lwz instruction in place of the lwa instruction.</para>
</note>
<table frame="all" pgwide="1">
<figure>
<title>Absolute Switch Code (Beyond) for static modules beyond the top
or bottom 2 GB of the address space</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-38.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1">
<title>Absolute Switch Code (Beyond) for static modules beyond the top
or bottom 2 GB of the address space</title>
<tgroup cols="2">
@ -8006,7 +7777,7 @@ bctr
</row>
</tbody>
</tgroup>
</table>
</table -->
<para>For position-independent code targeted at being dynamically loaded
to different address ranges as DSO, the preferred code pattern uses
TOC-relative addressing by taking advantage of the fact that the TOC
@ -8014,7 +7785,18 @@ bctr
relative offsets from the start address of the branch table ensures
position-independence when code is loaded at different addresses.</para>

<table frame="all" pgwide="1">

<figure>
<title>Position-Independent Switch Code for Small/Medium Models
(preferred with TOC-relative addressing)</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-39.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1">
<title>Position-Independent Switch Code for Small/Medium Models</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="30*" />
@ -8070,7 +7852,7 @@ bctr
</row>
</tbody>
</tgroup>
</table>
</table-->
<para>For position-independent code targeted at being dynamically loaded
to different address ranges as a DSO or a position-independent executable
(PIE), the preferred code pattern uses TOC-indirect addresses for code
@ -8079,7 +7861,17 @@ bctr
table ensures position independence when code is loaded at different
addresses.</para>

<table frame="all" pgwide="1">
<figure>
<title>Position-Independent Switch Code for All Models (alternate, with
GOT-indirect addressing)</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-40.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1">
<title>Position-Independent Switch Code for All Models (alternate, with
GOT-indirect addressing)</title>
<tgroup cols="2">
@ -8136,7 +7928,7 @@ bctr
</row>
</tbody>
</tgroup>
</table>
</table-->
<para>
<xref linkend="dbdoclet.50655240_11405" /> shows how, in the medium code
model, PIC code can be used to avoid using the lwa instruction, which may
@ -8262,7 +8054,7 @@ addi r3,r1,p ; R3 = new data area following parameter save area.</pro
<para>The DWARF specification is used by compilers and debuggers to aid
source-level or symbolic debugging. However, the format is not biased toward
any particular compiler or debugger. Per the DWARF specification, a
mapping from Power Archtecture regiters to register numbers is required as
mapping from Power Archtecture registers to register numbers is required as
described in <xref linkend="dbdoclet.50655240_94513" />.</para>
<para>All instances of the Power Architecture use the mapping shown in
<xref linkend="dbdoclet.50655240_94513" /> for encoding registers into
@ -8397,8 +8189,7 @@ addi r3,r1,p ; R3 = new data area following parameter save area.</pro
<para>cr0 - cr7</para>
</entry>
<entry>
<para>0.5
<footnote>
<para>0.5<footnote>
<para>The CRx registers correspond to 4-bit fields within a
word where the offset of the 4-bit group within a word is a
function of the CRFx number (x).</para>

33
specification/ch_3.xml
Unescape Escape View File

@ -116,8 +116,7 @@ e_ident[EI_DATA] ELFDATA2LSB For all little-endian implementations.</progra
</row>
<row>
<entry>
<para>.plt
<footnote>
<para>.plt<footnote>
<para>The type of the OpenPOWER ABI .plt section is
SHT_NOBITS, not SHT_PROGBITS as on most other processors.</para>
</footnote></para>
@ -184,7 +183,7 @@ e_ident[EI_DATA] ELFDATA2LSB For all little-endian implementations.</progra
is linker generated. The linker must ensure that .got is aligned to an
8-byte boundary. In an executable or shared library, it may contain
part or all of the TOC. For more information, see
<xref revisionflag='deleted' linkend="dbdoclet.50655240___RefHeading___Toc377640591" /> and
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640591" /> and
<xref linkend="dbdoclet.50655242_47739" />.</para>
</listitem>
<listitem>
@ -319,7 +318,7 @@ e_ident[EI_DATA] ELFDATA2LSB For all little-endian implementations.</progra
pointer can use a common entry point for the local and global
entry points.</para>
<note>
<para>Note: If the function is not a leaf function, it must
<para>If the function is not a leaf function, it must
call subroutines using the R_PPC64_REL24_NOTOC relocation
to indicate that the TOC register is not initialized. In
turn, this may lead to more expensive procedure linkage
@ -852,7 +851,7 @@ my_func:
</entry>
</row>
<row>
<entry align="left">
<entry align="right">
<para>0</para>
</entry>
<entry>
@ -2360,7 +2359,7 @@ my_func:
</tgroup>
</informaltable>
<note>
<para>Note: Relocations flagged with an asterisk(*) will
<para>Relocations flagged with an asterisk(*) will
trigger a relocation failure if the value computed does
not fit in the field specified.</para>
</note>
@ -2426,11 +2425,12 @@ my_func:
<tfoot>
<row>
<entry nameend="c4" namest="c1" align="left">
<para><emphasis role="bold">Note:</emphasis>Relocation values 8, 9, 12, 13, 18, 23, 32,
<note>
<para>Relocation values 8, 9, 12, 13, 18, 23, 32,
and 247 are not used. This is to maintain a
correspondence to the relocation values used by the
32-bit PowerPC ELF ABI.
</para>
</para></note>
</entry>
</row>
</tfoot>
@ -3204,7 +3204,7 @@ my_func:
<para>half16ds*</para>
</entry>
<entry>
<para></para>
<para>(R + A) &gt;&gt; 2</para>
</entry>
</row>
<row>
@ -4119,9 +4119,7 @@ my_func:
resolved through a call to the symbol’s procedure linkage table entry.
Additionally, it instructs the link editor to build a procedure linkage
table for the executable or shared object if one is not created.</para>
<para>
<anchor xml:id="dbdoclet.50655241_R_PPC_COPY"
xreflabel="" /> R_PPC64_COPY</para>
<para><anchor xml:id="dbdoclet.50655241_R_PPC_COPY" xreflabel="" />R_PPC64_COPY</para>
<para>This relocation type is created by the link editor for dynamic
linking. Its offset member refers to a location in a writable segment.
The symbol table index specifies a symbol that should exist both in the
@ -4219,7 +4217,7 @@ ld r3,x@got@l(r3)</programlisting>
<para> </para>
<note>
<para>
<emphasis role="bold">Note:</emphasis> If X is a variable stored in the TOC,
If X is a variable stored in the TOC,
then X@got is the offset within the TOC of a doubleword whose
value is X@toc.</para>
</note>
@ -4274,7 +4272,7 @@ lwz rt, offset(r2)</programlisting>
<para>Compilers and programmers
<emphasis>must</emphasis> ensure that r2 is live at the actual data access
point associated with extended displacement addressing.</para>
</section>

<section xml:id="dbdoclet.50655241_19147">
<title>TOC Pointer Usage</title>
<para>To enable linker-based optimizations when global data is accessed,
@ -4320,6 +4318,8 @@ target:
rewrite address references created using GOT-indirect loads and bl+4
sequences to use TOC-relative address computation.</para>
</section>
</section>
<section>
<title>Fusion</title>
<para>Code generation in compilers, linkers, and by programmers should
@ -5717,8 +5717,7 @@ static __thread unsigned int x3;
the following code, which makes no reference to GOT entries. The GOT
entries in
<xref linkend="dbdoclet.50655241_16273" /> can be removed from the GOT by
the linker when performing this code transformation.
<footnote xml:id="pgfId-1134055">
the linker when performing this code transformation.<footnote xml:id="pgfId-1134055">
<para>To further optimize the code in
<xref linkend="dbdoclet.50655241_16273" />, a linker may reschedule the
sequence to exploit fusion by generating a sequence that may be fused
@ -6251,7 +6250,7 @@ nop</programlisting>
<para>
<orderedlist>
<listitem xml:id="dbdoclet.50655241_21152">
<para>1. The linker may prefer to schedule the addis and
<para>The linker may prefer to schedule the addis and
addi to be adjacent to take advantage of fusion as a
microarchitecture optimization opportunity.</para>
</listitem>

22
specification/ch_4.xml
Unescape Escape View File

@ -141,7 +141,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</tgroup>
</table>
<note>
<para>Note: For the PT_LOAD entry describing the data segment, the
<para>For the PT_LOAD entry describing the data segment, the
p_memsz may be greater than the p_filesz. The difference is the size of
the .bss section. On implementations that use virtual memory file
mapping, only the portion of the file between the .data p_offset
@ -152,7 +152,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
data through p_vaddr + p_memsz.</para>
</note>
<para>
<xref linkend="dbdoclet.50655242_44623" /> demonstrates a typical mapping of
<xref linkend="dbdoclet.50655242_45730" /> demonstrates a typical mapping of
file to memory segments.</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50655242_45730">
<title>Memory Segment Mappings</title>
@ -366,11 +366,9 @@ int main(int argc, char *argv[], char *envp[], ElfW(auxv_t) *auxvec)</programlis
</itemizedlist>
<para>This section explains how to implement the call to main or to the
entry point.</para>
</section>

<section xml:id="dbdoclet.50655242___RefHeading___Toc377640653">
<title>Registers
<anchor xml:id="dbdoclet.50655242_PROC-REG"
xreflabel="" /> Registers</title>
<title xml:id="dbdoclet.50655242_PROC-REG">Registers</title>
<para>The contents of most registers are
<emphasis>not</emphasis> specified when a process is first entered from an
exec system call. A program should not expect the operating system to set
@ -699,6 +697,8 @@ PPC_FEATURE2_HAS_VCRYPTO 0x02000000 /* The processor implements the
information block.</para>
</section>
</section>
</section>
<section>
<title>Dynamic Linking</title>
<section xml:id="dbdoclet.50655242___RefHeading___Toc377640656">
@ -709,8 +709,7 @@ PPC_FEATURE2_HAS_VCRYPTO 0x02000000 /* The processor implements the
</section>
<section>
<title>Dynamic Section</title>
<para>
<anchor xml:id="dbdoclet.50655242_page119" xreflabel="" /> The dynamic
<para><anchor xml:id="dbdoclet.50655242_page119" xreflabel="" />The dynamic
section provides information used by the dynamic linker to manage
dynamically loaded shared objects, including relocation, initialization,
and termination when loaded or unloaded, resolving dependencies on other
@ -877,7 +876,7 @@ PPC_FEATURE2_HAS_VCRYPTO 0x02000000 /* The processor implements the
stored in the file image. The individual PLT entries are populated by the
dynamic linker using one of the following binding methods. Execution can
then be redirected to a dependent shared object or executable.</para>
</section>

<section>
<title>Lazy Binding</title>
<para>The lazy binding method is the default. It delays the resolution of
@ -966,8 +965,7 @@ bctr</programlisting>
ld r12,func@plt@toc@l(r12)
mtctr r12
bctr</programlisting>
<para>
<anchor xml:id="dbdoclet.50655242___DdeLink__61883_1749258592"
<para><anchor xml:id="dbdoclet.50655242___DdeLink__61883_1749258592"
xreflabel="" />A possible implementation for case 3 looks as
follows:</para>
<programlisting> mflr r0
@ -1062,4 +1060,6 @@ res_1: b PLTresolve
<para> </para>
</section>
</section>
</section>

</chapter>

3
specification/ch_5.xml
Unescape Escape View File

@ -195,8 +195,7 @@ xml:id="dbdoclet.50655243_pgfId-1099317">
<entry>
<para>__PPC64__</para>
<para>__powerpc64__</para>
<para>__64BIT__
<footnote xml:id="pgfId-1101811">
<para>__64BIT__<footnote xml:id="pgfId-1101811">
<para>Phased in.</para>
</footnote></para>
</entry>

95
specification/ch_6.xml
Unescape Escape View File

@ -203,9 +203,9 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<table frame="all" pgwide="1" xml:id="dbdoclet.50655244_35023">
<title>Endian-Sensitive Operations</title>
<tgroup cols="3">
<colspec colname="c1" colwidth="15*" align="center" />
<colspec colname="c2" colwidth="35*" align="center" />
<colspec colname="c3" colwidth="50*" />
<colspec colname="c1" colwidth="25*" align="center" />
<colspec colname="c2" colwidth="30*" align="center" />
<colspec colname="c3" colwidth="45*" />
<thead>
<row>
<entry>
@ -274,8 +274,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>vec_extract_fp32_</para>
<para>from_shorth</para>
<para>vec_extract_fp32_from_shorth</para>
</entry>
<entry>
<para> </para>
@ -286,8 +285,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>vec_extract_fp32_</para>
<para>from_shortl</para>
<para>vec_extract_fp32_from_shortl</para>
</entry>
<entry>
<para> </para>
@ -310,8 +308,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>vec_first_match</para>
<para>_index</para>
<para>vec_first_match_index</para>
</entry>
<entry>
<para> </para>
@ -322,8 +319,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>vec_first_match</para>
<para>_index_or_eos</para>
<para>vec_first_match_index_or_eos</para>
</entry>
<entry>
<para> </para>
@ -364,8 +360,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<para>vmrgew</para>
</entry>
<entry>
<para>Swap inputs and use vmrgow for LE. Phased in.
<footnote xml:id="pgfId-1105723">
<para>Swap inputs and use vmrgow for LE. Phased in.<footnote xml:id="pgfId-1105723">
<para>This optional function is being phased in, and it may not
be available on all implementations.</para>
</footnote></para>
@ -401,8 +396,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<para>vmrgow</para>
</entry>
<entry>
<para>Swap inputs and use vmrgew for LE. Phased in.
<footnoteref linkend="pgfId-1105723" /> </para>
<para>Swap inputs and use vmrgew for LE. Phased in.<footnoteref linkend="pgfId-1105723" /> </para>
</entry>
</row>
<row>
@ -754,8 +748,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xlw4
<footnote xml:id="dbdoclet.50655244_73052"><para>
<para>vec_xlw4<footnote xml:id="dbdoclet.50655244_73052"><para>
Deprecated. The use of vector data type
assignment and overloaded vec_xl and vec_xst vector
built-in functions are preferred forms for assigning
@ -774,8 +767,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xld2
<footnoteref linkend="dbdoclet.50655244_73052"/>
<para>vec_xld2<footnoteref linkend="dbdoclet.50655244_73052"/>
</para>
</entry>
<entry>
@ -798,8 +790,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xstw4
<footnoteref linkend="dbdoclet.50655244_73052"/>
<para>vec_xstw4<footnoteref linkend="dbdoclet.50655244_73052"/>
</para>
</entry>
<entry>
@ -811,8 +802,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xstd2
<footnoteref linkend="dbdoclet.50655244_73052"/>
<para>vec_xstd2<footnoteref linkend="dbdoclet.50655244_73052"/>
</para>
</entry>
<entry>
@ -1173,8 +1163,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xlw<phrase revisionflag="added">4</phrase>
<footnote xml:id="dbdoclet.50655244_78719">
<para>vec_xlw<phrase revisionflag="added">4</phrase><footnote xml:id="dbdoclet.50655244_78719">
<para>Deprecated. The use of vector data type
assignment and overloaded vec_xl and vec_xst vector
built-in functions are preferred forms for assigning
@ -1193,8 +1182,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xld2
<footnoteref linkend="dbdoclet.50655244_78719"/>
<para>vec_xld2<footnoteref linkend="dbdoclet.50655244_78719"/>
</para>
</entry>
<entry>
@ -1219,8 +1207,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xstw4
<footnoteref linkend="dbdoclet.50655244_78719"/>
<para>vec_xstw4<footnoteref linkend="dbdoclet.50655244_78719"/>
</para>
</entry>
<entry>
@ -1232,8 +1219,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xstd2
<footnoteref linkend="dbdoclet.50655244_78719"/>
<para>vec_xstd2<footnoteref linkend="dbdoclet.50655244_78719"/>
</para>
</entry>
<entry>
@ -1295,6 +1281,53 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
</thead>
<tbody>
<row revisionflag="added">
<entry>
<para>VEC_CONCAT (ARG1, ARG2)<?linebreak?>(Fortran)</para>
<para></para>
</entry>
<entry>
<para>Purpose:</para>
<para>Concatenates two elements to form a vector.</para>
<para>Result value:</para>
<para>The resulting vector consists of the two scalar elements,
ARG1 and ARG2, assigned to elements 0 and 1 (using the
environment’s native endian numbering), respectively.</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Note: </emphasis>This function corresponds to the C/C++ vector
constructor (vector type){a,b}. It is provided only for
languages without vector constructors.</para>
</listitem>
</itemizedlist>
</entry>
</row>
<row revisionflag="added">
<entry>
<para></para>
</entry>
<entry>
<para>vector signed long long vec_concat (signed long long,
signed long long);</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para></para>
</entry>
<entry>
<para>vector unsigned long long vec_concat (unsigned long long,
unsigned long long);</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para></para>
</entry>
<entry>
<para>vector double vec_concat (double, double);</para>
</entry>
</row>
<row>
<entry>
<para>VEC_CONVERT(V, MOLD)</para>

Write Preview
Loading…
Cancel
Save