Re: Thoughts about a floating point exception fix

["Maciej W. Rozycki" <macro%linux-mips.org@localhost>]

On Fri, 8 Feb 2019, Mouse wrote:

> >> How does that differ from just using reserved operands (which the
> >> hardware already knows how to fault on)?  Would the simulated FP
> >> include things operationally like infinities or quiet NaNs [...]?
> > I still don't understand what exactly needs to be fixed in the
> > software (and if we have to do it in pkgsrc because upstream is
> > stupid, so be it).
> 
> I don't understand details myself - I do not have the luxury of playing
> with VAXen at present - but, based on upthread comments, it looks to me
> as though python and/or awk have testsuites that rely on infinities and
> NaNs, possibly as well as details such as you mention, exact ranges and
> underflow/overflow points and such.

 Well, if it's only test suites that suffer from problems, then I think it 
should be fairly straightforward to fix them by disabling the respective 
tests (or better yet create suitable alternatives) for targets, such as 
the VAX, that have different FP semantics.  Another case would be the 
Sony/Toshiba R5900 MIPS processor core aka Emotion Engine used with the 
PS2 video game console, which also has a non-IEEE-754 FPU, which has no 
NaNs or infinities and doesn't do exceptions at all.

 What might be a problem it is programs that rely on IEEE-754 denormals.  
I have learnt it the hard way when trying to get GCJ and especiallythe GNU 
Classpath library ported to VAX many years ago (the Java language standard 
explicitly asks for IEEE-754 FP).  The lack of support for denormals also 
was the ultimate reason why the VAX FP format lose the battle[1].

 NB GCC does soft float out of the box, although you obviously have to 
wire the target backend to handle it.

 Hard-float and soft-float object code interlinking should be doable too, 
however I think that would be a considerable effort (if we wanted to have 
IEEE-754 soft-float FP, that is; VAX soft-float FP interlinking would be 
trivial to do owing to the lack of a separate FPR set, but it would be 
obviously missing the point here), because we'd have to introduce function 
call/return stubs aka thunks for the purpose of range conversion.  That 
would have to be handled by the linker somehow, taking into account the 
arcane semantics of the CALLS instruction, with dynamic loading in mind 
too.

References:

[1] "An Interview with the Old Man of Floating-Point",
    <https://people.eecs.berkeley.edu/~wkahan/ieee754status/754story.html>

  Maciej