Lec 5 · Exception 처리, R4000, static scheduling 과 decoupled execution

1.104강 덱 뒷부분: exception·interrupt·trap 정의, precise interrupt, trap handler, 5-stage pipeline 의 exception 처리와 speculation 관점.

1.2MIPS R4000 8-stage pipeline(load-use, branch, FP)과 SPEC92 CPI 분석.

1.305강 덱: static scheduling(재배치, loop unrolling)과 decoupled execution, IBM Stretch·CDC 6600, complex pipeline 동기 (p18 까지, p19~38 은 다음 강의).

상황·문제project proposal 은 이번 수요일까지 PDF 로 이메일 제출. 지난 강의 basic pipelining 에 이어 exception 부터 시작.

상황·문제pipeline 실행 중 예상 밖 상황을 exception, trap, interrupt 로 부르는데 가리키는 대상이 다르다.

원인exception = program 실행 중 생기는 내부 이벤트(page fault, arithmetic overflow/underflow). 무엇이 exception 인지는 ISA 정의에 따름 (RISC-V 는 overflow 가 exception 이 아님).

해결interrupt = 외부 장치(keyboard, mouse, disk, network card) 신호. trap = exception·interrupt 로 supervisor(OS·hypervisor) 로 제어가 넘어가는 것. IEEE 754 floating point 예외처럼 trap 을 안 일으키는 경우는 FPU status 를 직접 확인.

상황·문제초기 컴퓨터는 overflow 같은 예외와 I/O 이벤트를 어떻게 처리했나.

원인Babbage 의 Analytical Engine 에도 overflow exception 이 있었고, 첫 trap 시스템은 UNIVAC-I(1951): overflow 시 주소 0 의 2-instruction fix-up routine 실행 또는 정지.

해결후속 UNIVAC 에 external interrupt 추가(실시간 wind tunnel data). DYSEAC(1954) 는 첫 I/O interrupt 시스템: PC 2개(정상용·I/O 처리용), DMA 지원, 트럭 2대(20 ton)로 옮긴 미 육군용 이동식 컴퓨터.

상황·문제I/O 장치가 priority 가 있는 interrupt request line 을 올리면 processor 가 실행 중인 program 을 멈추고 handler 로 가야 한다.

원인어디서 멈췄는지가 명확해야 handler 뒤에 정상 실행을 재개할 수 있다.

해결instruction Ii 에서 멈추고 Ii-1 까지 모두 완료, Ii 이후는 실행 안 된 것처럼 보이게 함 (precise interrupt). Ii 의 PC 를 EPC 에 저장, interrupt 를 끄고 supervisor mode 의 handler 로 점프, 끝나면 Ii 로 복귀.

상황·문제handler 실행 중에 또 interrupt 가 오면 EPC 가 덮여 원래 복귀 주소를 잃는다.

원인EPC 는 special register 라 일반 instruction 으로 접근 불가. lower priority interrupt 가 계속 오면 deadlock 가능.

해결privileged instruction 으로 EPC 를 GPR 로 옮겨 memory 에 저장한 뒤 interrupt 재허용(nested interrupt). 그동안 lower priority interrupt 는 mask. status(cause) register 로 원인 확인, ERET 로 interrupt 재허용·user mode 복귀·상태 복원.

상황·문제특정 instruction 이 일으키는 exception (예: page table 에 없는 주소를 load → page fault).

원인그 instruction 은 완료될 수 없고, 뒤에 부분 실행된 instruction 의 효과도 되돌려야 한다.

해결handler 후 원인 instruction 에서 재시작 (접근 권한 위반이면 program 을 kill). 단 system call trap(printf 등)은 instruction 이 완료된 것으로 보고 다음 instruction 에서 재개 — 아니면 system call 을 무한 반복.

상황·문제IF(PC address exception), ID(illegal opcode), EX(overflow), MEM(data address exception) 각 stage 에서 exception 이 동시에 날 수 있고, asynchronous interrupt 도 들어온다.

원인앞선 instruction 은 정상 완료시키고, 뒤 instruction 은 없던 일로 만들어야 precise 하게 handler 로 갈 수 있다.

해결exception flag·PC 를 pipeline latch 로 commit point(M stage) 까지 전달. 한 instruction 에선 앞 stage 의 exception 이 우선. async interrupt 는 commit point 에 주입. commit 에서 trap 이면 Cause·EPC 갱신, 모든 stage kill, handler PC 를 fetch 에 주입.

상황·문제fetch 시점에는 그 instruction 이 나중에(예: MEM 의 page fault) exception 을 낼지 모른다.

원인그래도 실행을 계속하는 것은 '예외 없음' 을 예측하는 speculation. exception 은 드물고 I/O 는 processor 에 비해 매우 느려 예측이 거의 맞다.

해결예측 확인은 pipeline 끝에서, 복구는 architectural state 를 commit point 에서만 갱신해 부분 실행분을 버리고 flush 후 handler 시작. 결과는 bypass(forwarding)로 후속 instruction 이 쓰므로 성능 손해 없음.

상황·문제memory access 를 1 cycle 로 두면 clock frequency 를 희생해야 한다.

원인R4000 은 I-cache·D-cache 접근을 여러 cycle 로 나눠 8 stage(IF IS RF EX DF DS TC WB). cache 접근은 3 cycle.

해결direct-mapped cache 라 tag check 전에 데이터를 쓸 수 있음: I-cache tag check 는 RF 에서 decode 와 병렬, D-cache 는 DS 끝에 데이터를 ALU 로 forward 하고 TC 에서 tag check. miss 면 kill/bubble 후 재실행. set-associative 면 더 까다로움.

