<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>That is kind of what I need, but it can be done in a specific way.<BR> <BR>currently I have:<BR> <BR>print(u, "blah blah")<BR> <BR>I can instead go through and say:<BR> <BR>gen_code(u, "blah blah")<BR>gen_declaration(u, "blah blah")<BR>gen_segment_initializer(u, segment, "blah blah")<BR> <BR>each function is tied to a specific variable<BR>later I'll just print all the variables<BR> <BR>OR I can decompose it into passes.<BR>Have several very small m3cg implementations.<BR>That share data.<BR>One that just pays attention to import_procedures. Builds up data for those.<BR> Other later passes would mark in that what they used.<BR>One that just pays attention to initializers. Builds up data for those.<BR>Very late pass would go through various data and print it all.<BR> <BR> <BR>It is surprising what one pass with minimal separate buffers can do.<BR>e.g. you need buffering to build up parameter lists.<BR>Actually, I guess Iwekeep around all the "procs", and their associated data, for the lifetime of a unit.<BR>An "IR" if you will -- just some structs/records with pointers.<BR> <BR> <BR>The "frame" stuff I think I already have correct and working.<BR>But maybe not.<BR>It seems declare_locals sometimes happen before any code, sometimes in the middle of code.<BR>I at least handle the case where up_level locals are declared before there is any code.<BR>If they come in at arbitrary points in the code, that might be too late.<BR>I can put in checks for that. Not difficult.<BR> <BR> <BR>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.<BR> <BR> <BR>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.<BR>(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....)<BR> <BR> <BR> - Jay<br> <BR><div><div id="SkyDrivePlaceholder"></div>> Date: Fri, 7 Sep 2012 20:36:19 -0400<br>> From: hendrik@topoi.pooq.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] a "need" for multi-pass m3cg (or different order of calls)<br>> <br>> On Fri, Sep 07, 2012 at 04:10:19PM -0400, Antony Hosking wrote:<br>> > Sorry, I should have read more closely. You are right.<br>> > Yes, I do believe that when generating C code you will need multiple <br>> > passes to accumulate stuff to be dumped out together.<br>> > For example, I assume that to handle nested functions that you will <br>> > construct a local "frame" struct for the function, containing a <br>> > pointer to it’s outer scope frame struct plus all the local variables <br>> > having "up_level==true". There is no other way to do static chains <br>> > portably in C. A pointer to this frame struct will serve as the <br>> > static link to inner-scope functions.<br>> <br>> This is why I (once I had machines with gigabytes of RAM) devised the <br>> following data structure in RAM:<br>> <br>> It's a string with insertion points. Initially, it's empty, with one <br>> insertion point. At any insertion point, anytine, you can insert a <br>> string or an insertion point, either before or after the insertion point.<br>> <br>> Thus at any place in code generation where you might have to accumulate <br>> declarations while you go on generating code that uses them elsewhere, <br>> you set up two insertion points -- one where the declarations go, and <br>> one where the other code goes.<br>> <br>> When you're done, you just write it all out in sequence.<br>> <br>> It eats storage, but is very simple to use.<br>> <br>> In the old days, about four decades ago, I was thinking of bulding such <br>> a data structure on disk. Instead I generated code with a lot of <br>> macro-time GOTO statemtents to rearrange the code as needed.<br>> <br>> Using RAM is so much easier.<br>> <br>> -- hendrik<br>> <br>> > <br>> > <br>> > On Sep 6, 2012, at 10:23 PM, Jay K <jay.krell@cornell.edu> wrote:<br>> > <br>> > > I'm not really suggesting any change to any existing code..<br>> > > <br>> > > <br>> > > Though, the frontend, I gather, is already multi-pass,<br>> > > so it might be nice if it did things in an order more<br>> > > convenient for backends.<br>> > > e.g. it'd be nice if all the import_procedure calls came in before any begin_procedure;<br>> > > as it stands, many come in early, and then more come in in the middle of code.<br>> > > <br>> > > <br>> > > I'm motivating that my C/C++ generating backend could<br>> > > benefit from internally having multiple passes.<br>> > > <br>> > > <br>> > > Which might be convenient to implement via a general<br>> > > mechanism for combining multiple "partial" passes.<br>> > > <br>> > > <br>> > > Such mechanism would naturally "temporarily persist"<br>> > > a faithful m3cg representation in memory.<br>> > > Very similar to the existing temporary binary files<br>> > > we feed to parse.c, but without all the encoding for<br>> > > compactness. i.e. an array of records<br>> > > <br>> > > <br>> > > I guess I'll still try to ignore this matter for now.<br>> > > I'm getting by with one pass that generates invalid C++ but valid C.<br>> > > <br>> > > <br>> > > Possibly I can provide a "nicely reordering m3cg"<br>> > > that buffers it all up and then plays it back<br>> > > in a slightly better order, that is more amenable<br>> > > to a simple implementation, e.g. again getting<br>> > > all the import_procedure calls in before any begin_procedure.<br>> <br>> You could use a mechanism like mine. I could send you my C code for it <br>> if you like. Or you could write the inport procedure calls out to one <br>> file and the begin_procedures to another and subsequently concatenate <br>> them.<br>> <br>> -- hendrik<br></div> </div></body>
</html>