【正文】 ) or the .NET runtime . Code running under the control of the CLR is often termed managed code .However, before it can be executed by the CLR, any source code that you develop (in C or some other language) needs to be piled. Compilation occurs in two steps in .NET:1) Compilation of source code to IL.2) Compilation of IL to platform specific code by the CLR.This two stage pilation process is very important, because the existence of the IL (managed code) is the key to providing many of the benefits of .NET.Microsoft Intermediate Language shares with Java byte code the idea that it is a low level language with a simple syntax (based on numeric codes rather than text), which can be very quickly translated into native machine code. Having this well defined universal syntax for code has significant advantages:platform independence, performance improvement, and language interoperability.Platform IndependenceFirst, platform independence means that the same file containing byte code instructions can be placed on any platform。 at runtime, the final stage of pilation can then be easily acplished so that the code will run on that particular platform. In other words, by piling to IL you obtain platform independence , in much the same way as piling to Java byte code gives Java platform independence.Note that the platform independence of .NET is only theoretical at present because, at the time of writing, aplete implementation of .NET is available only for Windows. However, a partial implementation is available (see, for example, the Mono project, an effort to create an open source implementation of .NET,at ).Performance ImprovementAlthough we previously made parisons with Java, IL is actually a bit more ambitious than Java byte code. IL is always Just in Time piled (known as JIT pilation), whereas Java byte code was often interpreted. One of the disadvantages of Java was that, on execution, the process of translating from Java byte code to native executable resulted in a loss of performance (with the exception of more recent cases,where Java is JIT piled on certain platforms).Instead of piling the entire application in one go (which could lead to a slow startup time), the JIT piler simply piles each portion of code as it is called (just in time). When code has been piled once, the resultant native executable is stored until the application exits so that it does not need to be repiled the next time that portion of code is run. Microsoft argues that this process is more efficient than piling the entire application code at the start, because of the likelihood that large portions of any application code will not actually be executed in any given run. Using the JIT piler, such code will never be piled.This explains why we can expect that execution of managed IL code will be almost as fast as executing native machine code. What it does not explain is why Microsoft expects that we will get a performance improvement . The reason given for this is that, because the final stage of pilation takes place at runtime, the JIT piler will know exactly what processor type the program will run on. This means that it can optimize the final executable code to take advantage of any features or particular machine code instructions offered by that particular processor.Traditional pilers will optimize the code, but they can only perform optimizations that are independent of the particular processor that the code will run on. This is because traditional pilers pile to native executable before the software is shipped. This means that the piler does not know what type of processor the code will run on beyond basic generalities, such as that it will be an x86 patible processor or an Alpha processor. The older Visual Studio 6, for example, optimizes for a generic Pentium machine, so the code that it generates cannot take advantage of hardware features of Pentium III processors. However, the JIT piler can do all the optimizations that Visual Studio 6 can, and in addition, it will optimize for the particular processor that the code is running on.中文翻譯CC是一種相當新的編程語言，C的重要性體現(xiàn)在一下兩個方面： Framework一起使用而設計的。（.Net Framework是一個功能非常豐富的平臺，可開發(fā)、部署和執(zhí)行分布式應用程序）。它是一個基于現(xiàn)代面向對象設計方法的語言，在設計它時，Microsoft還吸取了其他類似語言的經(jīng)驗，這些語言是近20年來面向對象規(guī)則得到廣泛應用后才開發(fā)出來的。有一個很重要的問題要弄明白：C就其本身而言只是一種語言。.NET支持的一些特性，C并不支持。而C語言支持的另一些特性，.NET卻并不支持（例如運算符重載）！但是，因為C，所以如果要使用C高效的開發(fā)應用程序，理解Framework就非常重要。公共語言運行庫.NET Framework的核心是起運行庫的執(zhí)行環(huán)境，稱為公共語言運行庫（CLR）。通常將在CLR的控制下運行的代碼稱為托管代碼(managed code)。但是，在CLR執(zhí)行編寫好的源代碼之前，需要編譯它們（在C中或其他語言中）。，編譯分為兩個階段：把源代碼編譯為Microsoft中間語言（IL）。CLR把IL編譯為平臺專用代碼。這兩個階段的編譯過程非常重要，因為Microsoft中間語言（托管代碼）。Microsoft中間語言與Java字節(jié)代碼共享一種理念：它們都是低級語言，語法很簡單（使用數(shù)字代碼而不是文本代碼），可以非?？焖俚霓D換為內(nèi)部機器碼。對于代碼來說，這種精心設計的通用語法有很重要的優(yōu)點：平臺無關性、提高性能和語言的互操作性。平臺無關性首先，這意味著包含字節(jié)代碼指令的同一文件可以放在任一平臺中，運行時編譯過程的最后階段可以很容易完成，這樣代碼就可以運行在特定的平臺上。換言之，這與編譯為Java平臺無關性是一樣的。.NET的平臺無關性目前只是一種可能，但人們正在積極準備，使它可以用于其他平臺。提高性能前面把IL和Java做了比較，實際上，IL比Java字節(jié)代碼的作用還要大。IL總是即時編譯的（稱為JIT編譯），而Java字節(jié)代碼常常是解釋性的，Java的一個缺點是，在運行應用程序時，把Java字節(jié)代碼轉換為內(nèi)部可執(zhí)行代碼的過程會導致性能的損失（但在最近，Java在某些平臺上能進行JIT編譯）。JIT編譯器并不是把整個應用程序一次編譯完，而是只編譯它調(diào)用的那部分代碼。代碼編譯過一次后，得到的內(nèi)部可執(zhí)行代碼就存儲起來，直到退出該應用程序為止，這樣在下次運行這部分代碼時，就不需要重新編譯了。Microsoft認為這個工程要比一開始就編譯整個應用程序代碼的效率高很多，因為任何應用程序的大部分代碼實際上并不是在每次運行過程中都執(zhí)行。使用JIT編譯器，從來都不會編譯這種代碼。這解釋了為什么托管IL代碼的執(zhí)行幾乎和內(nèi)部機器代碼的執(zhí)行速度一樣快，但是并沒有說明為什么Microsoft認為這會提高性能。其原因是編譯過程的最后一部分是在運行時進行的，JIT編譯器確切的知道程序運行在什么類型的處理器上，可以利用該處理器提供的任何特性或特定的機器代碼指令來優(yōu)化最后的可執(zhí)行代碼。傳統(tǒng)的編譯器會優(yōu)化代碼，但它們的優(yōu)化過程是獨立于代碼所運行的特定處理器上的。這是因為傳統(tǒng)的編譯器是在發(fā)布軟件之前編譯為內(nèi)部機器可執(zhí)行的代碼。即編譯器不知道代碼所運行的處理器類型，例如該處理器是X86兼容處理器還是Alpha處理器，這超出了基本操作的范圍。例如Visual Studio 6為一般的奔騰機器進行了優(yōu)化，所以它生成的代碼就不能利用奔騰Ⅲ處理器的硬件特性。相反，JIT編譯器不僅可以進行Visual Studio 6所能完成的優(yōu)化工作，還可以優(yōu)化代碼所運行的特定處理器