[M3commit] CVS Update: cm3

[Jay Krell]

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.)