🧩 Компилятор: что он делает с твоим кодом

В прошлый раз мы разрезали однострочник "Hello, World!" как торт и увидели его слои, от компилятора до процессора 🍰
Давай разберёмся с верхним слоем — компилятором

⚙️ Что это вообще такое

Компилятор — переводчик. Он берёт код, который пишет и понимает человек, и переводит его в форму, которую способна понимать и исполнять машина, а человек там мало что поймёт (да ему и не надо). Отдельно качать компилятор обычно не надо: он приезжает вместе с установкой .NET SDK (набор инструментов для разработки) и работает на этапе сборки, ещё до того, как программа запустится🧩

Кажется, что такой перевод — это очень просто, "просто одну строку сконвертировать в другую, и всё!"👩‍💼 На самом деле это целый завод с конвейером: несколько фаз, и каждая передаёт результат следующей 🏭

Давай посмотрим, что рождается на выходе каждой🔎


🔤 Фаза 1. Разбор на токены (лексер)

Текст рубится на токены — минимальные значимые кусочки🪓
Результат — плоский список:

Console · . · WriteLine · ( · "Hello, World!" · ) · ;

Пока это просто «слова», без понимания, что они значат.

🌳 Фаза 2. Сборка дерева (парсер)

Токены складываются в синтаксическое дерево — оно отражает грамматику: что во что вложено. Упрощённо это выглядит так:

вызов метода
 ├ что зовём: Console.WriteLine
 └ аргумент: "Hello, World!"

Полное дерево, прямо из компилятора — на дикпике 1. Смысла в нём всё ещё нет, это чистая форма

🧠 Фаза 3. Добавление смысла (семантика)

Компилятор проходит по дереву и добавляет узлам смысл — формализует, какой символ и тип за ними стоит. Результат — на дикпике 2. Если при написании кода ошибёшься в имени или типе, то компилятор будет ругаться на это именно на этом этапе

📦 Фаза 4. Генерация (emit)

В конце дерево со смыслом превращается в IL (Intermediate Language, промежуточный переносимый код, но это ещё не машинный код🐁)
Результатом компиляции одной нашей строки станут три инструкции:

ldstr  "Hello, World!"
call   Console.WriteLine(string)
ret

Они пакуются в сборку — файл .dll

🎩 А теперь фокус

В дереве не было ни класса, ни метода — мы их не писали. Но C# годами требовал каркас: class Program со статическим методом Main внутри.

Если заглянуть в собранный .dll, внутри окажется Program, а в нём метод <Main>$(string[]).

Компилятор дописал каркас за нас, а наш однострочник стал телом этого метода. Причём имя метода специально сделано таким сложным, чтобы к нему нельзя было обратиться из кода🛑

🅰️ Что с этим делать

🟢 Ошибка компиляции может возникнуть на одном из этапов сборки: не закрылась скобка — это парсер, опечатка в имени типа — это семантика
🟢 В результате компиляции получается .dll с IL внутри.

Как IL превратится в настоящие инструкции процессора — узнаем в следующий раз👉

🧑‍💻dp🥁
#dotnet #csharp #инженерныештучки #heavywednesday

⚡️ JIT: из IL в инструкции процессора

В прошлый раз мы прогнали код через конвейер компилятора и остановились на IL — промежуточном переносимом коде внутри .dll 📦
Но процессор про IL ничего не знает, ему нужны его собственные инструкции. Вот тут-то JIT и делает этот последний перевод

🕐 Кто такой JIT

JIT — Just-In-Time, «точно в срок». Это ещё один компилятор, но работает он не при сборке, а уже во время выполнения программы: берёт IL и превращает его в машинный код процессора, на котором прямо сейчас выполняется программа 🤩

JIT делает это лениво, по методам. То есть, компилируется не весь .dll разом, а конкретный метод в момент своего первого вызова. Дальше уже используется его машинный код 🐁

🛠 Это компилятор, а не переводчик слов

JIT — это именно компилятор. Он не идёт по IL шаг за шагом, как интерпретатор, и не перекладывает одну инструкцию в другую один-в-один. Он подбирает инструкции текущего процессора, раскладывает значения по регистрам, кое-где оптимизирует

🔎 Смотрим своими глазами

Возьмём наш однострочник. В IL он был представлен тремя инструкциями: ldstr, call, ret. После обработки JIT-ом под x64 ЦПУ они превращаются в настоящий ассемблер (дикпик 1):

mov  rdi, <адрес строки>
call Console.WriteLine(String)
ret

ldstr стал mov — кладём адрес нашей строки в регистр, откуда его заберёт вызов. call остался call, ret остался ret. А ещё JIT сам дописал пролог и эпилог (push/add вокруг) — это возня со стеком под вызов, которой в IL не было 🧹

Вот это уже те самые инструкции, которые процессор исполняет напрямую ⚡️

Этот машинный код никуда не сохраняется на диск — JIT кладёт его прямо в память процесса, и с концом программы он исчезает. Почему так и чем за это платим — вернёмся, когда дойдём до памяти 🧠

🅰️ Что с этим делать

🟢 Первый вызов метода всегда чуть дороже: ровно в этот момент JIT его и компилирует. Из-за этого возникает такое явление, как «холодный старт», когда самые первые прогоны методов медленнее последующих
🟢 IL не исполняется сам по себе. Он лишь заготовка, которую JIT собирает в машинный код под запуск. Дальше уже работает этот нативный код

Причём JIT в первый раз переводит метод наспех, лишь бы программа уже начала выполняться. А если метод оказывается «горячим», то есть если он вызывается снова и снова, то в какой-то момент JIT компилирует его заново, уже с оптимизациями. Зачем так, как он это решает, и сколько бывает уровней оптимизации — расскажу в следующий раз 👉

🧑‍💻dp🥁
#dotnet #csharp #инженерныештучки #heavywednesday