C-- Harvard EECS -> C-- Home -> C-- News
  C-- Home | Specification & Downloads | Old News | Papers | Mailing List | People | FAQ

C-- News for October, 2001

(There is old news from earlier this year still available.)

Basile Starynkevitch has asked us on the C-- mailing list where Quick C-- is heading. Good question. Here is Norman's answer:

I am quite impressed by the ongoing work on QuickC--. But I did not have the time to study it with big care.

I also have the impression that this mailing list is really silent...

We are too busy working on the compiler :-)
What are the first (real machine) targets of QC--?

It seems to me that the first target are Sparcs. Why not x86 under Linux? I understand that compiling to x86 might be a bit more difficult than compiling to Sparc (because Sparc is more RISC-y and, most importantly, more orthogonal ISA than x86) but I naively believe that x86 is a more common target (i.e. a much bigger market).

We want to knock off sparc, x86, and probably alpha and arm in fairly short order. We're starting with sparc primarily because the instruction set is simpler and therefore the not-ready-for-prime-time tools we're using to manage the instruction set have an easier time. We are also concerned about the that x86 register-allocation constraints may be hard to deal with.
Why is a Lua interpreter included in QC--?

I understand quite well the usefulness of a [Turing-complete] scripting language in an application, at least in the development phase. However, I have no idea why a scripting language would be useful in a mature C-- compiler!

It's not a mature compiler---it's an experimental compiler. We want to be able to reconfigure the compiler on the command line and to describe calling conventions in source code.
But I cannot see why Ocaml is not used as a scripting language (I know that bytecode [compiled with ocamlc] and machinecode [compiled with ocamlopt] Ocaml are not mixable, but I would believe that for testing and debugging purpose an Ocaml-bytecode C-- compiler would be enough, ie that Lua is not really useful, but we could have a custom Ocaml interpreter containing all QC-- code).
The technology we would need to make this work is beyond us. A Lua interpreter is quite simple and is sufficient for our needs.
How should I run QC-- on some example to see actual generated assembly code (in Sparc, or preferably x86 when it would happen).
For the moment,
  qc-- -c foo.c--
will do something moderately interesting. In the long run, something like
  qc-- -target=x86/linux -S foo.c--
is likely to be the eventual interface.
What are the medium term roadmap of QC--? What about targetting x86 and PIC (position independent code) for shared library?
  1. Emit proper assembly language
  2. Get it to run on parameterless procedures
  3. Support sensible calling conventions
  4. Support C calling conventions
  5. Get a real code generator
  6. Start work on the run-time system
  7. Get some front ends
We're trying to make multiple targets and PIC easy.

Contact: C-- Webmaster. URL: http://www.cminusminus.org/. Last edited: Mon 05 Feb 2007 14:02 EST.