[M3commit] CVS Update: cm3

[Antony Hosking]

Jay,

I’m not convinced that you need multiple passes if you simply cache state in the Proc structures and then dump it at the end of the procedure.  There is no need for you to write to output on every opcode.  You can accumulate all you need and then dump at the end.

— T

On Sep 28, 2012, at 7:58 AM, jkrell at elego.de (Jay Krell) wrote:

> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	12/09/28 07:58:22
> 
> Modified files:
> 	cm3/m3-sys/m3back/src/: M3C.i3 M3C.m3 
> 	./: M3C.i3 M3C.m3 
> 	cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 
> 
> Log message:
> 	"u" => "self"
> 	"U" => "T"
> 	
> 	finish the multipass infrastructure
> 	including working out the Var/Proc vs. tag/INTEGER stuff
> 	I kind of wanted to stop trafficing in the pointers and
> 	only traffic in tag/INTEGER, to save some efficiency,
> 	but the result isn't all that bad -- it leaves M3C oblivious/unchanged
> 	
> 	hookup M3CG to multipass and actually make it multipass
> 	but don't take any advantate of it yet
> 	
> 	Remove commented out code that tried to swap the parameter
> 	order in except blocks. This was to try to deal with
> 	the frontend wierdness where it doesn't always pass the exception argument.
> 	But it didn't work because of indirect calls?
> 	I also tried K&R as a hack. No go.
> 	Workaround I went with is to push extra parameter for direct calls.
> 	Lame all around here.
> 	
> 	Result can still upgrade itself, very nice.
> 	
> 	We can build up to libarithmetic, which hits
> 	the known problem:
> 	../AMD64_DARWIN/BigIntegerComplexGCD.m3 => ../src/algebra/misc/GCD.mg:118:
> 	warning: anonymous struct declared inside parameter list
> 	
> 	add some more builtin struct sizes for that
> 	multipass is also meant to address that problem cleanly: discovering
> 	all struct sizes and declaring them all early, not just lame hardcoded list
> 	which is both too many and not enough
> 	
> 	(I previously compiled up to a different point -- uplevel locals
> 	declared in sub-blocks; why the difference? I don't know. It is possible
> 	there were other changes and I hadn't tried compiling everything, maybe
> 	only up to cm3. In particular, maybe not the passing of structs correctly
> 	by value (by pointer and then copied into a local)? That is where the error
> 	is here. That is another area where multipass will help a lot..maybe..
> 	passing/returning structs by value -- letting the C compiler do the work.
> 	The reason we can't return them by value is because m3cg doesn't tell us
> 	the size of a function's return type! We might be able to guess it
> 	from the "_result" variable -- lame...)
> 	
> 	Indeed..I now compile up to:
> 	
> 	== package /Users/jay/dev2/cm3/m3-libs/m3tk-misc ==
> 	
> 	***
> 	*** runtime error:
> 	***    <*ASSERT*> failed.
> 	***    file "../src/M3C.m3", line 1614
> 	*
> 	
> 	which is where I got to before -- uplevel local declared
> 	when already in the middle of a function..too late in the current
> 	code for putting it in the frame struct..will fix soon now
> 	that multiple passes are easy.
> 	(in particular -- I haven't invented an M3C-specific IR.
> 	The IR is a faithful storing of the M3CG calls, in memory.)
>