From f2b49d2e28230f775d2af06d8e48c83c76a3d8a4 Mon Sep 17 00:00:00 2001
From: Lam Gia Thuan <22922064+duckladydinh@users.noreply.github.com>
Date: Thu, 23 May 2024 00:13:37 +0200
Subject: [PATCH] Make definition of control hazard more correct.

In this case, it's not that the CPU doesn't know what to execute next, but it's more like the CPU already executed the wrong step. So I think this definition is more accurate and more relevant to branch-related statements later.
---
 content/english/hpc/pipelining/hazards.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/english/hpc/pipelining/hazards.md b/content/english/hpc/pipelining/hazards.md
index 872b59de..f49a505a 100644
--- a/content/english/hpc/pipelining/hazards.md
+++ b/content/english/hpc/pipelining/hazards.md
@@ -10,7 +10,7 @@ There are multiple ways this may happen:
 
 * A *structural hazard* happens when two or more instructions need the same part of CPU (e.g., an execution unit).
 * A *data hazard* happens when you have to wait for an operand to be computed from some previous step.
-* A *control hazard* happens when a CPU can't tell which instructions it needs to execute next.
+* A *control hazard* (or *branch hazard*) happens when a CPU mispredicts a branch and brings into the pipeline instructions that must be later discarded.
 
 The only way to resolve a hazard is to have a *pipeline stall*: stop the progress of all previous steps until the cause of congestion is gone. This creates *bubbles* in the pipeline — analogous with air bubbles in fluid pipes — a time-propagating condition when execution units are idling and no useful work is done.