[M3devel] LONGINT in frontend?

Jay K jay.krell at cornell.edu
Sun Nov 21 19:08:53 CET 2010


Isn't it at least better than current situation of using INTEGER?
I understand in the future LONGINT might not suffice and Target.Int might be desired.
But today LONGINT suffices and lets more things work.


Granted you can no longer compile with older compilers.


Surely what we could at that time is introduce INTEGER128.
Bootstrap "with restrictions" first like today, extending Target.Int where it is already used,
and then go and use INTEGER128 instead of LONGINT in the frontend and reremove the restrictions?


And perhaps by then have switched LONGINT to Target.Int?
Perhaps by then we'll have operator overloading in Modula-3?


 - Jay

From: hosking at cs.purdue.edu
Date: Sun, 21 Nov 2010 10:44:40 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LONGINT in frontend?



The reason I am nervous about LONGINT is that it assumes we can model all target INTEGER/LONGINT as host LONGINT.  There is no guarantee of this.  Target.Int can always be extended to model target values that are bigger than the host's INTEGER/LONGINT.


On Nov 20, 2010, at 7:26 PM, Jay K wrote:Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail.
  Operators are nice. e.g. defining them for user defined types.


In some places, things are limited by an INTEGER number of bits.
In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64:


 (* DIV BITSIZE should not be here! *)
 (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *)
 MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64);


Possibly due to ArrayType.m3:

    IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN
      Error.Msg ("CM3 restriction: array has too many elements");
      p.n_elts := 1;
    END;

or

    IF (p.n_elts > 0) AND (p.elt_pack > 0)
      AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN
      Error.Msg ("CM3 restriction: array type too large");
      full_size := 0;
      p.total_size := 0;


or ArrayExpr.m3:


      IF NOT TInt.ToInt (nn, n) THEN
        Error.Msg ("array has too many elements");
      END;


Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone.
You end up having to replace many instances of INTEGER, and then all the uses.
With LONGINT, perhaps, you can just change the types and not have to visit every single use. 


 - Jay

From: hosking at cs.purdue.edu
Date: Sat, 20 Nov 2010 11:35:21 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LONGINT in frontend?

Target.Int is appropriate here, not LONGINT.Where is the current 2Gbyte limit encoded?

On Nov 20, 2010, at 3:43 AM, Jay K wrote:How about we use LONGINT a bunch in the frontend
instead of INTEGER? Either that, or Target.Int.
I do think 32bit frontend should be able to target
64bit target, including declaring data structures
larger than 2GB. (besides that the current limit
is 2 billion bits, not bytes like it should be..)

LONGINT is easier.

I won't get to either for a little while, other stuff first.

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101121/26c27d94/attachment-0002.html>


More information about the M3devel mailing list