<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<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"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody class=hmmessage leftMargin=0 topMargin=0
CanvasTabStop="true" name="Compose message area">
<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>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>Con: Only Windows platform is really prime-time quality</LI></UL>
<LI>
<P>LLVM:</P>
<UL>
<LI>Pro: enthusiastic user community with charismatic leader
<LI>Pro: serious backing from Apple
<LI>Pro: many interesting performance improvements
<LI>Con: somewhat complex interface
<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>
<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>Pro: design is reasonably mature and reasonably clean
<LI>Pro: supports accurate garbage collection
<LI>Pro: most users report it is very easy to use
<LI>Con: very small development team
<LI>Con: as of early 2009, supports only three hardware platforms (x86, PPC,
ARM)
<LI>Con: does not ship with a garbage collector
<LI>Con: project has no future</LI></UL>
<LI>
<P>C as target language</P>
<UL>
<LI>Pro: looks easy
<LI>Con: nearly impossible to get decent performance
<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></BODY></HTML>