What is a Virtual Execution System

The Virtual Execution System (VES) provides an environment for executing managed code.

• It provides direct support for a set of built-in data types, defines a hypothetical machine with an associated machine model and state, a set of control flow constructs, and an exception handling model.

• To a large extent, the purpose of the VES is to provide the support required to execute the Common Intermediate Language instruction set.

ECMA C# and Common Language Infrastructure Standards

In June 2005, the General Assembly of the international standardization organization Ecma approved edition 3 of the C# Language and the Common Language Infrastructure (CLI) specifications, as updated Ecma-334 and Ecma-335, respectively (see press release). The updated technical report on the CLI, Ecma TR-84, and a new technical report on the CLI, Ecma TR-89, were also ratified.

In July 2005, Ecma submitted the Standards and TRs to ISO/IEC JTC 1 via the ISO Fast-Track process. The Standards were adopted in April 2006 as ISO/IEC 23270:2006 (C#), ISO/IEC 23270:2006 (CLI), ISO/IEC TR 23272:2006 (CLI, XML Libraries) and ISO ISO/IEC TR 25438:2006 (CLI, Common Generics).

In July 2006 the General Assembly of Ecma approved edition 4 of the Standards which correspond to the ISO 2006 versions.

1- Common Language Infrastructure

The Common Language Infrastructure (CLI) provides a specification for executable code and the execution environment (the Virtual Execution System) in which it runs.Executable code is presented to the VES as modules.

A module is a single file containing executable content , the Common Language Infrastructure (CLI) provides a specification for executable code and the execution environment (the Virtual Execution System) in which it runs.

Type safety is usually discussed in terms of what it does (e.g., guaranteeing encapsulation between different objects) or in terms of what it prevents (e.g., memory corruption by writing where one shouldn’t). However, from the point of view of the CTS, type safety guarantees that:

• References are what they say they are
• Identities are who they say they are
• Only appropriate operations can be invoked

Metadata describes code by describing the types that the code defines and the types that it references externally. The compiler produces the metadata when the code is produced. Enough information is stored in the metadata To:

• Manage code execution
• Administer the code
• Reference types in the code

The CTS assumes that the execution environment is metadata-driven. Using metadata allows the CLI to support:

1. Multiple execution models
2. Auto support for services
3. Better optimization
4. Reduced binding brittleness
5. Flexible deployment resolution

2- Managed Code and Managed Data

Managed code is code that provides enough information to allow the CLI to provide a set of core services ,Given an address inside the code for a method, locate the metadata describing the method

• Walk the stack
• Handle exceptions
• Store and retrieve security information

Managed data is data that is allocated and released automatically by the CLI, through a process called garbage collection.

3- Common Language Specification

The CLS is a set of rules intended to promote language interoperability ,these rules shall be followed in order to conform to the CLS. CLS conformance is a characteristic of types that are generated for execution on a CLI implementation.

Such types must conform to the CLI standard, in addition to the CLS rules.

These additional rules apply only to types that are visible in assemblies other than those in which they are defined, and to the members that are accessible outside the assembly; that is, those that have an accessibility of public, family (but not on sealed types), or family-or-assembly (but not on sealed types).

A library consisting of CLS-compliant code is herein referred to as a framework . Frameworks are designed for use by a wide range of programming languages and tools, including both CLS consumer and extender languages. By adhering to the rules of the CLS, authors of libraries ensure that the libraries will be usable by a larger class of tools than if they chose not to adhere to the CLS rules. The following are some additional guidelines that CLS-compliant frameworks should follow:

• Avoid the use of names commonly used as keywords in programming languages.
• Not expect users of the framework to be able to author nested types.
• Assume that implementations of methods of the same name and signature on different interfaces are independent.
• Not rely on initialization of value types to be performed automatically based on specified initializer values.

Assume users can instantiate and use generic types and methods, but do not require them to define new generic types or methods, or deal with partially constructed generic types.

3-1 Common Language Specification Extender

A CLS extender is a language or tool that is designed to allow programmers to both use and extend CLS compliant frameworks. CLS extenders support a superset of the behavior supported by a CLS consumer (i.e., everything that applies to a CLS consumer also applies to CLS extenders). In addition to the requirements of a consumer, extenders are expected to be able to:

• Define new CLS-compliant types that extend any (non-sealed) CLS-compliant base class.
• Have some mechanism for defining types whose names are keywords in the language.
• Provide independent implementations for all methods of all interfaces supported by a type.
• That is, it is not sufficient for an extender to require a single code body to implement all interface methods of the same name and signature.
• Implement any CLS-compliant interface.
• Place any CLS-compliant custom attribute on all appropriate elements of metadata.

Define new CLS-compliant (non-generic) types that extend any (non-sealed) CLS-compliant base type. Valid base types include normal (non-generic) types and also fully constructed generic types.

Extenders need not support the following:

1. Definition of new CLS-compliant interfaces.
2. Definition of nested types.
3. Definition of generic types and methods.
4. Overriding existing virtual generic methods.

3-2 Common Language Specification Compliance

The CLS defines language interoperability rules, which apply only to “externally visible” items. The CLS unit of that language interoperability is the assembly—that is, within a single assembly there are no restrictions as to the programming techniques that can be used. Thus, the CLS rules apply only to items that are visible outside of their defining assembly and have public, family, or family-or-assembly accessibility.The class System.CLSCompliantAttribute : Indicates which types and type members are CLScompliant.

Built In Value and References Type

The Following data types are integral part of CTS and are supported directly by the VES they have special encoding in the persistent metadata.



The CLI model uses an evaluation stack to support this data types.

• Instructions that copy values from memory to the evaluation stack are “loads”.
• Instructions that copy values from the stack back to memory are “stores”.

The full set of data types in the Table are Data Types Directly supported by the CLI can be represented in memory. However, the CLI supports only a subset of these types in its operations upon values stored on its evaluation stack—int32, int64, and native int.

CLI instruction for short value special support

Load and store instructions to/from memory:

• ldelem
• Ldind
• Stelem
• stind

Data conversion:

• Conv
• Conv
• ovf

Array Creation:

• newarr