. NET direct compilation cost code: A brief introduction to the. NET Native architecture __.net

This blog has not been updated for a long time. I've been busy with. NET native recently (mostly MCG), but it's not possible to mention it in a blog for reasons of secrecy. Last week build finally released (unfortunately did not go to, the team places too little), I can finally talk about the. NET native some things, hehe.

If you have not seen the previous release information, you can go to the following several URLs to see:

. NET native blog published by home. NET native


If English listening is good, you can listen to our team principal Dev leads talk (in fact, his English is more difficult to understand, fast ... ）：


Inside. NET Native Talk


Here is a brief description of the basic architecture of the. NET native, the basic content and the above talk actually almost, just to tell you some of the basic concepts of. NET native. If you have a certain part of the specific interest, you can also put forward, I try to answer within the scope of my ability (after all, I am not a person to do, hehe) or write a new blog detailed explanation.


There is an essential difference between. NET native and previous NGen. NGen actually gives Yiguoduan the data structure and code for the runtime of the CLR (which is, of course, simpler, actually more complex than this) in the final PE, and runs with the entire. NET Framework support, and cannot avoid JIT. Net Native is a new technology, the entire. NET framework after refactoring rewrite, the final runtime is very small, only hundreds of K, without any installation (in addition to Mrt100.dll, you can understand as Msvcrt.dll). Most functions are refactor from runtime to the framework as C # code or as part of Toolchain. A typical example is that P/invoke was originally implemented by the CLR and is written using C + + and compilation. And now it is through the MCG tool to take over, directly generated C #. The final. NET native generated Exe/dll is a machine code that can be run directly (generated from the back-end of the C + + compiler). By the way, some friends may ask: do we directly generate C + + code. The answer is in the negative. We use the C + + compiler backend to accept IL as input and generate Mdil.


The entire toolchain (tool chain) can be roughly divided into the following phases:


APP IL + FX-> MCG-> interop.g.cs-> CSC-> Interop.dll-> merges-> IL transform-> nutc-> rhbin D->. Exe


Step one: Use the IL Code of the application along with the IL of the entire. NET Framework BCL as input to MCG. MCG (marshalling Code generator) This piece is mainly in my charge. This tool is responsible for checking all interop-related types in the program and BCL, such as the WinRT interface, P/invoke, and so on. MCG will generate C # code for it. This C # code can be directly debugged, interested friends can F11 try to see. The role of C # code is primarily to replace the WINRT type definition in WINDOWS.WINMD, p/invoke definitions, and so on, to add various types of conversion code, such as String type, RCW and CCW, and so on, and eventually call directly to the local code. Some friends may ask: Why Build C #? The original CLR generated IL code directly at run time, but it is obvious that this method does not work well in. NET native, and that the IL code is difficult to debug. C # is convenient for everyone to debug, but also convenient for us to quickly modify the generated code, add more features. (write C + + program generated IL code is more troublesome, you have to manually calculate the position of the stack)
Step two: The C # code generated by MCG is compiled by CSC to generate the PE file. This step has nothing to say.
Step three: The PE file is packaged and merged into applications and BCL, generating a collection of IL code. Be prepared for the next step.

Step Fourth: This collection of IL code is handled in a number of steps, each of which is relatively simple and does just one thing. The primary role of these steps is to provide the functionality that was provided by the original CLR runtime, with the ultimate goal of enabling the final code to be compiled by C + +. In the original desktop version of the CLR (that is, the 4.5 inside), many features are provided by runtime, such as Delegate.invoke, such as Interop. The role of these transform is to process the code, replacing the part that originally needed runtime implementation with the actual code. Give a few examples:

1. When you call the Windows.UI.Xaml.Controls.Button type, MCG also generates a corresponding button type, and Il transform replaces both. The type of button that the program calls is the MCG generated code. 2. When you are doing serialization and deserialization, IL transform invokes another tool, SG, to generate serialization/deserialization C # code. Eventually these C # code builds are available for these operations.

3. Most of your programs do not use the entire BCL. In IL transform, there is a step called dependency reducer, which uses a GC-like algorithm (mark->sweep) to remove unwanted code. MCG also cooperates with Dr to reduce unnecessary interop code generation. The DR also reads the Rd.xml file, deciding which types need to reflect the information that they do not need. RD. XML this piece we are still improving, we also hope that we can make more valuable suggestions.

In fact, MCG is also a part of Il transform, but it is actually not transform, but directly generated C #.

Fifth step: NUTC to the IL processing, generate Mdil. NUTC is a special version of the legendary compiler back end of C + +, which is optimized for whatever it is. The last generated Mdil is close to the machine code, but it also contains some abstract type information that needs further processing.
The sixth step: Rhbind is responsible for Mdil processing, the inside and type system-related information generated code, and finally generate an EXE. In fact, the end is a exe+dll, the actual code is in the DLL. EXE just plays the role of Bootstrap. The reason for choosing a DLL is that we need to support the load as a background task within broker.

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

1. Did you finally generate C + + code?

A: Do not generate. C + + back-end is converted directly from Il to Mdil.

2. WPF support.

A: It is not supported at the moment. Currently only supports Windows Store Apps

3. Does this support desktop programs?

A: For the moment, only the Windows Store Apps is supported

4. Does this support JIT?

A: At present,. NET native does not support JIT, all code is compile-time generation.

5. Since it is a local machine code, you can also support type Reflection (reflection).

A: Machine code and reflection do not conflict, we in the PE file to store additional information for reflection, and then dynamically read this information to invoke. C + + can also support reflection (RTTI), just as well. NET strong just.

6. Do you need to install the. NET framework?

A: You need to develop the compilation, the runtime does not need.

7. Why not support VB

A: VB in Nature and C # are generated IL, technically very similar. At present, we only support C # because of the problem of time.

8. Why is the startup running faster.

A: On the one hand, thanks to C + + 's excellent compiler backend, on the one hand because of runtime rewrite and simplification.

This time it's about so much. Welcome to try. NET Native, go to the following places to give us some advice:

. NET Native Official forum dotnetnative@microsoft.com


If you do not want to write in English (in fact, you can write in Chinese), or directly in this blog message.


--
Zhang Yi
. NET Native