[bitc-dev] Choice of runtime/VM
Jonathan S. Shapiro
shap at eros-os.org
Fri Jul 30 17:43:33 PDT 2010
On Fri, Jul 30, 2010 at 5:33 PM, Ben Kloosterman <bklooste at gmail.com> wrote:
> Ø Separately, if the constraints of safe CLI cause mangling in the original compile (e.g. for unboxed unions), there is very little that the later translator can do to recover them.
>
> I don’t think its that limiting , There are a number of languages that target CIL and the worst case they add some metadata that the JIT or CIL to LLVM converter can read ( while not “correct” it won’t be that ugly ) .
Plausible. The main concerns I have are concurrency-driven constraints
and unboxed unions. Can you suggest how one would annotate the unboxed
unions?
But note also that once you rely on annotations, you can't just pick
up an existing CLR->native translator without potentially significant
changes.
> BTW here is a article how one firm used the CLR/mono for hard real time sensor control and how they addressed some Concurrency issues in CIL http://www.codeproject.com/KB/cs/SomeUsefulConcurrency.aspx note the sync table is not part of the CLR.
Thanks. That's a useful pointer.
Ben: I'm not opposed to targeting CLR. In fact, I've been paying some
attention to that. I *am* pretty well opposed to using CLR as an
intermediate form for native code.
As to "associated with Microsoft", I survived that; BitC would too.
shap
More information about the bitc-dev
mailing list