[M3commit] CVS Update: cm3

Tony Hosking hosking at cs.purdue.edu
Mon Feb 8 17:14:34 CET 2010


I am working on these issues right now.  Stay tuned...   It will be much cleaner than what Jay proposes.


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 8 Feb 2010, at 11:02, Rodney M. Bates wrote:

> 
> 
> Jay K wrote:
>> I wonder if we need
>>  TInt8, TInt16, TInt32, TInt64, TInt, TLong
>>  TWord8, TWord16, TWord32, TWord64, TWord, TLongWord
>> that accurately implement ints/words of the exact specified size,
>> with TInt/TWord/TLong/TLongWord depending on the target.
>> I wouldn't mind trying to remove this word "Word".
>> And replace it with UInt or such.
>> TInt, TUInt, TLong, TULong?
>> TSignedInt, TUnsignedInt, TSignedLong, TUnsignedLong?
>> TInt, TUnsignedInt, TLong, TUnsignedLong?
>> TInt.Zero is just always 8 bytes.
>> The size is I believe meant to be fairly opaque to the user.
>> This is the first I've noticed it being visible, such that TInt.EQ is true for values with "quite different" behavior. I would have "thunk" (thought without much thought) that anything TInt.EQ is more equivalent than they actually are.
>> 
> 
> Hmm.  I recall in a discussion a while back that the arithmetic on
> target ints was not coded to handle operands with mixed values of
> n.  Could this have something to do with this?
> 
>>  - Jay
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100208/45793b4f/attachment-0002.html>


More information about the M3commit mailing list