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

Fix github issue #59, Lower-priority corrections from Ian's review.

Browse Source 
Signed-off-by: Bill Schmidt <linux.vnet.ibm.com>
master
Bill Schmidt 7 years ago
parent 0b238260d2
commit f908db83d2
6 changed files with 76 additions and 83 deletions
Show Stats Download Patch File Download Diff File

2
specification/app_a.xml
Unescape Escape View File

@ -821,7 +821,7 @@ xml:id="dbdoclet.50655245_pgfId-1138128">
</entry>
<entry revisionflag="added">
<para>vector bool long long vec_and (vector bool long long,
vector bool long long)</para>
vector bool long long);</para>
</entry>
</row>
<row>

8
specification/app_b.xml
Unescape Escape View File

@ -15,10 +15,10 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"
xml:id="dbdoclet.50655245_pgfId-1450875" revisionflag="added">
<title>Binary-Coded Decimal Built-In Functions</title>
<para>Binary-coded decimal (BCD) values are compressed; each decimal digit
and sign bit occupies 4 bits. Digits are ordered right-to-left in the order
of significance. The final 4 bits encode the sign. A valid encoding must
have a value in the range 0&#8211;9 in each of its 31 digits, and a value in
the range 10&#8211;15 for the sign field.</para>
and sign bit occupies 4 bits. Digits are ordered with the most significant
on the left and the least on the right. The final 4 bits encode the sign.
A valid encoding must have a value in the range 0&#8211;9 in each of its 31
digits, and a value in the range 10&#8211;15 for the sign field.</para>
<para>Source operands with sign codes of 0b1010, 0b1100, 0b1110, or 0b1111
are interpreted as positive values. Source operands with sign codes of
0b1011 or 0b1101 are interpreted as negative values.</para>

4
specification/app_glossary.xml
Unescape Escape View File

@ -314,7 +314,7 @@ xml:id="dbdoclet.50655246_33489">
<para>LSB</para>
</entry>
<entry>
<para>Least-significant byte</para>
<para>Least-significant byte, least-significant bit</para>
</entry>
</row>
<row revisionflag="added">
@ -330,7 +330,7 @@ xml:id="dbdoclet.50655246_33489">
<para>MSB</para>
</entry>
<entry>
<para>Most-significant byte</para>
<para>Most-significant byte, most-significant bit</para>
</entry>
</row>
<row revisionflag="added">

2
specification/ch_1.xml
Unescape Escape View File

@ -40,7 +40,7 @@
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 subscribe to either byte
ordering is not portable to a system running in the other mode.</para>
ordering are not portable to a system running in the other mode.</para>
<itemizedlist>
<listitem>
<para>Note:

103
specification/ch_2.xml
Unescape Escape View File

