endian neutral TextToFloat

[jaykrell]

For endian neutrality of C++ backend output, I propose roughly:

Add to existing interface IEEE:

TYPE Sign = [0..1];
TYPE Exponent32 = [0..16_FF];
TYPE Significand32 = [0..16_7FFFFF];

(* For historical reasons a float64 can be considered
 * as having its significand split into two pieces.
 * This is presumably so the pieces fit in 32bit INTEGER.
 * A fair amount code uses this idea.
 * so unfortunately we favor it here.
 *)
TYPE Exponent64 = [0..16_7FF];
(*TYPE Significand64 = [0L..16_FFFFFFFFFFFFFL]; *) (* 52 bits *)
TYPE Significand64_0 = [0..16_FFFFF];
TYPE Significand64_1 = [-16_7fffffff-1..16_7fffffff];
(*
TYPE Float64 = RECORD
    sign         : Sign          := 0;
    exponent     : Exponent64    := 0L; (* 11 bits *)
    significand  : Significand64 := 0L; (* 52 bits *)
END;
*)
TYPE Float64 = RECORD
    significand1 : Significand64_1 := 0; (* 32 bits *)
    significand0 : Significand64_0 := 0; (* 20 bits *)
    exponent     : Exponent64      := 0; (* 11 bits *)
    sign         : Sign            := 0;
END;

TYPE Float32 = RECORD
    significand : Significand32 := 0; (* 23 bits *)
    exponent    : Exponent32    := 0; (* 8 bits *)
    sign        : Sign          := 0;
END;

PROCEDURE Unpack32 (r:REAL) = Float32;
PROCEDURE Unpack64 (r:LONGREAL) = Float64;

PROCEDURE Pack32 (READONLY r:Float32) = REAL;
PROCEDURE Pack64 (READONLY r:Float64) = LONGREAL;

PROCEDURE SetSign32 (VAR a: REAL; sign: Sign);
PROCEDURE SetExponent32 (VAR a: REAL; Exponent32);
PROCEDURE SetSignificand32 (VAR a: REAL; significand: Significand32);

PROCEDURE GetSign32 (a: REAL): Sign;
PROCEDURE GetExponent32 (a: REAL): Exponent32;
PROCEDURE GetSignificand32 (a: REAL): Significand32;

PROCEDURE SetSign64 (VAR a: LONGREAL; sign: Sign);
PROCEDURE SetExponent64 (VAR a: LONGREAL; Exponent);
PROCEDURE SetSignificand64_0 (VAR a: LONGREAL; significand0: Significand64_0);
PROCEDURE SetSignificand64_1 (VAR a: LONGREAL; significand1: Significand64_1);

PROCEDURE GetSign64 (a: LONGREAL): Sign;
PROCEDURE GetExponent64 (a: LONGREAL): Exponent;
PROCEDURE GetSignificand64_0 (a: LONGREAL): Significand64_0;
PROCEDURE GetSignificand64_1 (a: LONGREAL): Significand64_1;

For easier source transform, Unpack/Pack is more likely to be used then Get/Set.

This is all trivial to provide.

An example would be like:

+++ b/m3-libs/libm3/src/random/IEEE/RandomReal.m3
@@ -9,7 +9,7 @@

 UNSAFE MODULE RandomReal;

-IMPORT LongRealRep, RealRep, Random, Word;
+IMPORT IEEE, Random, Word;

 (* Implements Random.Real and Random.LongReal for IEEE floating-point
    format (both big-endian and little-endian). *)
@@ -41,13 +41,13 @@ PROCEDURE Real (r: Random.T): REAL =
     END;

     (* Repack as REAL: *)
-    WITH r = LOOPHOLE (result, RealRep.T) DO
+    WITH r = IEEE.Unpack32 (result) DO
       r.sign := 0;
       r.exponent := exp;
       r.significand := Word.Shift (Word.And (frac, 16_7fffffff),
                                    -(WordSize - 1 - FractionBits));
+      RETURN IEEE.Pack32 (r);
     END;
-    RETURN result;



 PROCEDURE Longreal (r: Random.T): LONGREAL =
@@ -77,14 +77,14 @@ PROCEDURE Longreal (r: Random.T): LONGREAL =
     END;

     (* Repack as LONGREAL: *)
-    WITH lr = LOOPHOLE (result, LongRealRep.T) DO
+    WITH lr = IEEE.Unpack64 (result DO
       lr.sign := 0;
       lr.exponent := exp;
       lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff),
                                       -(WordSize - 1 - FractionBits));
       lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff);
+      RETURN IEEE.Pack64 (lr);
     END;
-    RETURN result;
   END Longreal;

Question then..surverying users of RealRep / LongRealRep..Peter do you mind if I change TextToFloat here?

Rep.T appear in its interface.

[jaykrell]

@demoitem

[jaykrell]

I suppose I can try omitting that code from the bootstrap..is already is really..

[jaykrell]

i.e This proposal does not take away the existing endian specific IEEE interfaces, it add new ones.

[demoitem]

No objection go for it

[jaykrell]

I am taking a kinda more conservative approach..
While I am adding stuff...and changing some stuff... I think your code, other than adding to your files, might be unchanged.

There is a bit of a catch though..maybe. You know, Grisu is excluded from C++ bootstraps currently...for a "bad" reason, to be fixed, maybe already fixed. For that reason.. it doens't matter. Currently.

What I do is I built big and little endian bootstraps and compare them.
They are almost identical.
Where things are different, I try to remove or "converge".
Your stuff is absent currently. it might get added later.

But the above is still a draft of what happens elsewhere, and maybe here, so thank you for the approval.

[jaykrell]

I think think we should lift IEEE up a directory, as a separate minor matter. Later.

[jaykrell]

Ultimately the present RealRep / LongRealRep will be gone from bootstrap cm3/m3core, but present as normal in normal m3core.
All uses directly or indirectly by cm3 need visit.. I am doing it.. for example you can see I removed the ordered table from m3c.