[M3devel] next little step

[Jay K]

And the problem here is that ETimer__Push
contains a parameter "t" and a local in a nested block "t".
 ETimer_Push(t)
{
  {
    t
    stuff with inner t
  }
  stuff with outer t
} 
Normally this'd be dealt with begin_block/end_block.
However because import_procedure comes in at arbitrary
times, and is needed to remain in scope from there on,
I ignore begin/end_block -- and the braces above aren't present. 
Longer term I will move all the declarations from import_procedure
up to global scope, and then honor begin/end_block.
Would be nice if frontend did this but oh well. 
So for now I munge all parameters/locals (except "_static_link")
with a unique number on the end, so these two aren't the same. Now we get much further.
We get to cm3 trying to open files, the files aren't present, it raises an exception. Raising an exception doesn't work due to a small stupid error of extra work I did.
I wasn't adding static_links to exception handlers because they already have a parameter.
Likely fix is to stop special casing exception handlers. (Btw, Tony -- we should have
 m3cg.try 
 m3cg.finally 
 m3cg.except whatever that means (what are the parameters? I guess types?)
 and maybe:
   m3cg.understands_try  
   m3cg.understands_finally 
   m3cg.understands_except whatever that means  
 and maybe: 
   m3cg.is_pass_through which means, something like, the backend doesn't
 really understand anything, please make all the calls and a later backend
 might ignore some -- if it is workable to make ignored calls. I'll try to think about later, much later.
And come up wwith something that doesn't break existing backends.
Obvious goals:
  a new backend that understands try/finally/except has a enough information
  to a) use setjmp/longjmp
     or b) use Microsoft C source __try/__except/__finally and the VMS/Tru64/Ultrix equivalents
     or c) use C++ source try/except/finally
     or d) use the IA64 ABI ? 
     or e) generate Java source or bytecodesMaybe even a goal where you could layer a thin new filter m3cg on top of an older one
and all the thin new filter m3cg does is change try/except/finally to setjmp/longjmp.
That'd be nifty if we could achieve it.
Some sort of "dynamic chaining of m3cg".
 ) I also wasn't defining structs right for a bit there.struct {short a; char b;} m3_struct3_t isn't really guaranteed 3 bytes. We might have a problem there.So I have:struct {char a[3];} m3_struct3_t isn't really guaranteed 3 bytes. but we might cast and read a 2 byte integer out of that, and the alignment could be off.x86/AMD64 don't care so I'm ignoring it.The higher level IR might/will fix it. We'll see. 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.. 
 Later,
  - Jay



 > Date: Wed, 19 Sep 2012 06:55:39 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	12/09/19 06:55:39
> 
> Modified files:
> 	cm3/m3-sys/m3back/src/: M3C.m3 
> 
> Log message:
> 	put line directives in comments (for now)
> 	put static_link last instead of first
> 	This lets us get much further:
> 	RunMainBody: exec: ../src/etimer/ETimer.m3(3)
> 	
> 	Program received signal EXC_BAD_ACCESS, Could not access memory.
> 	Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
> 	0x00343511 in ETimer__Push (t=0x16bc1b8 "??B") at ETimer.mc.c:743
> 	743	(*(volatile INT32*)(4+(ADDRESS)*(volatile ADDRESS*)&L_14))=(INT32)(((INT32)(((INT32)(((INT32)(*(volatile INT32*)(4+(ADDRESS)*(volatile ADDRESS*)&L_14)))+((INT32)(((INT32)1))))))));
> 	(gdb)
> 	
> 	(before at Main(0) we ran the body, which was wrong)
> 	
> 	print min32 and min64 as -max32 and -max64-1 to fix warning
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120919/95851a08/attachment-0001.html>