Notes from meeting 11 Jan 1991

[David Hough]

This meeting was with W. Kahan, Jim Thomas, and Jerome Coonen, to discuss
NCEG and related issues.

Scope of IEEE modes:  
Kahan prefers localizable modes and status
in the sense of APL.  
That is to say, the majority of programs that don't mention IEEE
rounding or trapping modes or exception status
would inherit the calling environment
and if they modified it, the caller would inherit the modified
environment.  Thus there would be no performance penalty in the 
normal case, for the modes and status would be like global
variables.

But modes declared staticly in the source code for
a module would be treated differently, more like automatic variables.  
Those modes would inherit
the caller's value unless an initial value were specified in the source
code, but the caller's value would revert on exit from the callee.

Some symbol table support would be required in order to support trap handlers
that wanted to be able to figure out how a module was staticly compiled,
in order to do something appropriate.

Retrospective diagnostics log:
Recent Sun Fortran products, for instance, have provided retrospective
IEEE exception summaries based on what can be inferred cheaply from 
hardware status bits.  These tell you what exceptions occurred but give
no clue where, relative to source code.

To do more, there should be a (small finite) log of the first occurrence
of each exception that contains information about what happened and where
in the source code to look for further clues.  This requires intervention
between the hardware IEEE floating-point trap and the user-level SIGFPE
handler; the hardware exception-occurred bits are replaced conceptually
by pointers to exception-occurred records containing details.  Among the
details are a stack traceback
containing pointers to the offending basic block in the source code.
This requires some sort of milestone symbol table support; simply reporting
PC's isn't too helpful on highly pipelined systems.  The RS/6000
has some hardware support of this type.

Presubstitution:
The most one can expect to be able to do from a SIGFPE handler on a 
high-performance system is to set a global variable and return or
longjump to someplace else.  It's hard to imagine a capability for
altering operands or results of exceptional operations and continuing
after the fact.

To do more, one would like to be able to instruct the hardware on what to
do in advance of a possible exception, for the cases when IEEE defaults
aren't what's wanted.  Some possible menu choices for each exception:

	IEEE defaults

	Language-defined results

	trap/signal/abort

	invoke debugger	and pause, as if at a breakpoint
This requires the ability to return and continue from a signal handler
after an exception.

	counting mode for underflow/overflow (counting mode could also
be handled staticly by defining distinct counting-mode + - * op codes
in the hardware architecture and language definition).

	other pre-substituted results appropriate to exception and
application, e.g.
	MAX{FLOAT,DOUBLE,etc.} for overflow or division by zero
	zero for underflow or invalid

Three operand addition:
Most people know by now that IBM RiscSystem/6000 has a multiply-add
that incurs only one rounding error.  Perhaps inspired by that, some other
people are looking at three-operand add with just one rounding error.
This would have application to complex multiply-add
and to fabricating doubled-precision arithmetic based on the paradigm

	z = x + y
	w = (z - x) - y

Thinking about it for an architecture like SPARC with a maximum of three
source/destination register specifiers, 
an orthogonal set of such operations might include

	z = z + (x + y)
	z = z + (x - y)
	z = z - (x + y)
	z = (z + x) + y
	z = (z + x) - y
	z = (z - x) + y
	z = (z - x) - y

That's beginning to add up to a lot of op codes, in addition to the
interesting hardware question of how to efficiently implement a three-
operand add.