[M3devel] reducing our diff to gcc?

[Daniel Alejandro Benavides D.]

Hi all:
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).
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.
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). 
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?

Thanks in advance



--- El mar, 12/6/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribió:

De: Rodney M. Bates <rodney_bates at lcwb.coop>
Asunto: Re: [M3devel] reducing our diff to gcc?
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 12 de junio, 2012 11:17



On 06/11/2012 02:07 PM, Jay K wrote:
>
>   >  Maybe gcc would be easier too, if we didn't do our own debug
>    >  info production in parse.c.
>
> Correct. It is "our fault" for doing wierd things debugging-wise.
>
>   >  That could be a lot of work
>
>
> It is "the right amount of work", but yeah, kind of a lot.
>
>   >  but would fit fit nicely with switching to dwarf.
> We'd just use -g and use whatever gcc wants for the target system.
> Sometimes Dwarf, sometimes not, we wouldn't care.
>

It's going to require quite a lot in m3gdb.  Stock gdb has readers for several
debug info formats, but there's a lot that is language-dependent, even for C,
let alone the other languages supported by stock gdb.  I think this has considerable
debug-format dependency too, leading to a Cartesian product.  It is certainly
that way for Modula-3.  I would be greatly surprised if gcc didn't also require
at least a bit of M3-dependent work, even for dwarf.

>
>   >  As I understood it, all of the changes tree-nested.c makes are really only
>   >  needed for the interaction between nonlocal variable access _and_ inlining.
>
>
> I don't think so, but I don't know.
>
>
>   >  The last I knew we have had inlining disabled from the beginning anyway.
>
>
> We have inlining on mostly. Aside from a small sprinkling of "volatile".
> Off in gcc 4.6 backend, but I never enabled that and am moving on to 4.7 rapidly.
>
>
>   >  what would you think of just disabling what tree-nested does?
> I'm really not sure it is possible.
> Sure, if nested functions used only for "lexical hiding" of the functions themselves.
> But Modula-3 uses the "static link" in a unique-to-itself way.
> I don't expect gcc to "just work".
> I can explain the Modula-3 unique way if people want.
> It turns out..I have thought about this a bunch, there is no good way to handle the static link,
> given that you can take the addresses of nested functions. (Right?)
>

Please elaborate.  Yes, you can take the address of a nested function.  But you can
only pass it as a parameter.  You can't assign it to a variable.  This latter restriction
requires some runtime enforcement, but I think it is taken care of by explicitly
coded runtime checks generated by parse.c or earlier.

The nested-function language extension to C, implemented by stock gcc, allows the taking
of the address of a nested function, without the restriction against assigning it to
a variable, with no linguistic safety added.  If, in C, you use such a function "address"
for a function that has returned, to quote from gcc "all hell will break loose".
But this should imply that stock gcc support is enough for Modula-3.

>
>
> Where you don't take the address, the static link can just be an extra parameter.
>

Either way, you need a static link, and it is just passed as an extra parameter.
In the x86 case, it is always passed in the same register (ecx, if I recall) and
always immediately stored by prolog code at the same place in the AR.  tree-nested
doesn't mess with this, but adds extra static-linkish variable(s) elsewhere in
the AR, derived from this one, and uses them in some/all places.

>
> Or maybe this is dealt with elsewhere or otherwise...
>
>
> We do actually use "extra parameter" sometimes for static link.
> And maybe elsewhere/otherwise is in the frontend, mostly..just mostly...
>
>
> There are comments in tree-nested.c indicating it has "bad history".
> But actually, I'm not sure it does things so poorly.
>

I haven't read the comments in later gcc versions, but the bad history I recall
is that it greatly simplifies an "insanely complicated" scheme.  Unfortunately,
the simplification is all compile-time, at the expense of replacing a relatively
simple runtime scheme with one I would call at least very complicated, if not
insanely so.

> The basic theory of nested functions includes stuffing locals into a struct,
> at least locals accessed by nested functions, and passing a pointer to that struct
> as an extra parameter. The locals include said pointer to struct of locals, in the case
> of multiple nesting levels. OR you can "flatten" things, I guess, maybe.f

Actually, it's the other way around.  All locals start out in a flat AR.  If the
function contains nested function(s), tree-nested collects the locals that are
referenced nonlocally (i.e., from within one of the nested functions) into a local
struct.  Then, the nested functions get and use what you could call a "derived static link"
(a better term is needed) that points directly to this struct rather than to the whole AR.
I guess this helps with inlining, in case the struct isn't actually located in the same way
inside the parent AR.

> Flattening is problematic though, given nested functions can be mutually recursive
> and such..you want to update just one place and have all the other code follow pointers to it.
> Optimization can copy around copies instead of pointers, where it is profitable.
> Sorry, I don't have time to explain right now.
>
>
>   - Jay
>
>
> ----------------------------------------
>> Date: Mon, 11 Jun 2012 07:39:09 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] reducing our diff to gcc?
>>
>>
>>
>> On 06/10/2012 03:34 AM, Jay K wrote:
>>>
>>> reducing our diff to gcc?
>>>
>>>
>>> Ignore my hacking: extern C, removal of optimizer, removal of gmp/mpfr/mpc..
>>>
>>>
>>> but wait: do people like removal of gmp/mpfr/mpc? I do. I'm torn.
>>>
>>> But to my point:
>>>
>>>
>>> gimplify.c: I think we can achieve the diff via langhook.gimplify_expr.
>>>
>>>
>>> tree.def: I think frontends can add their own codes in separate files, so the diff can be removed.
>>>
>>>
>>> but, tree-nested.c, I doubt this can be avoided..so I'm left probably
>>> just not bothering with the others.
>>>
>>
>> tree-nested.c has been a thorn in my side from its inception. I broke a whole
>> lot of stuff in m3gdb, everything that has to do with nonlocal variable access
>> and/or variables of procedure type. It reshuffles the activation record around,
>> with multiple copies of lots of things, especially the static link, which has
>> either two, or, if I remember right, three copies in different places. Moreover,
>> they don't all point to the same place in their target AR.
>>
>> All this wouldn't be too bad, if we got the debug info altered to reflect the
>> reality, but by the time tree-nested does its thing, it's kind of late to do
>> that easily. That's one of the attractions of llvm to me, that it's well set
>> up to transform both the code and its debug info in parallel, when doing
>> optimization. Maybe gcc would be easier too, if we didn't do our own debug
>> info production in parse.c. That could be a lot of work, but would fit
>> fit nicely with switching to dwarf.
>>
>> As I understood it, all of the changes tree-nested.c makes are really only
>> needed for the interaction between nonlocal variable access _and_ inlining.
>> The last I knew we have had inlining disabled from the beginning anyway.
>> Jay, if this is still true, and as you are into disabling various gcc
>> optimizations, what would you think of just disabling what tree-nested does?
>>
>>>
>>> Thoughts?
>>>
>>>
>>> There is also at least one bug fix...that I could avoid needing.
>>> There is a bug optimizing our form of div/mod.
>>> We could avoid that by going back to function calls, but..again, I'm torn.
>>>
>>>
>>> If you configure -enable-checking, at least currently, there are asserts that have to be removed.
>>>
>>>
>>> I think I'll just go ahead and patch 4.7 "completely", w/o overdoing it.
>>>
>>>
>>> - Jay
>>>
>                           
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120613/5653fadd/attachment-0002.html>