3 ms·

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

VLM 13y ago
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.
- _delirium 13y ago
  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.
  - mattgreenrocks 13y ago
    Do you think LLVM IR covers this ground adequately, despite not being cross-platform?
    - _delirium 13y ago
      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.
    - thinkmoore 13y ago
      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.
elehack 13y ago
OCaml also internally uses an intermediate code representation called C-- (or Cmm). I do not know if the two have any relationship.
- deleted 13y ago
  [deleted]
- _delirium 13y ago
  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/ http://article.gmane.org/gmane.comp.lang.caml.inria/9436/

VLM 13y ago

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.

_delirium 13y ago
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.
- mattgreenrocks 13y ago
  Do you think LLVM IR covers this ground adequately, despite not being cross-platform?
  - _delirium 13y ago
    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.
  - thinkmoore 13y ago
    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.

elehack 13y ago

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

deleted 13y ago
[deleted]
_delirium 13y ago
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/ http://article.gmane.org/gmane.comp.lang.caml.inria/9436/