[M3commit] CVS Update: cm3

[Jay K]

I'd rather move along to other things..

 

 - Jay
 


From: hosking at cs.purdue.edu
Date: Tue, 23 Feb 2010 08:35:39 -0500
To: jay.krell at cornell.edu
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3




That can be fixed...



On 22 Feb 2010, at 21:30, Jay K wrote:


ToBytes claims the value 128 requires 2 bytes. Which is reasonable. But not always expected. There should be an unsigned version that claims 1 byte?
I can look into Chop and ToBytes more, but I am at least currently reusing add/subtract/multiple/div/mod/shift/rotate/toint/fromint/tochars, not bad.


- Jay


----------------------------------------

From: hosking at cs.purdue.edu

Date: Mon, 22 Feb 2010 21:10:10 -0500

To: jay.krell at cornell.edu

CC: m3commit at elegosoft.com

Subject: Re: [M3commit] CVS Update: cm3



On 22 Feb 2010, at 20:30, Jay K wrote:




I'm still a bit leary of Chop and ToBytes.



Chop is just the same as a C cast.

i.e., (char)0xFFFFFFFF and (char)0x000000FF return the same value (char)-1.



ToBytes simply returns the significant bytes.




I *suspect* we need a bit more in TWord to make this all hold together.



I don't see the need. I think this speaks to confusion on your part...




Look at my current M3BackInt.m3. It is almost entirely now delegating to TInt/TWord, except it has its own conversions back and forth. It applies Widen before every operation, chop after every one. They are different for unsigned vs. signed. (Hm, unsigned narrow should probably check that the value fits, and the caller can ignore that or not.)








I don't entirely ignore ToInt's boolean.


I then check if the value fits in Word32. If it does, I ignore the overflow, knowing the value converted "reasonably". If it doesn't, I error.








I think TWord.ToWord, which doesn't exist, would do what I want -- allow for 0-2^n and fail otherwise.








Further, I should chose TWord.ToWord vs. TInt.ToInt based on the types I have. And then the frontend shouldn't claim 255 is an Int8. And such.


(I'm not sure how I'm getting away with this currently, maybe something odd in my ToBytes.)








What is there now is in pretty good shape, and M3BackInt/Word reinvent exceedingly little code now. I'd be plenty ok moving to other stuff now, such as atomic8/16/64 (and more testing of atomic32, which I think are done and working). I wasn't too keen spending the time adapting to the TInt/TWord changes, but I also didn't want the two nearly identical copies, esp. since I haven't read through DivMod to understand it.








And then rewriting hand.c in Modula-3.








And then other stuff.








..Jay








________________________________



From: hosking at cs.purdue.edu



Date: Mon, 22 Feb 2010 20:03:03 -0500



To: hosking at cs.purdue.edu



CC: m3commit at elegosoft.com



Subject: Re: [M3commit] CVS Update: cm3















P.S. The assumption is that results from operations that overflow should be discarded.











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 22 Feb 2010, at 20:01, Tony Hosking wrote:







Jay, If you want that behavior, just do:







TInt.Chop(x, BYTESIZE(INTEGER), x);



TInt.ToInt(x, i)







On 22 Feb 2010, at 23:57, Jay Krell wrote:







CVSROOT: /usr/cvs



Changes by: jkrell at birch. 10/02/22 23:57:21







Modified files:



cm3/m3-sys/m3back/src/: M3BackInt.m3







Log message:



remove local versions of ToInt and FromInt now that TInt.ToInt packs the bytes even if there is overflow (the right solution I suspect it TWord.ToWord)









    

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100223/15e99a4a/attachment-0002.html>