<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>target dependency is essential in this process, so a good backend must target an quintessential machine, so I don't agree a given machine will give us lot of optimization without lot of work:<br>http://irclog.perlgeek.de/parrot/2010-07-25#i_2605776<br><br>M3CG can be converted to a virtual machine as an emulator of an automaton, but studying that automaton complexity will give us the real facts (instead on believing stories), I don't want to fight wars among languages, but by practice we now know that C is far easier to code low level stuff than everything else, so .. if we want a radical change let's study why we do it first.<br>Thanks in advance<br><br>--- El <b>mar, 21/8/12, Antony Hosking <i><hosking@cs.purdue.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left:
5px;"><br>De: Antony Hosking <hosking@cs.purdue.edu><br>Asunto: Re: [M3devel] higher level m3cg?<br>Para: "Dirk Muysers" <dmuysers@hotmail.com><br>CC: "m3devel" <m3devel@elegosoft.com>, "Jay K" <jay.krell@cornell.edu><br>Fecha: martes, 21 de agosto, 2012 09:10<br><br><div id="yiv1453094616"><div><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 rel="nofollow" ymailto="mailto:dmuysers@hotmail.com" target="_blank" href="/mc/compose?to=dmuysers@hotmail.com">dmuysers@hotmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<style><!--
#yiv1453094616 .yiv1453094616hmmessage P
{
margin:0px;padding:0px;}
#yiv1453094616 body.yiv1453094616hmmessage
{
font-size:12pt;font-family:Calibri;}
--></style>
<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="yiv1453094616post-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 rel="nofollow" target="_blank" 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-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
<div><br></div>
<div style="background: rgb(245, 245, 245) none repeat scroll 0%; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">
<div style=""><b>From:</b> <a rel="nofollow" title="jay.krell@cornell.edu" ymailto="mailto:jay.krell@cornell.edu" target="_blank" href="/mc/compose?to=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 rel="nofollow" title="m3devel@elegosoft.com" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=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></div></div></blockquote></td></tr></table>