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

Change to draft status for revision 1.5. Incorporate errata 1.0 for

Browse Source 
revision 1.4.

Signed-off-by: Bill Schmidt <wschmidt@linux.vnet.ibm.com>
master
Bill Schmidt 6 years ago
parent b40a909f05
commit 7d4d77fcda
4 changed files with 28 additions and 46 deletions
Show Stats Download Patch File Download Diff File

14
specification/bk_main.xml
Unescape Escape View File

@ -37,7 +37,7 @@
</author> </author>
<copyright> <copyright>
<!-- TODO: Keep second year accurate for latest publish --> <!-- TODO: Keep second year accurate for latest publish -->
<year>2014-2017</year> <year>2014-2018</year>
<holder>OpenPOWER Foundation</holder> <holder>OpenPOWER Foundation</holder>
</copyright> </copyright>
<copyright> <copyright>
@ -57,7 +57,7 @@
<holder>Freescale Semiconductor, Inc</holder> <holder>Freescale Semiconductor, Inc</holder>
</copyright> </copyright>
<!-- TODO: Set the correct document releaseinfo --> <!-- TODO: Set the correct document releaseinfo -->
<releaseinfo>Revision 1.4</releaseinfo> <releaseinfo>Revision 1.5 draft</releaseinfo>
<productname>OpenPOWER</productname> <productname>OpenPOWER</productname>
<pubdate/> <pubdate/>


@ -93,6 +93,16 @@


<revhistory> <revhistory>
<!-- TODO: Set the initial version information and clear any old information out --> <!-- TODO: Set the initial version information and clear any old information out -->
<revision>
<date>2018-03-02</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Revision 1.5: POWER10 support.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision> <revision>
<date>2017-05-10</date> <date>2017-05-10</date>
<revdescription> <revdescription>

5
specification/ch_2.xml
Unescape Escape View File

@ -2065,11 +2065,6 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
order encountered, to ensure consistent mapping. When using variables order encountered, to ensure consistent mapping. When using variables
individually, more strict alignment may be imposed if it has individually, more strict alignment may be imposed if it has
optimization benefits.</para> optimization benefits.</para>
<para>Regardless of the alignment rules for the allocation of data
types, pointers to both aligned and unaligned data of each data type
shall return the value corresponding to a data type starting at the
specified address when accessed with either the pointer dereference
operator * or the array reference operator [ ].</para>


<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_49259"> <table frame="all" pgwide="1" xml:id="dbdoclet.50655240_49259">
<?dbfo keep-together="always" ?> <?dbfo keep-together="always" ?>

51
specification/ch_6.xml
Unescape Escape View File

