Для кого все же предназначен код, полученный из CIL (байт-кода .net)?

Question

[Евгений]

Компилируя исходный код на на .net-совместимом языке, получаем CIL, который впоследствии транслируется виртуальной машиной в, так сказать, "окончательный" код, предназначенный для конкретной платформы.
Обычно можно встретить формулировку вроде "компилируется JIT-компилятором в машинный код".

Однако так уж прямо в машинный ли?

Ведь "машинный код" подразумевает команды, которые процессор может выполнить непосредственно, безо всяких дополнительных преобразований от различного рода трансляторов. Если открыть страницу вики, посвященную Mono, в первом же абзаце можно увидеть, для каких операционных систем существуют реализации моно и какие архитектуры процессоров поддерживаются. То есть вы можете писать в Mono из-под винды, макос, линукса и написанная вами программа будет работать на всех ОС из списка по ссылке (а именно - Windows, Linux, BSD (FreeBSD, OpenBSD, NetBSD), Solaris, Mac OS X, Apple iOS, Wii).

Но сама операционная система может работать не с любой архитектурой процессора.
К чему я веду: если CIL действительно компилируется в машинный код, который уходит непосредственно процессору на исполнение, то зачем указывать список целевых операционных систем?
Может быть тогда все же CIL компилируется в код для операционной системы, которая уже занимается окончательным его переводом в машинный код для процессора?

Ведь даже если вспомнить книгу "Архитектура компьютера" Таненбаума, то там уровень машинных команд находится в самом низу, а над ним несколько других уровней, в частности, уровень 3 операционной системы

(схема)

Comments

[freeExec]

Вам вопрос на засыпку, а C++ компилируется во что: в машинный код или код для ОС?

[Евгений]

freeExec, судя по третьему абзацу код С++ компилируется в "binary", то есть в программу в двоичном виде. Однако Таненбаум пишет, что код уровня операционной системы тоже является цифровым, а буквенное представление команд впервые появляется на уровне ассемблера. В таком случае становится не очень понятно, как с виду понять, это машинный код или код ОС, если они оба представлены цифрами. Если вы знаете точный ответ на свой вопрос, хотелось бы его услышать.

[Александр]

Евгений,

а буквенное представление команд впервые появляется на уровне ассемблера

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

if(n==0)
{}
else {}

разворачивается в связку из cmpи je (или jne).

[freeExec]

Евгений, По-моему у вас каша из всех этих "кодов". Вам не кажется странным, что программы распространяются в виде для Винды, для Линукса, для Мака и т.д.

код уровня операционной системы тоже является цифровым, а буквенное представление команд впервые появляется на уровне ассемблера.

Ещё больше заблуждение. От того как это отобразиться на экране машинный код: двоичный вид, хекс или ассемблерное представление - суть не меняется. Так же как цвет пикселя может быть представлен в виде RGB или HLS, но он не меняет от этого цвет.

как с виду понять, это машинный код или код ОС, если они оба представлены цифрами

Легко - смотрим есть ли вызов системных функций. Код без привязки ОС - это код загрузки этой самой ОС. Всё прикладное ПО использует функционал ОС.

[Евгений]

freeExec, так и есть, полная каша и у меня складывается впечатление, что люди, пишущие эти книги, статьи, тоже слабо понимают, о чем они пишут. Потому что иначе я не понимаю, как можно столько "скользких" формулировок делать.

Вам не кажется странным, что программы распространяются в виде для Винды, для Линукса, для Мака и т.д.

Не кажется и я вижу это так: в каждой ОС есть своя реализация стандарта CLI. В Windows это .net Framework, в Linux, Mac OS - Mono ну и так далее. Реализации различаются, в .net Framework есть куски, не реализованные в Mono и наоборот. Соответственно, я должен либо писать программу, которая использует только полностью пересекающийся функционал реализаций, тогда мне не придется иметь несколько версий программы, мой скомпилированный в CIL код будет работать на всех ОС идентично. Либо я должен оформить некое "ядро" своей программы из общего функционала реализаций, а все остальное для каждой версии написать отдельно с помощью тех самых различающихся средств. И вот тут у меня появляется "версия для Винды", "версия для Линукса" и все остальное.

Ещё больше заблуждение. От того как это отобразиться на экране машинный код: двоичный вид, хекс или ассемблерное представление - суть не меняется.

Ну, значит Таненбаум вводит людей в

заблуждение

. Либо это не до конца объяснено. Вот

дальше

он уже утверждает, что первая версия Unix была написана на ассемблере, а вторая на C. Хотя если следовать его логике, если она писалась на ассемблере, значит она находится на уровне ассемблера, а не на уровне ОС. А вторая версия тогда вообще переходит на уровень 5, "языка прикладных программистов".

