|
|
<!--
|
|
|
Copyright (c) 2016 OpenPOWER Foundation
|
|
|
|
|
|
Licensed under the GNU Free Documentation License, Version 1.3;
|
|
|
with no Invariants Sections, with no Front-Cover Texts,
|
|
|
and with no Back-Cover Texts (the "License");
|
|
|
you may not use this file except in compliance with the License.
|
|
|
You may obtain a copy of the License at
|
|
|
|
|
|
http://www.gnu.org/licenses/fdl-1.3.txt
|
|
|
|
|
|
-->
|
|
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
|
|
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"
|
|
|
xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
<title>Low-Level System Information</title>
|
|
|
<section>
|
|
|
<title>Machine Interface</title>
|
|
|
<para>The machine interface describes the specific use of the Power ISA
|
|
|
64-bit features to implement the ELF ABI version 2.</para>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640572">
|
|
|
<title>Processor Architecture</title>
|
|
|
<para>This ABI is predicated on, at a minimum, Power ISA version 2.7 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.
|
|
|
ABI-conforming implementations must provide these instructions through
|
|
|
software emulation if they are not provided by the OpenPOWER-compliant
|
|
|
processor.</para>
|
|
|
<para>In addition, the instruction specification must meet additional
|
|
|
implementation-defined specifics as commonly required by the OpenPOWER
|
|
|
specification.</para>
|
|
|
<para>OpenPOWER-compliant processors may support additional instructions
|
|
|
beyond the published Power Instruction Set Architecture (ISA) and may
|
|
|
include optional Power Architcture instructions.</para>
|
|
|
<para>This ABI does not explicitly impose any performance constraints on
|
|
|
systems.</para>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640573">
|
|
|
<title>Data Representation</title>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640574">
|
|
|
<title>Byte Ordering</title>
|
|
|
<para>The following standard data formats are recognized:</para>
|
|
|
<itemizedlist spacing="compact">
|
|
|
<listitem>
|
|
|
<para>8-bit byte</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>16-bit halfword</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>32-bit word</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>64-bit doubleword</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>128-bit quadword</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>In little-endian byte ordering, the least-significant byte is
|
|
|
located in the lowest addressed byte position in memory (byte 0). This
|
|
|
byte ordering is alternately referred to as least-significant byte
|
|
|
(LSB) ordering.</para>
|
|
|
<para>In big-endian byte ordering, the most-significant byte is located
|
|
|
in the lowest addressed byte position in memory (byte 0). This byte
|
|
|
ordering is alternately referred to as most-significant byte (MSB)
|
|
|
ordering.</para>
|
|
|
<para>A specific OpenPOWER-compliant processor implementation must
|
|
|
state which type of byte ordering is to be used.</para>
|
|
|
<note>
|
|
|
<para>MSR[LE|SLE]: Although it may be possible to modify the
|
|
|
active byte ordering of an application process that uses
|
|
|
application-accessible configuration controls or that uses system
|
|
|
calls on some systems, applications that change active byte ordering
|
|
|
during the course of execution do not conform to this ABI.</para>
|
|
|
</note>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_73292" /> through
|
|
|
<xref linkend="dbdoclet.50655240_16995" /> show the conventions assumed
|
|
|
in little-endian byte ordering at the bit and byte levels. These
|
|
|
conventions are applied to integer and floating-point data types. As
|
|
|
shown in
|
|
|
<xref linkend="dbdoclet.50655240_92041" />, byte numbers are indicated
|
|
|
in the upper corners, and bit numbers are indicated in the lower
|
|
|
corners.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1" rowsep="0" colsep="0"
|
|
|
xml:id="dbdoclet.50655240_92041">
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
<title>Little-Endian Bit and Byte Numbering Example</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="50*" />
|
|
|
<colspec colname="c2" colwidth="50*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right">
|
|
|
<para>Little-Endian Byte Number</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry nameend="c2" namest="c1">
|
|
|
<para> </para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para> </para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Little-Endian Bit Number End</para>
|
|
|
</entry>
|
|
|
<entry align="right">
|
|
|
<para>Little-Endian Bit Number Start</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
|
|
|
<table frame="all" pgwide="1" rowsep="0" colsep="0"
|
|
|
xml:id="dbdoclet.50655240_73292">
|
|
|
<?dbhtml table-width="30%" ?>
|
|
|
<?dbfo table-width="30%" ?>
|
|
|
<title>Little-Endian Bit and Byte Numbering in Halfwords</title>
|
|
|
<tgroup cols="6">
|
|
|
<colspec colname="c1" colwidth="6*" />
|
|
|
<colspec colname="c2" colwidth="6*" />
|
|
|
<colspec colname="c3" colwidth="6*" />
|
|
|
<colspec colname="c4" colwidth="6*" />
|
|
|
<colspec colname="c5" colwidth="6*" />
|
|
|
<colspec colname="c6" colwidth="6*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry nameend="c3" namest="c1" align="right" colsep="1">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry nameend="c6" namest="c4" align="right">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry nameend="c3" namest="c1" align="center" colsep="1">
|
|
|
<para>MSB</para>
|
|
|
</entry>
|
|
|
<entry nameend="c6" namest="c4" align="center">
|
|
|
<para>LSB</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry align="left">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
|
|
|
<table frame="all" pgwide="1" rowsep="0" colsep="0">
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
<title>Little-Endian Bit and Byte Numbering in Words</title>
|
|
|
<tgroup cols="12">
|
|
|
<colspec colname="c1" colwidth="3*" />
|
|
|
<colspec colname="c2" colwidth="3*" />
|
|
|
<colspec colname="c3" colwidth="3*" />
|
|
|
<colspec colname="c4" colwidth="3*" />
|
|
|
<colspec colname="c5" colwidth="3*" />
|
|
|
<colspec colname="c6" colwidth="3*" />
|
|
|
<colspec colname="c7" colwidth="3*" />
|
|
|
<colspec colname="c8" colwidth="3*" />
|
|
|
<colspec colname="c9" colwidth="3*" />
|
|
|
<colspec colname="c10" colwidth="3*" />
|
|
|
<colspec colname="c11" colwidth="3*" />
|
|
|
<colspec colname="c12" colwidth="3*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>3</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>MSB</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>LSB</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>31</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>24</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>23</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
|
|
|
<table frame="all" pgwide="1" colsep="0" rowsep="0">
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
<title>Little-Endian Bit and Byte Numbering in Doublewords</title>
|
|
|
<tgroup cols="12">
|
|
|
<colspec colname="c1" colwidth="3*" />
|
|
|
<colspec colname="c2" colwidth="3*" />
|
|
|
<colspec colname="c3" colwidth="3*" />
|
|
|
<colspec colname="c4" colwidth="3*" />
|
|
|
<colspec colname="c5" colwidth="3*" />
|
|
|
<colspec colname="c6" colwidth="3*" />
|
|
|
<colspec colname="c7" colwidth="3*" />
|
|
|
<colspec colname="c8" colwidth="3*" />
|
|
|
<colspec colname="c9" colwidth="3*" />
|
|
|
<colspec colname="c10" colwidth="3*" />
|
|
|
<colspec colname="c11" colwidth="3*" />
|
|
|
<colspec colname="c12" colwidth="3*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>6</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>5</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>MSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row rowsep="1">
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>63</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>56</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>55</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>48</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>47</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>40</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>39</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>32</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>3</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>LSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>31</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>24</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>23</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
|
|
|
<table frame="all" pgwide="1" rowsep="0" colsep="0"
|
|
|
xml:id="dbdoclet.50655240_16995">
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
<title>Little-Endian Bit and Byte Numbering in Quadwords</title>
|
|
|
<tgroup cols="12">
|
|
|
<colspec colname="c1" colwidth="3*" />
|
|
|
<colspec colname="c2" colwidth="3*" />
|
|
|
<colspec colname="c3" colwidth="3*" />
|
|
|
<colspec colname="c4" colwidth="3*" />
|
|
|
<colspec colname="c5" colwidth="3*" />
|
|
|
<colspec colname="c6" colwidth="3*" />
|
|
|
<colspec colname="c7" colwidth="3*" />
|
|
|
<colspec colname="c8" colwidth="3*" />
|
|
|
<colspec colname="c9" colwidth="3*" />
|
|
|
<colspec colname="c10" colwidth="3*" />
|
|
|
<colspec colname="c11" colwidth="3*" />
|
|
|
<colspec colname="c12" colwidth="3*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>14</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>13</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>12</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>MSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row rowsep="1">
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>127</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>120</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>119</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>112</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>111</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>104</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>103</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>96</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>11</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>10</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>9</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para> </para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row rowsep="1">
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>95</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>88</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>87</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>80</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>79</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>72</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>71</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>64</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>6</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>5</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para> </para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row rowsep="1">
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>63</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>56</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>55</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>48</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>47</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>40</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>39</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>32</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>3</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>LSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>31</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>24</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>23</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_85970" /> through
|
|
|
<xref linkend="dbdoclet.50655240_23386" /> show the conventions assumed
|
|
|
in big-endian byte ordering at the bit and byte levels. These
|
|
|
conventions are applied to integer and floating-point data types. As
|
|
|
shown in
|
|
|
<xref linkend="dbdoclet.50655240_10997" />, byte numbers are indicated
|
|
|
in the upper corners, and bit numbers are indicated in the lower
|
|
|
corners.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1" colsep="0" rowsep="0"
|
|
|
xml:id="dbdoclet.50655240_10997">
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
<title>Big-Endian Bit and Byte Numbering Example</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="50*" />
|
|
|
<colspec colname="c2" colwidth="50*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>Big-Endian Byte Number</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para> </para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>Big-Endian Bit Number Start</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="0">
|
|
|
<para>Big-Endian Bit Number End</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
|
|
|
<table frame="all" pgwide="1" rowsep="0" colsep="0"
|
|
|
xml:id="dbdoclet.50655240_85970">
|
|
|
<?dbhtml table-width="30%" ?>
|
|
|
<?dbfo table-width="30%" ?>
|
|
|
<title>Big-Endian Bit and Byte Numbering in Halfwords</title>
|
|
|
<tgroup cols="6">
|
|
|
<colspec colname="c1" colwidth="6*" />
|
|
|
<colspec colname="c2" colwidth="6*" />
|
|
|
<colspec colname="c3" colwidth="6*" />
|
|
|
<colspec colname="c4" colwidth="6*" />
|
|
|
<colspec colname="c5" colwidth="6*" />
|
|
|
<colspec colname="c6" colwidth="6*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>MSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>LSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
|
|
|
<table frame="all" pgwide="1" colsep="0" rowsep="0"
|
|
|
xml:id="dbdoclet.50655240_41330">
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
<title>Big-Endian Bit and Byte Numbering in Words</title>
|
|
|
<tgroup cols="12">
|
|
|
<colspec colname="c1" colwidth="3*" />
|
|
|
<colspec colname="c2" colwidth="3*" />
|
|
|
<colspec colname="c3" colwidth="3*" />
|
|
|
<colspec colname="c4" colwidth="3*" />
|
|
|
<colspec colname="c5" colwidth="3*" />
|
|
|
<colspec colname="c6" colwidth="3*" />
|
|
|
<colspec colname="c7" colwidth="3*" />
|
|
|
<colspec colname="c8" colwidth="3*" />
|
|
|
<colspec colname="c9" colwidth="3*" />
|
|
|
<colspec colname="c10" colwidth="3*" />
|
|
|
<colspec colname="c11" colwidth="3*" />
|
|
|
<colspec colname="c12" colwidth="3*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>3</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>MSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>LSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>23</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>24</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>31</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
|
|
|
<table frame="all" pgwide="1" colsep="0" rowsep="0"
|
|
|
xml:id="dbdoclet.50655240_98446">
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
<title>Big-Endian Bit and Byte Numbering in Doublewords</title>
|
|
|
<tgroup cols="12">
|
|
|
<colspec colname="c1" colwidth="3*" />
|
|
|
<colspec colname="c2" colwidth="3*" />
|
|
|
<colspec colname="c3" colwidth="3*" />
|
|
|
<colspec colname="c4" colwidth="3*" />
|
|
|
<colspec colname="c5" colwidth="3*" />
|
|
|
<colspec colname="c6" colwidth="3*" />
|
|
|
<colspec colname="c7" colwidth="3*" />
|
|
|
<colspec colname="c8" colwidth="3*" />
|
|
|
<colspec colname="c9" colwidth="3*" />
|
|
|
<colspec colname="c10" colwidth="3*" />
|
|
|
<colspec colname="c11" colwidth="3*" />
|
|
|
<colspec colname="c12" colwidth="3*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>3</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>MSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row rowsep="1">
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>23</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>24</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>31</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>5</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>6</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>LSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>32</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>39</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>40</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>47</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>48</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>55</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>56</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>63</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<table frame="all" pgwide="1" colsep="0" rowsep="0"
|
|
|
xml:id="dbdoclet.50655240_23386">
|
|
|
<title>Big-Endian Bit and Byte Numbering in Quadwords</title>
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
<tgroup cols="12">
|
|
|
<colspec colname="c1" colwidth="3*" />
|
|
|
<colspec colname="c2" colwidth="3*" />
|
|
|
<colspec colname="c3" colwidth="3*" />
|
|
|
<colspec colname="c4" colwidth="3*" />
|
|
|
<colspec colname="c5" colwidth="3*" />
|
|
|
<colspec colname="c6" colwidth="3*" />
|
|
|
<colspec colname="c7" colwidth="3*" />
|
|
|
<colspec colname="c8" colwidth="3*" />
|
|
|
<colspec colname="c9" colwidth="3*" />
|
|
|
<colspec colname="c10" colwidth="3*" />
|
|
|
<colspec colname="c11" colwidth="3*" />
|
|
|
<colspec colname="c12" colwidth="3*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>3</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>MSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row rowsep="1">
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>23</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>24</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>31</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>5</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>6</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para> </para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row rowsep="1">
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>32</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>39</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>40</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>47</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>48</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>55</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>56</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>63</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>9</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>10</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>11</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para> </para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row rowsep="1">
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>64</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>71</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>72</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>79</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>80</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>87</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>88</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>95</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>12</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>13</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>14</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>LSB</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>96</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>103</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>104</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>111</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>112</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>119</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>120</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>127</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<note>
|
|
|
<para>In the Power ISA, the figures are generally only shown in
|
|
|
big-endian byte order. The bits in this data format specification are
|
|
|
numbered from left to right (MSB to LSB).</para>
|
|
|
</note>
|
|
|
<note>
|
|
|
<para>
|
|
|
<emphasis role="bold">FPSCR Formats:</emphasis> As of Power ISA version 2.05, the
|
|
|
FPSCR is extended from 32 bits to 64 bits. The fields of the original
|
|
|
32-bit FPSCR are now held in bits 32–63 of the 64-bit FPSCR. The
|
|
|
assembly instructions that operate upon the 64-bit FPSCR have either
|
|
|
a W instruction field added to select the operative word for the
|
|
|
instruction (for example,
|
|
|
<emphasis role="bold">mtfsfi</emphasis>) or the instruction is extended to
|
|
|
operate upon the entire 64-bit FPSCR, (for example,
|
|
|
<emphasis role="bold">mffs</emphasis>). Fields of the FPSCR that represent 1 or
|
|
|
more bits are referred to by field number with an indication of the
|
|
|
operative word rather than by bit number.</para>
|
|
|
</note>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_73207">
|
|
|
<title>Fundamental Types</title>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_49259" /> describes the ISO C scalar
|
|
|
types, and
|
|
|
<xref linkend="dbdoclet.50655240_89351" /> describes the vector types of
|
|
|
the POWER SIMD vector programming API. Each type has a required
|
|
|
alignment, which is indicated in the Alignment column. Use of these
|
|
|
types in data structures must follow the alignment specified, in the
|
|
|
order encountered, to ensure consistent mapping. When using variables
|
|
|
individually, more strict alignment may be imposed if it has
|
|
|
optimization benefits.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_49259">
|
|
|
<?dbfo keep-together="always" ?>
|
|
|
<title>Scalar Types</title>
|
|
|
<tgroup cols="5">
|
|
|
<colspec colname="c1" colwidth="15*" />
|
|
|
<colspec colname="c2" colwidth="20*" />
|
|
|
<colspec colname="c3" colwidth="10*" align="center" />
|
|
|
<colspec colname="c4" colwidth="15*" />
|
|
|
<colspec colname="c5" colwidth="40*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Type</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">ISO C Types</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">sizeof</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Alignment</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Description</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Boolean</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>_Bool</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Byte</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Boolean</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry morerows="2">
|
|
|
<para>Character</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>char</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Byte</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Unsigned byte</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned char</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed char</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Byte</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Signed byte</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry morerows="1">
|
|
|
<para>Enumeration</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>signed enum</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Word</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Signed word</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned enum</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Word</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Unsigned word</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry morerows="14">
|
|
|
<para>Integral</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>int</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Word</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Signed word</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed int</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned int</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Word</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Unsigned word</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>long int</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Doubleword</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Signed doubleword</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed long int</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned long int</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Doubleword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Unsigned doubleword</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>long long int</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Doubleword</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Signed doubleword</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed long long int</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned long long int</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Doubleword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Unsigned doubleword</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>short int</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Halfword</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Signed halfword</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed short int</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned short int</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Halfword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Unsigned halfword</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>__int128</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Signed quadword</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed __int128</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned __int128</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Unsigned quadword</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry morerows="1">
|
|
|
<para>Pointer</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>any *</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>Doubleword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Data pointer</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>any (*) ( )</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Function pointer</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry morerows="2">
|
|
|
<para>Binary Floating-Point</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>float</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Word</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Single-precision float</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>double</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Doubleword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Double-precision float</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>long double</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Extended- or quad-precision float</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<note>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>A NULL pointer has all bits set to zero.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>A Boolean value is represented as a byte with a value of 0
|
|
|
or 1. If a byte with a value other than 0 or 1 is evaluated as a
|
|
|
boolean value (for example, through the use of unions), the
|
|
|
behavior is undefined.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>If an enumerated type contains a negative value, it is
|
|
|
compatible with and has the same representation and alignment as
|
|
|
int. Otherwise, it is compatible with and has the same
|
|
|
representation and alignment as an unsigned int.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>For each real floating-point type, there is a corresponding
|
|
|
imaginary type with the same size and alignment, and there is a
|
|
|
corresponding complex type. The complex type has the same
|
|
|
alignment as the real type and is twice the size; the
|
|
|
representation is the real part followed by the imaginary
|
|
|
part.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
</note>
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_89351">
|
|
|
<title>Vector Types</title>
|
|
|
<tgroup cols="5">
|
|
|
<colspec colname="c1" colwidth="15*" />
|
|
|
<colspec colname="c2" colwidth="20*" />
|
|
|
<colspec colname="c3" colwidth="10*" align="center" />
|
|
|
<colspec colname="c4" colwidth="15*" />
|
|
|
<colspec colname="c5" colwidth="40*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Type</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Power SIMD C Types</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">sizeof</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Alignment</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Description</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>vector-128</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector unsigned char</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 16 unsigned bytes.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector signed char</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 16 signed bytes.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector bool char</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 16 bytes with a value of either 0 or
|
|
|
2<superscript>8</superscript> – 1.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector unsigned short</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 8 unsigned halfwords.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector signed short</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 8 signed halfwords.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector bool short</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 8 halfwords with a value of either 0 or
|
|
|
2<superscript>16</superscript> – 1.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector unsigned int</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 4 unsigned words.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector signed int</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 4 signed words.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector bool int</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 4 words with a value of either 0 or
|
|
|
2<superscript>32</superscript> – 1.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<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>
|
|
|
</footnote></para>
|
|
|
<para>vector unsigned long long</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 2 unsigned doublewords.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector signed long<footnoteref linkend="vlong" /></para>
|
|
|
<para>vector signed long long</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 2 signed doublewords.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector bool long<footnoteref linkend="vlong" /></para>
|
|
|
<para>vector bool long long</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 2 doublewords with a value of either 0 or
|
|
|
2<superscript>64</superscript> – 1.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector unsigned __int128</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 1 unsigned quadword.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector signed __int128</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 1 signed quadword.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<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>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector float</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 4 single-precision floats.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vector double</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Vector of 2 double-precision floats.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<note>
|
|
|
<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">
|
|
|
<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>
|
|
|
</note>
|
|
|
<para> </para>
|
|
|
<bridgehead xml:id="dbdoclet.50655240_43748">Decimal Floating-Point
|
|
|
(ISO TR 24732 Support)</bridgehead>
|
|
|
<para>The decimal floating-point data type is used to specify variables
|
|
|
corresponding to the IEEE 754-2008 densely packed, decimal
|
|
|
floating-point format.</para>
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_52539">
|
|
|
<title>Decimal Floating-Point Types</title>
|
|
|
<tgroup cols="5">
|
|
|
<colspec colname="c1" colwidth="15*" />
|
|
|
<colspec colname="c2" colwidth="20*" />
|
|
|
<colspec colname="c3" colwidth="10*" align="center" />
|
|
|
<colspec colname="c4" colwidth="15*" />
|
|
|
<colspec colname="c5" colwidth="40*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Type</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">ISO TR 24732 C Types</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">sizeof</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Alignment</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Description</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Decimal Floating-Point</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>_Decimal32</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Word</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Single-precision decimal float.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>_Decimal64</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Doubleword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Double-precision decimal float.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>_Decimal128</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quad-precision decimal float.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para> </para>
|
|
|
<bridgehead xml:id="dbdoclet.50655240_33603">IBM EXTENDED
|
|
|
PRECISION</bridgehead>
|
|
|
<table frame="all" pgwide="1">
|
|
|
<title>IBM EXTENDED PRECISION Type</title>
|
|
|
<tgroup cols="5">
|
|
|
<colspec colname="c1" colwidth="15*" />
|
|
|
<colspec colname="c2" colwidth="20*" />
|
|
|
<colspec colname="c3" colwidth="10*" align="center" />
|
|
|
<colspec colname="c4" colwidth="15*" />
|
|
|
<colspec colname="c5" colwidth="40*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Type</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">ISO C Types</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">sizeof</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Alignment</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Description</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>IBM EXTENDED PRECISION</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>long double</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Two double-precision floats.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para> </para>
|
|
|
<bridgehead xml:id="dbdoclet.50655240_66797">IEEE BINARY 128 QUADRUPLE
|
|
|
PRECISION</bridgehead>
|
|
|
<table frame="all" pgwide="1">
|
|
|
<title>IEEE BINARY 128 QUADRUPLE PRECISION Type</title>
|
|
|
<tgroup cols="6">
|
|
|
<colspec colname="c1" colwidth="15*" />
|
|
|
<colspec colname="c2" colwidth="20*" />
|
|
|
<colspec colname="c3" colwidth="10*" align="center" />
|
|
|
<colspec colname="c4" colwidth="15*" />
|
|
|
<colspec colname="c5" colwidth="32*" />
|
|
|
<colspec colname="c6" colwidth="8*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Type</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">ISO C Types</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">sizeof</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Alignment</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Description</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Notes</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>IEEE BINARY 128 QUADRUPLE PRECISION</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>long double</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>IEEE 128-bit quad-precision float.</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_32808"
|
|
|
xrefstyle="select: nopage" />
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>IEEE BINARY 128 QUADRUPLE PRECISION</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>_Float128</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Quadword</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>IEEE 128-bit quad-precision float.</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_32808"
|
|
|
xrefstyle="select: nopage" />,
|
|
|
<xref linkend="dbdoclet.50655240_63070"
|
|
|
xrefstyle="select: nopage" /></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry nameend="c6" namest="c1">
|
|
|
<orderedlist>
|
|
|
<listitem xml:id="dbdoclet.50655240_32808">
|
|
|
<para>Phased in. This type is being phased in and it may
|
|
|
not be available on all implementations.</para>
|
|
|
</listitem>
|
|
|
<listitem xml:id="dbdoclet.50655240_63070">
|
|
|
<para>__float128 shall be recognized as a synonym for the
|
|
|
_Float128 data type, and it is used interchangeably to
|
|
|
refer to the same type. Implementations that do not offer
|
|
|
support for _Float128 may provide this type with the
|
|
|
__float128 type only.</para>
|
|
|
</listitem>
|
|
|
</orderedlist>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para> </para>
|
|
|
<bridgehead>IBM EXTENDED PRECISION && 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>
|
|
|
<para> </para>
|
|
|
<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
|
|
|
long double is the IEEE 128-bit quad-precision binary floating-point
|
|
|
type.</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>IEEE BINARY 128 QUADRUPLE PRECISION</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Long double is implemented as an IEEE 128-bit quad-precision
|
|
|
binary floating-point type in accordance with the applicable IEEE
|
|
|
floating-point standards.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Support is provided for all IEEE standard features.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<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
|
|
|
independent of the floating-point representation chosen for the
|
|
|
long double ISO C type. However, this is not part of the C
|
|
|
standard.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>IBM EXTENDED PRECISION</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Support is provided for the IBM EXTENDED PRECISION format. In
|
|
|
this format, double-precision numbers with different magnitudes
|
|
|
that do not overlap provide an effective precision of 106 bits or
|
|
|
more, depending on the value. The high-order double-precision value
|
|
|
(the one that comes first in storage) must have the larger
|
|
|
magnitude. The high-order double-precision value must equal the sum
|
|
|
of the two values, rounded to nearest double (the Linux convention,
|
|
|
unlike AIX).</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>IBM EXTENDED PRECISION form provides the same range as double
|
|
|
precision (about 10<superscript>–308</superscript> to
|
|
|
10<superscript>308</superscript>) but more precision (a variable amount,
|
|
|
about 31 decimal digits or more).</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>As the absolute value of the magnitude decreases (near the
|
|
|
denormal range), the precision available in the low-order double
|
|
|
also decreases.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>When the value represented is in the subnormal or denormal
|
|
|
range, this representation provides no more precision than 64-bit
|
|
|
(double) floating-point.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The actual number of bits of precision can vary. If the
|
|
|
low-order part is much less than one unit of least precision (ULP)
|
|
|
of the high-order part, significant bits (all 0s or all 1s) are
|
|
|
implied between the significands of high-order and low-order
|
|
|
numbers. Some algorithms that rely on having a fixed number of bits
|
|
|
in the significand can fail when using extended precision.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>This implementation differs from the IEEE 754 Standard in the
|
|
|
following ways:</para>
|
|
|
<itemizedlist>
|
|
|
<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>
|
|
|
<para>The following rules for aggregates (structures and arrays) and
|
|
|
unions apply to their alignment and size:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>The entire aggregate or union must be aligned to its most
|
|
|
strictly aligned member, which corresponds to the member with the
|
|
|
largest alignment, including flexible array members.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Each member is assigned the lowest available offset that
|
|
|
meets the alignment requirements of the member. Depending on the
|
|
|
previous member, internal padding can be required.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<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
|
|
|
<xref linkend="dbdoclet.50655240_46433" /> through
|
|
|
<xref linkend="dbdoclet.50655240_62361" />, the big-endian byte offsets
|
|
|
are located in the upper left corners, and the little-endian byte
|
|
|
offsets are located in the upper right corners.</para>
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50655240_46433">
|
|
|
<title>Structure Smaller than a Word</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-1.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1">
|
|
|
<title>Structure with No Padding</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-2.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1">
|
|
|
<title>Structure with Internal Padding</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-3.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1">
|
|
|
<title>Structure with Internal and Tail Padding</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-4.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50655240_20058">
|
|
|
<title>Structure with Vector Element and Internal Padding</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-5.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1">
|
|
|
<title>Structure with Vector Element and Tail Padding</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-6.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1">
|
|
|
<title>Structure with Internal Padding and Vector Element</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-7.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1">
|
|
|
<title>Structure with Internal Padding and 128-Bit Integer</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-8.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50655240_49841">
|
|
|
<title>Packed Structure</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-9.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50655240_62361">
|
|
|
<title>Union Allocation</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-10.png" format="PNG"
|
|
|
scalefit="1" width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
</section>
|
|
|
<section>
|
|
|
<title>Bit Fields</title>
|
|
|
<para>Bit fields can be present in definitions of C structures and
|
|
|
unions. These bit fields define whole objects within the structure or
|
|
|
union where the number of bits in the bit field is specified.</para>
|
|
|
<para>In
|
|
|
<xref linkend="dbdoclet.50655240_47126" />, a signed range goes from
|
|
|
–2<superscript>w – 1</superscript> to
|
|
|
2<superscript>w – 1</superscript> – 1 and an unsigned range goes from 0 to
|
|
|
2<superscript>w</superscript> – 1.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_47126">
|
|
|
<title>Bit Field Types</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Bit Field Type</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Width (w)</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>_Bool</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed char</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>1–8</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned char</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed short</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>1–16</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned short</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed int</para>
|
|
|
</entry>
|
|
|
<entry morerows="2">
|
|
|
<para>1–32</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned int</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>enum</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed long</para>
|
|
|
</entry>
|
|
|
<entry morerows="3">
|
|
|
<para>1–64</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned long</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed long long</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned long long</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>signed __int128</para>
|
|
|
</entry>
|
|
|
<entry morerows="1">
|
|
|
<para>1–128</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>unsigned __int128</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para>Bit fields can be a signed or unsigned of type short, int, long,
|
|
|
or long long. However, bit fields shall have the same range for each
|
|
|
corresponding type. For example, signed short must have the same range
|
|
|
as unsigned short. All members of structures and unions, including bit
|
|
|
fields, must comply with the size and alignment rules. The following
|
|
|
list of additional size and alignment rules apply to bit fields:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>The allocation of bit fields is determined by the system
|
|
|
endianness. For little-endian implementations, the bit allocation
|
|
|
is from the least-significant (right) end to the most-significant
|
|
|
(left) end. The reverse is true for big-endian implementations; the
|
|
|
bit allocation is from most-significant (left) end to the
|
|
|
least-significant (right) end.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<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
|
|
|
must share the storage unit with other structure members, including
|
|
|
members that are not bit fields. Clearly, all the structure members
|
|
|
occupy different parts of the storage unit.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The types of unnamed bit fields have no effect on the
|
|
|
alignment of a structure or union. However, the offsets of an
|
|
|
individual bit field's member must comply with the alignment rules.
|
|
|
An unnamed bit field of zero width causes sufficient padding
|
|
|
(possibly none) to be inserted for the next member, or the end of
|
|
|
the structure if there are no more nonzero width members, to have
|
|
|
an offset from the start of the structure that is a multiple of the
|
|
|
size of the declared type of the zero-width member.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>In
|
|
|
<xref linkend="dbdoclet.50655240_54268" />, the little-endian byte
|
|
|
offsets are given in the upper right corners, and the bit numbers are
|
|
|
given in the lower corners.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1" colsep="0" rowsep="0"
|
|
|
xml:id="dbdoclet.50655240_54268">
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
<title>Little-Endian Bit Numbering for 0x01020304</title>
|
|
|
<tgroup cols="12">
|
|
|
<colspec colname="c1" colwidth="3*" />
|
|
|
<colspec colname="c2" colwidth="3*" />
|
|
|
<colspec colname="c3" colwidth="3*" />
|
|
|
<colspec colname="c4" colwidth="3*" />
|
|
|
<colspec colname="c5" colwidth="3*" />
|
|
|
<colspec colname="c6" colwidth="3*" />
|
|
|
<colspec colname="c7" colwidth="3*" />
|
|
|
<colspec colname="c8" colwidth="3*" />
|
|
|
<colspec colname="c9" colwidth="3*" />
|
|
|
<colspec colname="c10" colwidth="3*" />
|
|
|
<colspec colname="c11" colwidth="3*" />
|
|
|
<colspec colname="c12" colwidth="3*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>6</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>5</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row rowsep="1">
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>63</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>56</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>55</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>48</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>47</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>40</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>39</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>32</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>3</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>3</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>31</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>24</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>23</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para>In
|
|
|
<xref linkend="dbdoclet.50655240_47219" />, the big-endian byte offsets
|
|
|
are given in the upper left corners, and the bit numbers are given in
|
|
|
the lower corners.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1" colsep="0" rowsep="0"
|
|
|
xml:id="dbdoclet.50655240_47219">
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
<title>Big-Endian Bit Numbering for 0x01020304</title>
|
|
|
<tgroup cols="12">
|
|
|
<colspec colname="c1" colwidth="3*" />
|
|
|
<colspec colname="c2" colwidth="3*" />
|
|
|
<colspec colname="c3" colwidth="3*" />
|
|
|
<colspec colname="c4" colwidth="3*" />
|
|
|
<colspec colname="c5" colwidth="3*" />
|
|
|
<colspec colname="c6" colwidth="3*" />
|
|
|
<colspec colname="c7" colwidth="3*" />
|
|
|
<colspec colname="c8" colwidth="3*" />
|
|
|
<colspec colname="c9" colwidth="3*" />
|
|
|
<colspec colname="c10" colwidth="3*" />
|
|
|
<colspec colname="c11" colwidth="3*" />
|
|
|
<colspec colname="c12" colwidth="3*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>3</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>1</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>2</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row rowsep="1">
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>15</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>23</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>24</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>31</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>5</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>6</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>7</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>3</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>32</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>39</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>40</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>47</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>48</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>55</para>
|
|
|
</entry>
|
|
|
<entry align="left" colsep="0">
|
|
|
<para>56</para>
|
|
|
</entry>
|
|
|
<entry align="center" colsep="0">
|
|
|
<para></para>
|
|
|
</entry>
|
|
|
<entry align="right" colsep="1">
|
|
|
<para>63</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
|
|
|
<para>The byte offsets for structure and union members are shown in
|
|
|
<xref linkend="dbdoclet.50655240_22573" /> through
|
|
|
<xref linkend="dbdoclet.50655240_30073" />.</para>
|
|
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50655240_22573">
|
|
|
<title>Simple Bit Field Allocation</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-11.png" format="PNG"
|
|
|
scalefit="1" width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1">
|
|
|
<title>Bit Field Allocation with Boundary Alignment</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-12.png" format="PNG"
|
|
|
scalefit="1" width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1">
|
|
|
<title>Bit Field Allocation with Storage Unit Sharing</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-13.png" format="PNG"
|
|
|
scalefit="1" width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1">
|
|
|
<title>Bit Field Allocation in a Union</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-14.png" format="PNG"
|
|
|
scalefit="1" width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50655240_30073">
|
|
|
<title>Bit Field Allocation with Unnamed Bit Fields</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-15.png" format="PNG"
|
|
|
scalefit="1" width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<note>
|
|
|
<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.
|
|
|
However, it is possible that the alignment of the named members is
|
|
|
not on optimum boundaries in memory. For instance, in an array of
|
|
|
the structure in
|
|
|
<xref linkend="dbdoclet.50655240_30073" />, the d members will not
|
|
|
all be on 4-byte (integer) boundaries.</para>
|
|
|
</note>
|
|
|
</section>
|
|
|
</section>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_85672">
|
|
|
<title>Function Calling Sequence</title>
|
|
|
<para>The standard sequence for function calls is outlined in this section.
|
|
|
The layout of the stack frame, the parameter passing convention, and the
|
|
|
register usage are also described in this section. Standard library
|
|
|
functions use these conventions, except as documented for the register save
|
|
|
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 https://apps.na.collabserv.com/meetings/join?id=2897-3986
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640591" />.</para>
|
|
|
<note>
|
|
|
<para>While it is recommended that all functions use the standard
|
|
|
calling sequence, the requirements of the standard calling sequence are
|
|
|
only applicable to global functions. Different calling sequences and
|
|
|
conventions can be used by local functions that cannot be reached from
|
|
|
other compilation units, if they comply with the stack back trace
|
|
|
requirements. Some tools may not work with alternate calling sequences
|
|
|
and conventions.</para>
|
|
|
</note>
|
|
|
<section xml:id="dbdoclet.50655241_FnLinkage" revisionflag="added">
|
|
|
<title>Function Call Linkage Protocols</title>
|
|
|
<para>
|
|
|
The compiler (or assembly programmer) and linker cooperate to make
|
|
|
function calls as efficient as possible. Different protocols are
|
|
|
required depending on whether a call is local, whether the caller
|
|
|
and/or callee use a TOC pointer in r2 for code or data accesses
|
|
|
(see <xref linkend="dbdoclet.50655241_66700" />), and whether the
|
|
|
caller and/or callee guarantee to preserve r2. A local
|
|
|
function call is one where the callee is known and visible within
|
|
|
the unit of code being compiled or assembled. A function that
|
|
|
uses a TOC pointer always has a separate local entry point (see
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640597" />),
|
|
|
and preserves r2 when called via its local entry point. See <xref
|
|
|
linkend="dbdoclet.50655241_95185" /> for information about encoding
|
|
|
this information in the symbol table entries of functions.
|
|
|
</para>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655241_ExternalProtocols" /> summarizes the
|
|
|
protocol requirements for external function calls, and
|
|
|
<xref linkend="dbdoclet.50655241_LocalProtocols" /> summarizes the
|
|
|
protocol requirements for local function calls. Each entry in these
|
|
|
tables is further described in the referenced section. A program may
|
|
|
contain any combination of the function call protocols in these
|
|
|
tables.
|
|
|
<note><para>Note that
|
|
|
this ABI does not define protocols where the caller does not use
|
|
|
a TOC pointer, but does preserve r2. It is most efficient when
|
|
|
such functions are always leaf procedures. It is not forbidden for
|
|
|
such a function to call another function, but in this case it is
|
|
|
up to the caller to save and restore r2 around each call.
|
|
|
</para></note>
|
|
|
</para>
|
|
|
<table frame="all" pgwide="1"
|
|
|
xml:id="dbdoclet.50655241_ExternalProtocols">
|
|
|
<title>Protocols for External Function Calls</title>
|
|
|
<tgroup cols="6">
|
|
|
<colspec colname="c1" colwidth="8*" align="center" />
|
|
|
<colspec colname="c2" colwidth="8*" align="center" />
|
|
|
<colspec colname="c3" colwidth="8*" align="center" />
|
|
|
<colspec colname="c4" colwidth="8*" align="center" />
|
|
|
<colspec colname="c5" colwidth="13*" align="center" />
|
|
|
<colspec colname="c6" colwidth="15*" align="center" />
|
|
|
<thead valign="middle">
|
|
|
<row>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
Caller
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
Callee
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
PLT stub
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
nop needed?
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
Relocation
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
Section link
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody valign="middle">
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Uses TOC
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Any
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
r2 save
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Yes
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
R_PPC64_REL24
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655241_Ext2"
|
|
|
xrefstyle="select: nopage" />
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Does not use TOC, does not preserve r2
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Any
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
No r2 save
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
No
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
R_PPC64_REL24_NOTOC
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655241_Ext1"
|
|
|
xrefstyle="select: nopage" />
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<table frame="all" pgwide="1"
|
|
|
xml:id="dbdoclet.50655241_LocalProtocols">
|
|
|
<title>Protocols for Local Function Calls</title>
|
|
|
<tgroup cols="6">
|
|
|
<colspec colname="c1" colwidth="8*" align="center" />
|
|
|
<colspec colname="c2" colwidth="8*" align="center" />
|
|
|
<colspec colname="c3" colwidth="8*" align="center" />
|
|
|
<colspec colname="c4" colwidth="8*" align="center" />
|
|
|
<colspec colname="c5" colwidth="13*" align="center" />
|
|
|
<colspec colname="c6" colwidth="15*" align="center" />
|
|
|
<thead valign="middle">
|
|
|
<row>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
Caller
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
Callee
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
Call method
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
nop needed?
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
Relocation
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center" rowsep="1">
|
|
|
<para>
|
|
|
Section link
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody valign="middle">
|
|
|
<row>
|
|
|
<entry morerows="2">
|
|
|
<para>
|
|
|
Uses TOC
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Uses TOC
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Local
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
No
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
R_PPC64_REL24
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655241_Local20"
|
|
|
xrefstyle="select: nopage" />
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Does not use TOC, preserves r2
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Local
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
No
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
R_PPC64_REL24
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655241_Local20"
|
|
|
xrefstyle="select: nopage" />
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Does not use TOC, does not preserve r2
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
r2 save stub
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Yes
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
R_PPC64_REL24
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655241_Local21"
|
|
|
xrefstyle="select: nopage" />
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry morerows="1">
|
|
|
<para>
|
|
|
Does not use TOC, does not preserve r2
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Uses TOC
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
r12 setup stub
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
No
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
R_PPC64_REL24_NOTOC
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655241_Local12"
|
|
|
xrefstyle="select: nopage" />
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Does not use TOC
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
Local
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
No
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
R_PPC64_REL24_NOTOC
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655241_Local10"
|
|
|
xrefstyle="select: nopage" />
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<section xml:id="dbdoclet.50655241_Ext2">
|
|
|
<title>External Call, Caller Uses TOC</title>
|
|
|
<para>
|
|
|
When a function that uses a TOC pointer makes any call to an
|
|
|
external function, the compiler generates a nop instruction after the
|
|
|
bl instruction for the call. The linker generates a procedure
|
|
|
linkage table (PLT) stub that saves r2 and replaces the nop
|
|
|
instruction with a restore of r2. (The save of r2 may be omitted
|
|
|
from the PLT stub if the R_PPC64_TOCSAVE relocation is used; see
|
|
|
<xref linkend="dbdoclet.50655241_90220" />.) If the callee requires
|
|
|
a TOC, the PLT stub also includes code to place the callee's global
|
|
|
entry point into r12. See <xref linkend="dbdoclet.50655242_82622"
|
|
|
/> for a full description of PLT stubs.
|
|
|
</para>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655241_Ext1">
|
|
|
<title>External Call, Caller Does Not Use TOC, Caller Does Not Preserve
|
|
|
r2</title>
|
|
|
<para>
|
|
|
When a function that does not use a TOC pointer and does not preserve
|
|
|
r2 makes any call to an
|
|
|
external function, the compiler does not generate a nop instruction
|
|
|
after the bl instruction for the call. Instead, the compiler
|
|
|
annotates the bl instruction with an R_PPC64_REL24_NOTOC
|
|
|
relocation. The linker generates a PLT stub that does not include
|
|
|
a save of r2. If the callee requires a TOC, the PLT stub also
|
|
|
includes code to place the callee's global entry point into r12.
|
|
|
</para>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655241_Local20">
|
|
|
<title>Local Call, Caller Uses TOC, Callee Preserves r2</title>
|
|
|
<para>
|
|
|
When a function that uses a TOC pointer makes a local call to a
|
|
|
function that also preserves r2, the compiler generates a direct call
|
|
|
to the function's local entry point, and does not generate a nop
|
|
|
instruction after the call.
|
|
|
</para>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655241_Local21">
|
|
|
<title>Local Call, Caller Uses TOC, Callee Does Not Preserve r2</title>
|
|
|
<para>
|
|
|
When a function that uses a TOC pointer makes a local call to a
|
|
|
function
|
|
|
that does not preserve r2, the compiler generates a nop instruction
|
|
|
after the call. The linker generates a PLT stub that saves r2, but
|
|
|
does not include code to place the callee's global entry point into
|
|
|
r12, and replaces the nop instruction with a restore of r2. (The
|
|
|
save of r2 may be omitted from the PLT stub if the R_PPC64_TOCSAVE
|
|
|
relocation is used; see <xref linkend="dbdoclet.50655241_90220" />.)
|
|
|
</para>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655241_Local12">
|
|
|
<title>Local Call, Caller Does Not Preserve r2, Callee Uses TOC</title>
|
|
|
<para>
|
|
|
When a function that does not use a TOC and does not preserve r2
|
|
|
makes a local call to
|
|
|
a function that requires a TOC pointer, the compiler does not
|
|
|
generate a nop instruction after the bl instruction for the call.
|
|
|
The linker generates a PLT stub that does not include a save of r2,
|
|
|
but does include code to place the callee's global entry point into
|
|
|
r12. The compiler annotates the bl instruction with an
|
|
|
R_PPC64_REL24_NOTOC relocation.
|
|
|
</para>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655241_Local10">
|
|
|
<title>Local Call, Caller Does Not Preserve r2, Callee Does Not Use
|
|
|
TOC</title>
|
|
|
<para>
|
|
|
When a function that does not use a TOC and does not preserve r2
|
|
|
makes a local call to
|
|
|
a function that does not require a TOC pointer, the compiler
|
|
|
generates a direct call to the function's local entry point, and
|
|
|
does not generate a nop instruction after the call. The compiler
|
|
|
annotates the bl instruction with an R_PPC64_REL24_NOTOC relocation.
|
|
|
</para>
|
|
|
</section>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640579">
|
|
|
<title>Registers</title>
|
|
|
<para>Programs and compilers may freely use all registers except those
|
|
|
reserved for system use. The system signal handlers are responsible for
|
|
|
preserving the original values upon return to the original execution
|
|
|
<anchor xml:id="dbdoclet.50655240_page30" xreflabel="" />path. Signals
|
|
|
that can interrupt the original execution path are documented in the
|
|
|
<emphasis>System V Interface Definition (SVID)</emphasis>.</para>
|
|
|
<para>The tables in
|
|
|
<xref linkend="dbdoclet.50655240_68174" /> give an overview of the
|
|
|
registers that are global during program execution. The tables use four
|
|
|
terms to describe register preservation rules:</para>
|
|
|
|
|
|
<informaltable frame="none" colsep="0" rowsep="0">
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="20*" />
|
|
|
<colspec colname="c2" colwidth="80*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Nonvolatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>A caller can expect that the contents of all registers
|
|
|
marked nonvolatile are valid after control returns from a
|
|
|
function call.</para>
|
|
|
<para>A callee shall save the contents of all registers marked
|
|
|
nonvolatile before modification. The callee must restore the
|
|
|
contents of all such registers before returning to its
|
|
|
caller.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>A caller cannot trust that the contents of registers
|
|
|
marked volatile have been preserved across a function
|
|
|
call.</para>
|
|
|
<para>A callee need not save the contents of registers marked
|
|
|
volatile before modification.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Limited-access</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>The contents of registers marked limited-access have
|
|
|
special preservation rules. These registers have mutability
|
|
|
restricted to certain bit fields as defined by the Power ISA.
|
|
|
The individual bits of these bit fields are defined by this ABI
|
|
|
to be limited-access.</para>
|
|
|
<para>Under normal conditions, a caller can expect that these
|
|
|
bits have been preserved across a function call. Under the
|
|
|
special conditions indicated in
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640581" />,
|
|
|
a caller shall expect that these bits will have changed across
|
|
|
function calls even if they have not.</para>
|
|
|
<para>A callee may only permanently modify these bits without
|
|
|
preserving the state upon entrance to the function if the
|
|
|
callee satisfies the special conditions indicated in
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640581" />.
|
|
|
Otherwise, these bits must be preserved before modification and
|
|
|
restored before returning to the caller.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reserved</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>The contents of registers marked reserved are for
|
|
|
exclusive use of system functions, including the ABI. In
|
|
|
limited circumstances, a program or program libraries may set
|
|
|
or query such registers, but only when explicitly allowed in
|
|
|
this document.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</informaltable>
|
|
|
<section xml:id="dbdoclet.50655240_68174">
|
|
|
<title>Register Roles</title>
|
|
|
<para>In the 64-bit OpenPOWER Architecture, there are always 32
|
|
|
general-purpose registers, each 64 bits wide. Throughout this document
|
|
|
the symbol rN is used, where N is a register number, to refer to
|
|
|
general-purpose register N.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_56674">
|
|
|
<title>Register Roles</title>
|
|
|
<tgroup cols="3">
|
|
|
<colspec colname="c1" colwidth="15*" />
|
|
|
<colspec colname="c2" colwidth="20*" />
|
|
|
<colspec colname="c3" colwidth="65*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Register</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Preservation Rules</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry align="center">
|
|
|
<para>
|
|
|
<emphasis role="bold">Purpose</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>r0</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Optional use in function linkage.</para>
|
|
|
<para>Used in function prologues.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>r1</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Nonvolatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Stack frame pointer.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>r2</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Nonvolatile<footnote>
|
|
|
<para>Register r2 is nonvolatile with respect to calls
|
|
|
between <phrase revisionflag="added">most</phrase> functions
|
|
|
in the same compilation unit. It is saved and restored by
|
|
|
code inserted
|
|
|
by the linker resolving a call to an external function. For
|
|
|
more information, see <xref linkend="dbdoclet.50655240_51083"
|
|
|
/> <phrase revisionflag="added"> and <xref
|
|
|
linkend="dbdoclet.50655241_FnLinkage" /></phrase>.</para>
|
|
|
</footnote><phrase revisionflag="added"> 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 preserve r2. See
|
|
|
<xref linkend="dbdoclet.50655241_FnLinkage" />.</para>
|
|
|
</footnote></phrase></para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>TOC pointer.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>r3–r10</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Parameter and return values.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>r11</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Optional use in function linkage.</para>
|
|
|
<para>Used as an environment pointer in languages that
|
|
|
require environment pointers.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>r12</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Optional use in function linkage.</para>
|
|
|
<para>Function entry address at the global entry
|
|
|
point.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>r13</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Reserved</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Thread pointer (see
|
|
|
<xref linkend="dbdoclet.50655241_90241" />).</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<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>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Nonvolatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Local variables.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>LR</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Link register.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>CTR</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Loop count register.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>TAR</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Reserved</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Reserved for system use. This register should not be
|
|
|
read or written by application software.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>XER</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Fixed-point exception register.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>CR0–CR1</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Condition register fields.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>CR2–CR4</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Nonvolatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Condition register fields.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>CR5–CR7</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Condition register fields.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>DSCR</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Limited Access</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Data stream prefetch control.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>VRSAVE</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Reserved</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Reserved for system use. This register should not be
|
|
|
read or written by application software.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para> </para>
|
|
|
<bridgehead xml:id="dbdoclet.50655240_51083">TOC Pointer
|
|
|
Usage</bridgehead>
|
|
|
<para>As described in
|
|
|
<xref linkend="dbdoclet.50655241_73385" />, the TOC pointer, r2, is
|
|
|
commonly initialized by the global function entry point when a function
|
|
|
is called through the global entry point. It may be called from a
|
|
|
module other than the current function's module or from an unknown call
|
|
|
point, such as through a function pointer. (For more information, see
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640597" />.)</para>
|
|
|
<para>In those instances, it is the caller's responsibility to store
|
|
|
the TOC pointer, r2, in the TOC pointer doubleword of the caller's
|
|
|
stack frame. For references external to the compilation unit, this code
|
|
|
is inserted by the static linker if a function is to be resolved by the
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
pointer must have a legal value pointing to the TOC base, which may be
|
|
|
initialized as described in <xref
|
|
|
linkend="dbdoclet.50655242_47739" />.</para>
|
|
|
<para>When global data is accessed, the TOC pointer must be available
|
|
|
for dereference at the point of all uses of values derived from the TOC
|
|
|
pointer in conjunction with the @l operator. This property is used by
|
|
|
the linker to optimize TOC pointer accesses. In addition, all reaching
|
|
|
definitions for a TOC-pointer-derived access must compute the same
|
|
|
definition for code to be ABI compliant. (See the
|
|
|
<xref linkend="dbdoclet.50655241_19147" />.)</para>
|
|
|
<para>In some implementations, non ABI-compliant code may be processed
|
|
|
by providing additional linker options; for example, linker options
|
|
|
disabling linker optimization. However, this behavior in support of
|
|
|
non-ABI compliant code is not guaranteed to be portable and supported
|
|
|
in all systems. For examples of compliant and noncompliant code, see
|
|
|
<xref linkend="dbdoclet.50655241_19147" />.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead xml:id="dbdoclet.50655240_97283">Optional Function
|
|
|
Linkage</bridgehead>
|
|
|
<para>Except as follows, a function cannot depend on the values of
|
|
|
those registers that are optional in the function linkage (r0, r11, and
|
|
|
r12) because they may be altered by interlibrary calls:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>When a function is entered in a way to initialize its
|
|
|
environment pointer, register r11 contains the environment pointer.
|
|
|
It is used to support languages with access to additional
|
|
|
environment context; for example, for languages that support
|
|
|
lexical nesting to access its lexically nested outer
|
|
|
context.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>When a function <phrase revisionflag="added">that requires a
|
|
|
TOC pointer</phrase> 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" />
|
|
|
and <xref linkend="dbdoclet.50655240_13754" />.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para> </para>
|
|
|
<bridgehead>Stack Frame Pointer</bridgehead>
|
|
|
<para>The stack pointer always points to the lowest allocated valid
|
|
|
stack frame. It must maintain quadword alignment and grow toward the
|
|
|
lower addresses. The contents of the word at that address point to the
|
|
|
previously allocated stack frame when the code has been compiled to
|
|
|
maintain back chains. A called function is permitted to decrement it if
|
|
|
required. For more information, see
|
|
|
<xref linkend="dbdoclet.50655240_32686" />.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead>Link Register</bridgehead>
|
|
|
<para>The link register contains the address that a called function
|
|
|
normally returns to. It is volatile across function calls.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead>Condition Register Fields</bridgehead>
|
|
|
<para>In the condition register, the bit fields CR2, CR3, and CR4 are
|
|
|
nonvolatile. The value on entry must be restored on exit. The other bit
|
|
|
fields are volatile.</para>
|
|
|
<para>This ABI requires OpenPOWER-compliant processors to implement
|
|
|
<emphasis role="bold">mfocr</emphasis> instructions in a manner that initializes
|
|
|
undefined bits of the RT result register of
|
|
|
<emphasis role="bold">mfocr</emphasis> instructions to one of the following
|
|
|
values:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>0, in accordance with OpenPOWER-compliant processor
|
|
|
implementation practice</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The architected value of the corresponding CR field in the
|
|
|
<emphasis role="bold">mfocr</emphasis> instruction</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
|
|
|
<note>
|
|
|
<para>
|
|
|
When executing an
|
|
|
<emphasis role="bold">mfocr</emphasis> instruction, the POWER8 processor does not
|
|
|
implement the behavior described in the "Fixed-Point Invalid Forms
|
|
|
and Undefined Conditions" section of
|
|
|
<citetitle>POWER8 Processor User's Manual for the Single-Chip
|
|
|
Module</citetitle>. Instead, it replicates the selected condition
|
|
|
register field within the byte that contains it rather than
|
|
|
initializing to 0 the bits corresponding to the nonselected bits of
|
|
|
the byte that contains it. When generating code to save two condition
|
|
|
register fields that are stored in the same byte, the compiler must
|
|
|
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>
|
|
|
</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
|
|
|
Forms and Undefined Conditions" in
|
|
|
<citetitle>POWER9 Processor User's Manual.</citetitle></para>
|
|
|
<bridgehead>Floating-Point Registers</bridgehead>
|
|
|
<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
|
|
|
<xref linkend="dbdoclet.50655240_56800" />, there are 64 vector-scalar
|
|
|
registers; each is 128 bits wide.</para>
|
|
|
<para>The vector-scalar registers can be addressed with vector-scalar
|
|
|
instructions, for vector and scalar processing of all 64 registers, or
|
|
|
with the "classic" Power floating-point instructions to refer to a
|
|
|
32-register subset of 64 bits per register. They can also be addressed
|
|
|
with VMX instructions to refer to a 32-register subset of 128-bit wide
|
|
|
registers.</para>
|
|
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50655240_97144">
|
|
|
<title>Floating-Point Registers as Part of VSRs</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-16.png" format="PNG"
|
|
|
scalefit="1" width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50655240_56800">
|
|
|
<title>Vector Registers as Part of VSRs</title>
|
|
|
<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.
|
|
|
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 right half of VSX
|
|
|
registers, corresponding to the classic floating-point registers (that
|
|
|
is, vsr0–vsr31), is volatile.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_83567">
|
|
|
<title>Floating-Point Register Roles for Binary Floating-Point
|
|
|
Types</title>
|
|
|
<tgroup cols="3">
|
|
|
<colspec colname="c1" colwidth="15*" />
|
|
|
<colspec colname="c2" colwidth="20*" />
|
|
|
<colspec colname="c3" colwidth="65*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Register</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Preservation Rules</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Purpose</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>f0</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Local variables.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>f1–f13</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Used for parameter passing and return values of binary
|
|
|
float types.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>f14–f31</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Nonvolatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Local variables.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>FPSCR</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Limited-access</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Floating-Point Status and Control Register
|
|
|
limited-access bits. Preservation rules governing the
|
|
|
limited-access bits for the bit fields [VE], [OE], [UE],
|
|
|
[ZE], [XE], and [RN] are presented in
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640581" />.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para> </para>
|
|
|
<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 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.</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
|
|
|
lower half of a floating-point register. Quad-precision floating-point
|
|
|
values shall occupy an even/odd register pair. When passing
|
|
|
quad-precision decimal floating-point parameters in accordance with
|
|
|
this ABI, an odd floating-point register may be skipped in allocation
|
|
|
order to align quad-precision parameters and results in an even/odd
|
|
|
register pair. When a floating-point register is skipped during input
|
|
|
parameter allocation, words in the corresponding GPR or memory
|
|
|
doubleword in the parameter list are not skipped.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1">
|
|
|
<title>Floating-Point Register Roles for Decimal Floating-Point
|
|
|
Types</title>
|
|
|
<tgroup cols="3">
|
|
|
<colspec colname="c1" colwidth="15*" />
|
|
|
<colspec colname="c2" colwidth="20*" />
|
|
|
<colspec colname="c3" colwidth="65*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Register</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Preservation Rules</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Purpose</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>FPSCR</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Limited-access</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Floating-Point Status and Control Register
|
|
|
limited-access bits. Preservation rules governing the
|
|
|
limited-access bits for the bit field [DRN] are presented in
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640581" />.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</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.
|
|
|
Throughout this document, the symbol vN is used, where N is a register
|
|
|
number, to refer to vector register N.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1">
|
|
|
<title>Vector Register Roles</title>
|
|
|
<tgroup cols="3">
|
|
|
<colspec colname="c1" colwidth="15*" />
|
|
|
<colspec colname="c2" colwidth="20*" />
|
|
|
<colspec colname="c3" colwidth="65*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Register</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Preservation Rules</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Purpose</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>v0–v1</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Local variables.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>v2–v13</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Used for parameter passing and return values.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>v14–v19</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Volatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Local variables.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>v20–v31</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Nonvolatile</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Local variables.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>VSCR</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Limited-access</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>32-bit Vector Status and Control Register. Preservation
|
|
|
rules governing the limited-access bits for the bit field
|
|
|
[NJ] are presented in
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640581" />.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para> </para>
|
|
|
<bridgehead xml:id="dbdoclet.50655240_89740">IEEE BINARY 128 QUADRUPLE
|
|
|
PRECISION</bridgehead>
|
|
|
<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> </para>
|
|
|
<bridgehead xml:id="dbdoclet.50655240_40559">IBM EXTENDED
|
|
|
PRECISION</bridgehead>
|
|
|
<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>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640581">
|
|
|
<title>Limited-Access Bits</title>
|
|
|
<para>The Power ISA identifies a number of registers that have
|
|
|
mutability limited to the specific bit fields indicated in the
|
|
|
following list:</para>
|
|
|
|
|
|
<informaltable frame="none" colsep="0" rowsep="0">
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="20*" />
|
|
|
<colspec colname="c2" colwidth="80*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>FPSCR [VE]</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>The Floating-Point Invalid Operation Exception Enable
|
|
|
bit [VE] of the FPSCR register.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>FPSCR [OE]</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>The Floating-Point Overflow Exception Enable bit [OE]
|
|
|
of the FPSCR register.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>FPSCR [UE]</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>The Floating-Point Underflow Exception Enable bit [UE]
|
|
|
of the FPSCR register.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>FPSCR [ZE]</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>The Floating-Point Zero Divide Exception Enable bit
|
|
|
[ZE] of the FPSCR register.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>FPSCR [XE]</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>The Floating-Point Inexact Exception Enable bit [XE] of
|
|
|
the FPSCR register.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>FPSCR [RN]</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>The Binary Floating-Point Rounding Control field [RN]
|
|
|
of the FPSCR register.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>FPSCR [DRN]</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>The DFP Rounding Control field [DRN] of the 64-bit
|
|
|
FPSCR register.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>VSCR [NJ]</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>The Vector Non-Java Mode field [NJ] of the VSCR
|
|
|
register.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</informaltable>
|
|
|
<para>The bits composing these bit fields are identified as limited
|
|
|
access because this ABI manages how they are to be modified and
|
|
|
preserved across function calls. Limited-access bits may be changed
|
|
|
across function calls only if the called function has specific
|
|
|
permission to do so as indicated by the following conditions. A
|
|
|
function without permission to change the limited-access bits across a
|
|
|
function call shall save the value of the register before modifying the
|
|
|
bits and restore it before returning to its calling function.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead>Limited-Access Conditions</bridgehead>
|
|
|
<para>Standard library functions expressly defined to change the state
|
|
|
of limited-access bits are not constrained by nonvolatile preservation
|
|
|
rules; for example, the fesetround( ) and feenableexcept( ) functions.
|
|
|
All other standard library functions shall save the old value of these
|
|
|
bits on entry, change the bits for their purpose, and restore the bits
|
|
|
before returning.</para>
|
|
|
<para>Where a standard library function, such as qsort( ), calls
|
|
|
functions provided by an application, the following rules shall be
|
|
|
observed:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>The limited-access bits, on entry to the first call to such a
|
|
|
callback, must have the values they had on entry to the library
|
|
|
function.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The limited-access bits, on entry to a subsequent call to
|
|
|
such a callback, must have the values they had on exit from the
|
|
|
previous call to such a callback.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The limited-access bits, on exit from the library function,
|
|
|
must have the values they had on exit from the last call to such a
|
|
|
callback.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>The compiler can directly generate code that saves and restores
|
|
|
the limited-access bits.</para>
|
|
|
<para>The values of the limited-access bits are unspecified on entry
|
|
|
into a signal handler because a library or user function can
|
|
|
temporarily modify the limited-access bits when the signal is taken.
|
|
|
<anchor xml:id="dbdoclet.50655240_page39" xreflabel="" /></para>
|
|
|
<para>When setjmp( ) returns from its first call (also known as direct
|
|
|
invocation), it does not change the limited access bits. The limited
|
|
|
access bits have the values they had on entry to the setjmp( )
|
|
|
function.</para>
|
|
|
<para>When longjmp( ) is performed, it appears to be returning from a
|
|
|
call to setjmp( ). In this instance, the limited access bits are not
|
|
|
restored to the values they had on entry to the setjmp( )
|
|
|
function.</para>
|
|
|
<para>C library functions, such as _FPU_SETCW( ) defined in
|
|
|
<fpu_control.h>, may modify the limited-access bits of the FPSCR.
|
|
|
Additional C99 functions that can modify the FPSCR are defined in
|
|
|
<fenv.h>.</para>
|
|
|
<para>The vector vec_mtvscr( ) function may change the limited-access NJ
|
|
|
bit.</para>
|
|
|
<para>The unwinder does not modify limited-access bits. To avoid the
|
|
|
overhead of saving and restoring the FPSCR on every call, it is only
|
|
|
necessary to save it briefly before the call and to restore it after
|
|
|
any instructions or groups of instructions that need to change its
|
|
|
control flags have been completed. In some cases, that can be avoided
|
|
|
by using instructions that override the FPSCR rounding mode.</para>
|
|
|
<para>If an exception and the resulting signal occur while the FPSCR is
|
|
|
temporarily modified, the signal handler cannot rely on the default
|
|
|
control flag settings and must behave as follows:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>If the signal handler will unwind the stack, print a
|
|
|
traceback, and abort the program, no other special handling is
|
|
|
needed.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>If the signal handler will adjust some register values (for
|
|
|
example, replace a NaN with a zero or infinity) and then resume
|
|
|
execution, no other special handling is needed. There is one
|
|
|
exception; if the signal handler changed the control flags, it
|
|
|
should restore them.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>If the signal handler will unwind the stack part way and
|
|
|
resume execution in a user exception handler, the application
|
|
|
should save the FPSCR beforehand and the exception handler should
|
|
|
restore its control flags.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
</section>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640582">
|
|
|
<title>The Stack Frame</title>
|
|
|
<para>A function shall establish a stack frame if it requires the use of
|
|
|
nonvolatile registers, its local variable usage cannot be optimized into
|
|
|
registers and the protected zone, or it calls another function. For more
|
|
|
information about the protected zone, see
|
|
|
<xref linkend="dbdoclet.50655240_27825" />. It need only allocate space
|
|
|
for the required minimal stack frame, consisting of a back-chain
|
|
|
doubleword (optionally containing a back-chain pointer), the saved CR
|
|
|
word, a reserved word, the saved LR doubleword, and the saved TOC pointer
|
|
|
doubleword.</para>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_97610" /> shows the relative layout of an
|
|
|
allocated stack frame following a nonleaf function call, where the stack
|
|
|
pointer points to the back-chain word of the caller's stack frame. By
|
|
|
default, the stack pointer always points to the back-chain word of the
|
|
|
most recently allocated stack frame. For more information, see
|
|
|
<xref linkend="dbdoclet.50655240_84103" />.</para>
|
|
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50655240_97610">
|
|
|
<title>Stack Frame Organization</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-18.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
<para>In
|
|
|
<xref linkend="dbdoclet.50655240_97610"/> 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>
|
|
|
<section xml:id="dbdoclet.50655240_82182">
|
|
|
<title>General Stack Frame Requirements</title>
|
|
|
<para>The following general requirements apply to all stack
|
|
|
frames:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>The stack shall be quadword aligned.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The minimum stack frame size shall be 32 bytes. A minimum
|
|
|
stack frame consists of the first 4 doublewords (back-chain
|
|
|
doubleword, CR save word and reserved word, LR save doubleword, and
|
|
|
TOC pointer doubleword), with padding to meet the 16-byte alignment
|
|
|
requirement.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>There is no maximum stack frame size defined.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Padding shall be added to the Local Variable Space of the
|
|
|
stack frame to maintain the defined stack frame alignment.</para>
|
|
|
</listitem>
|
|
|
<listitem xml:id="dbdoclet.50655240_page41">
|
|
|
<para>The stack pointer, r1, shall always point to the lowest
|
|
|
address doubleword of the most recently allocated stack
|
|
|
frame.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The stack shall start at high addresses and grow downward
|
|
|
toward lower addresses.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The lowest address doubleword (the back-chain word in
|
|
|
<xref linkend="dbdoclet.50655240_97610" />) shall point to the
|
|
|
previously allocated stack frame when a back chain is present. As
|
|
|
an exception, the first stack frame shall have a value of 0
|
|
|
(NULL).</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>If required, the stack pointer shall be decremented in the
|
|
|
called function's prologue and restored in the called function's
|
|
|
epilogue.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>
|
|
|
See <xref linkend="dbdoclet.50655240___RefHeading___Toc377640599" />.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Before a function calls any other functions, it shall save
|
|
|
the value of the LR register into the LR save doubleword of the
|
|
|
caller's stack frame.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<note>
|
|
|
<para>An optional frame pointer may be created if necessary (for
|
|
|
example, as a result of dynamic allocation on the stack as described
|
|
|
in
|
|
|
<xref linkend="dbdoclet.50655240_32686" /> to address arguments or local
|
|
|
variables.</para>
|
|
|
</note>
|
|
|
<para>An example of a minimum stack frame allocation that meets these
|
|
|
requirements is shown in
|
|
|
<xref linkend="dbdoclet.50655240_76854" />.</para>
|
|
|
|
|
|
<figure xml:id="dbdoclet.50655240_76854">
|
|
|
<title>Minimum Stack Frame Allocation with and without Back
|
|
|
Chain</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-19.png" format="PNG"
|
|
|
scalefit="1" width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_84103">
|
|
|
<title>Minimum Stack Frame Elements</title>
|
|
|
<para />
|
|
|
<bridgehead>Back Chain Doubleword</bridgehead>
|
|
|
<para>When a back chain is not present, alternate information
|
|
|
compatible with the ABI unwind framework to unwind a stack must be
|
|
|
provided by the compiler, for all languages, regardless of language
|
|
|
features. A compiler that does not provide such system-compatible
|
|
|
unwind information must generate a back chain. All compilers shall
|
|
|
generate back chain information by default, and default libraries shall
|
|
|
contain a back chain.</para>
|
|
|
<para>On systems where system-wide unwind capabilities are not
|
|
|
provided, compilers must not generate object files without back-chain
|
|
|
generation. A system shall provided a programmatic interface to query
|
|
|
unwind information when system-wide unwind capabilities are
|
|
|
provided.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead>CR Save Word</bridgehead>
|
|
|
<para>If a function changes the value in any nonvolatile field of the
|
|
|
condition register, it shall first save at least the value of those
|
|
|
nonvolatile fields of the condition register, to restore before
|
|
|
function exit. The caller frame CR Save Word may be used as the save
|
|
|
location. This location in the current frame may be used as temporary
|
|
|
storage, which is volatile over function calls.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead>Reserved Word</bridgehead>
|
|
|
<para>This word is reserved for system functions. Modifications of the
|
|
|
value contained in this word are prohibited unless explicitly allowed
|
|
|
by future ABI amendments.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead>LR Save Doubleword</bridgehead>
|
|
|
<para>If a function changes the value of the link register, it must
|
|
|
first save the old value to restore before function exit. The caller
|
|
|
frame LR Save Doubleword may be used as the save location. This
|
|
|
location in the current frame may be used as temporary storage, which
|
|
|
is volatile over a function call.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead>TOC Pointer Doubleword</bridgehead>
|
|
|
<para>If a function changes the value of the TOC pointer register,
|
|
|
it shall first save it in the TOC pointer doubleword.</para>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_15141">
|
|
|
<title>Optional Save Areas</title>
|
|
|
<para>This ABI provides a stack frame with a number of optional save
|
|
|
areas. These areas are always present, but may be of size 0. This
|
|
|
section indicates the relative position of these save areas in relation
|
|
|
to each other and the primary elements of the stack frame.</para>
|
|
|
<para>Because the back-chain word of a stack frame must maintain
|
|
|
quadword alignment, a reserved word is introduced above the CR save
|
|
|
word to provide a quadword-aligned minimal stack frame and align the
|
|
|
doublewords within the fixed stack frame portion at doubleword
|
|
|
boundaries.</para>
|
|
|
<para>An optional alignment padding to a quadword-boundary element
|
|
|
might be necessary above the Vector Register Save Area to provide
|
|
|
16-byte alignment, as shown in
|
|
|
<xref linkend="dbdoclet.50655240_97610" />.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead>Floating-Point Register Save Area</bridgehead>
|
|
|
<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
|
|
|
floating-point registers are to be saved, the Floating-Point Register
|
|
|
Save Area has a zero size.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead xml:id="dbdoclet.50655240_page42">General-Purpose Register
|
|
|
Save Area</bridgehead>
|
|
|
<para>If a function changes the value in any nonvolatile
|
|
|
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 DWARF is present, registers can be
|
|
|
saved in arbitrary locations in the stack frame. If the system
|
|
|
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 – N) bytes before the back-chain word of the previous frame, as shown
|
|
|
in
|
|
|
<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
|
|
|
general-purpose registers are to be saved, the General-Purpose Register
|
|
|
Save Area has a zero size.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead>Vector Register Save Area</bridgehead>
|
|
|
<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 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>
|
|
|
<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
|
|
|
General-Purpose Register Save Areas, and/or the Local Variable Space
|
|
|
may be expanded to the next quadword boundary. The size of the Vector
|
|
|
Register Save Area depends upon the number of vector registers that
|
|
|
must be saved. It ranges from 0 bytes to a maximum of 192 bytes (12 X
|
|
|
16). If no vector registers are to be saved, the Vector Register Save
|
|
|
Area has a zero size.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead>Local Variable Space</bridgehead>
|
|
|
<para>The Local Variable Space is used for allocation of local
|
|
|
variables. The Local Variable Space is located immediately above the
|
|
|
Parameter Save Area, at a higher address. There is no restriction on
|
|
|
the size of this area.</para>
|
|
|
<note>
|
|
|
<para>Sometimes a register spill area is needed. It is typically
|
|
|
positioned above the Local Variable Space.</para>
|
|
|
</note>
|
|
|
<para>The Local Variable Space also contains any parameters that need
|
|
|
to be assigned a memory address when the function's parameter list does
|
|
|
not require a save area to be allocated by the caller.</para>
|
|
|
<para> </para>
|
|
|
<bridgehead xml:id="dbdoclet.50655240_78421">Parameter Save
|
|
|
Area</bridgehead>
|
|
|
<para>The Parameter Save Area shall be allocated by the caller for
|
|
|
function calls unless a prototype is provided for the callee indicating
|
|
|
that all parameters can be passed in registers. (This requires a
|
|
|
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 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
|
|
|
to pass more than 8 doublewords of arguments, the Parameter Save Area
|
|
|
shall be large enough to spill all register-based parameters and to
|
|
|
contain the arguments that the caller stores in it.</para>
|
|
|
<para>The calling function cannot expect that the contents of this save
|
|
|
area are valid when returning from the callee.</para>
|
|
|
<para>The Parameter Save Area, which is located at a fixed offset of 32
|
|
|
bytes from the stack pointer, is reserved in each stack frame for use
|
|
|
as an argument list when an in-memory argument list is required. For
|
|
|
example, a Parameter Save Area must be allocated by the caller when
|
|
|
calling functions with the following characteristics:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Prototyped functions where the parameters cannot be contained
|
|
|
in the parameter registers</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Prototyped functions with variadic arguments</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<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>,
|
|
|
<citetitle>The C Programming Language</citetitle>, 1st
|
|
|
edition).</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>Under these circumstances, a minimum of 8 doublewords are always
|
|
|
reserved. The size of this area must be sufficient to hold the longest
|
|
|
argument list being passed by the function that owns the stack frame.
|
|
|
Although not all arguments for a particular call are located in
|
|
|
storage, when an in-memory parameter list is required, consider the
|
|
|
parameters to be forming a list in this area. Each argument occupies
|
|
|
one or more doublewords.</para>
|
|
|
<para>More arguments might be passed than can be stored in the
|
|
|
parameter registers. In that case, the remaining arguments are stored
|
|
|
in the Parameter Save Area. The values passed on the stack are
|
|
|
identical to the values placed in registers. Therefore, the stack
|
|
|
contains register images for the values that are not placed into
|
|
|
registers.</para>
|
|
|
<para>This ABI uses a simple va_list type for variable lists to point
|
|
|
to the memory location of the next parameter. Therefore, regardless of
|
|
|
type, variable arguments must always be in the same location so that
|
|
|
they can be found at runtime. The first 8 doublewords are located in
|
|
|
general registers r3–r10. Any additional doublewords are located in
|
|
|
the stack Parameter Save Area. Alignment requirements such as those for
|
|
|
vector types may require the va_list pointer to first be aligned before
|
|
|
accessing a value.</para>
|
|
|
<para>Follow these rules for parameter passing:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Map each argument to enough doublewords in the Parameter Save
|
|
|
Area to hold its value.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Map single-precision floating-point values to the
|
|
|
least-significant word in a single doubleword.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Map double-precision floating-point values to a single
|
|
|
doubleword.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Map simple integer types (char, short, int, long, enum) to a
|
|
|
single doubleword. Sign or zero extend values shorter than a
|
|
|
doubleword to a doubleword based on whether the source data type is
|
|
|
signed or unsigned.</para>
|
|
|
</listitem>
|
|
|
<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">
|
|
|
<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
|
|
|
of the quadword (__int128) is stored in the higher numbered GPR
|
|
|
or parameter word. In little-endian environments, the
|
|
|
least-significant doubleword of the quadword (__int128) parameter
|
|
|
is stored in the lower numbered GPR or parameter word. The
|
|
|
most-significant doubleword of the quadword (__int128) is stored
|
|
|
in the higher numbered GPR or parameter word.</para>
|
|
|
</footnote> The required alignment of int128 data types is 16 bytes.
|
|
|
Therefore, by-value parameters must be copied to a new location in
|
|
|
the local variable area of the callee's stack frame before the
|
|
|
address of the type can be provided (for example, using the
|
|
|
address-of operator, or when the variable is to be passed by
|
|
|
reference), when the incoming parameter is not aligned at a 16-byte
|
|
|
boundary.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>If extended precision floating-point values in IEEE BINARY
|
|
|
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>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>If extended precision floating-point values in IBM EXTENDED
|
|
|
PRECISION format are supported (see
|
|
|
<xref linkend="dbdoclet.50655240_33603" />), map them to two
|
|
|
consecutive doublewords. The required alignment of IBM EXTENDED
|
|
|
PRECISION data types is 16 bytes. Therefore, by-value parameters
|
|
|
must be copied to a new location in the local variable area of the
|
|
|
callee's stack frame before the address of the type can be provided
|
|
|
(for example, using the address-of operator, or when the variable
|
|
|
is to be passed by reference), when the incoming parameter is not
|
|
|
aligned at a 16-byte boundary.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Map complex floating-point and complex integer types as if
|
|
|
the argument was specified as separate real and imaginary
|
|
|
parts.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Map pointers to a single doubleword.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Map vectors to a single quadword, quadword aligned. This
|
|
|
might result in skipped doublewords in the Parameter Save
|
|
|
Area.</para>
|
|
|
</listitem>
|
|
|
<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:
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Aggregates that contain qualified floating-point or vector
|
|
|
arguments are normally aligned at the alignment of their base type.
|
|
|
For more information about qualified arguments, see
|
|
|
<xref linkend="dbdoclet.50655240_60588" />.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Other aggregates are normally aligned in accordance with the
|
|
|
aggregate's defined alignment.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The alignment will never be larger than the stack
|
|
|
frame alignment (16 bytes).</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 other portions mapping to the same doubleword.
|
|
|
(That is, a doubleword 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>
|
|
|
</listitem>
|
|
|
</itemizedlist></para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Pad an aggregate or union smaller than one doubleword in
|
|
|
size, but having a non-zero size,
|
|
|
so that it is in the
|
|
|
least-significant bits of the doubleword.
|
|
|
Pad all others, if
|
|
|
necessary, at their tail. Variable size aggregates or unions are
|
|
|
passed by reference.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Map other scalar values to the number of doublewords required
|
|
|
by their size.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Future data types that have an architecturally defined
|
|
|
quadword-required alignment will be aligned at a quadword
|
|
|
boundary.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>If the callee has a known prototype, arguments are converted
|
|
|
to the type of the corresponding parameter when loaded to their
|
|
|
parameter registers or when being mapped into the Parameter Save
|
|
|
Area. For example, if a long is used as an argument to a float
|
|
|
double parameter, the value is converted to double-precision and
|
|
|
mapped to a doubleword in the Parameter Save Area.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_27825">
|
|
|
<title>Protected Zone</title>
|
|
|
<para>The 288 bytes below the stack pointer are available as volatile
|
|
|
program storage that is not preserved across function calls. Interrupt
|
|
|
handlers and any other functions that might run without an explicit
|
|
|
call must take care to preserve a protected zone, also referred to as
|
|
|
the red zone, of 512 bytes that consists of:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>The 288-byte volatile program storage region that is used to
|
|
|
hold saved registers and local variables</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>An additional 224 bytes below the volatile program storage
|
|
|
region that is set aside as a volatile system storage region for
|
|
|
system functions</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>If a function does not call other functions and does not need
|
|
|
more stack space than is available in the volatile program storage
|
|
|
region (that is, 288 bytes), it does not need to have a stack frame.
|
|
|
The 224-byte volatile system storage region is not available to
|
|
|
compilers for allocation to saved registers and local variables.</para>
|
|
|
</section>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_60588">
|
|
|
<title>Parameter Passing in Registers</title>
|
|
|
<para>For the OpenPOWER Architecture, it is more efficient to pass
|
|
|
arguments to functions in registers rather than through memory. For more
|
|
|
information about passing parameters through memory, see
|
|
|
<xref linkend="dbdoclet.50655240_78421" />. For the OpenPOWER ABI, the
|
|
|
following parameters can be passed in registers:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Up to eight arguments can be passed in general-purpose
|
|
|
registers r3–r10.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Up to thirteen qualified floating-point arguments can be passed
|
|
|
in floating-point registers f1–f13 or up to twelve in vector
|
|
|
registers v2–v13.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Up to thirteen single-precision or double-precision decimal
|
|
|
floating-point arguments can be passed in floating-point registers
|
|
|
f1–f13.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Up to six quad-precision decimal floating-point arguments can
|
|
|
be passed in even-odd floating-point register pairs f2–f13.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Up to 12 qualified vector arguments can be passed in v2–v13.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>A qualified floating-point argument corresponds to:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>A scalar floating-point data type</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Each member of a complex floating-point type</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>A member of a homogeneous aggregate of multiple like data types
|
|
|
passed in up to eight floating-point registers</para>
|
|
|
<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
|
|
|
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 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
|
|
|
sizes, provided that all union members are homogeneous with respect to
|
|
|
each other.) They are passed in floating-point registers if parameters of
|
|
|
that type would be passed in floating-point registers. They are passed in
|
|
|
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>
|
|
|
<para>A vector data type</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>A member of a homogeneous aggregate of multiple like data types
|
|
|
passed in up to eight vector registers</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Any future type requiring 16-byte alignment (see
|
|
|
<xref linkend="dbdoclet.50655240_15141" />) or processed in vector
|
|
|
registers</para>
|
|
|
<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
|
|
|
are like.</para>
|
|
|
<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
|
|
|
vector type. Homogeneous vector aggregates with up to eight members are
|
|
|
passed in up to eight vector registers as if each member was specified as
|
|
|
a separate parameter. (Unions are treated as their largest member. For
|
|
|
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
|
|
|
homogeneous aggregates.</para>
|
|
|
</note>
|
|
|
<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 QUADRUPLE
|
|
|
PRECISION format (see
|
|
|
<xref linkend="dbdoclet.50655240_89740" />) are passed using a VMX
|
|
|
register. Binary extended precision numbers in IBM EXTENDED PRECISION
|
|
|
format (see
|
|
|
<xref linkend="dbdoclet.50655240_33603" />) are passed using two
|
|
|
successive floating-point registers. Single-precision decimal
|
|
|
floating-point numbers (see
|
|
|
<xref linkend="dbdoclet.50655240_12913" />) are passed in the lower half
|
|
|
of a floating-point register. Quad-precision decimal floating-point
|
|
|
numbers (see
|
|
|
<xref linkend="dbdoclet.50655240_12913" />) are passed using a paired
|
|
|
even/odd floating-point register pair. A floating-point register might be
|
|
|
skipped to allocate an even/odd register pair when necessary. When a
|
|
|
floating-point register is skipped, no corresponding memory word is
|
|
|
skipped in the natural home location; that is, the corresponding GPR or
|
|
|
memory doubleword in the parameter list.</para>
|
|
|
<para>All other aggregates are passed in consecutive GPRs, in GPRs and in
|
|
|
memory, or in memory.</para>
|
|
|
<para>When a parameter is passed in a floating-point or vector register,
|
|
|
a number of GPRs are skipped, in allocation order, commensurate to the
|
|
|
size of the corresponding in-memory representation of the passed
|
|
|
argument's type.</para>
|
|
|
<para>The parameter size is always rounded up to the next multiple of a
|
|
|
doubleword.<footnote xml:id="pgfId-1184124" >
|
|
|
<para>Consequently, each parameter of a non-zero size is allocated to
|
|
|
at least one doubleword.</para>
|
|
|
</footnote></para>
|
|
|
<para> </para>
|
|
|
<bridgehead>Full doubleword rule:</bridgehead>
|
|
|
<para>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 other portions mapping to the same doubleword. (That is, a doubleword
|
|
|
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>
|
|
|
<para> </para>
|
|
|
<bridgehead>IEEE BINARY 128 QUADRUPLE PRECISION</bridgehead>
|
|
|
<itemizedlist mark="none">
|
|
|
<listitem>
|
|
|
<para>Up to 12 quad-precision parameters can be passed in v2–v13.
|
|
|
For the purpose of determining qualified floating-point and vector
|
|
|
arguments, an IEEE 128b type shall be considered a "like" vector
|
|
|
type, and a complex _Float128 shall be treated as two individual
|
|
|
scalar elements.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<bridgehead>IBM EXTENDED PRECISION</bridgehead>
|
|
|
<itemizedlist mark="none">
|
|
|
<listitem>
|
|
|
<para>IBM EXTENDED PRECISION format parameters are passed as if they
|
|
|
were a struct consisting of separate double parameters.</para>
|
|
|
<para>IBM EXTENDED PRECISION format parameters shall be considered as
|
|
|
a distinct type for the determination of homogeneous aggregates.
|
|
|
</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>If fewer arguments are needed, the unused registers defined
|
|
|
previously will contain undefined values on entry to the called
|
|
|
function.</para>
|
|
|
<para>If there are more arguments than registers or no function prototype
|
|
|
is provided, a function must provide space for all arguments in its stack
|
|
|
frame. When this happens, only the minimum storage needed to contain all
|
|
|
arguments (including allocating space for parameters passed in registers)
|
|
|
needs to be allocated in the stack frame.</para>
|
|
|
<para>General-purpose registers r3–r10 correspond to the allocation of
|
|
|
parameters to the first 8 doublewords of the Parameter Save Areah.
|
|
|
Specifically, this requires a suitable number of general-purpose
|
|
|
registers to be skipped to correspond to parameters passed in
|
|
|
floating-point and vector registers.</para>
|
|
|
<para>If a parameter corresponds to an unnamed parameter that corresponds
|
|
|
to the ellipsis, a caller shall promote float values to double. If a
|
|
|
parameter corresponds to an unnamed parameter that corresponds to the
|
|
|
ellipsis, the parameter shall be passed in a GPR or in the Parameter Save
|
|
|
Area.</para>
|
|
|
<para>If no function prototype is available, the caller shall promote
|
|
|
float values to double and pass floating-point parameters in both
|
|
|
available floating-point registers and in the Parameter Save Area. If no
|
|
|
function prototype is available, the caller shall pass vector parameters
|
|
|
in both available vector registers and in the Parameter Save Area. (If
|
|
|
the callee expects a float parameter, the result will be
|
|
|
incorrect.)</para>
|
|
|
<para>It is the callee's responsibility to allocate storage for the
|
|
|
stored data in the local variable area. When the callee's parameter list
|
|
|
indicates that the caller must allocate the Parameter Save Area (because
|
|
|
at least one parameter must be passed in memory or an ellipsis is present
|
|
|
in the prototype), the callee may use the preallocated Parameter Save
|
|
|
Area to save incoming parameters.</para>
|
|
|
<section xml:id="dbdoclet.50655240_96577">
|
|
|
<title>Parameter Passing Register Selection Algorithm</title>
|
|
|
<para>The following algorithm describes where arguments are passed for
|
|
|
the C language. In this algorithm, arguments are assumed to be ordered
|
|
|
from left (first argument) to right. The actual order of evaluation for
|
|
|
arguments is unspecified.</para>
|
|
|
<itemizedlist spacing="compact">
|
|
|
<listitem>
|
|
|
<para>gr contains the number of the next available general-purpose
|
|
|
register.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>fr contains the number of the next available floating-point
|
|
|
register.</para>
|
|
|
</listitem>
|
|
|
<listitem xml:id="dbdoclet.50655240_page50">
|
|
|
<para>vr contains the number of the next available vector
|
|
|
register.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<note>
|
|
|
<para>The following types refer to the type of the argument as
|
|
|
declared by the function prototype. The argument values are converted
|
|
|
(if necessary) to the types of the prototype arguments before passing
|
|
|
them to the called function.</para>
|
|
|
</note>
|
|
|
<para>If a prototype is not present, or it is a variable argument
|
|
|
prototype and the argument is after the ellipsis, the type refers to
|
|
|
the type of the data objects being passed to the called
|
|
|
function.</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>INITIALIZE: If the function return type requires a storage
|
|
|
buffer, set gr = 4; else set gr = 3.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<programlisting>Set fr = 1
|
|
|
Set vr = 2</programlisting>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>SCAN: If there are no more arguments, terminate. Otherwise,
|
|
|
allocate as follows based on the class of the function
|
|
|
argument:</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<programlisting>switch(class(argument))
|
|
|
|
|
|
unnamed parameter:
|
|
|
if gr > 10
|
|
|
goto mem_argument
|
|
|
|
|
|
size = size_in_DW(argument)
|
|
|
reg_size = min(size, 11 – gr)
|
|
|
pass (GPR, gr, first_n_DW (argument, reg_size));
|
|
|
|
|
|
if remaining_members
|
|
|
argument = after_n_DW(argument,reg_size))
|
|
|
goto mem_argument
|
|
|
|
|
|
break;
|
|
|
|
|
|
integer: // up to 64b
|
|
|
pointer: // this also includes all pass by reference values
|
|
|
|
|
|
if gr > 10
|
|
|
goto mem_argument
|
|
|
pass (GPR, gr, argument);
|
|
|
gr++
|
|
|
|
|
|
break;
|
|
|
|
|
|
aggregate:
|
|
|
if (homogeneous(argument,float) and regs_needed(members(argument)) <=8)
|
|
|
if (register_type_used (type (argument)) == vr)
|
|
|
goto use_vrs;
|
|
|
n_fregs = n_fregs_for_type(member_type(argument,0))
|
|
|
agg_size = members(argument) * n_fregs
|
|
|
reg_size = min(agg_size, 15 – fr)
|
|
|
pass(FPR,fr,first_n_DW(argument,reg_size)
|
|
|
fr += reg_size;
|
|
|
gr += size_in_DW (first_n_DW(argument,reg_size))
|
|
|
|
|
|
if remaining_members
|
|
|
argument = after_n_DW(argument,reg_size))
|
|
|
goto gpr_struct
|
|
|
|
|
|
break;
|
|
|
|
|
|
if (homogeneous(argument,vector) and members(argument) <= 8)
|
|
|
use_vrs:
|
|
|
agg_size = members(argument)
|
|
|
reg_size = min(agg_size, 14 – vr)
|
|
|
if (gr&1 = 0) // align vector in memory
|
|
|
gr++
|
|
|
pass(VR,vr,first_n_elements(argument,reg_size);
|
|
|
vr += reg_size
|
|
|
gr += size_in_DW (first_n_elements(argument,reg_size)
|
|
|
|
|
|
if remaining_members
|
|
|
argument = after_n_elements(argument,reg_size))
|
|
|
goto gpr_struct
|
|
|
break;
|
|
|
|
|
|
if gr > 10
|
|
|
goto mem_argument
|
|
|
|
|
|
size = size_in_DW(argument)
|
|
|
|
|
|
gpr_struct:
|
|
|
reg_size = min(size, 11 – gr)
|
|
|
pass (GPR, gr, first_n_DW (argument, reg_size));
|
|
|
gr += size_in_DW (first_n_DW (argument, reg_size))
|
|
|
|
|
|
if remaining_members
|
|
|
argument = after_n_DW(argument,reg_size))
|
|
|
goto mem_argument
|
|
|
|
|
|
break;
|
|
|
|
|
|
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 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 QUADRUPLE PRECISION.
|
|
|
goto use_vr;
|
|
|
|
|
|
fr += align_pad(fr,type(argument))
|
|
|
// Assumes align_pad = 8 for _Decimal128 if fr is odd; otherwise = 0.
|
|
|
if fr > 14
|
|
|
goto mem_argument
|
|
|
|
|
|
n_fregs = n_fregs_for_type(argument)
|
|
|
// Assumes n_fregs_for_type == 2 for IBM EXTENDED PRECISION
|
|
|
// or _Decimal128, == 1 for float, double, _Decimal32 or _Decimal64.
|
|
|
pass(FPR,fr,argument)
|
|
|
fr += n_fregs
|
|
|
gr += size_in_DW(argument)
|
|
|
|
|
|
break;
|
|
|
|
|
|
vector:
|
|
|
Use vr:
|
|
|
if vr > 13
|
|
|
goto mem_argument
|
|
|
|
|
|
if (gr&1 = 0) // align vector in memory
|
|
|
gr++
|
|
|
|
|
|
pass(VR,vr,argument)
|
|
|
vr ++
|
|
|
gr += 2
|
|
|
|
|
|
break;
|
|
|
|
|
|
next argument;
|
|
|
|
|
|
mem_argument:
|
|
|
need_save_area = TRUE
|
|
|
pass (stack, gr, argument)
|
|
|
gr += size_in_DW(argument)
|
|
|
|
|
|
next argument;</programlisting>
|
|
|
<para>All complex data types are handled as if two scalar values of the
|
|
|
base type were passed as separate parameters.</para>
|
|
|
<para>If the callee takes the address of any of its parameters, values
|
|
|
passed in registers are stored to memory. It is the callee's
|
|
|
responsibility to allocate storage for the stored data in the local
|
|
|
variable area. When the callee's parameter list indicates that the
|
|
|
caller must allocate the Parameter Save Area (because at least one
|
|
|
parameter must be passed in memory, or an ellipsis is present in the
|
|
|
prototype), the callee may use the preallocated Parameter Save Area to
|
|
|
save incoming parameters. (If an ellipsis is present, using the
|
|
|
preallocated Parameter Save Area ensures that all arguments are
|
|
|
contiguous.) If the compilation unit for the caller contains a function
|
|
|
prototype, but the callee has a mismatching definition, this may result
|
|
|
in the wrong values being stored.</para>
|
|
|
<note>
|
|
|
<para>If the declaration of a function that is used by the caller
|
|
|
does not match the definition for the called function, corruption of
|
|
|
the caller's stack space can occur.</para>
|
|
|
</note>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_45473">
|
|
|
<title>Parameter Passing Examples</title>
|
|
|
<para>This section provides some examples that use the algorithm
|
|
|
described in
|
|
|
<xref linkend="dbdoclet.50655240_96577" />.</para>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_87898" /> shows how parameters are
|
|
|
passed for a function that passes arguments in GPRs, FPRs, and
|
|
|
memory.</para>
|
|
|
<figure xml:id="dbdoclet.50655240_87898">
|
|
|
<title>Passing Arguments in GPRs, FPRs, and Memory</title>
|
|
|
<programlisting>typedef struct {
|
|
|
int a;
|
|
|
double dd;
|
|
|
} sparm;
|
|
|
sparm s, t;
|
|
|
int c, d, e;
|
|
|
long double ld;/* IBM EXTENDED PRECISION format */
|
|
|
double ff, gg, hh;
|
|
|
|
|
|
x = func(c, ff, d, ld, s, gg, t, e, hh);
|
|
|
|
|
|
Parameter Register Offset in parameter save area
|
|
|
c r3 0–7 (not stored in parameter save area)
|
|
|
ff f1 8–15 (not stored)
|
|
|
d r5 16–23 (not stored)
|
|
|
ld f2,f3 24–39 (not stored)
|
|
|
s r8,r9 40–55 (not stored)
|
|
|
gg f4 56–63 (not stored)
|
|
|
t (none) 64–79 (stored in parameter save area)
|
|
|
e (none) 80–87 (stored)
|
|
|
hh f5 88–95 (not stored)</programlisting>
|
|
|
</figure>
|
|
|
<note>
|
|
|
<para>If a prototype is not in scope:</para>
|
|
|
<itemizedlist spacing="compact">
|
|
|
<listitem>
|
|
|
<para>The floating-point argument ff is also passed in r4.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The long double argument ld is also passed in r6 and
|
|
|
r7.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The floating-point argument gg is also passed in
|
|
|
r10.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The floating-point argument hh is also stored into the
|
|
|
Parameter Save Area.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>If a prototype containing an ellipsis describes any of these
|
|
|
floating-point arguments as being part of the variable argument part,
|
|
|
the general registers and Parameter Save Area are used as when no
|
|
|
prototype is in scope. The floating-point registers are not
|
|
|
used.</para>
|
|
|
</note>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_82633" /> shows the definitions that
|
|
|
are used in the remaining examples of parameter passing.</para>
|
|
|
<figure xml:id="dbdoclet.50655240_82633">
|
|
|
<title>Parameter Passing Definitions</title>
|
|
|
<programlisting>typedef struct {
|
|
|
double a
|
|
|
double b;
|
|
|
} dpfp2;
|
|
|
|
|
|
typedef struct
|
|
|
float a
|
|
|
float b;
|
|
|
} spfp2;
|
|
|
|
|
|
double a1,a4;
|
|
|
dpfp2 a2,a3 ;
|
|
|
spfp a6,a7;
|
|
|
double func2 (double a, dpfp2 p1, dpfp p2, double b, int x);
|
|
|
double func3 (double a, dpfp2 p1, dpfp p2, double b, int x, spfp2 p3,spfpp4);
|
|
|
|
|
|
struct three_floats { float a,b,c;}
|
|
|
struct two_floats { float a,b;}</programlisting>
|
|
|
</figure>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_89721" /> shows how parameters are
|
|
|
passed for a function that passes homogenous floating-point aggregates
|
|
|
and integer parameters in registers without allocating a Parameter Save
|
|
|
Area because all the parameters can be contained in the
|
|
|
registers.</para>
|
|
|
<figure xml:id="dbdoclet.50655240_89721">
|
|
|
<title>Passing Homogeneous Floating-Point Aggregates and Integer
|
|
|
Parameters in Registers without a Parameter Save Area</title>
|
|
|
<programlisting>x = func2(a1,a2,a3,a4, 5);
|
|
|
Parameter Register Offset in parameter save area
|
|
|
a1 f1 n/a
|
|
|
a2.a f2 n/a
|
|
|
a2.b f3 n/a
|
|
|
a3.a f4 n/a
|
|
|
a3.b f5 n/a
|
|
|
a4 f6 n/a
|
|
|
5 r9 n/a</programlisting>
|
|
|
</figure>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_76432" /> shows how parameters are
|
|
|
passed for a function that passes homogenous floating-point aggregates
|
|
|
and integer parameters in registers without allocating a Parameter Save
|
|
|
Area because all parameters can be passed in registers.</para>
|
|
|
<figure xml:id="dbdoclet.50655240_76432">
|
|
|
<title>Passing Homogeneous Floating-Point Aggregates and Integer
|
|
|
Parameters in Registers without a Parameter Save Area</title>
|
|
|
<programlisting>x = func3(a1,a2,a3,a4, 5,a6,a7);
|
|
|
Parameter Register Offset in parameter save area
|
|
|
a1 f1 n/a
|
|
|
a2.a f2 n/a
|
|
|
a2.b f3 n/a
|
|
|
a3.a f4 n/a
|
|
|
a3.b f5 n/a
|
|
|
a4 f6 n/a
|
|
|
5 r9 n/a
|
|
|
a6.a f7 n/a
|
|
|
a6.b f8 n/a
|
|
|
a7.a f9 n/a
|
|
|
a7.b f10 n/a</programlisting>
|
|
|
</figure>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_63912" /> shows how parameters are
|
|
|
passed for a function that passes floating-point scalars and
|
|
|
homogeneous floating-point aggregates in registers and memory because
|
|
|
the number of available parameter registers has been exceeded. It
|
|
|
demonstrate the full doubleword rule.</para>
|
|
|
<figure xml:id="dbdoclet.50655240_63912">
|
|
|
<title>Passing Floating-Point Scalars and Homogeneous Floating-Point
|
|
|
Aggregates in Registers and Memory</title>
|
|
|
<programlisting>x = oddity (float d1, float d2, float d3, float d4, float d5,
|
|
|
float d6, float d7, float d8, float d9, float d10,
|
|
|
float d11, float d12, struct three_floats x)
|
|
|
Parameter Register Offset in parameter save area
|
|
|
d1 f1 0 (not stored)
|
|
|
d2 f2 8 (not stored)
|
|
|
d3 f3 16 (not stored)
|
|
|
d4 f4 24 (not stored)
|
|
|
d5 f5 32 (not stored)
|
|
|
d6 f6 40 (not stored)
|
|
|
d7 f7 48 (not stored)
|
|
|
d8 f8 56 (not stored)
|
|
|
d9 f9 64 (not stored)
|
|
|
d10 f10 72 (not stored)
|
|
|
d11 f11 80 (not stored)
|
|
|
d12 f12 88 (not stored)
|
|
|
x.a f13 96 (store because of no partial DW rule)
|
|
|
x.b - 100 (stored)
|
|
|
x.c - 104 (stored)</programlisting>
|
|
|
</figure>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_96711" /> shows how parameters are
|
|
|
passed for a function that passes homogeneous floating-point aggregates
|
|
|
and floating-point scalars in general-purpose registers because the
|
|
|
number of available floating-point registers has been exceeded. In this
|
|
|
figure, a Parameter Save Area is not allocated because all the
|
|
|
parameters can be passed in registers.</para>
|
|
|
<figure xml:id="dbdoclet.50655240_96711">
|
|
|
<title>Passing Floating-Point Scalars and Homogeneous Floating-Point
|
|
|
Aggregates in FPRs and GPRs without a Parameter Save Area</title>
|
|
|
<programlisting>x = oddity2 (struct two_floats s1, struct two_floats s2,
|
|
|
struct two_floats s3, struct two_floats s4,
|
|
|
struct two_floats s5, struct two_floats s6,
|
|
|
struct two_floats s7, struct two_floats s8)
|
|
|
Parameter Register Offset in parameter save area
|
|
|
s1.a f1 n/a
|
|
|
s1.b f2 n/a
|
|
|
s2.a f3 n/a
|
|
|
s2.b f4 n/a
|
|
|
s3.a f5 n/a
|
|
|
s3.b f6 n/a
|
|
|
s4.a f7 n/a
|
|
|
s4.b f8 n/a
|
|
|
s5.a f9 n/a
|
|
|
s5.b f10 n/a
|
|
|
s6.a f11 n/a
|
|
|
s6.b f12 n/a
|
|
|
s7.a f13 n/a
|
|
|
s7.b - n/a
|
|
|
s7 gpr9 n/a
|
|
|
s8 gpr10 n/a</programlisting>
|
|
|
</figure>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_12078" /> shows how parameters are
|
|
|
passed for a function that passes homogeneous floating-point aggregates
|
|
|
in FPRs, GPRs, and memory because the number of available
|
|
|
floating-point and integer parameter registers has been exceeded. In
|
|
|
this figure, a Parameter Save Area is allocated because all the
|
|
|
parameters cannot be passed in the registers. This figure also
|
|
|
demonstrates the full doubleword rule applied to GPR7.</para>
|
|
|
<figure xml:id="dbdoclet.50655240_12078">
|
|
|
<title>Passing Homogeneous Floating-Point Aggregates in FPRs, GPRs,
|
|
|
and Memory with a Parameter Save Area</title>
|
|
|
<programlisting>x = oddity3 (struct two_floats s1, struct two_floats s2, struct two_floats s3,
|
|
|
struct two_floats s4, struct two_floats s5, struct two_floats s6,
|
|
|
struct two_floats s7, struct two_floats s8, struct two_floats s9)
|
|
|
Parameter Register Offset in parameter save area
|
|
|
s1.a f1 0 (not stored)
|
|
|
s1.b f2 4 (not stored)
|
|
|
s2.a f3 8 (not stored)
|
|
|
s2.b f4 12 (not stored)
|
|
|
s3.a f5 16 (not stored)
|
|
|
s3.b f6 20 (not stored)
|
|
|
s4.a f7 24 (not stored)
|
|
|
s4.b f8 28 (not stored)
|
|
|
s5.a f9 32 (not stored)
|
|
|
s5.b f10 36 (not stored)
|
|
|
s6.a f11 40 (not stored)
|
|
|
s6.b f12 44 (not stored)
|
|
|
s7.a f13 48 (not stored, SPFP in FPR)
|
|
|
s7.b - 52 (not stored)
|
|
|
s7 gpr9 48 (not stored, full gpr)
|
|
|
s8 gpr10 56 (not stored, full gpr)
|
|
|
s9 64 (stored)</programlisting>
|
|
|
</figure>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_78388" /> shows how parameters are
|
|
|
passed for a function that passes vector data types in VRs, GPRs, and
|
|
|
FPRs. In this figure, a Parameter Save Area is not allocated.</para>
|
|
|
<figure xml:id="dbdoclet.50655240_78388">
|
|
|
<title>Passing Vector Data Types without Parameter Save Area</title>
|
|
|
<programlisting>x =func4(int s1, vector float s2, float s3, vector int s4,
|
|
|
vector char s5)
|
|
|
Parameter Register Offset in parameter save area
|
|
|
s1 gpr3 n/a
|
|
|
s2 v2 n/a
|
|
|
s3 f1 n/a
|
|
|
s4 v3 n/a
|
|
|
s5 v4 n/a</programlisting>
|
|
|
</figure>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_15894" /> shows how parameters are
|
|
|
passed for a function that passes vector data types in VRs, GPRs, and
|
|
|
FPRs. In this figure, a Parameter Save Area is allocated.</para>
|
|
|
<figure xml:id="dbdoclet.50655240_15894">
|
|
|
<title>Passing Vector Data Types with a Parameter Save Area</title>
|
|
|
<programlisting>x =func5(int s1, vector float s2, float s3, vector int s4,
|
|
|
int s5, char s6)
|
|
|
Parameter Register Offset in parameter save area
|
|
|
s1 gpr3 0 (not stored)
|
|
|
s2 v2 16 (not stored)
|
|
|
s3 f1 32 (not stored)
|
|
|
s4 v3 48 (not stored)
|
|
|
s5 - 64 (stored)
|
|
|
s6 - 72 (stored)</programlisting>
|
|
|
</figure>
|
|
|
<para>When a function takes the address of at least one of its
|
|
|
arguments, it is the callee's responsibility to store function
|
|
|
parameters in memory and provide a suitable memory address for
|
|
|
parameters passed in registers.</para>
|
|
|
<para>For functions where all parameters can be contained in the
|
|
|
parameter registers and without an ellipsis, the caller shall allocate
|
|
|
saved parameters in the local variable save area because the caller may
|
|
|
not have allocated a Parameter Save Area. This can be performed, for
|
|
|
example, in the prologue. For functions where the caller must allocate
|
|
|
a Parameter Save Area because at least one parameter must be passed in
|
|
|
memory, or has an ellipsis in the prototype to indicate the presence of
|
|
|
a variadic function, references to named parameters may be spilled to
|
|
|
the Parameter Save Area.</para>
|
|
|
</section>
|
|
|
</section>
|
|
|
<section>
|
|
|
<title>Variable Argument Lists</title>
|
|
|
<para>C programs that are intended to be portable across different
|
|
|
compilers and architectures must use the header file <stdarg.h> to
|
|
|
deal with variable argument lists. This header file contains a set of
|
|
|
macro definitions that define how to step through an argument list. The
|
|
|
implementation of this header file may vary across different
|
|
|
architectures, but the interface is the same.</para>
|
|
|
<para>C programs that do not use this header file for the variable
|
|
|
argument list and assume that all the arguments are passed on the stack
|
|
|
in increasing order on the stack are not portable, especially on
|
|
|
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
|
|
|
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>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640590">
|
|
|
<title>Return Values</title>
|
|
|
<para>Functions that return a value shall place the result in the same
|
|
|
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">
|
|
|
<para>For a definition of homogeneous aggregates, see
|
|
|
<xref linkend="dbdoclet.50655240_60588" />.</para>
|
|
|
</footnote> (Homogeneous aggregates are arrays, structs, or unions of a
|
|
|
homogeneous floating-point or vector type and of a known fixed size.)
|
|
|
Therefore, IBM EXTENDED PRECISION functions are returned in f1:f2.</para>
|
|
|
<para>Homogeneous floating-point or vector aggregate return values that
|
|
|
consist of up to eight registers with up to eight elements will be
|
|
|
returned in floating-point or vector registers that correspond to the
|
|
|
parameter registers that would be used if the return value type were the
|
|
|
first input parameter to a function.</para>
|
|
|
<para>Aggregates that are not returned by value are returned in a storage
|
|
|
buffer provided by the caller. The address is provided as a hidden first
|
|
|
input argument in general-purpose register r3.</para>
|
|
|
|
|
|
<note>
|
|
|
<para>Quadword decimal floating-point return values shall be returned
|
|
|
in the first paired floating-point register parameter pair; that is,
|
|
|
f2:f3.</para>
|
|
|
</note>
|
|
|
<para>Functions that return values of the following types shall place the
|
|
|
result in register r3 as signed or unsigned integers, as appropriate, and
|
|
|
sign extended or zero extended to 64 bits where necessary:</para>
|
|
|
<itemizedlist spacing="compact">
|
|
|
<listitem>
|
|
|
<para>char</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>enum</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>short</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>int</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>long</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>pointer to any type</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>_Bool</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
</section>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640591">
|
|
|
<title>Coding Examples</title>
|
|
|
<para>The following ISO C coding examples are provided as illustrations of
|
|
|
how operations may be done, not how they shall be done, for calling
|
|
|
functions, accessing static data, and transferring control from one part of
|
|
|
a program to another. They are shown as code fragments with simplifications
|
|
|
to explain addressing modes. They do not necessarily show the optimal code
|
|
|
sequences or compiler output. The small data area is not used in any of
|
|
|
them. For more information, see
|
|
|
<xref linkend="dbdoclet.50655241_81959" />.</para>
|
|
|
<para>The previous sections explicitly specify what a program, operating
|
|
|
system, and processor may and may not assume and are the definitive
|
|
|
reference to be used.</para>
|
|
|
<para>In these examples, absolute code and position-independent code are
|
|
|
referenced.</para>
|
|
|
<para>When instructions hold absolute addresses, a program must be loaded
|
|
|
at a specific virtual address to permit the absolute code model to
|
|
|
work.</para>
|
|
|
<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
|
|
|
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
|
|
|
new "PC-relative" instructions that can be used to obtain such
|
|
|
addresses relative to the current instruction address (CIA). Both
|
|
|
methods may be used in the same executable, dynamically shared
|
|
|
object (DSO), object file, or even in the same function. If a
|
|
|
function does not require a TOC pointer for addressing, it is not required
|
|
|
to establish this pointer in register r2, and may choose not to preserve
|
|
|
register r2's value provided that the function's symbol table entry is
|
|
|
appropriately annotated. Full details of function call linkage
|
|
|
requirements are provided in <xref linkend="dbdoclet.50655241_FnLinkage"
|
|
|
/>.</para>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640592">
|
|
|
<title>Code Model Overview</title>
|
|
|
<para>Executable modules can be built to use either position-dependent or
|
|
|
position-independent memory references. Position-dependent references
|
|
|
generally result in better performing programs.</para>
|
|
|
<para>Static modules representing the base executables and libraries
|
|
|
intended to be statically linked into a base executable can be compiled
|
|
|
and linked using either position-dependent or position-independent
|
|
|
code.</para>
|
|
|
<para>Dynamic shared objects (DSOs) intended to be used as shared
|
|
|
libraries and position-independent executables must be compiled and
|
|
|
linked as position-independent code.</para>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640593">
|
|
|
<title>Position-Dependent Code</title>
|
|
|
<para>Static objects are preferably built by using position-dependent
|
|
|
code. Position-dependent code can reference data in one of the
|
|
|
following ways:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Directly by creating absolute memory addresses using a
|
|
|
combination of instructions such as lis, addi, and memory
|
|
|
instructions:</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<programlisting>lis r16, symbol@ha
|
|
|
ld r12, symbol@l(r16)
|
|
|
|
|
|
lis r16, symbol2@ha
|
|
|
addi r16, r16, symbol2@l
|
|
|
lvx v1, r0, r16</programlisting>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>By instantiating the TOC pointer in r2 and using TOC-pointer
|
|
|
relative addressing. (For more information, see
|
|
|
<xref linkend="dbdoclet.50655241_66700" />.)</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<programlisting><load TOC base to r2>
|
|
|
ld r12, symbol@toc(r2)
|
|
|
|
|
|
li r16, symbol2@toc
|
|
|
lvx v1, r2, r16</programlisting>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>By instantiating the TOC pointer in r2 and using GOT-indirect
|
|
|
addressing:</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<programlisting><load TOC base to r2>
|
|
|
|
|
|
ld r12, symbol@got(r2)
|
|
|
ld r12, 0(r12)
|
|
|
|
|
|
ld r12, symbol2@got(r2)
|
|
|
lvx v1, 0, r12</programlisting>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para revisionflag="added">
|
|
|
By using PC-relative addressing.
|
|
|
</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<programlisting revisionflag="added">pld r12, symbol@pcrel
|
|
|
|
|
|
plxv v1, symbol@pcrel</programlisting>
|
|
|
<para>In the OpenPOWER ELF V2 ABI, position-dependent code built with
|
|
|
this addressing scheme may have a Global Offset Table (GOT) in the data
|
|
|
segment that holds addresses. (For more information, see
|
|
|
<xref linkend="dbdoclet.50655242_47739" />.) For position-dependent
|
|
|
code, GOT entries are typically updated to reflect the absolute virtual
|
|
|
addresses of the reference objects at static link time. Any remaining
|
|
|
GOT entries are updated by the loader to reflect the absolute virtual
|
|
|
addresses that were assigned for the process. These data segments are
|
|
|
private, while the text segments are shared. In systems based on the
|
|
|
Power Architecture, the GOT can be addressed with a single instruction
|
|
|
if the GOT size is less than 65,536 bytes. A larger GOT requires more
|
|
|
general code to access all of its entries.</para>
|
|
|
<para>OpenPOWER-compliant processor hardware implementation and linker
|
|
|
optimizations described here work together to optimize efficient code
|
|
|
generation for applications with large GOTs. They use instruction
|
|
|
fusion to combine multiple ISA instructions into a single internal
|
|
|
operation.</para>
|
|
|
<para>Offsets from the TOC register can be generated using
|
|
|
either:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>16-bit offsets (small code model), with a maximum addressing
|
|
|
reach of 64 KB for TOC-based relative addressing or GOT
|
|
|
accesses</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>32-bit offsets (medium or large code model) with a maximum
|
|
|
addressing reach of 4 GB</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>Efficient implementation of the OpenPOWER ELF V2 ABI medium code
|
|
|
model is supported by additional optimizations present in
|
|
|
OpenPOWER-compliant processor implementations and the OpenPOWER ABI
|
|
|
toolchain (see
|
|
|
<xref linkend="dbdoclet.50655240_19143" />).</para>
|
|
|
<para>Position-dependent code is most efficient if the application is
|
|
|
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">
|
|
|
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
|
|
|
higher virtual addresses than text sections.
|
|
|
</para>
|
|
|
</section>
|
|
|
<section>
|
|
|
<title>Position-Independent Code</title>
|
|
|
<para>A shared object file is mapped with virtual addresses to avoid
|
|
|
conflicts with other segments in the process. Because of this mapping,
|
|
|
shared objects use position-independent code, which means that the
|
|
|
instructions do not contain any absolute addresses. Avoiding the use of
|
|
|
absolute addresses allows shared objects to be loaded into different
|
|
|
virtual address spaces without code modification, which can allow
|
|
|
multiple processes to share the same text segment for a shared object
|
|
|
file.</para>
|
|
|
<para>Two techniques are used to deal with position-independent
|
|
|
code:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>First, branch instructions use an offset to the current
|
|
|
effective address (EA) or use registers to hold addresses. The
|
|
|
Power Architecture provides both EA-relative branch instructions
|
|
|
and branch instructions that use registers. In both cases, absolute
|
|
|
addressing is not required.</para>
|
|
|
</listitem>
|
|
|
<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>
|
|
|
<para>DSOs can access data as follows:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>By instantiating the TOC pointer in r2 and using TOC pointer
|
|
|
relative addressing (for private data).</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<programlisting><load TOC base to r2>
|
|
|
|
|
|
ld r12, symbol@toc(r2)
|
|
|
|
|
|
li r16, symbol2@toc
|
|
|
lvx v1, r2, r16</programlisting>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>By instantiating the TOC pointer in r2 and using GOT-indirect
|
|
|
addressing (for shared data or for very large data
|
|
|
sections):</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<programlisting><load TOC base to r2>
|
|
|
|
|
|
ld r12, symbol@got(r2)
|
|
|
|
|
|
ld r12, 0(r12)
|
|
|
|
|
|
ld r12 symbol2@got(r2)
|
|
|
lvx v1, 0, r12</programlisting>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para revisionflag="added">By using PC-relative addressing (for
|
|
|
private data).</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<programlisting revisionflag="added">pld r12, symbol@pcrel
|
|
|
|
|
|
plxv v1, symbol@pcrel</programlisting>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para revisionflag="added">By using PC-relative GOT-indirect
|
|
|
addressing (for shared data):
|
|
|
</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<programlisting revisionflag="added">pld r12, symbol@got@pcrel
|
|
|
ld r12, 0(r12)
|
|
|
|
|
|
pld r12, symbol@got@pcrel
|
|
|
lvx v1, 0, r12</programlisting>
|
|
|
<para revisionflag="added">
|
|
|
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
|
|
|
from a statically or dynamically linked source, so the compiler must
|
|
|
be conservative. The compiler and linker can cooperate to replace a
|
|
|
PC-relative GOT-indirect sequence with a PC-relative sequence when
|
|
|
the data reference is satisfied at static link time. See
|
|
|
<xref linkend="dbdoclet.50655241_OptPCRel" />.
|
|
|
</para>
|
|
|
<para>Position-independent executables or shared objects have a GOT in
|
|
|
the data segment that holds addresses. When the system creates a memory
|
|
|
image from the file, the GOT entries are updated to reflect the
|
|
|
absolute virtual addresses that were assigned for the process. These
|
|
|
data segments are private, while the text segments are shared. In
|
|
|
systems based on the Power Architecture, the GOT can be addressed with
|
|
|
a single instruction if the GOT size is less than 65,536 bytes. A
|
|
|
larger GOT requires more general code to access all of its
|
|
|
entries.</para>
|
|
|
<para>The OpenPOWER-compliant processor hardware implementation and
|
|
|
linker optimizations described here work together to optimize efficient
|
|
|
code generation for applications with large GOTs. They use instruction
|
|
|
fusion to combine multiple ISA instructions into a single internal
|
|
|
operation.</para>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_19143">
|
|
|
<title>Code Models</title>
|
|
|
<para>Compilers may provide different code models depending on the
|
|
|
expected size of the TOC and the size of the entire executable or
|
|
|
shared library.</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Small code model: The TOC is accessed using 16-bit offsets
|
|
|
from the TOC pointer. This limits the size of a single TOC to 64
|
|
|
KB. Position-independent code uses GOT-indirect addressing to
|
|
|
access other objects in the binary.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Large code model: The TOC is accessed using 32-bit offsets
|
|
|
from the TOC pointer, except for .sdata and .sbss, which are
|
|
|
accessed using 16-bit offsets from the TOC pointer. This allows a
|
|
|
TOC of at least 2 GB. Position-independent code uses GOT-indirect
|
|
|
addressing to access other objects in the binary.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Medium code model: Like the large code model, the TOC is
|
|
|
accessed using 32-bit offsets from the TOC pointer, except for
|
|
|
.sdata and .sbss, which are accessed using 16-bit offsets. In
|
|
|
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
|
|
|
entire binary to between 2 GB and 4 GB, depending on the placement
|
|
|
of the TOC base.</para>
|
|
|
<note>
|
|
|
<para>The medium code model is the default for compilers, and it
|
|
|
is applicable to most programs and libraries. The code examples
|
|
|
in this document generally use the medium code model.</para>
|
|
|
</note>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>When linking medium and large code model relocatable objects, the
|
|
|
linker should place the .sdata and .sbss sections near to the TOC
|
|
|
base.</para>
|
|
|
<para>A linker must allow linking of relocatable object files using
|
|
|
different code models. This may be accomplished by sorting the
|
|
|
constituent sections of the TOC so that sections that are accessed
|
|
|
using 16-bit offsets are placed near to the TOC base, by using multiple
|
|
|
TOCs, or by some other method. The suggested allocation order of
|
|
|
sections is provided in
|
|
|
<xref linkend="dbdoclet.50655241_66700" />.</para>
|
|
|
<para revisionflag="added">
|
|
|
PC-relative addressing may be used with the medium code model.
|
|
|
Accesses to
|
|
|
module-local code and data objects use PC-relative addressing with
|
|
|
up to 34-bit offsets. Position-independent code uses PC-relative
|
|
|
GOT-indirect addressing to access shared objects.
|
|
|
</para>
|
|
|
</section>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_12107">
|
|
|
<title>Function Prologue and Epilogue</title>
|
|
|
<para>A function's prologue and epilogue are described in this
|
|
|
section.</para>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640597">
|
|
|
<title>Function Prologue</title>
|
|
|
<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
|
|
|
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 (GEP) 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 or LEP) 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
|
|
|
<emphasis>may</emphasis> choose (but is not required) to use the local
|
|
|
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>When a linker causes control to transfer to a global entry point
|
|
|
<phrase revisionflag="added">of a function that also has a local entry
|
|
|
point</phrase>,
|
|
|
it 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 GEP. <phrase revisionflag="added">
|
|
|
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>
|
|
|
<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
|
|
|
establishing addressability to a different, more optimized form.</para>
|
|
|
<para>For example, while linking a static module with a known load
|
|
|
address in the first 2 GB of the address space, the following code
|
|
|
sequence may be rewritten:</para>
|
|
|
<programlisting>addis r2, r12, .TOC.-func@ha
|
|
|
addi r2, r2, .TOC.-func@l</programlisting>
|
|
|
<para>It may be rewritten by a linker or assembler to an equivalent
|
|
|
form that is faster due to instruction fusion, such as:</para>
|
|
|
<programlisting>lis r2, .TOC.@ha
|
|
|
addi r2, r2, .TOC.@l</programlisting>
|
|
|
<para>In addition to establishing addressability, the function prologue
|
|
|
is responsible for the following functions:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Creating a stack frame when required</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Saving any nonvolatile registers that are used by the
|
|
|
function</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Saving any limited-access bits that are used by the function,
|
|
|
per the rules described in
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640581" /></para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>This ABI shall be used in conjunction with
|
|
|
the Power Architecture that implements the
|
|
|
<emphasis role="bold">mfocrf</emphasis> architecture level. Further,
|
|
|
OpenPOWER-compliant processors shall implement implementation-defined
|
|
|
bits in a manner to allow the combination of multiple
|
|
|
<emphasis role="bold">mfocrf</emphasis> results with an OR instruction; for example,
|
|
|
to yield a word in r0 including all three preserved CRs as
|
|
|
follows:</para>
|
|
|
<programlisting>mfocrf r0, crf2
|
|
|
mfocrf r1, crf3
|
|
|
or r0, r0, r1
|
|
|
mfocrf r1, crf4
|
|
|
or r0, r0, r1</programlisting>
|
|
|
<para>Specifically, this allows each
|
|
|
OpenPOWER-compliant processor implementation to set each field to hold
|
|
|
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"> </para>
|
|
|
<bridgehead>Assembly Language Syntax for Defining Entry
|
|
|
Points</bridgehead>
|
|
|
<para>When a function has two entry points, the global entry point is
|
|
|
defined as a symbol. The local entry point is defined with the
|
|
|
.localentry assembler pseudo op.</para>
|
|
|
<para />
|
|
|
<programlisting>my_func:
|
|
|
addis r2, r12, (.TOC.-my_func)@ha
|
|
|
addi r2, r2, (.TOC.-my_func)@l
|
|
|
.localentry my_func, .-my_func
|
|
|
... ; function definition
|
|
|
blr</programlisting>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655241_95185" /> shows how to represent dual
|
|
|
entry points in symbol tables in an ELF object file. It also defines
|
|
|
the meaning of the second parameter, which is put in the three
|
|
|
most-significant bits of the st_other field in the ELF Symbol Table
|
|
|
entry.</para>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_13754">
|
|
|
<title>Function Epilogue</title>
|
|
|
<para>The purpose of the epilogue is to perform the following
|
|
|
functions:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Restore all registers and limited-access bits that we saved
|
|
|
by the function's prologue.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Restore the last stack frame.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Return to the caller.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640599">
|
|
|
<title>Rules for Prologue and Epilogue Sequences</title>
|
|
|
<para>Set function prologue and function epilogue code sequences are
|
|
|
not imposed by this ABI. There are several rules that must be adhered
|
|
|
to in order to ensure reliable and consistent call chain
|
|
|
backtracing:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Before a function calls any other function, it shall
|
|
|
establish its own stack frame, whose size shall be a multiple of 16
|
|
|
bytes.</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>In instances where a function's prologue creates a stack
|
|
|
frame, the back-chain word of the stack frame shall be updated
|
|
|
atomically with the value of the stack pointer (r1) when a back
|
|
|
chain is implemented. (This must be supported as default by all ELF
|
|
|
V2 ABI-compliant environments.) This task can be done by using one
|
|
|
of the following Store Doubleword with Update instructions:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Store Doubleword with Update instruction with relevant
|
|
|
negative displacement for stack frames that are smaller than 32
|
|
|
KB</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Store Doubleword with Update Indexed instruction where the
|
|
|
negative size of the stack frame has been computed, using
|
|
|
<emphasis role="bold">addis</emphasis> and
|
|
|
<emphasis role="bold">addi</emphasis> or
|
|
|
<emphasis role="bold">ori</emphasis> instructions, and then loaded into a
|
|
|
volatile register, for stack frames that are 32 KB or
|
|
|
greater</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The function shall save the link register that contains its
|
|
|
return address in the LR save doubleword of its caller's stack
|
|
|
frame before calling another function.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The deallocation of a function's stack frame must be an
|
|
|
atomic operation. This task can be accomplished by one of the
|
|
|
following methods:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Increment the stack pointer by the identical value that it
|
|
|
was originally decremented by in the prologue when the stack frame
|
|
|
was created.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Load the stack pointer (r1) with the value in the back-chain
|
|
|
word in the stack frame, if a back chain is present.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The calling sequence does not restrict how languages leverage
|
|
|
the Local Variable Space of the stack frame. There is no
|
|
|
restriction on the size of this section.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The Parameter Save Area shall be allocated by the caller. It
|
|
|
shall be large enough to contain the parameters needed by the
|
|
|
caller if a Parameter Save Area is needed (as described in
|
|
|
<xref linkend="dbdoclet.50655240_15141" />). Its contents are not
|
|
|
saved across function calls.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>If any nonvolatile registers are to be used by the function,
|
|
|
the contents of the register must be saved into a register save
|
|
|
area. See
|
|
|
<xref linkend="dbdoclet.50655240_15141" /> for information on all of
|
|
|
the optional register save areas.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>Saving or restoring nonvolatile registers used by the function
|
|
|
can be accomplished by using in-line code. Alternately, one of the
|
|
|
system subroutines described in
|
|
|
<xref linkend="dbdoclet.50655240_24141"/> may offer a more efficient alternative
|
|
|
to in-line code, especially in cases where there are many registers to
|
|
|
be saved or restored.</para>
|
|
|
</section>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_24141">
|
|
|
<title>Register Save and Restore Functions</title>
|
|
|
<para>This section describes functions that can be used to save and
|
|
|
restore the contents of nonvolatile registers. Using these routines,
|
|
|
rather than performing these saves and restores inline in the prologue
|
|
|
and epilogue of functions, can help reduce the code footprint. The
|
|
|
calling conventions of these functions are not standard, and the
|
|
|
executables or shared objects that use these functions must statically
|
|
|
link them.</para>
|
|
|
<para>The register save and restore functions affect consecutive
|
|
|
registers from register N through register 31, where N represents a
|
|
|
number between 14 and 31. Higher-numbered registers are saved at higher
|
|
|
addresses within a save area. Each function described in this section is
|
|
|
a family of functions with identical behavior except for the number and
|
|
|
kind of registers affected.</para>
|
|
|
<para>Systems must provide three pairs of functions to save and restore
|
|
|
general-purpose, floating-point, and vector registers. They may be
|
|
|
implemented as multiple-entry-point routines or as individual routines.
|
|
|
The specific calling conventions for each of these functions are
|
|
|
described in
|
|
|
<xref linkend="dbdoclet.50655240_41483" />,
|
|
|
<xref linkend="dbdoclet.50655240_56788" />, and
|
|
|
<xref linkend="dbdoclet.50655240_96790" />. Visibility rules are
|
|
|
described in
|
|
|
<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.
|
|
|
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.
|
|
|
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>
|
|
|
<programlisting> _savegpr0_14: std r14,-144(r1)
|
|
|
_savegpr0_15: std r15,-136(r1)
|
|
|
_savegpr0_16: std r16,-128(r1)
|
|
|
_savegpr0_17: std r17,-120(r1)
|
|
|
_savegpr0_18: std r18,-112(r1)
|
|
|
_savegpr0_19: std r19,-104(r1)
|
|
|
_savegpr0_20: std r20,-96(r1)
|
|
|
_savegpr0_21: std r21,-88(r1)
|
|
|
_savegpr0_22: std r22,-80(r1)
|
|
|
_savegpr0_23: std r23,-72(r1)
|
|
|
_savegpr0_24: std r24,-64(r1)
|
|
|
_savegpr0_25: std r25,-56(r1)
|
|
|
_savegpr0_26: std r26,-48(r1)
|
|
|
_savegpr0_27: std r27,-40(r1)
|
|
|
_savegpr0_28: std r28,-32(r1)
|
|
|
_savegpr0_29: std r29,-24(r1)
|
|
|
_savegpr0_30: std r30,-16(r1)
|
|
|
_savegpr0_31: std r31,-8(r1)
|
|
|
std r0, 16(r1)
|
|
|
blr
|
|
|
|
|
|
_restgpr0_14: ld r14,-144(r1)
|
|
|
_restgpr0_15: ld r15,-136(r1)
|
|
|
_restgpr0_16: ld r16,-128(r1)
|
|
|
_restgpr0_17: ld r17,-120(r1)
|
|
|
_restgpr0_18: ld r18,-112(r1)
|
|
|
_restgpr0_19: ld r19,-104(r1)
|
|
|
_restgpr0_20: ld r20,-96(r1)
|
|
|
_restgpr0_21: ld r21,-88(r1)
|
|
|
_restgpr0_22: ld r22,-80(r1)
|
|
|
_restgpr0_23: ld r23,-72(r1)
|
|
|
_restgpr0_24: ld r24,-64(r1)
|
|
|
_restgpr0_25: ld r25,-56(r1)
|
|
|
_restgpr0_26: ld r26,-48(r1)
|
|
|
_restgpr0_27: ld r27,-40(r1)
|
|
|
_restgpr0_28: ld r28,-32(r1)
|
|
|
_restgpr0_29: ld r0, 16(r1)
|
|
|
ld r29,-24(r1)
|
|
|
mtlr r0
|
|
|
ld r30,-16(r1)
|
|
|
ld r31,-8(r1)
|
|
|
blr
|
|
|
_restgpr0_30: ld r30,-16(r1)
|
|
|
_restgpr0_31: ld r0, 16(r1)
|
|
|
ld r31,-8(r1)
|
|
|
mtlr r0
|
|
|
blr</programlisting>
|
|
|
<para>Each _savegpr1_N routine saves the general registers from
|
|
|
rN–r31, inclusive. When the routine is called, r12 contains the address of
|
|
|
the word just beyond the end of the general register save area.</para>
|
|
|
<para>The _restgpr1_N routines restore the general registers from
|
|
|
rN–r31. When the routine is called, r12 contains the address of the word
|
|
|
just beyond the end of the general register save area, superseding the
|
|
|
normal use of r12 on a call.</para>
|
|
|
<para>A sample implementation of _savegpr1_N and _restgpr1_N
|
|
|
follows:</para>
|
|
|
<programlisting> _savegpr1_14: std r14,-144(r12)
|
|
|
_savegpr1_15: std r15,-136(r12)
|
|
|
_savegpr1_16: std r16,-128(r12)
|
|
|
_savegpr1_17: std r17,-120(r12)
|
|
|
_savegpr1_18: std r18,-112(r12)
|
|
|
_savegpr1_19: std r19,-104(r12)
|
|
|
_savegpr1_20: std r20,-96(r12)
|
|
|
_savegpr1_21: std r21,-88(r12)
|
|
|
_savegpr1_22: std r22,-80(r12)
|
|
|
_savegpr1_23: std r23,-72(r12)
|
|
|
_savegpr1_24: std r24,-64(r12)
|
|
|
_savegpr1_25: std r25,-56(r12)
|
|
|
_savegpr1_26: std r26,-48(r12)
|
|
|
_savegpr1_27: std r27,-40(r12)
|
|
|
_savegpr1_28: std r28,-32(r12)
|
|
|
_savegpr1_29: std r29,-24(r12)
|
|
|
_savegpr1_30: std r30,-16(r12)
|
|
|
_savegpr1_31: std r31,-8(r12)
|
|
|
blr
|
|
|
|
|
|
_restgpr1_14: ld r14,-144(r12)
|
|
|
_restgpr1_15: ld r15,-136(r12)
|
|
|
_restgpr1_16: ld r16,-128(r12)
|
|
|
_restgpr1_17: ld r17,-120(r12)
|
|
|
_restgpr1_18: ld r18,-112(r12)
|
|
|
_restgpr1_19: ld r19,-104(r12)
|
|
|
_restgpr1_20: ld r20,-96(r12)
|
|
|
_restgpr1_21: ld r21,-88(r12)
|
|
|
_restgpr1_22: ld r22,-80(r12)
|
|
|
_restgpr1_23: ld r23,-72(r12)
|
|
|
_restgpr1_24: ld r24,-64(r12)
|
|
|
_restgpr1_25: ld r25,-56(r12)
|
|
|
_restgpr1_26: ld r26,-48(r12)
|
|
|
_restgpr1_27: ld r27,-40(r12)
|
|
|
_restgpr1_28: ld r28,-32(r12)
|
|
|
_restgpr1_29: ld r29,-24(r12)
|
|
|
_restgpr1_30: ld r30,-16(r12)
|
|
|
_restgpr1_31: ld r31,-8(r12)
|
|
|
blr</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
|
|
|
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
|
|
|
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>
|
|
|
<para>It is incorrect to call both _savefpr_M and _savegpr0_M in the
|
|
|
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>
|
|
|
<programlisting> _savefpr_14: stfd f14,-144(r1)
|
|
|
_savefpr_15: stfd f15,-136(r1)
|
|
|
_savefpr_16: stfd f16,-128(r1)
|
|
|
_savefpr_17: stfd f17,-120(r1)
|
|
|
_savefpr_18: stfd f18,-112(r1)
|
|
|
_savefpr_19: stfd f19,-104(r1)
|
|
|
_savefpr_20: stfd f20,-96(r1)
|
|
|
_savefpr_21: stfd f21,-88(r1)
|
|
|
_savefpr_22: stfd f22,-80(r1)
|
|
|
_savefpr_23: stfd f23,-72(r1)
|
|
|
_savefpr_24: stfd f24,-64(r1)
|
|
|
_savefpr_25: stfd f25,-56(r1)
|
|
|
_savefpr_26: stfd f26,-48(r1)
|
|
|
_savefpr_27: stfd f27,-40(r1)
|
|
|
_savefpr_28: stfd f28,-32(r1)
|
|
|
_savefpr_29: stfd f29,-24(r1)
|
|
|
_savefpr_30: stfd f30,-16(r1)
|
|
|
_savefpr_31: stfd f31,-8(r1)
|
|
|
std r0, 16(r1)
|
|
|
blr
|
|
|
|
|
|
_restfpr_14: lfd f14,-144(r1)
|
|
|
_restfpr_15: lfd f15,-136(r1)
|
|
|
_restfpr_16: lfd f16,-128(r1)
|
|
|
_restfpr_17: lfd f17,-120(r1)
|
|
|
_restfpr_18: lfd f18,-112(r1)
|
|
|
_restfpr_19: lfd f19,-104(r1)
|
|
|
_restfpr_20: lfd f20,-96(r1)
|
|
|
_restfpr_21: lfd f21,-88(r1)
|
|
|
_restfpr_22: lfd f22,-80(r1)
|
|
|
_restfpr_23: lfd f23,-72(r1)
|
|
|
_restfpr_24: lfd f24,-64(r1)
|
|
|
_restfpr_25: lfd f25,-56(r1)
|
|
|
_restfpr_26: lfd f26,-48(r1)
|
|
|
_restfpr_27: lfd f27,-40(r1)
|
|
|
_restfpr_28: lfd f28,-32(r1)
|
|
|
_restfpr_29: ld r0, 16(r1)
|
|
|
lfd f29,-24(r1)
|
|
|
mtlr r0
|
|
|
lfd f30,-16(r1)
|
|
|
lfd f31,-8(r1)
|
|
|
blr
|
|
|
|
|
|
_restfpr_30: lfd f30,-16(r1)
|
|
|
_restfpr_31: ld r0, 16(r1)
|
|
|
lfd f31,-8(r1)
|
|
|
mtlr r0
|
|
|
blr</programlisting>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_96790">
|
|
|
<title>Vector Save and Restore Functions</title>
|
|
|
<para>Each _savevr_M routine saves the vector registers from vM–v31
|
|
|
inclusive.
|
|
|
<anchor xml:id="dbdoclet.50655240_page74" xreflabel="" />
|
|
|
<anchor xml:id="dbdoclet.50655240_page73" xreflabel="" />
|
|
|
<anchor xml:id="dbdoclet.50655240_page72" xreflabel="" />
|
|
|
<anchor xml:id="dbdoclet.50655240_page71" xreflabel="" />
|
|
|
<anchor xml:id="dbdoclet.50655240_page70" xreflabel="" />
|
|
|
<anchor xml:id="dbdoclet.50655240_page69" xreflabel="" /> On entry to
|
|
|
this function, r0 contains the address of the word just beyond the end
|
|
|
of the Vector Register Save Area. The routines leave r0 undisturbed.
|
|
|
They modify the value of r12.</para>
|
|
|
<para>The _restvr_M routines restore the vector registers from vM–v31
|
|
|
inclusive. On entry to this function, r0 contains the address of the
|
|
|
word just beyond the end of the Vector Register Save Area. The routines
|
|
|
leave r0 undisturbed. They modify the value of r12. The following code
|
|
|
is an example of restoring a vector register.</para>
|
|
|
<para>It is valid to call _savevr_M before any of the other register
|
|
|
save functions, or after _savegpr1_M. It is valid to call _restvr_M
|
|
|
before any of the other register restore functions, or after
|
|
|
_restgpr1_M.</para>
|
|
|
<para>A sample implementation of _savevr_M and _restvr_M
|
|
|
follows:</para>
|
|
|
<programlisting>
|
|
|
_savevr_20: addi r12,r0,-192
|
|
|
stvx v20,r12,r0 # save v20
|
|
|
_savevr_21: addi r12,r0,-176
|
|
|
stvx v21,r12,r0 # save v21
|
|
|
_savevr_22: addi r12,r0,-160
|
|
|
stvx v22,r12,r0 # save v22
|
|
|
_savevr_23: addi r12,r0,-144
|
|
|
stvx v23,r12,r0 # save v23
|
|
|
_savevr_24: addi r12,r0,-128
|
|
|
stvx v24,r12,r0 # save v24
|
|
|
_savevr_25: addi r12,r0,-112
|
|
|
stvx v25,r12,r0 # save v25
|
|
|
_savevr_26: addi r12,r0,-96
|
|
|
stvx v26,r12,r0 # save v26
|
|
|
_savevr_27: addi r12,r0,-80
|
|
|
stvx v27,r12,r0 # save v27
|
|
|
_savevr_28: addi r12,r0,-64
|
|
|
stvx v28,r12,r0 # save v28
|
|
|
_savevr_29: addi r12,r0,-48
|
|
|
stvx v29,r12,r0 # save v29
|
|
|
_savevr_30: addi r12,r0,-32
|
|
|
stvx v30,r12,r0 # save v30
|
|
|
_savevr_31: addi r12,r0,-16
|
|
|
stvx v31,r12,r0 # save v31
|
|
|
blr # return to epilogue
|
|
|
|
|
|
_restvr_20: addi r12,r0,-192
|
|
|
lvx v20,r12,r0 # restore v20
|
|
|
_restvr_21: addi r12,r0,-176
|
|
|
lvx v21,r12,r0 # restore v21
|
|
|
_restvr_22: addi r12,r0,-160
|
|
|
lvx v22,r12,r0 # restore v22
|
|
|
_restvr_23: addi r12,r0,-144
|
|
|
lvx v23,r12,r0 # restore v23
|
|
|
_restvr_24: addi r12,r0,-128
|
|
|
lvx v24,r12,r0 # restore v24
|
|
|
_restvr_25: addi r12,r0,-112
|
|
|
lvx v25,r12,r0 # restore v25
|
|
|
_restvr_26: addi r12,r0,-96
|
|
|
lvx v26,r12,r0 # restore v26
|
|
|
_restvr_27: addi r12,r0,-80
|
|
|
lvx v27,r12,r0 # restore v27
|
|
|
_restvr_28: addi r12,r0,-64
|
|
|
lvx v28,r12,r0 # restore v28
|
|
|
_restvr_29: addi r12,r0,-48
|
|
|
lvx v29,r12,r0 # restore v29
|
|
|
_restvr_30: addi r12,r0,-32
|
|
|
lvx v30,r12,r0 # restore v30
|
|
|
_restvr_31: addi r12,r0,-16
|
|
|
lvx v31,r12,r0 # restore v31
|
|
|
blr #return to epilogue</programlisting>
|
|
|
</section>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_29249">
|
|
|
<title>Function Pointers</title>
|
|
|
<para>A function's address is defined to be its global entry point.
|
|
|
Function pointers shall contain the global entry-point address.</para>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640604">
|
|
|
<title>Static Data Objects</title>
|
|
|
<para>Data objects with static storage duration are described here.
|
|
|
Stack-resident data objects are omitted because the virtual addresses of
|
|
|
stack-resident data objects are derived relative to the stack or frame
|
|
|
pointers. Heap data objects are omitted because they are accessed via a
|
|
|
program pointer.</para>
|
|
|
<para>The only instructions that can access memory in the Power
|
|
|
Architecture are load and store instructions. Programs typically access
|
|
|
memory by placing the address of the memory location into a register and
|
|
|
accessing the memory location indirectly through the register because
|
|
|
Power Architecture instructions cannot hold 64-bit addresses directly.
|
|
|
The values of symbols or their absolute virtual addresses are placed
|
|
|
directly into instructions for symbolic references in absolute
|
|
|
code.</para>
|
|
|
<para>
|
|
|
<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
|
|
|
linkend="dbdoclet.50655240_12719" />,
|
|
|
<xref linkend="dbdoclet.50655240_page77" />,
|
|
|
<xref linkend="dbdoclet.50655240_19926" />, and
|
|
|
<xref linkend="dbdoclet.50655240_StaticPCRel" /></phrase>. 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
|
|
|
addressing while shared objects must use position-independent code
|
|
|
addressing. The figures are intended to demonstrate the compilation of
|
|
|
each C statement independent of its context; hence, there can be
|
|
|
redundant operations in the code.</para>
|
|
|
<para>Absolute addressing efficiency depends on the memory-region
|
|
|
addresses:</para>
|
|
|
<informaltable frame="none">
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Top 32 KB</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Addressed directly with load and store D forms.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Top 2 GB</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Addressed by a two-instruction sequence consisting of an
|
|
|
lis with load and store D forms.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Remaining addresses</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>More than two instructions.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Bottom 2 GB</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Addressed by a two-instruction sequence consisting of an
|
|
|
lis with load and store D forms.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Bottom 32 KB</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Addressed directly with load and store D forms.</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</informaltable>
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_12719">
|
|
|
<title>Absolute Load and Store Example</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>extern int src;
|
|
|
extern int dst;
|
|
|
extern int *ptr;
|
|
|
|
|
|
dst = src;
|
|
|
|
|
|
|
|
|
|
|
|
ptr = &dst;
|
|
|
|
|
|
|
|
|
|
|
|
*ptr = src;
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>.extern src
|
|
|
.extern dst
|
|
|
.extern ptr
|
|
|
.section ".text"
|
|
|
lis r9,src@ha
|
|
|
lwz r9,src@l(r9)
|
|
|
lis r11,dst@ha
|
|
|
stw r9,dst@l(r11)
|
|
|
lis r11,ptr@ha
|
|
|
lis r9,dst@ha
|
|
|
la r9,dst@l(r9)
|
|
|
std r9,ptr@l(r11)
|
|
|
lis r11,ptr@ha
|
|
|
lwz r11,ptr@l(r11)
|
|
|
lis r9,src@ha
|
|
|
lwz r9,src@l(r9)
|
|
|
stw r9,0(r11)</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_page77">
|
|
|
<title>Small Model Position-Independent Load and Store (DSO)</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>extern int src;
|
|
|
extern int dst;
|
|
|
extern int *ptr;
|
|
|
|
|
|
|
|
|
dst = src;
|
|
|
|
|
|
|
|
|
|
|
|
ptr = &dst;
|
|
|
|
|
|
|
|
|
*ptr = src;
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>.extern src
|
|
|
.extern dst
|
|
|
.extern ptr
|
|
|
.section ".text"
|
|
|
# TOC base in r2
|
|
|
ld r9,src@got(2)
|
|
|
lwz r0,0(r9)
|
|
|
ld r9,dst@got(r2)
|
|
|
stw r0,0(r9)
|
|
|
ld r9,ptr@got(r2)
|
|
|
ld r0,dst@got(r2)
|
|
|
std r0,0(r9)
|
|
|
ld r9,ptr@got(r2)
|
|
|
ld r11,0(r9)
|
|
|
ld r9,src@got(r2)
|
|
|
lwz r0,0(r9)
|
|
|
stw r0,0(r11)</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_19926">
|
|
|
<title>Medium or Large Model Position-Independent Load and Store
|
|
|
(DSO)</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>extern int src;
|
|
|
extern int dst;
|
|
|
int *ptr;
|
|
|
|
|
|
|
|
|
dst = src;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ptr = &dst;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*ptr = src;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>.extern src
|
|
|
.extern dst
|
|
|
.extern ptr
|
|
|
.section".text"
|
|
|
# AssumesTOC pointer in r2
|
|
|
addis r6,r2,src@got@ha
|
|
|
ld r6,src@got@l(r6)
|
|
|
addis r7,r2,dst@got@ha
|
|
|
ld r7,dst@got@l(r7)
|
|
|
lwz r0,0(r6)
|
|
|
stw r0,0(r7)
|
|
|
addis r6,r2,dst@got@ha
|
|
|
ld r6,dst@got@l(r6)
|
|
|
addis r7,r2,ptr@got@ha
|
|
|
ld r7,ptr@got@l(r7)
|
|
|
stw r6,0(r7)
|
|
|
addis r6,r2,src@got@ha
|
|
|
ld r6,src@got@l(r6)
|
|
|
addis r7,r2,ptr@got@ha
|
|
|
ld r7,ptr@got@l(r7)
|
|
|
ld r7,0(r7)
|
|
|
lwz r0,0(r6)
|
|
|
stw r0,0,(r7)</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_StaticPCRel"
|
|
|
revisionflag="added">
|
|
|
<title>PC-Relative Load and Store</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>extern int src;
|
|
|
extern int dst;
|
|
|
int *ptr;
|
|
|
|
|
|
dst = src;
|
|
|
|
|
|
ptr = &dst;
|
|
|
|
|
|
*ptr = src;
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>.extern src
|
|
|
.extern dst
|
|
|
.extern ptr
|
|
|
.section ".text"
|
|
|
plwz r9, src@pcrel
|
|
|
pstw r9, dst@pcrel
|
|
|
paddi r11, dst@pcrel
|
|
|
pstd r11, ptr@pcrel
|
|
|
pld r11, ptr@pcrel
|
|
|
plwz r9, src@pcrel
|
|
|
stw r9, 0(r11)</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<note>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Due to fusion hardware support, the preferred code forms are
|
|
|
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
|
|
|
instruction so that only one result register is produced. Fusion
|
|
|
can then give the same performance as a single load instruction
|
|
|
with a 32-bit displacement.</para>
|
|
|
</footnote> addressing forms with an addis specifying a set of
|
|
|
high-order bits followed immediately by a destructive load using
|
|
|
the same target register as the addis instruction to load data from
|
|
|
a signed 32-bit offset from a base register.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>For <phrase revisionflag="changed">TOC-based</phrase> 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
|
|
|
given by the assembly syntax symbol@got. This syntax represents the
|
|
|
address of the variable named "symbol."</para>
|
|
|
<para>The offset for this assembly syntax cannot be any larger than 16
|
|
|
bits. In cases where the offset is greater than 16 bits, the following
|
|
|
assembly syntax is used for offsets up to 32 bits:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>High (32-bit) adjusted part of the offset:
|
|
|
symbol@got@ha</para>
|
|
|
<para>Causes a linker error if the offset is larger than 32
|
|
|
bits.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>High (32-bit) part of the offset: symbol@got@h</para>
|
|
|
<para>Causes a linker error if the offset is larger than 32
|
|
|
bits.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Low part of the offset: symbol@got@l</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>To obtain the multiple 16-bit segments of a 64-bit offset, the
|
|
|
following operators may be used:</para>
|
|
|
<itemizedlist spacing="compact">
|
|
|
<listitem>
|
|
|
<para>Highest (most-significant 16 bits) adjusted part of the
|
|
|
offset: symbol@highesta</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Highest (most-significant 16 bits) part of the offset:
|
|
|
symbol@highest</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Higher (next significant 16 bits) adjusted part of the
|
|
|
offset: symbol@highera</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Higher (next significant 16 bits) part of the offset:
|
|
|
symbol@higher</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>High (next significant 16 bits) adjusted part of the offset:
|
|
|
symbol@higha</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>High (next significant 16 bits) part of the offset:
|
|
|
symbol@high</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<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.
|
|
|
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
|
|
|
<xref linkend="dbdoclet.50655241_51269" />.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
</note>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_88555">
|
|
|
<title>Function Calls</title>
|
|
|
<para>Direct function calls are made in programs with the Power
|
|
|
Architecture bl instruction. A bl instruction can reach 32 MB backwards
|
|
|
or forwards from the current position due to a self-relative branch
|
|
|
displacement in the instruction. Therefore, the size of the text segment
|
|
|
in an executable or shared object is constrained when a bl instruction is
|
|
|
used to make a function call. When the distance of the called function
|
|
|
exceeds the displacement reach of the bl instruction, a linker
|
|
|
implementation may either introduce branch trampoline code to extend
|
|
|
function call distances or issue a link error.</para>
|
|
|
<para>As shown in
|
|
|
<xref linkend="dbdoclet.50655240_85319" />, the bl instruction is
|
|
|
generally used to call a local function.</para>
|
|
|
<para>Two possibilities exist for the location of the function with
|
|
|
respect to the caller:</para>
|
|
|
<orderedlist>
|
|
|
<listitem>
|
|
|
<para>The called function is in the same executable or shared object
|
|
|
as the caller. In this case, the symbol is resolved by the link
|
|
|
editor and the bl instruction branches directly to the called
|
|
|
function as shown in
|
|
|
<xref linkend="dbdoclet.50655240_85319" />.</para>
|
|
|
</listitem>
|
|
|
</orderedlist>
|
|
|
<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*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>extern void function( );
|
|
|
function( );</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>
|
|
|
bl function
|
|
|
nop</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table -->
|
|
|
<orderedlist continuation="continues">
|
|
|
<listitem>
|
|
|
<para>The called function is not in the same executable or shared
|
|
|
object as the caller. In this case, the symbol cannot be directly
|
|
|
resolved by the link editor. The link editor generates a branch to
|
|
|
glue code that loads the address of the function from the Procedure
|
|
|
Linkage Table. See
|
|
|
<xref linkend="dbdoclet.50655242_20388" />.</para>
|
|
|
</listitem>
|
|
|
</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 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"
|
|
|
xml:id="dbdoclet.50655240_95364">
|
|
|
<title>Indirect Function Call (Absolute Medium Model)</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>extern void function( );
|
|
|
extern void (*ptrfunc) ( );
|
|
|
|
|
|
ptrfunc = function;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(*ptrfunc) ( );
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>
|
|
|
|
|
|
.section .text
|
|
|
lis r11,ptrfunc@ha
|
|
|
lis r9,function@ha
|
|
|
ld r9,function@l(r9)
|
|
|
std r9,ptrfunc@l(r11)
|
|
|
|
|
|
lis r12,ptrfunc@ha
|
|
|
ld r12,ptrfunc@l(r12)
|
|
|
mtctr r12
|
|
|
bctrl</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</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" revisionflag="changed"
|
|
|
xml:id="dbdoclet.50655240_16744">
|
|
|
<title>Small-Model Position-Independent Indirect Function Call</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>extern void function( );
|
|
|
extern void (*ptrfunc) ( );
|
|
|
|
|
|
|
|
|
ptrfunc = function;
|
|
|
|
|
|
|
|
|
|
|
|
(*ptrfunc) ( );
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>
|
|
|
|
|
|
.section .text
|
|
|
/* TOC pointer is in r2 */
|
|
|
ld r9,ptrfunc@got(r2)
|
|
|
ld r0,function@got(r2)
|
|
|
std r0,0(r9)
|
|
|
|
|
|
ld r9,ptrfunc@got(r2)
|
|
|
ld r12,0(r9)
|
|
|
mtctr r12
|
|
|
std r2,24(r1)
|
|
|
bctrl
|
|
|
ld r2,24(r1)</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</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" revisionflag="changed"
|
|
|
xml:id="dbdoclet.50655240_95225">
|
|
|
<title>Large-Model Position-Independent Indirect Function Call</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>extern void function( );
|
|
|
extern void (*ptrfunc) ( );
|
|
|
|
|
|
|
|
|
ptrfunc = function;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(*ptrfunc) ( );
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>
|
|
|
|
|
|
.section .text
|
|
|
/* TOC pointer is in r2 */
|
|
|
addis r9,r2,ptrfunc@got@ha
|
|
|
ld r9,ptrfunc@got@l(r9)
|
|
|
addis r12,r2,function@got@ha
|
|
|
ld r12,function@got@l(r12)
|
|
|
std r12,0(r9)
|
|
|
|
|
|
addis r9,r2,ptrfunc@got@ha
|
|
|
ld r9,ptrfunc@got@l(r9)
|
|
|
ld r12,0(r9)
|
|
|
std r2,24(r1)
|
|
|
mtctr r12
|
|
|
bctrl
|
|
|
ld r2,24(r1)</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para revisionflag="added">
|
|
|
<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"
|
|
|
xml:id="dbdoclet.50655240_PCRelPICIndirect">
|
|
|
<title>PC-Relative Position-Independent Indirect Function Call</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>extern void function( );
|
|
|
|
|
|
extern void (*ptrfunc) ( );
|
|
|
ptrfunc=function;
|
|
|
|
|
|
|
|
|
(*ptrfunc) ( );
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>.section .text
|
|
|
|
|
|
pld r9,ptrfunc@got@pcrel
|
|
|
pld r0,function@got@pcrel
|
|
|
std r0,0(r9)
|
|
|
|
|
|
pld r9, ptrfunc@got@pcrel
|
|
|
ld r12,0(r9)
|
|
|
mtctr r12
|
|
|
bctrl</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para>Function calls <phrase revisionflag="added">often</phrase>
|
|
|
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. <phrase revisionflag="added">In many cases,</phrase>
|
|
|
<phrase revisionflag="changed">the</phrase> 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<phrase
|
|
|
revisionflag="changed">.</phrase> 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">
|
|
|
There are two cases where the caller need not provide a nop after
|
|
|
the bl instruction performing a call:
|
|
|
<itemizedlist spacing="compact">
|
|
|
<listitem><para>When the bl instruction is marked with an
|
|
|
R_PPC64_REL24_NOTOC relocation (see
|
|
|
<xref linkend="dbdoclet.50655241_90220" />); or</para></listitem>
|
|
|
<listitem><para>When the callee is in the same compilation unit and
|
|
|
is guaranteed to preserve r2.</para></listitem>
|
|
|
</itemizedlist>
|
|
|
</para>
|
|
|
<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
|
|
|
with an R_PPC64_TOCSAVE relocation that points to a nop provided in the
|
|
|
caller's prologue. In <phrase revisionflag="changed">either</phrase>
|
|
|
case, the stub code can omit the r2 save.
|
|
|
<phrase revisionflag="changed">In the latter case,</phrase>
|
|
|
the linker replaces the prologue nop with an r2 save.</para>
|
|
|
<programlisting>tocsaveloc:
|
|
|
nop
|
|
|
...
|
|
|
bl target
|
|
|
.reloc ., R_PPC64_TOCSAVE, tocsaveloc
|
|
|
nop</programlisting>
|
|
|
<para>The linker may assume that r2 is valid at the point of a call.
|
|
|
Thus, stub code may use r2 to load an address from the PLT unless the
|
|
|
call is marked with an R_PPC64_REL24_NOTOC relocation to indicate that r2
|
|
|
is not available.</para>
|
|
|
<para>The nop instruction must be:</para>
|
|
|
<programlisting>ori r0,r0,0</programlisting>
|
|
|
<para>For more information, see
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640597" />,
|
|
|
<xref linkend="dbdoclet.50655241_95185" />, and
|
|
|
<xref linkend="dbdoclet.50655241_47572" />.</para>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_47036">
|
|
|
<title>Branching</title>
|
|
|
<para>The flow of execution in a program is controlled by the use of
|
|
|
branch instructions. Unconditional branch instructions can jump to
|
|
|
locations up to 32 MB in either direction because they hold a signed
|
|
|
value with a 64 MB range that is relative to the current location of the
|
|
|
program execution.</para>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_66111" /> shows the model for branch
|
|
|
instructions.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1" revisionflag="changed"
|
|
|
xml:id="dbdoclet.50655240_66111">
|
|
|
<title>Branch Instruction Model</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>label:
|
|
|
...
|
|
|
goto label;</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>.L01:
|
|
|
...
|
|
|
b .L01</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</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
|
|
|
grouping constraints. In the examples that follow, details that are not
|
|
|
relevant are avoided by the use of the following simplifying
|
|
|
assumptions:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>r12 holds the selection expression.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Case label constants begin at zero.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>The assembler names .Lcasei, .Ldefault, and .Ltab are used for
|
|
|
the case labels, the default, and the address table
|
|
|
respectively.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<para>For position-dependent code (for example, the main module of an
|
|
|
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"
|
|
|
xml:id="dbdoclet.50655240_AbsSwitch">
|
|
|
<title>Absolute Switch Code (Within) for static modules located in low
|
|
|
or high 2 GB of address space</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>switch (j)
|
|
|
{
|
|
|
case 0:
|
|
|
...
|
|
|
case 1:
|
|
|
...
|
|
|
case 3:
|
|
|
...
|
|
|
default:
|
|
|
...
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>cmplwi r12,4
|
|
|
bge .Ldefault
|
|
|
slwi r12,2
|
|
|
addis r12,r12,.Ltab@ha
|
|
|
lwa r12,.Ltab@l(r12)
|
|
|
mtctr r12
|
|
|
bctr
|
|
|
.rodata
|
|
|
.Ltab:
|
|
|
.long .Lcase0
|
|
|
.long .Lcase1
|
|
|
.long .Ldefault
|
|
|
.long .Lcase3
|
|
|
.text</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</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" revisionflag="changed"
|
|
|
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>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>switch (j)
|
|
|
{
|
|
|
case 0:
|
|
|
...
|
|
|
case 1:
|
|
|
...
|
|
|
case 3:
|
|
|
...
|
|
|
default:
|
|
|
...
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>cmplwi r12,4
|
|
|
bge .Ldefault
|
|
|
slwi r12,2
|
|
|
addis r12,r12,.Ltab@ha
|
|
|
ld r12,.Ltab@l(r12)
|
|
|
mtctr r12
|
|
|
bctr
|
|
|
.rodata
|
|
|
.Ltab:
|
|
|
.long .Lcase0
|
|
|
.long .Lcase1
|
|
|
.long .Ldefault
|
|
|
.long .Lcase3
|
|
|
.text</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</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
|
|
|
pointer points to a fixed offset from the code segment. The use of
|
|
|
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"
|
|
|
xml:id="dbdoclet.50655240_SwitchPicMed">
|
|
|
<title>Position-Independent Switch Code for Small/Medium Models
|
|
|
(preferred, with TOC-relative addressing)</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>switch (j)
|
|
|
{
|
|
|
case 0:
|
|
|
...
|
|
|
case 1:
|
|
|
...
|
|
|
case 3:
|
|
|
...
|
|
|
default:
|
|
|
...
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>cmplwi r12,4
|
|
|
bge .Ldefault
|
|
|
addis r10,r2,(.Ltab-.TOC.)@ha
|
|
|
addi r10,r10,(.Ltab-.TOC.)@l
|
|
|
slwi r12,2
|
|
|
lwax r8,r10,r12
|
|
|
add r10,r8,r10
|
|
|
mtctr r10
|
|
|
bctr
|
|
|
.Ltab:
|
|
|
.word (.Lcase0-.Ltab)
|
|
|
.word (.Lcase1-.Ltab)
|
|
|
.word (.Ldefault-.Ltab)
|
|
|
.word (.Lcase3-.Ltab)</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</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
|
|
|
models where the distance between the TOC and the branch table exceeds 2
|
|
|
GB. The use of 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"
|
|
|
xml:id="dbdoclet.50655240_SwitchGotAll">
|
|
|
<title>Position-Independent Switch Code for All Models (alternate, with
|
|
|
GOT-indirect addressing)</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>switch (j)
|
|
|
{
|
|
|
case 0:
|
|
|
...
|
|
|
case 1:
|
|
|
...
|
|
|
case 3:
|
|
|
...
|
|
|
default:
|
|
|
...
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting>cmplwi r12,4
|
|
|
bge .Ldefault
|
|
|
addis r10,r2,.Ltab@got@ha
|
|
|
ld r10,r10,.Ltab@got@l(r10)
|
|
|
slwi r12,2
|
|
|
lwax r8,r10,r12
|
|
|
add r10,r8,r10
|
|
|
mtctr r10
|
|
|
bctr
|
|
|
.Ltab:
|
|
|
.word (.Lcase0-.Ltab)
|
|
|
.word (.Lcase1-.Ltab)
|
|
|
.word (.Ldefault-.Ltab)
|
|
|
.word (.Lcase3-.Ltab)</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</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
|
|
|
result in lower performance in some POWER processor
|
|
|
implementations.</para>
|
|
|
<figure xml:id="dbdoclet.50655240_11405">
|
|
|
<title>PIC Code that Avoids the lwa Instruction</title>
|
|
|
<programlisting> .text
|
|
|
f1:
|
|
|
addis r9,r2,.Ltab@ha
|
|
|
sldi r10,r3,2
|
|
|
addi r9,r9,.Ltab@l
|
|
|
lwzx r10,r10,r9
|
|
|
sub r10,r2,r10
|
|
|
mtctr r10
|
|
|
bctr
|
|
|
.Ltab:
|
|
|
.long .TOC. - Lcase0
|
|
|
.long .TOC. - Lcase1
|
|
|
.long .TOC. - Ldefault
|
|
|
.long .TOC. - Lcase13</programlisting>
|
|
|
</figure>
|
|
|
<para revisionflag="added">
|
|
|
<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">
|
|
|
<title>
|
|
|
Position-Independent Switch Code (PC-Relative Addressing)
|
|
|
</title>
|
|
|
<tgroup cols="2">
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
<colspec colname="c2" colwidth="70*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">C Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Assembly Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<programlisting>switch(j)
|
|
|
{
|
|
|
case 0:
|
|
|
...
|
|
|
case 1:
|
|
|
...
|
|
|
case 3:
|
|
|
...
|
|
|
default:
|
|
|
...
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
</programlisting>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<programlisting> cmplwi r12, 4
|
|
|
bge .Ldefault
|
|
|
slwi r12, 2
|
|
|
paddi r10, .Ltab@pcrel
|
|
|
lwax r8, r10, r12
|
|
|
add r10, r8, r10
|
|
|
mtctr r10
|
|
|
bctr
|
|
|
.p2align 2
|
|
|
.Ltab:
|
|
|
.word (.Lcase0-.Ltab)
|
|
|
.word (.Lcase1-.Ltab)
|
|
|
.word (.Ldefault-.Ltab)
|
|
|
.word (.Lcase3-.Ltab)</programlisting>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_32686">
|
|
|
<title>Dynamic Stack Space Allocation</title>
|
|
|
<para>When allocated, a stack frame may be grown or shrunk dynamically as
|
|
|
many times as necessary across the lifetime of a function. Standard
|
|
|
calling conventions must be maintained because a subfunction can be
|
|
|
called after the current frame is grown and that subfunction may stack,
|
|
|
grow, shrink, and tear down a frame between dynamic stack frame
|
|
|
allocations of the caller. The following constraints apply when
|
|
|
dynamically growing or shrinking a stack frame:</para>
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Maintain 16-byte alignment.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Stack pointer adjustments shall be performed atomically so that
|
|
|
at all times the value of the back-chain word is valid, when a back
|
|
|
chain is used.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Maintain addressability to the previously allocated local
|
|
|
variables in the presence of multiple dynamic allocations or
|
|
|
conditional allocations.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Ensure that other linkage information is correct, so that the
|
|
|
function can return or its stack space can be deallocated by
|
|
|
exception handling without deallocating any dynamically allocated
|
|
|
space.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
<note>
|
|
|
<para>Using a frame pointer is the recognized method for
|
|
|
maintaining addressability to arguments or local variables. (This may
|
|
|
be a pointer to the top of the stack frame, typically in r31.) For
|
|
|
correct behavior in the cases of setjmp( ) and longjmp( ), the frame
|
|
|
pointer shall be allocated in a nonvolatile general-purpose
|
|
|
register.</para>
|
|
|
</note>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_20151" /> shows the organization of a
|
|
|
stack frame before a dynamic allocation.</para>
|
|
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50655240_20151">
|
|
|
<title>Before Dynamic Stack Allocation</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-42.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
<figure>
|
|
|
<title>Example Code to Allocate n Bytes</title>
|
|
|
<programlisting>#define n 13
|
|
|
; char *a = alloca(n);
|
|
|
; rnd(x) = round x to be multiple of stack alignment
|
|
|
; psave = size of parameter save area (may be zero).
|
|
|
p = 32 + rnd(sizeof(psave)+15); Offset to the start of the dynamic allocation
|
|
|
ld r0,0(r1) ; Load
|
|
|
stdu r0,-rnd(n+15)(r1) ; Store new back chain, quadword-aligned.
|
|
|
addi r3,r1,p ; R3 = new data area following parameter save area.</programlisting>
|
|
|
</figure>
|
|
|
<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 CR save word and the TOC pointer doubleword from
|
|
|
their old locations 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
|
|
|
if the function uses the Reserved word, the LR save doubleword must also
|
|
|
be copied.</para>
|
|
|
<note>
|
|
|
<para>Additional instructions will be necessary for an allocation of
|
|
|
variable size. If a dynamic deallocation will occur, the r1 stack
|
|
|
pointer must be saved before the dynamic allocation, and r1 reset to
|
|
|
that by the deallocation. The deallocation does not need to copy any
|
|
|
stack locations because the old ones should still be valid.</para>
|
|
|
</note>
|
|
|
<para>
|
|
|
<xref linkend="dbdoclet.50655240_24583" /> shows an example organization
|
|
|
of a stack frame after a dynamic allocation.</para>
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50655240_24583">
|
|
|
<title>After Dynamic Stack Allocation</title>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="figures/fig2-44.png" format="PNG" scalefit="1"
|
|
|
width="100%" />
|
|
|
</imageobject>
|
|
|
</mediaobject>
|
|
|
</figure>
|
|
|
</section>
|
|
|
</section>
|
|
|
<section xml:id="dbdoclet.50655240_82998">
|
|
|
<title>DWARF Definition</title>
|
|
|
<para>Although this ABI itself does not define a debugging format, debug
|
|
|
with arbitrary record format (DWARF) is defined here for systems that
|
|
|
implement the DWARF specification. For information about how to locate the
|
|
|
specification, see
|
|
|
<xref linkend="dbdoclet.50655239___RefHeading___Toc377640569" />.</para>
|
|
|
<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 Architecture 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
|
|
|
DWARF. DWARF register numbers 32–63 and 77–108 are also used to
|
|
|
indicate the location of variables in VSX registers vsr0–vsr31 and
|
|
|
vsr32–vsr63, respectively, in DWARF debug information.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_94513">
|
|
|
<title>Mappings of Common Registers</title>
|
|
|
<tgroup cols="4">
|
|
|
<colspec colname="c1" colwidth="25*" align="center" />
|
|
|
<colspec colname="c2" colwidth="25*" align="center" />
|
|
|
<colspec colname="c3" colwidth="25*" align="center" />
|
|
|
<colspec colname="c4" colwidth="25*" align="center" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">DWARF</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Register Number</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Register Name</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Register Width (Bytes)</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>0–31</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>r0–r31</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>32–63</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>f0–f31</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>64</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Reserved</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>N/A</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>65</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>lr</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>66</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>ctr</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>67</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Reserved</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>N/A</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>68–75</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>cr0–cr7</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<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>
|
|
|
</footnote></para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>76</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>xer</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>4</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>77–108</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vr0–vr31</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>16</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>109</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Reserved</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>N/A</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>110</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>vscr</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>111</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Reserved</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>N/A</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>112</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Reserved</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>N/A</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>113</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>Reserved</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>N/A</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>114</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>tfhar</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>115</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>tfiar</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>Reg</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>116</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>texasr</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>8</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
<para>DWARF for the OpenPOWER ABI defines the address class codes described
|
|
|
in
|
|
|
<xref linkend="dbdoclet.50655240_47286" />.</para>
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_47286">
|
|
|
<title>Address Class Codes</title>
|
|
|
<tgroup cols="3">
|
|
|
<colspec colname="c1" colwidth="33*" />
|
|
|
<colspec colname="c2" colwidth="33*" />
|
|
|
<colspec colname="c3" colwidth="33*" />
|
|
|
<thead>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Code</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Value</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>
|
|
|
<emphasis role="bold">Meaning</emphasis>
|
|
|
</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</thead>
|
|
|
<tbody>
|
|
|
<row>
|
|
|
<entry>
|
|
|
<para>ADDR_none</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>0</para>
|
|
|
</entry>
|
|
|
<entry>
|
|
|
<para>No class specified</para>
|
|
|
</entry>
|
|
|
</row>
|
|
|
</tbody>
|
|
|
</tgroup>
|
|
|
</table>
|
|
|
</section>
|
|
|
<section>
|
|
|
<title>Exception Handling</title>
|
|
|
<para>Where exceptions can be thrown or caught by a function, or thrown
|
|
|
through that function, or where a thread can be canceled from within a
|
|
|
function, the locations where nonvolatile registers have been saved must be
|
|
|
described with unwind information. The format of this information is based
|
|
|
on the DWARF call frame information with extensions.</para>
|
|
|
<para>Any implementation that generates unwind information must also
|
|
|
provide exception handling functions that are the same as those described
|
|
|
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">
|
|
|
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
|
|
|
if and only if that instruction is an explicit restore of r2, i.e.,
|
|
|
ld r2,24(r1).
|
|
|
</para>
|
|
|
|
|
|
</section>
|
|
|
</chapter>
|