Remove revision flags for v1.5

master
Bill Schmidt 4 years ago
parent 0836a0a376
commit 74b0637d26

File diff suppressed because it is too large Load Diff

@ -197,14 +197,6 @@ xml:id="dbdoclet.50655246_33489">
<para>GNU Compiler Collection</para>
</entry>
</row>
<row revisionflag="deleted">
<entry>
<para>GEP</para>
</entry>
<entry>
<para>Global entry point</para>
</entry>
</row>
<row>
<entry>
<para>GOT</para>
@ -293,14 +285,6 @@ xml:id="dbdoclet.50655246_33489">
<para>Little-endian</para>
</entry>
</row>
<row revisionflag="deleted">
<entry>
<para>LEP</para>
</entry>
<entry>
<para>Local entry point</para>
</entry>
</row>
<row>
<entry>
<para>LR</para>

@ -37,7 +37,7 @@
</author>
<copyright>
<!-- TODO: Keep second year accurate for latest publish -->
<year>2014-<phrase revisionflag="changed">2020</phrase></year>
<year>2014-2020</year>
<holder>OpenPOWER Foundation</holder>
</copyright>
<copyright>
@ -94,7 +94,7 @@
<revhistory>
<!-- TODO: Set the initial version information and clear any old information out -->
<revision>
<date>2020-11-30</date>
<date>2020-12-01</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
@ -173,7 +173,6 @@
<xi:include href="ch_4.xml"/>
<xi:include href="ch_5.xml"/>
<xi:include href="ch_6.xml"/>
<xi:include href="app_a.xml"/>
<xi:include href="app_b.xml"/>
<xi:include href="app_glossary.xml"/>


@ -66,18 +66,15 @@
<itemizedlist>
<listitem>
<para>
<emphasis><phrase revisionflag="added">IBM</phrase> Power
Instruction Set Architecture,</emphasis> Versions <phrase
revisionflag="deleted">2.7 and 3.0,</phrase> <phrase
revisionflag="added">2.07, 3.0, and 3.1</phrase>, IBM, <phrase
revisionflag="deleted">2013-2016</phrase><phrase
revisionflag="added">2013-2020</phrase>.
<emphasis>IBM Power
Instruction Set Architecture,</emphasis> Versions
2.07, 3.0, and 3.1, IBM, 2013-2020.
<emphasis>
<link xl:href="https://openpowerfoundation.org/technical/resource-catalog/">https://openpowerfoundation.org/technical/resource-catalog/
</link>
</emphasis></para>
</listitem>
<listitem revisionflag="added">
<listitem>
<para>
<emphasis>POWER Vector Intrinsics Programming
Reference</emphasis>, Version 1.0.0, OpenPOWER Foundation,
@ -132,7 +129,7 @@
</link>
</emphasis></para>
</listitem>
<listitem revisionflag="added">
<listitem>
<para>ELFv2 ABI Compliance TH/TS Specification 1.00, OpenPOWER
Foundation, June 27, 2017.
<emphasis>
@ -206,7 +203,7 @@
</listitem>
</itemizedlist>
</section>
<section revisionflag="added">
<section>
<title>Changes from Revision 1.4</title>
<itemizedlist>
<listitem>
@ -244,7 +241,7 @@
</listitem>
</itemizedlist>
</section>
<section revisionflag="added">
<section>
<title>Conformance to this Specification</title>
<para>
Compilers, assemblers, linkers, system libraries, and other

