[M3commit] CVS Update: cm3

[Jay K]

I did a mechanical transform from Word to TWord.

Nearly all of the constant folding was there, but only for 32bit operations (the only ones that existed).

I've "merely" been giving parity to the 64bit variants.

If anything, so far I have added checks.

Granted, there might be some missing.
My experience though is that they are in there, somewhere, probably via the frontend calling check_hi/lo.

You know, I write code like Word.Shift(a, 123), I get a compile time warning and a runtime error.

 

The large shift count is what comes to mind.

I can test the extract/insert n + i stuff.

 

I'm going to test with TWord.Extract put back.

It ended up not used by my fix.

Sorry about that.

 

 - Jay

 


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

I'm worried what it does for use of TWord.Extract with constant folding.  The semantics of Word.Extract mandate a checked run-time error for n+i>Word.Size.  We want to get that behaviour by not constant folding when the error might occur, so that the programmer gets the appropriate run-time error.




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