@ -2234,13 +2234,13 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<entry>
<para>long int</para>
</entry>
<entry>
<entry morerows="1">
<para>8</para>
</entry>
<entry>
<entry morerows="1">
<para>Doubleword</para>
</entry>
<entry>
<entry morerows="1">
<para>Signed doubleword</para>
</entry>
</row>
@ -2248,15 +2248,6 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<entry>
<para>signed long int</para>
</entry>
<entry>
<para>8</para>
</entry>
<entry>
<para>Doubleword</para>
</entry>
<entry>
<para>Signed doubleword</para>
</entry>
</row>
<row>
<entry>
@ -2806,7 +2797,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>Quadword</para>
</entry>
<entry>
<para>Vector of 2 double-precision doubles.</para>
<para>Vector of 2 double-precision floats.</para>
</entry>
</row>
</tbody>
@ -2981,10 +2972,10 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</tgroup>
</table>
<para>&#160;</para>
<bridgehead xml:id="dbdoclet.50655240_66797">IEEE BINARY 128 EXTENDED
<bridgehead xml:id="dbdoclet.50655240_66797">IEEE BINARY 128 QUADRUPLE
PRECISION</bridgehead>
<table frame="all" pgwide="1">
<title>IEEE BINARY 128 EXTENDED PRECISION Type</title>
<title>IEEE BINARY 128 QUADRUPLE PRECISION Type</title>
<tgroup cols="6">
<colspec colname="c1" colwidth="15*" />
<colspec colname="c2" colwidth="20*" />
@ -3029,7 +3020,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<tbody>
<row>
<entry>
<para>IEEE BINARY 128 EXTENDED PRECISION</para>
<para>IEEE BINARY 128 QUADRUPLE PRECISION</para>
</entry>
<entry>
<para>long double</para>
@ -3052,7 +3043,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</row>
<row>
<entry>
<para>IEEE BINARY 128 EXTENDED PRECISION</para>
<para>IEEE BINARY 128 QUADRUPLE PRECISION</para>
</entry>
<entry>
<para>_Float128</para>
@ -3095,14 +3086,14 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</tgroup>
</table>
<para>&#160;</para>
<bridgehead>IBM EXTENDED PRECISION &amp;&amp; IEEE BINARY 128 EXTENDED
<bridgehead>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 EXTENDED PRECISION format are mutually
format and the IEEE BINARY 128 QUADRUPLE PRECISION format are mutually
exclusive.</para>
<para>&#160;</para>
<bridgehead xml:id="dbdoclet.50655240_95080">IEEE BINARY 128 EXTENDED
<bridgehead xml:id="dbdoclet.50655240_95080">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
@ -3110,7 +3101,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
type.</para>
<itemizedlist>
<listitem>
<para>IEEE BINARY 128 EXTENDED PRECISION</para>
<para>IEEE BINARY 128 QUADRUPLE PRECISION</para>
<itemizedlist>
<listitem>
<para>Long double is implemented as an IEEE 128-bit quad-precision
@ -3121,8 +3112,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>Support is provided for all IEEE standard features.</para>
</listitem>
<listitem>
<para>IEEE128 quad-precision values are passed in VMX parameter
registers.</para>
<para>IEEE128 quad-precision values are passed and returned in
VMX parameter registers.</para>
</listitem>
<listitem>
<para>With some compilers, _Float128 can be used to access IEEE128
@ -3211,9 +3202,9 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
previous member, internal padding can be required.</para>
</listitem>
<listitem>
<para>The entire aggregate or union must have a size that is a
multiple of its alignment. Depending on the last member, tail
padding may be required.</para>
<para>Unless it is packed, the entire aggregate or union must have
a size that is a multiple of its alignment. Depending on the last
member, tail padding may be required.</para>
</listitem>
</itemizedlist>
<para>For
@ -3459,9 +3450,9 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
least-significant (right) end.</para>
</listitem>
<listitem>
<para>A bit field cannot cross its unit boundary; it must occupy
part or all or the storage unit allocated for its declared
type.</para>
<para>Unless it appears in a packed struct, a bit field cannot
cross its unit boundary; it must occupy part or all of the storage
unit allocated for its declared type.</para>
</listitem>
<listitem>
<para>If there is enough space within a storage unit, bit fields
@ -4644,27 +4635,14 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<bridgehead xml:id="dbdoclet.50655240_12913">DFP Support</bridgehead>
<para>The OpenPOWER ABI supports the decimal floating-point (DFP)
format and DFP language extensions. The default implementation of DFP
types shall be a software implementation of the IEEE DFP standard (IEEE
Standard 754-2008).</para>
types shall be an implementation of the IEEE DFP standard (IEEE
Standard 754-2008). The default may be either a hardware or a
software implementation.</para>
<para>The Power ISA decimal floating-point category extends the Power
Architecture by adding a decimal floating-point unit. It uses the
existing 64-bit floating-point registers and extends the FPSCR register
to 64 bits, where it defines a decimal rounding-control field in the
extended space. For OpenPOWER, DFP support is defined as an optional
category. When DFP is supported as a vendor-specific implementation
capability, compilers can be used to implement DFP support. The
compilers should provide an option to generate DFP instructions or to
issue calls to DFP emulation software. The DFP parameters are passed in
floating-point registers.</para>
<para>As with other implementation-specific features, all
OpenPOWER-compliant programs must be able to execute, functionally
indistinguishably, on hardware with and without vendor-specific
extensions. It is the application's responsibility to transparently
adapt to the absence of vendor-specific features by using a library
responsive to the presence of DFP hardware, or in conjunction with
operating-system dynamic library services, to select from among
multiple DFP libraries that contain either a first software
implementation or a second hardware implementation.</para>
extended space.</para>
<para>Single-precision, double-precision, and quad-precision decimal
floating-point parameters shall be passed in the floating-point
registers. Single-precision decimal floating-point shall occupy the
@ -4721,6 +4699,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</tbody>
</tgroup>
</table>
<bridgehead>Vector Registers</bridgehead>
<para>The OpenPOWER vector-category instruction repertoire provides the
ability to reference 32 vector registers, each 128 bits wide, of the
vector-scalar register file, and a special-purpose register VSCR.
@ -4815,17 +4794,17 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</tgroup>
</table>
<para>&#160;</para>
<bridgehead xml:id="dbdoclet.50655240_89740">IEEE BINARY 128 EXTENDED
<bridgehead xml:id="dbdoclet.50655240_89740">IEEE BINARY 128 QUADRUPLE
PRECISION</bridgehead>
<para>Parameters in IEEE BINARY 128 EXTENDED PRECISION format shall be
passed in a single 128-bit vector register as if they were vector
values.</para>
<para>Parameters and function results in IEEE BINARY 128 QUADRUPLE
PRECISION format shall be passed in a single 128-bit vector register
as if they were vector values.</para>
<para>&#160;</para>
<bridgehead xml:id="dbdoclet.50655240_40559">IBM EXTENDED
PRECISION</bridgehead>
<para>Parameters in the IBM EXTENDED PRECISION format with a pair of
two double-precision floating-point values shall be passed in two
successive floating-point registers.</para>
<para>Parameters and function results in the IBM EXTENDED PRECISION
format with a pair of two double-precision floating-point values shall
be passed in two successive floating-point registers.</para>
<para>If only one value can be passed in a floating-point register, the
second parameter will be passed in a GPR or in memory in accordance
with the parameter passing rules for structure aggregates.</para>
@ -5081,7 +5060,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</listitem>
<listitem>
<para>
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640599" />.</para>
See <xref linkend="dbdoclet.50655240___RefHeading___Toc377640599" />.</para>
</listitem>
<listitem>
<para>Before a function calls any other functions, it shall save
@ -5250,8 +5229,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
Parameter Save Area to be created for functions where the number and
type of parameters exceeds the registers available for parameter
passing in registers, for those functions where the prototype contains
an ellipsis to indicate a variadic function, and functions are declared
without prototype.)</para>
an ellipsis to indicate a variadic function, and functions declared
without a prototype.)</para>
<para>When the caller allocates the Parameter Save Area, it will always
be automatically quadword aligned because it must always start at SP +
32. It shall be at least 8 doublewords in length. If a function needs
@ -5346,7 +5325,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</listitem>
<listitem>
<para>If extended precision floating-point values in IEEE BINARY
128 EXTENDED PRECISION format are supported (see
128 QUADRUPLE PRECISION format are supported (see
<xref linkend="dbdoclet.50655240_66797" />), map them to a single
quadword, quadword aligned. This might result in skipped
doublewords in the Parameter Save Area.</para>
@ -5506,7 +5485,7 @@ 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, four IEEE BINARY 128 EXTENDED precision
EXTENDED PRECISION members, four IEEE BINARY 128 QUADRUPLE 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
@ -5554,7 +5533,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>A homogeneous aggregate is either a homogeneous floating-point
aggregate or a homogeneous vector aggregate. This ABI does not specify
homogeneous aggregates for integer types.</para>
<para>Binary extended precision numbers in IEEE BINARY 128 EXTENDED
<para>Binary extended precision numbers in IEEE BINARY 128 QUADRUPLE
PRECISION format (see
<xref linkend="dbdoclet.50655240_89740" />) are passed using a VMX
register. Binary extended precision numbers in IBM EXTENDED PRECISION
@ -5591,7 +5570,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
valid and invalid, except in the last doubleword where invalid padding
may be present.)</para>
<para>&#160;</para>
<bridgehead>IEEE BINARY 128 EXTENDED PRECISION</bridgehead>
<bridgehead>IEEE BINARY 128 QUADRUPLE PRECISION</bridgehead>
<itemizedlist mark="none">
<listitem>
<para>Up to 12 quad-precision parameters can be passed in v2&#8211;v13.
@ -5766,13 +5745,13 @@ float:
// float is passed in one FPR.
// double is passed in one FPR.
// IBM EXTENDED PRECISION is passed in the next two FPRs.
// IEEE BINARY 128 EXTENDED PRECISION is passed in one VR.
// IEEE BINARY 128 QUADRUPLE PRECISION is passed in one VR.
// _Decimal32 is passed in the lower half of one FPR.
// _Decimal64 is passed in one FPR.
// _Decimal128 is passed in an even-odd FPR pair, skipping an FPR if necessary.

