Lec 12 · 고급 CPU microarchitecture: ILP, superscalar, register renaming

1.1앞 13분: Lecture 11 마무리 — nested interrupt, interrupt priority, exception 용 pipeline flush.

1.2성능 = T_cyc × CPI × instruction count, 여기에 program 의 ILP 가 superscalar(N)·superpipelined(M) 성능을 결정.

1.3in-order pipeline 은 independent instruction 도 dependency stall 에 같이 묶인다 → out-of-order execution 필요.

1.4WAR·WAW false dependency 는 hardware register renaming(map table + free list)으로 제거, physical register 는 새 binding 을 만든 instruction commit 때 반환.

1.5마지막에 OoO execution(dynamic scheduling)과 in-order commit 개념만 소개, 세부는 다음 강의.

상황·문제handler 진입 시 HW 가 interrupt 를 자동 disable. 지금까지 본 short handler 는 re-enable 하지 않았다.

원인handler 가 길면 그동안 오는 interrupt 를 놓친다. 그냥 enable 하면 다음 interrupt 가 EPC(SEPC)·cause·status 를 덮어써 복귀 PC 를 잃는다.

해결EPC 와 쓸 register 를 stack 에 저장한 뒤 status 의 interrupt enable bit 를 켠다. 끝에서 다시 disable 하고 복원 후 복귀.

상황·문제interrupt source 마다 중요도가 다르다. mouse click 하나는 놓쳐도 되지만 disk failure 는 안 된다.

원인handler 안에서 모든 interrupt 를 re-enable 하면 interrupt 가 끝없이 들어와 정상 실행으로 돌아오지 못할 수 있다 (강의 표현 deadlock).

해결status register mask 로 priority 별로 선택 disable. 처리 중에는 더 높은 priority 만 re-enable.

상황·문제interrupt·exception 시 handler 로 jump 하려면 이미 pipeline 에 들어온 younger instruction 을 없애야 한다.

원인기존 5-stage datapath 에는 stage 별 flush 제어와 handler 주소 선택 경로가 없다.

해결ID·EX stage 앞에 0 을 넣는 mux(IF.Flush, ID.Flush, EX.Flush)로 pipeline register 를 0 으로 채워 flush. IF 의 PC mux 에 handler 주소 입력 추가.

상황·문제chat 으로 출석 확인 후 본 주제(Advanced CPU microarchitecture)로 넘어감.

상황·문제지금까지 만든 5-stage RISC-V 보다 성능을 높이려면 superscalar, superpipelining, out-of-order execution(비순차 실행) 같은 기법이 필요하다.

원인pipeline 을 공격적으로 만들수록 data·control·structural hazard 가 stall 을 만들어 성능을 깎는다.

해결세 hazard 를 복습: data 는 instruction 간 data dependency, control 은 PC dependency, structural 은 resource 부족.

상황·문제CPU 성능 척도는 wall-clock time 이고 T_cyc × CPI × instruction count 로 나뉜다.

원인T_cyc 는 가장 긴 stage 의 max combinational delay, CPI 는 microarchitecture, instruction count 는 ISA·compiler 가 정한다.

해결식에 드러나지 않는 ILP(instruction-level parallelism, 명령어 수준 병렬성)도 성능을 좌우한다. 같은 instruction 수라도 ILP 에 따라 성능이 달라진다.

상황·문제program A 는 back-to-back dependency 가 많고 program B 는 independent instruction 이 많다. B 가 stall 이 적어 더 빠르다.

원인ILP 는 processor 가 아니라 program 의 성질이다. true dependency 가 있는 instruction 만 순서대로 실행해야 한다.

해결평균 ILP = (program 의 instruction 수) / (PE 가 무한할 때 필요한 cycle 수). PE(processing element)는 1 cycle 에 1 instruction 실행.

상황·문제baseline 5-stage scalar pipeline 은 operation latency 1, peak IPC 1 이라 ILP ≥ 1 이면 최대 성능.

원인superpipelined 는 baseline cycle 을 M 개 minor cycle 로 쪼개 minor cycle 마다 1개 완료, superscalar 는 폭 N 개 pipeline 을 둔다. 둘 다 operation latency 는 1 baseline cycle 그대로.

해결peak IPC 가 M (또는 N) 배가 되지만 program 에 ILP ≥ M (N) 이 있어야 그 성능이 나온다. 부족하면 stall.

상황·문제2-way superscalar 는 stage 마다 자원 2배가 필요: I-cache fetch 대역폭, register file read·write port, ALU 2개.

원인D-cache 처럼 늘 두 배로 할 수 없는 자원이 있다. 같은 cycle 의 두 ALU 사이 forwarding 은 stage 가 ALU latency 의 2배보다 길어야 해 비현실적.

해결같은 cycle 에 issue 하는 두 instruction 은 서로 independent 해야 하고, dependent 면 두 번째를 stall 한 뒤 forwarding.

상황·문제superpipelined 이면서 superscalar 인 CPU 는 매 cycle N×M 개 independent instruction 이 필요하고, full forwarding 으로도 dependency stall 이 잦다.

