컴퓨터 구조 - CPU 구조 - 파이프라인
Pipelining
1. CPU가 명령어를 처리하는 절차들(MIPS 기준)
- IF : Instruction fetch, 명령어를 갖고 오고 프로그램 카운터에 업데이트하는 과정
- Dec : Decode, 명령어를 해석하고 레지스터에 패치하는 과정
- Exec : Execution, 명령어를 실행하는 과정으로 계산하거나 메모리 주소를 계산하는 과정
- Mem : Memory read/write, 데이터 메모리에서 데이터를 읽거나 쓰는 과정
- WB : Write back, 연산 결과 데이터를 레지스터에 쓰는 과정
모든 명령어가 다음의 절차를 거치는 것은 아니다. 단순 연산인지, 혹은 분기문인지등 각 명령어의 타입에 따라 필요한 절차가 달라진다.
전체 절차는 CPU의 종류와 파이프라인 수준에 따라 달라진다.
2. 파이프라인의 이점
아래의 그림을 보자
위의 명령어 3개를 실행할 때 한 개의 명령어에 cpu 모두를 점유하는 single-cycle 방식의 경우 총 2400 ps후에나 완료되지만 pipeline으로 처리를 하게 되면 아래와 같이 된다.
Instruction Fetch부분이 끝나자마자 다음 명령어에 대해서 Instruction Fetch가 시작되면서 각 절차마다 명령어가 실행된다. 이렇게 되면 완료 시기는 1300 ps 이후가 된다. 약 명령어 하나당 800ps 소요되던게 200ps까지 줄어드는 셈이다.
3. 파이프라인의 단점
파이프라인으로 명령어를 실행할시에 생길 수 있는 오류가 있다.
이 오류의 종류는 총 3가지이고 아래와 같다.
1) Structural Hazard
구조적인 위험이다. 서로 다른 명령어가 동시에 동일한 하드웨어를 사용하려고 시동할 경우에 발생한다.
기다린다. (stall, 대상 사이클 파이프라인에 명령어 입력 방지)
당연하지만 CPU 성능에 영향이 간다.동일한 메모리에서 명령어 읽기와 데이터 읽기가 동시에 일어나야할 경우 문제가 된다.
이럴땐 명령어 구역과 데이터 구역을 분리해서 사용한다.동일한 레지스터에서 읽기와 쓰기가 동시에 일어날 경우
사이클 전반부에는 읽고, 후반부에서 쓰기를 처리함으로써 회피할 수 있다.
2) Data Hazard
필요한 데이터가 준비되기 전에 이를 사용하려 들때 발생한다.
반영될때까지 기다린다. (stall, 대상 사이클 파이프라인에 명령어 입력 방지)
연산결과가 아직 메모리나 레지스터에 반영되지 않았음에도 해당 메모리나 레지스터를 참조하는 경우
이 경우는 연산 결과를 바로 ALU에 집어넣어줌으로써 해결 할 수 있다.(Data Forwarding)
3) Control Hazard
조건이 평가되기 전에 프로그램 제어 흐름에 대해 결정을 내리려고 할때 발생한다.
이는 다음 명령어의 흐름이 순차적이지 않을때 발생하는데 분기문에서 많이 발생한다.
이런 경우 총 4가지 해결책이 있다.
Flush(CPU의 명령어를 비워버리기)나 stall(한 사이클 정지)한다.
결정을 미뤄서 영향이 가지 않는 다른 명령어부터 실행하도록 만든다. (컴파일러에서 지원한다면)
예측해서 실행한 다음에 들어 맞길 빈다. 안 맞으면? flush로 파이프라인을 비워버린다.
이런 방식은 하드웨어에서 지원해야한다.
참고자료
- Computer Organization and Design-The hardware/software interface, 5th edition, Patterson, Hennessy, Elsevier