[M3devel] TInt/TWord/specified precision

[Jay K]

Tony, the TInt/TWord cleanup cost me a lot of time, and
still more to do.

 


They used to provide target math to a specified precision.

 


Now always to a fixed large precision.

 


Historically M3back did host math, no overflow checking.
 It "had" to change, at least to split Target.Int into
 two host integers, in order to accomodate 64bit integers,
 but preferably to sometimes keep them together to do constant folding.
 (Arguably 64bit integer support initially only from 64bit host,
 then have working LONGINT, then use LONGINT, but no.)

 


Adding overflow checking at the same time caught actual
 borderline bugs in user code -- code that depended on silent overflow.

 


 m3front won't catch those I guess because it never? folds constants?
 Maybe it should be willing to do so as long as there is no overflow,
  and then if it is hits overflow, back off and generate code to do the work?
  But also warn?


 

I'm left very much desiring the functionaly that TInt did have.

 


I have a few options.
M3BackInt as it recently was, a thin layer over TInt.
  The constants could remain in TInt.


 

Introducing TIntN, which is TInt but with n=specified precision,
 at runtime (Not TInt8, TInt32, just one TIntN that adapts
 at runtime, just like TInt used to do).


 

The only difference between TIntN and M3BackInt is the name and location.
  It would be in m3middle.


 

Maybe adding just a few functions to TInt, like having Chop return a BOOLEAN,
and SignExtend and ZeroExtend that give a source precision.
These functions would exist either way, just in TIntN, TWordN, or TInt.

 


But I think still useful to wrap the type in a type that carries the precision.

 


Now, also, I wonder if TInt, with its lost functionality, should
be renamed, say to TInt64 or Int64?

 


TInt used to do more and it was a little more complicated but useful.
Are you sure it shouldn't go back to how it was?
If not, I'll layer over it. Multiple layers aren't necessarily a bad thing,
if it keeps the individual layers thinner, simpler, easier to get correct.

 

 

Doesn't analogy to TFloat suggest it was better before?


TFloat doesn't support just one large precision type, it supports

parameterizing itself in order to simulate various floating types.

Granted, I haven't looked at what all it provides and I don't believe

m3back folds constant float math at compile time, but it could.

 At least stuff not dependent on various "modes".

  1.0 + 2.0 is always 3.0, no matter the rounding/precision mode.

  I'd have to think a bit, but it's probably something like floating

  constants with the same exponent and a mantissa that holds

  the full value can be folded. Bunch of examples is that if I

  convert a bunch of 32bit integers to double and do only

  add and subtract, it can all be folded at compile time. 

  Multiplication and division cannot in general be done, though sometimes.

  Comparison to the same set can be done.

 

 

Anyway, my current best idea is to introduce TIntN, TWordN, but I have

a while to think about it before I do anything.


 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100226/2de4e512/attachment-0001.html>