Technical Overview of the Common Language Runtime

Technical Overview of the Common Language Runtime

In past years many researchers moved to JVM (1) as their vehicle for their languages, the JVM is just a great platform for Java but that is not the case with other languages. As an alternative Microsoft .NET Common Language Infraestructure (CLI) was designed from the ground up to be a multi-language platform.

The main reasons why people are looking at alternative implementation paths for native compilers are(1):

• Portability: By using an intermediate language, you need only n+m translators instead of n∗m translators, to implement n languages on m platforms.
• Compactness: Intermediate code is often much more compact than the original source.
• Efficiency: By delaying the commitment to a specific native platform as much as possible, you can make optimal use of the knowledge of the u nderlying machine, or even adapt to the dynamic behavior of the program.
• Security: High-level intermediate code is more amenable to deployment and runtime enforcement of security and typing constraints than low level binaries.
• Interoperability: By sharing a common type system and high-level execution environment (that provides services such as a common garbage collected heap, threading, security, etc), interoperability between different languages becomes easier than binary interoperability.
• Flexibility: Combining high level intermediate code with metadata enables the construction of (typesafe) metaprogramming concepts such as reflection, dynamic code generation, serialization, type browsing etc.

But, why JVM was so attractive?

People was mainly attracted because of the high-level run time support the wide availability of the JVM and the rich set of libraries of the Java platform.

Not everything is perfect, JVM has a lot of disadvantages:

• Values of type long or double occupy two locations, which makes things unnecessarily hard for compiler writers.
• Its type system lumps together all pointers into one reference type, closing the door for languages or compilers that need a more fine-grained level of detail.
• It does not support tailcalls.

In comparision the CLI has been designed from the ground up as a target for multiple languages,
Microsoft has worked closely with a large number of language implementers.

A couple of advantages that CLI has:

• CLI has good support for imperative (COBOL, C, Pascal, Fortran) and statically typed OO languages (such as C#, Eiffel, Oberon, Component Pascal). 
• Microsoft keeps working on improving support for languages in non-standard paradigms.
• The CLI manages multiple concurrent threads of control (which are not necessarily native OS   threads). 
• Storage locations are polymorphic, in the sense that they might be 4 bytes (such as a 32 bit integer) or hundreds of bytes (such as a user-defined value type), but their type is fixed for lifetime of the frame.

CLI is currently more powerful and accessible than the JVM. Also CLI has the continuous support and improvement supplied by the Microsoft Research team and the .NET.  JVM has lost ground, meanwhile CLI has become the "alternative" by excellence.

Reference:
1.-http://34.212.143.74/s201913/tc3048/clr.pdf