[M3commit] CVS Update: cm3

Jay K jay.krell at cornell.edu
Wed Feb 24 00:08:32 CET 2010


I'll have to show you where the values are coming from. I don't know offhand.

  Could be from m3back, or m3front, I don't know.

 

This stuff largely is runnable/testable from arbitrary hosts.

  cd scripts/python

  ./do-cm3-std.py realclean NT386

  ./do-cm3-std.py buildship NT386

 

 

to get the data we are interested in, would want to change this code e.g.:

 

 

C:\dev2\cm3.2\m3-sys\m3back\src\Codex86.m3(386):    IF (NOT M3BackInt.ToInt(imm, ins.imm)) AND (NOT M3BackWord.LE(imm, M3BackInt.Word32.max)) THEN


 

Note that most of the uses of ToInt in m3back don't do that, e.g.:

 

 

      IF shiftCount.loc = OLoc.imm THEN
        IF NOT M3BackInt.ToInt(shiftCount.imm, ins.imm) THEN
          t.Err("binOp: unable to convert immediate to INTEGER:" & M3BackInt.ToDiagnosticText(shiftCount.imm));
        END;
        ins.imsize := 1;

 

 

And at least one of these examples is so far unreachable -- the one in bitTestAndSet that I added yesterday.

But some are not, I didn't go here randomly.

  bitTestAndSet seems unusual but ok in that many x86 instructions can take a one byte signed immediate value, but bitTestAndSet seems to take a one byte unsigned immediate value.

 

 

 - Jay
 


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


I guess I am uncertain what it is you are trying to achieve.  The Modula-3 frontend never generates unsigned integers.  Everything is signed.  If you want to represent (unsigned) then, yes, I guess you want TWord.TBytes.



On 23 Feb 2010, at 13:15, Jay K wrote:

So we need TWord.ToBytes?
 
 - Jay
 


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

Actually, on second thought, of course it cannot be fixed.  The signed value 128 *does* require 2 bytes to represent.   (char)128 == -128.  (short)128 == 128.
These TInt functions should be interpreted as having C arithmetic semantics.



On 23 Feb 2010, at 08:35, Tony Hosking wrote:




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


More information about the M3commit mailing list