<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
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.<br>There are plenty of files and volumes over 2GB in size manipulated by 32 bit code.<br> The 32-bit world will continue for a while -- phones, iPad, etc. But yet iPad is available with 64GB storage.<br>Are the 53bits of precision in double for migration to a 53bit world?<br><br>I agree the *name* LONGINT is a hack though, in the poor tradition of C's "long long".<br>
<br>Again again again, 32bit host C compilers have been targeting 64bit targets for a very long time and continue to do so.<br> And I would hope they don't have the same problem we have.<br> I know gcc has this "HOST_WIDE_INT" for this reason -- long long for 32bit hosts targeting 64bit.<br> Obviously a bit inefficient, but probably really ok and worth it.<br><br>Also, again, I believe our limit is in number of bits, not bytes. So it is even too small for native builds.<br> But I agree, maybe not easy to fix, if the problem is real (I think it is). Bit counts are convenient.<br> I guess maybe this is a good reason to extend Target.Int another byte?<br><br> - Jay<br><br><hr id="stopSpelling">From: hosking@cs.purdue.edu<br>Date: Sun, 21 Nov 2010 13:35:21 -0500<br>To: jay.krell@cornell.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] LONGINT in frontend?<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">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. <br>
<br><div><div>On Nov 21, 2010, at 1:08 PM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;">Isn't it at least better than current situation of using INTEGER?<br>I understand in the future LONGINT might not suffice and Target.Int might be desired.<br>But today LONGINT suffices and lets more things work.<br><br><br>Granted you can no longer compile with older compilers.<br><br><br>Surely what we could at that time is introduce INTEGER128.<br>Bootstrap "with restrictions" first like today, extending Target.Int where it is already used,<br>and then go and use INTEGER128 instead of LONGINT in the frontend and reremove the restrictions?<br><br><br>And perhaps by then have switched LONGINT to Target.Int?<br>Perhaps by then we'll have operator overloading in Modula-3?<br><br><br> - Jay<br><br><hr id="ecxstopSpelling">From:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Sun, 21 Nov 2010 10:44:40 -0500<br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] LONGINT in frontend?<br><br>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.<br><br><div><div>On Nov 20, 2010, at 7:26 PM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;">Target.Int is onerous, due to no operators (+, -, *, <, =) and everything can fail.<br> Operators are nice. e.g. defining them for user defined types.<br><br><br>In some places, things are limited by an INTEGER number of bits.<br>In m3core/TextLiteral.i3 fiddle with this and cross from 32bits to 64:<br><br><br> (* DIV BITSIZE should not be here! *)<br> (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *)<br> MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64);<br><br><br>Possibly due to ArrayType.m3:<br><br> IF NOT TInt.ToInt (Type.Number (p.index), p.n_elts) THEN<br> Error.Msg ("CM3 restriction: array has too many elements");<br> p.n_elts := 1;<br> END;<br><br>or<br><br> IF (p.n_elts > 0) AND (p.elt_pack > 0)<br> AND (p.n_elts > MAXSIZE DIV p.elt_pack) THEN<br> Error.Msg ("CM3 restriction: array type too large");<br> full_size := 0;<br> p.total_size := 0;<br><br><br>or ArrayExpr.m3:<br><br><br> IF NOT TInt.ToInt (nn, n) THEN<br> Error.Msg ("array has too many elements");<br> END;<br><br><br>Clearly it should work and it isn't difficult, but it is very very tedious and therefore also error prone.<br>You end up having to replace many instances of INTEGER, and then all the uses.<br>With LONGINT, perhaps, you can just change the types and not have to visit every single use.<span class="ecxApple-converted-space"> </span><br><br><br> - Jay<br><br><hr id="ecxstopSpelling">From:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Sat, 20 Nov 2010 11:35:21 -0500<br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] LONGINT in frontend?<br><br>Target.Int is appropriate here, not LONGINT.<div>Where is the current 2Gbyte limit encoded?<br><br><div><div>On Nov 20, 2010, at 3:43 AM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;">How about we use LONGINT a bunch in the frontend<br>instead of INTEGER? Either that, or Target.Int.<br>I do think 32bit frontend should be able to target<br>64bit target, including declaring data structures<br>larger than 2GB. (besides that the current limit<br>is 2 billion bits, not bytes like it should be..)<br><br>LONGINT is easier.<br><br>I won't get to either for a little while, other stuff first.<br><br> - Jay</div></span></blockquote></div><br></div></div></span><br class="ecxApple-interchange-newline"></blockquote></div><br></div></span><br class="ecxApple-interchange-newline"></blockquote></div><br> </body>
</html>