<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
And now again it doesn't work.<BR>
<BR>
new source -> compiling RTIO.i3<BR>new source -> compiling RTTypeMap.i3<BR>new source -> compiling RTMapOp.i3<BR>new source -> compiling RTModule.i3<BR>new source -> compiling RTHeapMap.m3<BR><BR>
***<BR>*** runtime error:<BR>*** <*ASSERT*> failed.<BR>*** file "..\src\Codex86.m3", line 430<BR>***<BR>
Stack trace:<BR> FP PC Procedure<BR>--------- --------- -------------------------------<BR> 0x12f310 0x466a46 immOp1 + 0x475 in ..\src\Codex86.m3<BR> 0x12f400 0x467108 immOp + 0x662 in ..\src\Codex86.m3<BR> 0x12f444 0x47d5c7 doimm + 0x255 in ..\src\Stackx86.m3<BR> 0x12f470 0x43ff5e if_false + 0x222 in ..\src\M3x86.m3<BR> 0x12f49c 0x64138b if_false + 0x101 in ..\src\M3CG_Check.m3<BR> 0x12f4c8 0x501a8f If_false + 0xa8 in ..\src\misc\CG.m3<BR> 0x12f4e8 0x5c2466 PrepNoBranch + 0x66 in ..\src\exprs\Expr.m3<BR> 0x12f510 0x5c1e3e PrepBranch + 0xcc in ..\src\exprs\Expr.m3<BR> 0x12f564 0x5e4392 Compile + 0x104 in ..\src\stmts\IfStmt.m3<BR> 0x12f594 0x536610 Compile + 0x63 in ..\src\stmts\Stmt.m3<BR>......... ......... ... more frames ...<BR> *** execution of [<function _BuildGlobalFunction at 0x00B59470>, <function _Shi<BR>pFunction at 0x00CA89B0>] failed ***<BR>
<BR>
<BR>
I'm going to move m3back to how it was, but leave m3middle alone.<BR>
With TIntN still in m3back.<BR>
I skimmed through most of your changes and they seemed ok, but<BR>
I'll have to apply them slowly/piecemeal and see which work.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> From: jay.krell@cornell.edu<BR>> To: hosking@cs.purdue.edu<BR>> Date: Sat, 27 Feb 2010 07:34:52 +0000<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] TInt/TWord/N<BR>> <BR>> <BR>> > As I understand it your stuff in m3back is mostly working.<BR>> > I took a look at the code there and I see a number of issues<BR>> <BR>> <BR>> Tony, I don't know of anything that isn't working.<BR>> Please let me know.<BR>> All 64bit operations should work. atomic32 should work.<BR>> Not yet atomic8/16/64, soon.<BR>> Oh there is an alignment issue once atomic64 is there.<BR>> It's present on other platforms too, for different reasons (incorrect max_align).<BR>> <BR>> <BR>> Thanks,<BR>> - Jay<BR>> <BR>> <BR>> ----------------------------------------<BR>> > From: hosking@cs.purdue.edu<BR>> > Date: Sat, 27 Feb 2010 01:16:32 -0500<BR>> > To: jay.krell@cornell.edu<BR>> > CC: m3devel@elegosoft.com<BR>> > Subject: Re: [M3devel] TInt/TWord/N<BR>> ><BR>> > The solution is not to push upstream into m3middle.<BR>> > I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime.<BR>> ><BR>> > -- T<BR>> ><BR>> > On 26 Feb 2010, at 23:48, Jay K wrote:<BR>> ><BR>> >><BR>> >> Tony, I just don't understand what is wrong with TIntN, TWordN.<BR>> >> They are what TInt/TWord did for a long time after all. ?<BR>> >> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks.<BR>> >><BR>> >><BR>> >> - Jay<BR>> >><BR>> >><BR>> >> ----------------------------------------<BR>> >>> From: hosking@cs.purdue.edu<BR>> >>> Date: Fri, 26 Feb 2010 19:51:15 -0500<BR>> >>> To: jkrell@elego.de<BR>> >>> CC: m3commit@elegosoft.com<BR>> >>> Subject: Re: [M3commit] CVS Update: cm3<BR>> >>><BR>> >>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this.<BR>> >>><BR>> >>> On 26 Feb 2010, at 13:48, Jay Krell wrote:<BR>> >>><BR>> >>>> CVSROOT: /usr/cvs<BR>> >>>> Changes by: jkrell@birch. 10/02/26 13:48:34<BR>> >>>><BR>> >>>> Modified files:<BR>> >>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3<BR>> >>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3<BR>> >>>> Wrx86.i3 Wrx86.m3 m3makefile<BR>> >>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3<BR>> >>>> TWordN.i3 TWordN.m3 Target.i3<BR>> >>>> Target.m3 m3makefile<BR>> >>>> Removed files:<BR>> >>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3<BR>> >>>> M3BackWord.m3<BR>> >>>><BR>> >>>> Log message:<BR>> >>>> introduce type Target.IntN which is Int plus a precision<BR>> >>>> just like the old Target.Int<BR>> >>>> (previously M3BackInt.Int)<BR>> >>>><BR>> >>>> make TIntN and TWordN support it<BR>> >>>> they are just thin wrappers over TInt, TWord<BR>> >>>> previously named M3BackInt, M3BackWord<BR>> >>>><BR>> >>>> add small amount of support to TInt:<BR>> >>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate<BR>> >>>> These could, if desired, go into their only users: TIntN, TWordN.<BR>> >>>> (with the understanding that that Target.Int is "revealed" to them.)<BR>> >>>><BR>> >>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision<BR>> >>>><BR>> >>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged<BR>> >>>> This is "just" additions.<BR>> >>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.)<BR>> >>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN)<BR>> >>>> (A little unsatisfactory that N is bytes instead of bits.)<BR>> >>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) )<BR>> >>>><BR>> >>>> While at it, in TIntN, rename things slightly:<BR>> >>>> FromInt => FromHostInteger<BR>> >>>> ToInt => ToHostInteger<BR>> >>>><BR>> >>>> "Int" is "Target.Int"<BR>> >>>> "HostInteger" is "INTEGER"<BR>> >>>><BR>> >>>> again, TInt/TWord/m3front/m3middle not much affected.<BR>> >>>><BR>> >>>> One fishy/uncertain thing in all of this, something to test out, is cross builds<BR>> >>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we<BR>> >>>> really need INTEGER to be 4 bytes throughout m3back?<BR>> >>>> (I know that mklib has little endian dependency.)<BR>> >>><BR>> > <BR> </body>
</html>