<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>I find Ramsey's analysis rather incomplete.<br>He mentions CLR has industrial strength support.<br>But he fails to say that C also does, way more significantly so.<br>And you can barely mention CLR w/o also mentioning Java,<br> though CLR is more general.<BR> <BR><br>I know C has downsides.<br>C, without C++, has the same poor exception handling.<br>The performance of the compiler indeed will not be the best.<BR> <BR><br>The portability however will be tremendous.<br>Basically every system I can think of except Windows Phone 7<br>and web browsers have a production quality C and C++ compiler.<br>Examples of systems we don't support or support well today<br>that a C/C++ backend would trivially enable, that are still<br>manufactured, sold, updated:<br> PPC{32,64}_AIX (still might need #ifdef in m3core) <br> PPC64_{FREEBSD?,LINUX} <br> ARM32_DARWIN (iPhone, iPad) <br> MIPS64_{LINUX,OPENBSD} <br> IA64_{VMS,HPUX,FREEBSD,LINUX} (still might need #ifdef in m3core<br> due to the "two stacks"; I'm also worried that a 64bit <br> integer closure marker is too small) <br> ARM32_LINUX (including Android) <br> MIPS32_LINUX (network routers!) <br> ARM32_NT <br> ARM64_? <br> {PPC32,MIPS32,ARM32,I386}_CE <BR><br> plus some more obsolete systems: <br> ALPHA{32,64}_VMS <br> PPC64_DARWIN <br> MIPS{32,64}_IRIX <br> PA{32,64}_HPUX <BR> <br> <br>Granted, gcc/m3cc is *almost* as portable, and some of the <br>above I have gotten far along in supporting -- really, <br>given the gcc/m3cc/posix base, the biggest task to any port <br>is getting the hardware up and running and with a decent C toolset. <BR> <BR> <BR> <BR>Plus that we would gain a "portable distribution format"<br>that people could just tar xfz; cd; ./configure; make; make install<BR> <BR><br>Granted, I don't have much experience in any area here,<br>and I don't yet have C working.<BR> <BR><br>LLVM will also take more time and learning. I probably won't put the time into it.<br>I am hoping to get the C backend working, so that the cm3 system might<br>be considered significantly more "done", so as new processors come along,<br>no new porting will be needed, just as for the vast majority of code out there.<BR> <BR> <BR>LLVM supports many more architectures than listed below.<BR> <BR><br>Anyway..later..<br> - Jay<br><br> <BR><div><div id="SkyDrivePlaceholder"></div>> CC: hosking@cs.purdue.edu; dmuysers@hotmail.com; m3devel@elegosoft.com; jay.krell@cornell.edu<br>> From: jay.krell@cornell.edu<br>> Subject: Re: [M3devel] higher level m3cg?<br>> Date: Tue, 21 Aug 2012 12:26:49 -0700<br>> To: lemming@henning-thielemann.de<br>> <br>> I don't see why C will be a problem. Performance of the compiler or the generated code? Our current system is bad on both fronts already, but nobody seems to notice. And yes it does look easy. I don't know why it'd cause craziness. M3cc is hardly writing our own & has serious shortcomings: stock debugging, exception handling...<br>> <br>> - Jay (briefly/pocket-sized-computer-aka-phone)<br>> <br>> On Aug 21, 2012, at 11:14 AM, Henning Thielemann <lemming@henning-thielemann.de> wrote:<br>> <br>> > <br>> > On Tue, 21 Aug 2012, Antony Hosking wrote:<br>> > <br>> >> *** A warning ***<br>> >> Norman Ramsey's opinion (in stackoverflow) on possible compiler backends:<br>> >> <br>> >> Code generation is my business :-)<br>> >> Comments on a few options:<br>> >> <br>> >> * <br>> >> CLR:<br>> >> <br>> >> + Pro: industrial support<br>> >> + Con: you have to buy into their type system pretty much completely; depending on what you want<br>> >> to do with types, this may not matter<br>> >> + Con: Only Windows platform is really prime-time quality<br>> >> * <br>> >> LLVM:<br>> >> <br>> >> + Pro: enthusiastic user community with charismatic leader<br>> >> + Pro: serious backing from Apple<br>> >> + Pro: many interesting performance improvements<br>> >> + Con: somewhat complex interface<br>> >> + Con: history of holes in the engineering; as LLVM matures expect the holes in the engineering<br>> >> to be plugged by adding to the complexity of the interface<br>> > <br>> > Additional Con: They introduce bugs from time to time and then they do not fix them ...<br>> > <br>> > <br>> >> * <br>> >> C--<br>> >> <br>> >> + Pro: target is an actual written language, not an API; you can easily inspect, debug, and edit<br>> >> your C-- code<br>> > <br>> > LLVM has also a text representation for its intermediate code. This way you can write intermediate code by hand and experiment with it. However, it is verbose and redundant.<br>> > <br>> >> + Pro: design is reasonably mature and reasonably clean<br>> >> + Pro: supports accurate garbage collection<br>> >> + Pro: most users report it is very easy to use<br>> >> + Con: very small development team<br>> >> + Con: as of early 2009, supports only three hardware platforms (x86, PPC, ARM)<br>> >> + Con: does not ship with a garbage collector<br>> >> + Con: project has no future<br>> >> * <br>> >> C as target language<br>> >> <br>> >> + Pro: looks easy<br>> >> + Con: nearly impossible to get decent performance<br>> >> + Con: will drive you nuts in the long run; ask the long line of people who have tried to<br>> >> compile Haskell, ML, Modula-3, Scheme and more using this technique. At some point every one<br>> >> of these people gave up and built their own native code generator.<br>> >> Summary: anything except C is a reasonable choice. For the best combination of flexibility, quality,<br>> >> and expected longevity, I'd probably recommend LLVM.<br>> > <br>> > Despite my 'con' point I would recommend LLVM, too.<br>> > <br></div> </div></body>
</html>