Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> А вот CLI в .Net Native не работает в песочнице. S>Ну о чём я и говорил — не надо натягивать термины, которые относятся к абстрактному описанию "как работает дотнет" на конкретную реализацию. Полный бред получается.
Для компиляции в .Net Native это язык. Ибо термины не компилируются S>CLI — это спецификация. Она не может "работать / не работать". Она или соблюдается, или не соблюдается. Как именно соблюдается: силами рантайма, компилятора или расстрелом нерадивых программистов — эт уже дело десятое и к самой спецификации никакого отношения не имеет.
А что тогда компилирует Jit или компилятор .Net Native?
В чем разница CLI от C#? Кстати первый прекрасно декомпилируется во второй.
Common Intermediate Language (сокращённо CIL) — «высокоуровневый ассемблер» виртуальной машины .NET. Промежуточный язык, разработанный фирмой «Microsoft» для платформы .NET Framework. JIT-компилятор CIL является частью CLR (англ. common language runtime) — общей среды выполнения программ, написанных на языках .NET. Ранее язык назывался «Microsoft Intermediate Language (MSIL)», однако был переименован для создания стандарта «ECMA-335».
Все компиляторы, поддерживающие платформу .NET, должны транслировать код с языков высокого уровня платформы .NET на язык CIL. В частности, код на языке CIL генерируют все компиляторы .NET фирмы «Microsoft», входящие в среду разработки «Microsoft Visual Studio» (C#, Managed C++, Visual Basic .NET, Visual J# .NET).
По синтаксису и мнемонике язык CIL напоминает язык ассемблера. Его можно рассматривать как ассемблер виртуальной машины .NET. В то же время язык CIL содержит некоторые достаточно высокоуровневые конструкции, повышающие его уровень по сравнению с ассемблером для любой реально существующей машины, и писать код непосредственно на CIL легче, чем на ассемблере для реальных машин. Поэтому CIL можно рассматривать как своеобразный «высокоуровневый ассемблер».
Язык CIL также нередко называют просто IL от англ. intermediate language — буквально «промежуточный язык».
Синтаксис и мнемоника языка CIL описываются стандартом «ECMA-335». Спецификация CIL является составной частью более общей спецификации — спецификации CLI (англ. common language infrastructure).
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> А вот CLI в .Net Native не работает в песочнице. S> Для компиляции в .Net Native это язык. Ибо термины не компилируются CLI == Common Language Infrastructure, какой нафиг язык?
CIL, возможно? Так это просто формат данных и он тож не работает. Работает машинный код, который из него порождён. И до тех пор, пока этот код соблюдает требования спецификации, нам абсолютно пофиг, как это "соблюдает" обеспечивается. Именно поэтому в CLI соответствующая часть обозвана VES (Virtual Execution System) — нас интересует только соблюдение контракта, прописанного в требованиях к среде исполнения, но не конкретная реализация.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>> А вот CLI в .Net Native не работает в песочнице. S>> Для компиляции в .Net Native это язык. Ибо термины не компилируются S>CLI == Common Language Infrastructure, какой нафиг язык?
S>CIL, возможно? Так это просто формат данных и он тож не работает. Работает машинный код, который из него порождён. И до тех пор, пока этот код соблюдает требования спецификации, нам абсолютно пофиг, как это "соблюдает" обеспечивается. Именно поэтому в CLI соответствующая часть обозвана VES (Virtual Execution System) — нас интересует только соблюдение контракта, прописанного в требованиях к среде исполнения, но не конкретная реализация.
То есть машинный код берется из формата?
Кстати насчет интерпретаторов
2 Интерпретатор — читает текст программы как есть и выполняет инструкцию (для c, c++, perl, ... есть интерпретатор)
например bash тоже интерпретатор не переводит даже в машинный код, или tcsh — этот shel тоже является
интерпретатором но "C" языка. Первые движки javascrip тоже являлись только интерпретатором. Конечно теперь у javascrip есть виртуальная машина и компилятор.
У Perl есть и интерпретатор и виртуальная машина и даже может компилить в нативные инструкции процессора (машинный код). Хотя когда запускаете perl script то идет компиляция на лету в байт код и потом виртуальная машина PERL исполняет этот код.
3 компилятор преобразует исходный текст программы в машинный код или в код виртуальный
машины (по другому абстрактной как раз этот код потом исполняется виртуальной машиной например Java, perl, Lua, .Net, ...)
как понимаешь виртуальная машина не абстрактное понятие а конкретное приложение и исполняет конкретный байт код
который сформировал соответствующий конкретный компилятор из конкретного языка программирования
Виртуальная машина исполняет некоторый машинно-независимый код (например, байт-код, шитый код, p-код) или машинный код реального процессора. Помимо процессора, ВМ может эмулировать работу как отдельных компонентов аппаратного обеспечения, так и целого реального компьютера (включая BIOS, оперативную память, жёсткий диск и другие периферийные устройства). В последнем случае в ВМ, как и на реальный компьютер, можно устанавливать операционные системы (например, Windows можно запускать в виртуальной машине под Linux или наоборот). На одном компьютере может функционировать несколько виртуальных машин (это может использоваться для имитации нескольких серверов на одном реальном сервере с целью оптимизации использования ресурсов сервера).
А вот натягивание этого понятия на CLR, да вообще на .Net в целом мало отличается от совы и глобуса.
Java назвала JVM и отсюда все, что связано с байт кодом и сборщиком мусора стали называть VM
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> То есть машинный код берется из формата?
С точки зрения VES — безусловно да. На входе данные в общепринятом формате, на выходе — исполняемый код.
С точки зрения конкретной реализации вместо IL может быть что угодно, от своего диалекта и до генерации RyuJIT IR напрямую из текстовых исходников.
Вы сначала определитесь, какой именно уровень и чего именно мы обсуждаем, затем можно продолжать будет.
Иначе получается очередная попытка натянуть нотный стан на струны рояля. А чо, и там и там музыка, ключи, и ноты и клавиши чорно-белые, да и молоточки на ноты (не)похожи.
Вот как-то так оно выглядит
S> Кстати насчет интерпретаторов S> А вот натягивание этого понятия на CLR, да вообще на .Net в целом мало отличается от совы и глобуса. S> Java назвала JVM и отсюда все, что связано с байт кодом и сборщиком мусора стали называть VM
Ну да, не надо смешивать описание реализаций в разных языках. В каждом из сложилась своя терминология и трактовка понятий "VM" в питоне и в яве пересекаются весьма слабо. Особенно если учесть, что вариантов питона штук двадцать, на любой вкус.
Тынц как пример.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> То есть машинный код берется из формата?
S>С точки зрения VES — безусловно да. На входе данные в общепринятом формате, на выходе — исполняемый код.
Данные в общепринятом формате это что?
Почему этот формат легко декомпилировать в C# или Delphi.Net?
S>С точки зрения конкретной реализации вместо IL может быть что угодно, от своего диалекта и до генерации RyuJIT IR напрямую из текстовых исходников.
То есть это язык который компилируется в машинные коды?
Кстати
RyuJIT provides the just in time compilation service for the .NET runtime.
The runtime itself is variously called the EE (execution engine), the VM (virtual machine) or simply the CLR (common language runtime).
Depending upon the configuration, the EE and JIT may reside in the same or different executable files. RyuJIT implements the JIT side of the JIT/EE interfaces:
S>Вы сначала определитесь, какой именно уровень и чего именно мы обсуждаем, затем можно продолжать будет. S>Иначе получается очередная попытка натянуть нотный стан на струны рояля. А чо, и там и там музыка, ключи, и ноты и клавиши чорно-белые, да и молоточки на ноты (не)похожи. S>Вот как-то так оно выглядит
Ну дык мы говрим о натягивании понятия VM на все, что имеет байт код.
Например по твоему CIL это не байт код.
S>> Кстати насчет интерпретаторов S>> А вот натягивание этого понятия на CLR, да вообще на .Net в целом мало отличается от совы и глобуса. S>> Java назвала JVM и отсюда все, что связано с байт кодом и сборщиком мусора стали называть VM
S>Ну да, не надо смешивать описание реализаций в разных языках. В каждом из сложилась своя терминология и трактовка понятий "VM" в питоне и в яве пересекаются весьма слабо. Особенно если учесть, что вариантов питона штук двадцать, на любой вкус. S>Тынц как пример.
Во правильно. Но в .Net как то не прижилось понятие VM.
Я вообще упомянул, то что в интерпретаторах часто используется предварительная компиляция в байт код. А различие Питона и Явы без JIT только в статической типизации и сборке мусора.
При этом напомню что изначально в JVM не было JIT
Является ли AST VM?
Кстати пропустил статью https://habrahabr.ru/company/pt/blog/210060/
Надо почитать
Здравствуйте, Serginio1, Вы писали:
S>>С точки зрения VES — безусловно да. На входе данные в общепринятом формате, на выходе — исполняемый код. S> Данные в общепринятом формате это что?
ECMA-335 Partition III: CIL Instruction Set.
S> Почему этот формат легко декомпилировать в C# или Delphi.Net?
Коротко: везение.
Подробней: по двум причинам:
* из бинарного представления восстановить il не сложнее, чем набросать простенький дизассемблер.
* до недавнего времени конструкции шарпа легко и однозначно сопоставлялись с последовательностями в il.
Но начиная с третьего шарпа всё больше логики декомпиляторов — это эвристики, которые легко ломаются на обновлениях компилятора или при использовании il-реврайтеров. Халява кончилась.
S>>и до генерации RyuJIT IR напрямую из текстовых исходников. S> То есть это язык который компилируется в машинные коды?
UPD: вопрос про RyuJIT IR? Если да — Это вообще не язык, это ещё одно представление потока инструкций (по аналогии с gcc ir или llvm ir), заточено под быстрые оптимизации и лёгкую трансляцию в бинарный код.
Тем не менее даже такой изврат наотлично будет работать с остальным managed-кодом, чем с незапамятных времён пользовались отдельные извращенцы (см секцию Native Injection).
Если нет и вопрос про IL — см выше
С CIL вечно путаница — под ним понимают и CIL bytecode и CIL как язык, из контекста обычно понятно
для преобразования в бинарный код сам язык, очевидно, не нужен.
S>>Вы сначала определитесь, какой именно уровень и чего именно мы обсуждаем, затем можно продолжать будет. S> Ну дык мы говрим о натягивании понятия VM на все, что имеет байт код.
А, бесполезное это дело. Нужно ещё знать контекст, в котором обсуждаем. Иначе под VM кучу разных вещей c разных логических уровней набивается. Про что и писал выше
Если говорить про CLI как про абстрактную модель, то там VM разумеется присутствует, но когда дело доходит до готовых бинарников, то вся роль "VM" сводится к набору runtime services. Конкретный их состав зависит от таргетинга.
S> Например по твоему CIL это не байт код.
Так CIL или CLI? разные ж вещи
Если CIL — тыкни носом, где я это писал плиз.
Здравствуйте, Sinix, Вы писали:
S>> Например по твоему CIL это не байт код. S>Так CIL или CLI? разные ж вещи S>Если CIL — тыкни носом, где я это писал плиз.
Прошу прощения спутал
Кстати ассемблер то по сути представление потока инструкций
Помню еще в 80 х компилятои Пакскаля сначла переводил в ассемблер, потом obj затем в Exe
и солнце б утром не вставало, когда бы не было меня
S>Виртуальная машина исполняет некоторый машинно-независимый код (например, байт-код, шитый код, p-код) или машинный код реального процессора. Помимо процессора, ВМ может эмулировать работу как отдельных компонентов аппаратного обеспечения, так и целого реального компьютера (включая BIOS, оперативную память, жёсткий диск и другие периферийные устройства). В последнем случае в ВМ, как и на реальный компьютер, можно устанавливать операционные системы (например, Windows можно запускать в виртуальной машине под Linux или наоборот). На одном компьютере может функционировать несколько виртуальных машин (это может использоваться для имитации нескольких серверов на одном реальном сервере с целью оптимизации использования ресурсов сервера).
На вики с произошел перегруз термина "виртуальная машина".
То что писал раннее прочтите внимательно. S>[g]Помимо процессора, ВМ может эмулировать работу как отдельных компонентов аппаратного обеспечения, так и целого реального компьютера S>[/g]
там же четко написали что помимо виртуальной машины есть ЭМУЛЯТОР.
Роль Эмулятора заключается в замене реальной СТРУКТУРЫ (процессор, видео, периферия) на программную или электронную
Я не могу точно привести данные кто и когда применял эмуляцию. Но уже когда стали проектировать процессор 8086
стали создавать эмуляторы. Для чего делали Эти эмуляторы.
Прочтите внимательно
Когда начинают производство нового процессора то заказчики или координаты групп создают спецификацию этого
процессора в том числе и на команды.
Далее это спецификация поступает на отдел электронщиков и отдел программистов.
Конечно каждый из отделов особенно электронщики вносит некоторые изменения
Но самое главное программисты начинают создавать эмулятор этого процессора, этот эмулятор нужен
для того чтоб программисты могли уже писать OS и программы для не существующей системы.
И к моменту выпуска процессора уже будет готова все программное обеспечение.
Но эмулятором может быть не только программа но и электроника программируемая например ПЛМ-
программируемая логическая матрица
У многих тут обсуждающих нет полного понимания терминалогий
Частенько в качестве эмуляторов выступают программы которые могут эмулировать какие либо процессоры,
тогда можно установить на эти эмулируемы процессоры все программы которые для него написаны
но кроме процессора этот эмулятор может подключать эмуляторы внешних устройств.
но бывают ситуации когда программа эмулирует устройство например. Например CISCO предлогает
эмуляторы маршрутизаторов для учебных заведений. Это позволяет проводит обучение не имея реального
оборудования который может стоить до 200000$ и даже более.
Есть емулятор и берете бинарный образ OS CISCO и запускаете — получаете маршрутизатор (но виртуальный)
Когда вы запускаете виртуальную машину надо понимать что есть разные виртуальные машины
Все подробности расписывать нет смысла прочтете в инете но основные моменты отмечу
1 Две OS запускается паралельно через гипервизор он переключает процессор
между разными OS. Как понимаете процессор имее 4 уровня защиты (или контекста исполнения)
обычно Linux ядро и модули работают на зищищенном уровне 3 а пользовательские на уровне 4
также работают и другие OS
но первые два уровня свободны поэтому можно запустить гипервизор каторый будет переключать
OS-ы
2 вид. когда внутри OS созадется среда т.е. специальная программа которая будет предлогать
по внешнему виду пвседо среду на сомом деле использует все библиотеки основной OS и в том числе
оборудование через обычные системные вызовы.
3 вид. Когда программа создает виртуальную среду в том числе и биос и аппаратную среду и исполнение
происходит в контексте основной OS.
При этом программы выполняются на процессоре как есть, а доступ к оборудованю идет через запросы
из гостевой ос в ОСНОВНУЮ, но так как гостевая эмулирeет периферию то идет захват запросов(на оборудование)
гостевой ОС и виртуальная машина преобразует и делает бращение к ОСНОВНОЙ ОС.
Как видим в реальности все они являются эмуляторами но эмуляторами разного уровня
1 выриант это не эмулятор а виртуальная машина (но виртуализация на уровне процессорпа) т.к. разные OS имеют полноправный доступ к процессору,
и каждый из OS считает что имеет монопольный доступ, но процессор хитрый и обманывает все OS которые на нем работают.
Также есть оборудование которое также как и процессор предлагает виртуальную услугу серверные сетевые платы intel.
Кстати иногда эти опции можно увидеть в биосе (по поводу виртуального оборудования).
2 вариант тоже витруальная машина но при этом гостевая ос как зеркало совпадает с основной.
чаще всего такую услугу предлагают датацентрах т.к. меньше использует вычислительных мощностей ЦП
3 вариат является виртуальной машиной + эмулятором т.к. эмулирует периферию процессора(внешниие устройства).
к ТЕРМИНАМ язык программирования, интерпретатор, компилятор, среда исполнения, байт код, виртуальная машина
надо добавить
трансляцию, песочницу, дебагеры, КОНТЕЙНЕРЫ.
Текст длинный получился.
Попробую чуть позже написать про все эти термины и где лежит граница между терминами
Замечу что в браузере для javascript работает не виртуальная машина а контейнер.
Что CLR эмулирует? Он просто компилирует код. Там никакого понятия эмуляции не существут.
Прочитал. Где в CLR какая либо замена? CIL это язык, аналог ассемблера.
Опять же байт код выполняет не только Java, но и на питон и 1С и еще куча интерпритаторов. Если убрать JIT,
то по сути они тоже VM? Отличие от Java только в статической типизации и сборщике мусора.
трехадресный код это тоже VM
Так объясни мне где в .Net эмуляция, Весь код перед выполнением компилируется.
Ты так и не ответил про NGEN, Net Native.
Вот это и есть виртуальные машины, который выполняет код предназначенный для других Осей,процессоров.
В VS полно таких эмуляторо и бот они как раз и являются VM.
При этом код компилируется под определенную ось и процессор.
T>к ТЕРМИНАМ язык программирования, интерпретатор, компилятор, среда исполнения, байт код, виртуальная машина T>надо добавить T>трансляцию, песочницу, дебагеры, КОНТЕЙНЕРЫ.
Вот CLR это как раз среда выполнения, но в ней никакой эмуляции не происходит. Все компилируется в машинный код.
Эмуляция происходит только в Hyper-V T>Текст длинный получился. T>Попробую чуть позже написать про все эти термины и где лежит граница между терминами
T>Замечу что в браузере для javascript работает не виртуальная машина а контейнер.
А в чем различие? Уже есть WebAssembly по твоей териналогии тот же байт код.
WebAssembly определяет абстрактное синтаксическое дерево(AST), которое хранится в бинарном формате. Бинарность это здорово, так как позволяет создавать меньшие приложения. Наверняка вы задаетесь вопросом, как можно отлаживать бинарный код.
В: Почему бы не использовать JVM?
О: Попытки добавить JVM в браузеры с помощью плагинов были и не раз. К сожалению, ничего хорошего из этого не вышло. В JavaScript есть встроенная виртуальная машина, поэтому добавление еще одной приводит к появлению второго набора API подключений, чтобы дать виртуальной машине доступ к DOM, сетям, сенсорам, устройствам ввода и т.п. За это придется кое чем пожертвовать. Например, как будут процессы в виртуальной машине распределять между собой имеющиеся ресурсы? Ответить на этот вопрос сложнее, чем кажется.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, tranzit, Вы писали:
S> Что CLR эмулирует? Он просто компилирует код. Там никакого понятия эмуляции не существут.
.. S> Так объясни мне где в .Net эмуляция, Весь код перед выполнением компилируется.
.. S> Вот это и есть виртуальные машины, который выполняет код предназначенный для других Осей,процессоров. S> В VS полно таких эмуляторо и бот они как раз и являются VM. S> При этом код компилируется под определенную ось и процессор.
.. S> Вот CLR это как раз среда выполнения, но в ней никакой эмуляции не происходит. Все компилируется в машинный код.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, tranzit, Вы писали:
S> Что CLR эмулирует? Он просто компилирует код. Там никакого понятия эмуляции не существут.
CLR не компилирует ничего это среда исполнения для байт кода. т.е. эта среда содержит
виртуальную машину и вспомогательные утилиты и функции.
CLR не компилирует а исполняет байт код
S> Прочитал. Где в CLR какая либо замена? CIL это язык, аналог ассемблера. S>Опять же байт код выполняет не только Java, но и на питон и 1С и еще куча интерпритаторов. Если убрать JIT, S>то по сути они тоже VM? Отличие от Java только в статической типизации и сборщике мусора. S> трехадресный код это тоже VM
Совершенно верно любой байт код (код исполнения) является инструкцией машины следовательно кто-то должен исполнить
эту инструкцию но напрямую процессор не понимает, поэтому исполнение этой инструкции берет на себя виртуальная машина.
для каждого языка есть стандарт, так же как и стандарт для кода который получается путем компиляции.
Но нигде не говорится как должны компилироваться текст программы в код, ГЛАВНОЕ чтоб этот код был понимаем виртуальной машиной или процессором. Поэтому одни производители компиляторов лучше других т.к. генерируют код более оптимально.
Если этот код получен путем компиляции из языка java то и байт код может выполняться на виртуальной машине java.
если код был получен из .Net далее применен транслятор на язык CLI/CIL а к нему применили компилятор ilasm для получения байт кода CIL который будет исполняться в среде CLR который и содержит виртуальную машину CLR.
Если питон-то питон виртуальная машина исполняет байт код. Если Perl то виртуальная машина PERL исполняет
байт код. Если язык Erlang то компиляция erlang(в байт код) то виртуальная машина ERLANG выполняет этот код. Но нам все равно как CLR виртуальная машина будет выполнять этот код. Если хочет то пускай вызывает JIT для ускорения исполнения или сами запускайте ngen для компиляции из байт кода в машинный.
ТОЛЬКО не путайте CLR как среду исполнения (который может предлагать массу дополнительных утилит в том числе глубокую интеграцию с OS или с внешними библиотеками dll) и CLR как виртуальную машину которая исполняет CIL байт код.
Виртуальная машина CLR содержится в сред исполнения CLR и она для вас прозрачно т.к. вы взаимодействуете со средой
а не напрямую на виртуальную машину.
Но надо понимать различие между средой исполнения и контейнером, об этом чуть позже.
Я это говорю из-за того что CLR среда очень сильно подошла к понятию контейнер.
из WIKI
Common Language Runtime (англ. CLR — общеязыковая исполняющая среда) — исполняющая среда для байт-кода CIL (MSIL), в который компилируются программы, написанные на .NET-совместимых языках программирования (C#, Managed C++, Visual Basic .NET, F# и прочие). CLR является одним из основных компонентов пакета Microsoft .NET Framework.
В отличие от переносимых виртуальных машин Java, абстрагирующихся от нижележащих операционных систем, CLR позиционируется как не «виртуализированная» платформа, тесно связанная с операционной системой Microsoft Windows (в том числе для целей сохранения инвестиций Microsoft в операционную систему)[1]
Среда CLR является реализацией спецификации CLI (англ. Common Language Infrastructure), спецификации общеязыковой инфраструктуры компании Microsoft.
из WIKI
Common Intermediate Language (сокращённо CIL) — «высокоуровневый ассемблер» виртуальной машины .NET. Промежуточный язык, разработанный фирмой «Microsoft» для платформы .NET Framework.
как понимаем виртуальной машины .NET-не существует т.к. из языка .Net идет трансляция на язык CLI/CIL и потом компиляция в CIL байт код (а можно и напрямую в CIL байт код). следовательно виртуальная машина не .NET а CLR.
"Assembler" компилятор для языка CLI/CIL называется ilasm а на выходе CIL байт код. есть disassembler для CIL посмотрите проект mono.
ОБратите внимание мы говорим об assemblere который из текста программы на языке CLI/CIL(assembler) делает байт код CIL для виртуальной машины CLR
Читать инфу надо задумываясь.
Вы рассматриваете строго один из возможных вариантов исключая остальные
Давайте еще раз рассмотрим весь процесс.
Вы создаете программу на языке который имеет определенную структуры. Вы не можете произвольные инструкции
писать в тексте этой программы а должны придерживаться семантики и семантических структур.
Чаще всего языки программирования стандартизованы т.е. есть комитеты и масса людей которые принимают решения
о вводе новых или удалении старых семантических структур. Так рождается спецификация на язык программирования. Долгое время javascript, perl, и др. языки не были приняты международным комитетом
Далее производители процессоров создают свои компиляторы в первую очередь ассемблеры. и часто С/C++
эти компиляторы формируют код из ТЕКСТА программы в КОД машины. Процесс этот не регламентируется
главное требование чтоб код был исполняемым на процессоре и был как можно оптимален т.е. чтоб
выполнял как можно более передовые и оптимальные инструкции машины для увеличения производительности
например для x86_64 можно выполнять как одиночные команды сложения умножения так и для sse4 который
манипулирует 256bit регистрами и одна инструкция выполняет сразу действия над 4Хarg1 + 4xarg2 = 4 числа
для sse5 уже регистры имеют размер 512 бит и одна команда манипулирует уде 8 числами double float
производительность возврастает но только при условии что эти инструкции будут задействованы компилятором
Аналогично и с компиляторами байт кода, но байт код пока не меняется и виртуальная машина тоже
но виртуальная машина может выполнять инструкции байт кода как от своего имени и при этом задействует
новы возможности процессора или же может вызвать jit компиляцию. Но нам все равно как будет выполняться
эти виртуальные коды. Главное что мы может взять эти виртуальные коды и перенести на другую машину
и даже на машину с другой платформой(CPU+OS) и этот код должен выполняться.
CIL код должен так же исполняться на виртуальной машине CLR. Но проблема в Microsoft они не хотят
чтобы их клиенты которые покупают IDE уходили на другие платформы т.к. потеряют доход.
Т.к. сегодня opensource предлагает CLR среду https://habrahabr.ru/post/243065/ https://github.com/dotnet/core https://en.wikipedia.org/wiki/Mono_%28software%29
Не забываете что CLR был регламентирован как машинно независимый код.
Давайте теперь рассмотрим варианты компиляции
их очень много. Но сначала для Perl
1
после того как вы записали текст программы можно его выполнить
perl example.pl — в этом случает perl выступает как интерпретатор, но есть одно но. Дело в в том
что на лету perl формирует байт код в памяти (т.е. компиляция) и только потом ее исполняет.
но нам не интересно как выполняет perl текст написанный на языке perl, главное что мы передаем текст,
а perl интерпретатор выдает результат.
2
можно текст программы на perl скомпилировать в PERL байт код, например так
perl -MO=Bytecode,-H,-oexample.bl example.pl
в результате мы имеем PERL байт код и находится в файле example.bl
и если мы выполним инструкцию
perl example.bl — то perl программа уже выступает в роли PERL виртуальной машины которая исполняет PERL byte code
3
теперь попробуем выполнить следующую инструкцию perlcc (устанавливается отдельно)
perlcc -o example example.pl
perlcc скомпилирует example.pl в исполнимый файл на машинном коде
тогда ./example становится самоcтоятельным приложением и уже с perl никак не связан
4
мы можем выполнить следующую инструкцию
perlcc -c example.pl
на выходе будем иметь example.c и опять никак не связан уже с perl, данная
процедура называется трансляцией
5
если выполнить perljvm то получим из perl текста программы байт код для java виртуальной машины
и этот код надо будет выполнять уже на JAVA виртуальной машине а не PERL виртуальной машине
можно продолжать и далее, очень гибкий инструмент
Тоже самое можно делать и с "с/c++"
ну и чтоб совсем было весело с компиляторами можно рассмотреть gcc в качестве кросс компилятора
опции --build=x86_64 --host=sparc-sun-solaris2.10 --target=arm позволяют скомпилировать gcc на текущем компьютере например на x86_64 для sparc машины (т.е. программа gcc будет выполняться на spark) а компиляцию делать
для arm процессора
все это я привел для того чтобы было четкое понимание где текст программы, интерпретатор, виртуальная машина, транслятор
Теперь разберем .Net
перевод из одного языка в другой называется трансляцией
на самом деле можно трансляцию делать из одного языка в другой или из байт кода java в другой байт код
или из одного процессорного кода (бинарный уровень) в другой машинный код совершенно другого процессора.
например С текст программы можно преобразовать в assembler-ный текст программы
gcc -S -o exemple.s example.c
из машинного кода в другой машинный код objdump
или из перл в С
точно также .Net может сделать трансляцию на CLI/CIL(язык ассемблера)
далее применяя команду ilasm текст программы на assembler CIL в объектный код CIL
этот объектный код может выполнить CLR виртуальная машина возможно даже он применит
jit компиляцию (https://ru.wikipedia.org/wiki/JIT-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F)
прочтите доконца
Мы имеем CIL код(не путать с текстом на assembler CIL) но мы можем применить для этого кода команду
ngen для получения машинного кода. https://en.wikipedia.org/wiki/Native_Image_Generator https://ru.wikipedia.org/wiki/Ngen
но не забываем что можно сразу компилировать из любого языка CLI (https://en.wikipedia.org/wiki/List_of_CLI_languages) в CIL код
Также можно компилировать сразу в машинный код
ngen может компилировать и из текста программы на CIL assembler в машинный код
S> Так объясни мне где в .Net эмуляция, Весь код перед выполнением компилируется. S>Ты так и не ответил про NGEN, Net Native.
надеюсь ответил
S> Вот это и есть виртуальные машины, который выполняет код предназначенный для других Осей,процессоров. S> В VS полно таких эмуляторо и бот они как раз и являются VM. S> При этом код компилируется под определенную ось и процессор.
T>>к ТЕРМИНАМ язык программирования, интерпретатор, компилятор, среда исполнения, байт код, виртуальная машина T>>надо добавить T>>трансляцию, песочницу, дебагеры, КОНТЕЙНЕРЫ.
S> Вот CLR это как раз среда выполнения, но в ней никакой эмуляции не происходит. Все компилируется в машинный код.
да CLR есть виртуальная машина и нам не интересно что применяет jit компиляцию S>Эмуляция происходит только в Hyper-V T>>Текст длинный получился. T>>Попробую чуть позже написать про все эти термины и где лежит граница между терминами
T>>Замечу что в браузере для javascript работает не виртуальная машина а контейнере S> А в чем различие? Уже есть WebAssembly по твоей териналогии тот же байт код.
Совершенно верно это байт код и для выполнения нужна виртуальная машина WebAssembly который может применить jit компиляцию
некоторые люди уже попробовали запустить, сам пока не компилил https://habrahabr.ru/company/infopulse/blog/304362/
S>
S>WebAssembly определяет абстрактное синтаксическое дерево(AST), которое хранится в бинарном формате. Бинарность это здорово, так как позволяет создавать меньшие приложения. Наверняка вы задаетесь вопросом, как можно отлаживать бинарный код.
S>В: Почему бы не использовать JVM?
S> О: Попытки добавить JVM в браузеры с помощью плагинов были и не раз. К сожалению, ничего хорошего из этого не вышло. В JavaScript есть встроенная виртуальная машина, поэтому добавление еще одной приводит к появлению второго набора API подключений, чтобы дать виртуальной машине доступ к DOM, сетям, сенсорам, устройствам ввода и т.п. За это придется кое чем пожертвовать. Например, как будут процессы в виртуальной машине распределять между собой имеющиеся ресурсы? Ответить на этот вопрос сложнее, чем кажется.
Для javascript уже давно делают контейнер(а не встроенная виртуальная машина) который содержит javascript виртуальную машину и jit
Здравствуйте, tranzit, Вы писали:
S>>Здравствуйте, tranzit, Вы писали:
...
Всё ок, но я бы сделал оговорку, что это всё с точки зрения разработки под абстрактную CLI-совместимую реализацию дотнета.
Когда дело доходит до _конкретной_ реализации на _конкретной_ платформе, то имеем классический "В теории, между теорией и практикой разницы нет. На практике — упс".
Скажем, компиляторы не вызывают Ilasm и вот это
но виртуальная машина может выполнять инструкции байт кода как от своего имени и при этом задействует
новы возможности процессора или же может вызвать jit компиляцию.
для любого девелопера под дотнет не вызовет никакой реакции кроме как "да ладно?". Не, _теоретически_ никто не запрещает писать под netmf скажем, где JIT-а на сегодня нет вообще, но на практике — сколько разработчиков этим занимаются?
Здравствуйте, pilgrim_, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, tranzit, Вы писали:
S>> Что CLR эмулирует? Он просто компилирует код. Там никакого понятия эмуляции не существут. _>.. S>> Так объясни мне где в .Net эмуляция, Весь код перед выполнением компилируется. _>.. S>> Вот это и есть виртуальные машины, который выполняет код предназначенный для других Осей,процессоров. S>> В VS полно таких эмуляторо и бот они как раз и являются VM. S>> При этом код компилируется под определенную ось и процессор. _>.. S>> Вот CLR это как раз среда выполнения, но в ней никакой эмуляции не происходит. Все компилируется в машинный код.
_>Для кругозора:
_>Например есть вот такой CLR для .NET Micro Framework
_>https://github.com/NETMF/netmf-interpreter
_>Вот тут есть обсуждение по поводу AOT и JIT, + AOT для MSIL -> IR (intermediate represenation) — https://github.com/NETMF/llilum
Спасибо я знаю. Изначально речь шлп про .Net. Когда сказали, что .Net включает в себя .Net Native, то стали говорить, что имели ввиду CLR/
Кстати CLR для микрофреймворка называется TinyCLR
Runtime Component Layer
Этот слой состоит из 3-х компонентов:
• .NET Micro Framework common language runtime (CLR);
• Hardware abstraction layer (HAL);
• Platform abstraction layer (PAL).
CLR
Среда исполнения .NET Micro Framework CLR (TinyCLR) является подмножеством .NET Framework CLR. TinyCLR отличается от «большой» CLR тем, что она была специально переработана для использования в небольших встраиваемых устройствах.
.Net Micro Framework Porting Kit поставляется вместе с исходными кодами TinyCLR. Данные коды представляют собой аппаратно-независимую библиотеку, которая может быть скомпилирована разными компиляторами для разных архитектур.
Здравствуйте, tranzit, Вы писали:
T>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, tranzit, Вы писали:
S>> Что CLR эмулирует? Он просто компилирует код. Там никакого понятия эмуляции не существут. T>CLR не компилирует ничего это среда исполнения для байт кода. т.е. эта среда содержит T>виртуальную машину и вспомогательные утилиты и функции. T>CLR не компилирует а исполняет байт код
То есть JIT компиляция, это не компиляция вовсе?
Еще раз как обстоит дела с NGEN, что выполняет CLR?
Генератор образов в машинном коде (NGEN) компилирует сборки в машинный код и устанавливает их в кэш образов в машинном коде на локальном компьютере. Однако хотя NGEN, как и .NET Native, создает машинный код, NGEN имеет существенные отличия от .NET Native:
• Если для конкретного метода нет образа в машинном коде, NGEN переключается на JIT-компиляцию кода. Это означает, что образы в машинном коде должны продолжать включать метаданные и IL-код для того случая, если генератору NGEN необходимо переключиться на JIT-компиляцию. В противоположность этому .NET Native только создает образы в машинном коде и не переключается на JIT-компиляцию. В результате должны сохраняться метаданные, необходимые только для некоторых сценариев отражения, сериализации и взаимодействия.
• NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
• Образы NGEN, как правило, хрупкие. Например, обновление или изменение зависимости обычно требует, чтобы сборки, которые его используют, также были пересозданы NGEN. Это особенно верно для системных сборок в библиотеке классов .NET Framework. В противоположность этому .NET Native позволяет обслуживать приложения независимо друг от друга.
Читай выделенное. Все компилируется либо сразу либо во время выполнения.
S>> Прочитал. Где в CLR какая либо замена? CIL это язык, аналог ассемблера. S>>Опять же байт код выполняет не только Java, но и на питон и 1С и еще куча интерпритаторов. Если убрать JIT, S>>то по сути они тоже VM? Отличие от Java только в статической типизации и сборщике мусора. S>> трехадресный код это тоже VM
T>Совершенно верно любой байт код (код исполнения) является инструкцией машины следовательно кто-то должен исполнить T>эту инструкцию но напрямую процессор не понимает, поэтому исполнение этой инструкции берет на себя виртуальная машина. T>для каждого языка есть стандарт, так же как и стандарт для кода который получается путем компиляции. T>Но нигде не говорится как должны компилироваться текст программы в код, ГЛАВНОЕ чтоб этот код был понимаем виртуальной машиной или процессором. Поэтому одни производители компиляторов лучше других т.к. генерируют код более оптимально. T>Если этот код получен путем компиляции из языка java то и байт код может выполняться на виртуальной машине java. T>если код был получен из .Net далее применен транслятор на язык CLI/CIL а к нему применили компилятор ilasm для получения байт кода CIL который будет исполняться в среде CLR который и содержит виртуальную машину CLR. T>Если питон-то питон виртуальная машина исполняет байт код. Если Perl то виртуальная машина PERL исполняет
Еще раз NGEN нет там никакого байт кода. Другое дело, что CLR может подгрузить сборку и откомпилировать её например при reflection. Но если нет Рефлексии то и CLR ни какой байткодом не бедет исполнять.
ооооо. Теперь у нас все интерпритаторы стали VM. И трех адресный код это уже VM. Пишем интерпретатор трехадресного кода https://habrahabr.ru/post/117173/
T>байт код. Если язык Erlang то компиляция erlang(в байт код) то виртуальная машина ERLANG выполняет этот код. Но нам все равно как CLR виртуальная машина будет выполнять этот код. Если хочет то пускай вызывает JIT для ускорения исполнения или сами запускайте ngen для компиляции из байт кода в машинный.
То есть assembler это байт код? Тот же LLVM https://ru.wikipedia.org/wiki/Low_Level_Virtual_Machine
В основе LLVM лежит промежуточное представление кода (Intermediate Representation, IR), над которым можно производить трансформации во время компиляции, компоновки и выполнения. Из этого представления генерируется оптимизированный машинный код для целого ряда платформ, как статически, так и динамически (JIT-компиляция). LLVM 3.6 поддерживает статическую генерацию кода для x86, x86-64, ARM, PowerPC, SPARC, MIPS, Qualcomm Hexagon, NVPTX, SystemZ, Xcore. JIT-компиляция (генерация машинного кода во время исполнения) поддержана для архитектур x86, x86_64, PowerPC, MIPS, SystemZ, и частично ARM[4].
То есть статически скомпилированный LLVM или CIL в .Net Native это тоже VM?
T>ТОЛЬКО не путайте CLR как среду исполнения (который может предлагать массу дополнительных утилит в том числе глубокую интеграцию с OS или с внешними библиотеками dll) и CLR как виртуальную машину которая исполняет CIL байт код. T>Виртуальная машина CLR содержится в сред исполнения CLR и она для вас прозрачно т.к. вы взаимодействуете со средой T>а не напрямую на виртуальную машину. T>Но надо понимать различие между средой исполнения и контейнером, об этом чуть позже. T>Я это говорю из-за того что CLR среда очень сильно подошла к понятию контейнер.
Во наконец то. Еще раз CLR это среда выполнения. Она может вообще не иметь дела с CIL.
T>из WIKI
T>Common Language Runtime (англ. CLR — общеязыковая исполняющая среда) — исполняющая среда для байт-кода CIL (MSIL), в который компилируются программы, написанные на .NET-совместимых языках программирования (C#, Managed C++, Visual Basic .NET, F# и прочие). CLR является одним из основных компонентов пакета Microsoft .NET Framework.
T>В отличие от переносимых виртуальных машин Java, абстрагирующихся от нижележащих операционных систем, CLR позиционируется как не «виртуализированная» платформа, тесно связанная с операционной системой Microsoft Windows (в том числе для целей сохранения инвестиций Microsoft в операционную систему)[1]
T>Среда CLR является реализацией спецификации CLI (англ. Common Language Infrastructure), спецификации общеязыковой инфраструктуры компании Microsoft.
T>из WIKI T>
T>Common Intermediate Language (сокращённо CIL) — «высокоуровневый ассемблер» виртуальной машины .NET. Промежуточный язык, разработанный фирмой «Microsoft» для платформы .NET Framework.
T>как понимаем виртуальной машины .NET-не существует т.к. из языка .Net идет трансляция на язык CLI/CIL и потом компиляция в CIL байт код (а можно и напрямую в CIL байт код). следовательно виртуальная машина не .NET а CLR.
CLR это среда выполнения. А выполняется не байт код, а скомпилированный код из него. Это может быть заранее скомпилированный код. В том числе и для .Net Native где СДК не используется.
CIL это просто язык.
T>"Assembler" компилятор для языка CLI/CIL называется ilasm а на выходе CIL байт код. есть disassembler для CIL посмотрите проект mono. T>ОБратите внимание мы говорим об assemblere который из текста программы на языке CLI/CIL(assembler) делает байт код CIL для виртуальной машины CLR T>Читать инфу надо задумываясь.
TT>для linux T>https://en.wikipedia.org/wiki/Mono_%28software%29 T>https://github.com/dotnet/coreclr T>http://www.mono-project.com/
Вот ты бы сам ссылки почитал, а то утверждаешь, что .Net только для Windows
T>Давайте теперь рассмотрим варианты компиляции T>их очень много. Но сначала для Perl
T>1 T>после того как вы записали текст программы можно его выполнить T>perl example.pl — в этом случает perl выступает как интерпретатор, но есть одно но. Дело в в том T>что на лету perl формирует байт код в памяти (т.е. компиляция) и только потом ее исполняет. T>но нам не интересно как выполняет perl текст написанный на языке perl, главное что мы передаем текст, T>а perl интерпретатор выдает результат.
T>2 T>все это я привел для того чтобы было четкое понимание где текст программы, интерпретатор, виртуальная машина, транслятор
T>точно также .Net может сделать трансляцию на CLI/CIL(язык ассемблера) T>далее применяя команду ilasm текст программы на assembler CIL в объектный код CIL T>этот объектный код может выполнить CLR виртуальная машина возможно даже он применит T>jit компиляцию (https://ru.wikipedia.org/wiki/JIT-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F) T>прочтите доконца T>Мы имеем CIL код(не путать с текстом на assembler CIL) но мы можем применить для этого кода команду T>ngen для получения машинного кода. T>https://en.wikipedia.org/wiki/Native_Image_Generator T>https://ru.wikipedia.org/wiki/Ngen
T>но не забываем что можно сразу компилировать из любого языка CLI (https://en.wikipedia.org/wiki/List_of_CLI_languages) в CIL код T>Также можно компилировать сразу в машинный код T>ngen может компилировать и из текста программы на CIL assembler в машинный код
Сборка обладает следующими свойствами.
• Содержит код, выполняемый общеязыковой исполняющей средой. При отсутствии манифеста сборки код на промежуточном языке MSIL, находящийся в переносимом исполняемом (PE) файле, выполняться не будет. Имейте в виду, что каждая сборка может иметь только одну точку входа (т. е. DllMain, WinMain или Main).
if (!CreateDelegate(domainId, L"SetDelegate", (INT_PTR*)&pSetDelegate)) return false;
// Передадим ссылки на нужные методы
pSetDelegate(ManagedDomainLoader::GetMem, ManagedDomainLoader::AddError);
Внутри .Net я получаю ссылки на статические методы
Где здесь VM? Выполнение машинного кода.
S>> Так объясни мне где в .Net эмуляция, Весь код перед выполнением компилируется. S>>Ты так и не ответил про NGEN, Net Native. T>надеюсь ответил
S>> Вот это и есть виртуальные машины, который выполняет код предназначенный для других Осей,процессоров. S>> В VS полно таких эмуляторо и бот они как раз и являются VM. S>> При этом код компилируется под определенную ось и процессор.
T>>>к ТЕРМИНАМ язык программирования, интерпретатор, компилятор, среда исполнения, байт код, виртуальная машина T>>>надо добавить T>>>трансляцию, песочницу, дебагеры, КОНТЕЙНЕРЫ.
S>> Вот CLR это как раз среда выполнения, но в ней никакой эмуляции не происходит. Все компилируется в машинный код. T>да CLR есть виртуальная машина и нам не интересно что применяет jit компиляцию S>>Эмуляция происходит только в Hyper-V T>>>Текст длинный получился. T>>>Попробую чуть позже написать про все эти термины и где лежит граница между терминами
T>>>Замечу что в браузере для javascript работает не виртуальная машина а контейнере S>> А в чем различие? Уже есть WebAssembly по твоей териналогии тот же байт код. T>Совершенно верно это байт код и для выполнения нужна виртуальная машина WebAssembly который может применить jit компиляцию T>некоторые люди уже попробовали запустить, сам пока не компилил T>https://habrahabr.ru/company/infopulse/blog/304362/
S>>
S>>WebAssembly определяет абстрактное синтаксическое дерево(AST), которое хранится в бинарном формате. Бинарность это здорово, так как позволяет создавать меньшие приложения. Наверняка вы задаетесь вопросом, как можно отлаживать бинарный код.
S>>В: Почему бы не использовать JVM?
S>> О: Попытки добавить JVM в браузеры с помощью плагинов были и не раз. К сожалению, ничего хорошего из этого не вышло. В JavaScript есть встроенная виртуальная машина, поэтому добавление еще одной приводит к появлению второго набора API подключений, чтобы дать виртуальной машине доступ к DOM, сетям, сенсорам, устройствам ввода и т.п. За это придется кое чем пожертвовать. Например, как будут процессы в виртуальной машине распределять между собой имеющиеся ресурсы? Ответить на этот вопрос сложнее, чем кажется.
T>Для javascript уже давно делают контейнер(а не встроенная виртуальная машина) который содержит javascript виртуальную машину и jit
WebAssembly это продолжение asm.js
asm.js — это подмножество JavaScript. Скрипты, написанные на этом подмножестве, подлежат эффективной компиляции: типы данных переменных определяются статически с использованием вывода типов. Используется в основном в качестве промежуточного языка для компиляции с таких языков как C/C++ и используется в связке с такими инструментами, как Emscripten или Mandreel.
AOT-компиляция значительно ускоряет выполнение скриптов, написанных с использованием asm.js (в частности, такие скрипты не зависят от сборщика мусора).
asm.js — это подмножество JavaScript. Скрипты, написанные на этом подмножестве, подлежат эффективной компиляции: типы данных переменных определяются статически с использованием вывода типов. Используется в основном в качестве промежуточного языка для компиляции с таких языков как C/C++ и используется в связке с такими инструментами, как Emscripten или Mandreel.
AOT-компиляция значительно ускоряет выполнение скриптов, написанных с использованием asm.js (в частности, такие скрипты не зависят от сборщика мусора).
Вот у кого мешанина в голове так это ....
и солнце б утром не вставало, когда бы не было меня
Советую еще раз прочитать, трудно найти информацию в инете которую я тут для вас расписал.
S>
S>asm.js — это подмножество JavaScript. Скрипты, написанные на этом подмножестве, подлежат эффективной компиляции: типы данных переменных определяются статически с использованием вывода типов. Используется в основном в качестве промежуточного языка для компиляции с таких языков как C/C++ и используется в связке с такими инструментами, как Emscripten или Mandreel.
S>AOT-компиляция значительно ускоряет выполнение скриптов, написанных с использованием asm.js (в частности, такие скрипты не зависят от сборщика мусора).
S>asm.js — это подмножество JavaScript. Скрипты, написанные на этом подмножестве, подлежат эффективной компиляции: типы данных переменных определяются статически с использованием вывода типов. Используется в основном в качестве промежуточного языка для компиляции с таких языков как C/C++ и используется в связке с такими инструментами, как Emscripten или Mandreel.
S>AOT-компиляция значительно ускоряет выполнение скриптов, написанных с использованием asm.js (в частности, такие скрипты не зависят от сборщика мусора).
S> Вот у кого мешанина в голове так это ....
может вы правы но вот разработчики с вами не согласны
официальный проект находится https://github.com/WebAssembly/design
попробуйте скачать
git clone https://github.com/WebAssembly/design.git
и не читайте разную ересь, всегда есть сайт разработчика для получения информации
У меня сложилось впечатление что вы еще настолько молоды и все у вас впереди
Будете черпать информацию только из принятых стандартов, только там вы найдете правильную информацию
Обсуждение далее нет смысла
Читайте всегда первоисточник
В CLR каждая функция (метод) представляет собой набор IL-команд и вся информация о ней хранится в метаданных модуля. При загрузке модуля для каждого его класса система CLR создает таблицу MethodTable, содержащую информацию о методах класса. Каждый метод класса описывается структурой MethodDesc, одно из полей которой содержит адрес скомпилированного метода в памяти (при выполненной JIT-компиляции метода), а другое содержит индекс в таблице MethodTable, по которому указан адрес переходника (thunk), содержимое которого изменяется в процессе выполнения в зависимости от того, скомпилирован метод или нет.
Первоначально (до выполнения JIT-компиляции) в качестве переходника выступает один из четырех т.н. precode переходников CLR: StubPrecode, FixupPrecode, RemotingPrecode или NDirectImportPrecode. Поскольку последний переходник используется только для вызова API-функций Windows, которые можно перехватить и напрямую, то его мы рассматривать не будем.
Основной задачей каждого из precode-переходников является передача адреса структуры MethodDesc,
определяющей используемый метод, внутренней функции ThePreStub (ThePreStubAMD64 для платформы x64, на рисунке отмечена как Stub), которая выполняет следующие задачи:
1.JIT-компиляция метода, идентифицируемого структурой MethodDesc;
2.установка указателя в структуре MethodDesc на сгенерированный native-код;
3.перезапись переходника таким образом, чтобы он осуществлял безусловный переход (jmp) на сгенерированный native-код;
4.выполнение сгенерированного native-кода.
Таким образом, в результате первоначального вызова целевого метода не только сгенерируется и выполнится код метода, но и изменится содержимое переходника, что приведет к прямому вызову сгенерированного native-кода при последующих вызовах метода.
Любой метод .NET, вызываемый из среды CLR, проходит через адрес в таблице MethodTable методов класса. Однако среда CLR предоставляет возможность вызова метода из неуправляемой среды С/С++. Для этого служат следующие функции: GetFunctionPointer класса RuntimeMethodHandle и GetFunctionPointerForDelegate класса Marshal. Адреса, возвращаемые указанными функциями, также являются адресами переходников, среди которых могут быть уже упомянутые StubPrecode, FixupPrecode и RemotingPrecode. В результате первоначального вызова метода происходит его компиляция и выполнение, при последующем вызове – прямой переход на сгенерированный код. При этом важным для нас является то, что для некомпилированного метода при вызове его как через таблицу методов, так и через возвращаемые упомянутыми функциями указатели, происходит вызов внутренней функции ThePreStub.
