[M3devel] LONGINT in frontend?

[Tony Hosking]

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/bd7409b7/attachment-0002.html>