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

[Jay K]

To be clear, I'm not working on this, was just thinking about it.

 

 - Jay

 


Subject: Re: [M3devel] TInt/TWord proposal (at least what I was thinking..)
From: hosking at cs.purdue.edu
Date: Thu, 11 Feb 2010 11:52:12 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu




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/2dc25da8/attachment-0002.html>