Почему код .NET компилируется в MSIL? - PullRequest
7 голосов
/ 18 декабря 2009

Сначала код .NET компилируется в MSIL, а затем JIT преобразует его в машинно-зависимый код. Может ли кто-нибудь сказать мне, что все преимущества получают из-за двухэтапной компиляции. Спасибо

Ответы [ 4 ]

20 голосов
/ 18 декабря 2009

Есть несколько причин. В первую очередь, вероятно, сделать его кроссплатформенным. Если C # или другие языки .NET скомпилированы непосредственно в нативный код, их придется перекомпилировать для каждой платформы, на которой они работают. В случае виртуальной машины весь код может храниться в промежуточном формате, и вам нужно только написать реализацию виртуальной машины для каждой платформы.

Кроме того, имея не зависящий от языка промежуточный язык, вы можете иметь много языков высокого уровня (C #, VB.NET, Python и т. Д.), Все ссылки на сборки написаны на других языках. Поскольку все они компилируются в одно и то же, они могут беспрепятственно работать друг с другом.

Есть и преимущества в производительности. JIT-компилятор может выполнять агрессивную оптимизацию специально для машины, на которой выполняется код в это время. Я не знаю, какую оптимизацию выполняет компилятор .NET JIT в этом смысле, но теоретические преимущества могут быть очень большими.

6 голосов
/ 18 декабря 2009

Ответ можно найти на MSDN

1 голос
/ 18 декабря 2009

Первое преобразование с языка высокого уровня, а затем на машинный уровень - так устроена платформа .Net. Первый уровень заботится о языке высокого уровня для MSIL, а второй уровень может быть сконцентрирован на проблемах платформы для преобразования из MSIL в код машинного уровня. Он в основном поддерживает языковую совместимость и, возможно, в ближайшем будущем он также обеспечит кроссплатформенную поддержку, когда такой проект, как Mono, получит больше возможностей.

1 голос
/ 18 декабря 2009
  • Исполняемый файл не привязан к платформе. Например, XNA предназначена для процессоров PPC (Xbox360) и x86. Некоторые программы будут работать на Mono на Linux или OSX.

  • Позволяет оптимизировать работу целевой машины или заменить отсутствующие функции:

    • Например, OSX> = 10.5 компилируется в отсутствующих инструкциях GPU во время выполнения с OpenCL.
    • Допустим, вы работаете с ЦП без поддержки плавающей запятой, тогда вы можете эмулировать его с помощью JIT без необходимости полного переписывания кода.
    • В какой-то момент в будущем можно будет динамически разгрузить обработку в графический процессор или другие цели (я подозреваю, что функциональные языки несколько лучше подходят для этого).
...