Usually to develop an application Program First, select a development platform. Then, we must Decide which one to useProgramming Language . This is usually a difficult choice, because different languages have different skills. Of course, the premise is that you can use this language as a developer. Because debuglzq Article We will discuss how to develop on the. NET Framework development platform. Public Language Runtime Language, including: C ++/CLI, C #, Visual Basic, JScript, J #, and an intermediate language assembler ). In addition to Ms, some companies and universities have also launched runtime-oriented Code Products, I know Ada, APL, caml, COBOL, Eiffel, forth, Fortran, Haskell, lexico, liso, logo, Lua, mercury, ML, Mondrian, Oberon, Pascal, perl, PHP, Prolog, Python, RPG, scheme, smalltalk, and Tcl/TK. In this case, what are the advantages of different programming languages? In fact, the compiler can be used as a parser for the syntax checker and "correct code. They check Source code Make sure everything you write makes sense, and then output the code that describes your intent.Different Languages allow different syntaxes for development . Do not underestimate the value of this choice. For example, for mathematical or financial applications, using APL can save a lot of development time than using Perl. In fact ,. when a. NET application is running, CLR does not care about the language used by developers, because the source code written in a specific language has been compiled into a managed module by the corresponding compiler ). What does debuglzq mean? (from Jeffrey Richter, debuglzq pays tribute to Daniel J. R !!!) :
Shows the process of compiling source code files. From this figure, you can use any language that supports CLR to write source code files. Then the compiler checks the syntax and analyzes the source code. No matter which compiler you use, the result isHosting module. The hosted module is a standard 32-bit Microsoft Windows portable execution file (pe32), or a standard 64-bit Microsoft Windows portable execution file (pe32 + ).
What is the "managed module" compiled by the compiler? The following section shows the components of the managed module's brother (I originally wanted to use debuglzq's own language, but I was worried that it was not accurate enough. You know, I am most worried about the poor performance of debuglzq. It's just a fool !! Therefore, debuglzq tries its best to keep the original descriptions in the important references. It is not a opportunistic practice of debuglzq. I really don't want to mislead you !) :
It should be noted that, unlike the local code compiler, the local code compiler generates code for a specific CPU architecture. Each CLR-oriented compiler generates il (intermediate language) code.
In addition to generating Il, each CLR-oriented compiler also generates complete metadata in each managed module. In short, metadata is a group of data tables. Some data tables describe the content defined in the module, such as the type and its members. Some metadata describes the content referenced by the hosting module, such as the import type and its members. Since the compiler generates metadata and IL at the same time, binds them together and embeds them into the final managed module, the metadata and the Il code it describes will never be out of sync.
Ms C #, Visual Basic, F #, and IL compilers always generate modules that contain managed code (IL) and managed data (garbage collection data types. To execute modules that contain hosted code and/or data, end users must install CLR on their computers (currently provided as part of the. NET Framework ). Similar to running Visual Basic 6 applications, you must install the Microsoft Foundation Class (MFC) library or visual basic DLLs.
By default, the C ++ compiler of Ms generates EXE/DLL modules that contain unmanaged (local) Code and manipulate unmanaged data (local memory) during runtime ). These modules can be executed without the need for CLR. However, when a/CLR command line switch is developed, the C ++ compiler can generate modules that contain unmanaged code. Of course, the end user must install CLR to execute this code (Amazing !!!).
After a managed module is generated by the compiler, can the program run? The answer is no.The CLR does not actually work with the module. Instead, it works with the Assembly..Assembly(Assembly) is an abstract concept. First, an assembly is a logical grouping of one or more modules/resource files. Second, an assembly is the minimum unit for reuse, security, and version control. Depending on your choice of the compiler or tool, you can generate a single-file assembly or a multi-file assembly. In the CLR world, a program list is associated with a "component ".
By default, the compiler will actually convert the generated managed module into an assembly. The following figure is displayed:
Each assembly you generate can be either an executable application or a DLL (which contains a group of types used by executable programs ). Of course, the CLR manages the execution of the Code in these programs.
Before introducing how to load CLR, we need to discuss the 32-bit and 64-bit Windows versions. In fact, the EXE file generated by the compiler can not only run on 32-bit windows, but also run on 64-bit windows x64 and IA64 versions! In rare cases, developers want code intelligence to run on a specific version of Windows. To help these developers, the C # compiler provides a/platform command line switch option. This switch allows developers to select the target platform to run. If you do not specify a platform, the default option is anycpu, indicating that the program set to be generated can run on any version of Windows. For example:
When running an executable file, Windows checks the header of the EXE file to determine whether the application needs a 32-bit address space or a 64-bit address space. Which managed module will be obtained when C # compiler has ing different/platform command line switches. Secondly, it summarizes how applications run on different versions of Windows.
After windows checks the EXE file header and determines whether to create a 32-bit, 64-bit, or wow64 process, the x86, x64, or IA64 versions of mscoree. dll will be loaded in the process address space.
Then, the main thread of the process calls a method defined in mscoree. dll. Initialize the CLR, load the EXE assembly, and call its main method ). Then, the hosted application starts and runs.
Then, run the assembly code. To execute a method, you must first convert its Il to the local CPU command. This is the responsibility of the clr jit (just-in-time) compiler. Shows the events that occur when a method is called for the first time.
InMainBefore the method is executed, CLR checks allMainType of method reference. This will cause the CLR to allocate an internal data structure to manage these referenced types.In,MainThe method references only one type,ConsoleTherefore, CLR allocates a single internal data organization. This internal data structure is included inConsoleType. Each portal has an address, which can be used to find the implementation part of the method. When initializing this structure, CLR sets each entryAn internal function that is not officially recorded is describedJitcompiler.
(1) When Main is called for the first time
Writeline,
JitcompilerThe function is also called.
JitcompilerResponsible for the Il code compilation cost of a method's CPU commands. Because Il is compiled by "instant (Just In Time )",CLRThis part is usually calledJitterOrJITCompiler.
when the
jitcompiler function is called, it knows which method is called, what type is defined in this method. (2) the
jitcompiler function searches for the Il code of the called method in the Assembly metadata.
jitcompiler verifies the Il code and compiles the local CPU commands. local CPU commands are stored in a dynamically allocated memory block. Then (3)
jitcompiler replaces the address of the method called in the preceding internal data structure with the address containing the local CPU memory block address of the instruction . (4) the
jitcompiler function jumps to the Code in the memory block . The code here is the implementation of the
writeline method ( contains a string type parameter version ). (5) after the code is executed, it will be returned to the main function, main the function continues to execute the following code . Now
MainSecond call
WritelineMethod. This time,
WritelineThe Code has been verified and compiled.So this time it will be called directly to the memory, and it will be skipped completely.
JitcompileFunction.WritelineAfter executionMain.
Indicates the second call
WritelineMethod.
In this wayMethod (s) will cause some performance loss only when it is called for the first time.. All subsequent calls to this method will be executed at full speed with the local code, because the local Code no longer needs to be verified and compiled.
JITThe compiler stores locally in the dynamic memory. This means that when the application is closed, the locally generated code will be discarded. In this way,If we run the application again later or run two different instances of the application at the same time,The JIT compiler needs to repeat the same IlCode compilation cost commands. For most applications,JITThe loss caused by compilation is negligible. In addition, most of them can also use the program to call the same method repeatedly. In this way, when the application is executed, these methods only cause one-time loss. In addition, it usually takes more time to execute a method than to call the method itself. Note that the clr jit compiler optimizes the local code. Similarly, it may take a lot of time to optimize the code, but the code will get better performance after optimization than the code without optimization. In fact, Ms has performed a lot of optimization work in the second variant phase, keeping the additional overhead at the lowest. Although this is hard to convince, many people (including me) think that the performance of hosted applications actually exceeds that of unmanaged applications. There are many reasons we are convinced of this. Here are the reasons for referencing JR:
If the test shows that the clr jit compiler does not seem to achieve the performance of its own applications, you should also use the ngen.exe tool provided by. NET Framework sdk. This will compile all the code of an assembly and save the code to a disk file. At runtime, once the Assembly CLR is loaded, the system automatically determines whether a pre-compiled version of the Assembly exists. If a pre-compiled version of the Assembly exists. If it is CLR, load the pre-compiled code. In this way, the pre-compiled code is not loaded at runtime. In this way, the pre-compiled code is not loaded at runtime. In this way, the pre-compiled code is not loaded at runtime. In this way, the pre-compiled code is not loaded at runtime. This avoids compilation during runtime. Note,
Ngen.exe makes very conservative assumptions about the final execution environment (it cannot be so ).Therefore, the code generated by ngen is not highly optimized as the code generated by the JIT compiler. Average level, limited capacity, please forgive me !!!!!!!!!!!!!!!!! [Click the following green channel:
Follow debuglzq, Learning and improving together with debug!]