Real.maxFinite bug

[Matthew Fluet]

> I'm  confused:  isn't  Real.isFinite  going to be a primitive?  If it is then
> only the back  end  needs  to  know  what  code  (assembler)  to  emit.   For
> Real.maxFinite  and  friends,  again,  the  compiler  just has to know how to
> define the bits.

Not sure the context you're responding to.  

It is certainly possible to implement Real.isFinite as a primitive.

> > Shouldn't Real.isFinite be handled in native code?  Since you have to store
> > the floating point number in memory any way the cost probably isn't horrible,
> > but still it seems a bit strange.
>
> Primitive.Real.isFinite could be defined as an _prim instead of an _ffi. I'll
> leave it to Matthew to decide if he can do any better in the native codegen 
> than calling the Real_isFinite.

In my response to this email, I was noting that the cost of implementing
something as an FFI as opposed to a prim, is that C calling convention
will force the float stack to be emptied.  So, there is more memory
traffic than that single float.

Turns out that it is even worse.  Gcc won't turn
bool Real_isFinite(double d) { return finite(d); }
into a tail-call, so we actually copy the float one more time.

In short, some tight loop, like the calculation of maxFinite, would
probably benefit from Real.isFinite as a primitive.


The other, and, as you note, orthogonal issue is the Real.maxFinite and
Real.min* constants.  I'm proposing defining them like

val maxFinite = let
		  val maxFiniteBytes : Word8.word 
                    = Word8Vector.fromList [...]
                in
                  PackReal.fromBytes maxFiniteBytes
                end

Now, because PackReal.fromBytes calls an ffi function, this won't evaluate
to a constant at compile time.