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

[Hendrik Boom]

On Sat, Sep 08, 2012 at 01:58:17AM +0000, Jay K wrote:
> 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 cor
> rect 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 w
> rong..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

I don't know if it would help to look at what the smarteiffel compiler does.  It 
also generates C code, so it may have to face the same problems.  It might be 
useful if your and its object code were compatible, too.
Hmm.  More current is Gambit/C, a conpiler that generates C code for Scheme 
sosurce.

Too many of these garbage-collected languages won't talk to one another.

I know;  I'm drifting off to pie in the sky.

-- hendrik