<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>Should we just be a little lax and say minus 64?</div><div>Or pick some other number like 256MB?</div><div><br></div><div>Can we declare there is no bound?</div><div><br></div><div>Thank you,</div><div> - Jay<br><br><br></div><div>> Date: Wed, 3 Jun 2015 14:23:07 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com; jay.krell@cornell.edu<br>> Subject: Re: [M3devel] TextLiteral.MaxBytes again (unable to compile 64bit target on 32bit host)<br>> <br>> <br>> <br>> On 06/02/2015 09:51 PM, Jay K wrote:<br>> > Ideally:<br>> > 1 32bit host could target 64bit target<br>> > 2 32bit texts could be as large as the address space/OS allows.<br>> > 3 ditto 64bit texts -- larger than 4GB<br>> > 4 be unpicklable between 32bit and 64bit, as long as they fit into the address space.<br>> > Currently only #4 is true.<br>> > TEXTs for any target can only be about 500MB.<br>> ><br>> ><br>> > To fix 2 and 3 requires m3front to use TInt more.<br>> ><br>> > This fixes #1 and likely breaks #4. Cutting the limit just a little.<br>> > Can we special case somehow?<br>> > Is there some construct we can use that has no stated limit, like 0..cnt - 1?<br>> > Should/can we introduce one?<br>> ><br>> > jbook2:src jay$ git diff "../src/text/TextLiteral.i3"<br>> > diff --git a/m3-libs/m3core/src/text/TextLiteral.i3 b/m3-libs/m3core/src/text/TextLiteral.i3<br>> > index fa72589..4d16a44 100644<br>> > --- a/m3-libs/m3core/src/text/TextLiteral.i3<br>> > +++ b/m3-libs/m3core/src/text/TextLiteral.i3<br>> > @@ -14,7 +14,7 @@ IMPORT RTHooks, TextClass;<br>> > CONST<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;<br>> > + MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 15;<br>> <br>> I'd say go ahead and change this. We really do want it to cross-compile<br>> sooner than anybody will be able to put TInt in all over the place.<br>> <br>> I did not build a cross compiler, but did what I think should be a realistic<br>> simulation of it by changing the cnt:INTEGER field to two INTEGER fields and<br>> compiling with a 32-bit compiler. That would be the same size as a 64-bit<br>> INTEGER. It requires MaxBytes <= 16_7FFFFFFF DIV BITSIZE (Byte) - 11 to<br>> compile, with bit size having space for 31 more bits before it overflows.<br>> This byte count of buf is a multiple of 4, which we want for unicode-range<br>> WIDECHAR. Making it -10 overflows, presumably because the additional byte is<br>> padded out to a multiple of 32 bits.<br>> <br>> I would have expected that somewhere, a size including the one-word heap header<br>> would be computed, but these are never actually heap allocated, and it seems to<br>> work. But to hedge against things, I suggest using -19. This would allow space<br>> to count it, cross-compiling 32->64.<br>> <br>> This will allow a text literal of 268435436 ISO characters, and a wide text literal<br>> of 1/4 that, which is not likely to be a serious limitation, considering that it<br>> all has to be on a single line of source code.<br>> <br>> As for pickles, the horse is already out of the barn on that, as pickles could<br>> already have been written with the current fingerprint, and we can't change the<br>> type in any way without the fingerprint changing. It is not hard to add<br>> recognition of the old fingerprint to pickles. Right off hand, I don't remember<br>> the process for finding actual fingerprint values, but I've done it before and<br>> can rediscover it.<br>> <br>> > (* - 8 * ORD(BITSIZE(INTEGER) = 64) *)<br>> > (* Do not adjust this for INTEGER size. It makes T have different<br>> > fingerprints on 32- and 64-bit machines, which undermines pickling/<br>> ><br>> ><br>> ><br>> > otherwise we have:<br>> ><br>> ><br>> > new source -> compiling TextLiteral.i3<br>> > "../src/text/TextLiteral.i3", line 27: CM3 restriction: record or object type is too large<br>> > 1 error encountered<br>> ><br>> ><br>> > Ok?<br>> > - Jay<br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br></div> </div></body>
</html>