Answer 1

[Saboteur]

Исполняемый файл - это не прямой набор инструкций. Он может иметь специальную структуру - .com, exe, линуксовые и юниксовые бинарники отличаются - CIL компилируется в машинный код, но в результате создается не просто байткод команд, а бинарник определенного формата, с которым умеет работать операционка - машинный код должен каким-то образом загрузиться в память, возможно даже не весь а частями, точка входа должна быть сообщена процессору и так далее.
Сейчас практически несуществует линейных программ, которые написаны таким образом, что выполняются в моносреде - все пишется из расчета многозадачных ОС.

Таким образом, в CLI обычный машинный код, который выполняется процессором, но который содержит определенные закладки, вызовы функций операционных систем для того, чтобы этот код успешно работал в определенной ОС, чтобы он не загребал под себя 100% CPU на пустые циклы и так далее.
Это не значит, что там немашиный код, это значит что машинный код написан для работы в определенных условиях и содержит определенные вызовы.

Comments

[Евгений]

Что представляет из себя эта "определенная среда", о которой вы говорите?
Машинному коду дано определение как коду, непосредственно исполняемому процессором. Машинный код существовал до изобретения микрокода и тем более до появления самой первой операционной системы. Следовательно, машинный код никак не может обращаться к функциям операционной системы, потому она находится выше уровнем и как раз ее команды являются надстройкой над машинными. Какие-то могут иметь отношение одна-к-одной, какие-то быть сложными комбинациями машинных команд.

Таким образом, вопрос остается открытым. Если он не понятен, могу переформулировать: CIL компилируется в команды, которые процессор выполняет непосредственно или он компилируется в очередную промежуточную форму? Если последнее, то в какую именно и как выглядит выглядит его дальнейший путь по превращению в окончательные команды, которые непосредственно может выполнить процессор.

[Александр]

Евгений,

CIL компилируется в команды, которые процессор выполняет непосредственно или он компилируется в очередную промежуточную форму?

Это байт-код для виртуальной машины. В байт-код реальной машины он транслируется непосредственно перед исполнением. Трансляцией занимается рантайм, например mono, net core...

[Saboteur]

Евгений,

Машинный код существовал до изобретения микрокода и тем более до появления самой первой операционной системы.

Вы не слушаете.

Работая в рамках операционной системы, вы не можете выполнять произвольный код на процессоре.
И Linux и Windows выполнят вашу программу в защищенном режиме, в своей среде, блокируя например попытки прямого доступа к устройствам.

Следовательно вам придется вызывать функции стандартных библиотек стандартным способом - это делается через стандартный способ - прерывания.

Если вы так настаиваете на чистом процессорном выполнении, приведите пожалуйста листинг программы на ассемблере, которая например напечатает hello на экране в разрешении 1200x1024x32, без использования функций BIOS.

[Евгений]

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

Если в рамках ОС нельзя выполнять код напрямую на процессоре, значит этот "машинный код", который якобы получается из CIL, вовсе не машинный, а некая очередная промежуточная форма кода, предназначенного на этот раз для конкретной ОС, который она как-то дальше запускает по цепочке преобразований, пока он не превратится в команды процессору?
Или это действительно готовый двоичный код для процессора и ОС никак его уже не преобразует, а просто является посредником в его передаче процессору? Но в таком случае при чем здесь вызовы каких-то функций стандартных библиотек, если у нас есть готовые к исполнению команды?

[Александр]

Но в таком случае при чем здесь вызовы каких-то функций стандартных библиотек, если у нас есть готовые к исполнению команды?

Евгений,
У процессора нет команд вроде "открыть файл, сетевой порт и т.д.". Процессор умеет считать, двигать биты в байтах, читать\писать в озу и порты ввода-вывода. Все.
"открыть файл, сетевой порт и т.д." -- это тот самый пресловутый api ос и стандартной библиотеки языка. Обертка над сырым железом, драйверами и т.д. Вы, когда в дотнете пишете

string text = File.ReadAllText(@"c:\file.txt", Encoding.UTF8);

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

[Saboteur]

Если в рамках ОС нельзя выполнять код напрямую на процессоре, значит этот "машинный код", который якобы получается из CIL, вовсе не машинный

Вы невнимательно слушаете.
Я же сказал что выполнять код напрямую можно. Но если вы захотите обратиться к устройству, например экрану, или диску, или еще к чему-нибудь - вам придется обращаться к функциям операционной системы.
Поэтому нужно их знать.
В машинном коде есть понятие подпрограммы - есть call, int, pop, есть регистры для передачи аргументов - это обычный машинный код. Просто эти стандартные функции нужно знать, чтобы написать более-менее адекватную программу.
На чистом ассемблере, без всяких функций вы просто не сможете передать данные, а любая программа откуда-то берет данные и куда-то передает, иначе она бесполезна.

