[M3devel] higher level m3cg?

[Jay]

Btw, while I claimed to ignore them...a higher level information about exception handling to the backend might be good. & possibly loops. It really just depends on what the backend is outputting & how much work it is willing to do. There is kind of this "gradual lowering" going on..but sometimes things get "reraised".
 

I guess really there is no canonical set in stone interface & implementation. We'll figure it out gradually. But I also am not as familiar with the system as I would like.


On the matter of exception handling, it 'd likely be good to generate __try for NT platforms and C++ try otherwise. It'd likely make things more efficient. 
But that would snowball a bit -- generating the catch/__except code would likely require other higher level information.


On the matter of LLVM I don't expect to have the time/motivation.


Anyway, I'll press on for asis.
I have to figure out something for nested functions...


 - Jay (briefly/pocket-sized-computer-aka-phone)

On Aug 16, 2012, at 11:06 AM, Antony Hosking <hosking at cs.purdue.edu> wrote:

> 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/4ef63d09/attachment-0002.html>