Editing Common Intermediate Language

{{short description|Intermediate representation defined within the CLI specification}}
{{confused|C Intermediate Language}}
{{refimprove|date=November 2017}}

'''Common Intermediate Language''' ('''CIL'''), formerly called '''Microsoft Intermediate Language''' ('''MSIL''') or '''Intermediate Language''' ('''IL'''),<ref>{{cite web |url = https://docs.microsoft.com/en-us/dotnet/standard/managed-code |title = Intermediate Language & execution| date=19 April 2023 }}</ref> is the [[intermediate language]] binary instruction set defined within the [[Common Language Infrastructure]] (CLI) specification.<ref>{{cite web |url = https://ecma-international.org/publications-and-standards/standards/ecma-335/ <!-- |page = 32 --> |title = ECMA-335 Common Language Infrastructure (CLI)}}</ref> 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 machine|stack-based]] [[bytecode]]. Runtimes typically [[Just-in-time compilation|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 Sharp (programming language)|C#]] and the CLI, the bytecode is now officially known as CIL.<ref>{{cite web
| url = http://www.interviewcity.com/2010/04/what-is-intermediate-languageilmsilcil.html
| title = What is Intermediate Language(IL)/MSIL/CIL in .NET 
| access-date = 2011-02-17
| quote = CIL: ... When we compile [a]. NET project, it [is] not directly converted to binary code but to the intermediate language. When a project is run, every language of .NET programming is converted into binary code into CIL. Only some part of CIL that is required at run time is converted into binary code. DLL and EXE of .NET are also in CIL form.}}</ref> [[Windows Defender]] virus definitions continue to refer to binaries compiled with it as MSIL.<ref name="Defender">{{cite web |title=HackTool:MSIL/SkypeCracker |url=https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=HackTool:MSIL/SkypeCracker&threatId=-2147221892 |publisher=Microsoft |access-date=26 November 2019}}</ref>

