2014-10-02 2 views
13

cmov 명령어를 어디서 사용하고 어디서 사용 설명서를 사용해야합니까?조건부 명령어 (cmov)와 점프 명령어 간의 차이점

  • 둘의 차이는 무엇입니까 :보기의 성능 관점에서

    ?

  • 어느 것이 더 낫습니까?

가능하면 예제와의 차이점을 설명하십시오.

+4

어떤 프로세서/제품군에 대해 관련 태그를 추가하십시오. –

답변

15

movcc movcc은 소위 이며, 표현식은입니다. 그것은 "이 명령은 조건 (조건 자)에서 실행됩니다"에 대한 환상입니다.

x86을 비롯한 많은 프로세서가 산술 연산 (특히 명령어 비교)을 한 후에 연산 결과의 상태를 나타내는 조건 코드 비트를 설정합니다.

조건부 점프 명령은 상태에 대한 조건 코드 비트를 검사하고, 참이면 지정된 대상으로 점프합니다.

점프가 조건부이며 프로세서에 일반적으로 딥 파이프 라인이 있기 때문에 조건 코드 비트는 말 그대로 CPU가 jmp 명령어를 만날 때 jmp 명령어가 처리 할 준비가되지 않았을 수 있습니다. 칩 설계자는 파이프 라인이 빠져 나가기를 기다리고 (종종 많은 클럭 사이클) jmp를 실행하지만 프로세서가 느려질 수 있습니다.

대신 대부분은 분기 예측 알고리즘을 선택합니다.이 알고리즘은 조건부 점프가 어떤 방식으로 진행될 것인지를 예측합니다. 그러면 프로세서는 예측 된 브랜치를 가져오고 실행할 수 있으며, 조건 코드 비트가 최종적으로 으로 바뀌면 조건부 (분기 예측 오류) 인 경우에도 빠른 실행을 계속할 수 있습니다.), 프로세서는 브랜치 다음에 수행 한 모든 작업을 취소하고 다른 경로로 내려가는 프로그램을 다시 실행합니다.

조건부 점프는 일반 데이터 종속성보다 파이프 라인 실행의 경우 파이프 라인을 통해 흐르는 명령어 스트림에서 어떤 명령어가 다음에 있어야 하는지를 변경할 수 있기 때문에 어렵습니다. 이것은 데이터 종속성 (예 : add)과는 달리 control dependency이라고합니다. 두 입력은 다른 최근 명령어의 출력입니다.

브랜치 예측기는 대부분의 브랜치가 방향에 대해 편향되는 경향이 있기 때문에 매우 양호합니다. (대부분의 루프 끝에있는 지점은 일반적으로 다시 맨 위로 분기 할 것입니다.) 대부분의 경우 프로세서는 잘못 예측 된 작업에서 철회 할 필요가 없습니다.

브랜치 방향이 예측할 수없는 경우 일 경우 프로세서가 시간의 약 50 %를 잘못 추정하여 작업을 취소해야합니다. 그건 비싸.

OK, 지금, 하나는 종종 다음과 같은 코드를 찾습니다 분기 예측 잘 추측

cmp ... 
    jcc $ 
    mov register1, register2 
$: ; continue here 
    ... 
    ; use register1 

경우,이 코드는 상관없이 분기가 이동하는 방식으로 빠른 없다. 잘못 추측하면 .. 아프다.

따라서 조건부 이동 명령. 이것은 조건 코드 비트를 기반으로 데이터를 조건부로 이동하는 동작입니다. 우리는 위의 내용을 다시 작성할 수 있습니다 :

cmp ... 
    movcc register1, register2 
$: ; continue here 
    ... 
    ; use register1 

이제 우리는 모든 작업을 취소하여 더 가지 지침 및 프로세서을 전혀 예측 오류가 없습니다. 제어 종속성이 없으므로 movccmov 또는 nop과 같은 역할을하는지 여부에 관계없이 다음 명령어를 가져오고 디코딩해야합니다. register1을 사용하는 상태를 예측하거나 추측 적으로 실행하지 않고 파이프 라인을 가득 채울 수 있습니다. 그런 식으로 CPU를 만들 수는 있지만, 이는 movcc의 목적을 무효화합니다.

movcc은 데이터 종속성으로 컨트롤 종속성을 변환합니다. CPU는 EFLAGS 및 두 개의 "일반"입력 (dest 레지스터 및 소스 레지스터 또는 메모리) 인 입력을 사용하여 3 입력 연산 명령어와 똑같이 처리합니다. x86의 경우 adccmovae (mov 인 경우 CF==0)과 동일하지만 순서가 잘못되어 실행이 종속성을 추적하는 한 입력은 CF 및 GP 레지스터입니다. 출력은 대상 레지스터입니다.

x86의 경우 모든 조건 조합 cc에 대해 cmovcc, jccsetcc 명령어가 있습니다. (setcc는 조건에 따라 대상을 0 또는 1로 설정하므로 플래그에 대한 데이터 종속성이 있으며 다른 입력 종속성은 없습니다.)

+0

movcc에 고정 된 비용이 드는 반면 예측 된 점프는 기본적으로 무료 임에 유의하십시오. 예측 점프는 항상 빠릅니다. (현재 x86 CPU에서) –

+1

@Cory : cc 비트가 유효하거나 다운 스트림 레지스터가 사용될 때까지는 movcc를 단순히 무시할 수없는 근본적인 이유는 없습니다. 현재 CPU가 그렇게하지 않습니까? 명령 디코드 시간은 실행 전에 발생한다는 사실 때문에 본질적으로 0입니다. –

+1

필자는 "동등하거나 더 빠름"이라고 말해야한다고 생각합니다. 예측 된 점프는 항상 자유롭고, 'movcc'는 그렇지 않을 수도 있습니다. 'movcc'는 예측할 수 없으며 기본적으로'add '처럼 취급됩니다. 종속성을 도입하고 재정렬 될 수 있으며 ILP에 의해 대기 시간이 "숨겨져"있을 수 있습니다. –