Hi All,

Microsoft Intermediate Language (MSIL) is a language used as the output of a number of compilers (C#, VB, .NET, and so forth). The ILDasm (Intermediate Language Disassembler) program that ships with the .NET Framework SDK (FrameworkSDK\Bin\ildasm.exe) allows the user to see MSIL code in human-readable format. By using this utility, we can open any .NET executable file (EXE or DLL) and see MSIL code.

The ILAsm program (Intermediate Language Assembler) generates an executable file from the MSIL language. We can find this program in the WINNT\Microsoft.NET\Framework\vn.nn.nn directory.


Any Visual C++ programmer starting with .NET development is interested in what happens in the low level of the .NET Framework. Learning MSIL gives a user the chance to understand some things that are hidden from a programmer working with C# or VB.NET. Knowing MSIL gives more power to a .NET programmer.


Shall we discover some of the secrets of MSIL

thnx....

Common Intermediate Language (CIL, pronounced either "sill" or "kill") (formerly called Microsoft Intermediate Language or MSIL) is the lowest-level human-readable programming language in the Common Language Infrastructure and in the .NET Framework. Languages which target the .NET Framework compile to CIL, which is assembled into bytecode. CIL resembles an object-oriented assembly language, and is entirely stack-based. It is executed by a virtual machine. The primary .NET languages are C#, Visual Basic .NET, C++/CLI, and J#.

CIL was originally known as Microsoft Intermediate Language (MSIL) during the beta releases of the .NET languages. Due to standardization of C# and the Common Language Infrastructure, the bytecode is now officially known as CIL. Because of this legacy, CIL is still frequently referred to as MSIL, especially by long-standing users of the .NET languages.


During compilation of .NET programming languages, the source code is translated into CIL code rather than platform or processor-specific object code. CIL is a CPU- and platform-independent instruction set that can be executed in any environment supporting the .NET framework. CIL code is verified for safety during runtime, providing better security and reliability than natively compiled binaries.



thnx....

hey,

I have some other General Information to share with you...

All operations in MSIL are executed on the stack. When a function is called, its parameters and local variables are allocated on the stack. Function code starting from this stack state may push some values onto the stack, make operations with these values, and pop values from the stack.

Execution of both MSIL commands and functions is done in three steps:

1. Push command operands or function parameters onto the stack.
2. Execute the MSIL command or call function. The command or function pops their operands (parameters) from the stack and pushes onto the stack result (return value).
3. Read result from the stack.

Steps 1 and 3 are optional. For example, the void function doesn't push a return value to the stack.

The stack contains objects of value types and references to objects of reference type. Reference type objects are kept in the heap.

MSIL commands used to push values onto the stack are called ld... (load). Commands used to pop values from the stack are called st... (store), because values are stored in variables. Therefore, we will call the push operation loading and the pop operation storing.

__________________
Venkat
knowledge is Power

Hi,

Here is the simple hellow world program in MSIL.

.assembly PrintString {}

/*
Console.WriteLine("Hello, World)"
*/

.method static public void main() il managed
{
.entrypoint // this function is the application
// entry point

.maxstack 8


// ************************************************** ***
// Console.WriteLine("Hello, World)";
// ************************************************** ***
ldstr "Hello, World" // load string onto stack

// Call static System.Console.Writeline function
// (function pops string from the stack)
call void [mscorlib]System.Console::WriteLine
(class System.String)


// ************************************************** ***
ldstr "Press Enter to continue"
call void [mscorlib]System.Console::WriteLine
(class System.String)


// Call the System.Console.Read function
call int32 [mscorlib]System.Console::Read()

// The pop instruction removes the top element from the stack.
// (remove number returned by Read() function)
pop
// ************************************************** ***

ret
}



MSIL directives used in the code are as follows:

* .entrypoint—defines the application entry point (the function called by .NET Runtime when the program starts).
* .maxstack—defines the maximum stack depth used by the function code. The C# compiler sets always the exact value for each function. In the sample project, I set this value to 8.

MSIL commands are as follows:

* ldstr string—loads the string constant onto the stack.
* call function(parameters)—calls the static function. Parameters for the function should be loaded onto the stack before this call.
* pop—pops a value from the stack. Used when we don't need to store a value in the variable.
* ret—returns from a function.

Calling the static function is simple. We push to stack the function parameters, call the function, and read from the stack function return value (if function is not void). Console.WriteLine is an example of such a function.


thnx....

hi,

Before we start grinding through MSIL instructions, I need to introduce a little bit about how the CLR works because it is essentially the CPU for the instructions. Where traditional CPUs rely on registers and stacks to do everything, the CLR uses only a stack. That means that to add two numbers, load both numbers onto the stack and call an instruction to add them. The instruction will remove the two numbers from the stack and put the result on top of the stack. If you are like me, it sometimes helps to see the actual implementation. The CLR evaluation stack can hold any type of value in the stack slots. Copying values from memory to the stack is referred to as loading, while copying items from the stack to memory is referred to as storing. Unlike the Intel CPU, the CLR stack does not hold the locals, but the locals are in memory. The stacks are local to the method doing the work and the CLR saves them across method invocations. Finally, the stack is also where method return values are placed. Now that I've covered just enough about how the CLR works.


thnx....