[M3devel] a "need" for multi-pass m3cg (or different order of calls)

[Jay K]

That is kind of what I need, but it can be done in a specific way. currently I have: print(u, "blah blah") I can instead go through and say: gen_code(u, "blah blah")gen_declaration(u, "blah blah")gen_segment_initializer(u, segment, "blah blah") each function is tied to a specific variablelater I'll just print all the variables OR I can decompose it into passes.Have several very small m3cg implementations.That share data.One that just pays attention to import_procedures. Builds up data for those.  Other later passes would mark in that what they used.One that just pays attention to initializers. Builds up data for those.Very late pass would go through various data and print it all.  It is surprising what one pass with minimal separate buffers can do.e.g. you need buffering to build up parameter lists.Actually, I guess Iwekeep around all the "procs", and their associated data, for the lifetime of a unit.An "IR" if you will -- just some structs/records with pointers.  The "frame" stuff I think I already have correct and working.But maybe not.It seems declare_locals sometimes happen before any code, sometimes in the middle of code.I at least handle the case where up_level locals are declared before there is any code.If they come in at arbitrary points in the code, that might be too late.I can put in checks for that. Not difficult.  Anyway... I'll get it figured out... hopefully within a few weeks cm3 will link, and then I'll move on to try to apply this backend to AMD64_NT.  Once that is working there will be some controversy what to do with it for existing targets, and directions of like, making it the one and only target.(That will require a fair amount of work, as I've said, the current C output is target-specific, due to endian, wordsize, jmpbuf size, and Win32 vs. Posix...Win32 vs. Posix is particularly difficult to deal with......eh... I guess what we there is generate both/all sets of C code and then the problem is really at the "makefile" level...so maybe that's not difficult...hm..actually I think this is wrong..I think we can have separate interfaces, with different types/constants, imported into common code.....maybe we do something like generate headers that are #included.....under #ifdef....? I don't know..later, much much later....)   - Jay
 > Date: Fri, 7 Sep 2012 20:36:19 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] a "need" for multi-pass m3cg (or different order of calls)
> 
> On Fri, Sep 07, 2012 at 04:10:19PM -0400, Antony Hosking wrote:
> > Sorry, I should have read more closely.  You are right.
> > Yes, I do believe that when generating C code you will need multiple 
> > passes to accumulate stuff to be dumped out together.
> > For example, I assume that to handle nested functions that you will 
> > construct a local "frame" struct for the function, containing a 
> > pointer to it’s outer scope frame struct plus all the local variables 
> > having "up_level==true".  There is no other way to do static chains 
> > portably in C.  A pointer to this frame struct will serve as the 
> > static link to inner-scope functions.
> 
> This is why I (once I had machines with gigabytes of RAM) devised the 
> following data structure in RAM:
> 
> It's a string with insertion points.  Initially, it's empty, with one 
> insertion point.  At any insertion point, anytine, you can insert a 
> string or an insertion point,  either before or after the insertion point.
> 
> Thus at any place in code generation where you might have to accumulate 
> declarations while you go on generating code that uses them elsewhere, 
> you set up two insertion points -- one where the declarations go, and 
> one where the other code goes.
> 
> When you're done, you just write it all out in sequence.
> 
> It eats storage, but is very simple to use.
> 
> In the old days, about four decades ago, I was thinking of bulding such 
> a data structure on disk.  Instead I generated code with a lot of 
> macro-time GOTO statemtents to rearrange the code as needed.
> 
> Using RAM is so much easier.
> 
> -- hendrik
> 
> > 
> > 
> > On Sep 6, 2012, at 10:23 PM, Jay K <jay.krell at cornell.edu> wrote:
> > 
> > > I'm not really suggesting any change to any existing code..
> > >  
> > > 
> > > Though, the frontend, I gather, is already multi-pass,
> > > so it might be nice if it did things in an order more
> > > convenient for backends.
> > > e.g. it'd be nice if all the import_procedure calls came in before any begin_procedure;
> > > as it stands, many come in early, and then more come in in the middle of code.
> > >  
> > > 
> > > I'm motivating that my C/C++ generating backend could
> > > benefit from internally having multiple passes.
> > >  
> > > 
> > > Which might be convenient to implement via a general
> > > mechanism for combining multiple "partial" passes.
> > >  
> > >  
> > > Such mechanism would naturally "temporarily persist"
> > > a faithful m3cg representation in memory.
> > > Very similar to the existing temporary binary files
> > > we feed to parse.c, but without all the encoding for
> > > compactness. i.e. an array of records
> > >  
> > >  
> > > I guess I'll still try to ignore this matter for now.
> > > I'm getting by with one pass that generates invalid C++ but valid C.
> > >  
> > >  
> > > Possibly I can provide a "nicely reordering m3cg"
> > > that buffers it all up and then plays it back
> > > in a slightly better order, that is more amenable
> > > to a simple implementation, e.g. again getting
> > > all the import_procedure calls in before any begin_procedure.
> 
> You could use a mechanism like mine.  I could send you my C code for it 
> if you like.  Or you could write the inport procedure calls out to one 
> file and the begin_procedures to another and subsequently concatenate 
> them.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120908/d1970c98/attachment-0002.html>