<html><body>
<p><font size="2" face="sans-serif">Yes, please omit "unconventional". The PowerPC branches are different from some others in that each tests some bit in a conditional register, but that's not really unconventional. More importantly, the standard branch instructions that handle standard compares that set the condition register also handle floating-point exception testing, because first a status bit is copied from the Floating-Point Status and Control Register to the condition register.</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__=0ABBF663DF80BFFA8f9e8a93df938@ca.ibm.com" border="0" alt="Inactive hide details for Jim Thomas ---2014-06-06 08:05:23 PM---On Jun 6, 2014, at 4:25 PM, David Hough CFP <pcfp@oakapple.net"><font size="2" color="#424282" face="sans-serif">Jim Thomas ---2014-06-06 08:05:23 PM---On Jun 6, 2014, at 4:25 PM, David Hough CFP <pcfp@oakapple.net> wrote: > Here are some revisions bas</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__=0ABBF663DF80BFFA8f9e8a93df938@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__=0ABBF663DF80BFFA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">Jim Thomas <jaswthomas@sbcglobal.net></font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF663DF80BFFA8f9e8a93df938@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__=0ABBF663DF80BFFA8f9e8a93df938@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__=0ABBF663DF80BFFA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">Cc:</font></ul>
</td><td width="100%" valign="middle"><img width="1" height="1" src="cid:2__=0ABBF663DF80BFFA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">CFP <cfp-interest@ucbtest.org></font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF663DF80BFFA8f9e8a93df938@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__=0ABBF663DF80BFFA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">2014-06-06 08:05 PM</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF663DF80BFFA8f9e8a93df938@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__=0ABBF663DF80BFFA8f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">Re: [Cfp-interest] draft of syntax discussion for C committee</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF663DF80BFFA8f9e8a93df938@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__=0ABBF663DF80BFFA8f9e8a93df938@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>
On Jun 6, 2014, at 4:25 PM, David Hough CFP <pcfp@oakapple.net> wrote:<br>
<br>
> Here are some revisions based on Jim's comments, along with responses<br>
> on some of the comments:<br>
> <br>
> =========================================<br>
> <br>
> DIFF: 36,37c36,44<br>
> <br>
> < traps, but with significant performance penalties for either the normal case <br>
> < or exceptional case.<br>
> ---<br>
>> traps, but that might entail significant performance penalties for either <br>
>> the normal case or exceptional case. Exceptions can be detected<br>
>> inline for each operation with tests on operands and results and flags -<br>
>> slowing down the normal case - or at the end of the try clause with flags -<br>
>> slowing the detection of the exceptional case (but testing flags alone does<br>
>> not detect exact underflow exceptions). Instead of traps,<br>
>> some existing hardware such as<br>
>> PowerPC can exploit its unconventional conditional branch instructions <br>
>> to detect exceptions.<br>
<br>
Consider omitting “unconventional”.<br>
<br>
> <br>
> COMMENT:<br>
> <br>
> [<br>
>> Is how to implement alternate exception handling without traps <br>
>> (including for underflow) documented somewhere?<br>
> <br>
> Not that I know of - the general idea is mentioned here; how that works out<br>
> in detailed code generation depends on the hardware architecture, but we<br>
> could write up some hints that look like C code - <br>
> but I don't think this document is the place for it.<br>
<br>
Right, this isn’t the place for such details. (I’m still wondering if some HW might not provide any way for a program to detect underflow exceptions.)<br>
<br>
> ]<br>
> <br>
> =========================================<br>
> <br>
> DIFF: 150,151c157,160<br>
> <br>
> < But having to specify the same exception-list in two different places<br>
> < seems error-prone.<br>
> ---<br>
>> Compilers that would process the catch_fe clauses before generating the<br>
>> try clause code could ignore that pragma.<br>
>> One-pass compilers that encountered discrepancies in catch_fe clauses <br>
>> from the exceptions flagged in advance should probably generate errors.<br>
> <br>
> COMMENT:<br>
> <br>
> [<br>
>> It doesn't need to be error prone. The CATCH_AHEAD exception list could be required to be a super set of all the catch_fe exception lists, which the compiler could check. The advantages would be a concise statement of exceptions that might get alternate exception handling and not having to see all the exception code before getting to the main code - which I believe would make the code more readable.<br>
> <br>
> Actually the simplest method for doing what Jim proposes without duplicating<br>
> effort might be like this:<br>
> <br>
> {<br>
> #pragma STDC catch_fe fe_exception1 label1<br>
> #pragma STDC catch_fe fe_exception2 label2<br>
> ... normal case code<br>
> }<br>
> ... normal case continues here<br>
> label1:<br>
> ... exception case 1 code<br>
> label2:<br>
> ... exception case 2 code<br>
> <br>
> You don't need exception lists any more - list one exception at a time<br>
> even if they both go to the same place.<br>
> The above is entirely freed from block structure... or not:<br>
> <br>
> {<br>
> #pragma STDC catch_fe fe_exception1 label1<br>
> #pragma STDC catch_fe fe_exception2 label2<br>
> ... normal case code<br>
> break;<br>
> label1:<br>
> ... exception case 1 code<br>
> label2:<br>
> ... exception case 2 code<br>
> }<br>
> ... normal case continues here<br>
> <br>
> Putting it into C++ try/catch form requires a way of creating a type<br>
> from an exception name:<br>
> <br>
> try {<br>
> #pragma STDC catch_fe fe_exception1<br>
> #pragma STDC catch_fe fe_exception2<br>
> ... normal case code<br>
> }<br>
> catch (FE_EXCEPTION_TYPE(fp_exception1) e1) {<br>
> ... exception case 1 code<br>
> }<br>
> catch (FE_EXCEPTION_TYPE(fp_exception2) e2) {<br>
> ... exception case 2 code<br>
> }<br>
> ... normal case continues here<br>
> <br>
> FE_EXCEPTION_TYPE is a standard macro that converts an <fenv.h> exception<br>
> like FE_INVALID (which is just an implementation-defined integer <br>
> representing a bit in a field) into a type FE_INVALID_TYPE,<br>
> since C++ style catch works on the type of its argument.<br>
> Whatever is actually in the variable e1 or e2 doesn't matter because it's<br>
> not likely to be in a form useful in a portable program.<br>
> <br>
> I don't regard defining FE_EXCEPTION_TYPE <br>
> as doing the application programmer any favor.<br>
> I'd much rather write<br>
> catch_fe(fp_exception1)<br>
> than <br>
> catch (FE_EXCEPTION_TYPE(fp_exception1) e1)<br>
> <br>
> The point is that it could be made to look more or less like C++<br>
> if that were deemed important enough.<br>
> ]<br>
> <br>
> =========================================<br>
> <br>
> DIFF: 156,160c164,168<br>
> <br>
> < exception handling could be added to C++ with minimal syntactic <br>
> < effort, and most of<br>
> < C++ exception handling could be added to C with minimal syntactic <br>
> < effort.<br>
> < If that compatibility is deemed to be of low value, <br>
> ---<br>
>> exception handling could be added to C++ with less syntactic <br>
>> effort than other possible approaches, and most of<br>
>> C++ exception handling could be added to C with less syntactic <br>
>> effort than other possible approaches.<br>
>> If that compatibility were deemed to cost more than its benefit,<br>
<br>
The pragma approach adds nothing to the syntax of the language.<br>
<br>
> <br>
> COMMENT:<br>
> <br>
> [<br>
>>> One result of preserving some form of try/catch syntax is that <br>
>>> floating-point<br>
>>> exception handling could be added to C++ with minimal syntactic effort, <br>
> <br>
>> Is this true? Has it been done?<br>
> <br>
>>> and most of<br>
>>> C++ exception handling could be added to C with minimal syntactic effort.<br>
> <br>
>> Really? We don't have a specification of the changes to C required to add such syntax.<br>
> <br>
> Neither of these has been done.<br>
> But they would require minimal syntactic effort <br>
> compared to a completely different syntax. <br>
<br>
See previous comment.<br>
<br>
> That doesn't address the effort to implement the semantics.<br>
> ]<br>
> <br>
> [<br>
>>> If that compatibility is deemed to be of low value<br>
> <br>
>> Not a fair statement. C and C++ compatibility is certainly of value, and it might be regarded as a reasons for not adding a different specialized try-catch.<br>
> <br>
> I should have used the subjunctive here - I really don't know if there is<br>
> consensus one way or another on the C committee on this point.<br>
> ]<br>
> <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>