<html><head><base href="x-msg://151/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" 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="stopSpelling">From:<span class="Apple-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="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>CC:<span class="Apple-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="Apple-interchange-newline"></blockquote></div><br></body></html>