원인addf→mulf RAW 로 mulf 가 D 에서 stall(근본 문제). 뒤의 subf 는 independent 인데 D stage 를 mulf 가 차지(structural hazard)하고 program order 때문에 추월 못 해 같이 stall.

해결subf 를 먼저 실행해도 결과는 맞다. 이 stall 은 근본 문제가 아니므로 out-of-order execution 으로 해결.

상황·문제instruction 을 out-of-order 로 실행하려면 WAR(write-after-read)·WAW(write-after-write) dependency 가 문제다. 먼저 실행하면 잘못된 operand·최종값이 남는다.

원인WAR·WAW 는 data 가 아니라 register 이름이 겹쳐서 생기는 false dependency. RISC-V 는 architectural register 가 32개뿐이라 이름을 재사용하게 된다.

해결register 가 무한하면 WAR·WAW 를 완전히 제거 가능. CPU 안에 register 를 더 두고(예 60개) 이름을 바꿔 쓰는 것이 register renaming.

상황·문제원래 4개 instruction 은 RAW(파랑)와 WAR·WAW(빨강) 때문에 infinite PE 로도 4 cycle, ILP = 4/4 = 1.

원인3·4번째 instruction 의 r1·r3 가 앞 instruction 과 이름만 겹친다.

해결r8, r9 로 이름을 바꾸면 독립 쌍 두 개가 생겨 ILP = 4/2 = 2. 순서를 바꾸면 superpipelining, 여러 pipeline 이면 superscalar 로 빨라진다.

상황·문제compiler 가 이미 만든 program 을 software 도움 없이 hardware 가 rename 해야 한다.

원인rename table 이 architectural register → physical register binding 을 유지. compiler 는 physical register 를 모르고, 개수·구성은 microarchitecture 마다 다르다.

해결rd 를 쓰는 instruction 이 issue 될 때 free physical register px 를 할당해 binding 기록. source 는 table 을 보고 변환.

상황·문제질문: architectural register 를 그냥 늘리면? free list 는 낭비 아닌가? physical register 는 몇 개 필요? rename 으로 cycle 이 길어지나?

원인architectural register 수는 ISA 가 정한다. 늘리면 instruction 길이가 늘고 RISC-V 가 아닌 다른 architecture 가 된다.

해결ISA 호환을 지키며 physical register 를 늘리고 동적으로 mapping. 필요한 수는 pipeline 에 동시에 있는 instruction 수와 관계, diminishing return·용도(server vs mobile)로 결정. rename 은 decode stage 에 넣거나 table 이 크면 별도 stage.

상황·문제r1 의 binding 이 p4 에서 p7 로 바뀐 뒤 p4 를 언제 free 해도 되는가?

원인새 binding 이 생겼다고 바로 지우면, 아직 실행 안 된 이전 instruction 이 p4 대신 p7 을 보게 되어 결과가 달라질 수 있다 (OoO 에서).

해결r1 에 새 binding 을 만든 instruction 이 commit 될 때(pipeline 에서 가장 오래된 instruction 으로 실행 완료) 이전 binding(r1→p4)을 제거.

상황·문제중간고사가 다음 시간까지 범위이며 일정(화요일)을 다시 공지하겠다고 안내.

상황·문제renaming 으로 WAR·WAW 는 사라지지만 RAW 에서는 reader 가 writer 결과를 기다려야 한다(근본적).

원인independent instruction 은 기다릴 이유가 없는데 in-order 는 program 순서로 막는다.

해결hardware 가 동적으로 independent instruction 을 먼저 issue 하는 OoO execution(=dynamic instruction scheduling). 단 외부에 드러나지 않게 architectural state 갱신(commit)은 in-order.

handler 안에서 EPC 등 저장 후 interrupt 를 re-enable. 더 높은 priority 만 허용.

program 의 성질. instruction 수 / 무한 PE 로 필요한 cycle 수.

baseline cycle 을 M minor cycle 로 쪼개 minor cycle 마다 1개 완료. ILP ≥ M 필요.

폭 N 의 병렬 pipeline, peak IPC N. 매 cycle N 개 independent instruction 필요.

WAR·WAW. data 가 아니라 register 이름 재사용에서 생긴다.

architectural register 를 매번 새 physical register 에 mapping 해 false dependency 제거.

architectural → physical binding 표. write 마다 새 binding, read 는 표 조회.

할당 가능한 physical register 목록. 이전 binding 은 새 binding 을 만든 instruction 의 commit 때 반환.

independent instruction 을 먼저 issue 하는 dynamic scheduling. commit 은 in-order.

architectural state 갱신을 program order 로 해 OoO 를 외부에 숨긴다.

4.1handler 안에서 interrupt 를 re-enable 하기 전에 무엇을 해야 하나?

4.2100개 instruction 중 2개만 서로 dependent 이면 ILP 는?

4.3superpipelined(M) + superscalar(N) CPU 가 peak 성능을 내려면?

4.4in-order pipeline 예제에서 subf 가 stall 되는 이유 두 가지는?

4.5WAR·WAW 를 false dependency 라 부르는 이유는?

4.6div r1,4,r1 은 slide 22 예제에서 어떻게 rename 되나?

4.7RISC-V architectural register 를 48개로 늘리지 않는 이유는?