[Cfp-interest] draft of syntax discussion for C committee

[Ian McIntosh]

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.

- Ian McIntosh          IBM Canada Lab         Compiler Back End Support
and Development



|------------>
| From:      |
|------------>
  >-----------------------------------------------------------------------------------------------------------------------------------------|
  |Jim Thomas <jaswthomas at sbcglobal.net>                                                                                                    |
  >-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >-----------------------------------------------------------------------------------------------------------------------------------------|
  |David Hough CFP <pcfp at oakapple.net>,                                                                                                     |
  >-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >-----------------------------------------------------------------------------------------------------------------------------------------|
  |CFP <cfp-interest at ucbtest.org>                                                                                                           |
  >-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >-----------------------------------------------------------------------------------------------------------------------------------------|
  |2014-06-06 08:05 PM                                                                                                                      |
  >-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >-----------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [Cfp-interest] draft of syntax discussion for C committee                                                                            |
  >-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >-----------------------------------------------------------------------------------------------------------------------------------------|
  |cfp-interest-bounces at oakapple.net                                                                                                        |
  >-----------------------------------------------------------------------------------------------------------------------------------------|






On Jun 6, 2014, at 4:25 PM, David Hough CFP <pcfp at oakapple.net> wrote:

> Here are some revisions based on Jim's comments, along with responses
> on some of the comments:
>
> =========================================
>
> DIFF: 36,37c36,44
>
> < traps, but with significant performance penalties for either the normal
case
> < or exceptional case.
> ---
>> traps, but that might entail significant performance penalties for
either
>> the normal case or exceptional case.     Exceptions can be detected
>> inline for each operation with tests on operands and results and flags -
>> slowing down the normal case - or at the end of the try clause with
flags -
>> slowing the detection of the exceptional case (but testing flags alone
does
>> not detect exact underflow exceptions).    Instead of traps,
>> some existing hardware such as
>> PowerPC can exploit its unconventional conditional branch instructions
>> to detect exceptions.

Consider omitting ?unconventional?.

>
> COMMENT:
>
> [
>> Is how to implement alternate exception handling without traps
>> (including for underflow) documented somewhere?
>
> Not that I know of - the general idea is mentioned here; how that works
out
> in detailed code generation depends on the hardware architecture, but we
> could write up some hints that look like C code -
> but I don't think this document is the place for it.

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.)

> ]
>
> =========================================
>
> DIFF: 150,151c157,160
>
> < But having to specify the same exception-list in two different places
> < seems error-prone.
> ---
>> Compilers that would process the catch_fe clauses before generating the
>> try clause code could ignore that pragma.
>> One-pass compilers that encountered discrepancies in catch_fe clauses
>> from the exceptions flagged in advance should probably generate errors.
>
> COMMENT:
>
> [
>> 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.
>
> Actually the simplest method for doing what Jim proposes without
duplicating
> effort might be like this:
>
> {
> #pragma STDC catch_fe fe_exception1 label1
> #pragma STDC catch_fe fe_exception2 label2
>  ... normal case code
> }
>  ... normal case continues here
> label1:
>  ... exception case 1 code
> label2:
>  ... exception case 2 code
>
> You don't need exception lists any more - list one exception at a time
> even if they both go to the same place.
> The above is entirely freed from block structure... or not:
>
> {
> #pragma STDC catch_fe fe_exception1 label1
> #pragma STDC catch_fe fe_exception2 label2
>  ... normal case code
>  break;
> label1:
>  ... exception case 1 code
> label2:
>  ... exception case 2 code
> }
> ... normal case continues here
>
> Putting it into C++ try/catch form requires a way of creating a type
> from an exception name:
>
> try {
> #pragma STDC catch_fe fe_exception1
> #pragma STDC catch_fe fe_exception2
>  ... normal case code
> }
> catch (FE_EXCEPTION_TYPE(fp_exception1) e1) {
>  ... exception case 1 code
> }
> catch (FE_EXCEPTION_TYPE(fp_exception2) e2) {
>  ... exception case 2 code
> }
> ... normal case continues here
>
> FE_EXCEPTION_TYPE is a standard macro that converts an <fenv.h> exception
> like FE_INVALID (which is just an implementation-defined integer
> representing a bit in a field) into a type FE_INVALID_TYPE,
> since C++ style catch works on the type of its argument.
> Whatever is actually in the variable e1 or e2 doesn't matter because it's
> not likely to be in a form useful in a portable program.
>
> I don't regard defining FE_EXCEPTION_TYPE
> as doing the application programmer any favor.
> I'd much rather write
> catch_fe(fp_exception1)
> than
> catch (FE_EXCEPTION_TYPE(fp_exception1) e1)
>
> The point is that it could be made to look more or less like C++
> if that were deemed important enough.
> ]
>
> =========================================
>
> DIFF: 156,160c164,168
>
> < exception handling could be added to C++ with minimal syntactic
> < effort, and most of
> < C++ exception handling could be added to C with minimal syntactic
> < effort.
> < If that compatibility is deemed to be of low value,
> ---
>> exception handling could be added to C++ with less syntactic
>> effort than other possible approaches, and most of
>> C++ exception handling could be added to C with less syntactic
>> effort than other possible approaches.
>> If that compatibility were deemed to cost more than its benefit,

The pragma approach adds nothing to the syntax of the language.

>
> COMMENT:
>
> [
>>> One result of preserving some form of try/catch syntax is that
>>> floating-point
>>> exception handling could be added to C++ with minimal syntactic effort,

>
>> Is this true? Has it been done?
>
>>> and most of
>>> C++ exception handling could be added to C with minimal syntactic
effort.
>
>> Really? We don't have a specification of the changes to C required to
add such syntax.
>
> Neither of these has been done.
> But they would require minimal syntactic effort
> compared to a completely different syntax.

See previous comment.

> That doesn't address the effort to implement the semantics.
> ]
>
> [
>>> If that compatibility is deemed to be of low value
>
>> 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.
>
> I should have used the subjunctive here - I really don't know if there is
> consensus one way or another on the C committee on this point.
> ]
>


_______________________________________________
Cfp-interest mailing list
Cfp-interest at oakapple.net
http://mailman.oakapple.net/mailman/listinfo/cfp-interest


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20140606/92a63836/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20140606/92a63836/attachment-0002.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20140606/92a63836/attachment-0003.gif