Round 2 documentation review updates

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

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

Signed-off-by: Jeff Scheel <scheel@us.ibm.com>
master
Jeff Scheel 8 years ago
parent 2cb6450f10
commit 5eba3e1cb1

File diff suppressed because it is too large Load Diff

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

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


File diff suppressed because it is too large Load Diff

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

<section xml:id="dbdoclet.50655241_19147">
<title>TOC Pointer Usage</title>
<para>To enable linker-based optimizations when global data is accessed,
@ -4320,6 +4318,8 @@ target:
rewrite address references created using GOT-indirect loads and bl+4
sequences to use TOC-relative address computation.</para>
</section>
</section>
<section>
<title>Fusion</title>
<para>Code generation in compilers, linkers, and by programmers should
@ -4426,14 +4426,14 @@ addi r4, r4, lower</programlisting>
tlsoffset(m + 1) = round(tlsoffset(m) + tlssize(m), align(m + 1))</programlisting>
<itemizedlist>
<listitem>
<para>The function round() returns its first argument rounded up to
<para>The function round( ) returns its first argument rounded up to
the next multiple of its second argument:</para>
</listitem>
</itemizedlist>
<programlisting>round(x, y) = y × ceiling(x / y)</programlisting>
<itemizedlist>
<listitem>
<para>The function ceiling() returns the smallest integer greater
<para>The function ceiling( ) returns the smallest integer greater
than or equal to its argument, where n is an integer satisfying: n -
1 &lt; x ≤ n:</para>
</listitem>
@ -4441,9 +4441,9 @@ tlsoffset(m + 1) = round(tlsoffset(m) + tlssize(m), align(m + 1))</programlistin
<programlisting>ceiling(x) = n</programlisting>
<para>In the case of dynamic shared objects (DSO), TLS blocks are
allocated on an as-needed basis, with the details of allocation
abstracted away by the __tls_get_addr() function, which is used to
abstracted away by the __tls_get_addr( ) function, which is used to
retrieve the address of any TLS variable.</para>
<para>The prototype for the __tls_get_addr() function, is defined as
<para>The prototype for the __tls_get_addr( ) function, is defined as
follows.</para>
<programlisting>typedef struct
{
@ -4514,7 +4514,7 @@ extern void *__tls_get_addr (tls_index *ti);</programlisting>
code model, which is the default for the ELF V2 ABI.</para>
</note>
<para>Given the following code fragment, to determine the address of a
thread-local variable x, the __tls_get_addr() function is called with one
thread-local variable x, the __tls_get_addr( ) function is called with one
parameter. That parameter is a pointer to a data object of type
tls_index.</para>
<programlisting>extern __thread unsigned int x;
@ -5717,8 +5717,7 @@ static __thread unsigned int x3;
the following code, which makes no reference to GOT entries. The GOT
entries in
<xref linkend="dbdoclet.50655241_16273" /> can be removed from the GOT by
the linker when performing this code transformation.
<footnote xml:id="pgfId-1134055">
the linker when performing this code transformation.<footnote xml:id="pgfId-1134055">
<para>To further optimize the code in
<xref linkend="dbdoclet.50655241_16273" />, a linker may reschedule the
sequence to exploit fusion by generating a sequence that may be fused
@ -6251,7 +6250,7 @@ nop</programlisting>
<para>
<orderedlist>
<listitem xml:id="dbdoclet.50655241_21152">
<para>1. The linker may prefer to schedule the addis and
<para>The linker may prefer to schedule the addis and
addi to be adjacent to take advantage of fusion as a
microarchitecture optimization opportunity.</para>
</listitem>
@ -6703,7 +6702,7 @@ nop</programlisting>
<para>The result of performing a relocation for a TLS symbol is the
module ID and its offset within the TLS block. These are then stored in
the GOT. Later, they are obtained by the dynamic linker at run-time and
passed to __tls_get_addr(), which returns the address for the variable
passed to __tls_get_addr( ), which returns the address for the variable
for the current thread.</para>
<para>For more information, see
<xref linkend="dbdoclet.50655241_18894" />. For TLS relocations, see

@ -141,7 +141,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</tgroup>
</table>
<note>
<para>Note: For the PT_LOAD entry describing the data segment, the
<para>For the PT_LOAD entry describing the data segment, the
p_memsz may be greater than the p_filesz. The difference is the size of
the .bss section. On implementations that use virtual memory file
mapping, only the portion of the file between the .data p_offset
@ -152,7 +152,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
data through p_vaddr + p_memsz.</para>
</note>
<para>
<xref linkend="dbdoclet.50655242_44623" /> demonstrates a typical mapping of
<xref linkend="dbdoclet.50655242_45730" /> demonstrates a typical mapping of
file to memory segments.</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50655242_45730">
<title>Memory Segment Mappings</title>
@ -341,8 +341,8 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
argument passing. For example, a C program might typically issue the
following declaration to begin executing at the local entry point of a
function named main:</para>
<programlisting revisionflag="changed">extern int main (int argc, char *argv[], char *envp[], void *auxv[]);
int main(int argc, char *argv[], char *envp[], ElfW(auxv_t) *auxvec)</programlisting>
<programlisting revisionflag="changed">extern int main (int argc, char *argv[ ], char *envp[ ], void *auxv[ ]);
int main(int argc, char *argv[ ], char *envp[ ], ElfW(auxv_t) *auxvec)</programlisting>
<para>where:</para>
<itemizedlist mark="none">
<listitem>
@ -366,11 +366,9 @@ int main(int argc, char *argv[], char *envp[], ElfW(auxv_t) *auxvec)</programlis
</itemizedlist>
<para>This section explains how to implement the call to main or to the
entry point.</para>
</section>

<section xml:id="dbdoclet.50655242___RefHeading___Toc377640653">
<title>Registers
<anchor xml:id="dbdoclet.50655242_PROC-REG"
xreflabel="" /> Registers</title>
<title xml:id="dbdoclet.50655242_PROC-REG">Registers</title>
<para>The contents of most registers are
<emphasis>not</emphasis> specified when a process is first entered from an
exec system call. A program should not expect the operating system to set
@ -527,7 +525,7 @@ int main(int argc, char *argv[], char *envp[], ElfW(auxv_t) *auxvec)</programlis
</itemizedlist>
<para>This initialization must be completed before any library
initialization codes are run and before control is transferred to the
main program (main()).</para>
main program (main( )).</para>
</section>
<section xml:id="dbdoclet.50655242_83727">
<title>Process Stack</title>
@ -551,7 +549,7 @@ int main(int argc, char *argv[], char *envp[], ElfW(auxv_t) *auxvec)</programlis
{
long a_val;
void *a_ptr;
void (*a_fcn)();
void (*a_fcn)( );
} a_un;
} auxv_t;
@ -571,7 +569,7 @@ AT_EGID 14 /* Effective group ID (egid) */
AT_PLATFORM 15 a_ptr /* String identifying platform. */
AT_HWCAP 16 a_val /* Machine-dependent hints about
processor capabilities. */
AT_CLKTCK 17 /* Frequency of times(), always 100 */
AT_CLKTCK 17 /* Frequency of times( ), always 100 */
AT_DCACHEBSIZE 19 a_val /* Data cache block size */
AT_ICACHEBSIZE 20 a_val /* Instruction cache block size */
AT_UCACHEBSIZE 21 a_val /* Unified cache block size */
@ -699,6 +697,8 @@ PPC_FEATURE2_HAS_VCRYPTO 0x02000000 /* The processor implements the
information block.</para>
</section>
</section>
</section>
<section>
<title>Dynamic Linking</title>
<section xml:id="dbdoclet.50655242___RefHeading___Toc377640656">
@ -709,8 +709,7 @@ PPC_FEATURE2_HAS_VCRYPTO 0x02000000 /* The processor implements the
</section>
<section>
<title>Dynamic Section</title>
<para>
<anchor xml:id="dbdoclet.50655242_page119" xreflabel="" /> The dynamic
<para><anchor xml:id="dbdoclet.50655242_page119" xreflabel="" />The dynamic
section provides information used by the dynamic linker to manage
dynamically loaded shared objects, including relocation, initialization,
and termination when loaded or unloaded, resolving dependencies on other
@ -877,7 +876,7 @@ PPC_FEATURE2_HAS_VCRYPTO 0x02000000 /* The processor implements the
stored in the file image. The individual PLT entries are populated by the
dynamic linker using one of the following binding methods. Execution can
then be redirected to a dependent shared object or executable.</para>
</section>

<section>
<title>Lazy Binding</title>
<para>The lazy binding method is the default. It delays the resolution of
@ -929,7 +928,7 @@ PPC_FEATURE2_HAS_VCRYPTO 0x02000000 /* The processor implements the
<programlisting>tocsaveloc:
nop
...
bl target
bl target
.reloc ., R_PPC64_TOCSAVE, tocsaveloc
nop</programlisting>
<orderedlist>
@ -956,23 +955,22 @@ bl target
func@plt@toc is less than 32 KB, the call stub may be simplified to omit
the addis):</para>
<programlisting>std r2,24(r1)
addis r12,r2,func@plt@toc@ha
ld r12,func@plt@toc@l(r12)
mtctr r12
bctr</programlisting>
addis r12,r2,func@plt@toc@ha
ld r12,func@plt@toc@l(r12)
mtctr r12
bctr</programlisting>
<para>For case 2, the same implementation as for case 1 may be used,
except that the first instruction “std r2,24(r1)” is omitted:</para>
<programlisting>addis r12,r2,func@plt@toc@ha
ld r12,func@plt@toc@l(r12)
mtctr r12
bctr</programlisting>
<para>
<anchor xml:id="dbdoclet.50655242___DdeLink__61883_1749258592"
xreflabel="" /> A possible implementation for case 3 looks as
ld r12,func@plt@toc@l(r12)
mtctr r12
bctr</programlisting>
<para><anchor xml:id="dbdoclet.50655242___DdeLink__61883_1749258592"
xreflabel="" />A possible implementation for case 3 looks as
follows:</para>
<programlisting> mflr r0
bcl 20,31,1f
1: mflr r2
1: mflr r2
mtlr r0
addis r2,r2,(.TOC.-1b)@ha
addi r2,r2,(.TOC.-1b)@l
@ -983,9 +981,9 @@ bctr</programlisting>
<para>When generating non-PIC code for the small or medium code model, a
simpler variant may alternatively be used for cases 2 or 3:</para>
<programlisting>lis r12,func@plt@ha
ld r12,func@plt@l(r12)
mtctr r12
bctr</programlisting>
ld r12,func@plt@l(r12)
mtctr r12
bctr</programlisting>
<para>To support lazy binding, the link editor also provides a set of
symbol resolver stubs, one for each PLT entry. Each resolver stub
consists of a single instruction, which is usually a branch to a common
@ -1014,12 +1012,12 @@ bctr</programlisting>
<programlisting> # ABI note: At entry to the resolver stub:
# - r12 holds the address of the res_N stub for the target routine
# - all argument registers hold arguments for the target routine
PLTresolve:
PLTresolve:
# Determine addressability. This sequence works for both PIC
# and non-PIC code and does not rely on presence of the TOC pointer.
mflr r0
bcl 20,31,1f
1: mflr r11
1: mflr r11
mtlr r0
# Compute .plt section index from entry point address in r12
# .plt section index is placed into r0 as argument to the resolver
@ -1045,15 +1043,15 @@ PLTresolve:
# Constant pool holding offset to the PLT
# Note that there is no actual symbol PLT; the link editor
# synthesizes this value when creating the .glink section
PLToffset:
PLToffset:
.quad PLT-.
# A table of branches, one for each PLT entry
# The idea is that the PLT call stub loads r12 with these
# addresses, so (r12 - res_0) gives the PLT index × 4.
res_0: b PLTresolve
res_1: b PLTresolve
res_0: b PLTresolve
res_1: b PLTresolve
...</programlisting>
<para>After resolution, the value of a PLT entry in the PLT is the
address of the functions global entry point, unless the resolver can
@ -1062,4 +1060,6 @@ res_1: b PLTresolve
<para> </para>
</section>
</section>
</section>

</chapter>

@ -17,7 +17,7 @@ xml:id="dbdoclet.50655243_pgfId-1099317">
<para />
<section xml:id="dbdoclet.50655243___RefHeading___Toc377640667">
<title>Malloc Routine Return Pointer Alignment</title>
<para>The malloc() routine must always return a pointer with the
<para>The malloc( ) routine must always return a pointer with the
alignment of the largest alignment needed for loads and stores of the
built-in data types. This is currently 16 bytes.</para>
</section>
@ -195,8 +195,7 @@ xml:id="dbdoclet.50655243_pgfId-1099317">
<entry>
<para>__PPC64__</para>
<para>__powerpc64__</para>
<para>__64BIT__
<footnote xml:id="pgfId-1101811">
<para>__64BIT__<footnote xml:id="pgfId-1101811">
<para>Phased in.</para>
</footnote></para>
</entry>

@ -60,7 +60,7 @@ xml:id="dbdoclet.50655244_pgfId-1095944">
alignment.</para>
<para>The preferred way to access vectors at an application-defined address
is by using vector pointers and the C/C++ dereference operator *. Similar
to other C /C++ data types, the array reference operator [] may be used to
to other C /C++ data types, the array reference operator [ ] may be used to
access vector objects with a vector pointer with the usual definition to
access the n-th vector element from a vector pointer. The use of vector
built-in functions such as vec_xl and vec_xst is discouraged except for
@ -136,7 +136,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
layout and vector element ordering in big-endian environments shall be big
endian, and the default vector layout and vector element ordering in
little-endian environments shall be little endian.</para>
<para>This element numbering shall also be used by the [] accessor method
<para>This element numbering shall also be used by the [ ] accessor method
to vector elements provided as an extension of the C/C++ languages by some
compilers, as well as for other language extensions or library constructs
that directly or indirectly refer to elements by their element
@ -203,9 +203,9 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<table frame="all" pgwide="1" xml:id="dbdoclet.50655244_35023">
<title>Endian-Sensitive Operations</title>
<tgroup cols="3">
<colspec colname="c1" colwidth="15*" align="center" />
<colspec colname="c2" colwidth="35*" align="center" />
<colspec colname="c3" colwidth="50*" />
<colspec colname="c1" colwidth="25*" align="center" />
<colspec colname="c2" colwidth="30*" align="center" />
<colspec colname="c3" colwidth="45*" />
<thead>
<row>
<entry>
@ -274,8 +274,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>vec_extract_fp32_</para>
<para>from_shorth</para>
<para>vec_extract_fp32_from_shorth</para>
</entry>
<entry>
<para> </para>
@ -286,8 +285,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>vec_extract_fp32_</para>
<para>from_shortl</para>
<para>vec_extract_fp32_from_shortl</para>
</entry>
<entry>
<para> </para>
@ -310,8 +308,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>vec_first_match</para>
<para>_index</para>
<para>vec_first_match_index</para>
</entry>
<entry>
<para> </para>
@ -322,8 +319,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>vec_first_match</para>
<para>_index_or_eos</para>
<para>vec_first_match_index_or_eos</para>
</entry>
<entry>
<para> </para>
@ -364,8 +360,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<para>vmrgew</para>
</entry>
<entry>
<para>Swap inputs and use vmrgow for LE. Phased in.
<footnote xml:id="pgfId-1105723">
<para>Swap inputs and use vmrgow for LE. Phased in.<footnote xml:id="pgfId-1105723">
<para>This optional function is being phased in, and it may not
be available on all implementations.</para>
</footnote></para>
@ -401,8 +396,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<para>vmrgow</para>
</entry>
<entry>
<para>Swap inputs and use vmrgew for LE. Phased in.
<footnoteref linkend="pgfId-1105723" /> </para>
<para>Swap inputs and use vmrgew for LE. Phased in.<footnoteref linkend="pgfId-1105723" /> </para>
</entry>
</row>
<row>
@ -754,8 +748,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xlw4
<footnote xml:id="dbdoclet.50655244_73052"><para>
<para>vec_xlw4<footnote xml:id="dbdoclet.50655244_73052"><para>
Deprecated. The use of vector data type
assignment and overloaded vec_xl and vec_xst vector
built-in functions are preferred forms for assigning
@ -774,8 +767,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xld2
<footnoteref linkend="dbdoclet.50655244_73052"/>
<para>vec_xld2<footnoteref linkend="dbdoclet.50655244_73052"/>
</para>
</entry>
<entry>
@ -798,8 +790,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xstw4
<footnoteref linkend="dbdoclet.50655244_73052"/>
<para>vec_xstw4<footnoteref linkend="dbdoclet.50655244_73052"/>
</para>
</entry>
<entry>
@ -811,8 +802,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xstd2
<footnoteref linkend="dbdoclet.50655244_73052"/>
<para>vec_xstd2<footnoteref linkend="dbdoclet.50655244_73052"/>
</para>
</entry>
<entry>
@ -1173,8 +1163,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xlw<phrase revisionflag="added">4</phrase>
<footnote xml:id="dbdoclet.50655244_78719">
<para>vec_xlw<phrase revisionflag="added">4</phrase><footnote xml:id="dbdoclet.50655244_78719">
<para>Deprecated. The use of vector data type
assignment and overloaded vec_xl and vec_xst vector
built-in functions are preferred forms for assigning
@ -1193,8 +1182,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xld2
<footnoteref linkend="dbdoclet.50655244_78719"/>
<para>vec_xld2<footnoteref linkend="dbdoclet.50655244_78719"/>
</para>
</entry>
<entry>
@ -1219,8 +1207,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xstw4
<footnoteref linkend="dbdoclet.50655244_78719"/>
<para>vec_xstw4<footnoteref linkend="dbdoclet.50655244_78719"/>
</para>
</entry>
<entry>
@ -1232,8 +1219,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
<row>
<entry>
<para>vec_xstd2
<footnoteref linkend="dbdoclet.50655244_78719"/>
<para>vec_xstd2<footnoteref linkend="dbdoclet.50655244_78719"/>
</para>
</entry>
<entry>
@ -1295,6 +1281,53 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</row>
</thead>
<tbody>
<row revisionflag="added">
<entry>
<para>VEC_CONCAT (ARG1, ARG2)<?linebreak?>(Fortran)</para>
<para></para>
</entry>
<entry>
<para>Purpose:</para>
<para>Concatenates two elements to form a vector.</para>
<para>Result value:</para>
<para>The resulting vector consists of the two scalar elements,
ARG1 and ARG2, assigned to elements 0 and 1 (using the
environments native endian numbering), respectively.</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Note: </emphasis>This function corresponds to the C/C++ vector
constructor (vector type){a,b}. It is provided only for
languages without vector constructors.</para>
</listitem>
</itemizedlist>
</entry>
</row>
<row revisionflag="added">
<entry>
<para></para>
</entry>
<entry>
<para>vector signed long long vec_concat (signed long long,
signed long long);</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para></para>
</entry>
<entry>
<para>vector unsigned long long vec_concat (unsigned long long,
unsigned long long);</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para></para>
</entry>
<entry>
<para>vector double vec_concat (double, double);</para>
</entry>
</row>
<row>
<entry>
<para>VEC_CONVERT(V, MOLD)</para>

Loading…
Cancel
Save