상황·문제branch 조건이 EX 에서 결정되어 3 cycle branch delay.

원인1개는 branch delay slot(항상 실행), 나머지 2개는 predict not-taken 으로 추측 → 틀리면 kill. 이후 MIPS 는 dynamic branch prediction 도입.

해결FPU 는 variable latency: 단순 연산 2~4 cycle, multiply/divide/sqrt 는 훨씬 김. initiation interval 때문에 divide 는 35 cycle, sqrt 는 111 cycle 후에야 다음 발행. S+A 는 두 stage 동시 사용, D28 은 D stage 28회 반복, 같은 stage 충돌 시 structural hazard stall.

상황·문제perfect cache 가정에서 SPEC92 정수 5개·FP 5개의 pipeline CPI 를 stall 원인별로 분해.

원인base CPI 1 위에 load stall(직전 load 의존, forwarding 불가), branch stall, FP result stall(FP RAW), FP structural stall 이 더해짐.

해결정수 program 은 branch stall 이, FP program 은 FP result stall 이 주된 CPI 기여. 그림들은 교재 Appendix C 에서 가져옴.

상황·문제vector add loop(fld×2, fadd.d, fsd, addi×3, bne)를 그대로 쓰면 긴 latency load 때문에 stall 이 생긴다.

원인scheduling 은 static(programmer·compiler) 과 dynamic(hardware) 두 가지. 한 iteration 안에는 병렬성이 적다.

해결독립인 pointer 증가 addi 를 load 뒤로 끌어올려 latency 를 가림 (fsd offset 은 -8). loop unrolling(2회) 으로 load 4, fadd 2, fsd 2 에 pointer 증가 16 → 병렬성 증가, dynamic instruction 수·branch 수 감소. 한계: architectural register 수(spill), I-cache footprint 증가, compiler 복잡도. software pipelining 도 비슷한 문제.

상황·문제static scheduling 대신 microarchitecture 로 program 에 내재한 병렬성을 끌어낼 수 없나.

원인control·address 계산(addi, bne, load 주소)은 data 계산(fadd)에 의존하지 않아 먼저 진행할 수 있다.

해결integer pipeline 이 주소·branch 를 처리하고 load 를 memory 로 보냄, 데이터는 load data queue 로. fld/fadd/fsd 는 µop(load data writeback, compute, store data read)으로 µop queue 에 넣어 FP pipeline 이 데이터 도착 시 실행. load 는 store address queue 와 비교해 일치하면 store data queue 에서 값을 받음.

상황·문제decoupled execution 을 쓴 초기 기계의 사례.

원인목표는 IBM 704 대비 100배. 4-stage lookahead pipeline 으로 indexing·branch 를 data 연산보다 앞서 speculative 하게 실행, 단순 store buffer 보유.

해결실제 성능은 30배에 그쳐 고객 불만, 초기 납품 후 철수. 하지만 개발 기술은 이후 IBM 기계로 이전.

상황·문제supercomputer 는 주어진 문제에서 가장 빠른 기계. top500.org 는 LINPACK 을 제출한 기계만 등재 (Google data center 는 없음). compute-bound 문제가 I/O-bound 로 바뀜.

원인Seymour Cray 의 CDC 6600(1964)이 첫 supercomputer 로 간주: 60-bit word, 128K word memory 32 bank, 10 functional unit(비pipeline), hardwired control, scoreboard 로 dynamic scheduling, I/O 용 peripheral processor 10개, 10 MHz, 750 ft², 5 ton, 150 kW.

해결load/store architecture(초기 RISC 형태): X 8개(60-bit), A 8개, B 8개. A1~A5 갱신 시 load, A6~A7 갱신 시 store 가 시작 → address/data register 분리로 decoupled 하게 다수의 outstanding load. IBM Watson 메모('청소부 포함 34명')에 Cray: '스스로 답했다'.

상황·문제오늘날 processor 는 decoupled 대신 functional unit 이 많은 단일 pipeline 에서 dynamic scheduling 으로 ILP 를 뽑는다.

원인long-latency load·FP unit, 가변·예측 불가 memory latency, 다수의 arithmetic·memory unit 이 pipeline 을 복잡하게 만든다.

해결execute·write-back stage 의 structural conflict, out-of-order write hazard, exception 처리 문제를 다음 강의(수요일)에서 계속. proposal 은 수요일까지 이메일 제출.

Ii-1 까지 모두 완료, Ii 이후는 실행 안 된 상태로 handler 에 진입.

중단된 instruction 의 PC 를 저장하는 special register. nested interrupt 전에 memory 로 저장.

handler 복귀용 특수 jump. interrupt 재허용, user mode 복귀.

특정 instruction 이 일으킴(page fault). system call 은 완료로 간주.

architectural state 를 갱신하는 지점. exception·interrupt 를 여기서 처리.

여러 iteration 을 한 번에 → 병렬성↑, branch·pointer 갱신↓. register·I-cache 부담.

주소·control 계산과 data 계산을 queue 로 분리된 pipeline 에서 실행.

CDC 6600 의 instruction 의존성 검사·dynamic scheduling 장치.

4.1exception, interrupt, trap 의 차이는?

4.2page fault 와 system call 은 handler 후 어디서 재개하나?

4.3여러 stage 에서 동시에 exception 이 나면?

4.4state 를 commit point 에서만 갱신해도 성능이 괜찮은 이유는?

4.5R4000 이 tag check 전에 데이터를 쓸 수 있는 이유는?

4.6loop unrolling 이 dynamic instruction 수를 줄이는 이유와 한계는?