Real.maxFinite and friends

[Matthew Fluet]

> Yes, reals are overloaded just like ints.  No, the open's above don't establish
> context (just like open doesn't for int).  I.E. both r1 and r2 above would have
> the same type, Real.real.

But
val r1 : Real80.real = 0.0
val r2 : Real32.real = 0.0
should work?

> 1. Have all three structures, Real32, Real64, and Real80.

Reasonable.

> 2. Real = Real80.

Yes, although this will need to be clearly documented.

> 3. Real64 behaves according to the -ieee-fp flag.

I.e., -ieee-fp affects the behavior of Real64.

> 4. Real32 and Real80 do not depend on -ieee-fp.

I don't see why Real32 shouldn't depend on -ieee-fp.  Certainly Real80
doesn't matter.

> 5. Real32.real (float) and Real64.real (double) are allowed to be used in FFI's,
>    and Real80 is not.  I.E. No implicit coercion.

Agreed.

> 6. The following Real.x are all _prims
> 	x = maxFinite minNormalPos minPos negInf posInf Math.pi Math.e

Good; the caveat being that they are_prims at each Real?? type/size.

> 7. The values of the Real constants in (6) are all hardwired into the compiler.
>    I.E. there is no use of lookup-constants.  Each codegen knows how to spit
>    out the appropriate bits in either a .c or .s file.

My previous concerns about lookup-constants was motivated by the fact that
I thought all nullary prims were handled by lookup-constants.  (And,
looking at the code, I still think that is true.)  In any event, there's
no way to "spit out the appropriate bits" in the codegen -- there is no
load floating point constant.  I still suggest using a Real_const.S file
in the runtime with each of the constants and their appropriate bits.