в таком случае при чем здесь вызовы каких-то функций стандартных библиотек, если у нас есть готовые к исполнению команды?

У нас есть готовые к исполнению подпрограммы, а не команды.
Почитайте что такое прерывания и функции.

[Евгений]

Saboteur, где вы сказали, что выполнять код напрямую можно? Вы сказали

Работая в рамках операционной системы, вы не можете выполнять произвольный код на процессоре. И Linux и Windows выполнят вашу программу в защищенном режиме, в своей среде, блокируя например попытки прямого доступа к устройствам.

В итоге значит CIL компилируется в ассемблер и он выполняется операционной системой, имея возможность вызывать ее функции через прерывания?

[Saboteur]

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

Чтобы понять каким образом обращения к устройствам может быть заблокирована - нужно иметь представление как процессор работает, как идет обращение к устройствам, что такое прерывания, что такое защищенный режим процессора.
Современный процессор довольно сложное устройство. Если копнуть глубже и попытаться понять как работает L1, L2 кеш, как работает предиктивное разветвление - можно сломать голову.

[Евгений]

Saboteur, "суть" мной понята была еще до публикации вопроса и озвучена в первых его двух строках, а именно:

Компилируя исходный код на на .net-совместимом языке, получаем CIL, который впоследствии транслируется виртуальной машиной в, так сказать, "окончательный" код, предназначенный для конкретной платформы.

Я же хотел просто узнать чуть дальше, что это за вид и кто занимается его обработкой. Исходя из обсуждения я сделал вывод, что

В итоге значит CIL компилируется в ассемблер и он выполняется операционной системой, имея возможность вызывать ее функции через прерывания?

и хотелось бы получить подтверждение или опровержение, но вы почему-то эту самую главную часть сообщения оставили без внимания.

Если вдруг вы чувствуете, что сами не совсем до конца понимаете, как это работает и не можете дать четкого ответа, то ничего страшного, на этом и закончим.
Хорошим же я вижу ответ примерно в такой форме: "CIL преобразуется в машинный код. Но "машинный" в данном случае вовсе не означает, что он выполняется непосредственно процессором. Он выполняется операционной системой по ее правилам (например, попытка прямого доступа к устройствам блокируется) и имеет вид (двоичных команд (1100 0101 и т.д.) | ассемблерных команд (mov ax, bx) | другой вариант). Если интересно, как именно выполняются программы внутри конкретных ОС - обратитесь к соответствующей литературе. Таким образом, потребителем кода, получаемого из CIL, является операционная система, которая разбирает его и уже отправляет конкретные команды процессору посредством системы прерываний".
Это просто пример и реальные шаги могут быть другими, но суть в том, что эта формулировка не оставляет белых пятен в объяснении на текущем уровне абстракции. То есть если хотите узнать как именно ОС выполняет программы - читайте дополнительную литературу. Не хотите - пожалуйста, просто знайте, что получаемый из CIL код уходит именно операционной системе, а не процессору или еще куда-то.

[Saboteur]

Давайте так.

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

Когда вы говорите, что код уходит в операционную систему, вы видимо плохо себе представляете, что такое операционная система. Она не является интерпретатором или компилятором. Это просто набор определенных служб и функций. Посторонний код она не выполняет. Код выполняет процессор.

Программа откомпилированная в машинный код - это код для процессора. Но если этот код требует наличия функций операционной системы, а их нет - она не сможет работать. Обращается к этим функциям код обычным способом - int или call.

[Евгений]

Про прерывания я прочитал. Только к чему это в данном вопросе?

вы видимо плохо себе представляете, что такое операционная система

Видимо, плохо. Потому что по Таненбауму, которого все советуют, как раз и выходит, что все, находящееся над уровнем цифрового логического уровня - это "виртуальные машины". Совокупность средств, неважно, аппаратных ли, программных ли, которые создают абстракции над двоичными командами. В том числе и операционная система - точно такая же абстракция, пускай и сложная, но все также содержащая команды, объединяющие под собой команды с предыдущего уровня в разных комбинациях. Какая-то команда, если она низкоуровневая, может транслироваться в машинную один-в-один, а более высокоуровневая в десятки. Операционная система загружается в память и соответственно все эти команды могут использоваться прикладными программистами. Либо напрямую, если это какое-то сравнительно низкоуровневое программирование, либо вот через абстракции в виде всяких дотнетов.

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

[Saboteur]

Евгений,

Есть подозрение, что вы путаете уровни абстракции и уровни виртуализации.
Современный ассемблер сильно отличается от ассемблера 80-х

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

