[컴퓨터 구조] 프로세서[2] - 파이프라이닝

 

 

 

 

 

 

 

🧐 단일 사이클 구현

단일 사이클 구현은 비록 올바르게 동작한다 하더라도 비효율성 때문에 사용되지 않습니다.

 

이유는 너무 분명한데, 단일 사이클 설계에서는 클럭 사이클이 모든 명령어에 대해서 같은 길이를 가져야 하기 때문에 클럭 사이클을 가장 오래 걸리는 명령어에 맞추어야 하기 때문입니다.

 

해당 명령어는 적재 명령어라는 것이 거의 확실한데, 적재 명령어는 명령어 메모리, 레지스터 파일, ALU, 데이터 메모리, 레지스터 파일의 5개 기능을 모두 사용하기 때문입니다.

 

 

 

 

 

 

 

 

 

 

 

 

🧐 파이프라이닝의 이해

파이프라이닝은 여러 명령어가 중첩되어 실행되는 구현 기술입니다.

파이프라이닝의 이해를 돕기 위해 세탁을 진행하는 예시를 들어 살펴보도록 하겠습니다.

 

 

우선 파이프라이닝을 사용하지 않은 세탁 방법은 다음과 같습니다.

1. 세탁기에 옷을 넣습니다.
2. 세탁이 끝나면 건조기에 넣습니다.
3. 건조가 끝나면 옷을 잘 개어둡니다.
4. 옷을 옷장에 넣습니다.

 

이렇게 한 과정이 끝나면 다음 옷들을 빨기 시작합니다.

 

이를 그림으로 표현하면 아래와 같습니다.

 

 

 

 

이를 파이프라이닝을 사용하면 다음과 같아집니다.

 

 

즉 세탁이 끝나는 순간 다음 세탁물을 세탁기에 넣고, 동시에 빨래가 끝난 옷은 건조기에 넣습니다.

이후 과정도 그림을 보면 충분히 이해할 수 있을 것이라 생각하여 넘어가겠습니다.

 

 

 

위 세탁 예제를 통한 중요한 관찰은 다음과 같습니다.

각 단계마다 별개의 자원을 사용한다면 작업들을 파이프라이닝 할 수 있습니다.

파이프라인의 역설적인 점은 양말 하나만을 세탁하는 과정과 여러 옷들을 세탁하는 과정에 걸리는 시간이 동일하다는 것입니다.

 

 

파이프라이닝을 사용하면 성능이 향상되는 이유는 각 단계를 병렬로 동작시켜 같은 시간에 더 많은 일을 처리할 수 있도록 하기 때문입니다.

파이프라이닝은 처리 시간은 오히려 증가시키지만, 처리량을 극대화시켜 시간을 감소시킵니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🧐 파이프라인과 데이터패스 제어

우선 명령어는 다음과 같이 5단계로 나눌 수 있습니다.

IF (Instruction Fetch): 명령어 인출

ID (Instruction Decode): 명령어 해독 및 레지스터 파일 읽기

EX (Execution/Address Calculation): 실행 또는 주소 계산

MEM (Memory Access) : 메모리 접근

WB (Write Back) : 쓰기

 

 

 

 

아래 그림을 보면 위 5개의 단계가 데이터패스를 그리는 방법에 어느정도 알맞다는 것을 알 수 있습니다.

명령어와 데이터가 이 다섯 단계를 왼쪽에서 오른쪽으로 지나가면서 실행을 마칩니다.

 

그러나 위 흐름을 어기는 두 가지 예외가 있습니다.

WB 단계 : 이 단계에서는 결과를 데이터패스 중앙에 있는 레지스터 파일에 씁니다.

PC 다음 값 선정: 증가된 PC값과 MEM 단계의 분기 주소 중에서 고릅니다

오른쪽에서 왼쪽으로 거꾸로 흐르는 데이터는 현재 명령에는 영향을 주지 않으며 파이프라인 뒤쪽에 존재하는 명령어에만 영향을 미칩니다.

 

WB 단계에서는 데이터 해저드를, PC의 다음 값을 선정하는 단계에서는 제어 해저드를 일으킬 수 있습니다.

 

 

 

 

 

 

명령어의 5단계 각각을 수행하는 동안, 각 명령어의 값, 레지스터의 값 등을 유지하기 위해서 해당 단계에서 사용중인 값을 레지스터에 저장해야 합니다.

 

이때 사용되는 레지스터를 파이프라인 레지스터라고 합니다.

 

아래는 파이프라인 레지스터가 강조된 파이프라인 데이터패스입니다.

 

모든 명령어는 매 클럭 사이클마다 한 파이프라인 레지스터에서 다음 레지스터로 전진합니다.

