<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>It might need some pre-processor but C is supposedly superior in performance than C# and Java by far, I mean we are not talking about using C, we are talking about generating object code from UNSAFE code, but it shouldn't be that bad in terms of assembly level compile and link time process compared to those systems, if not then why every body wants their software be written in (e.g us) Modula-3, but compiled in a C environment it must be something about engineering causes of who wrote that thing first, and C is much older, so there is better support for that UNSAFE level code (instead look C3 and Java, lame), and that's for me more important in this matter.<br>Probably C is referred as a high-level assembly (like DEC-SRC first versions), instead of a low-level assembly language like here we are trying to do.<br>In fact if we were able to generate C
from M3CG we can gain better portability, for instance my project of compare cross-boots would be more easily than by itself now.<br>Thanks in advance<br><br>--- El <b>mar, 21/8/12, Dirk Muysers <i><dmuysers@hotmail.com></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Dirk Muysers <dmuysers@hotmail.com><br>Asunto: Re: [M3devel] higher level m3cg?<br>Para: "Jay K" <jay.krell@cornell.edu>, "m3devel" <m3devel@elegosoft.com><br>Fecha: martes, 21 de agosto, 2012 06:18<br><br><div id="yiv729856355">
<style><!--
#yiv729856355 .yiv729856355hmmessage P
{
margin:0px;padding:0px;}
#yiv729856355 body.yiv729856355hmmessage
{
font-size:12pt;font-family:Calibri;}
--></style>
<div>
<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="yiv729856355post-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></div></blockquote></td></tr></table>