==General information==
During compilation of [[List of CLI languages|CLI programming languages]], the [[source code]] is translated into CIL code rather than into platform- or processor-specific [[object file|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 [[Common Language Runtime|.NET runtime]] on [[Microsoft Windows|Windows]], or the [[cross-platform]] [[Mono (software)|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.<ref>{{cite book| url = https://books.google.com/books?id=VGT1_UJzjM0C&q=CIL+is+platform-independent&pg=PA15| title = Benefits of CIL| access-date = 2011-02-17| last1 = Troelsen| first1 = Andrew| date = 2009-05-02| publisher = Apress| isbn = 9781590598849}}</ref><ref>{{cite web|url=https://www.visualcplusdotnet.com/visualcplusdotnet1.html|title=Unmanaged, Managed Extensions for C++, Managed and .Net Framework|website=www.visualcplusdotnet.com|access-date=2020-07-07}}</ref>

The execution process looks like this:

#Source code is converted to CIL [[bytecode]] and a [[Assembly (CLI)|CLI assembly]] is created.
#Upon execution of a CIL assembly, its code is passed through the runtime's [[Just-in-time compilation|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==
{{See also|List of CIL instructions}}

CIL bytecode has [[instruction (computer science)|instruction]]s for the following groups of tasks:
*Load and store
*[[Arithmetic]]
*[[Type conversion]]
*[[Dynamic memory allocation|Object creation and manipulation]]
*[[stack (data structure)|Operand stack management (push / pop)]]
*[[branch (computer science)|Control transfer (branching)]]
*[[Subroutine|Method invocation and return]]
*[[Exception handling|Throwing exceptions]]
*[[Monitor (synchronization)|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 language]]s.

Code that adds two numbers in [[x86 assembly language]], where eax and edx specify two different [[X86#x86_registers|general-purpose registers]]:
<syntaxhighlight lang="asm">
add eax, edx
</syntaxhighlight>

Code in an [[intermediate language]] (IL), where 0 is eax and 1 is edx:
<syntaxhighlight lang="csharp">
ldloc.0    // push local variable 0 onto stack
ldloc.1    // push local variable 1 onto stack
add        // pop and add the top two stack items then push the result onto the stack
stloc.0    // pop and store the top stack item to local variable 0
</syntaxhighlight>

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 (programming)|method]] needs (with some exceptions) to reside in a class. So does this static method:
<syntaxhighlight lang="csharp">
.class public Foo {
    .method public static int32 Add(int32, int32) cil managed {
        .maxstack 2
        ldarg.0 // load the first argument;
        ldarg.1 // load the second argument;
        add     // add them;
        ret     // return the result;
    }
}
</syntaxhighlight>

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#:
<syntaxhighlight lang="csharp">
int r = Foo.Add(2, 3);    // 5
</syntaxhighlight>

In CIL it would look like this:
<syntaxhighlight lang="csharp">
ldc.i4.2
ldc.i4.3
call int32 Foo::Add(int32, int32)
stloc.0
</syntaxhighlight>

====Instance classes====
An instance class contains at least one [[Constructor (object-oriented programming)|constructor]] and some [[Instance (computer science)|instance]] members. The following class has a set of methods representing actions of a Car-object.
<syntaxhighlight lang="csharp">
.class public Car {
    .method public specialname rtspecialname instance void .ctor(int32, int32) cil managed {
        /* Constructor */
    }

    .method public void Move(int32) cil managed { /* Omitting implementation */ }
    .method public void TurnRight() cil managed { /* Omitting implementation */ }
    .method public void TurnLeft() cil managed { /* Omitting implementation */ }
    .method public void Brake() cil managed { /* Omitting implementation */ }
}
</syntaxhighlight>

====Creating objects====
In C# class instances are created like this:
<syntaxhighlight lang="csharp">
Car myCar = new Car(1, 4); 
Car yourCar = new Car(1, 3); 
</syntaxhighlight>

And those statements are roughly the same as these instructions in CIL:
<syntaxhighlight lang="csharp">
ldc.i4.1
ldc.i4.4
newobj instance void Car::.ctor(int, int)
stloc.0    // myCar = new Car(1, 4);
ldc.i4.1
ldc.i4.3
newobj instance void Car::.ctor(int, int)
stloc.1    // yourCar = new Car(1, 3);
</syntaxhighlight>

====Invoking instance methods====
Instance methods are invoked in C# as the one that follows:
<syntaxhighlight lang="csharp">
myCar.Move(3);
</syntaxhighlight>

As invoked in CIL:
<syntaxhighlight lang="csharp">
ldloc.0    // Load the object "myCar" on the stack
ldc.i4.3
call instance void Car::Move(int32)
</syntaxhighlight>

===Metadata===
{{Main|Metadata (CLI)}}

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 (computer science)|reflection]]".

Metadata can be data in the form of "attributes". Attributes can be customized by extending the <code>Attribute</code> 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!".
<syntaxhighlight lang="csharp">
.assembly Hello {}
.assembly extern mscorlib {}
.method static void Main()
{
    .entrypoint
    .maxstack 1
    ldstr "Hello, world!"
    call void [mscorlib]System.Console::WriteLine(string)
    ret
}
</syntaxhighlight>

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]].''
<syntaxhighlight lang="csharp">
static void Main(string[] args)
{
    for (int i = 2; i < 1000; i++)
    {
        for (int j = 2; j < i; j++)
        {
             if (i % j == 0)
                 goto outer;
        }
        Console.WriteLine(i);
        outer:;
    }
}
</syntaxhighlight>

In CIL assembler syntax it looks like this:
<syntaxhighlight lang="cpp">
.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack  2
    .locals init (int32 V_0,
                  int32 V_1)

              ldc.i4.2
              stloc.0
              br.s       IL_001f
    IL_0004:  ldc.i4.2
              stloc.1
              br.s       IL_0011
    IL_0008:  ldloc.0
              ldloc.1
              rem
              brfalse.s  IL_001b
              ldloc.1
              ldc.i4.1
              add
              stloc.1
    IL_0011:  ldloc.1
              ldloc.0
              blt.s      IL_0008
              ldloc.0
              call       void [mscorlib]System.Console::WriteLine(int32)
    IL_001b:  ldloc.0
              ldc.i4.1
              add
              stloc.0
    IL_001f:  ldloc.0
              ldc.i4     0x3e8
              blt.s      IL_0004
              ret
}
</syntaxhighlight>

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.&nbsp;g. C# or [[Visual Basic .NET|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 [[Obfuscated code|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===
[[Common Language Infrastructure|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 (programming)|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 {{code|ldind}}, {{code|stind}}, {{code|ldloca}}, and many call instructions which are enough for data/function pointers manipulation needed to compile C/C++ code into CIL.

<syntaxhighlight lang="cpp">
class A {
   public: virtual void __stdcall meth() {}
};
void test_pointer_operations(int param) {
	int k = 0;
	int * ptr = &k;
	*ptr = 1;
	ptr = &param;
	*ptr = 2;
	A a;
	A * ptra = &a;
	ptra->meth();
}
</syntaxhighlight>

The corresponding code in CIL can be rendered as this:

<syntaxhighlight lang="cpp">
.method assembly static void modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl) 
        test_pointer_operations(int32 param) cil managed
{
  .vtentry 1 : 1
  // Code size       44 (0x2c)
  .maxstack  2
  .locals ([0] int32* ptr,
           [1] valuetype A* V_1,
           [2] valuetype A* a,
           [3] int32 k)
// k = 0;
  IL_0000:  ldc.i4.0 
  IL_0001:  stloc.3
// ptr = &k;
  IL_0002:  ldloca.s   k // load local's address instruction
  IL_0004:  stloc.0
// *ptr = 1;
  IL_0005:  ldloc.0
  IL_0006:  ldc.i4.1
  IL_0007:  stind.i4 // indirection instruction
// ptr = &param
  IL_0008:  ldarga.s   param // load parameter's address instruction
  IL_000a:  stloc.0
// *ptr = 2
  IL_000b:  ldloc.0
  IL_000c:  ldc.i4.2
  IL_000d:  stind.i4
// a = new A;
  IL_000e:  ldloca.s   a
  IL_0010:  call       valuetype A* modopt([mscorlib]System.Runtime.CompilerServices.CallConvThiscall) 'A.{ctor}'(valuetype A* modopt([mscorlib]System.Runtime.CompilerServices.IsConst) modopt([mscorlib]System.Runtime.CompilerServices.IsConst))
  IL_0015:  pop
// ptra = &a;
  IL_0016:  ldloca.s   a
  IL_0018:  stloc.1
// ptra->meth();
  IL_0019:  ldloc.1
  IL_001a:  dup
  IL_001b:  ldind.i4 // reading the VMT for virtual call
  IL_001c:  ldind.i4
  IL_001d:  calli      unmanaged stdcall void modopt([mscorlib]System.Runtime.CompilerServices.CallConvStdcall)(native int)
  IL_0022:  ret
} // end of method 'Global Functions'::test_pointer_operations
</syntaxhighlight>

==See also==
*[[LLVM]]
*[[List of CIL instructions]]
*[[List of CLI languages]]

==References==
{{Reflist}}

==Further reading==
* {{cite book|author-last=Bock|author-first=Jason|year=2002|title=CIL Programming: Under the Hood of .NET|publisher=Apress|isbn=978-1590590416}}

==External links==
*[https://www.ecma-international.org/publications-and-standards/standards/ecma-335/ Common Language Infrastructure (Standard ECMA-335)]
*[https://www.visualstudio.com/license-terms/ecma-c-common-language-infrastructure-standards/ “ECMA C# and Common Language Infrastructure Standards” on the Visual Studio website]
*[[wikibooks:Computer Programming/Hello world#CIL|Hello world program in CIL]]
*[http://msdn.microsoft.com/en-us/magazine/cc163808.aspx Speed: NGen Revs Up Your Performance With Powerful New Features -- MSDN Magazine, April 2005]

{{Common Language Infrastructure}}
{{.NET}}

[[Category:Assembly languages]]
[[Category:Bytecodes]]
[[Category:Common Language Infrastructure]]