은 일반적으로 우리가 같이 등록 번호를 -1에서로드

Question

비트 x86 CPU (64)에서 등록합니다.

또 다른 방법은 다음과 같습니다는

xor  rdx, rdx // 4831D2   
dec  rdx  // 48FFCA 

...이 옵 코드는 6 바이트를합니다.

편집 : 옌스 Björnhager으로

이 (내가 테스트 한) 말 xor edx, edx 오피 코드는 전체 RDX 레지스터를 취소해야합니다

는

xor  edx, edx // 31D2   
dec  rdx  // 48FFCA 

...이 옵 코드는 5 바이트를합니다.

는

편집 :

알렉스가 다른 해결책을 찾기는 :

mov  rdx, -1 // 48C7C2FFFFFFFF 

...이 옵 코드는 7 바이트를합니다. 그러나 DB를 사용하지 않고 짧은 opcode를 사용하도록 컴파일러에 알리는 방법은 무엇입니까?

는 ... 빨리 무엇입니까

무엇보다 경제적이다?

Answer 1

mov rdx, -1의 대체 7 바이트 인코딩 : 48C7C2FFFFFFFF가 있습니다.

이 단축 인코딩을 사용하여 컴파일러/어셈블러를 돕기 위해 코드에 mov rdx, dword -1이라는 명령어를 작성할 수 있습니다.

Answer 2

첫 번째가 훨씬 좋습니다. 첫 번째는 전혀 의존 관계가 없습니다. 두 번째 명령은 최악의 종속성 중 하나를 갖습니다. 명령은 명령을 시작하기 전에 명령의 최종 결과를 요구합니다. 그러나 xor과 dec 사이에 끼어들 수있는 다른 지침이 있다면 종속성이 제거되고 두 번째 옵션이 해제 될 수 있습니다.

두 번째 것은 또한 rdx의 값에 대해 가짜 종속성을 가지며, 첫 번째 값은 그렇지 않습니다. 일부 CPU는이 잘못된 종속성을 인식하고 rdx 값이 알려질 때까지 출력이 0이 아니기 때문에 첫 번째 명령을 지연시키지 않을만큼 똑똑 할 수 있습니다. 일부 x86 CPU에는 잘못된 종속성을 무시하는 논리가 있습니다.

코드 바이트 수를 비교하는 것은별로 유용하지 않습니다. 거의 대부분의 현실적인 상황에서 코드가 차지하는 바이트 수가 매우 중요하지는 않습니다.

Answer 3

가 언급 한 것들의 모든 이상의 짧은있다 : 4883CAFF OR rdx,-1
그것은 내가 아는 모든 아키텍처에 허위 의존성을 갖는 더러운 속성을 가지고 있지만, 그것은 IMO 언급되지 않은 가지 말았어야. 합법적 인 이유가 있습니다.예를 들어, 결과가 꽤 많이 필요할 때까지 필요하지 않은 경우, 그렇지 않으면 네 개의 16 바이트 블록에 맞지 않는 루프에 있습니다. 또한 속도가 특정 코드에 큰 문제가되지 않는다면 소중한 캐시 공간을 낭비하지 않을 수 있습니다. 정렬을 위해 사용할 수도 있지만, 그 다음으로 높은 정렬로 패딩하는 것이 더 빠를 것입니다.

컴파일러에게 말하면, 나는 단서를 얻지 못했다.