Branches: correctness before prediction

An RV32I conditional branch compares two registers and selects either a PC-relative target or the following instruction. BEQ compares equality; BLT uses signed ordering, while BLTU uses unsigned ordering. Signed and unsigned comparisons can disagree for the same bit patterns. For example, 0xFFFFFFFF is below one when treated as signed minus one but above one when treated as an unsigned 32-bit integer. Choose the branch that implements the intended data contract, not the one whose mnemonic looks familiar.

The branch target is calculated according to the instruction encoding and current instruction address. Do not confuse it with a source-language line number: optimization can combine conditions, eliminate paths, or use a conditional move instead. A correct low-level trace records the compared values, the comparison interpretation, and the chosen next address. It does not require knowing whether the processor guessed that path early. Predictor behavior affects performance and microarchitectural side effects, while required visible execution still follows the specified branch result.

A predictor uses implementation-specific information to guess direction and often target. Repeated loops and correlated decisions can be easier to predict than unstructured outcomes, but equal numbers of taken and not-taken branches do not imply randomness. A perfectly alternating sequence is balanced yet patterned. Conversely, a heavily biased condition can still generate costly surprises. Predictor structures, histories, aliasing, warmup, and code placement differ between processors, so no outcome percentage alone determines the miss rate on every machine.

When a guess is wrong, younger wrong-path instructions cannot be allowed to become the program’s committed result. Recovery redirects work and wastes some resources already spent. The number of lost cycles depends on when the branch resolves and on the pipeline state; memory effects and other bottlenecks can overlap. A simple average-cost model is useful only when you label its assumptions. Do not multiply a quoted universal penalty by the branch count and present the result as a measurement.

Replacing a branch with extra arithmetic or a conditional select can remove a control dependency while adding data dependencies and work. Computing both paths may also be unsafe if one path would access invalid memory. A faster isolated expression can lose in a larger loop with different register pressure or memory traffic. Compare representative input distributions, inspect generated code, and measure end-to-end impact. Keep correctness tests for both paths, including rare conditions that the benchmark might otherwise omit.

The probability lab supplies exact binomial counts for independent trials with fixed p. If you deliberately model each branch miss as an independent Bernoulli event with an assumed miss probability, predict the mean count np and its variance. This is a toy counting exercise, not a branch predictor: real misses can be correlated and their probability is not derived by this lab. Change p and n to separate uncertainty in a hypothetical count from evidence about hardware’s actual history-sensitive predictions.