If C# is not interpreted, then why is a VM needed?

Question

I have read a lot of controversy about C#, where some say it's interpreted, some say it's not. I do know it's compiled into the MSIL and then JITed when run, depending on the processor etc...but isn't it still interpreted in the way it needs a VM (.NET) to run?

Solution 1

The VM is an abstraction of a microprocessor. It is just a definition and does not really exist. I.e. you cannot run code on the VM; however, you can generate IL code for it. The advantage is that language compilers do not need to know details about different kinds of real processors. Since different .NET languages like C# or VB (and many more) produce IL, they are compatible on this level. This, together with other conventions like a common type system, allows you to use a DLL generated from VB code in a C# program, for instance.

The IL is compiled just in time on Windows when you run a .NET application and can also be compiled ahead of time in Mono. In both cases, native machine code for the actual processor is generated. This fully compiled code is executed on the REAL microprocessor!

---

A different aspect is the number of compliers you have to write. If you have n languages and you want to run them on m processor architectures, you need n language-to-IL compliers + m IL-to-native-code compliers. Without this intermediate abstraction layer you would need to have n × m compliers and this can be a much higher number than just n + m!

Solution 2

The short answer is no, the requirement for the VM does not indicate that it's interpreted.

The VM contains the JIT compiler that translates IL to native machine code. It also contains the .NET class library, upon which C# programs depend. It also contains some other mechanisms involved in dynamic linking and such (definitely built on top of Windows DLL mechanism, but .NET has features above and beyond what Windows provides on its own, which are implemented in the VM).

Solution 3

You are probably refering to CLR (an implementation of the specification CLI).

The CLI defines a specific type system, semantics of all the operations on these types, a memory model, and run-time metadata.

In order to provide all of the above, some instrumentation of the generated code must happen. One simple example is to ensure that larger-than-32-bit numerals are supported and that floating-point operations behave as per specification on every architecture.

In addition, to ensure correct behaviour of memory allocation, correct management of metadata, static initialisation, generic type instantiation and similar some additional processes must be present during the execution of your CLR code. This is all taken care of by the VM and is not readily provided by the CPU.

A quote from Wikipedia, for example:

The CLR provides additional services including memory management, type safety and exception handling.

Comments

[Ben Voigt]

"This fully compiled code is executed on the REAL microprocessor"... true, but additional code, not derived from the IL, implementing behavior of the virtual machine is executed also (for C#, this would be the .NET Common Language Runtime)

[Olivier Jacot-Descombes]

Yes, the CLR manages things like loading, linking JIT-compilation, security aspects, memory management and more. But I would compare it to a kind of operating system, rather than to a VM.