@ -67,27 +67,15 @@ xml:id="dbdoclet.50655244_pgfId-1095944">
static, auto, and register storage.</para> static, auto, and register storage.</para>
<para>Pointers to vector types are defined like pointers of other C/C++ <para>Pointers to vector types are defined like pointers of other C/C++
types. Pointers to objects may be defined to have const and volatile types. Pointers to objects may be defined to have const and volatile
properties. While the preferred alignment for vector data types is a properties.</para>
multiple of 16 bytes, pointers may point to vector objects at an arbitrary
alignment.</para>
<para>The preferred way to access vectors at an application-defined address <para>The preferred way to access vectors at an application-defined address
is by using vector pointers and the C/C++ dereference operator *. Similar is by using vector pointers and the C/C++ dereference operator *. Similar
to other C /C++ data types, the array reference operator [ ] may be used to to other C /C++ data types, the array reference operator [ ] may be used to
access vector objects with a vector pointer with the usual definition to access vector objects with a vector pointer with the usual definition to
access the n-th vector element from a vector pointer. The use of vector access the n-th vector element from a vector pointer. The dereference
built-in functions such as vec_xl and vec_xst is discouraged except for operator * may <emphasis>not</emphasis> be used to access data that is
languages where no dereference operators are available.</para> not aligned at least to a quadword boundary. Built-in functions such as
<programlisting>vector char vca; vec_xl and vec_xst are provided for unaligned data access.</para>
vector char vcb;
vector int via;
int a[4];
void *vp;
via = *(vector int *) &amp;a[0];
vca = (vector char) via;
vcb = vca;
vca = *(vector char *)vp;
*(vector char *)&amp;a[0] = vca;</programlisting>
<para>Compilers are expected to recognize and optimize multiple operations <para>Compilers are expected to recognize and optimize multiple operations
that can be optimized into a single hardware instruction. For example, a that can be optimized into a single hardware instruction. For example, a
load and splat hardware instruction might be generated for the following load and splat hardware instruction might be generated for the following
@ -578,12 +566,6 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</tbody> </tbody>
</tgroup> </tgroup>
</table> </table>
<note>
<para><emphasis role="bold">Reminder</emphasis>: The assignment operator = is the
preferred way to assign values from one vector data type to
another vector data type in accordance with the C and C++
programming languages.</para>
</note>
<para>&#160;</para> <para>&#160;</para>
<bridgehead>Extended Data Movement Functions</bridgehead> <bridgehead>Extended Data Movement Functions</bridgehead>
<para>The built-in functions in <para>The built-in functions in
@ -702,25 +684,20 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
of these sequences in new code is discouraged and usually results in of these sequences in new code is discouraged and usually results in
worse performance. It is recommended (but not required) that compilers worse performance. It is recommended (but not required) that compilers
issue a warning when these functions are used in little-endian issue a warning when these functions are used in little-endian
environments. It is recommended that programmers use the assignment environments. It is recommended that programmers use the vec_xl and
operator = or the vector vec_xl and vec_xst vector built-in functions to vec_xst vector built-in functions to access unaligned data
access unaligned data streams.</para> streams.</para>
<para>The set of extended mnemonics in <para>The built-in functions in
<xref linkend="dbdoclet.50655244_62451" /> may be provided by some <xref linkend="dbdoclet.50655244_62451" /> provide unaligned access to
compilers and are not required by the Power SIMD programming interfaces. data in memory that is to be copied to or from a variable having vector
In particular, the assignment operator = will have the same effect of data type. Memory access built-in
copying values between vector data types and provides a preferable method
to assign values while giving the compiler more freedom to optimize data
allocation. The only use for these functions is to support some coding
patterns enabling big-endian vector layout code sequences in both
big-endian and little-endian environments. Memory access built-in
functions that specify a vector element format (that is, the w4 and d2 functions that specify a vector element format (that is, the w4 and d2
forms) are deprecated. They will be phased out in future versions of this forms) are deprecated. They will be phased out in future versions of this
specification because vec_xl and vec_xst provide overloaded specification because vec_xl and vec_xst provide overloaded
layout-specific memory access based on the specified vector data layout-specific memory access based on the specified vector data
type.</para> type.</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50655244_62451"> <table frame="all" pgwide="1" xml:id="dbdoclet.50655244_62451">
<title>Optional Built-In Memory Access Functions</title> <title>VSX Memory Access Built-In Functions</title>
<tgroup cols="3"> <tgroup cols="3">
<colspec colname="c1" colwidth="15*" align="center" /> <colspec colname="c1" colwidth="15*" align="center" />
<colspec colname="c2" colwidth="35*" align="center" /> <colspec colname="c2" colwidth="35*" align="center" />
@ -1137,7 +1114,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<xref linkend="dbdoclet.50655244_21918" />.</para> <xref linkend="dbdoclet.50655244_21918" />.</para>
<para> </para> <para> </para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50655244_21918"> <table frame="all" pgwide="1" xml:id="dbdoclet.50655244_21918">
<title>Optional Built-In Memory Access Functions (BE Layout in LE <title>VSX Built-In Memory Access Functions (BE Layout in LE
Mode)</title> Mode)</title>
<tgroup cols="3"> <tgroup cols="3">
<colspec colname="c1" colwidth="15*" align="center"/> <colspec colname="c1" colwidth="15*" align="center"/>

4
specification/pom.xml
Unescape Escape View File

@ -123,9 +123,9 @@
review = this document is presently being reviewed review = this document is presently being reviewed


The appropriate starting security for a new document is "draft". --> The appropriate starting security for a new document is "draft". -->
<!-- documentStatus>draft</documentStatus --> <documentStatus>draft</documentStatus>
<!-- documentStatus>review</documentStatus --> <!-- documentStatus>review</documentStatus -->
<documentStatus>published</documentStatus> <!-- documentStatus>published</documentStatus -->


</configuration> </configuration>
</execution> </execution>

Write Preview
Loading…
Cancel
Save