The CLR admits overlapping valuetypes at arbitrary offsets. For (pointers to) reference types it's invalid to have partial overlapping and even so, it's not part of the defined safe subset.
The main issue with unions on the CLR is how to encode safety guarantees that are amendable to local verification. On Sat, Nov 15, 2008 at 1:34 PM, Jonathan S. Shapiro <[EMAIL PROTECTED]>wrote: > Is it possible for BitC on CLI to satisfy the representation requirements > for unions? I don't believe so, and this strikes me as an area where CLI > can/should be improved. > > > On Sat, Nov 15, 2008 at 12:31 AM, Eric Northup <[EMAIL PROTECTED]>wrote: > >> 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 >> >> > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
