[M3devel] Open CM3 regression tests

[Mika Nystrom]

Olaf Wagner writes:
...
>I don't really understand the consequences of what you say above:
>are the tests wrong and should be adapted, or is the implementation
>broken for IEEE-default (where most of the FloatMode procedures simply
>raise exceptions; if so, can we fix that for these platforms), or do
>we simply rely on broken hardware (x86 floating point processors)?
>
>It seems that FloatMode is only implemented for very few targets:
>DS3100 DS3100_OSF IRIX5 SOLsun SPARC SUN386 VAX. All the others use
>the default. Will we simply have to implement the missing functionality
>for all platforms? If so, can e.g. SUN386 be easily adapted to other
>x86 platforms (FreeBSD4, LINUXLIBC6, I386_DARWIN, NetBSD2_i386)?
>That would be a start.

Hmm this reminds me of something I read a long time ago.  My
recollection is that what we have is effectively the second
implementation of floating point in Modula-3.  At some point during
the design, I think someone talked to Bill Kahan, and he (or someone
like him) persuaded them that the only right way to do floating-point
is to provide an interface for turning on and off floating point
exceptions.  I believe that at least on DS3100, the floating point
exceptions (if enabled) are actually turned into bona fide, catch-able,
Modula-3 exceptions.  It's a little odd because I suppose you can
have code like this...

   TRY 
     x := a/b
   EXCEPT
     SomeFloatingException ...
   END

even though no exceptions are declared to be RAISEd anywhere...

I think very few programming languages actually support IEEE754 the
way Kahan originally envisioned it.  Modula-3 on DS3100 is one of
the few that actually approach the original intent (most of the
others have "fortran" somewhere in their names, and usually only
accomplish the goal with compiler flags).  It would be very neat
if this work could be extended to the modern targets.

x86 FP also isn't really that broken---the 8087 was actually to
some extent the reference implementation of IEEE754.  It works fine
if you write back the results between operations.  The problem is
that it uses higher (EXTENDED) precision internally, so if you keep
intermediate values in FP registers you get smaller rounding errors
than expected.  It's mainly a problem if you are doing step-by-step
comparison debugging with an x86 and a non-x86 and you can't somehow
tell your compiler to flush intermediate results to memory.

    Mika