<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Tony, the TInt/TWord cleanup cost me a lot of time, and<BR>still more to do.<BR>
<BR>
<BR>They used to provide target math to a specified precision.<BR>
<BR>
<BR>Now always to a fixed large precision.<BR>
<BR>
<BR>Historically M3back did host math, no overflow checking.<BR> It "had" to change, at least to split Target.Int into<BR> two host integers, in order to accomodate 64bit integers,<BR> but preferably to sometimes keep them together to do constant folding.<BR> (Arguably 64bit integer support initially only from 64bit host,<BR> then have working LONGINT, then use LONGINT, but no.)<BR>
<BR>
<BR>Adding overflow checking at the same time caught actual<BR> borderline bugs in user code -- code that depended on silent overflow.<BR>
<BR>
<BR> m3front won't catch those I guess because it never? folds constants?<BR> Maybe it should be willing to do so as long as there is no overflow,<BR> and then if it is hits overflow, back off and generate code to do the work?<BR> But also warn?<BR>
<BR> <BR>
I'm left very much desiring the functionaly that TInt did have.<BR>
<BR>
<BR>I have a few options.<BR>M3BackInt as it recently was, a thin layer over TInt.<BR> The constants could remain in TInt.<BR>
<BR> <BR>
Introducing TIntN, which is TInt but with n=specified precision,<BR> at runtime (Not TInt8, TInt32, just one TIntN that adapts<BR> at runtime, just like TInt used to do).<BR>
<BR> <BR>
The only difference between TIntN and M3BackInt is the name and location.<BR> It would be in m3middle.<BR>
<BR> <BR>
Maybe adding just a few functions to TInt, like having Chop return a BOOLEAN,<BR>and SignExtend and ZeroExtend that give a source precision.<BR>These functions would exist either way, just in TIntN, TWordN, or TInt.<BR>
<BR>
<BR>But I think still useful to wrap the type in a type that carries the precision.<BR>
<BR>
<BR>Now, also, I wonder if TInt, with its lost functionality, should<BR>be renamed, say to TInt64 or Int64?<BR>
<BR>
<BR>TInt used to do more and it was a little more complicated but useful.<BR>Are you sure it shouldn't go back to how it was?<BR>If not, I'll layer over it. Multiple layers aren't necessarily a bad thing,<BR>if it keeps the individual layers thinner, simpler, easier to get correct.<BR>
<BR>
<BR>
Doesn't analogy to TFloat suggest it was better before?<BR>
<BR>TFloat doesn't support just one large precision type, it supports<BR>
parameterizing itself in order to simulate various floating types.<BR>
Granted, I haven't looked at what all it provides and I don't believe<BR>
m3back folds constant float math at compile time, but it could.<BR>
At least stuff not dependent on various "modes".<BR>
1.0 + 2.0 is always 3.0, no matter the rounding/precision mode.<BR>
I'd have to think a bit, but it's probably something like floating<BR>
constants with the same exponent and a mantissa that holds<BR>
the full value can be folded. Bunch of examples is that if I<BR>
convert a bunch of 32bit integers to double and do only<BR>
add and subtract, it can all be folded at compile time. <BR>
Multiplication and division cannot in general be done, though sometimes.<BR>
Comparison to the same set can be done.<BR>
<BR>
<BR>
Anyway, my current best idea is to introduce TIntN, TWordN, but I have<BR>
a while to think about it before I do anything.<BR>
<BR> - Jay<BR><BR> </body>
</html>