[M3devel] why this loop/multipass stuff

[Tony Hosking]

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





On Aug 22, 2012, at 10:24 AM, Jay K <jay.krell at cornell.edu> wrote:

> 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).

Was this all in aid of building up proper type descriptors?

> 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.

Preferably these only, or else you will cause all locals to be in memory instead of registers.

> 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/561ebd13/attachment-0002.html>