[bitc-dev] Choice of runtime/VM

Ben Kloosterman bklooste at gmail.com
Fri Jul 30 17:33:24 PDT 2010

If you use LLVM as a compiler are you not also obligated to follow LLVM IR ,
this also has issues ,  most people solve with MetaData .  This has been
quite limiting in Mono esp around the area of interfaces and vtable support
. LLVM IR before was worse but they have made significant improvements  , in
2.7 they added Metadata so specific compilation option can be used. 



Ø  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 ) . 


Though both impose some limits which you won’t get if you bypass a VM IR eg
by going to C but its pretty ugly. 




Ø  As a bring-up strategy I have no problem with this, and I actually think
it's a fine idea. We just need to be careful not to oversell what it
actually does for us.


I don’t think im overselling you do have native x86 code  though  it
misleads since people to thing native = fast  . There are some CIL to LLVM
converters (incl mono)already around . It’s certainly not a perfect solution
but (IMHO)  a strong option 


You get 

-          Option for native code via LLVM  ahead of time

-          use CLR / runtime and possibly an interpreter command line like

-          You can use MS existing tools out of the box , including Visual
Studio  ( though it would need work for say language auto completion) 

-          Other apps can link into BitC  ( not so easy without the CLR) and
you can link into existing modules – this opens up Microsoft shops using
BitC  say for optimizing some key functions / libs . I know many merchant
banks that are C# shops  that would consider dropping their C++ messaging/
pub sub and quant systems for BitC if this was the case .  

-          You have the option of the .NET runtime  and libs ( or parts of
it ) and any assembly.  ( Quite important since using Clibs , Java etc is
not trivial for a GC language ) 

-          A more mature environment  ( note not just compiler) 


At a cost of  

-          stuffing around with CIL to IR  Metadata as an optimization. 

-          Early performance may not be as good which may hurt perceptions
if it gets out/ is not qualified..

-          Associated with Microsoft.. 

-          Generics and Vtable when compiling  to x86 exe , Mono is still
working on this. 


However it’s easy enough to do the reverse  eg focus on LLVM IR and then
convert to CIL but the real question here is how do you link to other apps
and how they link to you  ( which is a pain for GC objects)   and related,
what your run time will be .  There is a strong demand for a fast type safe
/ memory safe language for hotspots but to get access to a lot of this niche
integration with existing apps is a must. 


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.





An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100731/dcd5b574/attachment.html 

More information about the bitc-dev mailing list