[M3devel] TInt/TWord proposal (at least what I was thinking..)

[Tony Hosking]

Steady on.  I have it fixed.  CHeckin coming.  No need for more.

On 11 Feb 2010, at 07:05, Jay K wrote:

> TInt/TWord proposal
>  
> 
> TInt needs to be a "complete" replacement for INTEGER and LONGINT.
>  Plus overflow checking.
>  Not just for the frontend, but also m3back.
> 
>  
> TWord needs to be a "complete" replacement for Word and Long.
>  Therefore not likely any overflow checking.
> 
>  
> But in reality you might need all four:
>   signed with silent overflow
>   signed with nonsilent overflow
>   unsigned with silent overflow
>   unsigned with nonsilent overflow
>  
> 
> You can provide silent overflow by computing the result
> and leaving it to the caller to ignore the BOOLEAN or not.
>  
> 
> However in practise I don't think I needed silent overflow at all.
> The only places I allow it, I think really I'm confusing TInt with TWord,
> because TWord doesn't provide the right interface.
>  
>  
> Settle on bits or bytes for sizes.
> Enshrine it mostly in the public interface.
>  It maybe already is, granted.
>  But more so -- external users can construct the things.
>  
> 
> Operations with mixed sizes shall not be allowed.  <=== *****
>   Just as INTEGER, LONGINT, Word, Long don't allow.
>  
>  
> There would be some conversion functions, granted.
> SignedTruncate, UnsignedTruncate, SignExtend, ZeroExtend.
>  
>  
> Constants Zero, One, MOne, etc. shall probably be
> replaced with an array of 8 each, or maybe just
> 1, 2, 4, 8 -- the number of bytes in the size.
>  
> 
> "M" for "minus" is the wrong term.
> It should N or Neg or Negative.
> 
>  
> Something like:
> TYPE BitCount = [8, 16, 32, 64]; (* not legal, darn *)
> TYPE ByteCount = [1, 2, 4, 8]; (* also not legal, darn *)
> TYPE ByteCount = [1..8]; (* wasteful, darn *)
> 
> CONST Invalid = Target.Int{-1,IntBytes{0,..}};
>  
> CONST ZeroBytes = IntBytes{0,..};
> CONST OneBytes = IntBytes{1,0,..};
> CONST NegativeOneBytes = IntBytes{16_FF,..};
> CONST ThirtyTwoBytes = IntBytes{32,0,..};
> etc.
>  
> CONST Zero = ARRAY ByteCount OF { Target.Int{1,ZeroBytes}, Target.Int{2,ZeroBytes}, Invalid, Target.Int{4,ZeroBytes}, Invalid, Invalid,
>  Invalid, Target.Int{8,ZeroBytes}};
>  
> CONST One = ARRAY ByteCount OF { Target.Int{1,OneBytes}, Target.Int{2,OneBytes}, Invalid, Target.Int{4,OneBytes}, Invalid, Invalid,
>  Invalid, Target.Int{8,OneBytes}};
> etc.
> 
>  
> TInt.Zero becomes replaced by, e.g. TInt.Zero[Target.Integer.bytes] or TInt.Zero[Target.Longint.bytes]
>  
> 
> MAYBE as a possible simplification to the user:
> 
> Introduce InternalTInt which is today's TInt and then:
> TInt implies Target.Integer.bytes
> TWord implies Target.Integer.bytes
> new TLongint implies Target.Longint.bytes
> new TLong implies Target.Longint.bytes
>  
> 
> I really thing the short name "Long" is bad.
> There is no indication of unsignedness in it.
> It should be ULong or UnsignedLong or LongWord.
> 
>  
> "Word" is to INTEGER as what is to LONGINT?
>  I don't think Long is the answer.
> I'll start another thread on this.
>  
>  
> m3back maintains a stack of mixed types, but I think it works out ok.
>  
>  
> All that being said, I think what is there works and isn't terrible
> and we don't need to solve lots of problems here.
>  
>  
> I do think the variable sizing is a bit of a problem though.
>  
>  
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100211/51aa92f0/attachment-0002.html>