Hacker News Reader

Comment by vezzy-fnord | Hacker News Reader

This is pretty old. I don't know if anyone else besides the GHC team use it?

I think its part of the quaint appeal of the article, that c-- only supports i386 but the way the world moved did not require c--, FSF supported GCC supports something like 50 archs and many more not officially FSF supported. And GCC is hardly the only c compiler out there. The world just didn't move in the direction directly requiring c--.

Now as for current ideas and projects similar in concept to c--, that is interesting to think about.

Maybe the startup lesson is sometimes, if you try to intermediate yourself as a middleman, even if you do a good job of it, and appear to be a good idea, it just doesn't work. It would be interesting to dissect the c-- experience and figure out why.

GCC did already exist when the C-- project was started, so that part didn't really change. The C-- team's hypothesis was that some kinds of languages (especially functional languages) would benefit from a cross-platform layer that is a better compilation target than C, partly through being a bit more low-level. The previous two popular routes were native-code compilers and compile-via-C compilers. Native-code compilers have the disadvantage that porting them and maintaining them on N architectures is significant work, and compile-via-C compilers have the disadvantage that C isn't a very convenient compilation target for many language features, especially to efficiently compile some common FP language features. The hope was that C-- would be a nice middle ground between compiling via C and compiling to native code, producing a target that was nicer than C as a target.

Imo, that hypothesis did have some legs, but people are now instead usually using LLVM in various ways to accomplish it. LLVM's intermediate representation isn't really properly cross-platform, but it can be sort of hacked to be used for that purpose.

Do you think LLVM IR covers this ground adequately, despite not being cross-platform?

I'm not really a language implementor, more of a spectator of language implementations, so someone with more experience would give a better answer.

My impression is that the GHC people, at least, still think that C-- is a nicer IR than LLVM-IR for their purposes. But they are slowly moving more things to LLVM anyway, because the LLVM project as a project has, in the meantime, built up a lot more momentum and infrastructure. In the early 2000s this wasn't obvious, but in 2013 it's clear that LLVM has an ecosystem, institutional support, resources to maintain ports, etc., while C-- didn't manage to get the same traction.

From my personal experience, LLVM is tied a bit to closely to the C ABI, which makes it difficult to implement some FP features cleanly. One example is forgoing C's stack discipline to implement double-barreled continuations.

OCaml also internally uses an intermediate code representation called C-- (or Cmm). I do not know if the two have any relationship.

It looks like OCaml's C-- predates this C--, but has had an influence on it.

From Xavier Leroy, one of the lead Ocaml developers [1]:

    I think I'm the one who coined the name "C--" to refer to a low-level,
    weakly-typed intermediate code with operations corresponding roughly
    to machine instructions, and minimal support for exact garbage
    collection and exceptions.  See my POPL 1992 paper describing the
    experimental Gallium compiler.  Such an intermediate code is still in
    use in the ocamlopt compiler.

    I had many interesting discussions with Simon PJ and Norman Ramsey
    when they started to design their intermediate language.  Simon liked
    the name "C--" and kindly asked permission to re-use the name.

    However, C-- is more general than the intermediate code used by
    ocamlopt, since it is designed to accommodate the needs of many source
    languages, and present a clean, abstract interface to the GC and
    run-time system.  The ocamlopt intermediate code is somewhat
    specialized for the needs of Caml and for the particular GC we use.

[1] http://article.gmane.org/gmane.comp.lang.caml.inria/9436/

Reply on news.ycombinator.com