On Wed, Mar 23, 2011 at 11:52 PM, Ben Kloosterman <[email protected]>wrote:
> Basically safe = Java like language eg user app not system or high perf lib > . Unsafe is where BitC should go since the Language itself will provide > the safety. > Since the only reason to target CLI at all is to get a quick solution for GC, I tend to disagree. Once we have to do our own GC, I think I'ld prefer to go with LLVM. > C# has stackalloc and fixed for pointers which do work with the GC , is > this not enough ? Is the cost of fixed on a stack/static object to prevent > compaction too high ? > Fixed is not permissable within the safe subset. Can you point me to a description of stackalloc? > Another issue we discussed before is union representation. > Yes. But Eric Northup came up with a workable solution. If you know the constraints than the C# fixed and stackalloc CIL equivalents > will work with the GC and there shouldn’t be a high cost. > OK. So now we're looking at a weird middle position where the CIL modules will need to be compiled with /unsafe, and we propose to rely on "fixed" to deal with some of the mess. The "fixed" construct in CLR is surprisingly delicate, and *very* easy to get wrong from the perspective of the programmer. It fails completely if the captured reference ever escapes. There are legal and safe programs within a region framework where this kind of escape happens. But I agree that we are getting much closer to a resolution, and that this puts us on the bring of a workable pragmatic solution. Food for thought. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
