OK. In the last month or two we've made some pretty interesting progress here, and so I want to come back to the LLVM vs. CLI discussion. Partly as a result of our progress in the last two months, I think the issues have changed.
Reviewing the last two months: 1. For a variety of reasons, I think we have committed ourselves to the notion that types are inherently boxed or unboxed. While this does not dictate CLI, it does align us better with CLI. 2. We seem to be committing ourselves to non-inheritance and interfaces. Interfaces are merely classes with constrained member types. This maps directly onto CLI types without difficulty. 3. We also seem to be committing ourselves more and more strongly to region types. This is something that cannot be expressed in the CLI type system at all. While we can express the *semantics* of any BitC program in CLI, we cannot honor the layout constraints in the absence of a region type system in the underlying machine. Our compromises will have to be conservative, because modular compilation will lead us to conservative region assumptions. 4. LLVM has made definite progress toward GC support, though it still does not address the question of whether registers contain object references. 5. We have arrived at a pragmatic compromise for ambient instance resolution that I consider acceptable. An (undiscussed) consequence of this outcome is that we can now establish a reasonable resolution for overlapping instances. In the short term, it appears to me that targeting CLI has the following advantages and disadvantages: Pro: - It is a mature runtime with full support for collection. - It has an implementation everywhere we care about in the near term, though some are better than others. - It offers us significant debugging support for the runtime, at least in terms of the translated types. The debugger won't reverse the translation automatically, but that's easy enough to patch in. - It offers a wide range of existing code to interoperate with. Con: - CLI does not offer any support for region typing, which is an increasingly critical part of the BitC language design. An implementation targeting CLI may be semantically correct, but it will consequently be very GC-dependent and region-conservative. - I do not see how to support the checking we require at assembly link time given the facilities available within CLI. Meanwhile, targeting LLVM has the following advantages and disadvantages: Pro: - True native-code compilation, though run-time linking may require run-time code generation. - Reasonably well-regarded compiler and optimizer. Support for GC semantic constraints is not ideal, but perhaps no worse than other compilers. - Baseline IR not adequate for first-class GC support, but could be extended in a relatively straightforward fashion. - API is friendly to native call encapsulation using BitC interfaces. - The set of supported targets is much richer than those for CLI Con: - GC support is weak, restricting us to a "mostly copying" implementation because LLVM provides no register maps. - Support for GC'd languages is relatively under-tested. - The restriction that stack-based GC roots must be stored in alloca'd regions has the effect of disabling a long list of optimizations. - Essentially no debugging support in the near term. - Support for GC is clearly second class and likely to remain so. Before I go on to offer an opinion, can anybody identify pros/cons that I have failed to list? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
