CPU 명령어 세트 뒤에있는 근거는 무엇입니까?

Question

Intel x86 프로세서 용 명령어 세트를 살펴보면서 'mov', 'add', 'mul'과 같은 '직관적 인 명령어'가있는 반면 다른 것들은 'sete'와 같이 부자연 스럽습니다. 문제는 실질적인 문제보다는 호기심 때문입니다. 디자이너가 단일 명령으로 특정 실행 시나리오를 구현하는 이유는 무엇입니까? 그러한 디자인 결정을 설명 할 수있는 독서물을 알고 있습니까?

Answer 1

코드를 달성하는 데 가능한 두 가지 시퀀스가 ​​있습니다.여기 내 분석이다

; "classic" code 

cmp edx,15 
jne past 
mov al,20 
past: 

그리고

; "evolved" code 

cmp edx,15 
sete al,20 

이되는 조건, 간단한 할당은 단지 점프 경우에도, 반대 조건으로 조건부 점프를 포함 "해야한다"는 사고 방식의 비트 하나의 지시를 중심으로 그러나 자주 사용되는 특정 실행 시나리오가 더 나은 대안을 사용할 수 있다면 왜 그런가요?

코드가 실행될 때 실행 속도에 영향을 미치는 많은 요소가 있습니다. 그 중 두 가지는 비교/산술/부울 연산의 결과가 플래그 레지스터에 도달하는 데 걸리는 시간과 점프가 수행 될 때 다른 실행 페널티가되는 것입니다. (저는이 문제를 너무 단순화했습니다).

그래서 고전적인 코드는 이동을 실행하거나 점프를합니다. 전자는 다른 코드와 병렬로 실행될 것이고 후자는 프리 페처가 새로운 위치에서 데이터를로드하여 대기 상태가 될 수 있습니다. 프로세서의 분기 예측이 포함될 수 있으며 많은 요인에 따라 잘못 예측되어 추가 처벌이 발생할 수 있습니다.

진화 된 경우 프리 피트 쳐는 실행 속도에 좋은 영향을 전혀받지 않습니다. 또한 sete 시퀀스는 아마도 mov + jne 콤보보다 적은 바이트에 들어 맞을 것입니다. 상대적으로 적은 코드 캐시 용량/작업이 실행에 관련되어 상대적으로 더 많은 데이터 캐시 용량이 있음을 의미합니다. 잘. 과제의 내용이 즉시 필요하지 않을 경우 sete는 주변 코드와 더 잘 (실행에 따라) 혼합되는 위치로 재조정 될 수 있습니다. 이 재조정은 명시 적으로 (컴파일러에 의해) 또는 암시 적으로 (CPU 자체에 의해) 수행 될 수 있습니다.

정상적인 (일반적으로 조정되지 않은) 부풀린 응용 프로그램 코드의 경우 이와 같은 지침을 사용하면 전반적인 성능에 거의 영향을 미치지 않습니다. 매우 엄격한 루프를 사용하는 고도로 전문화 된 손으로 튜닝 된 코드에서 4 개 또는 5 개의 캐시 라인에서 실행하는 것의 차이는 특히 여러 코드가 여러 코어에서 실행되는 경우 큰 차이를 만들 수 있습니다.

Answer 2

sete의 경우 명령 세트에 작성된 코드의 실제 문제 일 가능성이 큽니다. 최소한 메모리가 작동하면이 386부터 추가되었으므로 명령어 세트는 몇 년 동안 계속 사용되었습니다. 추측 해 보면, 많은 일을했지만 직접 명령어 세트에서 지원되지 않는 것을 찾기 위해 코드를 조사하는 데 시간을 할애했을 것입니다. 그들은 CPU에서 직접 지원함으로써 훨씬 더 효율적으로 만들기 쉬운 것들을 찾는다.

많은 경우가 비슷합니다. 소프트웨어는 기본적으로 합리적이고 유연하고 효율적이며 구현하기 쉬운 디자인을 찾기 위해 프로토 타입 화되어 있습니다. 그런 다음 설계가 상대적으로 세련되면 CPU 설계자는이를 검토하여 하드웨어에서 적어도 부분적으로 구현함으로써 성능을 조금 더 효율적으로 만들 수 있는지 여부를 확인합니다.

대부분의 소위 RISC 프로세서는 기존 프로세서의 기존 컴파일러로 소스 코드에서 생성 된 코드에 대한 통계를 수집하여 설계되었습니다. 그런 다음 그들은 명령 사용의 빈도를 살펴 보았고, 많이 사용 된 것들을 최적화 (시도)하고, 많이 사용하지 않은 것들을 떨어 뜨렸다.

Answer 3

디자이너는 "특정 실행 시나리오"명령에 대한 합리적인 후보 여부를 결정하는 데 사용하는 일부 기준 :

1. 무 행동이 - 동작은 피연산자하거나 눈에 보이는 기계 상태에 의존한다 (예 : 연산 플래그) 실행 시간. 숨겨진 상태는 허용되지 않습니다. 이 제한은 명령이 완료된 것으로 보이는 후에 사용하지 않는 비 차단 명령을 배제합니다.

2. 제한된 메모리 터치 - 메모리 액세스는 종종 속도 제한 기입니다. 코드 밀도를 향상시키는 것 외에도 메모리 병목 현상으로 인해 둘 다 동일하게 수행되는 경우 개별 작업을 하나의 큰 명령어로 결합하는 것은 의미가 없습니다.

3. 계산 상 재미있는 것 - 새로운 지시는 가능한 한 다른 것보다 더 효율적으로해야합니다. x86 AES 명령어는 극단적 인 예입니다. 비트 스위 즐 (bit swizzle)과 같은 비교적 간단한 연산도 자주 발생하는 경우 중요합니다.

4. 비즈니스 가치 - 지침을 구현하기위한 실리콘 영역 및 유효성 검사 노력이 비용을 지불합니까?

5. 호환성 값 - 마지막으로, 많은 정보가 레거시 소프트웨어를 지원하는 것 외의 다른 이유로 존재합니다.