Chapter 4 프로세서 (4.9절, 4.12절, 4.13절)
Contents 4.1 소개 4.2 논리 설계 기초 4.3 데이터패스 설계 4.4 단순한 구현 방법 4.5 파이프라이닝 개요*** 4.6 파이프라이닝 데이터패스 및 제어*** 4.7 데이터 해저드: 포워딩 vs. 스톨링*** 4.8 제어 해저드*** 4.9 예외 처리*** 4.10 명령어 수준 병렬성 4.11 AMD Opteron X4의 파이프라인 4.12 오류와 함정 4.13 결론 2
예외(Exceptions)와 인터럽트(Interrupts) 예기치 않은 사건들은 명령어 흐름의 변화를 요구한다. ISA마다 그 사건들을 표현하는 용어들이 다르다 예외(Exception) CPU 안에서 발생한다 e.g., undefined opcode, overflow, syscall, 인터럽트(Interrupt) 외부 I/O 제어기로부터 발생한다 성능 저하 없이 예외 및 인터럽트를 처리하는 것은 어렵다 4.9 Exceptions 3
예외 처리하기(Excepting handling) MIPS에서는 예외들이 시스템 제어 코프로세서(System Control Coprocessor CP0)에 의해서 관리된다 예외 상황을 발생시키는 명령어나 인터럽트를 받은 명령어의 PC를 저장한다 MIPS에서는 Exception Program Counter (EPC)에 저장한다 발생한 예외 상황의 원인을 저장한다. MIPS에서는 Cause 레지스터에 저장한다 여기서는 1비트 Cause 레지스터를 가정해보자 0 for undefined opcode, 1 for overflow 그 다음 0x800000180번지에 있는 핸들러 루틴으로 점프한다 4
다른 대안들 벡터화된 인터럽트(Vectored Interrupts) 핸들러 주소가 원인에 의해 결정된다 예: Undefined opcode: C000 0000 Overflow: C000 0020 : C000 0040 5
ALU Computer Architecture 4-6
Computer Architecture 4-7
핸들러의 액션 원인을 읽고, 해당 핸들러 루틴으로 제어를 넘긴다 요구되는 액션(action)을 결정한다 만약, 재시작가능하다면, 예외 상황을 바로잡을 수 있는 액션을 수행한다 원래 프로그램 흐름으로 돌아가기 위해 EPC를 사용한다 재시작가능하지 않다면, 실행 중이던 프로그램을 종료시킨다 EPC와 cause 레지스터를 사용하여 사용자에게 발생한 예외 상황을 리포트한다 8
파이프라인에서의 예외 처리 또 다른 형태의 제어 해저드이다 add 명령의 EX 단계에서 overflow가 발생한 경우를 고려해 보자 add $1, $2, $1 $1 레지스터가 망가지는 것을 막는다 이전 명령어들은 실행을 완전히 끝낸다 파이프라인에 들어온 add와 후속 명령어들을 버린다 EPC와 cause 레지스터를 설정한다 제어를 핸들러에게 넘긴다 잘못 예측된 branch의 경우와 유사하다 동일한 하드웨어를 거의 그대로 사용한다 9
예외를 고려한 파이프라인 10
예외 처리의 속성 재시작가능한 예외들 파이프라인은 해당 명령어를 버릴 수 있다 핸들러가 실행된 후 그 명령어로 다시 돌아간다 그 명령어를 다시 적재해서 실행한다 EPC 레지스터에 저장된 PC 값 예외를 발생시킨 명령어를 확인시켜준다 사실, PC + 4 값이 저장되므로, 핸들러가 이것을 고려하여 PC 값이 가리키는 명령어를 원인 명령어로 판단해야 한다 11
예외 예시 add 명령어에서 예외 발생시 40 sub $11, $2, $4 44 and $12, $2, $5 48 or $13, $2, $6 4C add $1, $2, $1 50 slt $15, $6, $7 54 lw $16, 50($7) Handler 80000180 sw $26, 1000($0) 80000184 sw $27, 1004($0) 12
예외 예시 13
예외 예시 sw $26, 1000($0) 14
다중 예외 파이프라인은 복수개의 명령어들을 중첩하여 실행한다 따라서 한번에 복수개의 예외들이 발생할 수도 있다 단순 접근법: 첫번째로 발생한 예외만 처리한다 후속 명령어들을 모두 버린다 소위 정확한(precise) 예외 처리라고 부른다 복잡한 파이프라인에서는, 한 사이클에 복수개의 명령어들을 파이프라인에 집어넣는다 명령어 순서가 뒤바뀌어(out-of-order) 명령어들이 끝날 수도 있다 이 경우는 정확한 예외 처리를 하기가 어렵다 15
부정확한 예외들(Imprecise Exceptions) 파이프라인을 중단하고 상태를 저장한다 예외 발생 원인(들)을 포함하여. 핸들러가 처리하도록 한다 어느 명령어(들)이 예외를 발생시켰는지 어느 명령어가 실행을 마치거나 또는 버려질지 경우에 따라서는 수동적인(manual) 종료가 필요할 수도 있다 H/W는 단순해지지만, 핸들러 S/W는 더 복잡해진다 다중 이슈 out-of-order 파이프라인에서는 정확한 예외 처리가 어렵다 16
Contents 4.1 소개 4.2 논리 설계 기초 4.3 데이터패스 설계 4.4 단순한 구현 방법 4.5 파이프라이닝 개요*** 4.6 파이프라이닝 데이터패스 및 제어*** 4.7 데이터 해저드: 포워딩 vs. 스톨링*** 4.8 제어 해저드*** 4.9 예외 처리*** 4.10 명령어 수준 병렬성 4.11 AMD Opteron X4의 파이프라인 4.12 오류와 함정 4.13 결론 17
오류와 함정 형편없는 ISA 설계는 파이프라이닝을 더 어렵게 만들 수 있다 예) 복잡한 명령어 집합들 (VAX, IA-32) IA-32 micro-op 접근방식 4.13 Fallacies and Pitfalls 18
결론 ISA는 데이터패스와 제어에 영향을 준다 반대로, 데이터패스와 제어는 ISA 설계에 영향을 준다 파이프라이닝은 병렬성을 이용해서 명령어 처리량을 높인다 초당 더 많은 수의 명령어를 실행할 수 있다 각 명령어의 지연 시간은 줄어들지 않는다 해저드: 구조 / 데이터 / 제어 해저드 4.14 Concluding Remarks 19