32 비트 레지스터의 x86-64 명령어가 전체 64 비트 레지스터의 위쪽 부분을 0으로 만드는 이유는 무엇입니까?
에서 인텔 설명서의 x86-64에 투어 , 본인은
아마도 가장 놀라운 사실은 같은 명령어가
MOV EAX, EBX
상위 32 비트RAX
레지스터 를 자동으로 제로화 한다는 것입니다 .
동일한 소스에서 인용 된 인텔 문서 (3.4.1.1 수동 기본 아키텍처의 64 비트 모드에서 범용 레지스터)는 다음과 같이 알려줍니다.
- 64 비트 피연산자는 대상 범용 레지스터에서 64 비트 결과를 생성합니다.
- 32 비트 피연산자는 대상 범용 레지스터에서 64 비트 결과로 0 확장 된 32 비트 결과를 생성합니다.
- 8 비트 및 16 비트 피연산자는 8 비트 또는 16 비트 결과를 생성합니다. 대상 범용 레지스터의 상위 56 비트 또는 48 비트 (각각)는 연산에 의해 수정되지 않습니다. 8 비트 또는 16 비트 연산의 결과가 64 비트 주소 계산 용인 경우 레지스터를 전체 64 비트로 명시 적으로 부호 확장합니다.
x86-32 및 x86-64 어셈블리에서 다음과 같은 16 비트 명령어
mov ax, bx
eax의 상위 단어가 0이되는 이런 종류의 "이상한"동작을 표시하지 마십시오.
따라서이 행동이 도입 된 이유는 무엇입니까? 언뜻보기에는 비논리적 인 것처럼 보입니다 (하지만 x86-32 어셈블리의 단점에 익숙하기 때문일 수 있습니다).
나는 AMD가 아니거나 그들에게 말하고 있지는 않지만 같은 방식으로했을 것입니다. 높은 절반을 0으로 설정해도 이전 값에 대한 종속성이 생성되지 않으므로 CPU가 기다려야합니다. 레지스터 이름 변경 메커니즘은 그렇게하지 않으면 본질적으로 실패 할 것입니다. 이렇게하면 항상 종속성을 명시 적으로 중단하지 않고도 64 비트 모드에서 빠른 32 비트 코드를 작성할 수 있습니다. 이러한 동작이 없으면 64 비트 모드의 모든 32 비트 명령어는 상위 부분이 거의 사용되지 않더라도 이전에 일어난 일을 기다려야합니다.
16 비트 명령어의 동작은 이상합니다. 의존성 광기는 현재 16 비트 명령어를 피하는 이유 중 하나입니다.
단순히 명령어와 명령어 세트의 공간을 절약합니다. 기존 (32 비트) 명령어를 사용하여 작은 즉치 값을 64 비트 레지스터로 이동할 수 있습니다.
또한 재사용 MOV RAX, 42
할 MOV EAX, 42
수있는 경우에 대해 8 바이트 값을 인코딩 할 필요가 없습니다.
이 최적화는 8 비트 및 16 비트 작업에 대해 그다지 중요하지 않으며 (더 작기 때문에) 규칙을 변경하면 이전 코드도 손상됩니다.
'IT박스' 카테고리의 다른 글
문서 기반 데이터베이스와 키 / 값 기반 데이터베이스의 차이점은 무엇입니까? (0) | 2020.08.29 |
---|---|
왜 map, fmap 및 liftM이 있습니까? (0) | 2020.08.29 |
Windows API 코드 팩 : 어디에 있습니까? (0) | 2020.08.29 |
CMake에서 사용자 환경 변수를 검색하는 방법 (Windows) (0) | 2020.08.29 |
@Basic (optional = false) vs @Column (nullable = false) in JPA (0) | 2020.08.29 |