<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>With this fixed I get yet much further.<div><br></div><div><br></div><div>All way to RTCollector.m3:</div><div><br></div><div><br></div><div><div>PROCEDURE CleanBetween (h, he: RefHeader; clean: BOOLEAN) =</div><div> BEGIN</div><div> WHILE h < he DO</div><div> <* ASSERT Word.And (LOOPHOLE (h, INTEGER), 3) = 0 *></div><div><br></div><div> <* ASSERT NOT h.forwarded *></div><div><br></div><div>and that assert failed.</div><div><br></div><div>Ideas? Maybe you'll be able to look into this Tony?</div><div><br></div><div><br></div><div>In the meantime, I've moved my attention to m3-sys/m3tests and fix problems</div><div>they show -- I was reminded I have a thorough bit insert/extract test there,</div><div>and I'm not sure I didn't implement it backwards in C, and that assertion failure</div><div>is related to Word.Insert...but I think my Word.Insert is correct...</div><div>Anyway, m3-sys/m3tests have revealed another problem...probably a frontend one...</div><div>I"ll send another mail.</div><div><br></div><div><br></div><div> - Jay</div><br><br><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: m3devel@elegosoft.com<br>Date: Wed, 19 Sep 2012 20:15:12 +0000<br>Subject: Re: [M3devel] next little step<br><br>
<style><!--
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:12pt;font-family:Calibri;}
--></style>
<div dir="ltr">And the problem here is that ETimer__Push<br>contains a parameter "t" and a local in a nested block "t".<br><br> <br>ETimer_Push(t)<br>{<br> {<br> t<br> stuff with inner t<br> }<br> stuff with outer t<br>}<br> <br><br>Normally this'd be dealt with begin_block/end_block.<br>However because import_procedure comes in at arbitrary<br>times, and is needed to remain in scope from there on,<br>I ignore begin/end_block -- and the braces above aren't present.<br> <br><br>Longer term I will move all the declarations from import_procedure<br>up to global scope, and then honor begin/end_block.<br>Would be nice if frontend did this but oh well.<br> <br><br>So for now I munge all parameters/locals (except "_static_link")<br>with a unique number on the end, so these two aren't the same.<br> <br>Now we get much further.<br>We get to cm3 trying to open files, the files aren't present, it raises an exception.<br> <br>Raising an exception doesn't work due to a small stupid error of extra work I did.<br>I wasn't adding static_links to exception handlers because they already have a parameter.<br>Likely fix is to stop special casing exception handlers.<br> <br>(Btw, Tony -- we should have<br> m3cg.try <br> m3cg.finally <br> m3cg.except whatever that means (what are the parameters? I guess types?)<br> and maybe:<br> m3cg.understands_try <br> m3cg.understands_finally <br> m3cg.understands_except whatever that means <br> and maybe: <br> m3cg.is_pass_through which means, something like, the backend doesn't<br> really understand anything, please make all the calls and a later backend<br> might ignore some -- if it is workable to make ignored calls.<br> <br>I'll try to think about later, much later.<br>And come up wwith something that doesn't break existing backends.<br>Obvious goals:<br> a new backend that understands try/finally/except has a enough information<br> to a) use setjmp/longjmp<br> or b) use Microsoft C source __try/__except/__finally and the VMS/Tru64/Ultrix equivalents<br> or c) use C++ source try/except/finally<br> or d) use the IA64 ABI ? <br> or e) generate Java source or bytecodes<br>Maybe even a goal where you could layer a thin new filter m3cg on top of an older one<br>and all the thin new filter m3cg does is change try/except/finally to setjmp/longjmp.<br>That'd be nifty if we could achieve it.<br>Some sort of "dynamic chaining of m3cg".<br> )<br> <br>I also wasn't defining structs right for a bit there.<br>struct {short a; char b;} m3_struct3_t isn't really guaranteed 3 bytes.<br> <br>We might have a problem there.<br>So I have:<br>struct {char a[3];} m3_struct3_t isn't really guaranteed 3 bytes.<br> <br>but we might cast and read a 2 byte integer out of that, and the alignment could be off.<br>x86/AMD64 don't care so I'm ignoring it.<br>The higher level IR might/will fix it. We'll see.<br> <br>Also probably this doesn't happen -- if I actually have a record with a uint16 or uint32, the front end will pad it up in size.. There's still something I need to fix here..not urgent..<br> <br><br> Later,<br> - Jay<br><br><br><br> <br><div><div id="ecxSkyDrivePlaceholder"></div>> Date: Wed, 19 Sep 2012 06:55:39 +0000<br>> To: m3commit@elegosoft.com<br>> From: jkrell@elego.de<br>> Subject: [M3commit] CVS Update: cm3<br>> <br>> CVSROOT: /usr/cvs<br>> Changes by: jkrell@birch. 12/09/19 06:55:39<br>> <br>> Modified files:<br>> cm3/m3-sys/m3back/src/: M3C.m3 <br>> <br>> Log message:<br>> put line directives in comments (for now)<br>> put static_link last instead of first<br>> This lets us get much further:<br>> RunMainBody: exec: ../src/etimer/ETimer.m3(3)<br>> <br>> Program received signal EXC_BAD_ACCESS, Could not access memory.<br>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000004<br>> 0x00343511 in ETimer__Push (t=0x16bc1b8 "??B") at ETimer.mc.c:743<br>> 743 (*(volatile INT32*)(4+(ADDRESS)*(volatile ADDRESS*)&L_14))=(INT32)(((INT32)(((INT32)(((INT32)(*(volatile INT32*)(4+(ADDRESS)*(volatile ADDRESS*)&L_14)))+((INT32)(((INT32)1))))))));<br>> (gdb)<br>> <br>> (before at Main(0) we ran the body, which was wrong)<br>> <br>> print min32 and min64 as -max32 and -max64-1 to fix warning<br>> <br></div> </div></div></div> </div></body>
</html>