Rodrigo Kumpera wrote: > The naive approach to support generics by a CLR VM is to expand every > instantiation and produce > native code for all variations. This is far from optimal as the > generated bloat usually interacts pretty bad > with the icache. > > What the VMs support [1] is sharing code for all reference types, > which expands to pretty much the same thing. > For valuetypes this sharing is non-trivial so no VM does it. The very first CLR VM to support generics actually did share code for compatible (from the perspective of the GC's reference visitor) structure types - see section 4.1 of http://research.microsoft.com/projects/clrgen/generics.pdf .
[...] > BTW, I think BitC would map very well on top of the CLR given it had > interface injection support. I agree that a CLI target would be interesting for BitC. No particular support for interface injection is necessary - I can imagine several direct embeddings of type classes into CLI interfaces. Polyinstantation or method dictionaries could also be done while targeting the CLI, thus treating it as a lower-level IL. The lower-level IL might potentially be compatible with the CIL subset supported by the gcc cli front-end. I didn't quite understand what Shap said about sometimes needing to dynamically fabricate a dictionary, though. Is that a consequence of separate compilation? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
