[Cfp-interest] Background: How IEEE Exceptions Might have beenImplemented

David Hough CFP pcfp at oakapple.net
Wed Jun 11 14:16:26 PDT 2014


> void my_handler_function(int exceptionFlags) {
>    // ... exception case code ...
> }

> {
>     // ? some code ?
>     #pragma STDC FENV_ACCESS ON
>     fenv_t env; // Can be some other environment we create to keep binary compatibility
>     fe_handle_except(&env, &my_handler_function, FE_INVALID);  // Add exception handler, with the exceptions that should be handled by this handler
>     // ? main case code ?
>     fe_unhandle_except(&env, &my_handler_function, FE_INVALID);  // Remove the exception handler
>     feupdateenv(&env);
> }

If all we want to do is abort or longjump, then a SIGFPE handler
would do the job, though the application programmer would have to manage
the scope.
 
At Sun we actually implemented a lot of this stuff:

http://docs.oracle.com/cd/E19422-01/819-3693/ncg_handle.html#pgfId-10432

Please examine the sample trap-substitute-continue codes.

We spent a lot more time maintaining this infrastructure
than users spent using it,
because handlers weren't portable,
even to the next release of the same hardware
architecture.      Thus the intended target (mathematical software projects
like LAPACK) did not benefit.

One doesn't want to be decoding op codes in application software.


C (unlike Fortran-77) provides malloc/free instead of asking users to
manage blank common as a heap.     My goal here is to bring exception
handling up to roughly the convenience level of malloc/free.




More information about the Cfp-interest mailing list