Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how to understand. NET Native structure, the article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

Here is a brief talk about the basic architecture of the .NET Native. The basic content is actually similar to the above talk, just to tell you some basic concepts of the .NET Native.

The .NET Native is fundamentally different from the previous NGEN. NGEN is actually putting the data structure and code of the CLR runtime into the final PE (of course, this is a simplified term, actually more complex than this), the runtime still requires the entire .NET Framework support, and can not avoid JIT. The .NET Native is a completely new technology, and the entire .NET Framework has been rewritten by refactoring, and the final runtime is very small, only a few hundred kilograms, without any installation (apart from mrt100.dll, it can be understood as msvcrt.dll). Most of the functionality exists from refactor in runtime to framework as C # code or as part of toolchain. A typical example is that P/invoke was originally implemented by CLR and written in C++ and assembly. Now it is taken over by the tool MCG to generate C # directly. In the end, the EXE/DLL generated by the .NET Native is machine code that can be run directly (generated through the back end of the C++ compiler). By the way, some friends may ask: do we generate C++ code directly? The answer is no. The C++ compiler backend we use takes IL as input and generates MDIL.

The whole Toolchain (tool chain) can be divided into the following stages:

App IL + FX-> MCG-> Interop.g.cs-> CSC-> Interop.dll-> Merge-> IL transform-> NUTC-> RhBind-> .exe

Step 1: input the application's IL code and the entire .NET Framework BCL's IL to MCG. I am mainly in charge of MCG (Marshalling Code Generator). This tool is responsible for checking the program and all Interop-related types in BCL, such as WinRT interface, P/Invoke, and so on. MCG generates C # code for it. This C # code can be debugged directly. If you are interested, you can try it on F11. The main purpose of C # code is to replace WinRT type definition, P/invoke definition, and so on in Windows.WinMD, add various types of conversion code, such as string type, RCW and CCW, etc., and finally call directly to the local code. Some friends may ask: why do you want to generate caches? The original CLR generates IL code directly at run time, but obviously this method does not work well in the .NET Native, and IL code is difficult to debug. C # is not only convenient for everyone to debug, but also convenient for us to quickly modify the generated code and add more functions. (it is troublesome to write C++ programs to generate IL code, so you have to calculate the location of the stack manually.)

Step 2: the C # code generated by MCG is compiled by CSC to generate the PE file. There is nothing to say about this step.

Step 3: this PE file is packaged and merged into the application and BCL to generate a collection of IL code. Get ready for the next step.

Step 4: this collection of IL code is processed through several steps, each of which is relatively simple and does only one thing. The main purpose of these steps is to provide the functionality provided by the original CLR runtime, and the ultimate goal is to enable the final code to be compiled by C++. In the original desktop version of CLR (the one in 4.5), many functions are provided by Runtime, such as Delegate.Invoke, such as interop. The purpose of these Transform is to process the code, replacing the parts that need to be implemented by runtime with the actual code. Here are a few examples:

1. When you call the Windows.UI.Xaml.Controls.Button type, MCG will also generate a corresponding Button type, and then IL Transform will replace the two, so that the Button type called by the program is the code generated by MCG.

two。 When you are doing Serialization and Deserialization, IL Transform will call another tool, SG, to generate serialization/deserialization 's C # code, and eventually these operations will generate the C # code.

3. Your program probably won't use the entire BCL. There is a step in IL Transform called Dependency Reducer, which uses an algorithm like GC (mark- > sweep) to remove unwanted code. MCG also works with DR to reduce unnecessary interop code generation. DR also reads the RD.XML file to determine which types need to reflect information and which don't. We are still in the process of improving the RD.XML area, and we hope you will put forward more valuable suggestions.

In fact, MCG is actually a part of IL Transform, but it doesn't actually Transform, but generates C # directly.

Step 5: NUTC processes the IL to generate MDIL. NUTC is a special version of the legendary C++ compiler backend that optimizes things. The resulting MDIL is close to machine code, but also contains some abstract type information that needs further processing.

Step 6: RhBind is responsible for processing the MDIL, generating code for the information related to the type system, and finally generating an EXE. In fact, in the end, it is an EXE+DLL, and the actual code is in DLL. EXE only acts as Bootstrap. The reason for choosing DLL is that we need to support loading in Broker as Background Task.

A few frequently asked questions I hear (please forgive me if some of the answers are too "official"):

1. Did you finally generate C++ code?

Answer: not generated. The C++ backend is directly converted from IL to MDIL.

2. Does WPF support it?

A: not for the time being. Currently, only Windows Store Apps is supported.

3. Will this support desktop programs?

A: currently, only Windows Store Apps is supported.

4. Does this support JIT?

A: currently, .NET Native does not support JIT, and all code is generated at compile time.

5. Since it is native machine code, why can it support type reflection (reflection)?

A: there is no conflict between machine code and reflection. We store additional information for reflection in the PE file, and then dynamically read this information for calling. C++ can also support RTTI, but it's not as powerful as .NET.

6. Does this require the installation of .NET Framework?

Answer: developers need it when compiling, but not at run time.

7. Why not support VB

A: VB and C # essentially generate IL, which is very similar in technology. It's just that at present, we only support C# for the time being.

8. Why does the startup run faster?

A: on the one hand, it is due to C++ 's excellent compiler backend, and on the other hand, because of the rewriting and simplification of runtime.

The above is the editor for you to share how to understand. NET Native architecture, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.