[M3devel] LONGINT in frontend?

[Jay K]

I disagree there also. 32bit addresses/size_t and 64bit quantities can be mixed reasonably, and have been for a very long time in a *lot* of code.
There are plenty of files and volumes over 2GB in size manipulated by 32 bit code.
 The 32-bit world will continue for a while -- phones, iPad, etc. But yet iPad is available with 64GB storage.
Are the 53bits of precision in double for migration to a 53bit world?

I agree the *name* LONGINT is a hack though, in the poor tradition of C's "long long".


Again again again, 32bit host C compilers have been targeting 64bit targets for a very long time and continue to do so.
  And I would hope they don't have the same problem we have.
  I know gcc has this "HOST_WIDE_INT" for this reason -- long long for 32bit hosts targeting 64bit.
  Obviously a bit inefficient, but probably really ok and worth it.

Also, again, I believe our limit is in number of bits, not bytes. So it is even too small for native builds.
  But I agree, maybe not easy to fix, if the problem is real (I think it is). Bit counts are convenient.
  I guess maybe this is a good reason to extend Target.Int another byte?

 - Jay

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



I don't think we are at all convinced that the current LONGINT is anything other than a hack to allow migration from a 32-bit to a 64-bit world.  


On Nov 21, 2010, at 1:08 PM, Jay K wrote: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/37a88bed/attachment-0002.html>