Mention that IL is also called CIL or MSIL (dotnet#1058)

Author: svick

docs/standard/managed-code.md

@@ -22,12 +22,14 @@ Contrast this to the way you would run a C/C++ program, also called “unmanaged
 
 Managed code is written in one of the high-level languages that can be run on top of the .NET platform, such as C#, Visual Basic, F# and others. When you compile code written in those languages with their respective compiler, you don’t get machine code. You get **Intermediate Language** code which the runtime then compiles and executes. C++ is the one exception to this rule, as it can also produce native, unmanaged binaries that run on Windows.
 
-## Intermediate Language & Execution
+## Intermediate Language & execution
 
 What is “Intermediate Language” (or IL for short)? It is a product of compilation of code written in high-level .NET languages. Once you compile your code written in one of these languages, you will get a binary that is made out of IL. It is important to note that the IL is independent from any specific language that runs on top of the runtime; there is even a separate specification for it that you can read if you’re so inclined.
 
 Once you produce IL from your high-level code, you will most likely want to run it. This is where the CLR takes over and starts the process of **Just-In-Time** compiling, or **JIT-ing** your code from IL to machine code that can actually be run on a CPU. In this way, the CLR knows exactly what your code is doing and can effectivelly _manage_ it.
 
+Intermediate Language is sometimes also called Common Intermediate Language (CIL) or Microsoft Intermediate Language (MSIL).
+
 ## Unmanaged code interoperability
 
 Of course, the CLR allows passing the boundaries between managed and unmanaged world, and there is a lot of code that does that, even in the [Base Class Libraries](framework-libraries.md). This is called **interoperability** or just **interop** for short. These provisions would allow you to, for example, wrap up an unmanaged library and call into it. However, it is important to note that once you do this, when the code passes the boundaries of the runtime, the actual management of the execution is again in the hand of unmanged code, and thus falls under the same restrictions.