<html><body>
<p><font size="2" face="sans-serif">On PowerPC, to detect </font><font size="2" face="sans-serif"><u>all exceptions</u></font><font size="2" face="sans-serif"> that occurred in a block of code would involve something like:</font>
<ol type="1" style="padding-left: 36pt">
<li><font size="2" face="sans-serif">Copy the FPSCR (Floating-Point Status and Control Register) to a floating point/vector register (serializing on some CPU models).</font>
<li><font size="2" face="sans-serif">Make a copy of that with </font><font size="2" face="sans-serif"><u>all status bits</u></font><font size="2" face="sans-serif"> (the sticky bits that report an exception happened) cleared so changes can be detected,<br>
and with </font><font size="2" face="sans-serif"><u>all exception-signaling-enabled control bits</u></font><font size="2" face="sans-serif"> (the bits that say to create an interrupt) cleared so a signal handler won't be called.</font>
<li><font size="2" face="sans-serif">Copy that to the FPSCR (serializing on most CPU models).</font>
<li><font size="2" face="sans-serif">Execute the block of code. Any exceptions that occur will be recorded in the status bits but will not call a signal handler.</font>
<li><font size="2" face="sans-serif">Copy the FPSCR to another floating point/vector register (serializing on some CPU models).</font>
<li><font size="2" face="sans-serif">Extract </font><font size="2" face="sans-serif"><u>all the status bits</u></font><font size="2" face="sans-serif">.</font>
<li><font size="2" face="sans-serif">Probably OR </font><font size="2" face="sans-serif"><u>all the status bits</u></font><font size="2" face="sans-serif"> into the FPSCR copy saved in step 1.</font>
<li><font size="2" face="sans-serif">Write the saved FPSCR (probably with the new status bits ORed in) back to the FPSCR (serializing on most CPU models),<br>
restoring the original exception-signaling-enabled control bits and the original or original+new status bits.</font>
<li><font size="2" face="sans-serif">Compare the extracted status bits to zero.</font>
<li><font size="2" face="sans-serif">If nonzero, execute the alternate handling code.</font></ol>
<br>
<font size="2" face="sans-serif">To detect </font><font size="2" face="sans-serif"><u>one or more exceptions the programmer specifies</u></font><font size="2" face="sans-serif"> that occurred in a block of code would involve something like:</font>
<ol type="1" style="padding-left: 36pt">
<li><font size="2" face="sans-serif">Copy the FPSCR (Floating-Point Status and Control Register) to a floating point/vector register (serializing on some CPU models).</font>
<li><font size="2" face="sans-serif">Make a copy of that with </font><font size="2" face="sans-serif"><u>the specified status bit(s)</u></font><font size="2" face="sans-serif"> (the sticky bits that report an exception happened) cleared so changes can be detected,<br>
and with </font><font size="2" face="sans-serif"><u>the specified exception-signaling-enabled flags</u></font><font size="2" face="sans-serif"> (the bits that say to create an interrupt) cleared so a signal handler won't be called.</font>
<li><font size="2" face="sans-serif">Copy that to the FPSCR (serializing on most CPU models).</font>
<li><font size="2" face="sans-serif">Execute the block of code. Any exceptions that occur will be recorded in the status bits but will not call a signal handler.</font>
<li><font size="2" face="sans-serif">Copy the FPSCR to another floating point/vector register (serializing on some CPU models).</font>
<li><font size="2" face="sans-serif">Extract </font><font size="2" face="sans-serif"><u>the specified status bits</u></font><font size="2" face="sans-serif">.</font>
<li><font size="2" face="sans-serif">Probably OR </font><font size="2" face="sans-serif"><u>the specified status bit(s)</u></font><font size="2" face="sans-serif"> into the FPSCR copy saved in step 1.</font>
<li><font size="2" face="sans-serif">Write the saved FPSCR (probably with the new status bit(s) ORed in) back to the FPSCR (serializing on most CPU models).</font>
<li><font size="2" face="sans-serif">Compare the extracted status bit(s) to zero.</font>
<li><font size="2" face="sans-serif">If nonzero, execute the alternate handling code.</font></ol>
<br>
<font size="2" face="sans-serif">Not much difference.</font><br>
<br>
<font size="2" face="sans-serif">With the assumption that no exception-signaling-enabled flags are set, and that only one or a few exceptions need to be detected, and that the original status bits don't need to be preserved, that can be simplified:</font>
<ol type="1" style="padding-left: 36pt">
<li><font size="2" face="sans-serif">Clear the individual status bits for the exception(s) that need to be detected (serializing on most CPU models).</font>
<li><font size="2" face="sans-serif">Execute the block of code. Any exceptions that occur will be recorded in the status bits.</font>
<li><font size="2" face="sans-serif">Copy the FPSCR to a floating point/vector register (serializing on some CPU models).</font>
<li><font size="2" face="sans-serif">Extract</font><font size="2" face="sans-serif"> the specified status bit(s).</font>
<li><font size="2" face="sans-serif">Compare the extracted status bit(s) to zero.</font>
<li><font size="2" face="sans-serif">If nonzero, execute the alternate handling code.</font>
<li></ol>
<font size="2" face="sans-serif">That's still noticeably slower than a compare and conditional branch, but getting reasonable for at least some uses.</font><br>
<br>
<font size="2" face="sans-serif">What would be needed on other architectures?</font><br>
<br>
<font size="2" face="sans-serif">- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development<br>
</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF64ADF9511288f9e8a93df938@ca.ibm.com" border="0" alt="Inactive hide details for David Hough CFP ---2014-05-14 07:51:59 PM---There's a real problem with defining FP_EXCEPTIONAL witho"><font size="2" color="#424282" face="sans-serif">David Hough CFP ---2014-05-14 07:51:59 PM---There's a real problem with defining FP_EXCEPTIONAL without a list of exceptions or subexceptions of</font><br>
<br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF64ADF9511288f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">From:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF64ADF9511288f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">David Hough CFP <pcfp@oakapple.net></font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF64ADF9511288f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">To:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF64ADF9511288f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">cfp-interest@ucbtest.org, </font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF64ADF9511288f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">Date:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF64ADF9511288f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">2014-05-14 07:51 PM</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF64ADF9511288f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">Subject:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF64ADF9511288f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">[Cfp-interest] FP_EXCEPTIONAL and subexceptions</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF64ADF9511288f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">Sent by:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF64ADF9511288f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">cfp-interest-bounces@oakapple.net</font></td></tr>
</table>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2"><br>
There's a real problem with defining FP_EXCEPTIONAL without a list<br>
of exceptions or subexceptions of interest. In that case it has<br>
to return a complete list of exceptions and subexceptions, whether you're<br>
interested in them or not. In general, executing code and determining<br>
which subexceptions arose is going to be expensive and so you wouldn't<br>
want to do that unless you cared.<br>
<br>
Remember one of the goals here is that if the exception of interest does<br>
NOT arise, then the typical use case is that the just-computed test<br>
expression is actually the result you want. So it needs to be ready<br>
for use and efficient as well since it gets executed every time, unlike<br>
the special case code for exceptions of interest.<br>
<br>
_______________________________________________<br>
Cfp-interest mailing list<br>
Cfp-interest@oakapple.net<br>
</font></tt><tt><font size="2"><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</a></font></tt><tt><font size="2"><br>
<br>
</font></tt><br>
<br>
</body></html>