[M3devel] m3cg "Proc" and "Var"

[Jay K]

I'm wondering if it might just be much easier if m3front assigns
small incrementing integers for Var and Proc rather than getting
pointers back from declare_procedure, declare_local, etc., and then passing
them back to begin_procedure, load, etc.


See, where I am at is I want to "playback" an m3cg run multiple times,
computing different data each time -- later runs depending on earlier runs.


I don't need to a persisent "disk" form.
Though I end up close to that, esp. with this proposed change, which eliminates some pointers.


I already do this in parse.c.
Parse.c being written in C++ and having the preprocessor, it was much easier to do.
  See how I #include m3-def.h multiple times, with different macros. 
  Ugly perhaps but highly convenient and productive and easy to use..
I'm so tempted to write "m3toc" this way, but I'm trying to use the product. It is painful..


Anyway, so I'm using Modula-3, and I have this really tedious code to convert
the m3cg calls into an in-memory format. That I'll then loop over multiple times.
Due to the tedium, I build up the in-memory format in one shared module,
that I'm calling M3CG_MultiPass.
It is closely analogous to M3CG_Ops.i3:


TYPE declare_exception_t = REF RECORD name: Name; arg_typeid: TypeUID; raise_proc: BOOLEAN; base: Var; offset: INTEGER END;


PROCEDURE set_runtime_proc(self: T; name: Name; proc: Proc) =
BEGIN
self.Add(NEW(set_runtime_proc_t, name := name, proc := proc));
END set_runtime_proc;


etc.


so, now, for this in-memory format to be used by arbitrary other backends..I think these "Var" and "Proc"
will become a sticking point. I think we need a backend-independent way to refer to them.
I think INTEGER is the way. Like how M3CG_BinWr deals with them.
The downside/cost is that in M3x86.m3, rather than directly using the pointer (after narrow),
it will instead index into its own private array.


For efficiency, maybe some hint would come to the backend early as to how large to make the arrays?
Or maybe that defeats some of the design -- the single pass implementations.
(m3front is many-pass anyway, right? All this single-pass stuff is kind of only theoretical, right?
The compiler working-set is not small and fixed size, but rather scales with module size, right?)
Anyway, ok, either way. Backends can just at-least-double their internal arrays as they go.


One might suggest some sort of "multiple playback" based on M3CG_BinWr/BinRd.
I'm open to that. But it has some extra unnneeded overhead vs. a typical in-memory representation.
I'm also open to changing BinWr/BinRd to use a larger representation that requires "no" decoding.
(I've sketched this out myself, but decided it is not a priority. BinWr/BinRd really only
exist for licensing reasons and would likely go away if m3cc went away. I think. They are kind
of otherwise useful, at least during development.)


Thoughts?



 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120822/fe409428/attachment-0001.html>