> >> Thanks for woking on this. Any specific reason why using the LLVM > >> bytecode wasn't taken into account? > > > > It was. > > A large number of alternatives were explored, including CIL, the JVM, > > LLVM, etc. > > > >> It is proven to be stable, high-level enough to > >> perform any kind of needed optimization, > > > > This is not true, unfortunately. > > That's why it is called "low level virtual machine". > > It doesn't have things we'd like to do high level optimizations on, > > like dynamic_cast removal, etc. > > > Anyway, *slightly* extending an existing VM which already exists, is > production-ready, is GPL compatible, is supported by a full toolchain > (including interpreters, disassemblers, jitters, loaders, optimizers...) looks > like a much better deal. Also, I'm sure Chris would be willing to provide us > with all the needed help. > > I also think CIL would have egregiously worked. I'm sure the reasons to refuse > it are more political than tecnical, so it's useless to go into further > details > I presume.
I do not think that CIL really would have worked. CIL has been carefully crafted to support what Microsoft wants it to support and unrestricted C, C++, and Fortran are not in that mix. Remember that Microsoft wants to be able to take a CIL program produced on one (?Microsoft?) platform and run it on another (?Microsoft?) platform. By the time we get to where we want to produce the iterchangable code, the il has a lot of platform knowledge (for instance generated by the C preprocessor) that cannot be easily accounted for. > > Giovanni Bajo
