Which of the following methods can be used to handle hazards in pipelining?

Improved explanation: common methods used to handle pipeline hazards and when each is appropriate.

• Hardware interlock: Hardware detects hazards at runtime and stalls the pipeline until the hazard is cleared. This handles data and structural hazards transparently but increases stalls and hardware complexity.

• Branch prediction (static and dynamic): Predicts the outcome of branches to avoid pipeline flushes. Static prediction uses fixed rules or compiler hints; dynamic prediction uses runtime branch history and adaptive tables for higher accuracy. Mispredictions cause rollback and penalty cycles.

• Delayed branch: A compiler-level technique that places independent instructions into branch delay slot(s) so useful work occurs while the branch outcome is resolved. Effective when suitable instructions are available; otherwise less useful.

• Operand forwarding (data forwarding/bypassing): Sends results directly from producing stages to consuming stages without writing and reading the register file first, reducing data-hazard stalls. Requires extra bypass paths; does not eliminate all hazards (e.g., some load-use cases may still need a stall).

Mapping methods to hazard types:

• Data hazards: operand forwarding is often the first choice; hardware interlocks provide a fallback by stalling when forwarding is insufficient.

• Control hazards: branch prediction and delayed branch techniques reduce stalls caused by branches.

• Structural hazards: resolved by resource duplication, smarter scheduling, or stalling via hardware interlocks.

Recommendation: Use a combination of techniques. Forwarding minimizes data stalls, branch prediction and delayed-branch scheduling reduce control stalls, and hardware interlocks handle cases that other techniques cannot resolve. Understanding trade-offs (hardware cost, compiler complexity, and misprediction penalties) helps choose the right mix.