How do you get a SIGFPE out of RIOS?

[David Hough]

Thanks to John Mashey for digging up the following.  Recall that IEEE 754
recommends but does not require precise continuable traps after floating-point
exceptions.  Such traps are part of the SPARC architecture, for instance,
but have a significant impact on high-performance implementations,
which IBM elected not to pay by default.  Ironically, one reason that I
was able to get precise continuable traps into SPARC was that one of
the SPARC project managers had endured severe abuse from customers for his
part in the design of the 360/91 floating point.

> Date: Mon, 29 Oct 90 11:51:19 -0800
> From: mashamips.com (John Mashey)
> 
> >From IBM J Res & Dev, Vol 34, No 1, January 1990 (IBM RS/6000 issue)
> 
> p.33-34 (CAPITALS MINE)
> "Another very important aspect of fully exploiting floating-point performance
> is the method of presentation of floating-point exceptions and the precision
> in identifying the instructions that cause floating-point exceptions.
> Exceptions are a natural and perhaps expected consequence of floating-point
> operations, and most can be handled by default rules.  (Default exception
> handling is defined by the IEEE standard.)  These default rules can be
> managed completely in hardware and require no program intervention after
> initialization.
> 
> The IEEE default rules do not always provide the desired result, however.
> Since the standard allows for a program fix-up after an exception, the
> architecture problem is then to define a mechanism to permit program fix-up.
> The most straightforward approach is to specify that a floating-point
> interrupt at the failing instruction will occur whenever there is a
> floating-point exception that is not defaulted.  The hardware implication
> of this is that all instructions after a floating point instruction must
> be conditional until it is know that no exceptions are possible on that
> instruction.  Some floating point instructions take many cycles, and exceptions
> may not be known until the last cycle of the instruction.  Therefore, most
> implementations would serialize on floating-point instructions-if not the
> first, then the second; if not all, then some.  The inclusion of a floating-
> point interrupt would sacrifice much of the potential floating-point
> performance.
> 
> AN ALTERNATIVE STRATEGY IS NOT TO REPORT AN INTERRUPT AT ALL, BUT SIMPLY TO
> SET A BIT INDICATING THAT A FLOATING-POINT EXCEPTION HAS OCCURRED.  IT IS
> THEN UP TO A PROGRAM TO TEST FOR FLOATING-POINT EXCEPTIONS.  Different
> compiler strategies can be used as to where it is appropriate to test for
> these exceptions.  Since the definition of the exception also includes the
> setting of summary information, it is possible to test at the end of a program,
> at the end of a subprogram, or at the end of a statement where a floating-point
> operation was used.  This level of precision can be controlled by
> linker/compiler option.  None of these tell exactly where the exception
> occurred; they simply identify where it occurred.  In most cases, this
> information is sufficient.
> 
> However, if the exact failing instruction must be known, there are two
> possible strategies.  One can insert a test for the exception after each
> floating-point instruction, or one can tag each queued and/or executing
> floating-point instruction with its address.  Inserting code to test for
> every possible exception is yet another mode for the compiler to manage,
> necessitates recompilation, and can significantly expand execution time.
> Address tagging of "active" floating-point instructions identifies the
> failing instruction exactly.  However, it does require that the
> implementation keep track of the address tags.  Moreover, it is not
> synchronous; that is, if an exception occurs, the location of the
> failing instruction is reported, but not before the program
> has gone beyond that point.  Fix-up may still be possible, but in general
> this method only permits localization of the failing instruction.
> Consider the case of the inner-loop product described in Figure 7.
> This loop consists of two floating-point loads, one floating-point
> multiply-add, and one branch.  The "active" floating-point instructions
> will all be instances of the same multiply-add instruction.  If an
> exception occurs, what is know is the address of the instruction, not
> the iteration number.  The benefit of this approach is speed; floating-point
> performance is not limited by exception recognition.  The drawback, as
> outline above, is the precision with which the fault is determined.
> 
> RISC System/6000 architecture adopted a two-part strategy.  THE PRINCIPAL
> APPROACH WOULD BE TEST-CODE INSERTION, with the compilers able to insert
> such code at the statement or (sub)program level.  The linker also
> supports the enabling of test code at program exit, ensuring the ability 
> to report a floating-point exception if it occurs anywhere within the
> program.
> 
> To avoid recompilation in order to identify the failing operation exactly,
> the architecture also adopted a synchronize mode, in which an interrupt
> can be generated, identifying the failing instruction by running the
> machine with one floating-point instruction dispatched at a time.  This
> technique has the same weakness as code insertion; THAT IS, FLOATING-POINT
> PERFORMANCE IS GREATLY REDUCED.  However, it may not be as bad as code
> insertion, because the synchronization can be managed by hardware rather than
> by extra code inserted by software.  It is expected that the mode will only
> by extra code inserted by software.  IT IS EXPECTED THAT THE MODE WILL ONLY
> BE USED BY CERTAIN PROGRAMS AND THEN ONLY TO DEBUG THEIR ALGORITHMS."
> 
> p.54:
> 
> "The fixed-floating-point synchronization scheme ensures that precise
> interrupts are maintained between the fixed- and floating-point units.
> SINCE NO FLOATING-POINT INSTRUCTIONS COULD CAUSE INTERRUPTS IN AMERICA,
> the remaining need was to synchronize the branch-processing unit with
> the fixed-point unit.