Preliminary documentation review updates

- Cleanup <emphasis> tags to bold, literal, or superscript as needed in all files
- Update pom.xml to latest level for security and document status values

Signed-off-by: Jeff Scheel <scheel@us.ibm.com>
pull/92/head
Jeff Scheel 8 years ago
parent a8aa923362
commit e099f45c46

@ -6768,7 +6768,7 @@ xml:id="dbdoclet.50655245_pgfId-1138128">
<para>The value of each element is set to the value of an input
element of the concatenated vectors ARG1 and ARG2, with the word
offset to its right
<emphasis>1</emphasis> specified by ARG3, which should be in the
<superscript>1</superscript> specified by ARG3, which should be in the
range 0 - 3.</para>
<para>1. A shift left picks values from the right.</para>
</entry>
@ -6957,7 +6957,7 @@ xml:id="dbdoclet.50655245_pgfId-1138128">
<para>The result is the contents of ARG1, shifted left by the
number of bytes specified by the most-significant nibble of the
least-significant byte
<emphasis>1</emphasis> of ARG2. The bits that are shifted out are
<superscript>1</superscript> of ARG2. The bits that are shifted out are
replaced by zeros.</para>
<para>1. That is, by little-endian bits 7- 5 or big-endian bits
121 - 124.</para>
@ -16719,8 +16719,7 @@ vec_xst_be(result,0, &amp;le_result);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>
<emphasis></emphasis> </para>
<para></para>
</entry>
<entry>
<para>vector bool long long vec_sll (vector bool long long,
@ -16729,8 +16728,7 @@ vec_xst_be(result,0, &amp;le_result);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>
<emphasis></emphasis> </para>
<para> </para>
</entry>
<entry>
<para>vector bool long long vec_sll (vector bool long long,
@ -16739,8 +16737,7 @@ vec_xst_be(result,0, &amp;le_result);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>
<emphasis></emphasis> </para>
<para> </para>
</entry>
<entry>
<para>vector signed long long vec_sll (vector signed long long,
@ -16749,8 +16746,7 @@ vec_xst_be(result,0, &amp;le_result);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>
<emphasis></emphasis> </para>
<para> </para>
</entry>
<entry>
<para>vector signed long long vec_sll (vector signed long long,
@ -16759,8 +16755,7 @@ vec_xst_be(result,0, &amp;le_result);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>
<emphasis></emphasis> </para>
<para> </para>
</entry>
<entry>
<para>vector unsigned long long vec_sll (vector unsigned long
@ -16769,8 +16764,7 @@ vec_xst_be(result,0, &amp;le_result);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>
<emphasis></emphasis> </para>
<para> </para>
</entry>
<entry>
<para>vector unsigned long long vec_sll (vector unsigned long
@ -17002,8 +16996,7 @@ vec_xst_be(result,0, &amp;le_result);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>
<emphasis></emphasis> </para>
<para> </para>
</entry>
<entry>
<para>vector signed long long vec_srl (vector signed long long,
@ -17012,8 +17005,7 @@ vec_xst_be(result,0, &amp;le_result);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>
<emphasis></emphasis> </para>
<para> </para>
</entry>
<entry>
<para>vector signed long long vec_srl (vector signed long long,
@ -17022,8 +17014,7 @@ vec_xst_be(result,0, &amp;le_result);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>
<emphasis></emphasis> </para>
<para> </para>
</entry>
<entry>
<para>vector unsigned long long vec_srl (vector unsigned long
@ -17032,8 +17023,7 @@ vec_xst_be(result,0, &amp;le_result);</programlisting>
</row>
<row revisionflag="added">
<entry>
<para>
<emphasis></emphasis> </para>
<para> </para>
</entry>
<entry>
<para>vector unsigned long long vec_srl (vector unsigned long

@ -182,8 +182,7 @@ xml:id="dbdoclet.50655245_pgfId-1450875" revisionflag="added">
</entry>
<entry>
<para>int __ builtin_bcdsub_ofl (vector unsigned char, vector
unsigned char
<emphasis>)</emphasis>;</para>
unsigned char);</para>
</entry>
</row>
<row>
@ -315,7 +314,7 @@ xml:id="dbdoclet.50655245_pgfId-1450875" revisionflag="added">
<row>
<entry>
<para>
<emphasis>BCD Load and Store</emphasis>
<emphasis role="bold">BCD Load and Store</emphasis>
</para>
</entry>
<entry>

@ -57,8 +57,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<para>A specific OpenPOWER-compliant processor implementation must
state which type of byte ordering is to be used.</para>
<note>
<para>MSR[LE
<emphasis>|</emphasis> SLE]: Although it may be possible to modify the
<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
@ -2547,7 +2546,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</entry>
<entry>
<para>Vector of 16 bytes with a value of either 0 or 2
<emphasis>8</emphasis>- 1.</para>
<superscript>8</superscript>- 1.</para>
</entry>
</row>
<row>
@ -2599,7 +2598,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</entry>
<entry>
<para>Vector of 8 halfwords with a value of either 0 or 2
<emphasis>16</emphasis>- 1.</para>
<superscript>16</superscript>- 1.</para>
</entry>
</row>
<row>
@ -2651,7 +2650,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</entry>
<entry>
<para>Vector of 4 words with a value of either 0 or 2
<emphasis>32</emphasis>- 1.</para>
<superscript>32</superscript>- 1.</para>
</entry>
</row>
<row>
@ -2713,7 +2712,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</entry>
<entry>
<para>Vector of 2 doublewords with a value of either 0 or 2
<emphasis>64</emphasis>- 1.</para>
<superscript>64</superscript>- 1.</para>
</entry>
</row>
<row revisionflag="changed">
@ -3141,8 +3140,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<listitem>
<para>IBM EXTENDED PRECISION form provides the same range as double
precision (about 10
<emphasis>-308</emphasis> to 10
<emphasis>308</emphasis>) but more precision (a variable amount,
<superscript>-308</superscript> to 10
<superscript>308</superscript>) but more precision (a variable amount,
about 31 decimal digits or more).</para>
</listitem>
<listitem>
@ -3322,9 +3321,9 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
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
<emphasis>w - 1</emphasis> to 2
<emphasis>w - 1</emphasis>- 1 and an unsigned range goes from 0 to 2
<emphasis>w</emphasis>- 1.</para>
<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>
@ -4060,7 +4059,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
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
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
@ -4479,7 +4478,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<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>mfocr</emphasis> instructions to one of the following
<emphasis role="bold">mfocr</emphasis> instructions to one of the following
values:</para>
<itemizedlist>
<listitem>
@ -4498,23 +4497,23 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<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
<emphasis>POWER8 Processor User's Manual for the Single-Chip
Module</emphasis>. Instead, it replicates the selected condition
<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>mfocr</emphasis> to avoid corruption of the resulting
<emphasis role="bold">mfocr</emphasis> to avoid corruption of the resulting
(partial) condition register word.</para>
<para>This erratum does not apply to the POWER9 processor.</para>

<para>
<anchor xml:id="dbdoclet.50655240_Power-ISA-version-and-the-user-s-manual"
xreflabel="" /> For more information, see
<emphasis>Power ISA</emphasis>, version 3.0 and "Fixed-Point Invalid
<citetitle>Power ISA</citetitle>, version 3.0 and "Fixed-Point Invalid
Forms and Undefined Conditions" in
<emphasis>POWER9 Processor User's Manual.</emphasis></para>
<citetitle>POWER9 Processor User's Manual.</citetitle></para>
<para>
<anchor xml:id="dbdoclet.50655240_page33" xreflabel="" /> In
OpenPOWER-compliant processors, floating-point and vector functions are
@ -4574,10 +4573,10 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>
<emphasis>...</emphasis>
<emphasis role="bold">...</emphasis>
</para>
<para>
<emphasis>...</emphasis>
<emphasis role="bold">...</emphasis>
</para>
</entry>
<entry nameend="c5" namest="c4" colsep="1">
@ -4646,10 +4645,10 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
<para>
<emphasis>...</emphasis>
<emphasis role="bold">...</emphasis>
</para>
<para>
<emphasis>...</emphasis>
<emphasis role="bold">...</emphasis>
</para>
</entry>
<entry rowsep="0"></entry>
@ -4735,10 +4734,10 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>
<emphasis>...</emphasis>
<emphasis role="bold">...</emphasis>
</para>
<para>
<emphasis>...</emphasis>
<emphasis role="bold">...</emphasis>
</para>
<?dbhtml bgcolor="#EEEEEE" ?>
<?dbfo bgcolor="#EEEEEE" ?>
@ -4792,10 +4791,10 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
</entry>
<entry nameend="c3" namest="c2" align="center">
<para>
<emphasis>...</emphasis>
<emphasis role="bold">...</emphasis>
</para>
<para>
<emphasis>...</emphasis>
<emphasis role="bold">...</emphasis>
</para>
</entry>
<entry rowsep="0"></entry>
@ -5552,7 +5551,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
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 Ritche,
<emphasis>The C Programming Language</emphasis>, 1st
<citetitle>The C Programming Language</citetitle>, 1st
edition).</para>
</listitem>
</itemizedlist>
@ -6727,10 +6726,10 @@ addi r2, r2, .TOC.@l</programlisting>
</itemizedlist>
<para>This ABI shall be used in conjunction with the Power Architecture
that implements the
<emphasis>mfocrf</emphasis> architecture level. Further,
<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>mfocrf</emphasis> results with an OR instruction; for example,
<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
@ -6741,7 +6740,7 @@ 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>mfocrf</emphasis> instruction is performed.</para>
<emphasis role="bold">mfocrf</emphasis> instruction is performed.</para>
<para>&#160;</para>
<bridgehead>Assembly Language Syntax for Defining Entry
Points</bridgehead>
@ -7522,7 +7521,7 @@ stw r0,0,(r7)</programlisting>
</listitem>
</itemizedlist>
<para>If the instruction using symbol@got@
<emphasis>l</emphasis> has a signed immediate operand (for example,
<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

@ -4219,7 +4219,7 @@ ld r3,x@got@l(r3)</programlisting>
<para> </para>
<note>
<para>
<emphasis>Note:</emphasis> If X is a variable stored in the TOC,
<emphasis role="bold">Note:</emphasis> 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>
@ -4230,7 +4230,7 @@ ld r3,x@got@l(r3)</programlisting>
<programlisting>addis 2,12,.TOC.-func@ha
addi 2,2,.TOC.-func@l</programlisting>
<para>The syntax
<emphasis>SYMBOL@localentry</emphasis> refers to the value of the local
<literal>SYMBOL@localentry</literal> refers to the value of the local
entry point associated with a function symbol. It can be used to
initialize a memory word with the address of the local entry point as
follows:</para>
@ -4345,7 +4345,7 @@ addi r4, r4, lower</programlisting>
<section xml:id="dbdoclet.50655241_90241">
<title>Thread Local Storage ABI</title>
<para>The
<emphasis>ELF Handling for Thread-Local Storage</emphasis> document is the
<citetitle>ELF Handling for Thread-Local Storage</citetitle> document is the
authoritative TLS ABI specification that defines the context in which
information in the TLS section of this Power Architecture 64-bit ELF V2 ABI
must be viewed. For information about how to access this document, see
@ -6754,11 +6754,11 @@ nop</programlisting>
<section>
<title>Traceback Tables</title>
<para>To support debuggers and exception handlers, the 64-bit
<emphasis>OpenPOWER ELF V2 ABI</emphasis> defines the use of descriptive
<citetitle>OpenPOWER ELF V2 ABI</citetitle> defines the use of descriptive
debug and unwind information that enables flexible debugging and
unwinding of optimized code (such as, for example, DWARF).</para>
<para>To support legacy tooling, the
<emphasis>OpenPOWER ELF V2 ABI</emphasis> also specifies the use of a
<citetitle>OpenPOWER ELF V2 ABI</citetitle> also specifies the use of a
traceback table that may provide additional information about
functions.</para>
<para>

@ -603,7 +603,7 @@ AT_SYSINFO_EHDR 33 /* In many architectures, the kernel
If the AT_PHDR entry is present, entries of types AT_PHENT, AT_PHNUM, and
AT_ENTRY must also be present. See the Program Header section in Chapter
5 of the
<emphasis>System V ABI</emphasis> for more information about the program
<citetitle>System V ABI</citetitle> for more information about the program
header table.</para>
<para>AT_PHENT</para>
<para>The a_val member of this entry holds the size, in bytes, of one
@ -620,7 +620,7 @@ AT_SYSINFO_EHDR 33 /* In many architectures, the kernel
<para>The a_ptr member of this entry holds the base address at which the
interpreter program was loaded into memory. See the Program Header
section in Chapter 5 of the
<emphasis>System V ABI</emphasis> for more information about the base
<citetitle>System V ABI</citetitle> for more information about the base
address.</para>
<para>AT_FLAGS</para>
<para>If present, the a_val member of this entry holds 1-bit flags. Bits

@ -342,26 +342,12 @@ xml:id="dbdoclet.50655243_pgfId-1099317">
handles data streams that are detected by the hardware and defined by the
software. For more information, see “Data Stream Control Overview, ABI, and
API” at the following link:</para>
<para>
<emphasis>
<link xl:href="https://github.com/paflib/paflib/wiki/Data-Stream-Control-Overview,-ABI,-and-API">

<citetitle>
https://github.com/paflib/paflib/wiki/Data-Stream-Control-Overview,-ABI,-and-API</citetitle>
</link>
</emphasis>
<para><link xl:href="https://github.com/paflib/paflib/wiki/Data-Stream-Control-Overview,-ABI,-and-API">https://github.com/paflib/paflib/wiki/Data-Stream-Control-Overview,-ABI,-and-API</link>
</para>
<para>The event-based branching facility generates exceptions when certain
criteria are met. For more information, see the “Event Based Branching
Overview, ABI, and API” section at the following link:</para>
<para>
<emphasis>
<link xl:href="https://github.com/paflib/paflib/wiki/Event-Based-Branching----Overview,-ABI,-and-API">

<citetitle>
https://github.com/paflib/paflib/wiki/Event-Based-Branching----Overview,-ABI,-and-API</citetitle>
</link>
</emphasis>
<para><link xl:href="https://github.com/paflib/paflib/wiki/Event-Based-Branching----Overview,-ABI,-and-API">https://github.com/paflib/paflib/wiki/Event-Based-Branching----Overview,-ABI,-and-API</link>
</para>
</section>
</chapter>

@ -131,7 +131,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
<para>Consequently, the vector numbering schemes can be described as
big-endian and little-endian vector layouts and vector element numberings.
(The term “endian” comes from the endian debates presented in
<emphasis>Gulliver's Travels</emphasis> by Jonathan Swift.)</para>
<citetitle>Gulliver's Travels</citetitle> by Jonathan Swift.)</para>
<para>For internal consistency, in the ELF V2 ABI, the default vector
layout and vector element ordering in big-endian environments shall be big
endian, and the default vector layout and vector element ordering in
@ -573,7 +573,7 @@ register vector double vd = vec_splats(*double_ptr);</programlisting>
</tgroup>
</table>
<note>
<para><emphasis>Reminder</emphasis>: The assignment operator = is the
<para><emphasis role="bold">Reminder</emphasis>: The assignment operator = is the
preferred way to assign values from one vector data type to
another vector data type in accordance with the C and C++
programming languages.</para>

@ -75,34 +75,45 @@
<!-- TODO: Rename the pdfFilenameBase field to the PDF name for new document -->
<pdfFilenameBase>leabi</pdfFilenameBase>

<!-- TODO: If the document is not yet public, uncomment one of the following statements to create
a vertical running ribbon on the internal margin of the security status in all CAPS.
Values and definitions are formally defined by the IPR policy. A layman's definition follows:

working = typically new document within a work group that has not yet been reviewed
and/or approved for internal or external use.
internal = document that has been previously approved by a workgroup for internal use.
review = document that is under review
writeronly = document that has been created solely for the purpose of the writer (not in IPR policy)

The appropriate starting security for a new document is "working".

Note, the value of "external" is the same as specifying no status. -->
<!-- security>review</security -->
<security>working</security>
<!-- security>internal</security -->
<!-- security>writeronly</security -->
<!-- security>external</security -->

<!-- TODO: Define the appropriate work product type. These values are defined by the IPR Policy.
Consult with the Work Group Chair or a Technical Steering Committee member if you have
questions about which value to select.
If no value is provided below, the document will default to "Work Group Notes".-->
<!-- workProduct>workgroupNotes</workProduct -->
<workProduct>workgroupSpecification</workProduct>
<!-- workProduct>candidateStandard</workProduct -->
<!-- workProduct>openpowerStandard</workProduct -->

<!-- TODO: Set the appropriate security policy for the document. For documents
which are not "public" this will affect the document title page and
create a vertical running ribbon on the internal margin of the
security status in all CAPS. Values and definitions are formally
defined by the IPR policy. A layman's definition follows:

public = this document may be shared outside the
foundation and thus this setting must be
used only when completely sure it allowed
foundationConfidential = this document may be shared freely with
OpenPOWER Foundation members but may not be
shared publicly
workgroupConfidential = this document may only be shared within the
work group and should not be shared with
other Foundation members or the public

The appropriate starting security for a new document is "workgroupConfidential". -->
<!-- security>workgroupConfidential</security -->
<security>foundationConfidential</security>
<!-- security>public</security -->

<!-- TODO: Set the appropriate work flow status for the document. For documents
which are not "published" this will affect the document title page
and create a vertical running ribbon on the internal margin of the
security status in all CAPS. Values and definitions are formally
defined by the IPR policy. A layman's definition follows:

published = this document has completed all reviews and has
been published
draft = this document is actively being updated and has
not yet been reviewed
review = this document is presently being reviewed

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

</configuration>
</execution>

Loading…
Cancel
Save