Philipp indirectly raised a valid question: given the goals of BitC, does it make sense to be trying to do bring-up on CLI. I have reservations, but I think the answer is yes.
First, note that there are paths from CLI to native code for a number of platforms. The Mono 2.6 infrastructure includes the ability to use LLVM as a code generator. When coupled with their AOT technology, I would not be surprised if we can get nearly complete target code generation right now. Certainly it shouldn't be a big technical leap to get there given the work that they have already done. Finally, mono seems to be moving to a relocating collector. Concerning LLVM, it is very hard to know whether LLVM is the right infrastructure for BitC. The two main concerns are: - The LLVM infrastructure is itself unsafe. This violates the "eat your own dog food" rule, and it raises a bunch of concerns in my mind. - LLVM's support for GC is pretty minimal. As I said a few minutes ago, I need to go look at the state of that. Subjectively, it doesn't seem that managed languages are a priority for LLVM. Concerning CLI, you can say a lot of things about it, but it is an environment that has strong tools and strong debugging support, and one that supports a fully incremental edit-compile-debug loop. It also has a huge user base. If we *do* end up needing to write our own back-end, these seem like really good things to have. Finally, CLI is worth *considering* whether we target it or not. Say what you like about CLI, it is a popular target worthy of thought. It has forced me to re-think some things in BitC already, and revealed some mistakes in the process. So to answer the question: I'm not sure what the "right" target is, but I'm sure that targeting CLI is provoking useful thought, and that it will be a useful target to have both from the perspective of language adoption and from the perspective of having a bootstrap environment. Conversely, I don't see any easy path to native code that doesn't commit us to a mid-end and back-end construction later. If I'm going to have to do that, I'ld really prefer to do it within BitC itself, which argues for doing whatever gets us a quick bring-up most easily. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
