[M3devel] higher level m3cg?

[Antony Hosking]

Yes, I've thought so for a long time. It would also more easily enable llvm. 

Sent from my iPhone

On Aug 16, 2012, at 10:21, Jay K <jay.krell at cornell.edu> 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.
> 
> 
> 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
> 
> 
> 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".
> 
> 
> 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.
> 
> 
> 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?
> 
> 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?
> 
> 
> 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.
> 
> 
>  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120816/f77e17bf/attachment-0002.html>