10
두 도구 모두 어셈블리 명령어를 직접 기계어로 번역하지만 어느 것이 가장 빠르고 깨끗한 코드를 생성하는지 판단 할 수 있습니까?가스 대 nasm : 어떤 어셈블러가 최고의 코드를 생산합니까?
A
답변
26
어셈블러에서 작성할 때 을 생성하는 지침을 정확하게 설명하므로 어셈블러에 의존하지 않습니다. 그것은 당신 한테 달려 있어요. 작성한 니모닉과 기계어의 실제 지침 간에는 일대일 대응이 있습니다.
4
코드는 최적화되지 않습니다. 그대로 번역됩니다. 따라서 가장 빠르고 깨끗한 코드는 프로그래머 또는 컴파일러가 생성합니다.
+1
알았어요! 이제 어셈블러도 컴파일러입니다. 여기 저기에 CPU주기를 저장할 수 있습니까? 그것은 내 의심이었습니다. –
+1
어셈블러는 컴파일러가 아닙니다. 컴파일러는 일반적으로 어셈블러를 사용합니다. 그리고 어셈블러는 어셈블리를 바이너리 op 코드로 변환합니다. – tsturzl
2
1
@ 브라이언 : 질문이 아니었다 ... cyber98834 @
은 : 그 연산 코드에 대한 모든 지시를 번역 : 음, 어셈블러는 모든 어셈블러가해야 할 일을한다.
최적화가 없습니다.
아, 또한 "가장 빠른 코드"와 같은 것이 없습니다 ... 질문 할 수 있습니까? CPU의 속도는 정적입니다. 그렇지 않습니까?
따라서 CPU 속도를 변경할 수 없으므로 코드를 더 빠르게 실행할 수 없습니다.
그러나 CPU를 줄여 명령을 처리 할 수 있으므로 코드 실행 시간을 단축 할 수 있습니다.
내가 말하고자하는 바를 이해하기를 바랍니다.
많은 최적화 교훈을 다루는 Michael Abrash의 Graphics Programming Black Book을 구입하거나 (일부 pdf를 찾으려면 권할 만하지만 그게 합법인지는 모르겠다.) 추천합니다.
+0
안녕 SBouazza! 귀하의 요지를 이해합니다. 감사! 나는 이미 Michael Abrash의 그래픽 프로그래밍 블랙 북을 준비했다. (http://www.gamedev.net/reference/articles/article1698.asp) –
7
나는이 두 가지 특정 도구에 대해 잘 모르지만, 다른 인코딩 할 수있는 몇 가지 지침이 있습니다 :
ADD AX,1중 하나05 01또는81 c0 01또는fe c0INT 3이입니다 어느cc또는cd 03- 2 바이트 SSE 명령어를 확장하는 새로운 AVX 명령어는 2 바이트 또는 3 바이트 접두사를 갖습니다. 모든 2 바이트 접두사는 3 바이트 접두사로 인코딩 될 수 있습니다.
이들은 어셈블러가 동일한 명령어를 다르게 인코딩 할 수있는 몇 가지 예에 불과하므로 질문이 실제로 의미가 있습니다.
+0
대부분의 어셈블러는 보통 최소 크기의 명령어를 선택한다. 생성하려는 힌트를 구체적으로 선택할 수있는 힌트를 제공 할 수 있습니다. 예를 들어'cc'와'cd 03'은 CPU의 관점에서 두 가지 다른 명령입니다. 어셈블러를 대신하여 명령을 생성하는 방법을 제공하지 않기로 결정했습니다. –
+0
좋은 어셈블러 *해야한다고 동의합니다. 나는 어셈블러가 다른 것을 할 수있는 방법을 지적하고있다. 예를 들어 'fe c0'으로 인코딩 된 'INC AX'는 실제로 CPU에서 별도로 디코딩되지만 기능 및 명령어 길이에 관한 한 '05 01'로 인코딩 된 'ADD AX, 1'과 완전히 동일합니다. –
+0
그건 내 질문에 실제로 찾고 있었어. x86 어셈블리를 배우기 시작했습니다. (인텔 매뉴얼을 읽었습니다.) 리눅스 툴을 사용하고 싶지만, 어떤 도구로 시작할 지에 대해서는 의심의 여지가있었습니다. 가스와 nasm 사이에 실제적인 차이가없는 것 같기 때문에 나는 더 친숙한 sintax 때문에 nasm을 선택합니다. 도움 주셔서 감사합니다. –
5
구문에 관한 사이드 바. 당신은 소스 파일의 맨 위에 다음 줄을 넣어 인텔 문법을 완벽하게 정상적으로 가스 작업을 할 수 있습니다 : 내 모든 assmebly 요구에 너무 인텔 구문을 사용하고
.intel_syntax noprefix
. AT & T 구문보다 훨씬 자연스러운 것 같습니다. 그리고 그것은 몇몇 키 스트로크를 저장합니다 :-).
+0
_Recent_ Gas. 당신이 OS/2에 있다면 당신은 운이 없을 수도 있습니다 :) –
기술적으로는 사실이 아닙니다. 어드레싱 모드와 같은 것들을 위해서, 같은 위치를 인코딩하는 방법은 여러 가지가있을 수 있습니다. 잊어 버린 다른 동형이 있습니다. 당시의 x86 셰어웨어 어셈블러는 이러한 동형을 사용하여 속임수를 잡기 위해 코드와 함께 "지문"코드를 사용했습니다. –
나는 당신이 말하는 것을 이해합니다. 비슷한 효과를내는 다른 기계어 명령어가있을 수 있습니다. 기술적으로 어셈블러는 해당 명령어 (int3 및 int3)에 대해 두 가지 다른 표현을 제공하거나 생성 할 힌트를 사용할 수 있습니다. 이러한 것들은 대개 각 어셈블러에 대해 문서화됩니다. 나는이 질문의 목적을 위해 이론적으로이 문제들을 무시하는 것이 합리적이라고 생각한다. ** 그들은 정말로 다른 지시이다 ** 그리고 어셈블러는 당신이 하나로부터 선택할 수있게 할 수있다. –
어셈블러에서도 최적화를위한 여지가 있습니다. 많은 아키텍처에서는 주소 지정을위한 짧은 모드를 허용합니다 (예 : long 대신 relative displacment의 바이트 값 사용). 이 최적화는 객체 코드의 크기를 변경하기 때문에 일부 변위는 짧은 형식으로 사용될 수 있으므로 다중 패스 최적화가 필요합니다. AFAIK yasm이 (가)이 작업을 수행 할 수 있습니다. – hirschhornsalz