[M3devel] higher level m3cg?

[Jay K]

I find Ramsey's analysis rather incomplete.
He mentions CLR has industrial strength support.
But he fails to say that C also does, way more significantly so.
And you can barely mention CLR w/o also mentioning Java,
  though CLR is more general. 
I know C has downsides.
C, without C++, has the same poor exception handling.
The performance of the compiler indeed will not be the best. 
The portability however will be tremendous.
Basically every system I can think of except Windows Phone 7
and web browsers have a production quality C and C++ compiler.
Examples of systems we don't support or support well today
that a C/C++ backend would trivially enable, that are still
manufactured, sold, updated:
  PPC{32,64}_AIX (still might need #ifdef in m3core) 
  PPC64_{FREEBSD?,LINUX} 
  ARM32_DARWIN (iPhone, iPad)  
  MIPS64_{LINUX,OPENBSD}  
  IA64_{VMS,HPUX,FREEBSD,LINUX} (still might need #ifdef in m3core
    due to the "two stacks"; I'm also worried that a 64bit 
    integer closure marker is too small) 
  ARM32_LINUX (including Android)     
  MIPS32_LINUX (network routers!)   
  ARM32_NT  
  ARM64_?    
  {PPC32,MIPS32,ARM32,I386}_CE  
  plus some more obsolete systems: 
    ALPHA{32,64}_VMS 
    PPC64_DARWIN 
    MIPS{32,64}_IRIX  
    PA{32,64}_HPUX   
  
Granted, gcc/m3cc is *almost* as portable, and some of the 
above I have gotten far along in supporting -- really, 
given the gcc/m3cc/posix base, the biggest task to any port 
is getting the hardware up and running and with a decent C toolset.     Plus that we would gain a "portable distribution format"
that people could just tar xfz; cd; ./configure; make; make install 
Granted, I don't have much experience in any area here,
and I don't yet have C working. 
LLVM will also take more time and learning. I probably won't put the time into it.
I am hoping to get the C backend working, so that the cm3 system might
be considered significantly more "done", so as new processors come along,
no new porting will be needed, just as for the vast majority of code out there.  LLVM supports many more architectures than listed below. 
Anyway..later..
 - Jay

 > CC: hosking at cs.purdue.edu; dmuysers at hotmail.com; m3devel at elegosoft.com; jay.krell at cornell.edu
> From: jay.krell at cornell.edu
> Subject: Re: [M3devel] higher level m3cg?
> Date: Tue, 21 Aug 2012 12:26:49 -0700
> To: lemming at henning-thielemann.de
> 
> 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...
> 
>  - Jay (briefly/pocket-sized-computer-aka-phone)
> 
> On Aug 21, 2012, at 11:14 AM, Henning Thielemann <lemming at henning-thielemann.de> wrote:
> 
> > 
> > On Tue, 21 Aug 2012, Antony Hosking wrote:
> > 
> >>      *** A warning ***
> >> Norman Ramsey's opinion (in stackoverflow) on possible compiler backends:
> >>  
> >> Code generation is my business :-)
> >> Comments on a few options:
> >> 
> >> * 
> >>    CLR:
> >> 
> >>     +  Pro: industrial support
> >>     +  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
> >>     +  Con: Only Windows platform is really prime-time quality
> >> * 
> >>    LLVM:
> >> 
> >>     +  Pro: enthusiastic user community with charismatic leader
> >>     +  Pro: serious backing from Apple
> >>     +  Pro: many interesting performance improvements
> >>     +  Con: somewhat complex interface
> >>     +  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
> > 
> > Additional Con: They introduce bugs from time to time and then they do not fix them ...
> > 
> > 
> >> * 
> >>    C--
> >> 
> >>     +  Pro: target is an actual written language, not an API; you can easily inspect, debug, and edit
> >>        your C-- code
> > 
> > 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.
> > 
> >>     +  Pro: design is reasonably mature and reasonably clean
> >>     +  Pro: supports accurate garbage collection
> >>     +  Pro: most users report it is very easy to use
> >>     +  Con: very small development team
> >>     +  Con: as of early 2009, supports only three hardware platforms (x86, PPC, ARM)
> >>     +  Con: does not ship with a garbage collector
> >>     +  Con: project has no future
> >> * 
> >>    C as target language
> >> 
> >>     +  Pro: looks easy
> >>     +  Con: nearly impossible to get decent performance
> >>     +  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.
> >> Summary: anything except C is a reasonable choice. For the best combination of flexibility, quality,
> >> and expected longevity, I'd probably recommend LLVM.
> > 
> > Despite my 'con' point I would recommend LLVM, too.
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120821/314794eb/attachment-0002.html>