Действительно ли Just In Time Compiler(JIT) сопоставляет каждую из инструкций Common Intermediate Language(CIL) в программе с opcodes базового процессора?
И если это так, можем ли мы называть CIL языком ассемблера, а JIT - ассемблером
Примечание. Википедия не указывает CIL как язык ассемблера в своем списке языков ассемблера
Сборка состоит из мнемоник инструкций машинного кода конкретного процессора. Прямое представление единиц и нулей, которые заставляют ядро выполнять код, но написанное в тексте, чтобы облегчить работу человеку. Что очень не похоже на CIL:
Этот последний пункт является ключевым, дизайнерское решение, которое отличает CIL от байт-кода, состоит в том, что инструкции CIL не имеют типов. Есть только одна инструкция ADD, но у процессоров есть много ее версий. Конкретные, которые принимают операнды byte, short, int, long, float и double. Требуется, поскольку для выполнения добавления используются разные части ядра процессора. Джиттер выбирает правильный в зависимости от типа операндов, которые он выводит из предыдущих инструкций CIL.
Как и оператор + в языке C #, он также может работать с разными типами операндов. Что действительно делает L в CIL значимым, это язык. Простой, но простой, чтобы упростить запись для него джиттера.
Этот вопрос касается определений, поэтому давайте определим термины должным образом. Во-первых, язык ассемблера:
Ассемблер - это язык программирования низкого уровня для компьютеров, микропроцессоров, микроконтроллеров и других программируемых устройств, в котором каждый оператор соответствует одной инструкции машинного языка. Язык ассемблера специфичен для определенной компьютерной архитектуры, в отличие от большинства языков программирования высокого уровня, которые обычно переносимы на несколько систем.
Теперь CIL:
Common Intermediate Language - это язык программирования нижнего уровня, понятный человеку, определенный спецификацией Common Language Infrastructure (CLI) и используется .NET Framework и Mono. Языки, нацеленные на CLI-совместимую среду выполнения, компилируются в CIL, который собирается в объектный код, имеющий формат в стиле байт-кода.
Хорошо, эта часть технически неверна: например, компилятор C # компилируется непосредственно в байт-код, он не проходит через CIL (язык, читаемый человеком), но теоретически мы можем представить, что происходит.
С этими двумя определениями CIL является языком ассемблера, потому что каждый оператор в нем компилируется до одной инструкции байт-кода. Тот факт, что нет физического компьютера, который мог бы выполнить этот байт-код напрямую, не имеет значения.
В определении говорится, что каждый язык ассемблера «специфичен для определенной компьютерной архитектуры». В данном случае архитектура - это виртуальная машина CLR.
О JIT: JIT-компилятор нельзя считать ассемблером: он не выполняет преобразование 1: 1 из удобочитаемой формы в байт-код, это делает ilasm.
Компилятор JIT - это оптимизирующий компилятор, который компилирует байт-код в машинный код (для любого ISA / CPU, на котором он работает), одновременно выполняя оптимизацию.
ilasm является ассемблером (и, следовательно, CIL - языком ассемблера), согласно определениям терминов ...?
- person stakx - no longer contributing; 28.07.2012
Граница на самом деле довольно расплывчата ... аргументы, которые я видел против вызова CIL "языка ассемблера", почти так же применимы к _2 _ / _ 3_ на практике.
Intel и AMD не создали процессоры, которые выполняют инструкции сборки в точности так, как они были выпущены десятилетиями (если вообще когда-либо), поэтому даже так называемый «собственный» код не сильно отличается от работы на виртуальной машине, байт-код которой указан в _4 _ / _ 5_.
_6 _ / _ 7_ - это элемент нижнего уровня, к которому имеют доступ типичные разработчики, поэтому, если бы нам пришлось остановиться и называть что-то в нашей экосистеме «языком ассемблера», это бы победило, а поскольку CIL байт-код в конечном итоге требует _9 _ / _ 10_ инструкций чтобы иметь возможность работать на процессоре из этого семейства, тогда есть довольно веские аргументы в пользу того, что он действительно не «чувствует», что он должен считаться.
Так что в каком-то смысле, возможно, ни один из них не может считаться «языком ассемблера». Говоря о _11 _ / _ 12_ процессорах, мы почти никогда не говорим о процессорах, которые выполняют _13 _ / _ 14_, не переводя его во что-то другое (т.е. что бы ни делал микрокод).
Чтобы добавить еще одну сложность, способ, которым процессор _15 _ / _ 16_ выполняет заданную последовательность инструкций, может измениться, просто обновив микрокод. Быстрый поиск показывает, что Linux может даже сделать это самостоятельно в программном обеспечении!
Итак, я думаю, вот критерии, которые могут оправдать разделение их на две отдельные категории:
CIL байт-код, реализованы программно?Итак, что касается вопроса «является ли CIL языком ассемблера», лучшие ответы, которые я могу дать, - это «зависит от обстоятельств» (для ученых) и «в значительной степени» (для инженеров).
CIL - это больше байт-код, чем язык ассемблера. В частности, это не текстовая форма, удобочитаемая человеком, в отличие от языков ассемблера (вероятно, CIL также определяет формат файлов байт-кода).
MSIL JIT - это реализация виртуальной машины для этого байт-кода. То, как реализации (от Microsoft или Mono) переводят CIL в машинный код, является деталью реализации, которая на самом деле не имеет значения для вы (и учитывая, что виртуальная машина Microsoft, вероятно, проприетарная, то не скажу вам, как это делается). Я думаю, что Mono - бесплатная программная реализация CIL- использует LLVM, поэтому, вероятно, не переводите каждый байт-код за раз. но, вероятно, целые методы или функции.
