Re: [C--] C-- development

Yes, C-- as a standalone project is moribund in the sense that no one is working on it. But I think there were some interesting ideas in C--, notably concerning the runtime API for exception handling and garbage collection.  I'm not sure of the extent to which these ideas show up in LLVM, but that's just my ignorance.

However, in effect, LLVM is now the incumbent on the "portable assembly language" patch -- and more power to them!  There is a critical mass of people and companies gathered around LLVM doing great things.  One may argue (and some of you kindly have) that C-- does something better or more elegantly, but it's hard to argue with LLVM's momentum.  And that momentum is a good thing, because it motivates people to do the sweaty work of porting to new platforms etc. In effect, a "portable assembly language" HAS to have critical mass to meet its design purpose.

That said, I think C-- is wide open to people jumping in and "owning" it themselves, a research/development project.  Just go for it; Norman and I would be delighted.

GHC (the Glasgow Haskell Compiler) indeed uses C-- as an intermediate language, via its intermediate data type called 'Cmm'.  There's an external form too in .cmm files.  But in both cases it is somewhat adapted to the GHC setting, and so is not intended to be a standalone language useful as a backend for many things. (It may be, but we've felt free not to make that a constraint.)  As Norman says, it's an "extended subset"! 

We don't use qc--; rather there's a Cmm -> native code compiler in GHC.  And, in fact a Cmm -> LLVM generator that then uses LLVM as a back end.

I hope that helps clarify

Simon

| -----Original Message-----
| From: [email protected] [mailto:cminusminus-
| [email protected]] On Behalf Of doug moen
| Sent: 13 March 2013 16:44
| To: Hendrik Boom
| Cc: [email protected]
| Subject: Re: [C--] C-- development
| 
| From my outsider perspective, it appears that C-- is moribund until
| someone picks it up again. However, I also think that, rather than
| starting from the current C-- code base, it would be better to migrate
| the distinctive features of C-- into the LLVM project. Then, if you
| like, the C-- syntax could continue to be supported by writing a C--
| compiler with an LLVM back end. But you could get the benefits of C--
| semantics for your back end without generating C-- syntax, because those
| semantics would be part of LLVM. I'm not pretending this would be easy.
| But if it could be done, it would be the best way to bring the
| innovative ideas in C-- into the mainstream. I'll also note that the C--
| project was originally based on the design of the GHC (Haskell
| Compiler) back end, which has an intermediate language called C-- or
| Cmm. GHC also supports LLVM as an alternative back end, and I believe
| there are people in the GHC community who would gladly abandon the
| maintenance of the Cmm backend if LLVM were extended to do everything
| that Cmm does.
| 
| Doug Moen.
| 
| On 13 March 2013 11:49, Hendrik Boom <[email protected]> wrote:
| > Has development on C-- ceased?  Or just stalled for a few years?
| >
| > I notice in there seems to be files in qc--20090627/src with makes
| > starting with 'mips' and 'alpha' and 'ia64'.  Does this imply that
| > these architecures are actually supported?  Or are they still under
| > development and stalled along with the rest of the system.
| >
| > Is  IA64 the Itanium?  Or is it what Debian calls AMD64, the 64-bit
| > extension to Intel's traditional 32-bit archtecture?
| >
| > Is there other source code for C-- lying around somewhere that isn't
| > in the destributed package?
| >
| > If I were to want to use it on, say, an ARM machine, would I have to
| > do it myself?
| >
| > Would it be better to continue on from qc--, or better to start from
| > scratch?  Are there lessons to be learned from the qc-- experience I'd
| > better find out about before I even think of  doing this (and maybe
| > think better of it and find another worthy project?)
| >
| > -- hendrik
| >
| > _______________________________________________
| > Cminusminus mailing list
| > [email protected]
| > https://lists.eecs.harvard.edu/mailman/listinfo/cminusminus
| _______________________________________________
| Cminusminus mailing list
| [email protected]
| https://lists.eecs.harvard.edu/mailman/listinfo/cminusminus
_______________________________________________
Cminusminus mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/cminusminus