Od kodu do programu: kompilator, IL i JIT

Czego się dziś nauczysz

Problem: procesor nie zna C#

Kod, który piszesz, jest zrozumiały dla człowieka. Procesor rozumie coś zupełnie innego — kod maszynowy, czyli ciąg liczb oznaczających elementarne operacje: „weź liczbę z pamięci”, „dodaj”, „skocz do innego miejsca”. Ktoś musi jedno przetłumaczyć na drugie. Robi to kompilator.

Kompilator a interpreter

To dwa różne podejścia do tego samego zadania.

Implementacje języków mogą łączyć interpretację i kompilację. Edytor potrafi analizować kod i zaznaczać błędy także w językach interpretowanych. W typowym projekcie C# kompilator sprawdza kod przed uruchomieniem.

Dwa etapy zamiast jednego

W C# tłumaczenie nie odbywa się jednym skokiem. Dzieje się w dwóch krokach, w różnych momentach.

  Program.cs                    plik .dll                     kod maszynowy
  (kod w C#)                    (kod pośredni IL)             (rozumie procesor)
      │                              │                              │
      │   ETAP 1: kompilator         │   ETAP 2: kompilator JIT     │
      │   Roslyn                     │   w środowisku .NET          │
      └─────────────────────────────►└─────────────────────────────►
      gdy klikasz „Zbuduj"           gdy program działa

Etap 1 — kompilator Roslyn: C# → kod pośredni

Gdy budujesz projekt, do pracy zabiera się Roslyn — kompilator języka C#. Sprawdza kod pod względem poprawności i tłumaczy go na kod pośredni, nazywany IL (ang. Intermediate Language).

IL to język pośredni między C# a kodem maszynowym. Nie jest przeznaczony dla człowieka, ale też nie jest jeszcze zrozumiały dla procesora. Ważne: IL nie zależy od tego, na jakim procesorze i systemie ostatecznie uruchomisz program.

Etap 2 — kompilator JIT: kod pośredni → kod maszynowy

Gdy uruchamiasz program, wkracza środowisko uruchomieniowe .NET. Zawiera ono kompilator JIT (ang. Just-In-Time — „w samą porę”), który tłumaczy IL na kod maszynowy dopiero w trakcie działania programu i dokładnie dla tego procesora, na którym program właśnie działa.

Kod zarządzany i kompilacja podczas działania

C# jest językiem kompilowanym. JIT również jest kompilatorem, a nie interpreterem. Kod zarządzany korzysta z usług środowiska .NET, np. odśmiecania pamięci. Kod maszynowy wykonuje procesor. Istnieje też publikowanie Native AOT: kompilacja do kodu maszynowego przed uruchomieniem, bez JIT podczas działania.

Co naprawdę powstaje na dysku

Zbuduj projekt z poprzedniej lekcji i zajrzyj do folderu bin\Debug\. Znajdziesz tam kilka plików — warto wiedzieć, który jest który.

PierwszyProgram.dll                 ← TUTAJ jest twój kod (w postaci IL)
PierwszyProgram.exe                 ← mały program uruchamiający
PierwszyProgram.pdb                 ← informacje dla debugera
PierwszyProgram.runtimeconfig.json  ← która wersja .NET ma to uruchomić
PierwszyProgram.deps.json           ← lista zależności projektu

Omówienie

Debug czy Release?

Konfigurację zmienia się na pasku narzędzi Visual Studio, w rozwijanym polu obok przycisku uruchamiania. Na czas nauki zostaw Debug — potrzebujesz dokładnych komunikatów o błędach bardziej niż szybkości.

To samo z wiersza poleceń

Visual Studio wykonuje kompilację za ciebie, ale wszystko to samo można zrobić poleceniem dotnet. Warto je znać: na egzaminie zawodowym bywa szybsze, a na Linuksie często jest jedyną drogą.

dotnet new console -o MojProgram   # utwórz nowy projekt w folderze MojProgram
cd MojProgram                      # wejdź do tego folderu
dotnet build                       # skompiluj (C# → IL)
dotnet run                         # skompiluj i od razu uruchom
dotnet clean                       # usuń wyniki kompilacji

Plik projektu

Obok Program.cs leży plik z rozszerzeniem .csproj. To zwykły plik XML z ustawieniami projektu:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
</Project>

Jak czytać komunikaty kompilatora

Komunikat kompilatora ma zawsze ten sam układ. Warto raz nauczyć się go czytać — potem oszczędzi ci to godziny.

Program.cs(7,42): error CS1002: Oczekiwano ;
     │        │ │         │
     │        │ │         └── treść: co jest nie tak
     │        │ └── kod błędu — wpisz go w wyszukiwarkę, to działa
     │        └── wiersz 7, znak 42
     └── plik, w którym wystąpił problem

Błąd czy ostrzeżenie?

Najczęstsze błędy na początku

Zadania

using System

namespace MojaAplikacja
{
    class Program
    {
        static void Main(string[] args)
        {
            string imie = "Jan"
            Console.Writeline("Cześć " + imie)
        }
    }

Co trzeba zapamiętać

• Kompilator tłumaczy kod na inną postać. Interpreter wykonuje instrukcje; nie musi dosłownie czytać źródła linia po linii.
• W typowym projekcie Roslyn kompiluje C# do IL, a JIT w czasie działania tworzy kod maszynowy.
• JIT zachowuje wygenerowany kod i może później skompilować metodę ponownie w celu optymalizacji.
• Przenośny kod IL nadal wymaga zgodnego środowiska oraz użytych zależności.
• W zwykłym projekcie konsolowym DLL zawiera kod, a EXE może być programem uruchamiającym. Inne tryby publikowania, np. Native AOT, działają inaczej.
• Komunikat kompilatora zawiera kod błędu i lokalizację. Popraw przyczynę, a potem zbuduj program ponownie.
• Debug służy pracy z debuggerem; Release włącza ustawienia odpowiednie do wydania.