On Sun, 6 Aug 2023, Mouse wrote:
I think it's more likely that an algorithm expects a division by zero
or a range overflow to silently produce an infinity or NaN rather
than trap.
Possibly, but I'd expect that to produce a divide-by-zero trap. Divide
by zero and floating overflow are distinct when generated by the
hardware (the both use the "arithmetic exception" SCB slot, but they
push different type codes). I don't have a recent VAX trap.c at hand
to check, but the 5.2 one does draw the distinction:
case T_ARITHFLT|T_USER:
sig = SIGFPE;
switch (frame->code) {
...
case ATRP_FLTOVF: code = FPE_FLTOVF; break;
case ATRP_FLTDIV: code = FPE_FLTDIV; break;
...
}
Of course, I also have no specific reason to think that the message
printed is accurate, just general faith that nobody would commit code
that maps FPE_FLTDIV into "Floating point overflow".
Good point, but that leaves a range overflow expecting to produce an
infinity still a valid possibility.
Though, hmm, it has struck me that the program might expect the IEEE 754
exponent range of the double FP type, which raises a question: which of
D_floating and G_floating format has our port chosen? If it's G_floating,
then I'd expect the very narrow difference from IEEE 754 double highly
unlikely to hit, however with D_floating where the width of the exponent
is the same as with F_floating, i.e. the single FP type, it's actually
very likely.
Overall I think we ought to support both, but it might be a bit tricky on
the toolchain side, as it's an ABI issue to sort out. Did any machine
actually implement H_floating in hardware, or was it only ever emulated?