Мы знаем, что Common Intermediate Language (CIL) или (MSIL) является объектно-ориентированным языком ассемблера
.
Является ли CIL языком ассемблера и JIT ассемблером
Но компилятор Just In Time (JIT) действительно сопоставляет каждую из этих инструкций с базовым процессором opcodes?
И если так мы можем назвать CIL язык ассемблера и JIT ассемблер
Примечание: Википедия не список CIL как язык ассемблера в его list of assembly languages
Нет, вы не можете назвать CIL языком ассемблера. Сборка состоит из мнемоники для инструкций машинного кода конкретного процессора. Прямое представление 1s и 0s, которые делают код ядра исполняемым, но написаны в тексте, чтобы сделать его легким для человека. Что очень в отличие от КСС:
Эта последняя пуля является ключевой, конструктивное решение, которое делает CIL сильно отличающимся от байт-кода, заключается в том, что инструкции CIL не имеют типа. Существует только одна команда ADD, но у процессоров много версий. Конкретные, которые принимают байтовые, короткие, int, long, float и double операнды. Требуется, потому что различные части ядра процессора используются для выполнения добавления. Джиттер выбирает правильный, основываясь на типе операндов, которые он выводит из предыдущих инструкций CIL.
Как и оператор + на языке C#, он также может работать с различными операндами. Что действительно делает L в CIL значительным, это язык. Простой, но это просто, чтобы облегчить запись дрожания для него.
Почему имеет значение, что существует физический процессор? Что делать, если кто-то сделает физический процессор для байт-кода CIL в будущем, вдруг это сделает CIL языком ассемблера? Кроме того, означает ли это, что [MIXAL] (http://en.wikipedia.org/wiki/MIX) не является языком ассемблера? – svick
Такая игра «что если» не очень продуктивна. Факт в том, что такого процессора нет, последняя часть моего ответа указала на вероятную причину, почему у нас ее еще нет. Даже Java не существует, Jazelle не выполняет все байтовые коды. Я пообещаю, что как только у меня появится одна в моей машине, которая позволяет мне отправлять сообщения в SO, я буду использовать ее для редактирования этого ответа. Может случиться, посмотрим, что производит Мидори. –
Могу сказать, что определение, основанное на существовании какого-то определенного аппаратного обеспечения, глупо. Специфическое оборудование не создает язык ассемблера, а механика его компиляции. – svick
КСС является больше bytecode чем язык ассемблера. В частности, это не текстовая удобочитаемая форма, в отличие от ассемблерных языков (возможно, CIL также определяет формат файлов байт-кода).
MSIL JIT представляет собой реализацию virtual machine для этого байт-кода. Как реализация (от Microsoft или от Mono) переводит CIL в машинный код - это деталь реализации, которая не имеет для вас никакого значения (и учитывая, что Microsoft VM, вероятно, является собственностью, а затем не расскажет вам, как это делается). Я думаю, что в Mono -a бесплатное программное обеспечение CIL- используется LLVM, поэтому, вероятно, не переводить каждый байт-код за один раз, а, вероятно, целые методы или функции.
CIL также имеет удобочитаемую форму. – svick
bytecode - это физическое представление или «скомпилированная» версия CIL. CIL не байт-код. –
Этот вопрос касается определений, поэтому давайте определим термины должным образом. Во-первых, assembly language:
Ассемблер является языком программирования низкого уровня для компьютеров, микропроцессоров, микроконтроллеров и других программируемых устройств, в которых каждое заявление соответствует одной инструкции на машинном языке. Язык ассемблера специфичен для определенной архитектуры компьютера, в отличие от большинства языков программирования высокого уровня, которые обычно переносятся на несколько систем.
Теперь CIL:
Common Intermediate Language является читаемый человеком языка программирования низшего уровня определяется Common Language Infrastructure (CLI) спецификации и используется в .NET Framework и Mono. Языки, ориентированные на CLI-совместимую среду выполнения, компилируются в CIL, который собирается в объектный код, который имеет формат в стиле байт-кода.
Хорошо, эта часть технически не правильно: например, C# компилятор компилирует непосредственно в байткод, он не проходит через КСС (читаемый человеком языка), но теоретически, мы можем представить себе, что то, что происходит.
С этими двумя определениями CIL является языком ассемблера, поскольку каждый его оператор скомпилирован до одной инструкции байткода. Тот факт, что нет физического компьютера, который может выполнить этот байт-код напрямую, не имеет значения.
В определении говорится, что каждый ассемблерный язык «специфичен для определенной архитектуры компьютера». В этом случае архитектура представляет собой виртуальную машину CLR.
О JIT: JIT-компилятор не может считаться ассемблером: он не выполняет перевод 1: 1 из удобочитаемой формы в байт-код, ilasm делает это.
Виртуальные машины выполняют компиляцию JIT по конкретным машинным инструкциям (x86, x64, ia64 и т. Д.). –
@PeterRitchie Да, так? – svick
Часть вопроса OPs спросила о JIT. –
Линия на самом деле довольно размыта ... аргументы, которые я видел против вызова CIL, «язык ассемблера» может применяться практически так же, как на практике: x86/x86-64.
Intel и AMD не сделали процессоры, которые выполняют инструкции по сборке точно так же, как и в течение десятилетий (если вообще когда-либо), поэтому даже так называемый «собственный» код мало чем отличается от работы на виртуальной машине, байт-код которой указан в x86/x86-64.
x86/x86-64 являются вещи низшего уровня типичные разработчики имеют доступ, так что, если мы должны были поставить нашу ногу вниз и вызвать что-то в нашей экосистеме «ассемблере», что бы выиграть, и с тех пор CIL байткод в конечном счете, требует x86/x86-64 Инструкции для работы на процессоре в этом семействе, тогда есть довольно сильный случай, который нужно сделать, чтобы он действительно не «чувствовал», как он должен рассчитывать.
So в некотором смысле, может быть, ни один из них не может считаться «языком ассемблера». Когда речь идет о процессорах x86/x86-64, мы почти никогда не обращаемся к процессорам, которые выполняют x86/x86-64, не переводя его на что-то другое (то есть, что бы ни делал микрокод).
Чтобы добавить еще одну морщину, способ, которым процессор x86/x86-64 выполняет заданную последовательность инструкций, может быть изменен просто путем обновления микрокода. Быстрый поиск показывает, что Linux может даже упростить это сделать in software!
Так что я думаю, вот критерии, которые могут оправдать положить их в две отдельные категории:
CIL байткод реализованы в программном обеспечении?x86/x86-64 инструкциями по-другому после получения инструкций по этому поводу в программном обеспечении?x86/x86-64 процессоров?Так касательно «является CIL собрание language` вопрос, лучшие ответы, которые я могу дать это„зависит“(для ученых) и„довольно много“(для инженеров).
интересный вопрос, я попробовал ответить, но это не так просто. Я думаю, что вы не можете считать его ассемблером, так как tehre не является реальным процессором, запускающим его напрямую. –
@FelicePollano, тогда CIL может быть частичным ассемблером .. :) – Anirudha
Абонентский язык мнемосхемы соответствуют 1: 1 с инструкциями машинного кода с конкретным процессором. Ассемблер просто сопоставляет (sorta) код, читаемый человеком, с этими инструкциями. Это определенно не относится к CIL. Это не частично, это просто не - сборка возраст имеет очень четкое определение. –