[M3devel] why this loop/multipass stuff

[Jay K]

why this loop/multipass stuff


So people understand where I'm going here -- and Tony asked. I had already written this up..



1) in the past working on m3cc/parse.c, I found that "declare"s
weren't always "topologically sorted".


That is, like, I might see:

given TYPE T1 = INTEGER;
TYPE T2 = RECORD = a:T1; END;


I might have seen type T1 declared before T2, or not.
I'm not sure if it was record/fields or other relationships.
I just remember that building up a map of typeid to data, and
looking up it when needed, didn't always work, with one pass.


So what I did is that I was willing to "skip" declares
that referred to typeids I hadn't seen yet, and then loop
again, hoping for progress at each loop (fewer skips).


2) It looks like declare_local/temp don't all come in
"at the start" of a procedure. I'm not sure if I'm generating
C or C++, but if I'm generating C, it helps to have declare_local/temp
right after begin_procedure/block. Multiple passes let me make that
so, without changing m3front.
(Upon further looking..it seems this is mostly done right, but
not for "try" blocks; maybe reasonable to change m3front here.).


Now, generating C++ is an option, and I'm ignoring all declares
currently anyway, so these don't force the matter, but:


3) nested functions.
If a function contains any nested functions, I want to put all of
its locals in a local struct, and use the address of that struct
as the "static link". Or at least the locals that are referenced
by nested functions. As well, m3front contains options as to
the order of outputing functions. It uses one order for m3back and
a different order for m3cc. I wouldn't mind if M3C.m3 worked either
way.


There are possibly other benefits that could be derived from multiple passes.
Nothing offhand though.


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