To, co widzisz, gdy używasz Debug + Windows + Demontaż podczas debugowania programu C #, jest dobrym przewodnikiem dla tych warunków. Oto wersja z adnotacjami, gdy kompiluję program „Hello world” napisany w C # w konfiguracji wydania z włączoną optymalizacją JIT:
static void Main(string[] args) {
Console.WriteLine("Hello world");
00000000 55 push ebp ; save stack frame pointer
00000001 8B EC mov ebp,esp ; setup current frame
00000003 E8 30 BE 03 6F call 6F03BE38 ; Console.Out property getter
00000008 8B C8 mov ecx,eax ; setup "this"
0000000a 8B 15 88 20 BD 02 mov edx,dword ptr ds:[02BD2088h] ; arg = "Hello world"
00000010 8B 01 mov eax,dword ptr [ecx] ; TextWriter reference
00000012 FF 90 D8 00 00 00 call dword ptr [eax+000000D8h] ; TextWriter.WriteLine()
00000018 5D pop ebp ; restore stack frame pointer
}
00000019 C3 ret ; done, return
Kliknij prawym przyciskiem myszy okno i zaznacz opcję „Pokaż bajty kodu”, aby uzyskać podobny widok.
Kolumna po lewej stronie to adres kodu maszynowego. Debugger fałszuje jego wartość, kod faktycznie znajduje się gdzie indziej. Ale może to być gdziekolwiek, w zależności od lokalizacji wybranej przez kompilator JIT, więc debugger zaczyna numerować adresy od 0 na początku metody.
Druga kolumna to kod maszynowy . Rzeczywiste 1 i 0, które wykonuje procesor. Kod maszynowy, jak tutaj, jest zwykle wyświetlany w postaci szesnastkowej. Ilustracją może być to, że 0x8B wybiera instrukcję MOV, dodatkowe bajty są tam, aby powiedzieć procesorowi dokładnie, co ma zostać przeniesione. Zwróć także uwagę na dwa rodzaje instrukcji CALL, 0xE8 to wywołanie bezpośrednie, 0xFF to instrukcja wywołania pośredniego.
Trzecia kolumna to kod zespołu . Asembler to prosty język, zaprojektowany, aby ułatwić pisanie kodu maszynowego. Porównuje się do kompilacji języka C # do IL. Kompilator używany do tłumaczenia kodu asemblera nazywany jest „assemblerem”. Prawdopodobnie masz asembler firmy Microsoft na swoim komputerze, jego nazwa wykonywalna to ml.exe, ml64.exe dla wersji 64-bitowej. W użyciu są dwie popularne wersje języków asemblera. Ten, który widzisz, to ten, którego używają Intel i AMD. W świecie open source asemblacja w notacji AT&T jest powszechna. Składnia języka jest silnie zależna od rodzaju procesora, dla którego został napisany, język asemblera dla PowerPC jest zupełnie inny.
OK, to dotyczy dwóch terminów z twojego pytania. „Kod natywny” jest terminem rozmytym i nierzadko jest używany do opisywania kodu w niezarządzanym języku. Być może pouczające jest sprawdzenie, jaki rodzaj kodu maszynowego jest generowany przez kompilator C. To jest wersja „hello world” w języku C:
int _tmain(int argc, _TCHAR* argv[])
{
00401010 55 push ebp
00401011 8B EC mov ebp,esp
printf("Hello world");
00401013 68 6C 6C 45 00 push offset ___xt_z+128h (456C6Ch)
00401018 E8 13 00 00 00 call printf (401030h)
0040101D 83 C4 04 add esp,4
return 0;
00401020 33 C0 xor eax,eax
}
00401022 5D pop ebp
00401023 C3 ret
Nie dodałem adnotacji, głównie dlatego, że jest tak podobny do kodu maszynowego generowanego przez program C #. Wywołanie funkcji printf () różni się znacznie od wywołania Console.WriteLine (), ale wszystko inne jest mniej więcej takie samo. Należy również zauważyć, że debugger generuje teraz prawdziwy adres kodu maszynowego i że jest nieco mądrzejszy w zakresie symboli. Efekt uboczny generowania informacji debugowania po wygenerowaniu kodu maszynowego, tak jak często robią to niezarządzane kompilatory. Powinienem również wspomnieć, że wyłączyłem kilka opcji optymalizacji kodu maszynowego, aby kod maszynowy wyglądał podobnie. Kompilatory C / C ++ mają dużo więcej czasu na optymalizację kodu, wynik jest często trudny do zinterpretowania. I bardzo trudne do debugowania.
Kluczową kwestią jest to, że istnieje bardzo niewiele różnic między kodem maszynowym wygenerowanym z języka zarządzanego przez kompilator JIT a kodem maszynowym wygenerowanym przez kompilator kodu natywnego. To jest główny powód, dla którego język C # może konkurować z kompilatorem kodu natywnego. Jedyną prawdziwą różnicą między nimi są wywołania funkcji wsparcia. Wiele z nich jest zaimplementowanych w środowisku CLR. A to przede wszystkim kręci się wokół garbage collectora.