[Computer Architecture] - processor (2)

📕single-cycle 이 요즘 사용되지 않는 이유

• 싱글 사이클 설계는 정확하게 작동하지만, 현대적인 설계에 사용되기에는 부적절하기 때문에 잘 사용되지 않는다.
• 프로세서에서 가장 긴 path가 clcok cycle을 결정한다.

• instruction 중에서도 load instruction은 5개의 unit을 사용한다. [instruction마다 사용하는 거쳐가는 unit이 다르다]
  
  1. instruction memory
  2. register file
  3. ALU
  4. data memory
  5. register file

📕Pipelineing

여러 개의 instruction을 실행단계에서 overlap 시켜서 동시에 실행하는 방법이다.

그림으로 이해하면 쉽다.

아래 그림은 Pipeline 기법을 사용하지 않는 세탁방법이다.

A 작업에서 세탁기의 사용이 끝났지만 A작업이 끝날 때까지 B작업은 세탁기를 사용하지 않는다.

Pipeline 방법을 사용하면 A,B,C,D작업을 완료하는데 훨씬 적은 시간이 걸린다(non pipeline).

즉 같은 시간내에서 처리량이 향상한다.

하지만 A, B, C, D작업을 완료하는데 걸리는 시간이 달라지지는 않는다. 

각 작업에 할당된 시간 자체는 줄어들지 않지만, 효율적으로 일을 분담해서 진행해서, A,B,C,D 전체를 완료하는 시간만 줄어든다.

📗non-pipeline

• A, B, C, D를 완료하는데 2Am까지 시간을 사용

📗pipeline

• 10pm이 안되기 전에 A, B, C, D 작업이 끝남.

📕RISC-V Pipeline

• RISC-V instructions은 5개의 단계로 분류된다.
  1. IF : 메모리로부터 instruction을 fetch 함.
  2. ID : register를 읽고, instruction을 decode 함.
  3. EX : operation을 실행하거나, address를 계산함.
  4. MEM : data memory안으로 접근함.
  5. WB : register에 결괏값을 입력함.

📕instruction마다 거쳐가는 stage

1. lw
   1. IF  -> ID -> EX -> MEM -> WB
2. sw
   1. IF->ID->EX->MEM
3. R-type
   1. IF->ID->EX->WB
4. beq
   1. IF->ID->EX

여기서 보면 알 수 있듯이 memory에 접근하는 것은 load와 sw 뿐이다.

📕Pipeline Hazards

• Hazards는 파이프라인에서 다음 사이클에서 다음 명령을 시작하는 것을 방해하는 상황입니다.
• 3가지 종류가 있다.
  1. structural hazard
  2. data hazard
  3. control hazard

 

📕Structural Hazard

• 구조적 위험은 하드웨어가 동일한 클럭 사이클에서 실행하려는 명령의 조합을 지원할 수 없다는 것이다.
• 즉 자원은 하나인데 여러 명령이 동시에 수행되려고 할 때 발생한다.
  • 간단하게 예시를 들어보자면 memory가 하나인데, 한 명령어는 IF, 다른 명령어는 MEM을 위해서 메모리에 접근할 때 발생한다.
• RISC - V는 pipeline의 structural hazard를 방지하기 위해서 설계되었다.

• 위 그림을 보면 같은 단계에서 memory에 접근하는 것을 알 수 있다. (MEM , IF)
• 이럴 때 structural hazard가 발생한다.
• 이를 방지하기 위해서 우리는 IF를 한 오른쪽으로 한 사이클 밀어준다. [Pipeline bubble]
• 이러한 구조적 위험을 방지하기 위해서 pipeline datapath는 instruction과 data memory를 분리시켰다.

 

 

📕Data Hazard

• 한 단계가 다른 단계가 완료될 때까지 기다려야 하기 때문에 파이프라인이 중단되어야 할 때 데이터 위험이 발생합니다.
  • 간단하게 말하면 내가 아직 작업이 완료되지 않은 레지스터를 병렬적으로 사용할 경우 충돌이 발생한다.

 

add와 sub를 자세히 보면 공통적으로 x19를 사용하는 것을 알 수 있다.

x19에 연산 결과를 입력하는 WB 단계 전에 sub에서 x19를 읽어 오는 것을 알 수 있다.

이렇게 읽어 오는 것은 부적절한 작업이기에 add 작업에서 WB한뒤에 x19를 읽어와야 하기에 

sub에 ID(x19를 read)하는 과정은 add에 WB보다 뒤에 있어야 한다.

 

📕Forwarding

• Data hazard를 해결하기 위한 방법.
• 데이터 위험을 해결하기 전에 명령이 완료될 때까지 기다릴 필요가 없다.
• 위 사진에서 x19에 대한 연산 결과는 EX 과정에서 끝내고 WB 시점에서 x19에 입력된다.
• 그러한 과정을(WB) 기다리지 말고 바로 EX 과정에서의 결과를 바로바로 필요한 시점에서 쏴주는 것이다.

• Forwarding path는 대상 단계(sub)가 원본 단계(add) 보다 늦은 경우에만 사용할 수 있습니다

📕Load - Use Data Hazard

• Forwarding은 매우 잘 작동하지만 불행히도 모든 파이프라인 stall를 방지할 수는 없습니다.
• 그 예가 load이다.

• x1은 MEM단계 이후로 결과가 정해지는데 sub에서 x1을 사용하려고 한다.
• 이러한 경우에는 stall 할 수밖에 없다.

 

 

📕Stall을 줄이는 방법

이렇게 순서를 바꾸기만 해도, 최대한 stall를 줄일 수 있다.

 

📕Control Hazard

• 제어 위험은 다른 명령이 실행되는 동안 한 명령의 결과에 기초하여 결정을 내릴 필요성에서 발생한다.
  • 다음 명령을 가져오는 것은 분기 결과에 따라 다릅니다.
  • 파이프라인이 항상 올바른 명령을 가져올 수는 없습니다. 여전히 분기의 "ID" 단계에서 작업 중입니다.
  • 분기 위험으로 알려져 있습니다.
• 즉 쉽게 설명하자면 다음 instruction의 실행이 branch 결과에 따라 점프를 할지 그대로 진행할지 결정하기 때문에 branch 결과가 결정될 때까지 무작정 기다려야 한다.
• 그렇기에 우리는 예측을 사용한다.

📕Branch Prediction

• 만약 파이프라인이 길다면 branch의 결과를 쉽게 결정할 수 없습니다.
  • 그렇다고 결과가 나올 때까지 무작정 stall 하기에는 비효율적입니다.
• 그래서 컴퓨터는 무작정 기다리기보다는 예측을 사용합니다.
  • 간단한 접근방법은 항상 branch가 untaken 된다고 가정하는 것입니다.
  • 만약 branch가 taken 된다면 예측은 틀린 것이고, pipeline을 stall 할 것입니다.

📕Static branch prediction

• is based on typical branch behavior
• for문이나 while문 같은 것.
• Predict backward branches taken
• Predict forward branches not taken

📕Dynamic branch prediction

• 각 조건부 분기의 동작에 따라 추측한다.