@ -21,8 +21,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640572">
<title>Processor Architecture</title>
<para>This ABI is predicated on, at a minimum, Power ISA version
<phrase revisionflag="deleted">2.7</phrase> <phrase
revisionflag="added">2.07</phrase> and
2.07 and
contains additional implementation characteristics.</para>
<para>All OpenPOWER instructions that are defined by the Power
Architecture can be assumed to be implemented and to work as specified.
@ -2601,7 +2600,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
2<superscript>16</superscript> &#8211; 1.</para>
</entry>
</row>
<row revisionflag="added">
<row>
<entry>
<para></para>
</entry>
@ -2764,23 +2763,6 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>Vector of 1 signed quadword.</para>
</entry>
</row>
<row revisionflag="deleted">
<entry>
<para></para>
</entry>
<entry>
<para>vector _Float16</para>
</entry>
<entry>
<para>16</para>
</entry>
<entry>
<para>Quadword</para>
</entry>
<entry>
<para>Vector of 8 half-precision floats.</para>
</entry>
</row>
<row>
<entry>
<para></para>
@ -3097,15 +3079,10 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</tbody>
</tgroup>
</table>
<bridgehead revisionflag="deleted">>IBM EXTENDED PRECISION
&amp;&amp; IEEE BINARY 128 QUADRUPLE PRECISION</bridgehead>
<para>Availability of the long double data type is subject to
conformance to a long double standard where the IBM EXTENDED PRECISION
format and the IEEE BINARY 128 QUADRUPLE PRECISION format are mutually
exclusive.</para>
<bridgehead xml:id="dbdoclet.50655240_95080"
revisionflag="deleted">IEEE BINARY 128 QUADRUPLE
PRECISION || IBM EXTENDED PRECISION</bridgehead>
<para>This ABI provides the following choices for implementation of
long double in compilers and systems. The preferred implementation for
long double is the IEEE 128-bit quad-precision binary floating-point
@ -3132,7 +3109,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
long double ISO C type. However, this is not part of the C
standard.</para>
</listitem>
<listitem revisionflag="added">
<listitem>
<para>This implementation differs from the IEEE 754
Standard in the following ways:</para>
<itemizedlist>
@ -3201,29 +3178,6 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</itemizedlist>
</listitem>
</itemizedlist>
<para revisionflag="deleted">This implementation differs from
the IEEE 754 Standard in the
following ways:</para>
<itemizedlist revisionflag="deleted">
<listitem>
<para>The software support is restricted to round-to-nearest mode.
Programs that use extended precision must ensure that this rounding
mode is in effect when extended-precision calculations are
performed.</para>
</listitem>
<listitem>
<para>This implementation does not fully support the IEEE special
numbers NaN and INF. These values are encoded in the high-order
double value only. The low-order value is not significant, but the
low-order value of an infinity must be positive or negative
zero.</para>
</listitem>
<listitem>
<para>This implementation does not support the IEEE status flags
for overflow, underflow, and other conditions. These flags have no
meaning in this format.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640576">
<title>Aggregates and Unions</title>
@ -3519,9 +3473,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
xml:id="dbdoclet.50655240_54268">
<?dbhtml table-width="60%" ?>
<?dbfo table-width="60%" ?>
<title>Little-Endian Bit Numbering for <phrase
revisionflag="added">0x0001000200030004</phrase> <phrase
revisionflag="deleted">0x01020304</phrase></title>
<title>Little-Endian Bit Numbering for
0x0001000200030004</title>
<tgroup cols="12">
<colspec colname="c1" colwidth="3*" />
<colspec colname="c2" colwidth="3*" />
@ -3776,8 +3729,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
xml:id="dbdoclet.50655240_47219">
<?dbhtml table-width="60%" ?>
<?dbfo table-width="60%" ?>
<title>Big-Endian Bit Numbering for <phrase
revisionflag="added">0x0001000200030004</phrase> <phrase revisionflag="deleted">0x01020304</phrase></title>
<title>Big-Endian Bit Numbering for
0x0001000200030004</title>
<tgroup cols="12">
<colspec colname="c1" colwidth="3*" />
<colspec colname="c2" colwidth="3*" />
@ -4079,7 +4032,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</figure>

