네이티브 코드, 기계어 코드 및 어셈블리 코드의 차이점은 무엇입니까?
.NET 언어의 맥락에서 기계 코드와 네이티브 코드에 대해 혼란스러워합니다.
그들 사이의 차이점은 무엇입니까? 동일합니까?
이 용어는 때때로 일관되지 않게 사용되기 때문에 실제로 약간 혼란 스럽습니다.
기계 코드 : 가장 잘 정의 된 코드 입니다. 프로세서 (실제 작업을 수행하는 물리적 금속 조각)가 직접 이해하고 실행하는 바이트 코드 명령을 사용하는 코드입니다. 다른 모든 코드는 기계가 실행하기 전에 기계어 코드 로 변환되거나 변환되어야 합니다.
네이티브 코드 : 이 용어는 때때로 기계 코드 (위 참조)가 의미하는 곳에서 사용됩니다 . 그러나 때로는 비 관리 코드 를 의미하는데도 사용됩니다 (아래 참조).
비 관리 코드 및 관리 코드 : 비 관리 코드는 기계어 코드 로 직접 컴파일되는 C 또는 C ++와 같은 프로그래밍 언어로 작성된 코드를 나타냅니다 . C #, VB.NET, Java 등으로 작성되고 소프트웨어에서 프로세서를 "시뮬레이션"하는 가상 환경 (예 : .NET 또는 JavaVM)에서 실행 되는 관리 코드 와 대조됩니다 . 주된 차이점은 관리 코드가 가비지 수집을 사용하고 개체에 대한 참조를 불투명하게 유지하여 리소스 (대부분 메모리 할당)를 "관리"한다는 것입니다. 비 관리 코드메모리를 수동으로 할당 및 할당 해제해야하는 코드의 종류로, 때로는 메모리 누수 (할당 해제를 잊었을 때)와 세그먼트 오류 (너무 빨리 할당 해제 할 때)가 발생합니다. 관리되지 않음은 또한 일반적으로 null 포인터 역 참조 또는 배열 경계 오버플로와 같은 일반적인 오류에 대한 런타임 검사가 없음을 의미합니다.
엄밀히 말하면 Perl, Python, PHP 및 Ruby와 같은 대부분의 동적 형식 언어도 관리 코드 입니다. 그러나 일반적으로 그렇게 설명되지는 않습니다. 이는 관리 코드 가 실제로 크고 심각한 상용 프로그래밍 환경 (.NET 및 Java)에 대한 마케팅 용어라는 것을 보여줍니다 .
어셈블리 코드 : 이 용어는 일반적으로 사람들이 실제로 바이트 코드를 작성하고 싶을 때 작성하는 소스 코드의 종류를 나타냅니다. 어셈블러는 실시간 바이트 코드로이 소스 코드를 켤 수있는 프로그램입니다. 변환이 일대일이기 때문에 컴파일러 가 아닙니다 . 그러나 어떤 종류의 바이트 코드가 사용되는지에 대한 용어는 모호합니다. 관리되거나 관리되지 않을 수 있습니다. 관리되지 않는 경우 결과 바이트 코드는 기계 코드 입니다. 관리되는 경우 .NET과 같은 가상 환경에서 백그라운드에서 사용되는 바이트 코드가 생성됩니다. 관리 코드 (예 : C #, Java)는이 특수 바이트 코드 언어로 컴파일됩니다. .NET의 경우 CIL (Common Intermediate Language) 이라고하며 Java 에서는 Java 바이트 코드 라고 합니다.. 이 바로이 언어로이 코드 또는 쓰기에 액세스 할 수있는 일반적인 프로그래머에 대한 필요가 거의 보통이지만, 사람이 할 때, 그들은 종종로 참조 어셈블리 코드 그들이 사용하기 때문에 어셈블러 바이트 코드로 전원을 켭니다.
C # 프로그램을 디버깅 할 때 Debug + Windows + Disassembly를 사용할 때 표시되는 내용은 이러한 용어에 대한 좋은 가이드입니다. 다음은 JIT 최적화가 활성화 된 릴리스 구성에서 C #으로 작성된 'hello world'프로그램을 컴파일 할 때 주석이 달린 버전입니다.
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
창을 마우스 오른쪽 버튼으로 클릭하고 "Show Code Bytes"를 선택하면 유사한 디스플레이가 표시됩니다.
왼쪽 열은 기계 코드 주소입니다. 그 값은 디버거에 의해 가짜이며 코드는 실제로 다른 곳에 있습니다. 그러나 JIT 컴파일러가 선택한 위치에 따라 어디든 될 수 있으므로 디버거는 메서드 시작시 0부터 주소 번호 지정을 시작합니다.
두 번째 열은 기계 코드 입니다. CPU가 실행하는 실제 1과 0. 여기와 같이 기계어 코드는 일반적으로 16 진수로 표시됩니다. 예를 들어 0x8B가 MOV 명령을 선택하면 추가 바이트가 CPU에 정확히 무엇을 이동해야하는지 알려주는 것입니다. 또한 CALL 명령어의 두 가지 특징 인 0xE8은 직접 호출이고 0xFF는 간접 호출 명령어입니다.
세 번째 열은 어셈블리 코드 입니다. 어셈블리는 기계어 코드를 더 쉽게 작성할 수 있도록 설계된 간단한 언어입니다. IL로 컴파일되는 C #과 비교됩니다. 어셈블리 코드를 번역하는 데 사용되는 컴파일러를 "어셈블러"라고합니다. 컴퓨터에 Microsoft 어셈블러가있을 수 있습니다. 실행 파일 이름은 ml.exe, 64 비트 버전의 경우 ml64.exe입니다. 사용중인 어셈블리 언어에는 두 가지 공통 버전이 있습니다. 당신이 보는 것은 Intel과 AMD가 사용하는 것입니다. 오픈 소스 세계에서는 AT & T 표기법의 어셈블리가 일반적입니다. 언어 구문은 작성된 CPU의 종류에 따라 크게 달라지며 PowerPC의 어셈블리 언어는 매우 다릅니다.
좋아요, 귀하의 질문에서 두 가지 용어를 다룹니다. "네이티브 코드"는 모호한 용어로, 관리되지 않는 언어로 코드를 설명하는 데 드물게 사용되지 않습니다. C 컴파일러가 생성하는 기계 코드의 종류를 확인하는 것이 좋습니다. 이것은 C의 'hello world'버전입니다.
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
I didn't annotate it, mostly because it is so similar to the machine code generated by the C# program. The printf() function call is quite different from the Console.WriteLine() call but everything else is about the same. Also note that the debugger is now generating the real machine code address and that it is a bit smarter about symbols. A side effect of generating debug info after generating machine code like unmanaged compilers often do. I should also mention that I turned off a few machine code optimization options to make the machine code look similar. C/C++ compilers have a lot more time available to optimize code, the result is often hard to interpret. And very hard to debug.
Key point here is there are very few differences between machine code generated from a managed language by the JIT compiler and machine code generated by a native code compiler. Which is the primary reason why the C# language can be competitive with an native code compiler. The only real difference between them are the support function calls. Many of which are implemented in the CLR. And that revolves primary around the garbage collector.
Native code and machine code are the same thing -- the actual bytes that the CPU executes.
Assembly code has two meanings: one is the machine code translated into a more human-readable form (with the bytes for the instructions translated into short wordlike mnemonics like "JMP" (which "jumps" to another spot in the code). The other is the IL bytecode (instruction bytes that compilers like C# or VB generate, that will end up translated into machine code eventually, but aren't yet) that lives in a DLL or EXE.
In .NET, assemblies contain MS Intermediate Language code (MSIL, sometimes CIL).
It is like a 'high level' machine code.
When loaded, MSIL is compiled by the JIT compiler into native code (Intel x86 or x64 machine code).
'program story' 카테고리의 다른 글
영구 PowerShell 별칭을 만드는 방법 (0) | 2020.08.25 |
---|---|
XAML에 유니 코드 문자를 넣는 방법은 무엇입니까? (0) | 2020.08.25 |
maven 명령 줄 단일 명령에 대해 특정 settings.xml을 가리키는 방법은 무엇입니까? (0) | 2020.08.25 |
Android 프로젝트에서 처음부터 DAGGER 종속성 주입을 설정하는 방법은 무엇입니까? (0) | 2020.08.25 |
Eclipse의 사이드 바에서 강조 표시된 항목 색상을 변경하는 방법은 무엇입니까? (0) | 2020.08.25 |