I want to divert for a moment to talk about CLI again. By "CLI", I mean the safe CLI subset. This is not just a political issue; much of our purpose in targeting CLI is to gain the advantage of existing GC infrastructure, and we only get that if we target the safe subset. There are two notional features in BitC at the moment that have no translation to CLI within the safe subset. The first is inner references, and the second is region-based references (which are a specialized form of inner reference). If C is a CLI reference type (a class) having a field f of type F, and c is a reference to an instance of C, then c.f has type F. That is: there is no way to capture a reference into the interior of an instance of C within the safe CLI subset. The consequences of this are unfortunate. While CLI does provide a mechanism for by-reference parameters, these references are "internal" references that cannot be captured. In essence, they carry a restriction analogous to the current BitC by-ref parameter type. Unfortunately, this touches on region-constrained references as well. In particular, it means that we cannot stack-allocate certain values even when we know (and can prove) that the relevant lifetime constraints are satisfied. This raises two issues: * The BitC specification has to be weasily about when stack allocation is required, in order to leave leeway for a .NET or JVM-based implementation to be a conforming implementation. In effect, we're driven to introduce a two-layer conformance scheme, in which we distinguish between a semantically conforming implementation and an implementation that conforms to a particular set of unboxing and layout contracts. * Our ability to make effective use of liveness-constrained references (that is: regions) is going to be limited. For liveness-constrained references into the stack, the solution in .NET is probably going to be to heap-allocate those values in order to eliminate the liveness constraint. That appears to be the best we can do. Unfortunately, I don't see any way at the moment to implement capturable, liveness-constrained references to a struct or class field. Does anybody know of any work that has been done on this sort of thing in a .NET context? It's very possible (indeed, damned likely) that someone out there is more clever than I am. May be worth looking at the C++ implantation it's the only language ( and C#) that allows some unsafe stuff. But I do know its very limited. For completeness, our other alternative is to target the unsafe CLI subset. At that point we can do almost anything we want, but we are completely on our own for implementation of GC and the like. I'm not even sure that there are contracts in that corner of CLI regarding sequence points and JIT-generated temporary values. Even if those contracts exist in the specification, it's likely to be an under-explored part of the JIT subsystem, and one that nobody feels any urgency about addressing. Anybody see any light at the end of this tunnel? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
