Real.maxFinite and friends

[Stephen Weeks]

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

Right.

> > 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.

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.

Yes.

> > 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.)

Agreed.

> 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.

I think our only difference is that I was suggesting that the compiler spits out
whatever's in Real_const.S into the generated .S files.  But, upon further
reflection, using one Real_const.S shared among backends seems easier.  So,
we're in complete agreement.