<html><body>
<p><font size="2" face="sans-serif">I understand the interest in presubstitution, but I'm not aware of any existing hardware to do it automatically. That means it has to be done by software, presumably mostly by compilers in response to user code. I think it will be challenging to get it approved or implemented.</font><br>
<br>
<font size="2" face="sans-serif">For PowerPC there are several possible implementations. These are slightly simplified:</font><br>
<ol type="1" style="padding-left: 18pt">
<li><font size="2" face="sans-serif">Trap to a signal handler:<br>
Before the monitored code, activate a signal handler for either a SIGTRAP or SIGFPE (depending on whether AIX or Linux and on AIX the mechanism the user chose to detect exceptions) if it wasn't already active (requires a system call), store the substitution values in some agreed on place (probably an extern or thread-local struct variable, with the old value saved and later restored in case of recursion), save the Floating Point Status and Control Register and the FE0+FE1 bits in the Machine State Register enabling traps, and change them to enable exception trapping for the relevant exceptions (changing trap enablement requires a system call).<br>
After the monitored code, restore the FPSCR control but not status bits, the FE0+FE1 trap enablement (via a system call) and the substitution struct's previous values and deactivate the signal handler if necessary (via a system call).<br>
During the monitored code, an exception of interest would trap to the operating system which after many instructions would activate the signal handler. That would analyze the situation, find which instruction trapped instead of executing, what its result register was, deduce somehow what exception would have occurred (maybe by temporarily disabling exception trapping then executing just that instruction?), find the appropriate substitution value in the agreed on place, set the result register to the substitution value, adjust the instruction address register (PC) to point at the next instruction, then return.<br>
Obviously this is expensive.<br>
</font>
<li><font size="2" face="sans-serif">Test after each operation:<br>
Before the monitored code, store the substitution values in some agreed on place (which in this case can be a local auto variable), save the FPSCR and change it to enable exception reporting for the relevant exceptions and disable FE0+FE1 exception trapping (via a system call).<br>
After the monitored code, restore the FPSCR control but not status bits and FE0+FE1 exception trapping (via a system call).<br>
During the monitored code, an exception of interest would not trap. Each floating-point instruction would be a "record form instruction", containing a control bit telling the CPU to copy 4 specific flags from the FPSCR to a condition register. Also each function call would be followed by a floating-point copy instruction to detect any exceptions that occurred in the function. Each floating-point instruction would be followed by a conditional branch checking a specific condition register bit (copied from the FPSCR) indicating whether any enabled exception status bit was set. If yes, code would be executed to analyze the FPSCR to see what exception occurred, find the appropriate substitution value in the agreed on place and set the result register to the substitution value, then continue.<br>
If unsubstituted exceptions are supposed to trap to a signal handler then things get more complicated.<br>
Unfortunately adding a check after each instruction destroys parallelism.<br>
This approach is expensive but for small blocks much less expensive than trapping to a signal handler.<br>
</font>
<li><font size="2" face="sans-serif">Test after the code block:<br>
This would be similar to #2 but test only at the end of the code block. Depending on the semantics it may be necessary to either test before each store or to defer all stores until after the single test at the end.<br>
This would be less expensive than #1 or #2.<br>
</font>
<li><font size="2" face="sans-serif">Test instruction results:<br>
It may be cheaper to explicitly test the result of every floating-point instruction in the block, especially if only NaNs or Infinities or Zeros are being substituted.<br>
If the program had enabled trapping on exceptions, that would have to be disabled then restored, but that could be done by changing the FPSCR to not report the monitored exceptions.<br>
</font>
<li><font size="2" face="sans-serif">Let the user handle it:<br>
In many applications the least expensive way is to let the program do it itself. None of the above can meet the stated requirement of being no more expensive than a [compare and] conditional branch.</font></ol>
<br>
<font size="2" face="sans-serif">Assuming substitution would apply to all precisions, the substitution values must either be translated to all precisions in advance, or more likely translated to the required precision on demand. Or would the user have to specify the appropriate value for each precision in the block?</font><br>
<br>
<font size="2" face="sans-serif">Combining substitution with other special handling adds a little more complexity.</font><br>
<br>
<font size="2" face="sans-serif">Most of the exceptions are mutually exclusive, but inexact can occur with some of the others. If inexact is handled we will have to define which substitution wins.</font><br>
<br>
<font size="2" face="sans-serif">The PowerPC has specific invalid operation flags ORed together into the IEEE Invalid Operation, so users could distinguish between oo-oo, oo/oo, 0/0, 0*oo, sqrt(-1), (int)(1.E200), comparing to an SNaN or a library function domain or range error.</font><br>
<br>
<font size="2" face="sans-serif">On some systems SIMD operations might add additional comlexity.</font><br>
<br>
<br>
<font size="2" face="sans-serif"><i>How would this be implemented on other architectures that you're familiar with?</i></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__=0ABBF672DFE60D8F8f9e8a93df938@ca.ibm.com" border="0" alt="Inactive hide details for David Hough CFP ---2014-05-23 05:21:18 PM---I talked about my ideas for alternate exception handling "><font size="2" color="#424282" face="sans-serif">David Hough CFP ---2014-05-23 05:21:18 PM---I talked about my ideas for alternate exception handling yesterday at Berkeley. I'd say that the</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__=0ABBF672DFE60D8F8f9e8a93df938@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__=0ABBF672DFE60D8F8f9e8a93df938@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__=0ABBF672DFE60D8F8f9e8a93df938@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__=0ABBF672DFE60D8F8f9e8a93df938@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__=0ABBF672DFE60D8F8f9e8a93df938@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__=0ABBF672DFE60D8F8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">2014-05-23 05:21 PM</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF672DFE60D8F8f9e8a93df938@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__=0ABBF672DFE60D8F8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">[Cfp-interest] Berkeley feedback</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF672DFE60D8F8f9e8a93df938@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__=0ABBF672DFE60D8F8f9e8a93df938@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>
I talked about my ideas for alternate exception handling yesterday at<br>
Berkeley. I'd say that the main feedback, especially from Kahan, is that<br>
the macro syntax is too complicated. Others pointed out that nested<br>
macros will look especially unattractive. And the pragma syntax<br>
isn't much better.<br>
<br>
Kahan was particularly adamant that some kind of presubstitution mechanism<br>
be available, particularly because, lacking explicit branches, it made<br>
automated (and perhaps manual) theorem proving more tractable.<br>
<br>
We agreed that the continued fraction with derivative example was not a<br>
very compelling argument for presubstitution, because the presubstituted<br>
value changes in the inner loop, and it's very doubtful that any<br>
presubstitution mechanism can be as fast as conditional branches<br>
on operands or results in the source code, especially if they get <br>
compiled into correctly-predicted branches or conditional moves. <br>
<br>
One of the other attendees pointed out that the continued fraction example<br>
is a good candidate for executing the entire loop under FP_EXCEPTIONAL<br>
as if no invalid would occur, and then interrupting and recomputing more<br>
carefully in the infrequent occasions when invalid does occur.<br>
That corresponds to the way I imagine FP_EXCEPTIONAL could be applied<br>
to the dnrm2 problem, although Kahan has another algorithm for dnrm2<br>
that is supposed to be avoid exceptions and only invoke scaling if<br>
necessary.<br>
<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>