[assembly] x86이 못생긴 이유는 무엇입니까? 다른 사람과 비교할 때 왜 열등하다고 간주됩니까? [닫은]

이에 대한 몇 가지 가능한 이유 :

1. x86은 비교적 오래된 ISA입니다 (원조는 결국 8086이었습니다).
2. x86은 여러 번 크게 발전했지만 이전 바이너리와의 하위 호환성을 유지하려면 하드웨어가 필요합니다. 예를 들어 최신 x86 하드웨어에는 기본적으로 16 비트 코드를 실행하기위한 지원이 여전히 포함되어 있습니다. 또한 리얼 모드, 보호 모드, 가상 8086 모드 및 (amd64) 롱 모드와 같은 이전 코드가 동일한 프로세서에서 상호 작용할 수 있도록 여러 메모리 주소 지정 모델이 있습니다. 이것은 일부 사람들에게 혼란 스러울 수 있습니다.
3. x86은 CISC 시스템입니다. 오랫동안 이것은 MIPS 또는 ARM과 같은 RISC 시스템보다 느리다는 것을 의미했습니다. 명령어에는 데이터 상호 의존성과 플래그가 있어 대부분의 명령어 수준 병렬 처리 형식을 구현하기 어렵 기 때문입니다. 최신 구현에서는 x86 명령어를 ” micro-ops ” 라고하는 RISC와 유사한 명령어로 변환하여 이러한 종류의 최적화를 하드웨어에서 구현할 수 있도록합니다.
4. 어떤면에서 x86은 열등하지 않고 단지 다릅니다. 예를 들어 입력 / 출력은 대부분의 아키텍처에서 메모리 매핑으로 처리되지만 x86에서는 처리되지 않습니다. (주의 : 현대 x86 컴퓨터는 일반적으로 어떤 형태가 DMA의 ,하지만 지원 및 메모리 매핑을 통해 다른 하드웨어와 통신 ISA는 여전히 같은 I / O 지침을 가지고 IN와 OUT)
5. x86 ISA 에는 아키텍처 레지스터가 매우 적기 때문에 프로그램이 필요한 것보다 더 자주 메모리를 통해 왕복 할 수 있습니다. 이를 수행하는 데 필요한 추가 지침은 효율적인 저장 전달 이지만 유용한 작업에 사용될 수있는 실행 리소스를 사용합니다.지연 시간을 낮게 유지합니다. 레지스터 이름을 큰 물리적 레지스터 파일로 변경하는 최신 구현은 많은 명령을 계속 사용할 수 있지만 아키텍처 레지스터의 부족은 여전히 ​​32 비트 x86의 중요한 약점이었습니다. x86-64의 8 개에서 16 개 정수 및 벡터 레지스터로의 증가는 64 비트 코드에서 32 비트보다 더 빠른 (더 효율적인 레지스터 호출 ABI와 함께) 가장 큰 요소 중 하나이며 각 레지스터의 너비가 증가한 것이 아닙니다. 16 개에서 32 개 정수 레지스터로 추가 증가하면 일부는 도움이되지만 그다지 많지는 않습니다. (AVX512는 32 개의 벡터 레지스터로 증가합니다. 부동 소수점 코드는 대기 시간이 더 길고 종종 더 많은 상수가 필요하기 때문입니다.) ( 주석 참조 )

6. x86은 많은 기능을 가진 복잡한 아키텍처이기 때문에 x86 어셈블리 코드는 복잡합니다. 일반적인 MIPS 기계에 대한 지침 목록은 한 장의 Letter 크기의 종이에 맞습니다. x86에 해당하는 목록은 여러 페이지를 채우고 지침은 더 많은 작업을 수행하므로 목록에서 제공 할 수있는 것보다 더 큰 설명이 필요한 경우가 많습니다. 예를 들어, MOVSB명령어 가 수행하는 작업을 설명하려면 비교적 큰 C 코드 블록이 필요합니다.

   if (DF==0)
     *(byte*)DI++ = *(byte*)SI++;
   else
     *(byte*)DI-- = *(byte*)SI--;
   

   이는로드, 저장 및 두 개의 더하기 또는 빼기 (플래그 입력에 의해 제어 됨)를 수행하는 단일 명령어이며, 각각은 RISC 시스템에서 별도의 명령어입니다.

   MIPS (및 유사한 아키텍처)의 단순성이 반드시 이들을 우월하게 만드는 것은 아니지만 어셈블러 클래스에 대한 소개를 가르치려면 더 간단한 ISA 로 시작하는 것이 좋습니다 . 일부 어셈블리 클래스는 y86 이라는 매우 단순화 된 x86 서브 세트를 가르치는데 , 이는 실제 사용에 유용하지 않다는 점 (예 : 시프트 명령 없음)을 넘어 단순화되거나 일부는 기본 x86 명령 만 가르칩니다.

7. x86은 가변 길이 opcode를 사용하여 명령어 구문 분석과 관련하여 하드웨어 복잡성을 추가합니다. 현대 시대에 CPU가 원시 계산보다 메모리 대역폭에 의해 점점 더 제한됨에 따라이 비용은 점점 작아지고 있지만 많은 “x86 bashing”기사와 태도는이 비용이 비교적 훨씬 더 큰 시대에서 비롯되었습니다.
   2016 업데이트 : Anandtech는 x64 및 AArch64 아래의 opcode 크기 에 대한 토론 을 게시했습니다 .

편집 : 이것은 x86을 bash 로되 어서 는 안됩니다 ! 파티. 나는 선택의 여지가 거의 없었지만 질문이 표현 된 방식을 감안할 때 약간의 강타를 할 수밖에 없었다. 그러나 (1)을 제외하고 이러한 모든 작업은 정당한 이유로 수행되었습니다 (댓글 참조). 인텔 디자이너는 어리석지 않습니다. 아키텍쳐로 몇 가지를 달성하고 싶었고, 이는 이러한 것들을 실현하기 위해 지불해야하는 세금 중 일부입니다.

답변

  mov eax,b
  xor edx,edx
  div dword ptr c
  mov a,eax

  mov r5,addr b
  mov r5,[r5]
  mov r6,addr c
  mov r6,[r6]
  div r7,r5,r6
  mov r5,addr a
  mov [r5],r7