• Source: Common Intermediate Language

Common Intermediate Language (CIL), formerly called Microsoft Intermediate Language (MSIL) or Intermediate Language (IL), is the intermediate language binary instruction set defined within the Common Language Infrastructure (CLI) specification. CIL instructions are executed by a CIL-compatible runtime environment such as the Common Language Runtime. Languages which target the CLI compile to CIL. CIL is object-oriented, stack-based bytecode. Runtimes typically just-in-time compile CIL instructions into native code.
CIL was originally known as Microsoft Intermediate Language (MSIL) during the beta releases of the .NET languages. Due to standardization of C# and the CLI, the bytecode is now officially known as CIL. Windows Defender virus definitions continue to refer to binaries compiled with it as MSIL.




General information


During compilation of CLI programming languages, the source code is translated into CIL code rather than into platform- or processor-specific object code. CIL is a CPU- and platform-independent instruction set that can be executed in any environment supporting the Common Language Infrastructure, such as the .NET runtime on Windows, or the cross-platform Mono runtime. In theory, this eliminates the need to distribute different executable files for different platforms and CPU types. CIL code is verified for safety during runtime, providing better security and reliability than natively compiled executable files.
The execution process looks like this:

Source code is converted to CIL bytecode and a CLI assembly is created.
Upon execution of a CIL assembly, its code is passed through the runtime's JIT compiler to generate native code. Ahead-of-time compilation may also be used, which eliminates this step, but at the cost of executable-file portability.
The computer's processor executes the native code.




Instructions



CIL bytecode has instructions for the following groups of tasks:

Load and store
Arithmetic
Type conversion
Object creation and manipulation
Operand stack management (push / pop)
Control transfer (branching)
Method invocation and return
Throwing exceptions
Monitor-based concurrency
Data and function pointers manipulation needed for C++/CLI and unsafe C# code




Computational model


The Common Intermediate Language is object-oriented and stack-based, which means that instruction parameters and results are kept on a single stack instead of in several registers or other memory locations, as in most programming languages.
Code that adds two numbers in x86 assembly language, where eax and edx specify two different general-purpose registers:

Code in an intermediate language (IL), where 0 is eax and 1 is edx:

In the latter example, the values of the two registers, eax and edx, are first pushed on the stack. When the add-instruction is called the operands are "popped", or retrieved, and the result is "pushed", or stored, on the stack. The resulting value is then popped from the stack and stored in eax.




= Object-oriented concepts

=
CIL is designed to be object-oriented. One may create objects, call methods, and use other types of members, such as fields.
Every method needs (with some exceptions) to reside in a class. So does this static method:

The method Add does not require any instance of Foo to be declared because it is declared as static, and it may then be used like this in C#:

In CIL it would look like this:



Instance classes

An instance class contains at least one constructor and some instance members. The following class has a set of methods representing actions of a Car-object.



Creating objects

In C# class instances are created like this:

And those statements are roughly the same as these instructions in CIL:



Invoking instance methods

Instance methods are invoked in C# as the one that follows:

As invoked in CIL:




= Metadata

=

The Common Language Infrastructure (CLI) records information about compiled classes as metadata. Like the type library in the Component Object Model, this enables applications to support and discover the interfaces, classes, types, methods, and fields in the assembly. The process of reading such metadata is called "reflection".
Metadata can be data in the form of "attributes". Attributes can be customized by extending the Attribute class. This is a powerful feature. It allows the creator of the class the ability to adorn it with extra information that consumers of the class can use in various meaningful ways, depending on the application domain.




Example


Below is a basic "Hello, World!" program written in CIL assembler. It will display the string "Hello, world!".

The following code is more complex in number of opcodes.
This code can also be compared with the corresponding code in the article about Java bytecode.

In CIL assembler syntax it looks like this:

This is just a representation of how CIL looks near the virtual machine (VM) level. When compiled the methods are stored in tables and the instructions are stored as bytes inside the assembly, which is a Portable Executable (PE).




Generation


A CIL assembly and instructions are generated by either a compiler or a utility called the IL Assembler (ILAsm) that is shipped with the execution environment.
Assembled CIL can also be disassembled into code again using the IL Disassembler (ILDASM). There are other tools such as .NET Reflector that can decompile CIL into a high-level language (e. g. C# or Visual Basic). This makes CIL a very easy target for reverse engineering. This trait is shared with Java bytecode. However, there are tools that can obfuscate the code, and do it so that the code cannot be easily readable but still be runnable.




Execution






= Just-in-time compilation

=
Just-in-time compilation (JIT) involves turning the byte-code into code immediately executable by the CPU. The conversion is performed gradually during the program's execution. JIT compilation provides environment-specific optimization, runtime type safety, and assembly verification. To accomplish this, the JIT compiler examines the assembly metadata for any illegal accesses and handles violations appropriately.




= Ahead-of-time compilation

=
CLI-compatible execution environments also come with the option to do an Ahead-of-time compilation (AOT) of an assembly to make it execute faster by removing the JIT process at runtime.
In the .NET Framework there is a special tool called the Native Image Generator (NGEN) that performs the AOT. A different approach for AOT is CoreRT that allows the compilation of .Net Core code to a single executable with no dependency on a runtime. In Mono there is also an option to do an AOT.




Pointer instructions - C++/CLI


A notable difference from Java's bytecode is that CIL comes with ldind, stind, ldloca, and many call instructions which are enough for data/function pointers manipulation needed to compile C/C++ code into CIL.

The corresponding code in CIL can be rendered as this:




See also


LLVM
List of CIL instructions
List of CLI languages




References






Further reading


Bock, Jason (2002). CIL Programming: Under the Hood of .NET. Apress. ISBN 978-1590590416.




External links


Common Language Infrastructure (Standard ECMA-335)
“ECMA C# and Common Language Infrastructure Standards” on the Visual Studio website
Hello world program in CIL
Speed: NGen Revs Up Your Performance With Powerful New Features -- MSDN Magazine, April 2005

Kata Kunci Pencarian:

• Microsoft Intermediate Language
• Common Language Runtime
• Infrastruktur Bahasa Umum
• Daftar bahasa pemrograman
• Singularity
• Kode operasi
• C++
• Arya
• Rumpun bahasa Hindi Barat
• Sosialisme
• Common Intermediate Language
• Intermediate representation
• Common Language Runtime
• Common Language Infrastructure
• List of CLI languages
• LLVM
• List of programming languages
• List of CIL instructions
• Ahead-of-time compilation
• Common European Framework of Reference for Languages