<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>in fact language-dependent-parts of a debugger inherently are 'part' of compiler architecture (needs to re-implement a lot of machinery in Gdb from Gcc, maybe it's still the same but could be reordered to cut it down if so is done in C).<br>I have heard M3gdb is like 20k loc, this is hard to me, and in C, worse, I think a full debugger can be implemented in such lines, at least in ldb is like that, so I don't how much really M3gdb is not in Gdb.<br>Now, m3gcc or m3cgc or m3cg or m3cc is not of interest in GNU why keep it,like that, we should use it as a real backend for using it as a language but as a real architecture, as it isn't what would it take to do that? In fact that's what we are trying to do with JIT, right? What I have found tells me that C code tends to be AFAIK portable in the form of a stack architecture like M3CG than anything else In
the other sense, compiling gcc over and over again, I don't know how many of us want to do that each time we compile a Modula-3 distribution (I do). <br>Now, I don't think gcc wnats to add and support our ideal architecture, but anyway who knows if the thing will work for us, maybe they will want it, won't they?<br><br>Thanks in advance<br><br><br><br>--- El <b>mar, 12/6/12, Rodney M. Bates <i><rodney_bates@lcwb.coop></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Rodney M. Bates <rodney_bates@lcwb.coop><br>Asunto: Re: [M3devel] reducing our diff to gcc?<br>Para: "m3devel" <m3devel@elegosoft.com><br>Fecha: martes, 12 de junio, 2012 11:17<br><br><div class="plainMail"><br><br>On 06/11/2012 02:07 PM, Jay K wrote:<br>><br>> > Maybe gcc would be easier too, if we didn't do our own debug<br>> > info
production in parse.c.<br>><br>> Correct. It is "our fault" for doing wierd things debugging-wise.<br>><br>> > That could be a lot of work<br>><br>><br>> It is "the right amount of work", but yeah, kind of a lot.<br>><br>> > but would fit fit nicely with switching to dwarf.<br>> We'd just use -g and use whatever gcc wants for the target system.<br>> Sometimes Dwarf, sometimes not, we wouldn't care.<br>><br><br>It's going to require quite a lot in m3gdb. Stock gdb has readers for several<br>debug info formats, but there's a lot that is language-dependent, even for C,<br>let alone the other languages supported by stock gdb. I think this has considerable<br>debug-format dependency too, leading to a Cartesian product. It is certainly<br>that way for Modula-3. I would be greatly surprised if gcc didn't also require<br>at least a bit of M3-dependent
work, even for dwarf.<br><br>><br>> > As I understood it, all of the changes tree-nested.c makes are really only<br>> > needed for the interaction between nonlocal variable access _and_ inlining.<br>><br>><br>> I don't think so, but I don't know.<br>><br>><br>> > The last I knew we have had inlining disabled from the beginning anyway.<br>><br>><br>> We have inlining on mostly. Aside from a small sprinkling of "volatile".<br>> Off in gcc 4.6 backend, but I never enabled that and am moving on to 4.7 rapidly.<br>><br>><br>> > what would you think of just disabling what tree-nested does?<br>> I'm really not sure it is possible.<br>> Sure, if nested functions used only for "lexical hiding" of the functions themselves.<br>> But Modula-3 uses the "static link" in a unique-to-itself way.<br>> I don't
expect gcc to "just work".<br>> I can explain the Modula-3 unique way if people want.<br>> It turns out..I have thought about this a bunch, there is no good way to handle the static link,<br>> given that you can take the addresses of nested functions. (Right?)<br>><br><br>Please elaborate. Yes, you can take the address of a nested function. But you can<br>only pass it as a parameter. You can't assign it to a variable. This latter restriction<br>requires some runtime enforcement, but I think it is taken care of by explicitly<br>coded runtime checks generated by parse.c or earlier.<br><br>The nested-function language extension to C, implemented by stock gcc, allows the taking<br>of the address of a nested function, without the restriction against assigning it to<br>a variable, with no linguistic safety added. If, in C, you use such a function "address"<br>for a function that has returned, to quote from gcc "all
hell will break loose".<br>But this should imply that stock gcc support is enough for Modula-3.<br><br>><br>><br>> Where you don't take the address, the static link can just be an extra parameter.<br>><br><br>Either way, you need a static link, and it is just passed as an extra parameter.<br>In the x86 case, it is always passed in the same register (ecx, if I recall) and<br>always immediately stored by prolog code at the same place in the AR. tree-nested<br>doesn't mess with this, but adds extra static-linkish variable(s) elsewhere in<br>the AR, derived from this one, and uses them in some/all places.<br><br>><br>> Or maybe this is dealt with elsewhere or otherwise...<br>><br>><br>> We do actually use "extra parameter" sometimes for static link.<br>> And maybe elsewhere/otherwise is in the frontend, mostly..just mostly...<br>><br>><br>> There are comments in tree-nested.c indicating it has "bad
history".<br>> But actually, I'm not sure it does things so poorly.<br>><br><br>I haven't read the comments in later gcc versions, but the bad history I recall<br>is that it greatly simplifies an "insanely complicated" scheme. Unfortunately,<br>the simplification is all compile-time, at the expense of replacing a relatively<br>simple runtime scheme with one I would call at least very complicated, if not<br>insanely so.<br><br>> The basic theory of nested functions includes stuffing locals into a struct,<br>> at least locals accessed by nested functions, and passing a pointer to that struct<br>> as an extra parameter. The locals include said pointer to struct of locals, in the case<br>> of multiple nesting levels. OR you can "flatten" things, I guess, maybe.f<br><br>Actually, it's the other way around. All locals start out in a flat AR. If the<br>function contains nested function(s), tree-nested collects the locals
that are<br>referenced nonlocally (i.e., from within one of the nested functions) into a local<br>struct. Then, the nested functions get and use what you could call a "derived static link"<br>(a better term is needed) that points directly to this struct rather than to the whole AR.<br>I guess this helps with inlining, in case the struct isn't actually located in the same way<br>inside the parent AR.<br><br>> Flattening is problematic though, given nested functions can be mutually recursive<br>> and such..you want to update just one place and have all the other code follow pointers to it.<br>> Optimization can copy around copies instead of pointers, where it is profitable.<br>> Sorry, I don't have time to explain right now.<br>><br>><br>> - Jay<br>><br>><br>> ----------------------------------------<br>>> Date: Mon, 11 Jun 2012 07:39:09 -0500<br>>> From: <a
ymailto="mailto:rodney_bates@lcwb.coop" href="/mc/compose?to=rodney_bates@lcwb.coop">rodney_bates@lcwb.coop</a><br>>> To: <a ymailto="mailto:m3devel@elegosoft.com" href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>>> Subject: Re: [M3devel] reducing our diff to gcc?<br>>><br>>><br>>><br>>> On 06/10/2012 03:34 AM, Jay K wrote:<br>>>><br>>>> reducing our diff to gcc?<br>>>><br>>>><br>>>> Ignore my hacking: extern C, removal of optimizer, removal of gmp/mpfr/mpc..<br>>>><br>>>><br>>>> but wait: do people like removal of gmp/mpfr/mpc? I do. I'm torn.<br>>>><br>>>> But to my point:<br>>>><br>>>><br>>>> gimplify.c: I think we can achieve the diff via langhook.gimplify_expr.<br>>>><br>>>><br>>>> tree.def: I think frontends can add their own codes in separate
files, so the diff can be removed.<br>>>><br>>>><br>>>> but, tree-nested.c, I doubt this can be avoided..so I'm left probably<br>>>> just not bothering with the others.<br>>>><br>>><br>>> tree-nested.c has been a thorn in my side from its inception. I broke a whole<br>>> lot of stuff in m3gdb, everything that has to do with nonlocal variable access<br>>> and/or variables of procedure type. It reshuffles the activation record around,<br>>> with multiple copies of lots of things, especially the static link, which has<br>>> either two, or, if I remember right, three copies in different places. Moreover,<br>>> they don't all point to the same place in their target AR.<br>>><br>>> All this wouldn't be too bad, if we got the debug info altered to reflect the<br>>> reality, but by the time tree-nested does its thing, it's kind of late to do<br>>> that
easily. That's one of the attractions of llvm to me, that it's well set<br>>> up to transform both the code and its debug info in parallel, when doing<br>>> optimization. Maybe gcc would be easier too, if we didn't do our own debug<br>>> info production in parse.c. That could be a lot of work, but would fit<br>>> fit nicely with switching to dwarf.<br>>><br>>> As I understood it, all of the changes tree-nested.c makes are really only<br>>> needed for the interaction between nonlocal variable access _and_ inlining.<br>>> The last I knew we have had inlining disabled from the beginning anyway.<br>>> Jay, if this is still true, and as you are into disabling various gcc<br>>> optimizations, what would you think of just disabling what tree-nested does?<br>>><br>>>><br>>>> Thoughts?<br>>>><br>>>><br>>>> There is also at least one bug fix...that I
could avoid needing.<br>>>> There is a bug optimizing our form of div/mod.<br>>>> We could avoid that by going back to function calls, but..again, I'm torn.<br>>>><br>>>><br>>>> If you configure -enable-checking, at least currently, there are asserts that have to be removed.<br>>>><br>>>><br>>>> I think I'll just go ahead and patch 4.7 "completely", w/o overdoing it.<br>>>><br>>>><br>>>> - Jay<br>>>><br>> <br></div></blockquote></td></tr></table>