awesome-cpus/SPARC/errata-v9.html
2016-05-03 13:29:28 +02:00

1653 lines
86 KiB
HTML

<html>
<head>
<title>SPARC International, Inc. - V9 </title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">
<!--
.bodytext { font-family: Arial, Helvetica, sans-serif; font-size: 10pt}
.subheader { font-family: Arial, Helvetica, sans-serif; font-size: 14pt; font-weight: bold}
-->
</style>
<SCRIPT LANGUAGE="JavaScript1.2" SRC="menu.js"></SCRIPT>
<SCRIPT LANGUAGE="JavaScript1.2" SRC="sparcmenus.js"></SCRIPT>
<script language="JavaScript">
<!--
function MM_displayStatusMsg(msgStr) { //v2.0
status=msgStr;
document.MM_returnValue = true;
}
//-->
</script>
<SCRIPT language=JavaScript>
<!-- Begin
function leapto(form) {
var myindex=form.dest.selectedIndex
location.href=(form.dest.options[myindex].value);
}
// End -->
</SCRIPT>
</head>
<BODY bgColor=#ffffff leftMargin=9 topMargin=9 MARGINHEIGHT="0" MARGINWIDTH="0" link="#0000FF" vlink="#FF3300" alink="#FF9900">
<table width="619" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="163" valign="top">
<table width="163" border="0" cellspacing="0" cellpadding="0">
<tr>
<td><a href="http://www.sparc.org"><img src="/images/template_lsparc_logo.jpg" width="163" height="169" border="0"></a></td>
</tr>
<tr>
<td>
<table width="100" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="86" valign="top">
<table width="86" border="0" cellspacing="0" cellpadding="0">
<tr align="right">
<td height="18">&nbsp;</td>
</tr>
<tr align="right">
<td><a href="http://www.sparc.org/about.shtml" onMouseOver="MM_displayStatusMsg('Company Profile');return document.MM_returnValue"><img src="/images/toc_company_profile1.gif" width="74" height="20" border="0"></a></td>
</tr>
<tr align="right">
<td><a href="http://www.sparc.org/trademark.shtml" onMouseOver="MM_displayStatusMsg('SPARC Trademarks');return document.MM_returnValue"><img src="/images/toc_tradem1.gif" width="86" height="22" border="0"></a></td>
</tr>
<tr align="right">
<td><A HREF="http://www.sparc.org/members.html" onMouseOver="window.showMenu('members', 110, 244);MM_displayStatusMsg('SPARC Members');return document.MM_returnValue"><img src="/images/toc_members1.gif" width="75" height="22" border="0"></a></td>
</tr>
<tr align="right">
<td><A HREF="http://www.sparc.org/certified.html" onMouseOver="window.showMenu('products', 110, 266);MM_displayStatusMsg('SPARC Certified Products');return document.MM_returnValue"><img src="/images/toc_cert_products1.gif" width="73" height="34" border="0"></a></td>
</tr>
<tr align="right">
<td><a href="http://www.sparc.org/shop.html" onMouseOver="MM_displayStatusMsg('SPARCshop');return document.MM_returnValue"><img src="/images/toc_sparc_shop1.gif" width="53" height="24" border="0"></a></td>
</tr>
<tr align="right">
<td><a href="http://www.sparc.org/standards.html" onMouseOver="MM_displayStatusMsg('Downloads from SPARC standards');return document.MM_returnValue"><img src="/images/toc_download1.gif" width="77" height="33" border="0"></a></td>
</tr>
<tr align="right">
<td><a href="http://www.sparc.org/sf.htm" onMouseOver="MM_displayStatusMsg('SPARC-flash News');return document.MM_returnValue"><img src="/images/toc_flash_news1.gif" width="81" height="24" border="0"></a></td>
</tr>
<tr align="right">
<td><a href="http://www.sparc.org/map.shtml" onMouseOver="MM_displayStatusMsg('Site Map');return document.MM_returnValue"><img src="/images/toc_sitemap1.gif" width="39" height="23" border="0"></a></td>
</tr>
</table>
</td>
<td width="14"><img src="/images/template_line_ball.gif" width="14" height="254"></td>
</tr>
</table>
</td>
</tr>
</table>
</td>
<td width="456" valign="top">
<table width="456" border="0" cellspacing="0" cellpadding="0">
<tr>
<td height="44"></td>
</tr>
<tr>
<td height="30">
<table width="456" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="438" height="30">
<div align="right"></div>
</td>
<td width="18" height="30"></td>
</tr>
</table>
</td>
</tr>
<tr>
<td><img src="/images/template_slogan.jpg" width="456" height="26"></td>
</tr>
<tr align="right" valign="top">
<td>
<table width="432" border="0" cellspacing="0" cellpadding="0">
<tr>
<td height="85"></td>
</tr>
<tr valign="top">
<td>
<!-------------------body text begin ----------------->
<p class="subheader"><font color=#333333>Errata for "The SPARC
Architecture Manual, Version 9&quot;</font></p>
<form name=trade class="bodytext">
</form>
<table width="80%" border="1" cellspacing="0" cellpadding="5" align="center" bgcolor="#FFFFFF">
<tr bgcolor="#FFFFFF">
<td class="bodytext"><b><font color="#000000">The following
is a list of corrections for known errors in "The SPARC
Architecture Manual, Version 9" book. Page number references
are taken from the 1st (1994) printing, R1.4.2 (revision
1.4.2, identified by the text "SAV09R1429309" inside the
front cover), unless otherwise indicated.</font></b></td>
</tr>
</table>
<p><font color="#FF3300"><b><span class="bodytext">[1] Page
212 (second page of the Read State Register description),
4th paragraph from the top is printed as: </span></b></font></p>
<blockquote>
<p class="bodytext">"RDFPRS waits for all pending FPops to
complete before reading the FPRS register." </p>
</blockquote>
<p class="bodytext">It *should* read: </p>
<blockquote>
<p class="bodytext">"RDFPRS waits for all pending FPops **and
loads of floating-point registers** to complete before reading
the FPRS register." </p>
</blockquote>
<p class="bodytext"><font color="#FF3300"><b>[2] Page 234 (Tagged
Add):</b><br>
</font>The "op3" column is incorrect in the Opcode table;
the low-order bit should be "0" for all Tagged-Add instructions.
The table should read: </p>
<table width="80%" border="0" cellspacing="0" cellpadding="0" align="center">
<tr>
<td>
<table width="100%" border="1" cellspacing="0" cellpadding="5">
<tr bgcolor="#FF3300">
<td><font color="#FFFFFF"><b><span class="bodytext">Opcode</span></b></font></td>
<td><font color="#FFFFFF"><b><span class="bodytext">op3</span></b></font></td>
<td><font color="#FFFFFF"><b><span class="bodytext">Operation</span></b></font></td>
</tr>
<tr>
<td class="bodytext">TADDcc</td>
<td class="bodytext">10 0000 ... </td>
<td>&nbsp;</td>
</tr>
<tr>
<td class="bodytext">TADDccTV</td>
<td class="bodytext">10 0010 ... </td>
<td>&nbsp;</td>
</tr>
</table>
</td>
</tr>
<tr>
<td>
<div align="right" class="bodytext"></div>
</td>
</tr>
</table>
<p><span class="bodytext"><font color="#FF3300"><b>[3] Page
80 (subsection 6.3.6.4, RESTORED description):</b><br>
</font>In the last line of the 6.3.6.4, change:<br>
CLEANWIN < NWINDOWS<br>
</span><span class="bodytext">to:<br>
(CLEANWIN < (NWINDOWS-1)) </span></p>
<p class="bodytext"><font color="#FF3300"><b>[4] Page 216 (RESTORED):</b><br>
</font>Third paragraph, last sentence, change <br>
CLEANWIN != NWINDOWS <br>
to: <br>
(CLEANWIN < (NWINDOWS-1)) </p>
<p class="bodytext"><font color="#FF3300"><b>[5] Page 76, Section
6.3.4.[12] (branches): </b></font><br>
A *taken* conditional branch (not just a conditional branch)
should have been referred to in the last sentences of two
subsections. </p>
<p class="bodytext">Change the last sentence in 6.3.4.1, "Conditional
Branches", to: </p>
<blockquote>
<p class="bodytext">Note that the annul behavior of a taken
conditional branch is different from that of an unconditional
branch. </p>
</blockquote>
<p class="bodytext">And change the last sentence in 6.3.4.2,
"Unconditional Branches" to:</p>
<blockquote>
<p class="bodytext"> Note that the annul behavior of a unconditional
branch is is different from that of a taken conditional
branch. </p>
</blockquote>
<p class="bodytext"><font color="#FF3300"><b>[6] Page 290, Section
G, Table 43: </b></font><br>
In the table entries for "cas", "casl", "casx", and "casxl",
the built-in constant names beginning with "ASI" should all
be preceeded by "#" (as they were correctly specified on p.286).
</p>
<p class="bodytext"><font color="#FF3300"><b>[7] Page 242, Write
State Register page:</b></font> <br>
In the Exceptions section: <br>
"WRASR with rs1=16..31" <br>
should read: </p>
<blockquote>
<p class="bodytext">"WRASR with rd=16..31". </p>
</blockquote>
<p class="bodytext"><b><font color="#FF3300">[8] Page 57, subsection
5.2.10 (Register-Window State Registers):</font></b> <br>
A clarification has been added to Section 5, to allow an implementation
with 16 or fewer register windows the option to implement
the CWP, CANSAVE, CANRESTORE, OTHERWIN, and CLEANWIN registers
with fewer than 5 bits each, if desired. The following text
was added:</p>
<p class="bodytext"> IMPL. DEP. #126: Privileged registers CWP,
CANSAVE, CANRESTORE, OTHERWIN, and CLEANWIN contain values
in the range 0..NWINDOWS-1. The effect of writing a value
greater than NWINDOWS-1 to any of these registers is undefined.
Although the width of each of these five registers is nominally
5 bits, the width is implementation-dependent and shall be
bewteen ceil(log2(NWINDOWS)) and 5 bits, inclusive. If fewer
than 5 bits are implemented, the unimplemented upper bits
shall read as 0 and writes to them shall have no effect. All
five registers shall be the same width. </p>
<p class="bodytext"><b><font color="#FF0000">[9] Page 268, Table
32:</font></b><br>
As a privileged instruction, "RDPR" should be listed with
a trailing superscript "P".</p>
<p class="bodytext"> <font color="#FF3300"><b>[10] Pages 58-59,
subsection subsection 5.2.10 (Register-Window State Registers):</b></font>
<br>
Added note to descriptions of CWP, CANSAVE, CANRESTORE, OTHERWIN,
and CLEANWIN registers that the effect of writing a value
to them greater than NWINDOWS-1 is undefined. </p>
<p class="bodytext"><b><font color="#FF3300">[11] Page 81</font></b>:
<br>
In section 6.3.9, "FMOVc" was corrected to read "FMOVr". </p>
<p class="bodytext"><b><font color="#FF3300">[12] Page 81:</font></b>
<br>
In section 6.3.9, a sentence was added stating that FSR.cexc
and FSR.ftt are cleared by FMOVcc and FMOVr whether or not
the move occurs. </p>
<p class="bodytext"><b><font color="#FF3300">[13] Page 171</font></b>,
Annex A: Sentence added specifying that LDFSR does not affect
the upper 32 bits of FSR. </p>
<p class="bodytext"><b><font color="#FF3300">[14] Page 220(r142)/A.49(r142),
third paragraph:</font></b> <br>
The words "the" and "and" were transposed in the implementation
dependency description. It now reads: "The location of the
SIR_enable control flag and the means of accessing the SIR_enable
control flag..." </p>
<p class="bodytext"><b><font color="#FF3300">[15] Page 229</font></b>,
paragraph beginning "Store integer...": "...used for the load..."
changed to "...used for the store...". </p>
<p class="bodytext"><b><font color="#FF3300">[16] Page 231,
Annex A:</font></b> Corrected SWAP deprecation note to recommend
use of "CASA" or "CASXA" (not "CASX") in place of SWAP. </p>
<p class="bodytext"><b><font color="#FF3300">[17] Page 258</font></b>,
D.3.3., rule (1): The text was clarified, to read "(1) The
execution of Y is conditional on X, and S(Y) is true." </p>
<p><span class="bodytext"><b><font color="#FF3300">[18] Page
312, Annex I:</font></b><br>
</span><span class="bodytext">Missing word "not" added to
Compatibility Note: "The coprocessor opcodes were eliminated
because they have not been used in SPARC-V7 and SPARC-V8,
..." ^^^ </span></p>
<p class="bodytext"><b><font color="#FF3300">[19] Page 195,
Annex A: </font></b><br>
Order of instructions in Suggested Assembly Language Syntax
was rearranged to correspond to order of the instructions
in the Opcode/op3/Operation table above it. </p>
<p class="bodytext">"movre" and "movrz", as the assembly-language
mnemonic and its synonym, were exchanged to correspond with
the instruction name of MOVRZ. </p>
<p class="bodytext">"movrne" and "movrnz", as the assembly-language
mnemonic and its synonym, were exchanged to correspond with
the instruction name of MOVRNZ. </p>
<p class="bodytext"><b><font color="#FF3300">[20] Page 228,
Annex A:</font></b></p>
<p class="bodytext"> Order of instructions in Suggested Assembly
Language Syntax was rearranged to correspond to order of the
instructions in the Opcode/op3/Operation table above it. </p>
<p class="bodytext"><b><font color="#FF3300">[21] Page 241,
Annex A: </font></b><br>
Added footnote to Suggested Assembly Language Syntax table,
noting that the suggested syntax for WRASR with rd=16..31
may vary, citing reference to implementation dependency #48.
</p>
<p class="bodytext">(Suggested Assembly Language Syntax is just
that -- *suggested* -- so isn't part of the architecture specification
anyway, but this change makes it clearer that if bits are
interpreted differently in the instruction, one should expect
its assembly-language syntax to change, as well) </p>
<p><span class="bodytext"><b><font color="#FF3300">[22] Page
40, Table 7:</font></b><br>
</span><span class="bodytext"> Changed leftmost column text
as follows: <br>
"Single" to "Single f.p. or 32-bit integer" <br>
"Double" to "Double f.p. or 64-bit integer" <br>
"Quad" to "Quad f.p." <br>
</span></p>
<table width="80%" border="1" cellspacing="0" cellpadding="5" align="center">
<tr>
<td class="bodytext">Corrections 22-57 were incorporated
into R1.4.5, Dec 1999, | | which was to be used for the
2nd printing of the book. | | R1.4.5 (revision 1.4.5)
can be identified by the text | | "SAV09R1429309" inside
the front cover of the book. | | These corrections also
appear in all subsequent revisions.</td>
</tr>
</table>
<p class="bodytext"><b><font color="#FF3300">[23] p.13, subsection
2.57, definition of "reserved": </font></b></p>
<p class="bodytext">Wording: <br>
"...intended to run on future version of" <br>
was corrected to read: <br>
"...intended to run on future versions of". </p>
<p class="bodytext">The sentence beginning "Reserved register
fields" was amend to read: "Reserved register fields should
always be written by software with values of those fields
previously read from that register, or with zeroes; they should
read as zero in hardware." </p>
<p class="bodytext"><b><font color="#FF3300">[24] p.21(r142),
Editor's Notes: </font></b><br>
Added Les Kohn's name to the Acknowledgements. </p>
<p class="bodytext"><b><font color="#FF0000">[25] p.28(r142),
Tables 3,4,5: </font></b><br>
Made use of hyphens & dashes made consistent, and easier to
read. </p>
<p class="bodytext"><b><font color="#FF3300">[26] p.30(r142),
paragraph just above subsection 5.1: </font></b><br>
Changed end of sentence to read: </p>
<p class="bodytext">"...should be written with the values of
those bits previously read from that register, or with zeroes."
</p>
<p class="bodytext"><b><font color="#FF3300">[27] p.40(r142),
Table 7: </font></b><br>
Added lines for 32-bit and 64-bit signed integers in f.p.
registers, for clarity. </p>
<p class="bodytext"><b><font color="#FF3300">[28] p.51, Figure
17: </font></b><br>
Added bits 11..10 to the figure, so it looks like: </p>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td>
<table width="100%" border="1" cellspacing="0" cellpadding="2" class="bodytext">
<tr>
<td class="bodytext">PID1</td>
<td class="bodytext">PID0</td>
<td class="bodytext">CLE</td>
<td class="bodytext">TLE</td>
<td class="bodytext">MM </td>
<td class="bodytext">RED</td>
<td class="bodytext">PEF</td>
<td class="bodytext">AM</td>
<td class="bodytext">PRIV</td>
<td class="bodytext">IE</td>
<td class="bodytext">AG</td>
</tr>
<tr>
<td>11</td>
<td>10</td>
<td>9</td>
<td>8</td>
<td>7</td>
<td>6</td>
<td>5</td>
<td>4</td>
<td>3</td>
<td>2</td>
<td>1</td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="bodytext">\_________/ (changed here) </td>
</tr>
</table>
<p class="bodytext"><b><font color="#FF3300">[29] p.52(r142),
inserted new subsection 5.2.1.1 before old one: </font></b><br>
"IMPL. DEP. #127: The presence and semantics of PSTATE.PID1
and PSTATE.PID0 are implementation-dependent. Software intended
to run on multiple implementations should only write these
bits to values previously read from PSTATE, or to zeroes.
See also TSTATE bits 19..18." </p>
<p><span class="bodytext"><b><font color="#FF3300">[30] p.55(r142),
Figure 22, (TSTATE register): </font></b><br>
Extended the "saved PSTATE" field up through bit 19 of TSTATE;
changed the diagram to look like:</span><span class="bodytext">
</span></p>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td>
<table width="100%" border="1" cellspacing="0" cellpadding="0">
<tr valign="middle" align="center">
<td width="5%">...</td>
<td width="40%" class="bodytext">ASI from TL=x</td>
<td width="10%">---</td>
<td width="40%" class="bodytext">PSTATE from TL=X</td>
<td width="5%">...</td>
</tr>
</table>
</td>
</tr>
<tr>
<td>
<table width="100%" border="0" cellspacing="0" cellpadding="2">
<tr valign="middle" align="center">
<td width="5%">&nbsp;</td>
<td width="40%">
<table width="100%" border="0" cellspacing="0" cellpadding="0" class="bodytext">
<tr>
<td>31</td>
<td>
<div align="right">24</div>
</td>
</tr>
</table>
</td>
<td width="10%">
<table width="100%" border="0" cellspacing="0" cellpadding="0" class="bodytext">
<tr>
<td>23</td>
<td>
<div align="right">20</div>
</td>
</tr>
</table>
</td>
<td width="40%">
<table width="100%" border="0" cellspacing="0" cellpadding="0" class="bodytext">
<tr>
<td>19</td>
<td>
<div align="right">8</div>
</td>
</tr>
</table>
</td>
<td width="5%">&nbsp;</td>
</tr>
</table>
</td>
</tr>
<tr>
<td>
<table width="100%" border="0" cellspacing="0" cellpadding="2">
<tr valign="middle" align="center">
<td width="5%">&nbsp;</td>
<td width="40%">&nbsp;</td>
<td colspan="2" class="bodytext">\________/ (changed
here) </td>
<td width="10%">&nbsp;</td>
</tr>
</table>
</td>
</tr>
</table>
<p class="bodytext"><b><font color="#FF3300">[31] p.56(r142):</font></b><br>
Added a new paragraph to the end of subsection 5.2.6:</p>
<blockquote>
<p class="bodytext">"TSTATE bits 19 and 18 are implementation-dependent.
ImplDep#126: If PSTATE bit 11 (10) is implemented, TSTATE
bit 19 (18) shall be implemented and contain the state of
PSTATE bit 11 (10) from the previous trap level. If PSTATE
bit 11 (10) is not implemented, TSTATE bit 19 (18) shall
read as zero. Software intended to run on multiple implementations
should only write these bits to values previously read from
PSTATE, or to zeroes." </p>
</blockquote>
<p class="bodytext"><b><font color="#FF3300">[32] p.57(r142),
subsection 5.2.10 (Register-Window State Registers): Added
implementation dependency #126:</font></b> </p>
<p class="bodytext">IMPL. DEP. #126: Privileged registers CWP,
CANSAVE, CANRESTORE, OTHERWIN, and CLEANWIN contain values
in the range 0..NWINDOWS-1. The effect of writing a value
greater than NWINDOWS-1 to any of these registers is undefined.
Although the width of each of these five registers is nominally
5 bits, the width is implementation-dependent and shall be
between ceil(log2(NWINDOWS)) and 5 bits, inclusive. If fewer
than 5 bits are implemented, the unimplemented upper bits
shall read as 0, and writes to them shall have no effect.
All five registers should have the same width. </p>
<p class="bodytext"><b><font color="#FF3300">[33] pp.58-9(r142),
subsection 5.2.10 (Register-Window State Registers):</font></b>
<br>
Added note to descriptions of CWP, CANSAVE, CANRESTORE, OTHERWIN,
and CLEANWIN registers that the effect of writing a value
to them greater than NWINDOWS-1 is undefined. </p>
<p class="bodytext"><b><font color="#FF3300">[34] p.76, Section
6: <br>
Last sentence in 6.3.4.1, "Conditional Branches" changed to</font></b>:</p>
<p class="bodytext"> Note that the annul behavior of a taken
conditional branch is different from that of an unconditional
branch. </p>
<p class="bodytext">And the last sentence in 6.3.4.2, "Unconditional
Branches" changed to: </p>
<p class="bodytext">Note that the annul behavior of a unconditional
branch is is different from that of a taken conditional branch.</p>
<p class="bodytext"> <b><font color="#FF3300">[35] p.80(r142),
6.3.6.4(r142), RESTORED:</font></b><br>
correct the equation with CLEANWIN to read <br>
"(CLEANWIN < (NWINDOWS-1))". <br>
and correct the text above it. </p>
<p class="bodytext"><b><font color="#FF3300">[36] p.81(r141/r142):
</font></b><br>
In section 6.3.9, "FMOVc" was corrected to read "FMOVr". </p>
<p class="bodytext"><b><font color="#FF3300">[37] p.81(r141/r142):
</font></b><br>
In section 6.3.9, a sentence was added stating the clearing
of FSR.cexc and FSR.ftt during condition moves FMOVcc and
FMOVr: </p>
<p class="bodytext">FMOVcc and FMOVr instructions clear these
FSR fields regardless of the value of the conditional predicate.
</p>
<p class="bodytext"><b><font color="#FF3300">[38] p.121(r141/r142):
</font></b><br>
An index entry for "non-faulting loads" was fixed in section
8.3.</p>
<p class="bodytext"> <font color="#FF3300"><b>[39] p.151(r142),
A.9(r142), Compare and Swap page:</b></font><br>
Added mention of CASL and CASXL to the Programming Note:</p>
<p class="bodytext"> Compare and Swap Little (CASL) and Compare
and Swap Extended Little (CASXL) synthetic instructions are
available for "little endian" memory accesses. </p>
<p class="bodytext"><b><font color="#FF3300">[40] p.171, Annex
A, "Load Floating-Point": </font></b><br>
Sentence added:<br>
The upper 32 bits of FSR are unaffected by LDFSR. </p>
<p class="bodytext"><b><font color="#FF3300">[41] p.181(r141/r142):
</font></b><br>
Section number "A.31" was fixed so it now increments to A.32.
All following section numbers and odd page headers in Annex
A have changed. </p>
<p class="bodytext"><b><font color="#FF3300">[42] p.191(r141/r142):
</font></b><br>
Misspelling corrected in page heading: "Conditon" --> "Condition"
</p>
<p class="bodytext"><b><font color="#FF3300">[43] p.195(r141/r142),
"Move Integer Register on Register Condition (MOVR)":</font></b>
<br>
Order of instructions in Suggested Assembly Language Syntax
was rearranged to correspond to order of the instructions
in the Opcode/op3/Operation table above it. </p>
<p class="bodytext">"movre" and "movrz", as the assembly-language
mnemonic and its synonym, were exchanged to correspond with
the instruction name of MOVRZ. </p>
<p class="bodytext">"movrne" and "movrnz", as the assembly-language
mnemonic and its synonym, were exchanged to correspond with
the instruction name of MOVRNZ.</p>
<p class="bodytext"><b><font color="#FF3300">[44] p.212(r14[123])
A.43(r14[12])/A.44(r144)</font></b>, second page of the Read
State Register instruction descirption, 4th paragraph SHOULD
read:</p>
<p class="bodytext"> "RDFPRS waits for all pending FPops **and
loads of floating-point registers** to complete before reading
the FPRS register." </p>
<p class="bodytext"><b><font color="#FF3300">[45] p.216(r142),
A.46(r142), RESTORED page: </font></b><br>
Correct the equation with CLEANWIN to read </p>
<blockquote>
<p><span class="bodytext">" </span><span class="bodytext">(CLEANWIN
< (NWINDOWS-1))". </span></p>
</blockquote>
<p class="bodytext"><b><font color="#FF3300">[46] p.220(r142)/A.49(r142),
third paragraph: </font></b><br>
The words "the" and "and" were transposed in the implementation
dependency description. It now reads: </p>
<p class="bodytext">"The location of the SIR_enable control
flag and the means of accessing the SIR_enable control flag..."
</p>
<p class="bodytext"><b><font color="#FF3300">[47] p.228(r141/r142):
</font></b><br>
Order of instructions in Suggested Assembly Language Syntax
was rearranged to correspond to order of the instructions
in the Opcode/op3/Operation table above it. </p>
<p class="bodytext"><b><font color="#FF3300">[48] (duplicate
of erratum #15) </font> </b></p>
<p class="bodytext"><b><font color="#FF0000">[49] p.231(r142)/233(r144),
Annex A:</font></b><br>
Corrected SWAP deprecation note to recommend use of "CASA"
or "CASXA" (not "CASX") in place of SWAP. </p>
<p class="bodytext"><b><font color="#FF3300">[50] p.234, A.58(r14[12])/A.59(r144),
Tagged Add: </font></b><br>
op3 opcodes are wrong. Both should have "0" for low-order
bit (as is correctly specified in Appendix E). </p>
<p class="bodytext"><b><font color="#FF0000">[51] p.241(r142),
A.62(r142), Write State Register page:</font></b></p>
<blockquote>
<p class="bodytext"> Added footnote to Suggested Assembly
Language Syntax table, noting that the suggested syntax
for WRASR with rd=16..31 may vary, citing reference to implementation
dependency #48. (Suggested Assembly Language Syntax is just
that -- *suggested* -- so isn't a normative part of the
architecture specification anyway, but this makes it clearer
that if bits are interpreted differently in the instruction,
one should expect its assembly- language syntax to change,
as well) </p>
</blockquote>
<p class="bodytext"><b><font color="#FF3300">[52] p.242(r142),
A.62(r142), Write State Register page</font></b>: <br>
In the Exceptions section, "WRASR with rs1=16..31" now reads
"WRASR with rd=16..31". </p>
<p class="bodytext"><b><font color="#FF3300">[53] p.253(r142),
Annex C:</font></b><br>
Fixed 6 incorrect index entries. </p>
<p class="bodytext"><b><font color="#FF3300">[54] p.253(4142),
Annex C:</font></b><br>
Added a new Implementation Dependency: </p>
<table width="80%" border="1" cellspacing="0" cellpadding="3" align="center" class="bodytext">
<tr bgcolor="#FF3300">
<td><font color="#FFFFFF"><b><span class="bodytext">#</span></b></font></td>
<td><font color="#FFFFFF"><b><span class="bodytext">Cat</span></b></font></td>
<td><font color="#FFFFFF"><b><span class="bodytext">Def/Ref</span></b></font></td>
<td><font color="#FFFFFF"><b><span class="bodytext">Description</span></b></font></td>
</tr>
<tr valign="top">
<td class="bodytext">127</td>
<td>f</td>
<td class="bodytext">52, 56</td>
<td class="bodytext">The presence and semantics of PSTATE.PID1
and PSTATE.PID0 are implementation-dependent. The presence
of TSTATE bits 19 and 18 is implementation-dependent.
If PSTATE bit 11 (10) is implemented, TSTATE bit 19 (18)
shall be implemented and contain the state of PSTATE bit
11 (10) from the previous trap level. If PSTATE bit 11
(10) is not implemented, TSTATE bit 19 (18) shall read
as zero. Software intended to run on multiple implementations
should only write these bits to values previously read
from PSTATE, or to zeroes. </td>
</tr>
</table>
<p class="bodytext"><b><font color="#FF3300">[55] p.255(r142),
Annex C: </font></b><br>
Added implementation dependency #126. <br>
(see correction #31 above for the text of implementation dependency
#126) </p>
<p class="bodytext"><b><font color="#FF0000">[56] p.258(r142),
D.3.3., rule (1): </font></b><br>
The text was clarified, to read:<br>
"(1) The execution of Y is conditional on X, and S(Y) is true."
</p>
<p class="bodytext"><b><font color="#FF3300">[57] p.268(r142),
Table 32: </font></b><br>
As a privileged instruction, "RDPR" should be listed with
a superscripted suffix "P". </p>
<p class="bodytext"><b><font color="#FF3300">[58] p.290(r142),
Section G, Table 43: </font></b><br>
Insert "#" before the "ASI" in the compare-and-swap synthetic
instruction entries.</p>
<table width="80%" border="1" cellspacing="0" cellpadding="5" align="center">
<tr>
<td class="bodytext"><font color="#000000"><b>Corrections
58-on have been incorporated into R1.4.6, which has not
yet been published.</b></font></td>
</tr>
</table>
<p class="bodytext"><b><font color="#FF0000">[59] In Figure
3 in Chapter 6 (p.62)</font></b>, the 4th format description
from the bottom of the page (op,rd,op3,rs1,i=0,--,rs2) contains
an error; "i=0" should read "i=1". </p>
<p class="bodytext"><b><font color="#FF3300">[60] In section
6.3.1,</font></b> "Memory Access Instructions", on p.67, <br>
"and CAS accesses words or doublewords.<br>
" should be amended to read: <br>
"CASA accesses words, and CASXA acesses doublewords." </p>
<p class="bodytext"><b><font color="#FF3300">[61] In section
7.7, the async_data_error exception description should be
updated to read as follows: </font> </b> </p>
<p class="bodytext">async_data_error [tt = 0x040] (Precise,
Deferred, or Disrupting) -- An implementation-dependent exception
(impl. dep. #31) that indicates that one or more unrecoverable
or uncorrectable but recoverable errors have been detected
in the processor. This may include errors detected in the
architectural registers (general-purpose registers, floating-point
registers, ASRs, or ASI registers) and other core processor
hardware. A single async_data_error exception may indicate
multiple errors and may occur asynchronously to instruction
execution. An async_data_error exception may cause a precise,
deferred, or disrupting trap. When async_data_error causes
a disrupting trap, the TPC and TNPC stacked by the trap do
not necessarily indicate the instruction or data access that
caused the error. </p>
<p class="bodytext"><b><font color="#FF3300">[62] The following
text should be added to the second paragraph of section A.27
(p.176), to clarify the behavior of a little-endian doubleword
load (LDD):</font></b></p>
<p class="bodytext">With respect to little endian memory, an
LDD instruction behaves as if it is composed of two 32-bit
loads, each of which is byte swapped independently before
being written into each destination register. </p>
<p class="bodytext"><b><font color="#FF3300">[63] The following
text should be added to the second paragraph of section A.28
(p.178), to clarify the behavior of a little-endian doubleword
load from alternate space (LDDA):</font></b></p>
<p class="bodytext"> With respect to little endian memory, an
LDDA instruction behaves as if it is composed of two 32-bit
loads, each of which is byte swapped independently before
being written into each destination register. </p>
<p class="bodytext"><b><font color="#FF0000">[64] In the Index,
p.354</font></b>, the "signal monitor instruction" index entry
should instead read "software intiated reset (SIR) instruction".
</p>
<p class="bodytext"><b><font color="#FF0000">[65] There is an
error in the definition of CLEANWIN (p.59)</font></b> and
the SAVE instruction that allows the locals of the "invalid"
window to in some cases not be cleaned (zeroed) when it is
allocated by a SAVE instruction. </p>
<p class="bodytext">A software workaround (used in the Solaris
operating system and perhaps others), to keep user registers
clean of kernel data, involves the use of an extra %wstate
value. When the kernel returns to user code, it sets %wstate
to the new value. The new trap table entry for spills with
that %wstate value spills the window as usual but also backs
up a window and performs the missing "clean" operation. The
spill handler then sets %wstate back to the default value
for a user process. </p>
<p class="bodytext"><b><font color="#FF0000">[66] In Chapter
7</font></b>, "Traps", it is implied (but not explicitly stated)
that the value PSTATE.TLE is preserved during traps that cause
entry into RED_state and during XIR, WDR, and SIR resets.
However, PSTATE.TLE may be left in an undefined states by
one of those events. The correction, which applies to sections
7.6.2.1 (p.106), 7.6.2.3 (p.108), 7.6.2.4 (p.109), and 7.6.2.5
(p.110) is to change the little-ending mode settings from:</p>
<p><span class="bodytext"> PSTATE.CLE <-- PSTATE.TLE (set endian
mode for traps)<br>
</span><span class="bodytext"> to: <br>
PSTATE.CLE <-- PSTATE.TLE (set endian mode for traps) <br>
PSTATE.TLE <-- undefined </span></p>
<p><font color="#FF0000"><b><span class="bodytext">[67] In Chapter
5, section 5.1.7.9 (p.48)</span></b></font><span class="bodytext">,
the last sentence of the<br>
third paragraph is inaccurate. The entire third paragraph
should<br>
be replaced with: </span></p>
<p class="bodytext">Floating-point operations which cause an
overflow or underflow condition may also cause an &quot;inexact&quot;
condition. For overflow and underflow conditions, FSR.cexc
bits are set and trapping occurs as follows:</p>
<p class="bodytext">o If an IEEE 754 overflow condition occurs:<br>
<blockquote>
<p class="bodytext"> -- if OFM=0 and NXM=0, the cexc.ofc and
cexc.nxc bits are both set to 1, the other three bits of
cexc are set to 0, and<br>
an IEEE_754_exception trap does *not* occur.<br>
<br>
-- if OFM=0 and NXM=1, the cexc.nxc bit is set to 1, the
other four bits of cexc are set to 0, and and an IEEE_754_exception
trap *does* occur.<br>
<br>
-- if OFM=1, the cexc.ofc bit is set to 1, the other four
bits of cexc are set to 0, and an IEEE_754_exception trap
*does* occur.</p>
</blockquote>
<p class="bodytext">o If an IEEE 754 underflow condition occurs:<br>
<blockquote class="bodytext"> -- if UFM=0 and NXM=0, the cexc.ufc
and cexc.nxc bits are both set to 1, the other three bits
of cexc are set to 0, and an IEEE_754_exception trap does
*not* occur.<br>
<br>
-- if UFM=0 and NXM=1, the cexc.nxc bit is set to 1, the other
four bits of cexc are set to 0, and an IEEE_754_exception
trap *does* occur.<br>
-- if UFM=1, the cexc.ufc bit is set to 1, the other four
bits of cexc are set to 0, and an IEEE_754_exception trap
*does* occur. </blockquote>
<p class="bodytext"> The above behavior is summarized in the
following table<br>
(x = don't-care):</p>
<table width="385" border="0" cellspacing="0" cellpadding="0">
<tr>
<td colspan="4">Exception(s)</td>
<td width="38">&nbsp;</td>
<td width="37">&nbsp;</td>
<td width="2">&nbsp;</td>
<td width="60">&nbsp;</td>
<td width="12">&nbsp;</td>
<td colspan="4">Current</td>
</tr>
<tr>
<td colspan="2">Detected</td>
<td width="19">&nbsp;</td>
<td colspan="3">Trap Enable</td>
<td width="2">&nbsp;</td>
<td width="60">&nbsp;</td>
<td width="12">&nbsp;</td>
<td colspan="4">Exception</td>
</tr>
<tr>
<td colspan="2">in f.p.</td>
<td width="19">&nbsp;</td>
<td colspan="3">Mask Bits</td>
<td width="2">&nbsp;</td>
<td colspan="2">IEEE_754_</td>
<td colspan="4">Bits (in</td>
</tr>
<tr>
<td colspan="3">operation</td>
<td colspan="3">(in FSR.TEM)</td>
<td width="2">&nbsp;</td>
<td width="60">exception</td>
<td width="12">&nbsp;</td>
<td colspan="4">FSR.cexc)</td>
</tr>
<tr>
<td width="28" height="19">----</td>
<td width="27" height="19">---</td>
<td width="19" height="19">--</td>
<td width="43" height="19">-----</td>
<td width="38" height="19">-----</td>
<td width="37" height="19">-----</td>
<td width="2" height="19">&nbsp;</td>
<td width="60" height="19">Trap</td>
<td width="12" height="19">&nbsp;</td>
<td width="26" height="19">---</td>
<td width="25" height="19">---</td>
<td width="26" height="19">---</td>
<td width="42" height="19">----</td>
</tr>
<tr>
<td width="28">of</td>
<td width="27">uf</td>
<td width="19">nx</td>
<td width="43">OFM</td>
<td width="38">UFM</td>
<td width="37">NXM</td>
<td width="2">&nbsp;</td>
<td width="60">Occurs?</td>
<td width="12">&nbsp;</td>
<td width="26">ofc</td>
<td width="25">ufc</td>
<td width="26">nxc</td>
<td width="42">Notes</td>
</tr>
<tr>
<td width="28">----</td>
<td width="27">---</td>
<td width="19">--</td>
<td width="43">-----</td>
<td width="38">-----</td>
<td width="37">-----</td>
<td width="2">&nbsp;</td>
<td width="60">-------</td>
<td width="12">&nbsp;</td>
<td width="26">---</td>
<td width="25">---</td>
<td width="26">---</td>
<td width="42">----</td>
</tr>
<tr>
<td width="28">
<div align="center">-</div>
</td>
<td width="27">
<div align="center">-</div>
</td>
<td width="19">
<div align="center">-</div>
</td>
<td width="43">
<div align="center">x</div>
</td>
<td width="38">
<div align="center">x</div>
</td>
<td width="37">
<div align="center">x</div>
</td>
<td width="2">
<div align="center"></div>
</td>
<td width="60">
<div align="center">no</div>
</td>
<td width="12">
<div align="center"></div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="25">
<div align="center">0</div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="42">
<div align="center"></div>
</td>
</tr>
<tr>
<td width="28">
<div align="center">-</div>
</td>
<td width="27">
<div align="center">-</div>
</td>
<td width="19">
<div align="center">*</div>
</td>
<td width="43">
<div align="center">x</div>
</td>
<td width="38">
<div align="center">x</div>
</td>
<td width="37">
<div align="center">0</div>
</td>
<td width="2">
<div align="center"></div>
</td>
<td width="60">
<div align="center">no</div>
</td>
<td width="12">
<div align="center"></div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="25">
<div align="center">0</div>
</td>
<td width="26">
<div align="center">1</div>
</td>
<td width="42">
<div align="center"></div>
</td>
</tr>
<tr>
<td width="28">
<div align="center">-</div>
</td>
<td width="27">
<div align="center">*</div>
</td>
<td width="19">
<div align="center">*</div>
</td>
<td width="43">
<div align="center">x</div>
</td>
<td width="38">
<div align="center">0</div>
</td>
<td width="37">
<div align="center">0</div>
</td>
<td width="2">
<div align="center"></div>
</td>
<td width="60">
<div align="center">no</div>
</td>
<td width="12">
<div align="center"></div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="25">
<div align="center">1</div>
</td>
<td width="26">
<div align="center">1</div>
</td>
<td width="42">
<div align="center">(1)</div>
</td>
</tr>
<tr>
<td width="28">
<div align="center">*</div>
</td>
<td width="27">
<div align="center">-</div>
</td>
<td width="19">
<div align="center">*</div>
</td>
<td width="43">
<div align="center">0</div>
</td>
<td width="38">
<div align="center">x</div>
</td>
<td width="37">
<div align="center">0</div>
</td>
<td width="2">
<div align="center"></div>
</td>
<td width="60">
<div align="center">no</div>
</td>
<td width="12">
<div align="center"></div>
</td>
<td width="26">
<div align="center">1</div>
</td>
<td width="25">
<div align="center">0</div>
</td>
<td width="26">
<div align="center">1</div>
</td>
<td width="42">
<div align="center">(2)</div>
</td>
</tr>
<tr>
<td width="28">
<div align="center"></div>
</td>
<td width="27">
<div align="center"></div>
</td>
<td width="19">
<div align="center"></div>
</td>
<td width="43">
<div align="center"></div>
</td>
<td width="38">
<div align="center"></div>
</td>
<td width="37">
<div align="center"></div>
</td>
<td width="2">
<div align="center"></div>
</td>
<td width="60">
<div align="center"></div>
</td>
<td width="12">
<div align="center"></div>
</td>
<td width="26">
<div align="center"></div>
</td>
<td width="25">
<div align="center"></div>
</td>
<td width="26">
<div align="center"></div>
</td>
<td width="42">
<div align="center"></div>
</td>
</tr>
<tr>
<td width="28">
<div align="center">-</div>
</td>
<td width="27">
<div align="center">-</div>
</td>
<td width="19">
<div align="center">*</div>
</td>
<td width="43">
<div align="center">x</div>
</td>
<td width="38">
<div align="center">x</div>
</td>
<td width="37">
<div align="center">1</div>
</td>
<td width="2">
<div align="center"></div>
</td>
<td width="60">
<div align="center">yes</div>
</td>
<td width="12">
<div align="center"></div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="25">
<div align="center">0</div>
</td>
<td width="26">
<div align="center">1</div>
</td>
<td width="42">
<div align="center"></div>
</td>
</tr>
<tr>
<td width="28">
<div align="center">-</div>
</td>
<td width="27">
<div align="center">*</div>
</td>
<td width="19">
<div align="center">*</div>
</td>
<td width="43">
<div align="center">x</div>
</td>
<td width="38">
<div align="center">0</div>
</td>
<td width="37">
<div align="center">1</div>
</td>
<td width="2">
<div align="center"></div>
</td>
<td width="60">
<div align="center">yes</div>
</td>
<td width="12">
<div align="center"></div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="25">
<div align="center">0</div>
</td>
<td width="26">
<div align="center">1</div>
</td>
<td width="42">
<div align="center"></div>
</td>
</tr>
<tr>
<td width="28">
<div align="center">-</div>
</td>
<td width="27">
<div align="center">*</div>
</td>
<td width="19">
<div align="center">-</div>
</td>
<td width="43">
<div align="center">x</div>
</td>
<td width="38">
<div align="center">1</div>
</td>
<td width="37">
<div align="center">x</div>
</td>
<td width="2">
<div align="center"></div>
</td>
<td width="60">
<div align="center">yes</div>
</td>
<td width="12">
<div align="center"></div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="25">
<div align="center">1</div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="42">
<div align="center"></div>
</td>
</tr>
<tr>
<td width="28">
<div align="center">-</div>
</td>
<td width="27">
<div align="center">*</div>
</td>
<td width="19">
<div align="center">*</div>
</td>
<td width="43">
<div align="center">x</div>
</td>
<td width="38">
<div align="center">1</div>
</td>
<td width="37">
<div align="center">x</div>
</td>
<td width="2">
<div align="center"></div>
</td>
<td width="60">
<div align="center">yes</div>
</td>
<td width="12">
<div align="center"></div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="25">
<div align="center">1</div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="42">
<div align="center"></div>
</td>
</tr>
<tr>
<td width="28">
<div align="center">*</div>
</td>
<td width="27">
<div align="center">-</div>
</td>
<td width="19">
<div align="center">*</div>
</td>
<td width="43">
<div align="center">1</div>
</td>
<td width="38">
<div align="center">x</div>
</td>
<td width="37">
<div align="center">x</div>
</td>
<td width="2">
<div align="center"></div>
</td>
<td width="60">
<div align="center">yes</div>
</td>
<td width="12">
<div align="center"></div>
</td>
<td width="26">
<div align="center">1</div>
</td>
<td width="25">
<div align="center">0</div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="42">
<div align="center">(2)</div>
</td>
</tr>
<tr>
<td width="28">
<div align="center">*</div>
</td>
<td width="27">
<div align="center">-</div>
</td>
<td width="19">
<div align="center">*</div>
</td>
<td width="43">
<div align="center">0</div>
</td>
<td width="38">
<div align="center">x</div>
</td>
<td width="37">
<div align="center">1</div>
</td>
<td width="2">
<div align="center"></div>
</td>
<td width="60">
<div align="center">yes</div>
</td>
<td width="12">
<div align="center"></div>
</td>
<td width="26">
<div align="center">0</div>
</td>
<td width="25">
<div align="center">0</div>
</td>
<td width="26">
<div align="center">1</div>
</td>
<td width="42">
<div align="center">(2)</div>
</td>
</tr>
</table>
<p class="bodytext">(1) When the underflow trap is disabled
(UFM=0), underflow is always accompanied by inexact. <br>
</p>
<p class="bodytext"> (2) Overflow is always accompanied by inexact.</p>
<p></p>
<p class="bodytext"><b><font color="#FF0000">[68] In Appendix
B, section B.3 (p.245),</font></b> the first paragraph:</p>
<p> <span class="bodytext">&quot;Underflow occurs if the exact
unrounded result has magnitude<br>
between zero and the smallest normalized number in the<br>
destination format.&quot;</span></p>
<p class="bodytext"> should be replaced by the following two
paragraphs:</p>
<blockquote>
<p> <span class="bodytext">&quot;On an implementation that
detects tininess before rounding, trapped underflow occurs
when the exact unrounded result has magnitude between zero
and the smallest normalized number in the destination format.</span></p>
<p class="bodytext"> On an implementation that detects tininess
after rounding, trapped underflow occurs when the result,
if it was rounded to a hypothetical format having the same
precision as the destination but of unbounded range, would
have magnitude between zero and the smallest normalized
number in the actual destination format.&quot;</p>
</blockquote>
<p> <span class="bodytext"><b><font color="#FF0000">[69] In
Appendix B, section B.4 (p.245)</font></b>, the first two
paragraphs:</span></p>
<p class="bodytext"> The first paragraph:
<blockquote> <span class="bodytext">&quot;Underflow occurs if
the exact unrounded result has magnitudebetween zero and the
smallest normalized number in thedestination format, *and*
the correctly rounded result in the destination format is
inexact.&quot; </span></blockquote>
<p class="bodytext"> should be replaced by the following paragraph:</p>
<blockquote class="bodytext"> On an implementation that detects
tininess before rounding, untrapped underflow occurs when
the exact unrounded result has magnitude between zero and
the smallest normalized number in the destination format,
*and* the correctly-rounded result in the destination format
is inexact.&quot;</blockquote>
<p class="bodytext"> And the beginning of the second paragraph:</p>
<blockquote> <span class="bodytext">&quot;Table 28 summarizes
what happens when an exact ...&quot;<br>
should be modified to read:<br>
&quot;Table 28 summarizes what happens on an implementation
that detects tininess before rounding, when an exact ...&quot;</span></blockquote>
<p> <span class="bodytext"><b><font color="#FF0000">[70] In
Appendix B, Table 28, &quot;Untrapped Floating-Point Underflow&quot;
(p.245)</font></b>: Table 28 (and its footnote) should be
replaced by the following revised table and text:</span></p>
<blockquote>
<p class="bodytext"> Table 28: Untrapped Floating-Point Underflow
(Tininess Detected Before Rounding)</p>
<table width="385" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="48">&nbsp;</td>
<td colspan="2">
<div align="center">Underflow trap mask: </div>
</td>
<td width="64">UFM=1</td>
<td width="66">UFM=0</td>
<td width="54">UFM=0</td>
</tr>
<tr>
<td width="48">&nbsp;</td>
<td colspan="2">
<div align="center">Inexact trap mask: </div>
</td>
<td width="64">NXM=x</td>
<td width="66">NXM=x</td>
<td width="54">NXM=0</td>
</tr>
<tr>
<td width="48">&nbsp;</td>
<td width="6">&nbsp;</td>
<td width="137">&nbsp;</td>
<td width="64">&nbsp;</td>
<td width="66">&nbsp;</td>
<td width="54">&nbsp;</td>
</tr>
<tr>
<td width="48">u = r</td>
<td width="6">&nbsp;</td>
<td width="137">r is minimum normal</td>
<td width="64">none</td>
<td width="66">none</td>
<td width="54">none</td>
</tr>
<tr>
<td width="48">&nbsp;</td>
<td width="6">&nbsp;</td>
<td width="137">r is subnormal</td>
<td width="64">UF</td>
<td width="66">none </td>
<td width="54">none</td>
</tr>
<tr>
<td width="48">&nbsp;</td>
<td width="6">&nbsp;</td>
<td width="137">r is zero</td>
<td width="64">none</td>
<td width="66">none</td>
<td width="54">none</td>
</tr>
<tr>
<td width="48">&nbsp;</td>
<td width="6">&nbsp;</td>
<td width="137">&nbsp;</td>
<td width="64">&nbsp;</td>
<td width="66">&nbsp;</td>
<td width="54">&nbsp;</td>
</tr>
<tr>
<td width="48">u ! = r</td>
<td width="6">&nbsp;</td>
<td width="137">r is minimum normal</td>
<td width="64">UF</td>
<td width="66">NX</td>
<td width="54">uf nx</td>
</tr>
<tr>
<td width="48">&nbsp;</td>
<td width="6">&nbsp;</td>
<td width="137">r is subnormal</td>
<td width="64">UF</td>
<td width="66">NX</td>
<td width="54">uf nx</td>
</tr>
<tr>
<td width="48">&nbsp;</td>
<td width="6">&nbsp;</td>
<td width="137">r is zero</td>
<td width="64">UF</td>
<td width="66">NX</td>
<td width="54">uf nx</td>
</tr>
<tr>
<td width="48">&nbsp;</td>
<td width="6">&nbsp;</td>
<td width="137">&nbsp;</td>
<td width="64">&nbsp;</td>
<td width="66">&nbsp;</td>
<td width="54">&nbsp;</td>
</tr>
<tr>
<td colspan="6">
<div align="left">UF = IEEE_754_exception trap with
cexc.ufc=1</div>
</td>
</tr>
<tr>
<td colspan="6">
<div align="left">NX = IEEE_754_exception trap with
cexc.ufc=1</div>
</td>
</tr>
<tr>
<td colspan="6" height="17">&nbsp;</td>
</tr>
<tr>
<td colspan="6">
<div align="center"></div>
</td>
</tr>
<tr>
<td colspan="6">
<div align="left">uf = cexc.ufc=1, aexc.ufa=1, no IEEE_754_exception
trap </div>
</td>
</tr>
<tr>
<td colspan="6">
<div align="left">nx = cexc.nxc=1, aexc.nxa=1, no IEEE_754_exception
trap</div>
</td>
</tr>
</table>
</blockquote>
<p class="bodytext">In an implementation that detects tininess
after rounding, Table 28 applies to a narrower range of values
of the exact unrounded result u. The precise bounds depend
on the rounding direction specified in FSR.RD, as follows:
</p>
<blockquote>
<p class="bodytext"> o Let m denote the smallest normalized
number and e the absolute difference between 1 and the next
larger representable number in the destination format. Then
the bounds on u for which Table 28 applies are:</p>
</blockquote>
<table border="0" cellspacing="0" cellpadding="0" width="345" align="center">
<tr>
<td width="106">
<div align="center"></div>
</td>
<td width="93" class="bodytext">Rounding</td>
<td width="146">&nbsp;</td>
</tr>
<tr>
<td width="106">
<div align="center" class="bodytext">FSR.RD</div>
</td>
<td width="93" class="bodytext">Toward</td>
<td width="146" class="bodytext">Range of Values of u</td>
</tr>
<tr>
<td width="106">
<div align="center" class="bodytext">-------------</div>
</td>
<td width="93" class="bodytext">------------</td>
<td width="146" class="bodytext">---------------------</td>
</tr>
<tr>
<td width="106">
<div align="center" class="bodytext">0</div>
</td>
<td width="93" class="bodytext">nearest</td>
<td width="146" class="bodytext">|u| &lt; m(1 - e/4)</td>
</tr>
<tr>
<td width="106">
<div align="center" class="bodytext">1</div>
</td>
<td width="93" class="bodytext">0</td>
<td width="146" class="bodytext">|u| &lt; m</td>
</tr>
<tr>
<td width="106">
<div align="center" class="bodytext">2</div>
</td>
<td width="93" class="bodytext">+infinity</td>
<td width="146" class="bodytext">-m &lt; u &lt;= m(1 - 2/2)</td>
</tr>
<tr>
<td width="106">
<div align="center" class="bodytext">3</div>
</td>
<td width="93" class="bodytext">-infinity</td>
<td width="146" class="bodytext">-m(1 - e/2) &lt;= u &lt;
m</td>
</tr>
</table>
<p class="bodytext">o When u lies outside these ranges, underflow
does not occur,<br>
although an inexact exception still occurs when u != r, the
rounded value.</p>
<p><span class="bodytext"><b><font color="#FF0000">[71] In Appendix
A, section A.40, &quot;No Operation&quot; (p.204):</font></b></span><br>
<span class="bodytext">For clarity, in the instruction format
diagram the eterm &quot;op&quot; should be replaced by five
zeroes.</span></p>
<p class="bodytext"><b><font color="#FF0000">[72] In Appendix
A, section A.53, &quot;Store Integer&quot; (p.227):<br>
</font></b>The following paragraph should be added near the
end of the Description subsection, prior to the Programming
Note, to clarify the behavior of a little-endian doubleword
store (STD):<br>
<blockquote>
<p class="bodytext">&quot;With respect to little-endian memory,
a STD instruction behaves as if it is composed of two 32-bit
stores, each of which is byte-swapped independently before
being written into its respective destination memory word.&quot;</p>
</blockquote>
<p class="bodytext"><b><font color="#FF0000">[73] In Appendix
A, section A.54, &quot;Store Integer Into Alternate Space&quot;
(p.229):<br>
</font></b>The following paragraph should be added near the
end of the Description subsection, prior to the Programming
Note, to clarify the behavior of a little-endian doubleword
store to alternate space (STDA):<br>
<blockquote>
<p class="bodytext">&quot;With respect to little-endian memory,
a STDA instruction behaves as if it is composed of two 32-bit
stores, each of which is byte-swapped independently before
being written into its respective destination memory word.&quot;</p>
</blockquote>
<p class="bodytext"><b><font color="#FF0000">[74] In Chapter
7, reference is made in two places to a range of trap priorities,
with 0 as the highest priority and 31 as the lowest.</font></b><br>
Architecturally, there are no absolute trap priorities (only
relative trap priorities) and there is no specific limit to
trap priority numbers. Trap priorities are only used by a
processor to choose which exception will cause a trap at any
given time; a trap priority is an ordinal number which need
not be stored anywhere. Therefore, the following changes should
be noted:</p>
<p class="bodytext"><span class="bodytext">Caption above Table
15, p.101: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Change:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;0
= Highest; 31 = Lowest&quot;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to:<br>
</span>
<span class="bodytext">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;0
= Highest&quot;</span></p><span class="bodytext">
<p class="bodytext">Text of first paragraph of section 7.5.3
on p.102:<br>
&nbsp;&nbsp;&nbsp;&nbsp; Change:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;Priority 0 is highest, priority 31 is lowest; that is,
if.......&quot;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&quot;A trap priority is an ordinal number, with 0 indicating<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
the highest priority and greater priority numbers<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
indicating decreasing priority; that is, if......&quot;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
</span></td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
<table width="619" border="0" cellpadding="0" cellspacing="0">
<tr>
<td width="190">
<div align="center"></div>
</td>
<td>
<P><br><div align="center"><img src="/images/bottom_text.gif" width="418" height="50"></div>
</td>
</tr>
</table>
<script language="JavaScript1.2">
<!--
//For IE
if (document.all) {
onLoad();
}
//-->
</script>
</body>
</html>