[M3commit] CVS Update: cm3

Thu Feb 18 22:08:58 CET 2010

You had changed TWord.Rotate() uses to assume Target.Integer.bytes.

 x: M3x86Rep.Operand; 

 TWord.Rotate(x.imm, m, n) => TWord.Roate(x.imm, Target.Integer.bytes, m, n) 

What probably would have worked is more like: 

 TWord.Rotate(x.imm, m, n) => TWord.Rotate(x.imm, TypeSize(x.optype) * 4, m, n) 

Most uses of TWord/TInt are ok with the new always 8 byte precision, but Rotate is special. 

Precision affects the intermediate results. 

That's the only possible problem that stood out to me on a quick read.

Whatever it all was though, the compiler no longer worked, basically not at all,

even if I removed the assertions about integers fitting in their claimed types.

I wasn't too keen on debugging that right now but I should before much longer.

I'd rather not keep a separate copy of TInt/TWord..

  - Jay

> From: hosking at cs.purdue.edu
> Date: Thu, 18 Feb 2010 12:07:57 -0500
> To: jay.krell at cornell.edu
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> I'm not sure what you mean about the type size... Please elaborate. Do you have a test case?
> Yes, my intention here is that *no* client should presume anything about the actual precision of TInt/TWord. Indeed, we could make it larger, and should be able to without affecting clients. The only thing clients must do when manipulating Target.Int with TWord is to realise that the results are still interpreted in the TInt.Size space. To get a smaller interpretation they must explicitly use TInt.Chop to cut down to the desired number of bytes (and so sign-extend from that smaller size out to the TInt.Size). You will need to use Chop in places where you insert/extract/rotate/Xor (i.e., the sign needs extending in the result).
> 
> On 18 Feb 2010, at 05:05, Jay K wrote:
> 
> > Another problem now is that 64bit rotate of constants doesn't get the type size correct.
> > Anyway I'm trying to get things back to working by bringing in the old code, only in m3back, and then can find the actual problems..
> > I agree it is simpler now that TInt/TWord have a fixed precision of exactly 64 bits. Maybe make it even larger, say 72 bytes, a) to fix that warning a different way b) to sort of get better testing?
> > 
> > - Jay
> > 
> > 
> > From: jay.krell at cornell.edu
> > To: jkrell at elego.de; m3commit at elegosoft.com
> > Date: Thu, 18 Feb 2010 08:09:30 +0000
> > Subject: Re: [M3commit] CVS Update: cm3
> > 
> > Tony there are multiple related problems here.
> > 
> > 1) The front end likes to output values between 128 and 256 with type Int8 instead of Word8.
> > e.g. in InitTypecell.
> > And maybe similar for 16/32/64, I don't know.
> > 
> > 2) Even if the front end used the correct Word8 for them, m3back needs to use TWord.ToBytes vs. TInt.ToBytes for unsigned types, but TWord.ToBytes doesn't exist.
> > 
> > I'll see what I can do.
> > I'll probably add TWord.ToBytes and if the value fits using it, accept it.
> > 
> > - Jay
> > 
> > > Date: Thu, 18 Feb 2010 08:30:35 +0000
> > > To: m3commit at elegosoft.com
> > > From: jkrell at elego.de
> > > Subject: [M3commit] CVS Update: cm3
> > > 
> > > CVSROOT: /usr/cvs
> > > Changes by: jkrell at birch. 10/02/18 08:30:35
> > > 
> > > Modified files:
> > > cm3/m3-sys/m3back/src/: M3x86.m3 
> > > 
> > > Log message:
> > > more information when this assertion fails, as it now does:
> > > 
> > > == package C:\dev2\cm3.2\m3-libs\m3core ==
> > > 
> > > +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.8.2
> > > 
> > > new source -> compiling RTHooks.i3
> > > "..\src\runtime\common\RTHooks.i3", line 15: len:2 t:Int.8 CG_Bytes[t]:1 158
> > > 
> > > ***
> > > *** runtime error:
> > > *** <*ASSERT*> failed.
> > > *** file "..\src\M3x86.m3", line 1114
> > > ***
> > > 
> > > Stack trace:
> > > FP PC Procedure
> > > --------- --------- -------------------------------
> > > 0x12f5cc 0x43c230 init_int + 0x488 in ..\src\M3x86.m3
> > > 0x12f5f8 0x63f506 init_int + 0xa5 in ..\src\M3CG_Check.m3
> > > 0x12f638 0x4fe1ce Init_int + 0x1be in ..\src\misc\CG.m3
> > > 0x12f65c 0x4fe33e DumpInt + 0x34 in ..\src\misc\CG.m3
> > > 0x12f6a4 0x4fc86a DumpPendingNodes + 0x2c2 in ..\src\misc\CG.m3
> > > 0x12f6cc 0x4fa4c6 Bind_segment + 0xe0 in ..\src\misc\CG.m3
> > > 0x12f72c 0x4c71e8 GenLinkerInfo + 0x7d7 in ..\src\values\Module.m3
> > > 0x12f770 0x4c577c CompileInterface + 0x30a in ..\src\values\Module.m3
> > > 0x12f7a8 0x4c5252 Compile + 0x24d in ..\src\values\Module.m3
> > > 0x12f804 0x4aff65 DoCompile + 0x7cd in ..\src\misc\M3Front.m3
> > > 
> > > confusion here about signed vs. unsigned integers;
> > > the signed number 158 requires 2 bytes but the unsigned number 158
> > > only requirs 1 byte
> > > 
> > 
> 

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