[MLton] ARM and setRoundingMode

[Matthew Fluet]

On Mon, 13 Apr 2009, Adam Goode wrote:
> I am bootstrapping MLton for Fedora ARM. Everything seems to be
> working well, but the target hardware is software floating point,
> which on ARM doesn't implement non-default IEEE rounding modes.
>
> According to
> http://www.standardml.org/Basis/ieee-float.html#SIG:IEEE_REAL.setRoundingMode:VAL
> if the hardware doesn't support a rounding mode, setRoundingMode
> could raise an exception for unsupported modes. This is detectable
> when fesetround returns a non-zero value.
>
> Should MLton do this? What exception should be used? It would
> be nice to know when setRoundingMode fails.

Agreed that an exception should be raised; though, since failing to 
support all of the rounding modes automatically makes an implementation 
non-conforming, I guess the Basis Library specification need not specify 
the exception.  I looked at the source code for SML/NJ and for Poly/ML, 
and neither of them appear to have a code path for a failed 
setRoundingMode.

It seems to me that there are two reasonable exceptions:

   General.Domain

or

   OS.SysError ("inval", OS.syserror "inval")

The latter seems better, because it indicates a system dependent error; 
General.Domain seems to be limited to mathematical functions.  Although, 
the OS.SysError exception usually comes from an errno value, there are a 
few places where inval is raised directly.