The paper makes a comparison between the Java Virtual Machine (JVM) of Java and the Common Language Infrastructure (CLI) of Microsoft .NET, arguing that although almost of the developers moved to the JVM as their vehicle for their languages it wont be the best option for all of them as it is for Java. The paper starts listing some of the attempts to develop virtual machines, intermediate languages and language independent execution platforms. It is awesome to know about this because I did not know anything about them and I suppose there may be a good reason, well the paper mentions that the reasons to watch for another options are the portability, the compactness, the efficiency, the security, the interoperability and the flexibility.
The CLI has been designed to overpass the problems that the JVM may have (for example the capability of unboxing structures and unions, etc.…), this with the help of different implementers of different languages. The paper also describes some of the parts of the architecture of the CLI in order to understand a little bit more of how it works inside, the remarked part is that in contrast to the JVM, where all storage locations are not “polymorphic”, as they are within CLI, which means that their size can me user-defined, but they are fixed for lifetime of the frame
Later, the paper describes a little bit more some of the CLI’s features, the type system section describes some of the primitive types that are supported and letting us know that they can be combined into composite types. The base instruction set section, describe some of the most representative instruction of each group, and exposes that unlike JVM, the CLI do not hard-code within the instructions the type of their arguments. Finally, the last parts are about the reference and value types, how they interact and about invoking methods. These sections describes some interesting facts about how they work, for example the ways to indirect call a function pointer.