[M3commit] CVS Update: cm3

[Jay K]

I was just trying to get longint initialization to work.

It seemed some of its problems might have been related to the fact that you Extract more high order zeros from TInt.Zero than Target.Int{Target.Integer.bytes}. But in the end (just now) I left TWord.Extract alone.

It remains true that EQ(TInt.Zero) has multiple representations and they don't act alike.

 Maybe that is desirable.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Wed, 10 Feb 2010 10:13:31 -0500
To: jay.krell at cornell.edu
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3




I'm not sure what you are trying to do or why.  Can you provide further explanation?


On 10 Feb 2010, at 04:47, Jay K wrote:

Shall I go ahead and let Extract act as if the data is infinitely zero extended?
That seems easy to do. I don't know if it will fix the problems, or cause other problems.
It is easy to try. The danger is if it causes subtle undetected-at-first-and-for-a-while problems.
 
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Mon, 8 Feb 2010 11:36:31 -0500
To: jay.krell at cornell.edu
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3


Yes, that is what I am now trying to clean up.





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:18, Jay K wrote:

Rodney I *think* generally mixed sizes are supported in TWord, TInt.
  Though I don't necessarily understand all of the code.
There was a problem recently fixed, granted.
One problem here though is that you can't TWord.Extract beyond the size.
So the varying sizes of "zero" behave differently.
You might imagine it's zeros as far out as needed, but it doesn't work that way currently.
 
 - Jay
 
> Date: Mon, 8 Feb 2010 10:02:58 -0600
> From: rodney_bates at lcwb.coop
> To: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> 
> 
> 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/20100210/3bedea31/attachment-0002.html>