파이프라인 레지스터의 이름은 해당 레지스터가 분리하고 있는 두 단계의 이름을 따서 붙여집니다.

예를 들어 IF 단계와 ID 단계 사이의 파이프라인 레지스터는 IF/ID라고 부릅니다.

 

쓰기(WB) 단계 뒤에는 파이프라인 레지스터가 없습니다.

모든 명령어는 프로세서의 상태(레지스터 파일, 메모리, PC)를 갱신해야 합니다.

이렇게 갱신되는 상태는 별도의 파이프라인 레지스터가 필요하지 않습니다.

 

모든 명령어는 PC값을 증가시키든, 분기 목적지 주소로 바꾸든 아무튼 PC 값을 바꿉니다.

PC는 IF 단계 앞에 있는 파이프라인 레지스터라 생각할 수 있습니다.

 

 

이제 명령어가 파이프라인의 각각의 단계를 통과해 가면서 활성화되는 데이터패스 부분을 살펴보도록 하겠습니다.

 

레지스터나 메모리를 읽을 때에는, 레지스터 또는 메모리의 오른쪽 반을 파랗게,

쓰기를 행할 때에는 왼쪽 반을 파랗게 칠합니다.

 

 

 

 

👉 IF 단계 - 모든 명령어 동일

 

 

 

 

 

 

👉 ID 단계 - 모든 명령어 동일

 

 

 

 

 

 

 

👉 EX 단계 - 적재 명령어의 경우

적재 명령어는 immediate와 베이스 레지스터 1개를 EX 단계에서 사용합니다.

 

 

 

 

 

 

 

 

👉 MEM 단계 - 적재 명령어의 경우

적재 명령어는 MEM 단계에 메모리를 읽기 위해 사용합니다.

 

 

 

 

 

 

 

 

 

👉 WB 단계 - 적재 명령어의 경우

 

적재 명령어가 실행되는 과정을 통해 파이프라인의 후속 단계에서 필요한 모든 정보가 파이프라인 레지스터를 따라 전달되어야 한다는 것을 알 수 있습니다.

 

또한 데이터패스의 각 구성 요소(명령어 메모리, 레지스터 읽기 포트, ALU, 데이터 메모리, 레지스터 쓰기 포트 등)는 한 파이프라인 단계에서만 사용될 수 있다는 것도 알 수 있습니다.

그렇지 않다면 구조적 해저드를 발생시킵니다.

 

 

위 적재 명령어 설계는 사실 잘못된 설계인데, 이제부터 그 이유를 알아보도록 하겠습니다.

 

적재 명령어의 최종 단계에서 값이 바뀌는 레지스터는, IF/ID 단계에 위치한 명령어에 의해 제공됩니다.

이는 적재 명령어보다 나중에 나오는 명령어입니다.

 

따라서 적재 명령어가 읽어온 값을 정확한 위치에 저장하기 위해서는 목적지 레지스터 번호를 저장할 필요가 있습니다.

이를 표현한 올바른 데이터패스는 다음과 같습니다.

 

 

 

 

 

 

 

 

 

🧐 파이프라인 제어

이제 파이프라인 데이터패스에 제어를 추가하도록 하겠습니다.

이는 이전 글에서 사용된 제어와 동일합니다.

 

 

 

 

 

제어는 ID 단계에서 생성되며, 생성된 7개의 제어선 중 2개가 EX단계에서 사용되고 나머지 5개의 제어선은 다음 단계로 넘어갑니다.

 

 

 

 

 

 

 

이를 추가한 데이터패스는 다음과 같습니다.

 

파이프라이닝을 위한 제어를 명시하기 위해서는 각 파이프라인 단계 동안의 제어값들을 정하기만 하면 됩니다.

 

각 제어선은 한 파이프라인 단계에서만 활성화되는 구성 요소들과 관련 있기 때문에 제어선을 파이프라인 단계에 따라 다섯 그룹으로 나눌 수 있습니다.

1. 명령어 인출(IF) : 없음

명령어 메모리를 읽는 제어 신호와 PC에 쓰는 제어 신호는 항상 인가되어 있으므로 이 파이프라인 단계에는 특별히 제어할 것이 없습니다.

2. 명령어 해독 / 레지스터 파일 읽기(ID) : 없음

RISC-V 명령어 형식에서는 2개의 근원지 레지스터 번호가 항상 같은 위치에 있습니다.
따라서 이 파이프라인 단계에서는 특별히 제어할 것이 없습니다.

3. 실행 / 주소 계산 (EX) : ALUOp, ALUSrc

이 신호들은 ALU 연산을 선택하고, Read data 2와, 부호확장된 수치값(immediate) 중 하나를 ALU의 입력으로 선택합니다.

4. 메모리 접근 (MEM) : MemRead, MemWrite, Branch

