Yes. The problem is in staying within the safe subset. As far as I know, CLR does not provide a means to check a compiler-provided proof, so "amenable to local verification" must be taken a bit loosely.
On Sat, Nov 15, 2008 at 12:53 PM, Rodrigo Kumpera <[EMAIL PROTECTED]> wrote: > 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 > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
