Что такое CIL (ранее MSIL) код и как его увидеть?
Common Intermediate Language (сокращённо CIL) — «высокоуровневый ассемблер» виртуальной машины .NET,- промежуточный язык, разработанный компанией Microsoft для платформы .NET Framework.
Все компиляторы, поддерживающие платформу .NET, транслируют код с языков высокого уровня на язык CIL (в среде разработки Visual Studio это C#, Managed C++, Visual Basic .NET).
Далее CIL код компилируется в native code с помощью JIT (just-in-time) компилятора, который и исполняется в CLR.
Так каким же образом можно увидеть CIL код?
В большинстве случаев для этого используется IL Disassembler (ildasm.exe), найти который можно по следующему пути:
ildasm.exe позволяет увидеть:
🔶 Список всех классов и методов в вашей сборке (assembly)
🔶 Содержимое manifest сборки
🔶 IL code всех методов, реализованных в сборке
На деле это выглядит следующим образом.
Подробнее про CIL код и процесс исполнения можно почитать на MSDN - Managed Execution Process.
✅ Понравилась заметка? Тогда поделись ей с другими 😉
#assemblies
Common Intermediate Language (сокращённо CIL) — «высокоуровневый ассемблер» виртуальной машины .NET,- промежуточный язык, разработанный компанией Microsoft для платформы .NET Framework.
Все компиляторы, поддерживающие платформу .NET, транслируют код с языков высокого уровня на язык CIL (в среде разработки Visual Studio это C#, Managed C++, Visual Basic .NET).
Далее CIL код компилируется в native code с помощью JIT (just-in-time) компилятора, который и исполняется в CLR.
Так каким же образом можно увидеть CIL код?
В большинстве случаев для этого используется IL Disassembler (ildasm.exe), найти который можно по следующему пути:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64
ildasm.exe позволяет увидеть:
🔶 Список всех классов и методов в вашей сборке (assembly)
🔶 Содержимое manifest сборки
🔶 IL code всех методов, реализованных в сборке
На деле это выглядит следующим образом.
Подробнее про CIL код и процесс исполнения можно почитать на MSDN - Managed Execution Process.
✅ Понравилась заметка? Тогда поделись ей с другими 😉
#assemblies
В чём причина существования CIL?
Закономерный вопрос.
Почему бы сразу не компилировать C# код в native code имея для этого лишь один компилятор? Для чего необходимо было создавать ещё один промежуточный язык-посредник и компилятор для него?
Как писал Eric Lippert,- два компилятора с промежуточным языком, как это не парадоксально, являются менее дорогим решением в случае с платформой .NET и чтобы это понять, следует вглянуть на ситуацию чуть шире.
🔶 Предположим, у нас есть n языков программирования (далее ЯП): C#, VB, F#, JScript и другие.
🔶 Предположим, у нас так же есть m различных сред выполнения (runtime environment): Windows на базе x86 и x64, XBOX 360, мобильные и другие.
🔶 Предположим, мы хотим придерживаться изначальной стратегии с компиляцией ЯП непосредственно в native code среды выполнения.
Сколько в таком случае нам потребуется компиляторов, чтобы каждый ЯП (n) мог скомпилироваться под каждый runtime (m)?
Ответ: n x m.
Так а что же с CIL? В случае наличия промежуточного языка, нам потребуется n компиляторов из ЯП в CIL и m компиляторов из CIL в runtime.
Как результат, кол-во компиляторов составит всего лишь n + m (что значительно меньше, учитывая кол-во ЯП и доступных runtime в случае с .NET).
Так же стоит учесть тот факт, что те, кто разрабатывают ЯП совершенно не обязательно знают все нюансы каждой платформы, в которой ЯП в дальнейшем будет исполняться.
Более того, если мы хотим иметь возможность исполнять все существующие ЯП для каждого нового runtime, то всё что нам необходимо будет сделать, так это написать единственный JIT компилятор из CIL в native code этого runtime 😉
💬 Если верить wikipedia, то на сегодняшний день компиляцию в CIL поддерживают более 30 языков программирования ☝️
#assemblies
Закономерный вопрос.
Почему бы сразу не компилировать C# код в native code имея для этого лишь один компилятор? Для чего необходимо было создавать ещё один промежуточный язык-посредник и компилятор для него?
Как писал Eric Lippert,- два компилятора с промежуточным языком, как это не парадоксально, являются менее дорогим решением в случае с платформой .NET и чтобы это понять, следует вглянуть на ситуацию чуть шире.
🔶 Предположим, у нас есть n языков программирования (далее ЯП): C#, VB, F#, JScript и другие.
🔶 Предположим, у нас так же есть m различных сред выполнения (runtime environment): Windows на базе x86 и x64, XBOX 360, мобильные и другие.
🔶 Предположим, мы хотим придерживаться изначальной стратегии с компиляцией ЯП непосредственно в native code среды выполнения.
Сколько в таком случае нам потребуется компиляторов, чтобы каждый ЯП (n) мог скомпилироваться под каждый runtime (m)?
Ответ: n x m.
Так а что же с CIL? В случае наличия промежуточного языка, нам потребуется n компиляторов из ЯП в CIL и m компиляторов из CIL в runtime.
Как результат, кол-во компиляторов составит всего лишь n + m (что значительно меньше, учитывая кол-во ЯП и доступных runtime в случае с .NET).
Так же стоит учесть тот факт, что те, кто разрабатывают ЯП совершенно не обязательно знают все нюансы каждой платформы, в которой ЯП в дальнейшем будет исполняться.
Более того, если мы хотим иметь возможность исполнять все существующие ЯП для каждого нового runtime, то всё что нам необходимо будет сделать, так это написать единственный JIT компилятор из CIL в native code этого runtime 😉
💬 Если верить wikipedia, то на сегодняшний день компиляцию в CIL поддерживают более 30 языков программирования ☝️
#assemblies
Wikipedia
List of CLI languages
Wikimedia list article