[M3commit] CVS Update: cm3

Tony Hosking hosking at cs.purdue.edu
Mon Feb 8 08:39:26 CET 2010


Nah, not necessary.

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 7 Feb 2010, at 21:15, 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.
>  
>  
>  - Jay
> 
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Mon, 8 Feb 2010 01:47:59 +0000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> hm. Bug perhaps in TWord:
>  
> PROCEDURE Extract (READONLY x: Int;  i, n: CARDINAL;  VAR r: Int): BOOLEAN =
>   VAR w, b: INTEGER;
>       size := x.n * BITSIZE (IByte);
>   BEGIN
>     IF i + n > size THEN RETURN FALSE; END;
>     Shift (x, -i, r);
> 
>  
> and maybe:
>  
>  
> PROCEDURE Insert (READONLY x, y: Int;  i, n: CARDINAL;  VAR r: Int): BOOLEAN =
>   VAR yy, yyy, yyyy: Int;
>       size := x.n * BITSIZE (IByte);
>   BEGIN
>     IF i + n > size THEN RETURN FALSE; END;
> 
>  
> I propose that TWord.Extract interpret all values as infinitely extended with zeros.
> Er, well, except that it makes me a bit scared too (esp. I'm currently without my good editor to really search/read the code).
> And Insert widen infinitely to fit whatever is being inserted?
>  
>  
> Will it break stuff?
>  
>  
>  - Jay
> 
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Mon, 8 Feb 2010 01:40:46 +0000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> This really puzzles me, that using TInt.Zero makes it fail.
> I do see a subtle difference, n of TInt.Zero is always 8,
> but the CG.m3 code uses 4 for for 32bit.
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Mon, 8 Feb 2010 01:27:30 +0000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Oddly, just using TInt.Zero apparently breaks it all.
> Assertion failures all over ThreadWin32.m3.
> I'll dig a *little*.
> Well, er, maybe just try your change without the TInt.Zero part?
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Mon, 8 Feb 2010 01:09:42 +0000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Same thing on Linux/x86.
> i.e. it breaks everything.
>  
>  - Jay
> 
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Mon, 8 Feb 2010 01:05:58 +0000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> I'll look a bit.
> I'll double check the starting point, and try on Linux. This was on NT386, which has another problem initializing things larger than integer.
>  
>  - Jay
> 
>  
> Subject: Re: [M3commit] CVS Update: cm3
> From: hosking at cs.purdue.edu
> Date: Sun, 7 Feb 2010 19:57:17 -0500
> CC: m3commit at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Rats!  I'll look into it.
> 
> 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 7 Feb 2010, at 19:49, Jay K wrote:
> 
> new source -> compiling RTHooks.m3
> "..\src\runtime\common\RTHooks.m3", line 18: ** INTERNAL CG ERROR *** unable to
> convert or initialize bit field value??  n_bytes=4  size=32
> "..\src\runtime\common\RTHooks.m3", line 18: ** INTERNAL CG ERROR *** unable to
> convert or initialize bit field value??  n_bytes=4  size=32
> "..\src\runtime\common\RTHooks.m3", line 18: ** INTERNAL CG ERROR *** unable to
> convert or initialize bit field value??  n_bytes=4  size=32
> "..\src\runtime\common\RTHooks.m3", line 18: ** INTERNAL CG ERROR *** unable to
> convert or initialize bit field value??  n_bytes=4  size=32
> "..\src\runtime\common\RTHooks.m3", line 18: ** INTERNAL CG ERROR *** unable to
> convert or initialize bit field value??  n_bytes=4  size=32
> "..\src\runtime\common\RTHooks.m3", line 18: ** INTERNAL CG ERROR *** unable to
> 
> 
>  - Jay
> 
>  
> > Date: Mon, 8 Feb 2010 01:18:13 +0000
> > To: m3commit at elegosoft.com
> > From: hosking at elego.de
> > Subject: [M3commit] CVS Update: cm3
> > 
> > CVSROOT: /usr/cvs
> > Changes by: hosking at birch. 10/02/08 01:18:13
> > 
> > Modified files:
> > cm3/m3-sys/m3front/src/misc/: CG.m3 
> > 
> > Log message:
> > Fix bug for constant initialization of LONGINT static data:
> > 
> > MODULE Main;
> > VAR a := 1L;
> > BEGIN
> > END Main.
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100208/859a5247/attachment-0002.html>


More information about the M3commit mailing list