<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'>How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets?<br>double? That offers I think 53 bits, which is pretty good, but pesky floating point..<br>A library without infix notation?<br>C and C++ have been using __int64 and long long for this for going on 20 years.<br>And C++ has infix notation for arbitrary types.<br><br><br>I guess I will plumb Target.Int through?<br>I've started this before but it got tedious.<br><br><br> - Jay<br><br><div><hr id="stopSpelling">CC: m3devel@elegosoft.com<br>From: antony.hosking@gmail.com<br>Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more?<br>Date: Tue, 3 Sep 2013 08:11:32 -0400<br>To: jay.krell@cornell.edu<br><br><div>Don't plumb LONGINT throughout. I still consider it an abomination.<br><br>Sent from my iPad</div><div><br>On Sep 3, 2013, at 1:53 AM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><div></div><blockquote><div>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">I've complained about this before.<br><br><br>The frontend keeps track of things in bits in INTEGER.<br>Therefore TextLiteral.MaxBytes is around 512MB.<br><br><br>We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail.<br><br><br>Fixing this mostly but not entirely would be to plumb through LONGINT<br>"everywhere" instead of INTEGER.<br>We would still lose the sign bit and bits vs. bytes would lose us another 3 bits.<br>So we'd have a 60 bit limit instead of a 64bit limit.<br><br><br>Fixing it even more would require Target.Int.<br><br><br>Thoughts?<br><br><br>Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back?<br>Do we still require bootstrapping from LONGINT-less compilers?<br><br><br>Any lingering doubts as to its syntax and meaning?<br>I still think it should be named INT64.<br>Because in the future I want INT128 and I don't want LONGINT to grow in size.<br><br><br>Would it be considered adequate as a replacement for Target.Int?<br><br><br>If instead I plumb through Target.Int, any complaints?<br>Target.Int has the following advantages:<br> When we need INT128 in the future, it is a very very very simple and small change.<br> I already extended Target.Int from 64 bits to 72 bits.<br> It works with old frontends.<br><br><br>Target.Int has the following disadvantages:<br> no operator overloading so usage is cumbersome <br> slower <br> I still don't fully understand it, e.g. division <br><br><br><br> - Jay<br> </div>
</div></blockquote></div> </div></body>
</html>