4. The Processor (4.6. Data Hazard)

Data Hazard

 

Data Hazard는  이전 명령어의 실행 결과가 다음 명령어에서 필요한 경우 발생한다.

예를 들어, 덧셈 명령어의 결과를 뺄셈 명령어에서 사용하는 경우, 덧셈 명령어가 끝나지 않으면 뺄셈 명령어가 실행되지 못한다.

 

 

구조적 위험(Structural Hazard)

 

• 구조적 위험은 하드웨어 리소스가 부족할 때 발생한다.

예를 들어, 파이프라인에 메모리가 하나밖에 없을 때 두 명령어가 동시에 메모리를 참조하려고 하면 구조적 위험이 발생한다.

이 위험을 피하려면 메모리 리소스를 추가하거나, 각 명령어가 사용하는 리소스를 효율적으로 분배해야 한다.

• 예시: 세탁기와 건조기를 하나의 장비로 사용할 경우 세탁과 건조를 동시에 처리할 수 없게 되어 구조적 위험이 발생한다.

 

 

데이터 위험(Data Hazard)

 

• 데이터 위험은 이전 명령어의 결과가 다음 명령어에 필요할 때 발생한다.

예를 들어, 덧셈 연산을 먼저 수행하고, 그 결과를 뺄셈 연산에 사용해야 할 때 발생한다.

• 이때 전파(forwarding) 기술을 사용하면 이전 명령어의 결과를 즉시 다음 명령어에 전달할 수 있어 데이터 위험을 해결할 수 있다.

이 과정을 **바이패싱(bypassing)**이라고 하며, 이 방식으로 데이터를 전파하면 파이프라인의 속도를 높일 수 있다.

 

데이터 위험의 해결 방법: Forwarding

• 데이터를 **즉시 전달(forwarding)**하여 데이터 위험을 해결할 수 있다.

예를 들어, 덧셈 명령어(add x19, x0, x1)와 그 결과를 사용하는 뺄셈 명령어(sub x2, x19, x3)가 있을 때,

덧셈 명령어가 완료되기 전에 뺄셈 명령어가 실행되면 데이터가 부족하여 위험이 발생한다.

 

• 이때, forwarding을 사용하면 덧셈 명령어의 결과를 즉시 뺄셈 명령어에 전달할 수 있다.

이렇게 하면 파이프라인의 지연을 방지하고 데이터 위험을 해결할 수 있다.

 

• Figure 4.31에서는 forwarding이 어떻게 작동하는지 시각적으로 보여준다.

• 위의 그림에서는 add 명령어에서 생성된 결과를 바로 그 다음 명령어인 sub 명령어로 전달하는 방식이 설명된다.

이때, add 명령어의 실행 결과가 EX 단계에서 바로 sub 명령어의 EX 단계로 전달된다. 이 방식은 forwarding path라고 불리며, 파이프라인에서 데이터 위험을 해결하는 중요한 기술이다.

 

 

 

제어 위험 (Control Hazard)

 

제어 위험은 분기 명령어를 처리할 때 발생한다.

분기 명령어는 다음 명령어의 주소가 분기의 결과에 따라 달라지므로, 분기 명령어가 실행된 후에 어떤 명령어를 가져올지 결정해야 한다.

이때 파이프라인이 지연될 수 있다.

 

Figure 4.32: 제어 위험 해결 예시

 

• Figure 4.32는 파이프라인 지연을 시각적으로 보여준다. 예시에서 R-format 명령어가 로드 명령어 뒤에 실행될 때 발생하는 데이터 위험을 해결하기 위해 stall이 발생한다.

• stall은 파이프라인이 특정 명령어를 기다리면서 일시적으로 멈추는 상황을 의미한다.

이 경우, load-use hazard로 인해 파이프라인을 일시적으로 멈추게 만든다.

 add 명령어 뒤에 바로 sub 명령어가 실행되면, sub 명령어가 이전 add 명령어의 결과를 사용해야 하므로 리소스를 기다리게 되어 stall이 발생한다.

 

제어 위험 해결법: 분기 예측 (Branch Prediction)

 

• **분기 예측(branch prediction)**을 사용하여 제어 위험을 해결할 수 있다. 분기 예측은 분기 명령어가 어떤 경로로 실행될지 미리 예측하여 파이프라인의 지연을 줄이는 방법이다. 예측이 맞으면 파이프라인이 그대로 진행되고, 틀리면 파이프라인을 재설정하여 올바른 경로로 실행을 이어간다.

 

 

Figure 4.33: 분기 지연 - Stall on Branch

 

• Figure 4.33은 분기 명령어가 실행되는 동안 발생하는 파이프라인 지연을 보여준다.

• 예시에서는 add 명령어 뒤에 beq 명령어가 나온다.

이때, beq 명령어는 조건에 따라 분기를 수행하며, 분기 결과가 확정될 때까지 기다려야 하므로 한 사이클의 지연이 발생한다.

• stall은 분기 명령어가 실행되기 전에 한 사이클을 기다려야 한다는 점을 보여준다. 이로 인해 분기 명령어가 실행된 후, 다른 명령어는 하나 더 많은 클럭 사이클을 기다려야 한다.

 

 

Figure 4.34: 분기 예측의 작동 원리

 

• Figure 4.34는 분기 예측이 어떻게 파이프라인을 최적화하는지 보여준다.

• 이 그림에서는 분기 명령어가 실행될 때 예측된 경로가 맞으면 파이프라인이 정상적으로 진행되며, 분기 실패 시 stall이 발생하는 과정을 보여준다. 예측이 맞으면 파이프라인은 빠르게 진행되지만, 예측이 틀리면 추가적인 클럭 사이클을 소모해야 한다.

 

분기 예측의 효과

 

• 분기 예측이 효과적으로 작동하면 파이프라인은 더 빠르게 실행되며, 지연 시간이 최소화된다. 이 예시에서는 분기 명령어가 틀린 예측으로 재설정되지만, 정확한 예측이 가능하면 파이프라인 속도가 크게 향상된다.

 

 

동적 분기 예측 (Dynamic Branch Prediction)

 

• Dynamic branch prediction은 분기 명령어가 수행될 때 이전 분기의 결과를 바탕으로 미래 분기를 예측하는 방법이다.

이는 분기 예측 정확도를 높이는 방법으로, CPU가 과거 분기의 패턴을 추적하여 다음 분기를 예측한다.

 

데이터 위험, 제어 위험 등은 파이프라인에서 발생할 수 있는 주요 위험들이다. 각 위험은 forwarding, stall, 분기 예측 등을 통해 해결할 수 있다. 분기 예측을 통해 파이프라인의 효율성을 높이며, 동적 예측을 통해 예측의 정확도를 높일 수 있다. 파이프라인 설계는 이러한 위험들을 해결하며 성능을 최적화하는 중요한 과정이다.