등록명 변경
Register renaming컴퓨터 아키텍처에서 레지스터 이름 변경은 물리적 레지스터에서 논리 레지스터를 추상화하는 기술입니다.모든 논리 레지스터에는 일련의 물리 레지스터가 관련지어져 있습니다.기계어 명령이 특정 논리 레지스터를 참조할 때 프로세서는 이 이름을 하나의 특정 물리 레지스터로 바꿉니다.물리적 레지스터는 불투명하며 직접 참조할 수 없으며 정식 이름을 통해서만 참조할 수 있습니다.
이 기술은 레지스터 간에 실제 데이터 종속성이 없는 연속적인 명령에 의해 레지스터 재사용에서 발생하는 잘못된 데이터 종속성을 제거하기 위해 사용됩니다.이러한 잘못된 데이터 종속성을 제거하면 명령 스트림에서 더 많은 명령 수준 병렬화가 드러납니다. 이러한 병렬화는 성능 향상을 위해 슈퍼스칼라 및 순서가 잘못된 실행과 같은 다양한 보완적 기술에 의해 악용될 수 있습니다.
문제 접근법
레지스터 머신에서 프로그램은 값으로 동작하는 명령으로 구성된다.지시사항에서는 이들 값을 서로 구별하기 위해 이름을 지정해야 합니다.일반적인 명령에서는 "x x 및 y를 하여 결과를z\ z에 넣습니다.이 설명서에서 xx y 및(\ z는 저장 위치의 이름입니다.
콤팩트한 명령 부호화를 위해 대부분의 프로세서 명령어 세트는 특별한 이름인 레지스터로 참조할 수 있는 특별한 로케이션의 작은 세트를 가지고 있습니다.예를 들어, x86 명령 집합 아키텍처에는 8개의 정수 레지스터가 있고, x86-64에는 16개, 많은 RISC에는 32개, IA-64에는 128개가 있습니다.소형 프로세서에서는, 이러한 로케이션의 이름은 레지스터 파일의 요소에 직접 대응합니다.
명령어에 따라 시간이 걸릴 수 있습니다.예를 들어 프로세서는 메인 메모리에서1개의 로드가 진행 중일 때 수백 개의 명령어를 실행할 수 있습니다.로드가 미결 상태일 때 실행된 짧은 명령은 먼저 종료되므로 원래 프로그램 순서에서 명령이 종료됩니다.최신 고성능 CPU에서는 처리 속도를 높이기 위해 순서가 맞지 않는 실행이 사용되고 있습니다.
순서가 잘못된 CPU로 동작하고 있는 다음의 코드에 대해 생각해 주세요.
r1 ≔ m[1024] r1 ≔ r1 + 2 m[1032] ≔ r1 r1 ≔ m[2048] r1 ≔ r1 + 4 m[2056] ≔ r1 마지막 3행의 순서는 처음 3행의 순서와는 무관하지만 프로세서는 종료할 수 없습니다.r1 ≔ m[2048]이전까지m[1032] ≔ r1(그렇지 않으면 잘못된 값이 입력됩니다).
이 제한은 일부 레지스터의 이름을 변경하여 해소됩니다.
r1 ≔ m[1024] r1 ≔ r1 + 2 m[1032] ≔ r1 r2 ≔ m[2048] r2 ≔ r2 + 4 m[2056] ≔ r2 이제 마지막 세 가지 명령을 처음 세 가지 명령과 동시에 실행할 수 있습니다.잘못된 데이터 종속성으로 인한 지연을 제거하여 이전보다 더 빠르게 프로그램을 실행할 수 있습니다.
많은 고성능 CPU는 이 이름을 하드웨어에 구현하여 병렬 처리를 추가로 수행합니다.적절한 데이터 흐름 검출이 없는 타깃에서는 컴파일러가 독립된 명령 시퀀스를 검출하여 코드 생성 중에 다른 레지스터를 선택합니다.
데이터 위험
둘 이상의 명령이 특정 위치를 읽거나(입력) 또는 쓰기(출력)하여 피연산자로 참조하는 경우, 원래 프로그램 순서와 다른 순서로 해당 명령을 실행하면 다음과 같은 세 가지 종류의 데이터 위험이 발생할 수 있습니다.
- 쓰기 후 읽기(RAW)
- 레지스터 또는 메모리 위치에서 읽으면 다른 쓰기가 아닌 프로그램 순서로 마지막 쓰기로 지정된 값을 반환해야 합니다.이것은 진정한 의존관계 또는 흐름 의존관계라고 불리며 프로그램 순서로 실행하는 명령이 필요합니다.
- 쓰기 후 쓰기(WAW)
- 특정 레지스터 또는 메모리 위치에 대한 연속 쓰기는 두 번째 쓰기 결과가 포함된 위치를 벗어나야 합니다.이 문제는 필요에 따라 첫 번째 쓰기를 스쿼시(취소, 취소 또는 무팅이라고도 함)하여 해결할 수 있습니다.WAW 의존관계는 출력 의존관계라고도 불립니다.
- 읽기 후 쓰기(WAR)
- 레지스터 또는 메모리 위치에서 읽으면 해당 위치에 기록된 마지막 이전 값이 반환되어야 하며, 읽은 후에 프로그래밍 방식으로 쓴 값이 반환되지 않아야 합니다.이는 이름 변경으로 해결할 수 있는 일종의 잘못된 종속성입니다.WAR 의존성은 안티 의존이라고도 합니다.
모든 읽기가 완료될 때까지 쓰기를 지연하는 대신 이전 값과 새 값의 두 복사본을 유지할 수 있습니다.프로그램 순서로 새로운 값의 기입에 선행하는 판독치는 오래된 값으로 제공할 수 있습니다.기입에 이은 다른 판독치는 새로운 값으로 제공할 수 있습니다.잘못된 종속성이 해소되고 순서가 잘못된 실행을 위한 추가 기회가 생성됩니다.이전 값이 필요한 모든 읽기가 충족되면 해당 값은 폐기될 수 있습니다.이것은 레지스터 이름 변경의 이면에 있는 중요한 개념입니다.
읽고 쓰는 모든 항목의 이름을 변경할 수 있습니다.범용 및 부동소수점 레지스터에 대해 가장 많이 논의되는 반면 플래그 및 상태 레지스터 또는 개별 상태 비트도 일반적으로 이름이 변경됩니다.
메모리 위치도 이름을 변경할 수 있지만, 레지스터 이름 변경에서 일반적으로 실행되지는 않습니다.트랜스메타 크루소 프로세서의 게이트 스토어 버퍼는 메모리 이름 변경의 한 형태입니다.
프로그램이 레지스터를 즉시 재사용하는 것을 자제한다면 레지스터 이름을 바꿀 필요가 없습니다.일부 명령 집합(예: IA-64)은 특히 이러한 이유로 매우 많은 수의 레지스터를 지정합니다.단, 이 접근법에는 다음과 같은 제한이 있습니다.
- 큰 코드 사이즈가 증가하지 않으면 컴파일러가 레지스터를 재사용하지 않도록 하는 것은 매우 어렵습니다.예를 들어 루프에서는 연속되는 반복에서는 다른 레지스터를 사용해야 합니다.이 경우 루프 언롤링이라고 불리는 프로세스에서 코드를 복제하거나 각 반복에서 오퍼랜드타깃을 변경하기 위해 자체 수정 코드를 사용해야 합니다.
- 레지스터 수가 많을수록 명령에서 피연산자로 레지스터를 지정하기 위해 더 많은 비트가 필요하므로 코드 크기가 커집니다.
- 역사적으로 지정된 레지스터의 수가 적은 명령 집합은 하위 호환성을 유지하면서 변경할 수 없습니다.
프로그램 코드가 클수록 명령 캐시가 자주 누락되고 프로세서가 새로운 명령을 기다리는 동안 지연되기 때문에 코드 크기가 증가하는 것이 중요합니다.
아키텍처 레지스터와 물리 레지스터
기계어 프로그램은 명령 집합 아키텍처(ISA)에 의해 지정된 제한된 레지스터 세트에 대한 읽기 및 쓰기를 지정합니다.예를 들어, Alpha ISA는 각각 64비트 폭의 정수 레지스터 32개와 64비트 폭의 부동소수점 레지스터 32개를 지정합니다.이것들은 건축 등록부입니다.Alpha 명령 집합을 실행하는 프로세서용으로 작성된 프로그램은 64개의 레지스터를 읽고 쓰는 작업을 지정합니다.프로그래머가 디버거에서 프로그램을 정지하면 64개의 레지스터(및 몇 개의 상태 레지스터)의 내용을 관찰하여 머신의 진행 상황을 판단할 수 있습니다.
이 ISA를 실장하는 프로세서 중 하나인 Alpha 21264는 80개의 정수 및 72개의 부동소수점 물리 레지스터를 갖추고 있습니다.Alpha 21264 칩에는 정수 연산 결과를 저장할 수 있는 물리적으로 분리된 80개의 로케이션과 부동소수점 연산 결과를 저장할 수 있는 72개의 로케이션이 있습니다(실제로 이보다 더 많은 로케이션이 존재하지만 이러한 추가 로케이션은 레지스터 이름 변경 작업과 관련이 없습니다).
다음 텍스트에서는 레지스터 이름 변경의 두 가지 스타일에 대해 설명합니다.이러한 스타일은 실행 유닛에 사용할 수 있는 데이터를 유지하는 회선으로 구분됩니다.
모든 이름 변경 체계에서 기계는 명령 스트림에서 참조되는 아키텍처 레지스터를 태그로 변환합니다.아키텍처 레지스터를 3~5비트로 지정할 수 있는 경우 태그는 보통 6~8비트 번호입니다.이름 변경 파일에는 사이클마다 이름이 변경된 모든 명령 입력에 대한 읽기 포트와 사이클마다 이름이 변경된 모든 명령 출력에 대한 쓰기 포트가 있어야 합니다.일반적으로 레지스터 파일의 크기는 포트 수의 제곱에 따라 커지기 때문에 이름 변경 파일은 일반적으로 물리적으로 크고 상당한 전력을 소비합니다.
태그 색인화된 레지스터 파일 스타일에는 각 태그에 대해 하나의 레지스터를 포함하는 데이터 값용 하나의 큰 레지스터 파일이 있습니다.예를 들어 시스템에 80개의 물리적 레지스터가 있는 경우 7비트 태그를 사용합니다.이 경우 가능한 태그 값 중 48개는 사용되지 않습니다.
이 스타일에서는 실행부에 명령이 발행되면 소스 레지스터의 태그가 물리 레지스터 파일로 전송되고, 물리 레지스터 파일에서는 이들 태그에 대응하는 값이 읽혀져 실행부에 송신된다.
예약 스테이션 스타일에서는, 많은 작은 관련 레지스터 파일이 있으며, 보통 각 실행 유닛에 대한 입력에 하나씩 있습니다.발행 큐 내의 각 명령의 오퍼랜드에는 이들 레지스터 파일 중 하나의 값이 격납되어 있다.
이 스타일에서는 실행부에 지시가 발행되면 발행 큐 엔트리에 대응하는 레지스터 파일 엔트리를 읽어 실행부에 전송한다.
- 아키텍처 레지스터 파일 또는 은퇴 레지스터 파일(RRF)
- 머신의 커밋된 레지스터 상태.논리 레지스터 번호로 인덱스된 RAM입니다.일반적으로 결과가 취소되거나 재정렬 버퍼에서 커밋될 때 에 기록됩니다.
- 미래 파일
- 머신의 가장 투기적인 레지스터 상태.논리 레지스터 번호로 인덱스된 RAM입니다.
- 활성 레지스터 파일
- 인텔 P6 그룹의 미래 파일 용어.
- 이력 버퍼
- 일반적으로 미래 파일과 함께 사용됩니다.덮어쓴 레지스터의 "이전" 값을 포함합니다.생산자가 아직 가동 중인 경우 이력 버퍼 번호로 RAM 인덱스를 작성할 수 있습니다.브런치가 잘못 정의된 경우 이력 버퍼의 결과를 사용해야 합니다.이러한 결과가 복사되거나 향후 파일 검색이 디세이블이 되어 이력 버퍼가 논리 레지스터 번호로 색인화된 Content-Addressable Memory(CAM; 콘텐츠주소 지정 메모리)가 됩니다.
- 순서 변경 버퍼(ROB)
- 비행 중 지시를 위해 작업별로 순차적으로(원 단위로) 색인화된 구조물.순서 변경 버퍼는 일반적으로 미래의 파일(존재하는 경우)과 아키텍처 레지스터 파일 앞에 있기 때문에 이력 버퍼와는 다릅니다.
- 리오더 버퍼는 데이터가 없는 버퍼 또는 데이터 풀 버퍼입니다.
- Willamette의 ROB에서 ROB 엔트리는 물리 레지스터 파일(PRF)의 레지스터를 가리키며 다른 장부 키핑도 포함합니다.
- 이것은 또한 HaRRM과 함께 일리노이주에 있는 Andy Glew가 실시한 최초의 고장 설계이기도 합니다.
- P6의 ROB, ROB 엔트리에는 데이터가 포함되어 있으며 개별 PRF는 없습니다.
- ROB로부터의 데이터 값은 폐기 시 ROB에서 RRF로 복사됩니다.
- 한 가지 작은 세부사항: ROB 엔트리에 시간적 인접성이 있는 경우(즉, von Neumann 명령 시퀀스에서 명령어가 서로 근접하게 다시 쓰여지는 경우, ROB 엔트리에 대해 쓰기 결합을 수행할 수 있으므로 별도의 ROB/PRF보다 적은 포트를 가질 수 있습니다).
- PRF는 은행에 맡겨야 하기 때문에 차이가 나는지는 명확하지 않다.
- ROB에는 보통 관련 로직이 없습니다.또한 Andy Glew가 설계한 ROB에는 CAM이 없습니다.
- Keith Diefendorff는 ROBs가 오랫동안 복잡한 연상 논리를 가지고 있다고 주장했습니다.
- 최초의 ROB 프로포절에는 CAM이 포함되어 있을 가능성이 있습니다.
태그 색인화된 레지스터 파일
이는 MIPS R10000, Alpha 21264 및 AMD Athlon의 FP 섹션에서 사용되는 이름 변경 스타일입니다.
이름 변경 단계에서 참조되는 모든 아키텍처 레지스터(읽기 또는 쓰기용)는 아키텍처 색인화된 리맵 파일에서 검색됩니다.이 파일은 태그와 준비 비트를 반환합니다.아직 실행되지 않은 대기 중인 명령이 있는 경우 태그는 준비되지 않은 것입니다.읽기 오퍼랜드의 경우 이 태그는 명령에서 아키텍처 레지스터를 대체합니다.레지스터 쓰기마다 새로운 태그가 프리태그 FIFO에서 추출되고 새로운 매핑이 리맵 파일에 입력되므로 아키텍처 레지스터를 읽는 향후 명령이 이 새로운 태그를 참조할 수 있습니다.명령이 아직 실행되지 않았기 때문에 태그는 준비되지 않음으로 표시됩니다.아키텍처 레지스터에 할당된 이전 물리 레지스터는 명령과 함께 순서 변경 버퍼에 저장됩니다. FIFO는 디코딩 단계와 그라데이션 단계 사이에 명령을 프로그램 순서로 유지하는 것입니다.
그런 다음 다양한 이슈 큐에 지침이 배치됩니다.명령이 실행되면 결과의 태그가 브로드캐스트되고 문제 큐는 이러한 태그를 준비되지 않은 소스 오퍼랜드의 태그와 대조합니다.일치는 오퍼랜드가 준비되었음을 의미합니다.remap 파일도 이러한 태그와 일치하므로 대응하는 물리 레지스터를 ready로 표시할 수 있습니다.이슈 큐에 있는 명령의 오퍼랜드가 모두 준비되면 해당 명령을 발행할 준비가 된 것입니다.문제 큐는 사이클마다 다양한 기능 유닛에 전송하기 위한 준비 명령을 선택합니다.준비되지 않은 명령은 문제 대기열에 남아 있습니다.이렇게 문제 큐에서 명령을 순서대로 삭제하면 명령어가 대량으로 소비될 수 있습니다.
태그 인덱스화된 물리 레지스터 파일에서 읽은 명령어(브로드캐스트피연산자 바이패스)를 실행한다.실행 결과는 태그 색인화된 물리 레지스터 파일에 쓰이고 각 기능 유닛 앞의 바이패스 네트워크에 브로드캐스트됩니다.Graduation은 새로 디코딩된 명령에 재사용할 수 있도록 작성된 아키텍처 레지스터의 이전 태그를 프리 큐에 넣습니다.
예외 또는 분기의 잘못된 예측으로 인해 상태 스냅샷 조합과 순차적인 사전 그라데이션 큐의 이전 태그 순환을 통해 마지막으로 유효한 명령에서 재맵 파일이 재맵 상태로 백업됩니다.이 메커니즘은 필수적이며 (지시가 현재 등급 설정되기 전의 상태뿐만 아니라) 임의의 재맵 상태를 복구할 수 있기 때문에 브랜치가 졸업하기 전에 브랜치의 오예측을 처리할 수 있어 브랜치의 오예측 지연이 숨겨질 가능성이 있습니다.
예약역
이것은 AMD K7 및 K8 설계의 정수 섹션에서 사용되는 스타일입니다.
이름 변경 단계에서는 읽기에 대해 참조되는 모든 아키텍처 레지스터가 아키텍처 색인화된 미래 파일과 이름 변경 파일 모두에서 검색됩니다.아직 쓰기 명령이 없는 경우(즉, 준비 완료) 나중에 파일을 읽을 때 해당 레지스터의 값이 표시됩니다.명령이 이슈 큐에 배치되면 향후 파일에서 읽은 값이 예약 스테이션의 대응하는 엔트리에 기록됩니다.지시에 기입이 등록되면 준비되지 않은 새로운 태그가 이름 변경 파일에 기록됩니다.태그 번호는 보통 명령 순서로 시리얼로 할당됩니다.자유 태그 FIFO는 필요 없습니다.
태그 인덱스 방식의 경우와 마찬가지로 이슈 큐는 준비되지 않은 오퍼랜드가 일치하는 태그 브로드캐스트를 볼 때까지 기다립니다.태그 인덱스 방식과는 달리 태그가 일치하면 해당 브로드캐스트 값이 이슈 큐엔트리의 예약 스테이션에 기록됩니다.
발행된 명령은 예약 스테이션에서 해당 인수를 읽고 브로드캐스트 피연산자를 바이패스한 후 실행합니다.앞에서 설명한 바와 같이 예약 스테이션 레지스터 파일은 보통 8개의 엔트리가 있는 작은 파일입니다.
실행 결과는 순서 변경 버퍼, 예약 스테이션(이슈 큐 엔트리에 일치하는 태그가 있는 경우) 및 아키텍처 레지스터를 대상으로 하는 마지막 명령(이 경우 레지스터가 준비 완료로 표시됨)인 경우 향후 파일에 기록됩니다.
그라데이션은 리오더 버퍼에서 아키텍처 레지스터 파일로 값을 복사합니다.아키텍처 레지스터 파일의 유일한 용도는 예외 및 분기 예측에서 복구하는 것입니다.
졸업 시 인식되는 예외 및 분기 예측 오류로 인해 아키텍처 파일이 미래의 파일로 복사되고 이름 변경 파일에서 모든 레지스터가 준비 완료로 표시됩니다.보통 디코딩과 그라데이션 사이의 중간 명령에서는 미래 파일 상태를 재구성할 수 없기 때문에 일반적으로 분기 예측에서 조기 복구를 수행할 수 없습니다.
스킴의 비교
두 방식 모두 명령어는 문제 큐에 순서대로 삽입되지만 순서대로 제거됩니다.큐가 빈 슬롯을 축소하지 않으면 사용되지 않는 엔트리가 다수 있거나 여러 명령을 동시에 실행할 준비가 되었을 때 일종의 가변 priority 인코딩이 필요합니다.홀을 접는 큐는 priority 부호화가 간단하지만 큐를 통해 명령을 진행하려면 단순하지만 큰 회로가 필요합니다.
예약 스테이션은 이름 변경 단계에서는 물리 레지스터 번호를 찾아 값을 찾는 대신 레지스터 값을 직접 찾기 때문에 이름 변경에서 실행까지 지연 시간이 더 좋습니다.이 지연 시간은 분기 예측 오류 지연 시간의 구성 요소로 표시됩니다.
또한 각 로컬 레지스터 파일은 태그 색인 방식의 큰 중앙 파일보다 작기 때문에 예약 스테이션은 명령 발행에서 실행까지의 지연 시간이 더 좋습니다.태그 생성 및 예외 처리도 아래에서 설명한 바와 같이 예약 스테이션 방식에서 더 단순합니다.
예약 스테이션에 의해 사용되는 물리 레지스터 파일은 일반적으로 사용되지 않는 엔트리를 서비스 큐와 병렬로 접기 때문에 이들 레지스터 파일은 전체적으로 더 크고 태그 인덱스 방식으로 사용되는 단순한 레지스터 파일보다 더 많은 전력을 소비합니다.게다가 각 예약 스테이션의 모든 엔트리는 모든 결과 버스에 의해 기록될 수 있기 때문에, 예를 들어 기능 단위당 8개의 발행 큐 엔트리가 있는 예약 스테이션 머신에는 일반적으로 동등한 태그 색인화된 머신보다 9배 많은 바이패스 네트워크가 있습니다.따라서 결과 전송은 태그 색인화된 설계보다 훨씬 더 많은 전력과 영역을 소비합니다.
게다가 예약 스테이션 스킴은, 결과치를 격납할 수 있는 4개의 장소(Future File, Reservation Station, Reorder Buffer, Architectural File)를 가지는 반면, 태그 인덱스화된 스킴은 1개(물리 레지스터 파일)만을 가진다.이러한 모든 저장장소로 브로드캐스트되는 기능유닛의 결과는 태그 색인화된 방식보다 기계 내의 훨씬 많은 위치에 도달해야 하므로 이 함수는 더 많은 전력, 면적 및 시간을 소비합니다.그러나 매우 정확한 분기 예측 체계를 갖춘 기계에서 실행 지연 시간이 주요 관심사라면 예약 스테이션이 매우 잘 작동할 수 있습니다.
역사
IBM System/360 Model 91은 명령의 순서가 맞지 않는 실행을 지원하는 초기 머신으로 레지스터 이름 변경을 사용하는 Tomasulo 알고리즘을 사용했습니다.
POWER1은 1990년에 레지스터 이름 변경과 고장 실행을 사용한 최초의 마이크로프로세서입니다.
원래의 R10000 설계에서는 문제 큐의 축소나 가변 priority의 부호화가 없었기 때문에 결과적으로 큐 내의 가장 오래된 명령어는 이름 변경 레지스터가 없기 때문에 양쪽 명령 디코딩이 완전히 정지되고 다른 명령어가 발행될 때까지 발행되지 않는 경우가 있었습니다.R12000 이후 설계의 리비전에서는 이 문제를 완화하기 위해 부분적으로 가변적인 priority 인코더를 사용했습니다.
초기 고장 머신에서는 이름 변경과 ROB/PRF 스토리지 기능이 분리되지 않았습니다.이와 관련하여 Sohi의 RUU 또는 Metaflow DCAF와 같은 초기 모델 중 일부는 모두 동일한 구조로 결합된 스케줄링, 이름 변경 및 저장입니다.
대부분의 최신 머신에서는 논리 레지스터 번호로 맵테이블을 인덱싱하여 RAM 이름을 변경합니다.예를 들어, P6에서 이 작업을 수행했으며, 향후 파일에서도 이 작업을 수행하며 데이터 스토리지를 동일한 구조로 유지합니다.
다만, 이전의 머신에서는, 이름 변경에 Content-Addressable Memory(CAM; 컨텐츠 주소 지정 가능 메모리)를 사용했습니다.예를 들어 HPSM RAT 또는 Register Alias Table은 기본적으로 논리 레지스터 번호의 CAM을 다른 버전의 레지스터와 조합하여 사용했습니다.
많은 점에서 순서가 맞지 않는 마이크로아키텍처의 이야기는 이러한 CAM이 어떻게 점차적으로 제거되었는가 하는 것입니다.작은 CAM은 편리하지만 큰 CAM은 [citation needed]실용적이지 않습니다.
P6 마이크로아키텍처는 인텔의 마이크로아키텍처 중 처음으로 순서가 어긋난 실행과 레지스터 이름 변경을 구현한 것입니다.P6 마이크로아키텍처는 Pentium Pro, Pentium II, Pentium III, Pentium M, Core 및 Core 2 마이크로프로세서에 사용되었습니다.1995년 [1]10월 2일에 출시된 Cyrix M1은 레지스터 이름 변경과 순서가 잘못된 실행을 사용한 최초의 x86 프로세서입니다.1996년에 출시된 다른 x86 프로세서(NexGen Nx686 및 AMD K5)도 레지스터 이름 변경과 RISC μ 연산(원어민 x86 [2][3]명령어가 아닌)의 순서가 어긋난 실행을 특징으로 했습니다.
레퍼런스
- ^ "Cyrix 6x86 Processor".
- ^ "NexGen Nx686".
- ^ "PC Mag Dec 6, 1994". Ziff Davis. 1994-12-06.
- Smith, J. E.; Pleszkun, A. R. (June 1985). "Implementation of precise interrupts in pipelined processors". ACM SIGARCH Computer Architecture News. 13 (3): 36–44. doi:10.1145/327070.327125.
- Smith, J. E.; Pleszkun, A. R. (May 1988). "Implementing precise interrupts in pipelined processors". IEEE Trans. Comput. 37 (5): 562–573. doi:10.1109/12.4607.
- Smith, J. E.; Pleszkun, A. R. (1998). "Implementation of precise interrupts in pipelined processors". 25 years of the international symposia on Computer architecture (selected papers) - ISCA '98. pp. 291–299. doi:10.1145/285930.285988. ISBN 1581130589.