[J3] [EXTERNAL] Re: Exception handling in one Ada processor

[Van Snyder]

On Fri, 2019-07-26 at 10:18 +0900, Malcolm Cohen via J3 wrote:
> >The example in my paper
> >caught overflow or underflow to allow computing the L2 norm of a
> vector
> >by the obvious (and fast) method, unless an overflow or underflow
> >occurs.
> 
>  
> 
> After telling us that exceptions were for truly exceptional cases not
> ordinary ones, you have this very ordinary example.

One does expects overflow and underflow to be exceptional, not common,
occurrences during computation of the L2 norm.

> > Without exceptions, one needs to use the slower method that
> >checks at every step.
> 
>  
> 
> Not so. One just checks the IEEE flags at one’s own convenience. Which
> would presumably not be within the innermost loop. But if it’s a long
> vector waiting to the end might also be a suboptimal choice.

Checking the processor's overflow or underflow flag at every step is
suboptimal.  Checking at the end is suboptimal (e.g., if overflow occurs
during the first product out of, say, a million).  Checking "at one's
own convenience" would result in a complicated algorithm.  Does one
check every ten steps?  After every 10% of the steps?  Does one use a
calculation relating the cost of multiply-add to the cost of checking a
flag, which would be fragile, inscrutable, and non-portable?

> Using an exception handling mechanism just means the compiler inserts
> the checks. Without any user control, and so could very well be a
> suboptimal choice.

One could always choose to check flags explicitly instead of doing the
calculation in a block that has an associated exception handler.  This
decision ought to be based upon profiler results rather than a
labor-expensive premature optimization.

> (If you’re thinking the hardware might help cut the evaluation short
> with some kind of “IEEE trapping” behaviour, think again. Some
> hardware has an order of magnitude slowdown if traps are enabled, some
> other hardware simply does not support IEEE traps at all.)

"Some hardware" means the "under-the-covers" method is processor
dependent.  Is that a surprise?  The processor would know whether traps
exist, or that they're more expensive than flag testing, and generate
appropriate code if exception detection is enabled.

Penalizing trapping seems to be a defect in processor design.  I
remember processors that did not have any penalty for having overflow
and underflow traps turned on.  It seems a bit strange that processors
now penalize for it.  I can't think of a reason for the penalty to be
inevitable, but then, I'm not a processor designer.  Whether a processor
detects an overflow exception using flag testing or traps would be
hidden "under the covers" if exception detection and handling were
provided by the standard.

> This example is in any case handled well by our existing IEEE support.

It's handled by our existing IEEE support, but in what would be a
suboptimal way (i.e., not "well") if processors have traps that one is
not penalize for having them turned on.  Without exception handling, one
would have to insert code that tests the flags, which has a nonzero
labor cost (and risk of incorrectness).

If having exception handling implies that (some) processors would insert
tests that users would have to insert (rather than turning traps on),
that's a labor savings.  The cost of "owning" software throughout its
lifetime includes both labor cost and operational computing cost.

And this was just one example, mentioned in response to the assertion by
William Clodius in this thread that exceptions are only useful for
reporting errors.

> Cheers,
> 
> -- 
> 
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
> 
> 
>  
> 
>