Таким образом, в CLI обычный машинный код, который выполняется процессором, но который содержит определенные закладки, вызовы функций операционных систем для того, чтобы этот код успешно работал в определенной ОС, чтобы он не загребал под себя 100% CPU на пустые циклы и так далее.
Это не значит, что там немашиный код, это значит что машинный код написан для работы в определенных условиях и содержит определенные вызовы.

Таненбаум неплох для базы. Но на самом деле все меняется и усложняется слишком быстро, чтобы кто-то успел все освоить и создать комплексный источник. Я такой не подскажу. Я вообще сомневаюсь, что на сегодня может существовать человек, который бы смог освоить все на нужном уровне, и создать комплексное описание с четкими формулировками.

Взять например ту же модель OSI - она базовая. Но она устарела - многие уровни OSI часто виртуализируются, совмещаются, наоборот разделяются на несколько подуровней, в зависимости от реализации.

[Евгений]

Saboteur, ну в таком случае едва ли есть смысл копаться в этих вещах дальше. Остановлюсь на том, что CIL преобразуется в машинный код и все. С практической точки зрения, похоже, едва ли надо знать больше, если конечно не собираешься писать какую-нибудь очередную реализацию .net. Спасибо за уделенное внимание.

Если вот эту часть отдельным ответом напишете, отмечу его как решение. А то камент нельзя отметить решением, а стартовый ответ под ответ не подходит.

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

Таким образом, в CLI обычный машинный код, который выполняется процессором, но который содержит определенные закладки, вызовы функций операционных систем для того, чтобы этот код успешно работал в определенной ОС, чтобы он не загребал под себя 100% CPU на пустые циклы и так далее.
Это не значит, что там немашиный код, это значит что машинный код написан для работы в определенных условиях и содержит определенные вызовы.

[Saboteur]

Евгений, поправил ответ

Answer 2

[#]

хорошо сформулированный вопрос, содержит не менее половины ответа (с)

тут так..

CIL действительно компилируется в машинный код

да, действительно

зачем указывать список целевых операционных систем?

не поверите, но минимальный ответ примерно таков - правильный формат исполняемого файла
ps да да, как подмечено Saboteur, и правильные обращения к ОС, тоже.. или даже на первом месте.. .. эмм.. для CIL.. того же Mono, да проверьте сами! ))

Answer 3

[Александр]

Может быть тогда все же CIL компилируется в код для операционной системы, которая уже занимается окончательным его переводом в машинный код для процессора?

Нет такого понятия код для операционной системы. Операционная система -- точно такая же программа (в реальности -- комплекс программ), как и все остальные.

если CIL действительно компилируется в машинный код, который уходит непосредственно процессору на исполнение, то зачем указывать список целевых операционных систем?

CIL транслируется в машинный код рантаймом (например, моно) в момент непосредственно перед исполнением. И если рантайм не умеет работать на определенной ос, то и CIL там не заработает.
Т.о., при проектировании программы Вам необходимо знать, на каких ОС есть рабочий рантайм. Также, если Вы обращаетесь к сервисам ОС (неявно, через обертки .net, предоставляемые BCL, или явно -- через DllImport), Вам нужно знать, на какой ОС будет выполняться Ваше приложение, дабы учитывать возможности ОС.

Comments

[Евгений]

Такое понятие есть и оно описано тем же самым Таненбаумом в его книге. Операционная система предлагает API разного уровня, а компиляция, интерпретация и иже с ними суть - перевод из одного вида в другой. И переводить можно сколько угодно раз, так что тот же самый CIL вполне можно перевести в команды ОС, а они уже пойдут по цепочке дальше и в итоге где-то там наконец-то станут командами для процессора. Другое дело, что я не нашел вразумительного ответа нигде, как же это работает на самом деле, поэтому решил спросить непосредственно у людей. Но пока что-то ответа не видать.

[Александр]

я не нашел вразумительного ответа нигде, как же это работает на самом деле

Евгений, вызовы к api ос -- есть,

тот же самый CIL вполне можно перевести в команды ОС, а они уже пойдут по цепочке дальше и в итоге где-то там наконец-то станут командами для процессора

Неа. Они станут командами процессора -- собственно инструкциями вызова call и еще кучки push (для передачи параметров через стек). А что там по факту вызывается, процессору -- фиолетово.

как же это работает на самом деле

Читайте любой учебник по ассемблеру х86. Хоть под DOS (где вызываются функции ОС через прерывания), хоть под windows (где функции (не только ос) вызываются через call)

Answer 4

[Satangelus]

В статье приведенной по ссылке подробно разбирается что и как под капотом net framework. Там Вы найдете ответ на Ваш вопрос.
https://habr.com/ru/post/90426/