On Thu, Oct 09, 2008 at 08:06:23PM -0400, Norman Ramsey wrote: > > C-- also does not seem to have an AMD64 code generator, nor one for the > > ARM (an increasingly important atchitecture).. > > I believe John Dias has an ARM back end, but I could be wrong. > AMD64 is on our short list.
I do development on an x86 and an AMD64. My ARM machine (which appears to be armel) is not yet set up for development (it's a Nokia N800 hand-held). > > C-- has a modest amount of funding through the end of this year. > I think the project has foundered on the expectations of users that we > will also provide a thread scheduler, garbage collector, run-time > system, dynamic code generator, and so on. We have simply never been > funded at a level that would enable us to produce those things. > > If we have a user we can definitely put together AMD64 and ARM code > generators. But we don't have funding to write a garbage collector > for you... I was planning to use the usual conservative garbage collector until something better showed up. I believe it's Debian package libgc. > > If a knowledgable person wanted to move the existing repository to, > say, github, I'd be perfectly happy with that. I don't know anything > about monotone. I've had personal bad experiences with darcs and have > heard of bad experiences with mercurial, so I don't think those are > options. I was drawn to monotone because of its developers' extreme paranoia about data loss. A while ago one of the developers said that no one had ever permanently lost data because of a monotone failure. The style of monotone use is to check in frequently, and certify the revisions that actually work. That way developers can check in half-baked code and discuss their problems with it on mailing lists or IRC and all know they are talking about the same code. Then when it's tested, someone can certify it, and it will be available to those users that want to see only working versions. You can have any number of different kinds of certificates. I kep my ALgol 68 compiler online at a public monotone hosting site -- it's the a68h project you can see at http://mtn-host.prjek.net/ Have a look if you'd like. It uses the revision browser mtn-view to display the revision tree and all my source code. Information about monotone is available from http://www.monotone.ca/ The monotone wiki also has information about basic revision-control technology, other revisioning systems, and more. I've found it quite informative. > > I also suspect some of my students may have private bug fixes that are > not committed to the repository---I don't know for sure. > > > I'm wondering if there is enough potential interest in C-- to be worth > > reviving it. > > Next year I will probably seek funding to use C-- in developing a new > graduate course on compiler optimization. I am also interested in > looking at funding for research on abstraction, modularity, and reuse > in run-time systems, which would build on the lessons we learned in > doing C--. I would be happy to work with new users as I think it is > in everyone's interest to have the software used. But at the moment > my hands are a bit full with a new job and two PhD students trying to > graduate. Things will look a lot better after Dec 1. I'm pretty busy until then, too. The most I'll be able to do then is test the waters with C-- and llvm (mostly with letters like this one). Maybe a download and compile of QC--. > > > This would definitely be done on a free-software development model, > > consisting of volunteers all over the world. If there are any volunteers, that is. > > I would be delighted for people to volunteer. But I have to warn you > that the only compiler is very definitely designed as a research > vehicle. It uses abstraction to a frightening degree, and most of my > current and former students have found it difficult to learn the > compiler. The main problem I have with abstraction is that things rapidly get incomprehensible if the functions embodying them don't have explicit types. The only large CAML program I've ever tried to understand was written in a style of never-code-anything-the-compiler-can-figure-out. With that style, the better the type-inference engine, the worse for the reader. > > C-- will never support as many targets as llvm or gcc. It will if anyone writes a C-- to llvm or to gcc translator. But I think that putting code in the data may make this impossible. > But I think we can knock off some basic ones like amd64, and as I said > I thought we already had an ARM target. I've seen several messages ove the past year or two saying AND64 or ARM are in the works and should be ready soon. > At the moment, however, I > can't even get my copy of the compiler to build, so I can't test to > see if we really have an ARM target. Are the downloads from http://www.cminusminus.org/ in working order? -- hendrik > > > Norman _______________________________________________ Cminusminus mailing list [email protected] https://cminusminus.org/mailman/listinfo/cminusminus
