[M3commit] CVS Update: cm3

[Jay K]

Maybe.
Just to declare the parameters and possibly return typerequires such "buffering" though -- if they include structs,of sizes we haven't seen before.

Also, the reordering afforded by multiple passes will letme put module globals first instead of last.Currently otherwise I have to chose between an extra pointerindirection, or generating invalid C++.

It is just rather liberating to have this power.

It is true that function-at-a-time instead of unit-at-a-timeaffords much of the same power.

There are other examples where reordering/buffering/multiple passeswill help but true that function-at-a-time often suffices.

For example, I only want to output helper functions that are used.
I'll try to come to some decision and proceed.My next step was/is to fix the uplevel-locals-in-nested-blocks problem.
 - Jay



> From: hosking at cs.purdue.edu
> Date: Fri, 28 Sep 2012 10:01:47 -0400
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> 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.)
> > 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20120929/bfa2b1ee/attachment-0002.html>