[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	12/09/30 08:40:23

Modified files:
	cm3/m3-sys/m3back/src/: M3C.m3 
	./: M3C.m3 
	cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3 

Log message:
	next application of "multipass"
	
	move all imports up to before any functions
	so now we never need to repeat imports, because
	they were in the middle of a function
	
	"import_repeat" goes away, yeah.
	
	In Tony's approach, probably what we would do is not
	move them up before any function, but move them to just
	before any function they occur in the middle of.
	
	Two partial changes here also.
	One I ventured into by accident prematurely or incompletely.
	One I was too lazy to finish today but will come back to.
	
	First is that I started processing declare_procedure early,
	along with its declare_local, declare_temp..and then begin/end_procedure.
	There is a point to that, to build up frame types earlier, and
	to push up temps, so that I don't need "extra scopes",
	so that I can honor begin/end_block.
	(Here I have eliminated some of the "extra scopes", for imports.)
	for now I'm just moving up imports, not also declare_procededure/temp/local.
	
	Second is that in M3CG_MultiPass, major oops, I failed to fill
	in the "op" field in many of the records.
	MultiPass has two usage modes (at least) -- playback via virtual
	functions (er, OBJECT METHODS), or all the data, and playback of
	selective ops. The first works. The second depends on ops being
	set correctly..do only partly works now. There is no question this should
	be fixed. But it is very tedious (for lack of preprocessor), so
	I didn't finish it yet. Must do.
	
	Experiment: jumble labels.
	I don't understand the meaning of labels.
	Like, I understand procs/vars are created by backend, returned to frontend,
	and then send back to the backend. The correlation is critical.
	I don't understand labels in this regard.
	
	Either the correlation is critical and this messes it up.
	Or it doesn't matter.
	If it does matter, then we maybe we working only by accident.
	I need to do a more focused test here -- be sure to test a case/switch.
	If it does matter, I need to introduce "translation" in M3CG_MultiPass
	for labels similar to what I do for vars/procs, so it works deliberately
	and not by accident (the accident is the various M3CG implementations doling
	out the same labels, whereas they are free to assign their own "random" values,
	I think).
	
	My suspicion is that it can matter.
	If you look at how the M3x86 backend actually does work for label allocation.
	But M3C just uses them to format up names.
	In which case the internal consistency within the first pass -- M3CG.MultiPass --
	I think I understand how that suffices.
	We'll see...I have to think about this...