<html><head></head><body bgcolor="#FFFFFF"><div>I concur strongly with Norman's analysis. We should be focusing on llvm. That will still require lifting the level of m3cg slightly, viz getelementptr. </div><div><br>Sent from my iPhone</div><div><br>On Aug 21, 2012, at 7:18, "Dirk Muysers" <<a href="mailto:dmuysers@hotmail.com">dmuysers@hotmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<meta content="text/html;charset=iso-8859-1" http-equiv="Content-Type">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<meta name="GENERATOR" content="MSHTML 8.00.6001.19258">
<div><font face="Arial">*** A warning ***</font></div>
<div><font face="Arial">Norman Ramsey's opinion (in stackoverflow) on
possible compiler backends:</font></div>
<div> </div>
<div>
<div class="post-text">
<p>Code generation is my business :-)</p>
<p>Comments on a few options:</p>
<ul>
<li>
<p>CLR: </p>
<ul>
<li>Pro: industrial support
</li><li>Con: you have to buy into their type system pretty much completely;
depending on what you want to do with types, this may not matter
</li><li>Con: Only Windows platform is really prime-time quality</li></ul>
</li><li>
<p>LLVM:</p>
<ul>
<li>Pro: enthusiastic user community with charismatic leader
</li><li>Pro: serious backing from Apple
</li><li>Pro: many interesting performance improvements
</li><li>Con: somewhat complex interface
</li><li>Con: history of holes in the engineering; as LLVM matures expect the
holes in the engineering to be plugged by adding to the complexity of the
interface</li></ul>
</li><li>
<p><a href="http://www.cminusminus.org/">C--</a></p>
<ul>
<li>Pro: target is an actual written language, not an API; you can easily
inspect, debug, and edit your C-- code
</li><li>Pro: design is reasonably mature and reasonably clean
</li><li>Pro: supports accurate garbage collection
</li><li>Pro: most users report it is very easy to use
</li><li>Con: very small development team
</li><li>Con: as of early 2009, supports only three hardware platforms (x86, PPC,
ARM)
</li><li>Con: does not ship with a garbage collector
</li><li>Con: project has no future</li></ul>
</li><li>
<p>C as target language</p>
<ul>
<li>Pro: looks easy
</li><li>Con: nearly impossible to get decent performance
</li><li>Con: will drive you nuts in the long run; ask the long line of people
who have tried to compile Haskell, ML, Modula-3, Scheme and more using this
technique. At some point every one of these people gave up and built their
own native code generator.</li></ul></li></ul>
<p>Summary: <strong>anything except C</strong> is a reasonable choice. For the
best combination of flexibility, quality, and expected longevity, I'd probably
recommend LLVM.</p>
<p>Full disclosure: I am affiliated with the C-- project.</p></div> </div>
<div style="FONT: 10pt Tahoma">
<div><br></div>
<div style="BACKGROUND: #f5f5f5">
<div style="font-color: black"><b>From:</b> <a title="jay.krell@cornell.edu" href="mailto:jay.krell@cornell.edu">Jay K</a> </div>
<div><b>Sent:</b> Thursday, August 16, 2012 4:21 PM</div>
<div><b>To:</b> <a title="m3devel@elegosoft.com" href="mailto:m3devel@elegosoft.com">m3devel</a> </div>
<div><b>Subject:</b> [M3devel] higher level m3cg?</div></div></div>
<div><br></div>
<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></body></html>