<note>
<para><phrase revisionflag="added">In</phrase> <xref
<para>In <xref
linkend="dbdoclet.50655240_30073" />, the alignment of the
structure is not affected by the unnamed short and int fields. The
named members are aligned relative to the start of the structure.
@ -4091,8 +4044,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</note>
</section>
</section>
<section xml:id="dbdoclet.50655240___codealign"
revisionflag="added">
<section xml:id="dbdoclet.50655240___codealign">
<title>Code Alignment</title>
<para>
Functions must be aligned on at least a 4-byte boundary.
@ -4116,7 +4068,6 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
and restore functions.</para>
<para>The conventions given in this section are adhered to by C programs.
For more information about the implementation of C, See
<phrase revisionflag="deleted">https://apps.na.collabserv.com/meetings/join?id=2897-3986</phrase>
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640591" />.</para>
<note>
<para>While it is recommended that all functions use the standard
@ -4127,7 +4078,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
requirements. Some tools may not work with alternate calling sequences
and conventions.</para>
</note>
<section xml:id="dbdoclet.50655241_FnLinkage" revisionflag="added">
<section xml:id="dbdoclet.50655241_FnLinkage">
<title>Function Call Linkage Protocols</title>
<para>
The compiler (or assembly programmer) and linker cooperate to make
@ -4694,23 +4645,20 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>Nonvolatile<footnote>
<para>Register r2 is nonvolatile with respect to calls
between functions in the same compilation
unit<phrase revisionflag="deleted">. It is saved and
restored by code inserted by the linker resolving a
call to an external function.</phrase><phrase
revisionflag="added">, except under the conditions
in footnote (b).</phrase> For more information, see
<xref linkend="dbdoclet.50655240_51083" /> <phrase
revisionflag="added"> and <xref
unit, except under the conditions
in footnote (b). For more information, see
<xref linkend="dbdoclet.50655240_51083" />
and <xref
linkend="dbdoclet.50655241_FnLinkage"
/></phrase>.</para>
</footnote><phrase revisionflag="added"> or
/>.</para>
</footnote> or
Volatile<footnote>
<para>Register r2 is volatile and available for use in a
function that does not use a TOC pointer and that does
not guarantee that it preserves r2. See
<xref linkend="dbdoclet.50655241_FnLinkage" /> and
<xref linkend="dbdoclet.50655241_95185" />.</para>
</footnote></phrase></para>
</footnote></para>
</entry>
<entry>
<para>TOC pointer.</para>
@ -4900,17 +4848,17 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
dynamic linker. For references through function pointers, it is the
compiler's or assembler programmer's responsibility to insert
appropriate TOC save and restore code. If the function is called from
the same module as the callee, the callee must <phrase
revisionflag="added">normally</phrase> preserve the value of r2.
<phrase revisionflag="added">If the callee function is called from
the same module as the callee, the callee must
normally preserve the value of r2.
If the callee function is called from
a function in the same compilation unit as the callee, and the
callee does not preserve r2, the
caller is responsible for saving and restoring the TOC pointer if it
needs it.</phrase> (See <phrase revisionflag="changed"><xref
needs it. (See <xref
linkend="dbdoclet.50655241_FnLinkage" />
for more information.</phrase>)</para>
<para>When a function calls another function <phrase
revisionflag="added">that requires a TOC pointer</phrase>, the TOC
for more information.)</para>
<para>When a function calls another function
that requires a TOC pointer, the TOC
pointer must have a legal value pointing to the TOC base, which may be
initialized as described in <xref
linkend="dbdoclet.50655242_47739" />.</para>
@ -4943,8 +4891,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
context.</para>
</listitem>
<listitem>
<para>When a function <phrase revisionflag="added">that requires a
TOC pointer</phrase> is entered through its global entry point,
<para>When a function that requires a
TOC pointer is entered through its global entry point,
register r12 contains the entry-point address. For more
information, see the description of dual entry points in
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640597" />
@ -5000,15 +4948,15 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
mask the value received from
<emphasis role="bold">mfocr</emphasis> to avoid corruption of the resulting
(partial) condition register word.</para>
<para>This erratum does not apply to <phrase
revisionflag="changed">POWER9 and subsequent
processors.</phrase></para>
<para>This erratum does not apply to
POWER9 and subsequent
processors.</para>
</note>

