CIL Virtualization Layer


#1

One thing I have been thinking about since .net because opensource is the architecture. One issue that might pop up in the future us the difficulty to evolve the VM due to legacy CIL. So it might be an idea to Virtualize the CIL layer so that the VM implementation is independent of the CIL format.

This way:

  • Experimental CIL instructions can be added
  • New CIL formats can bee defined by the users. E.g. Parrot VM format
  • May be support JVM ByteCode also to run along CIL in the same VM (without something like IKVM)
  • etc.

Also the exposed API can be the basis of creating a AST interpreter as in one of my other proposals: AST Interpreter / Easily Create New Languages

Let me know what others think.


Defined VM Interface
#2

If the VM was independent of CIL, what would it depend on? Aren’t you just proposing to create a new intermediate language, along with a translation layer from the old CIL to the new language? I don’t see how that would solve anything.

If you’re creating something new, it makes sense to think about how to design it to make it flexible in the future (but making it more flexible is not always the right choice).

But if you already have something as big as the CLR, significantly changing the design should only be done if it actually provides significant benefits, not just when it might provide some benefit in the future.


#3

How about scenarios like supporting supporting both CIL, Java ByteCode and LLVM IR (bitcode) on the same VM? This will open up a lot of more possibilities.


#4

A low level VM interface would perhaps be more beneficial than 2 levels of IR. The CIL layer or any other IR layer communicates with this VM interface.


.NET Foundation Website | Blog | Projects | Code of Conduct