[M3devel] higher level m3cg?

[Daniel Alejandro Benavides D.]

Hi all:
Jay, even in RISC like G. Nelson mentioned there was this problem of big executables, and I happen to believe this doesn't change things too much for the better, so be careful with summing all kind of stuff will go on OK, there could be the side effects that we don't like too much.
In the other side SPIN M3 Vortex compiler was a DEC-SRC modified front-end for that back-end to a Java-like subset backend, I don't know how well it was that, but at least they have done that already to the front-end so is less work to do.
I don't care if you redefine the language to admittedly drop some unwanted changes but with some purpose of simplifying things, this was the best effort they did so we need to be aware of that.
I generally don't take to heart this part of the system, but we need to respect the existence of this backend if somebody has a new better and brave CG that's better but to use your own language to do this I don't like the idea of several backends and different languages.
Thanks in advance

--- El jue, 16/8/12, Jay <jay.krell at cornell.edu> escribió:

De: Jay <jay.krell at cornell.edu>
Asunto: Re: [M3devel] higher level m3cg?
Para: "Antony Hosking" <hosking at cs.purdue.edu>
CC: "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
Fecha: jueves, 16 de agosto, 2012 13:43

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