<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
If I have to a range check after basically every single operation,<BR>
if I can never just call Add, but always Add and then Something,<BR>
that merits a better type/interface/implementation that does that for me.<BR>
<BR>
I was thinking maybe the check is at "chop time", but<BR>
that would allow things like<BR>
LAST(INTEGER) + 1 - 1 to work, and they probably should not,<BR>
even if arguably they should. I think currently I let this through.<BR>
<BR>
<BR>
I think the previous M3BackInt.m3 shall be TIntN.m3.<BR>
I'll proceed that way.<BR>
<BR>
- Jay<BR> <BR>> From: hosking@cs.purdue.edu<BR>> Date: Thu, 25 Feb 2010 21:48:11 -0500<BR>> To: jay.krell@cornell.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] TInt/TWord/specified precision<BR>> <BR>> The precision (as you have noted) will possibly change. The problems arise because we now have two ranges of integer. We need to support both ranges. Explicit range checks are needed,<BR>> <BR>> m3front *does* fold constants. It has to for constant initialisers. If there is overflow (or results out of range) it refuses to constant fold.<BR>> <BR>> I really don't see the difficulty. You perform the arithmetic using TInt. If it doesn't overflow (at whatever arbitrary precision) then you still need to check that the result is in range for your desired precision. This is not hard.<BR>> <BR>> I do not want to complicate TInt any more than it is now.<BR>> <BR>> On 25 Feb 2010, at 19:06, Jay K wrote:<BR>> <BR>> > 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>> <BR> </body>
</html>