Didn't mean to send 2 replies..
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. This is the top response for unsafe CLI www.coyotos.org/pipermail/bitc-dev/2010-March/001919.html www.coyotos.org/pipermail/bitc-dev/2010-March/001919.html 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. 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 ? Another issue we discussed before is union representation. 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. 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. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
