Let's talk about CLR and CLR.

Let's talk about CLR and CLR.

1. What is CLR?

CLR (Common Language Runtime) is a remote time that can be used by multiple programming languages ". Core CLR functions (such as memory management, assembly loading, security, exception handling, and thread synchronization) can be used in all CLR-oriented languages. CLR does not care about the language used by developers for programming. As long as the compiler is oriented to CLR, developers should use the most suitable and familiar language for programming. All programming languages generate a managed module in CLR compiler-oriented compilation. The hosted module is a standard 32-bit Microsoft Windows portable execution body (PE32) file, or a standard 64-bit Windows portable PE32 + file, they all need CLR to execute.

2. Components of the hosting module

PE32 or PE32 + header standard Windows PE File Header, similar to "public object file format ".

The CLR header contains information that uses this module to become a managed module (which can be explained by CLR and some utilities ). The header contains the required CLR version, some logos, and MethodDef metadata tag (token) of the managed module population method (Main method ), the module metadata, resources, strong names, and positions/sizes of some flags and other less important data items

Each managed module of metadata contains metadata tables. There are two types of tables: one type of table description defined in source code type and member: the other type of table description source code reference type and member

The code generated when the IL (intermediate language) code compiler compiles the source code. During runtime, CLR will compile the CPU commands at the local cost of IL

Usage of metadata:

During compilation, metadata eliminates the need for local C/C ++ headers and library files, because in the IL code responsible for implementing types/members, all information about packages and referenced types/members. The compiler can read metadata directly from the managed module.

Microsoft Visual Studio uses metadata to help you write code. That is, "Intelligent Sensing (intelliisense) technology" can parse metadata and point out the methods, attributes, events, and fields that a type provides.

The CLR code verification process uses metadata to ensure that the Code only performs "type security" operations.

Metadata allows you to serialize an object field to one memory, send it to another machine, deserialize it, and recreate the object state on a remote machine.

Metadata allows the Garbage Collector to track the lifetime of an object. The garbage collector can determine the type of any object and know which fields in the object reference other objects from the metadata.

3. Assembly

Actually, CLR does not work with the hosting module. It works with an assembly. An assembly is a logical group of one or more modules/resource files. An assembly is the minimum unit for reuse and security that has been version controlled. Self-describing)

4. Run the Assembly Code

The managed Assembly contains both metadata and IL. To execute a program, you must first convert its IL to the local CPU command. This is the responsibility of the clr jit (just-in-time) compiler.

Next I will repeat an example of a book to illustrate how the code in an assembly is executed.

Before executing the Main method, CLR will detect all types referenced by the Main code. This causes the CLR to allocate an internal data structure to manage access to the referenced types. For example, the Main method references a Console type, which causes the CLR to allocate an internal structure. In this internal structure, each method defined by the Console type has a corresponding record item. Each record item contains an address based on which you can find the implementation method. When this structure is initialized, CLR sets each record item to an undocumented function (pointing to) included in the CLR. I will turn this function into JITCompiler.

When Main calls WriteLine for the first time, the JITCompiler function will be called. The JITCompiler function is responsible for compiling a method IL code with a local CPU command. Generally, this component of CLR is called JITter or JIT compiler because IL is compiled in "instant" (just in time.

When the JITCompiler function is called, it knows the method to be called and the type of the method defined. Then, JITCompiler searches for the IL of the called method in the metadata of the defined assembly. Then, JITCompiler verifies the IL code and compiles the IL code into local CPU commands. The local CPU command is saved to a dynamically allocated memory block. Then, JITCompiler returns the internal data structure created by CLR for the type, finds the record of the method object to be called, and modifies the original reference to JITCompiler, point it to the address in the memory block. Finally, the JITCompiler function jumps to the Code in the memory block.

The second call to WriteLine. This time, because the WriteLine code is verified and compiled, the code in the memory block is directly executed, completely skipping the JITCompiler function.

The second call to WriteLine

5. General Type System

To communicate with the code written in one programming language through a type, Microsoft specifies a formal specification, that is, the Common Type System (CTS) describes the Type definition and behavior.

The CTS specification specifies that a type can contain zero or multiple members.

Field: a data variable

Method: A Function

Property for the caller, the member looks like a field

An Event implements a common mechanism between objects and other related objects.

CTS also specifies type Visibility rules and access rules for type members, such as private and family.

CTS also inherits the type. Virtual Methods and object lifetime define the corresponding rules.

Tebi tells us a rule in CTS: All types must be inherited from the pre-defined System. Object type. System. Object can do the following:

Compare the equality of two instances

Obtains the hash code of an instance.

Queries the real type of an instance.

Perform a shortest copy of an instance.

Obtains a string representation based on the current status of the Instance Object.

6. Public language specifications

To create a type that is easily accessible from other programming languages, you can only select one of your programming languages to determine which features are supported by all other languages, microsoft defines a Common Language Specifiaction (CLS), which defines a minimum set of functions in detail.

7. Metadata

As mentioned above, the managed PE file consists of four parts: The PE32 (+) header, CLR header, metadata, and IL.

Here we mainly talk about metadata.

Metadata is a binary data block consisting of several tables. These tables are divided into three categories: definiton talbe, reference table, and mainfest table ).

Frequently used metadata definition table (when the compiler compiles the source code, anything defined by the Code will create a record in the definition table ):

ModuleDef always contains a record for the module.

Each type defined in the TypeDef module has a corresponding record item in this definition table.

Each method defined in the MethodDef module has a corresponding record item in this definition table.

Each field defined in the FieldDef module has a corresponding record item in this definition table.

Each parameter defined in the ParamDef module has a corresponding record item in this definition table.

Each attribute defined in the PropertyDef module has a corresponding record item in this definition table.

Each event defined in the EventDef module has a corresponding record item in this definition table.

Common reference metadata tables:

Each Assembly referenced in the AssemblyRef module has a corresponding record item in this table.

Each type referenced by the ModuleRef module may be implemented by another PE module. All those modules have a record in this table.

Each type referenced by the TypeDef module has a corresponding record item in this table.

Each member referenced by the MemberRef module has a corresponding record in this table.

List metadata table:

AssemblyDef if this module identifies an assembly, it contains a single record item in this metadata table. This record item lists Assembly names (excluding paths and extensions), versions (major, minor, build, and revision), language culture, and flag), hash algorithm, and the publisher's public key.

Each PE file and resource file of FileDef as part of the Assembly has a corresponding record item in this table.

Each resource of MainifestResourceDef as part of the Assembly has a corresponding record item in this table.

ExportedTypesDef has a corresponding record item in this table for each public type exported from all PE modules of the Assembly.