Те, що ви бачите при використанні налагодження + Windows + демонтаж при налагодженні програми C #, є хорошим посібником щодо цих умов. Ось примітка до нього, коли я складаю програму "привіт світ", написану на C # у конфігурації випуску з включеною оптимізацією 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
Клацніть правою кнопкою миші вікно і поставте галочку "Показати байти коду", щоб отримати подібне відображення.
Стовпчик зліва - адреса машинного коду. Його значення підробляється налагоджувачем, код насправді знаходиться десь в іншому місці. Але це може бути де завгодно, залежно від місця, обраного компілятором JIT, тому налагоджувач просто починає нумерувати адреси з 0 на початку методу.
Другий стовпець - машинний код . Фактичні 1 та 0, які виконує ЦП. Машинний код, як і тут, зазвичай відображається у шістнадцятковій формі. Можливо, ілюстративним є те, що 0x8B вибирає інструкцію MOV, додаткові байти є для того, щоб точно сказати процесору, що потрібно перемістити. Також зверніть увагу на два смаки інструкції CALL, 0xE8 - це прямий дзвінок, 0xFF - інструкція непрямого виклику.
Третій стовпчик - це код складання . Збірка - це проста мова, покликана полегшити запис машинного коду. Він порівнюється з компілюванням C # в IL. Компілятор, який використовується для перекладу коду збірки, називається "асемблером". Напевно, у вас на комп'ютері є асемблер Microsoft, його виконавче ім'я ml.exe, ml64.exe для 64-розрядної версії. Є дві поширені версії мов складання, які використовуються. Ви бачите той, який використовують Intel та AMD. У світі з відкритим кодом складання в нотаціях AT&T є загальним явищем. Синтаксис мови сильно залежить від типу процесора, для якого написано, мова складання для PowerPC сильно відрізняється.
Гаразд, це стосується двох термінів у вашому питанні. "Рідний код" - нечіткий термін, його нечасто використовують для опису коду некерованою мовою. Навчальним, можливо, є побачити, який машинний код генерується компілятором C. Це "привіт світ" версія на 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
Я не коментував це, здебільшого тому, що він настільки схожий на машинний код, сформований програмою C #. Виклик функції printf () сильно відрізняється від виклику Console.WriteLine (), але все інше приблизно те саме. Також зауважте, що зараз налагоджувач генерує реальну машинну кодову адресу і що він трохи розумніший щодо символів. Побічний ефект від генерування інформації про налагодження після генерування машинного коду, як це роблять некеровані компілятори. Я також повинен зазначити, що я вимкнув кілька варіантів оптимізації машинного коду, щоб зробити машинний код схожим. Компілятори C / C ++ мають набагато більше часу для оптимізації коду, результат часто важко інтерпретувати. І дуже важко налагоджувати.
Ключовим моментом тут є дуже мало відмінностей між машинним кодом, сформованим з керованої мови компілятором JIT, і машинним кодом, згенерованим нативним компілятором коду. Яка основна причина, чому мова C # може бути конкурентоспроможною компілятору нативного коду. Єдина реальна різниця між ними - це виклики функції підтримки. Багато з яких реалізовані в CLR. І це первинно обертається навколо сміттєзбірника.