[M3commit] CVS Update: cm3
jkrell at elego.de
Sun Sep 30 08:40:23 CEST 2012
Changes by: jkrell at birch. 12/09/30 08:40:23
cm3/m3-sys/m3middle/src/: M3CG_MultiPass.i3 M3CG_MultiPass.m3
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,
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...
More information about the M3commit