Углубление в C#
Страница 5. .NET IL


 

Осборн: Мы уже говорили о Java, C++ и скриптах. Здесь я слышал от многих людей, что в действительности нет разницы между .NET IL (IL это промежуточный язык Microsoft, который должны производить все компиляторы, для запуска на платформе .NET) и Java байт-кодом, который воспринимается виртуальной машиной Java (JVM). Из ваших слов понятно, что вы с этим не согласны. Не могли бы вы указать основные различия?

Хейлсберг: Конечно. Во-первых, идея IL - очень старая идея. Вы можете найти ее в концепции UCSD Pascal p-машины (ранняя реализация Pascal для персональных компьютеров) или в SmallTalk p-коде, и использование в Basic и VB. Части Word, внутренне используют механизм p-кода, так как он более компактен. Так что p-код вовсе не нов.

Я думаю, что подход, который мы применили в IL, интересен тем, что вы получаете дополнительные возможности контроля при преобразовании IL в native код. В С++ вы в действительности могли получать native код прямо из исходников. С++ может так же создавать IL, как и C# или VB. И когда вы устанавливаете код, мы даем вам возможность компилировать его на этом компьютере. Вы можете откомпилировать IL в native код определенного компьютера, и при запуске вы уже не будете иметь надстройки в виде JIT компиляции. Мы также предоставляем вам возможность запускать и компилировать код динамически - JIT компиляция. И конечно, присутствие IL добавляет возможностей, например, допустимость переноса на разные архитектуры процессора и предоставление проверки во время типовой защищенности, а далее построение системы безопасности поверх всего этого.

Я думаю, что одно из главных отличий между нашей реализацией IL и Java байткодом в том, что мы приняли решение не делать интерпретаторов. Код, который мы запускаем, всегда native. Даже когда вы создаете IL, он никогда не будет интерпретироваться. Мы имеем даже разные стили JIT компиляции. Для небольшой платформы у нас есть EconoJIT, мы назвали его так, потому что это очень простой JIT [Прим. ред.: .NET Compact - это подмножество среды .NET, созданная для переноса на другие устройства и платформы.]. Для desctop версии мы создали более полный JIT, и у нас есть даже JIT, который дает такие же результаты как наш C++ компилятор. Так как он требует больше времени, вы могли бы использовать его во время установки ПО.

Решение предпочесть запуск native кода интерпретации, оказало большое влияние на форму IL. Это поменяло набор включенных инструкций, и порядок их расположения. Если вы посмотрите на два IL, то сможете отметить, что они очень разные. Чувствуется, что наш IL нейтрален к типам. Нет информации в инструкциях, которая говорила бы о типах аргументов. Только подразумевается, что было положено в стэк. Этот подход делает IL более компактным. JIT компилятору в любом случае нужна эта информация, так что нет смысла хранить ее в инструкциях. Теперь вы знаете о некоторых разных решениях, которые позволяют проще переводить IL в native код.

Осборн: Какие различия между интерпретацией и вашим подходом вы можете отметить?

Хейлсберг: В основе интерпретации лежит цикл, берущий несколько байт из потока p-кода, и затем они отправляются к большому оператору переключения, который говорит: "это была операция сложения, теперь мы проходим через нее. Но этого не произошло" - и так далее.

Интерпретатор эмулирует процессор. Мы переворачиваем это сверху вниз и выполняем один проход - мы всегда выполняем один проход, когда переводим инструкции в машинный код. Это машинный код в случае EconoJIT, в действительности очень прост - это просто набор вызовов и push инструкций, и вызовов помощников из среды выполнения. Естественно даже такой код запускается во много раз быстрее.

Осборн: Так, давайте пройдем еще разок. Вы полностью компилируете код. Потом, когда вы закончите, будете иметь последовательность готовых к запуску битов. Однако в точке перевода IL в машинный код могут быть изменения.

Хейлсберг: Да. Но потом, если это среда построенная в памяти на небольшом устройстве, мы можем выкинуть код после использования.

Осборн: Возвращаясь назад к обсуждению синтаксиса языка: Меня интересует, включает ли C# встроенную поддержку регулярных выражений. Я не увидел ничего об этой поддержке в руководству по языку, но может быть она существует где-либо в другом месте.

Хейлсберг: Во-первых, существует класс регулярных выражений в библиотеке базовых классов. У нас нет прямой поддержки регулярных выражений, но у нас есть некоторые возможности, которые в действительности очень похожи на это. Не стоит уделять этому много внимания, но например, мы даем возможность писать дословные строковые литералы, где вам не нужно ставить два обратных слэша, каждый раз когда вы хотите поставить один. Это очень полезно когда вы используете регулярные выражения или когда вы пишите кавычки в кавычках. Это небольшая особенность очень помогает, и конечно ее основа находится в распределенной, на различные языки программирования, платформе .NET.

 

 
« Предыдущая статья