이 신호들은 각각 적재(ld), 저장(sd), beq 명령어일 때 인가됩니다.
(Branch는 사실 이 전 단계에, 혹은 더 줄여서 ID 단계에서 결정될 수 있습니다. 이는 제어 헤저드를 줄이기 위한 방법입니다.)

5. 쓰기 (WB) : MemToReg, RegWrite

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🧐 파이프라인 해저드(hazard)

다음 명령어가 다음 클럭 사이클에 실행될 수 없는 상황이 있습니다.

이러한 사건을 해저드라 부르는데, 해저드에는 구조적 해저드, 데이터 해저드, 제어 해저드가 있습니다.

 

 

 

 

 

 

 

🧐 구조적 해저드

같은 클럭 사이클에 실행하기를 원하는 명령어의 조합을 하드웨어가 지원할 수 없기 때문에 발생합니다.

예를 들어 이전에 살펴본 데이터패스 그림에서 메모리가 한개라고 생각을 한다면 load 혹은 store 인스트럭션을 실행하게 되면 메모리에 접근하게 되는데, 이 경우 다음 인스트럭션을 fetch하기 위해서도 메모리에 접근하므로 구조적 해저드를 피할 수 없습니다.

(이를 방지하기 위해 명령어를 위한 메모리 캐시와 데이터를 위한 메모리 캐시를 따로 두어 이들을 사용합니다.)

 

또한 레지스터의 경우에도 읽기와 쓰기가 동시에 발생하는 경우에는 구조적 해저드를 피할 수 없지만, 이를 방지하기 위해 클럭 사이클의 전반부에는 레지스터 쓰기가, 후반부에는 레지스터 읽기가 발생한다고 하겠습니다.

 

 

 

 

 

 

 

 

 

 

🧐 데이터 해저드

어떤 단계가 다른 단계가 끝나기를 기다려야 하기 때문에 파이프라인이 지연되어야 하는 경우 발생합니다.

다음 상황을 생각해 보면 이해하기 쉽습니다.

add x19, x0, x1
sub x2, x19, x3

위 상황에 별 다른 조치가 없다면 데이터 해저드가 발생하여 파이프라인을 지연시킬 수 있습니다.

add 명령어에서는 5번째 단계에서 x19에 계산 결과를 쓰기 때문에, 2번째 단계에서 레지스터를 읽어야 하는 sub 명령어의 경우 3개의 클럭 사이클을 낭비하게 됩니다.

 

즉 위와 같이 컴퓨터 파이프라인에서는 어떤 명령어가 아직 파이프라인에 있는 앞선 명령어에 종속성을 가질 때 데이터 해저드가 발생합니다.

 

이러한 데이터 해저드를 해결하기 위한 방법으로는 전방전달(forwarding)이 있습니다.

전방전달은 또한 우회전달(bypassing)이라고도 합니다.

 

 

 

 

👉 전방전달

전방전달은 명령어가 끝날 때까지 기다릴 필요가 없다는 관찰에 기반을 두고 있습니다.

 

위의 데이터 해저드가 발생하는 코드를 예시로 들면, ALU가 add의 합을 만들자 마자 이것을 sub의 입력으로 사용할 수 있습니다.

 

별도의 하드웨어를 추가하여 정상적으로 얻을 수 없는 값을 내부 자원으로부터 일찍 받아오는 것을 전방전달 또는 우회전달이라 합니다.

 

전방전달의 표현

그림을 보면 전방전달은 목적지 단계가 근원지 단계보다 시간적으로 늦을 경우에만 유효하단 것을 알 수 있습니다.

예를 들면 첫 번재 명령어의 메모리 접근 단계[MEM]의 출력으로부터 다음 명령어의 실행 단계[ID] 입력으로의 전방전달 통로는 유효한 통로가 될 수 없습니다.

 

전방전달은 잘 동작하지만, 이것만으로는 모든 파이프라인 지연을 막을 수 없습니다.

예를 들어 첫 번째 명령어가 add가 아닌 ld 명령어라고 가정하겠습니다.

 

이는 아래와 같은 상황이 발생합니다.

 

 

적재 명령어의 경우 4단계(MEM) 이후에만 사용할 수 있지만, 이는 sub 명령어의 입력으로는 너무 늦습니다.

따라서 위 그림처럼 전방전달을 사용하더라도 한 단계 지연되어야 하며, 이러한 특수한 해저드를 적재-사용 데이터 해저드(load-use data hazard)라 부릅니다.

 

위 그림은 파이프라인 지연(pipline stall)이라는 중요한 개념을 보여줍니다.

지연(stall)은 거품(bubble)이라고도 불립니다.

