<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>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.<br>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.<br>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.<br>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.<br>Thanks in advance<br><br>--- El <b>jue, 16/8/12, Jay <i><jay.krell@cornell.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Jay <jay.krell@cornell.edu><br>Asunto: Re: [M3devel] higher level m3cg?<br>Para: "Antony Hosking" <hosking@cs.purdue.edu><br>CC: "m3devel" <m3devel@elegosoft.com>, "Jay K" <jay.krell@cornell.edu><br>Fecha: jueves, 16 de agosto, 2012 13:43<br><br><div id="yiv307268691"><div><div>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".</div><div> </div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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. </div><div>But that would snowball a bit -- generating the catch/__except code would likely require other higher level information.</div><div><br></div><div><br></div><div>On the matter of LLVM I don't expect to have the time/motivation.</div><div><br></div><div><br>Anyway, I'll press on for asis.</div><div>I have to figure out something for nested functions...</div><div><br></div><div><br></div><div> - Jay (briefly/pocket-sized-computer-aka-phone)</div><div><br>On Aug 16, 2012, at 11:06 AM, Antony Hosking <<a
rel="nofollow" ymailto="mailto:hosking@cs.purdue.edu" target="_blank" href="/mc/compose?to=hosking@cs.purdue.edu">hosking@cs.purdue.edu</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div>Yes, I've thought so for a long time. It would also more easily enable llvm. <br><br>Sent from my iPhone</div><div><br>On Aug 16, 2012, at 10:21, Jay K <<a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu"></a><a rel="nofollow" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<style><!--
#yiv307268691 .yiv307268691hmmessage P
{
margin:0px;padding:0px;}
#yiv307268691 body.yiv307268691hmmessage
{
font-size:12pt;font-family:Calibri;}
--></style>
<div dir="ltr">Should m3cg provide enough information for a backend to generate idiomatic C?<br>(What is idiomatic C? e.g. I'm ignoring loop constructs and exception handlinh..)<br><br><br>Should we make it so?<br><br><br>Or be pragmatic and see if anyone gets to that point?<br><br><br>But, look at this another way.<br>Let's say we are keeping the gcc backend.<br><br><br>Isn't it reasonable to have a better experience with stock gdb?<br><br><br>What should m3cg look like then?<br><br><br>Matching up m3front to gcc turns out to be "wierd".<br>As does having a backend generate "C".<br><br><br>In particular, "wierd" because there is a "level mismatch".<br><br><br>m3cg presents a fairly low level view of the program.<br> It does layout. Global variables are stuffed into what you might call a "struct", with<br>no assigned field names. Field references are done by adding to addresses and casting.<br><br><br>Too low level to provide a "good" gcc tree
representation or to generate "normal" C.<br><br><br>One might be able to, by somewhat extraordinary means, make due.<br>That is, specifically one could deduce field references from<br>offsets/sizes. But maybe it is reasonable for load/store<br>to include fields? Maybe in addition to what it provides?<br><br><br>As well, it appears to me, that<br><br><br>given TYPE Enum = {One, Two, Three};<br><br>the m3cg is like:<br><br>declare enum typeidblah<br>declare enum_elt One<br>declare enum_elt Two<br>declare enum_elt Three<br>declare_typename typeidblah Enum<br><br><br>One kind of instead wants more like:<br><br><br>declare enum typeidblah Enum<br>declare enum_elt One => rename it Enum_One<br>declare enum_elt Two ""<br>declare enum_elt Three ""<br><br><br>However I understand that {One, Two, Three} exists<br>as anonymous type independent of the name "Enum".<br><br><br>One could just as well have:<br>given TYPE Enum1 = {One, Two, Three};<br>given TYPE
Enum2 = {One, Two, Three};<br><br><br>Enum1 and Enum2 probably have the same typeid, and are just<br>two typenames for the same type.<br><br><br>likewise:<br>given TYPE Enum1 = {One, Two, Three};<br>given TYPE Enum2 = Enum1;<br><br><br>but, pragmatically, in the interest of generating better C,<br>can we pass a name along with declare_enum?<br><br>I ask somewhat rhetorically. I realize there is the answer:<br> enum Mtypeid { Mtypeid_One, Mtypeid_Two, Mtypeid_Three };<br> typedef enum Mtypeid Enum1;<br><br><br>Also, enum variables I believe end up as just UINT8, 16, or 32.<br>Loads of enum values I believe end up as just loads of integers.<br>Can we pass along optional enum names with declare_local/declare_param?<br>And optional enum names with load_int?<br>Or add a separate load_enum call?<br><br><br>Really, I understand that the current interface can be pressed to do<br>pretty adequate things. I can infer field references. The way enums
work<br>isn't too bad.<br><br><br> - Jay </div>
</div></blockquote></div></blockquote></div></div></blockquote></td></tr></table>