[M3commit] CVS Update: cm3

Jay K jay.krell at cornell.edu
Tue Feb 23 03:30:08 CET 2010


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)
>>>
>>>
> 		 	   		  


More information about the M3commit mailing list