[M3devel] higher level m3cg?

[Rodney M. Bates]

On 08/16/2012 09:21 AM, Jay K wrote:
> Should m3cg provide enough information for a backend to generate idiomatic C?
> (What is idiomatic C? e.g. I'm ignoring loop constructs and exception handlinh..)
>
>
> Should we make it so?
>
>
> Or be pragmatic and see if anyone gets to that point?
>
>
> But, look at this another way.
> Let's say we are keeping the gcc backend.
>
>
> Isn't it reasonable to have a better experience with stock gdb?
>
>
> What should m3cg look like then?
>
>
> Matching up m3front to gcc turns out to be "wierd".
> As does having a backend generate "C".
>
>
> In particular, "wierd" because there is a "level mismatch".
>
>
> m3cg presents a fairly low level view of the program.
>    It does layout. Global variables are stuffed into what you might call a "struct", with
> no assigned field names. Field references are done by adding to addresses and casting.

In the stabs debug info given to (m3)gdb, they do have field names, with the original source
code field name embedded within, plus a character-encoded uid and some flags, etc.

>
>
> Too low level to provide a "good" gcc tree representation or to generate "normal" C.
>
>
> One might be able to, by somewhat extraordinary means, make due.
> That is, specifically one could deduce field references from
> offsets/sizes. But maybe it is reasonable for load/store
> to include fields? Maybe in addition to what it provides?
>
>
> As well, it appears to me, that
>
>
> given TYPE Enum = {One, Two, Three};
>
> the m3cg is like:
>
> declare enum typeidblah
> declare enum_elt One
> declare enum_elt Two
> declare enum_elt Three
> declare_typename typeidblah Enum
>
>

This is the more reasonable representation, in view of the fact
that any type expression is itself anonymous, as you note below,
while giving it a type name is a separate matter, done outside
the type definition.

> One kind of instead wants more like:
>
>
> declare enum typeidblah Enum
> declare enum_elt One => rename it Enum_One
> declare enum_elt Two ""
> declare enum_elt Three ""
>
>
> However I understand that {One, Two, Three} exists
> as anonymous type independent of the name "Enum".

Yes.

>
>
> One could just as well have:
> given TYPE Enum1 = {One, Two, Three};
> given TYPE Enum2 = {One, Two, Three};
>
>
> Enum1 and Enum2 probably have the same typeid, and are just
> two typenames for the same type.
>

Yes.

>
> likewise:
> given TYPE Enum1 = {One, Two, Three};
> given TYPE Enum2 = Enum1;
>
>
> but, pragmatically, in the interest of generating better C,
> can we pass a name along with declare_enum?
>

This business of anonymous types is pervasive, not just for
enumeration types and not just in Modula-3.  It shows up
all over the place in StubGen, which has lots of code
obviously intended to handle anonymous object types and,
not so obviously, broken, or at least unfinished.  I guess
nobody actually does it.  Having once been inside that code,
I would not define an anonymous type I wanted to have involved
in anyway with network objects.

Anonymous types are usually not particularly good coding style,
and I almost always regret defining one and end up giving it a
name after all, as I want to use it in multiple places.

Modula-3's structural type equality rules perhaps encourage it
more than so-called name equality.  C encourages it too for
the declarator types and by requiring manual construction of
pass-by-reference by the programmer, instead of parameter modes.
Something similar for the second-class treatment of arrays.

> I ask somewhat rhetorically. I realize there is the answer:
>    enum Mtypeid { Mtypeid_One, Mtypeid_Two, Mtypeid_Three };
>    typedef enum Mtypeid Enum1;
>
>
> Also, enum variables I believe end up as just UINT8, 16, or 32.
> Loads of enum values I believe end up as just loads of integers.
> Can we pass along optional enum names with declare_local/declare_param?
> And optional enum names with load_int?
> Or add a separate load_enum call?
>

I don't remember the details, but m3gdb gets enumeration value names,
displays them, and recognizes them in commands.  They had to go through
parse.c to get to stabs.

>
> Really, I understand that the current interface can be pressed to do
> pretty adequate things. I can infer field references. The way enums work
> isn't too bad.
>
>

I know this is a broken record, but the fact that debug info comes off the
side of parse.c means it can't reflect optimizations/transformations done
later by the gcc backend.  E.g. tree-nested.c.

>   - Jay