[M3commit] CVS Update: cm3
jkrell at elego.de
Fri Sep 28 07:58:22 CEST 2012
Changes by: jkrell at birch. 12/09/28 07:58:22
cm3/m3-sys/m3back/src/: M3C.i3 M3C.m3
./: M3C.i3 M3C.m3
cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3
"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.)
More information about the M3commit