지연은 제어 해저드 부분에서 다시 살펴보도록 하겠습니다.

 

 

적재 사용 데이터 해저드의 경우 지연을 사용하거나 혹은 적재 사용 데이터를 피할 수 있게 명령어의 순서를 바꾸는 소프트웨어를 사용하는 방법이 있습니다. (명령어의 순서를 바꾸는 것만으로는 모든 데이터 해저드를 해결할 수 없습니다.)

 

 

 

 

 

 

 

 

 

 

 

 

 

🧐 제어 해저드

다른 명령어들이 실행 중에 하나의 명령어의 결과값에 기반을 둔 결정을 할 필요가 있을 때 발생합니다.

branch 인스트럭션이 사용되는 경우 제어 해저드가 발생합니다.

 

제어 해저드를 해결하기 위한 해결책으로는 지연과, 예측이 있습니다.

 

 

 

 

 

 

👉 지연 (Stall)

명령어의 결과를 판단할 때까지 파이프라인을 정지시키는 방법입니다.

 

현재 살펴본 데이터패스에 하드웨어를 좀 더 추가하고 위치를 옮기면 두 번째 단계(ID)에서 레지스터를 테스트하고 분기 주소를 계산한 후 PC값을 바꾸도록 할 수 있습니다.

 

그러나 이렇게 바꾸더라도, 조건부 분기를 실행하는 파이프라인은 아래 그림처럼 실행될 것입니다.

두 번째 단계에서 레지스터의 분석과 분기 주소의 계산, PC 값 변경이 일어나므로, 지연은 1클럭 사이클동안만 지속됩니다.

 

지연을 위해 거품처럼 동작하는, 즉 아무런 효과도 없는 명령어(nop)를 삽입하는 방법은 7개의 제어 신호(RegWrite, ALuSrc, ALUOp, MemToReg, MemRead, MemWrite, Branch)모두에 0을 할당하면 nop 명령어를 만들 수 있습니다.

 

 

 

 

 

 

 

 

👉 예측 (Prediction)

예측을 사용하는 경우 예측이 맞는다면 파이프라인의 성능을 떨어뜨리지 않지만, 예측이 틀렸다면 파이프라인이 지연됩니다.

 

반복문 등을 생각한다면 실제로 사용되는 분기의 경우 성공하는 케이스가 많겠지만,

구현이 복잡해지기에 RISC-V의 경우 실패한다고 예측합니다.

 

만일 분기가 일어난다면 인출되고 해독되었던 명령어들은 버리고 분기 목적지에서 실행을 계속합니다.

 

명령어를 버리기 위해서는 (적재-사용 데이터 해저드도 마찬가지로) 경우처럼 원래의 제어값을 0으로 만들면 됩니다.

적재-사용 데이터 해저드의 경우, ID 단계의 제어값을 0으로 바꾸는 일만 하고 그 후에는 자연스럽게 파이프라인을 통과하도록 합니다.

그러나 분기 명령어는 MEM 단계에 도착했을 때 ID, IF, EX 단계의 제어값을 0으로 바꾸는 일만 하고 그 후에는 자연스럽게 파이프라인을 통과하도록 합니다.

 

위의 `지연`에 대한 설명에서 살펴보았듯이, 분기 결정을 돔 더 앞당긴다면, 버리는 명령어의 수가 줄어듭니다.

(이는 지연의 감소와 동일합니다)

 

분기 결정을 좀 더 빨리 진행하기 위해서는 분기 목적지 주소의 계산과 분기 여부를 판단하는 일이 좀 더 일찍 발생해야 합니다.

 

이 중 쉬운 부분은 분기 주소 계산을 끌어올리는 것입니다.

 

IF/ID 파이프라인 레지스터에는 이미 PC값과 수치 필드가 들어있습니다.

따라서 분기 덧셈기를 EX 단계에서 ID 단계로 옮기기만 하면 됩니다.

 

좀 더 어려운 부분은 분기 여부를 판단하는 것입니다.

beq 명령어는 두 레지스터 값이 같은지 알아보기 위해 ID 단계에서 읽은 레지스터 값을 비교해야 합니다.

두 레지스터가 같은지를 알아보려면 비트별로 XOR을 하고, 그 결과를 OR하면 됩니다.

 

분기 테스트를 ID 단계로 옮기는 것은 추가적인 전방전달 유닛과 해저드 검출 하드웨어를 필요로 한다는 것을 의미합니다.

그러나 이러한 것을 추가하여 얻은 손해보다 조건부 분기 실행을 ID 단계로 옮김으로써 얻는 성능 향상이 훨씬 큽니다.

분기 테스트를 ID 단계로 옮기계 된다면 예측 실패 시 버려야 하는 명령어의 수가 1개로 줄어들기 때문입니다.