<html><body bgcolor="#FFFFFF"><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 href="mailto: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 href="mailto:jay.krell@cornell.edu"><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a></a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
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></body></html>