if (register_type_used (type (argument)) == vr)
// Assumes == vr is true for IEEE BINARY 128 EXTENDED PRECISION.
// Assumes == vr is true for IEEE BINARY 128 QUADRUPLE PRECISION.
goto use_vr;
fr += align_pad(fr,type(argument))

40
specification/ch_6.xml
Unescape Escape View File

@ -103,8 +103,8 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
types.</para>
<para>The traditional C/C++ operators are defined on vector types with “do
all” semantics for unary and binary +, unary and binary &#8211;, binary *, binary
%, and binary / as well as the unary and binary logical and comparison
operators.</para>
%, and binary / as well as the unary and binary shift, logical and
comparison operators, and the ternary ?: operator.</para>
<para>For unary operators, the specified operation is performed on the
corresponding base element of the single operand to derive the result value
for each vector element of the vector result. The result type of unary
@ -871,8 +871,12 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<para>lxvd2x</para>
</entry>
<entry>
<para>Use lxvd2x for vector long long; vector long, vector
double.</para>
<para>Use lxvd2x for vector long long; vector long,<footnote
xml:id="vlongbad">
<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>
</footnote> vector double.</para>
<para>Use lxvd2x followed by reversal of elements within each
doubleword for all other data types.</para>
</entry>
@ -885,8 +889,8 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<para>stxvd2x</para>
</entry>
<entry>
<para>Use stxvd2x for vector long long; vector long, vector
double.</para>
<para>Use stxvd2x for vector long long; vector long,<footnoteref
linkend="vlongbad" /> vector double.</para>
<para>Use stxvd2x following a reversal of elements within each
doubleword for all other data types.</para>
</entry>
@ -1169,8 +1173,12 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<para>lxvd2x</para>
</entry>
<entry>
<para>Use lxvd2x for vector long long; vector long, vector
double.</para>
<para>Use lxvd2x for vector long long; vector long,<footnote
xml:id="vlongawful">
<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>
</footnote> vector double.</para>
</entry>
</row>
<row>
@ -1213,8 +1221,8 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<para>stxvd2x</para>
</entry>
<entry>
<para>Use stxvd2x for vector long long; vector long, vector
double.</para>
<para>Use stxvd2x for vector long long; vector long,<footnoteref
linkend="vlongawful" /> vector double.</para>
</entry>
</row>
<row>
@ -1274,7 +1282,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
bit-exact type conversions between vector types.</para>
<para> </para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50655244_14722">
<title>Built-In Vector Conversion Function</title>
<title>Built-In Vector Conversion Functions</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="30*" align="center" />
<colspec colname="c2" colwidth="70*" />
@ -1422,7 +1430,12 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<para>VECTOR(INTEGER(8))</para>
</entry>
<entry>
<para>vector signed long long, vector signed long</para>
<para>vector signed long long, vector signed long<footnote
xml:id="vlongappalling">
<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>
</footnote></para>
</entry>
</row>
<row>
@ -1462,7 +1475,8 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<para>VECTOR(UNSIGNED(8))</para>
</entry>
<entry>
<para>vector unsigned long long, vector unsigned long</para>
<para>vector unsigned long long, vector unsigned long<footnoteref
linkend="vlongappalling" /></para>
</entry>
</row>
<row>

Write Preview
Loading…
Cancel
Save