[m-dev.] Status of C--

[Ralph Becket]

This may be of interest...

----- Forwarded message from cminusminus-request at cminusminus.org -----

Message: 3
Date: Fri, 15 Dec 2006 22:28:56 -0500
From: Norman Ramsey <nr at eecs.harvard.edu>
Subject: [C--] C-- status report: yes, someone is (barely) out here
To: "Isaac Freeman" <memotype at gmail.com>
Cc: cminusminus at cminusminus.org
Message-ID: <20061216032900.A9995788215 at labrador.eecs.harvard.edu>

 > Hello, I stumbled across C-- a month or so ago and have been casually
 > investigating it until I just found this mailing list. Now that I am
 > here, I have to ask about the status of C--...

We've been silent for a long time, and I think I owe the community
a lengthy status report.

For well over a year, the C-- project has been progressing very
slowly, as I tried to navigate the tenure process at Harvard.  As it
turns out, I failed to navigate this process successfully, and when I
was denied tenure, I put the project more or less on hold.  Unless
someone else picks it up, C-- will stay on hold until I start a new
job, which I hope will happen about a year from now.

For the longer term, I met with Simon Peyton Jones last week, and
while we both continue to believe deeply in the value of the project,
we also recognize several obstacles.   First, there is significant
work to be completed:

  1. We have yet to complete the support required for handling stack
     overflow and underflow, which is necessary to support concurrent
     languages.  One PhD student made a great deal of progress on
     these problems, but he then took an indefinite leave of absence
     from school.  Still, with modest effort, this work could be
     completed relatively soon.

  2. We believe that for the long-term viability of C--, it must be
     possible to translate C-- to C, probably using the same
     techniques currently used by the Glasgow Haskell Compiler.  These
     techniques entail either a substantial loss of performance or a
     substantial investment in implementation.  We had an
     undergraduate student do an initial investigation, and the
     results look promising, but a very substantial amount of work
     remains to be done.

  3. It is clear that the 'path to entry' into C-- would be greatly
     eased if someone were to build a small but useful run-time system
     containing a simple garbage collector, exception dispatch, and
     threads package.  Each of these components has already been
     written at various time by various graduate students, but they
     lack the packaging and documentation needed to make them reusable
     by others.

  4. Several of the infamous 'proposed extensions' of December 2004
     really need to be implemented.  This probably isn't more than a
     week's worth of work for a couple of people who understand the
     compiler, but all the people who understand the compiler are
     desperately trying to be sure that my students get their degrees
     before my contract runs out.

Given a little time and manpower, the obstacles above could be
overcome.  But there are also more serious questions: Next month it
will be nine years since Simon and I started working together on C--.
We asked ourselves 'Is it still a good idea?' and 'Is there still an
audience for the work?'  The answers to these questions are less clear.

Our original goal was to provide reusable infrastructure so that
people could quickly and easily build implementations of new
programming languages and get native-code performance.  We hoped to
make it possible for a small team, perhaps even one person, to get a
state-of-the-practice language implementation going in a short
time---from a few months to a year, depending on the complexity of the
front end.  We still believe strongly in this goal, we still believe
that there is no other infrastructure that meets this goal, and we
still believe that it's a good idea.  But since 1998, both our
understanding of the problem and the technological landscape have
changed significantly.

  5. In 1998, we thought that the compiler, back end, or code
     generator would be the major problem.  And indeed, we have solved
     a number of hard problems in this area, and I think I can speak
     for everyone involved when I say that we are proud of the work.
     But we wildly underestimated the difficulty of building a
     run-time system.

     As evidence, we have heard repeatedly from users that we've done
     a good job with the compiler parts---several people have adapted
     existing compilers to emit C--, and they have found it easy to
     get good results.  But nobody who already had a working system
     has been able to port their front-end run-time system to use the
     C-- run-time interface.

     The causes of the difficulty are not well understood.  I am
     thinking quite seriously of devoting the next phase of my career
     to understanding problems of modularity and reuse in run-time
     systems, and to building a 'run-time system kit' to work hand in
     glove with C--.  But obviously such plans are contingent on my
     finding a job that will support such activities.

  6. We believe that the potential audience for the work has shrunk
     significantly since 1998.  

        * Many language designers or compiler writers seem to be happy
          targeting the Microsoft Common Language Runtime or the Java
          Virtual Machine.

        * More people are willing to use Gcc than were willing to do
          so in 1998; with the efforts of the Gcc Developers' Summits
          and the transition to Gcc 4, the internals appear to have
          been improved significantly and made easier to work with.

        * New projects such as LLVM have appeared.  LLVM focuses on
          dynamic optimization, not on reuse with multiple languages,
          but a great deal of effort is being expended on it, and it
          is a very interesting piece of compiler infrastructure.

  7. To be a really attractive alternative to these other projects,
     C-- not only has to deliver on all of the original promises about
     reuse; it also has to deliver more prosaic things like a
     comprehensive set of optimizations and a better story about
     dynamic compilation.  The NSF actually has funding available for
     this sort of thing, but with my tenure case undecided, I felt
     that it would be unfair to bring in new students or new employees
     who would probably be cast adrift if should I be denied tenure.

 > I would really like to use C-- as a back-end for one of my
 > projects, but I don't want to get left abandoned in a ghost town
 > when it dies. Is it already dead? Is anyone actually working on it?
 > What's the deal? How can I help?

One of our grad students is using C-- as a central part of his PhD
thesis, and we will certainly be keeping it alive long enough for him
to graduate :-)

After that, a lot depends on my future job.  On the one hand, it's
possible that I'll be offered an industrial job in which C-- would
play a significant role in the firm's plans.  If that happens, C--
could start to move forward very rapidly.  On the other hand, I'm
interviewing Monday for a teaching position which would leave me very
little time for C--.  If I wind up in that job, I'll do my best to
hand the project off to someone who can do it justice.  On the
gripping hand, I may get a job at a major research university, much
like the one I have now.  In that case, I would hope to continue work
on C--, but it will take several years to attract students, build up a
research group, and so on.  It is very difficult to build a serious
software artifact in an academic setting.

I think the best hope for the future of C-- is for our current group
to form a partnership with someone who has interests and expertise in
run-time systems.  But if someone credible were to come forward---
either from the academic community or from the open-source
community---I would consider handing the project over.  The
constraints on an academic research group are such that a major
compiler is very, very hard to pull off.

If we do close down the project, we will do our best to leave it in a
healthy and usable state---as it is now, by the way.  I am still
maintaining open-source software I first released in 1989, and I don't
imagine that keeping C-- on life support would represent a major burden.

 > Also, on a lighter note, the Tigerc tarball seems to come with .ml and
 > .mli files which appear to be generated by ocamlyacc/ocamllex, but I
 > see no .mly or .mll files anywhere... Where would I attain these as
 > well?

All this stuff should be available through our rsync server, which
would also give you access to the internal documentation of the Tiger
compiler.  (I hope the rsync server is still working, because the
sysadmin who set it up quit the day before yesterday, and I'm not sure
I know how to do it.)



Norman

_______________________________________________
Cminusminus mailing list
Cminusminus at cminusminus.org
https://cminusminus.org/mailman/listinfo/cminusminus


End of Cminusminus Digest, Vol 5, Issue 1
*****************************************

----- End forwarded message -----
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------