<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'>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></body>
</html>