<para><anchor xml:id="dbdoclet.50655240_Power-ISA-version-and-the-user-s-manual"
xreflabel="" />For more information, see
<citetitle>Power ISA</citetitle>, version <phrase
revisionflag="changed">3.0B</phrase> and "Fixed-Point Invalid
<citetitle>Power ISA</citetitle>, version
3.0B and "Fixed-Point Invalid
Forms and Undefined Conditions" in
<citetitle>POWER9 Processor User's Manual.</citetitle></para>
<bridgehead>Floating-Point Registers</bridgehead>
@ -5050,11 +4998,11 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
special-purpose register to provide floating-point status and control.
Throughout this document, the symbol fN is used, where N is a register
number, to refer to floating-point register N.</para>
<para>For the purpose of function calls, the <phrase
revisionflag="changed">least-significant halves of those VSX
registers corresponding</phrase> to the classic floating-point
registers (that is, vsr0&#8211;vsr31), <phrase
revisionflag="changed">are</phrase> volatile.</para>
<para>For the purpose of function calls, the
least-significant halves of those VSX
registers corresponding to the classic floating-point
registers (that is, vsr0&#8211;vsr31),
are volatile.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_83567">
<title>Floating-Point Register Roles for Binary Floating-Point
@ -5681,8 +5629,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
general-purpose register save and restore functions are to be used, the
general-purpose registers shall be saved in a contiguous range.
General-purpose register rN is saved in the doubleword located 8 x
(32 &#8211; N) bytes before the <phrase
revisionflag="changed">Floating-Point Register Save Area,</phrase>
(32 &#8211; N) bytes before the
Floating-Point Register Save Area,
as shown in
<xref linkend="dbdoclet.50655240_97610" />.</para>
<para>The General-Purpose Register Save Area is always doubleword
@ -5699,7 +5647,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
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 <phrase revisionflag="changed">quadword</phrase> located
saved in the quadword located
16 x (32 &#8211; N) bytes before the
General-Purpose Register Save Areas plus alignment padding, as shown in
@ -5762,8 +5710,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>Functions without a suitable declaration available to the
caller to determine the called function's characteristics (for
example, functions in C without a prototype in scope, in accordance
with Brian Kernighan and Dennis <phrase
revisionflag="changed">Ritchie</phrase>,
with Brian Kernighan and Dennis
Ritchie,
<citetitle>The C Programming Language</citetitle>, 1st
edition).</para>
</listitem>
@ -5992,9 +5940,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
floating-point type. (A complex floating-point data type is treated as if
two separate scalar values of the base type were passed.)</para>
<para>Homogeneous floating-point aggregates can have up to four IBM
EXTENDED PRECISION members, <phrase
revisionflag="deleted">four IEEE BINARY 128 QUADRUPLE
PRECISION members,</phrase> four _Decimal128 members, or
EXTENDED PRECISION members,
four _Decimal128 members, or
eight members of other
floating-point types. (Unions are treated as their largest member. For
homogeneous unions, different union alternatives may have different
@ -6020,14 +5967,12 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<xref linkend="dbdoclet.50655240_15141" />) or processed in vector
registers</para>
<para>For the purpose of determining a qualified
floating-point argument, <phrase
revisionflag="deleted">_Float128</phrase><phrase
revisionflag="added">IEEE BINARY 128 QUADRUPLE
PRECISION</phrase> shall be considered a vector data type. In
addition, <phrase
revisionflag="deleted">_Float128</phrase><phrase
revisionflag="added">IEEE BINARY 128 QUADRUPLE
PRECISION</phrase>
floating-point argument,
IEEE BINARY 128 QUADRUPLE
PRECISION shall be considered a vector data type. In
addition,
IEEE BINARY 128 QUADRUPLE
PRECISION
is like a vector data type for determining if multiple aggregate members
are like.</para>
<para>A homogeneous aggregate can consist of a variety of nested
@ -6603,14 +6548,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 revisionflag="deleted"><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
Area must be large enough to accommodate all parameters, including
parameters passed in registers.</para>
<para revisionflag="added">
<para>
The caller of any function with a variable argument list
must allocate a Parameter Save Area, as described in <xref
linkend="dbdoclet.50655240_78421" />.
@ -6691,7 +6629,7 @@ s6 - 72 (stored)</programlisting>
<para>When instructions hold relative addresses, a program library can be
loaded at various positions in virtual memory and is referred to as a
position-independent code model.</para>
<para revisionflag="added">When generating code for PowerISA version 3.1
<para>When generating code for PowerISA version 3.1
or above, this specification provides two ways to address non-local data
and text. The historical method relies on a dedicated table-of-contents
(TOC) pointer to obtain such addresses. PowerISA version 3.1 introduces
@ -6729,7 +6667,7 @@ s6 - 72 (stored)</programlisting>
instructions:</para>
</listitem>
</itemizedlist>
<programlisting revisionflag="changed">lis r16, symbol@ha
<programlisting>lis r16, symbol@ha
ld r10, symbol@l(r16)

lis r16, symbol2@ha
@ -6742,7 +6680,7 @@ lvx v1, r0, r16</programlisting>
<xref linkend="dbdoclet.50655241_66700" />.)</para>
</listitem>
</itemizedlist>
<programlisting revisionflag="changed">&lt;load TOC base to r2&gt;
<programlisting>&lt;load TOC base to r2&gt;
ld r10, symbol@toc(r2)

li r16, symbol2@toc
@ -6753,7 +6691,7 @@ lvx v1, r2, r16</programlisting>
addressing:</para>
</listitem>
</itemizedlist>
<programlisting revisionflag="changed">&lt;load TOC base to r2&gt;
<programlisting>&lt;load TOC base to r2&gt;

ld r10, symbol@got(r2)
ld r10, 0(r10)
@ -6762,12 +6700,12 @@ ld r10, symbol2@got(r2)
lvx v1, 0, r10</programlisting>
<itemizedlist>
<listitem>
<para revisionflag="added">
<para>
By using PC-relative addressing.
</para>
</listitem>
</itemizedlist>
<programlisting revisionflag="added">pld r10, symbol@pcrel
<programlisting>pld r10, symbol@pcrel

plxv v1, symbol@pcrel</programlisting>
<para>In the OpenPOWER ELF V2 ABI, position-dependent code built with
@ -6809,7 +6747,7 @@ plxv v1, symbol@pcrel</programlisting>
loaded in the first 2 GB of the address space because direct address
references and TOC-pointer initializations can be performed using a
two-instruction sequence.</para>
<para revisionflag="added">
<para>
PC-relative offsets are usually 34 bits for all code models, with
a maximum addressing reach of 16GB. The effective addressing reach
for global data is 8GB, since data sections are always located at
@ -6853,7 +6791,7 @@ plxv v1, symbol@pcrel</programlisting>
relative addressing (for private data).</para>
</listitem>
</itemizedlist>
<programlisting revisionflag="changed">&lt;load TOC base to r2&gt;
<programlisting>&lt;load TOC base to r2&gt;

ld r10, symbol@toc(r2)

@ -6866,7 +6804,7 @@ lvx v1, r2, r16</programlisting>
sections):</para>
</listitem>
</itemizedlist>
<programlisting revisionflag="changed">&lt;load TOC base to r2&gt;
<programlisting>&lt;load TOC base to r2&gt;

ld r10, symbol@got(r2)

@ -6876,26 +6814,26 @@ ld r10, symbol2@got(r2)
lvx v1, 0, r10</programlisting>
<itemizedlist>
<listitem>
<para revisionflag="added">By using PC-relative addressing (for
<para>By using PC-relative addressing (for
private data).</para>
</listitem>
</itemizedlist>
<programlisting revisionflag="added">pld r10, symbol@pcrel
<programlisting>pld r10, symbol@pcrel

plxv v1, symbol@pcrel</programlisting>
<itemizedlist>
<listitem>
<para revisionflag="added">By using PC-relative GOT-indirect
<para>By using PC-relative GOT-indirect
addressing (for shared data):
</para>
</listitem>
</itemizedlist>
<programlisting revisionflag="added">pld r10, symbol@got@pcrel
<programlisting>pld r10, symbol@got@pcrel
ld r10, 0(r10)

pld r10, symbol@got@pcrel
lvx v1, 0, r10</programlisting>
<para revisionflag="added">
<para>
A compiler may generate a PC-relative addressing sequence to access
static or restricted-visibility data, but must generate a PC-relative
GOT-indirect sequence for extern data. Extern data may be satisfied
@ -6946,8 +6884,8 @@ lvx v1, 0, r10</programlisting>
addition, accesses to module-local code and data objects use TOC
pointer relative addressing with 32-bit offsets. Using TOC pointer
relative addressing removes a level of indirection, resulting in
faster access and a smaller GOT. <phrase
revisionflag="changed">However,</phrase> it limits the size of the
faster access and a smaller GOT.
However, it limits the size of the
entire binary to between 2 GB and 4 GB, depending on the placement
of the TOC base.</para>
<note>
@ -6967,7 +6905,7 @@ lvx v1, 0, r10</programlisting>
TOCs, or by some other method. The suggested allocation order of
sections is provided in
<xref linkend="dbdoclet.50655241_66700" />.</para>
<para revisionflag="added">
<para>
PC-relative addressing may be used with the medium code model.
Accesses to
module-local code and data objects use PC-relative addressing with
@ -6985,17 +6923,16 @@ lvx v1, 0, r10</programlisting>
<para>A function's prologue establishes addressability by
initializing a TOC pointer in register r2, if necessary, and a stack
frame, if necessary, and may save any nonvolatile registers it
uses. <phrase revisionflag="added">Not all functions must initialize
uses. Not all functions must initialize
a TOC pointer, and not all functions must preserve the existing value
of r2. See <xref linkend="dbdoclet.50655241_FnLinkage" /> for more
information.</phrase></para>
<para>All functions have a global entry point <phrase revisionflag="deleted">(GEP)</phrase> available to any
information.</para>
<para>All functions have a global entry point available to any
caller and pointing to the beginning of the prologue. Some functions
may have a secondary entry point to optimize the cost of TOC pointer
management. In particular, functions within a common module sharing the
same TOC base value in r2 may be entered using a secondary entry point
(the local entry point<phrase revisionflag="deleted"> or
LEP</phrase>) that may bypass the code that loads a
(the local entry point) that may bypass the code that loads a
suitable TOC pointer value into the r2 register. When a dynamic or
global linker transfers control from a function to another function in
the same module, it
@ -7003,22 +6940,21 @@ lvx v1, 0, r10</programlisting>
entry point when the r2 register is known to hold a valid TOC base
value. Function pointers shared between modules shall always use the
global entry point to specify the address of a function.</para>
<para><phrase revisionflag="deleted">When a linker causes
control to transfer</phrase><phrase revisionflag="added">When
control is transferred</phrase> to a global entry point
<phrase revisionflag="added">of a function that also has a local entry
point</phrase>, <phrase revisionflag="deleted">it</phrase>
<phrase revisionflag="added">the linker</phrase> must insert a
<para>When
control is transferred to a global entry point
of a function that also has a local entry
point,
the linker must insert a
glue code sequence that loads r12 with the global
entry-point address. Code at the global entry point <phrase
revisionflag="added">of a function that also has a local entry
point</phrase> can assume that
register r12 points to the <phrase
revisionflag="deleted">GEP</phrase><phrase revisionflag="added">global
entry point</phrase>. <phrase revisionflag="added">
entry-point address. Code at the global entry point
of a function that also has a local entry
point can assume that
register r12 points to the
global
entry point.
However, code at the global entry point of a function that does not
have a separate local entry point cannot make any assumptions about
the values of either r2 or 12.</phrase></para>
the values of either r2 or 12.</para>
<para>Addresses between the global and local entry points must not be
branch targets, either for function entry or referenced by program
logic of the function, because a linker may rewrite the code sequence
@ -7066,7 +7002,6 @@ or r0, r0, r1</programlisting>
either 0 or the correct in-order value of the corresponding CR field at
the point where the <emphasis role="bold">mfocrf</emphasis>
instruction is performed.</para>
<para revisionflag="deleted">&#160;</para>
<bridgehead>Assembly Language Syntax for Defining Entry
Points</bridgehead>
<para>When a function has two entry points, the global entry point is
@ -7493,15 +7428,12 @@ _restvr_31: addi r12,r0,-16
The values of symbols or their absolute virtual addresses are placed
directly into instructions for symbolic references in absolute
code.</para>
<para revisionflag="deleted">
<xref linkend="dbdoclet.50655242_page119" /> shows an example of this
method.</para>
<para>Examples of absolute and position-independent compilations are
shown in <phrase revisionflag="changed"><xref
shown in <xref
linkend="dbdoclet.50655240_12719" />,
<xref linkend="dbdoclet.50655240_page77" />,
<xref linkend="dbdoclet.50655240_19926" />, and
<xref linkend="dbdoclet.50655240_StaticPCRel" /></phrase>. These
<xref linkend="dbdoclet.50655240_StaticPCRel" />. These
examples show the
C language statements together with the generated assembly language. The
assumption for these figures is that only executables can use absolute
@ -7767,8 +7699,7 @@ stw r0,0,(r7)</programlisting>
</tgroup>
</table>

<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_StaticPCRel"
revisionflag="added">
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_StaticPCRel">
<title>PC-Relative Load and Store</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="30*" />
@ -7837,7 +7768,7 @@ stw r9, 0(r11)</programlisting>
a signed 32-bit offset from a base register.</para>
</listitem>
<listitem>
<para>For <phrase revisionflag="changed">TOC-based</phrase> PIC
<para>For TOC-based PIC
code (see <xref linkend="dbdoclet.50655240_page77" /> and
<xref linkend="dbdoclet.50655240_19926" />), the offset in the
Global Offset Table where the value of the symbol is stored is
@ -7983,15 +7914,13 @@ nop</programlisting>
<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 perform the indirect branch as shown in
<phrase revisionflag="added">
<xref linkend="dbdoclet.50655240_95364" />,
</phrase>
<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" revisionflag="changed"
<table frame="all" pgwide="1"
xml:id="dbdoclet.50655240_95364">
<title>Indirect Function Call (Absolute Medium Model)</title>
<tgroup cols="2">
@ -8051,7 +7980,7 @@ bctrl</programlisting>
function call using small-model position-independent code.
</para>

<table frame="all" pgwide="1" revisionflag="changed"
<table frame="all" pgwide="1"
xml:id="dbdoclet.50655240_16744">
<title>Small-Model Position-Independent Indirect Function Call</title>
<tgroup cols="2">
@ -8113,7 +8042,7 @@ ld r2,24(r1)</programlisting>
function call using large-model position-independent code.
</para>

<table frame="all" pgwide="1" revisionflag="changed"
<table frame="all" pgwide="1"
xml:id="dbdoclet.50655240_95225">
<title>Large-Model Position-Independent Indirect Function Call</title>
<tgroup cols="2">
@ -8178,12 +8107,12 @@ ld r2,24(r1)</programlisting>
</tbody>
</tgroup>
</table>
<para revisionflag="added">
<para>
<xref linkend="dbdoclet.50655240_PCRelPICIndirect" /> shows how to
make an indirect function call using PC-relative addressing in a
function that does not preserve r2.
</para>
<table frame="all" pgwide="1" revisionflag="added"
<table frame="all" pgwide="1"
xml:id="dbdoclet.50655240_PCRelPICIndirect">
<title>PC-Relative Position-Independent Indirect Function Call</title>
<tgroup cols="2">
@ -8234,20 +8163,7 @@ bctrl</programlisting>
</tbody>
</tgroup>
</table>
<para revisionflag="deleted">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
may be modified. The caller must provide a nop
after the bl instruction performing a call, if r2 is not known to have
the same value in the callee. This is generally true for external calls.
The linker will replace the nop with an r2 restoring instruction if the
caller and callee use different r2 values, The linker leaves it
unchanged if they
use the same r2 value. This scheme avoids having a compiler generate an
overconservative r2 save and restore around every external
call.</para>
<para revisionflag="added">
<para>
When a function requires addressability through the TOC
pointer register, r2, and that function calls another function
that may not preserve the value of r2, the caller must provide
@ -8258,7 +8174,7 @@ bctrl</programlisting>
<xref linkend="dbdoclet.50655241_FnLinkage" /> for a full
description of when a nop must be inserted.
</para>
<para revisionflag="added">
<para>
There are two cases where the caller need not provide a nop after
the bl instruction performing a call:
<itemizedlist spacing="compact">
@ -8272,12 +8188,12 @@ bctrl</programlisting>
<para>For calls to functions resolved at runtime, the linker must
generate stub code to load the function address from the PLT.</para>
<para>The stub code also must save r2 to 24(r1) unless
<phrase revisionflag="added">either the call is marked with an
R_PPC64_REL24_NOTOC relocation, or</phrase> the call is marked
either the call is marked with an
R_PPC64_REL24_NOTOC relocation, or the call is marked
with an R_PPC64_TOCSAVE relocation that points to a nop provided in the
caller's prologue. In <phrase revisionflag="changed">either</phrase>
caller's prologue. In either
case, the stub code can omit the r2 save.
<phrase revisionflag="changed">In the latter case,</phrase>
In the latter case,
the linker replaces the prologue nop with an r2 save.</para>
<programlisting>tocsaveloc:
nop
@ -8307,7 +8223,7 @@ bl target
<xref linkend="dbdoclet.50655240_66111" /> shows the model for branch
instructions.</para>

<table frame="all" pgwide="1" revisionflag="changed"
<table frame="all" pgwide="1"
xml:id="dbdoclet.50655240_66111">
<title>Branch Instruction Model</title>
<tgroup cols="2">
@ -8366,7 +8282,7 @@ 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" revisionflag="changed"
<table frame="all" pgwide="1"
xml:id="dbdoclet.50655240_AbsSwitch">
<title>Absolute Switch Code (Within) for static modules located in low
or high 2 GB of address space</title>
@ -8432,7 +8348,7 @@ bctr
lwz instruction in place of the lwa instruction.</para>
</note>
<table frame="all" pgwide="1" revisionflag="changed"
<table frame="all" pgwide="1"
xml:id="dbdoclet.50655240_AbsSwitchBeyond">
<title>Absolute Switch Code (Beyond) for static modules beyond the top
or bottom 2 GB of the address space</title>
@ -8499,7 +8415,7 @@ 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" revisionflag="changed"
<table frame="all" pgwide="1"
xml:id="dbdoclet.50655240_SwitchPicMed">
<title>Position-Independent Switch Code for Small/Medium Models
(preferred, with TOC-relative addressing)</title>
@ -8567,7 +8483,7 @@ bctr
table ensures position independence when code is loaded at different
addresses.</para>

<table frame="all" pgwide="1" revisionflag="changed"
<table frame="all" pgwide="1"
xml:id="dbdoclet.50655240_SwitchGotAll">
<title>Position-Independent Switch Code for All Models (alternate, with
GOT-indirect addressing)</title>
@ -8649,12 +8565,11 @@ f1:
.long .TOC. - Ldefault
.long .TOC. - Lcase13</programlisting>
</figure>
<para revisionflag="added">
<para>
<xref linkend="dbdoclet.50655240_PCRelSwitch" /> shows a switch
implementation for PC-relative compilation units.
</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_PCRelSwitch"
revisionflag="added">
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_PCRelSwitch">
<title>
Position-Independent Switch Code (PC-Relative Addressing)
</title>
@ -8780,10 +8695,8 @@ addi r3,r1,p ; R3 = new data area following parameter save area.</pro
<para>Because it is allowed (and common) to return without first
deallocating this dynamically allocated memory, all the linkage
information in the new location must be valid. Therefore, it is also
necessary to copy the <phrase revisionflag="deleted">CR save
word and the</phrase> TOC pointer doubleword from <phrase
revisionflag="deleted">their old locations</phrase> <phrase
revisionflag="added">its old location</phrase> to the new. It is
necessary to copy the TOC pointer doubleword from its old location
to the new. It is
not necessary to copy the LR save
doubleword because, until this function makes a call, it does not contain
a value that needs to be preserved. In the future, if it is defined and
@ -9162,7 +9075,7 @@ addi r3,r1,p ; R3 = new data area following parameter save area.</pro
in the Itanium C++ ABI, the normative text on the issue. For information
about how to locate this material, see
<xref linkend="dbdoclet.50655239___RefHeading___Toc377640569" />.</para>
<para revisionflag="added">
<para>
When unwinding, care must be taken to restore the TOC pointer r2 if and
only if it has been saved. It is recommended that the unwinder reads the
instruction at the return address in the link register and restores r2

File diff suppressed because it is too large Load Diff

@ -698,12 +698,12 @@ PPC_FEATURE_HAS_VSX 0x00000080 /* P7 Vector Extension. */
PPC_FEATURE_PSERIES_PERFMON_COMPAT 0x00000040
PPC_FEATURE_TRUE_LE 0x00000002
PPC_FEATURE_PPC_LE 0x00000001</programlisting>
<para revisionflag="added">Bit 0x00000004 is reserved for kernel use.
<para>Bit 0x00000004 is reserved for kernel use.
</para>
<para>AT_HWCAP2</para>
<para>The a_val member of this entry is a bit map of hardware
capabilities. Some bit mask values include:</para>
<programlisting revisionflag="changed">PPC_FEATURE2_ARCH_2_07 0x80000000 /* ISA 2.07 */
<programlisting>PPC_FEATURE2_ARCH_2_07 0x80000000 /* ISA 2.07 */
PPC_FEATURE2_HAS_HTM 0x40000000 /* Hardware Transactional Memory */
PPC_FEATURE2_HAS_DSCR 0x20000000 /* Data Stream Control Register */
PPC_FEATURE2_HAS_EBB 0x10000000 /* Event Base Branching */
@ -825,13 +825,11 @@ PPC_FEATURE2_MMA 0x00020000 /* Matrix Multiply Assist */</programlist
addis instruction to provide a first high-order 16-bit portion of a
32-bit displacement in conjunction with an instruction to supply a
low-order 16-bit portion of a 32-bit displacement.</para>
<para>In PIC code<phrase revisionflag="added"> that uses the
TOC</phrase>, the TOC pointer r2 points to the TOC base, enabling
<para>In PIC code that uses the
TOC, the TOC pointer r2 points to the TOC base, enabling
easy reference. For static nonrelocatable modules, the GOT address is
fixed and can be directly used by code.</para>
<para revisionflag="deleted">All functions except leaf routines must
load the value of the TOC base into the TOC register r2.</para>
<para revisionflag="added">
<para>
Code may access GOT entries directly using PC-relative addressing,
where available.
</para>
@ -1040,11 +1038,11 @@ PPC_FEATURE2_MMA 0x00020000 /* Matrix Multiply Assist */</programlist
ld r12,func@plt@l(r12)
mtctr r12
bctr</programlisting>
<para revisionflag="added">
<para>
When PC-relative addressing is available, another simpler variant
may alternatively be used for cases 2 or 3:
</para>
<programlisting revisionflag="added">pld r12, func@plt@pcrel
<programlisting>pld r12, func@plt@pcrel
mtctr r12
bctr</programlisting>
<para>To support lazy binding, the link editor also provides a set of
@ -1084,9 +1082,9 @@ bctr</programlisting>
mtlr r0
# Compute .plt section index from entry point address in r12
# .plt section index is placed into r0 as argument to the resolver
sub <phrase revisionflag="changed">r12</phrase>,r12,r11
subi <phrase revisionflag="changed">r12,r12</phrase>,res_0-1b
srdi r0,<phrase revisionflag="changed">r12</phrase>,2
sub r12,r12,r11
subi r12,r12,res_0-1b
srdi r0,r12,2
# Load address of the first byte of the PLT
ld r12,PLToffset-1b(r11)
add r11,r12,r11

@ -242,7 +242,7 @@ xml:id="dbdoclet.50655243_pgfId-1099317">
the Power ISA for a POWER8 processor.</para>
</entry>
</row>
<row revisionflag="added">
<row>
<entry>
<para>__PCREL__</para>
</entry>
@ -329,8 +329,6 @@ xml:id="dbdoclet.50655243_pgfId-1099317">
<row>
<entry morerows="1">
<para>__VEC_ELEMENT_REG_ORDER__</para>
<para revisionflag="deleted">For more information, see
<xref linkend="dbdoclet.50655244_25365" />.</para>
</entry>
<entry>
<para>__ORDER_BIG_ENDIAN__</para>

File diff suppressed because it is too large Load Diff

@ -27,46 +27,6 @@
implementation-specific features.
</para>
<!-- Following deleted as redundant with sections 1 and 2.2.1, and
confusing with regard to subsequent ISA publication
strategies. -->

<para revisionflag="deleted">Specifically, to use this ABI and ABI-compliant programs, OpenPOWER-compliant
processors must implement the following categories:
<itemizedlist>
<listitem><para>Base</para></listitem>
<listitem><para>64-Bit</para></listitem>
<listitem><para>Server (subject to system-level requirements)</para></listitem>
<listitem><para>Floating-Point</para></listitem>
<listitem><para>Floating-Point.Record</para></listitem>
<listitem><para>Load/Store Quadword x2</para></listitem>
<listitem><para>Store Conditional Page Mobility (subject to system-level requirements)</para></listitem>
<listitem><para>Stream</para></listitem>
<listitem><para>Transactional Memory</para></listitem>
<listitem><para>Vector</para></listitem>
<listitem><para>Vector.Little-Endian</para></listitem>
<listitem><para>Vector-Scalar</para></listitem>
</itemizedlist>
</para>
<para revisionflag="deleted">For more information about these categories, see “Categories” in Book I of
<citetitle>Power ISA</citetitle>, version 2.07B.
</para>
<para revisionflag="deleted">The OpenPOWER ELF V2 ABI is intended for use in little- and big-endian environments.
</para>
<simplesect>
<title>Notices</title>
<?dbhtml stop-chunking?>

Loading…
Cancel
Save