 | This articleneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Common Intermediate Language" – news ·newspapers ·books ·scholar ·JSTOR(November 2017) (Learn how and when to remove this message) |
Common Intermediate Language (CIL), formerly calledMicrosoft Intermediate Language (MSIL) orIntermediate Language (IL),[1] is theintermediate language binary instruction set defined within theCommon Language Infrastructure (CLI) specification.[2] CIL instructions are executed by a CIL-compatible runtime environment such as theCommon Language Runtime. Languages which target the CLI compile to CIL. CIL isobject-oriented,stack-basedbytecode. Runtimes typicallyjust-in-time compile CIL instructions intonative code.
CIL was originally known as Microsoft Intermediate Language (MSIL) during the beta releases of the .NET languages. Due to standardization ofC# and the CLI, the bytecode is now officially known as CIL.[3]Windows Defender virus definitions continue to refer to binaries compiled with it as MSIL.[4]
During compilation ofCLI programming languages, thesource code is translated into CIL code rather than into platform- or processor-specificobject code. CIL is aCPU- and platform-independent instruction set that can be executed in any environment supporting the Common Language Infrastructure, such as the.NET runtime onWindows, or thecross-platformMono 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.[5][6]
The execution process looks like this:
CIL bytecode hasinstructions for the following groups of tasks:
The Common Intermediate Language is object-oriented andstack-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 mostprogramming languages.
Code that adds two numbers inx86 assembly language, where eax and edx specify two differentgeneral-purpose registers:
addeax,edx
Code in anintermediate language (IL), where 0 is eax and 1 is edx:
ldloc.0// push local variable 0 onto stackldloc.1// push local variable 1 onto stackadd// pop and add the top two stack items then push the result onto the stackstloc.0// pop and store the top stack item to local variable 0
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.
CIL is designed to be object-oriented. One may create objects, call methods, and use other types of members, such as fields.
Everymethod needs (with some exceptions) to reside in a class. So does this static method:
.classpublicFoo{.methodpublicstaticint32Add(int32,int32)cilmanaged{.maxstack2ldarg.0// load the first argument;ldarg.1// load the second argument;add// add them;ret// return the result;}}
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#:
intr=Foo.Add(2,3);// 5
In CIL it would look like this:
ldc.i4.2ldc.i4.3callint32Foo::Add(int32,int32)stloc.0
An instance class contains at least oneconstructor and someinstance members. The following class has a set of methods representing actions of a Car-object.
.classpublicCar{.methodpublicspecialnamertspecialnameinstancevoid.ctor(int32,int32)cilmanaged{/* Constructor */}.methodpublicvoidMove(int32)cilmanaged{/* Omitting implementation */}.methodpublicvoidTurnRight()cilmanaged{/* Omitting implementation */}.methodpublicvoidTurnLeft()cilmanaged{/* Omitting implementation */}.methodpublicvoidBrake()cilmanaged{/* Omitting implementation */}}
In C# class instances are created like this:
CarmyCar=newCar(1,4);CaryourCar=newCar(1,3);
And those statements are roughly the same as these instructions in CIL:
ldc.i4.1ldc.i4.4newobjinstancevoidCar::.ctor(int32,int32)stloc.0// myCar = new Car(1, 4);ldc.i4.1ldc.i4.3newobjinstancevoidCar::.ctor(int32,int32)stloc.1// yourCar = new Car(1, 3);
Instance methods are invoked in C# as the one that follows:
myCar.Move(3);
As invoked in CIL:
ldloc.0// Load the object "myCar" on the stackldc.i4.3callinstancevoidCar::Move(int32)
TheCommon Language Infrastructure (CLI) records information about compiled classes asmetadata. Like the type library in theComponent 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 theAttribute 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.
Below is a basic"Hello, World!" program written in CIL assembler. It will display the string "Hello, world!".
.assemblyHello{}.assemblyexternmscorlib{}.methodstaticvoidMain(){.entrypoint.maxstack1ldstr"Hello, world!"callvoid[mscorlib]System.Console::WriteLine(string)ret}
The following code is more complex in number of opcodes.
This code can also be compared with the corresponding code in the article aboutJava bytecode.
staticvoidMain(string[]args){for(inti=2;i<1000;i++){for(intj=2;j<i;j++){if(i%j==0)gotoouter;}Console.WriteLine(i);outer:;}}
In CIL assembler syntax it looks like this:
.methodprivatehidebysigstaticvoidMain(string[]args)cilmanaged{.entrypoint.maxstack2.localsinit(int32V_0,int32V_1)ldc.i4.2stloc.0br.sIL_001fIL_0004:ldc.i4.2stloc.1br.sIL_0011IL_0008:ldloc.0ldloc.1rembrfalse.sIL_001bldloc.1ldc.i4.1addstloc.1IL_0011:ldloc.1ldloc.0blt.sIL_0008ldloc.0callvoid[mscorlib]System.Console::WriteLine(int32)IL_001b:ldloc.0ldc.i4.1addstloc.0IL_001f:ldloc.0ldc.i40x3e8blt.sIL_0004ret}
This is just a representation of how CIL looks near thevirtual machine (VM) level. When compiled the methods are stored in tables and the instructions are stored as bytes inside the assembly, which is aPortable Executable (PE).
A CIL assembly and instructions are generated by either a compiler or a utility called theIL Assembler (ILAsm) that is shipped with the execution environment.
Assembled CIL can also be disassembled into code again using theIL Disassembler (ILDASM). There are other tools such as.NET Reflector that can decompile CIL into a high-level language (e. g. C# orVisual Basic). This makes CIL a very easy target for reverse engineering. This trait is shared withJava bytecode. However, there are tools that canobfuscate the code, and do it so that the code cannot be easily readable but still be runnable.
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, runtimetype safety, and assembly verification. To accomplish this, the JIT compiler examines the assembly metadata for any illegal accesses and handles violations appropriately.
CLI-compatible execution environments also come with the option to do anAhead-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 theNative Image Generator (NGEN) that performs the AOT. A different approach for AOT isCoreRT that allows the compilation of .Net Core code to a single executable with no dependency on a runtime. InMono there is also an option to do an AOT.
A notable difference from Java's bytecode is that CIL comes withldind,stind,ldloca, and many call instructions which are enough for data/function pointers manipulation needed to compile C/C++ code into CIL.
classA{public:virtualvoid__stdcallmeth(){}};voidtest_pointer_operations(intparam){intk=0;int*ptr=&k;*ptr=1;ptr=¶m;*ptr=2;Aa;A*ptra=&a;ptra->meth();}
The corresponding code in CIL can be rendered as this:
.methodassemblystaticvoidmodopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl)test_pointer_operations(int32param)cilmanaged{.vtentry1:1// Code size 44 (0x2c).maxstack2.locals([0]int32*ptr,[1]valuetypeA*V_1,[2]valuetypeA*a,[3]int32k)// k = 0;IL_0000:ldc.i4.0IL_0001:stloc.3// ptr = &k;IL_0002:ldloca.sk// load local's address instructionIL_0004:stloc.0// *ptr = 1;IL_0005:ldloc.0IL_0006:ldc.i4.1IL_0007:stind.i4// indirection instruction// ptr = ¶mIL_0008:ldarga.sparam// load parameter's address instructionIL_000a:stloc.0// *ptr = 2IL_000b:ldloc.0IL_000c:ldc.i4.2IL_000d:stind.i4// a = new A;IL_000e:ldloca.saIL_0010:callvaluetypeA*modopt([mscorlib]System.Runtime.CompilerServices.CallConvThiscall)'A.{ctor}'(valuetypeA*modopt([mscorlib]System.Runtime.CompilerServices.IsConst)modopt([mscorlib]System.Runtime.CompilerServices.IsConst))IL_0015:pop// ptra = &a;IL_0016:ldloca.saIL_0018:stloc.1// ptra->meth();IL_0019:ldloc.1IL_001a:dupIL_001b:ldind.i4// reading the VMT for virtual callIL_001c:ldind.i4IL_001d:calliunmanagedstdcallvoidmodopt([mscorlib]System.Runtime.CompilerServices.CallConvStdcall)(nativeint)IL_0022:ret}// end of method 'Global Functions'::test_pointer_operations
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.
