> Of these options, I think C-- (assuming it's not a dead project) is the > best of the lot. Even if it needs some work (an x86-64 back end, the > ability to move a stack frame from one stack to another),
I'm sure that an x86-64 back end will emerge from João Dias's thesis. I can say this with some confidence because I am chairing his thesis committee :-) It is unfortunate that the Linux support (especially distributions) for x86-64 is not very good, because it means this is a back end we will not be likely to use every day. > One of the big strokes of luck that C-- lacks is a big, well known > project that uses it. To give an example not quite at random, if a > functional language luminary like Simon Peyton Jones were to start > a project to design the successor to Haskell and Ocaml using C-- as > the back end, that'd be a huge boost to C--. Success of the > Haskell++ language using C-- would bring visibility, credibility, > and developers to C--. I'm sure Simon and I won't mind my saying that he and I have discussed this possibility, but at present he and Simon Marlow have their hands full with the Glasgow Haskell Compiler (not to mention the enormous run-time system that they are dragging around like a boat anchor). Having said that, we here at C-- Supplier A are keenly aware of the need for a high-profile client. We've had a number of interesting discussions with potential clients, but at present, legacy run-time systems are a real barrier. I've also had some serious conversations with potential brand-new clients, such as you suggest above, but all the people involved (including me) are extremely reluctant to discuss vaporware in public, let alone make an announcement :-) > I am less convinced that converting C-- to C is all that important. Our conversations with potential clients have convinced us that this is so. Essentially people want to be confident that even if all the back-end writers disappear (all two of us at present), they will continue to have a compilation path to the architecture of their choice through C. More than one potential client has told us that C-- will not be a viable option for them until such a path is in place. > As for the generic run-time library, I think this is fraught with dangers. Yes. That's what makes it a hard and interesting research problem, and ultimately solving hard problems, not building useful software, is what professors get credit for. While Microsoft was generous with seed money to get C-- started, the compiler in its current state has been funded almost entirely through research grants from the National Science Foundation of the USA. > I think the three new things I'd like to see out of C-- are (in rough > order of priority): > 1) x86-64 support > 2) the ability to move/copy a stack frame from one stack to another, and > 3) Some form of inline assembler without having to go to C (necessary for > writting threading primitives in C--) > > I am contemplating just adding those capabilities. x86-64 will be on the way. We've spent the last year talking about stacks and would be thrilled to have some help. If you're seriously interested, drop me a line and I'll point you to some of the records of the discussions and incomplete work. Regarding #3: it has always been a goal of C-- that if you have a particular machine instruction in mind, it should be possible to write C-- source code to get that instruction. (We have always had a problem, however, in that C-- does not have a good way to express *atomicity*---but I think we're willing to introduce a notion of primitive procedure to make that possible.) Meanwhile, regarding threads packages, Jean-Baptiste Tristan wrote a nice threading package about two years ago purely in C--. I'm not sure if he ever got it into shape to display in public, but if he is reading this discussion, perhaps he will respond and tell us so. Norman
_______________________________________________ Cminusminus mailing list [email protected] https://cminusminus.org/mailman/listinfo/cminusminus
