[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