pub const fn delay_cycles(funct: u8, fmt: u8) -> u32Expand description
Pipeline cycles for a COP1 arithmetic instruction — UM Table 7-14.
A direct transcription of the table, indexed by funct and the source
fmt. Written as data for the same reason the COP0 tables are: every entry
is a documented number with no generating rule, and a match over prose
becomes a place to forget one.
| Instruction | S | D | W | L |
|---|---|---|---|---|
ADD/SUB | 3 | 3 | ||
MUL | 5 | 8 | ||
DIV/SQRT | 29 | 58 | ||
ABS/MOV/NEG | 1 | 1 | ||
ROUND/TRUNC/CEIL/FLOOR (.W and .L) | 5 | 5 | ||
CVT.S | — | 2 | 5 | 5 |
CVT.D | 1 | — | 5 | 5 |
CVT.W/CVT.L | 5 | 5 | ||
C.cond | 1 | 1 |
§What a 1 means, and why it is not charged
One cycle is what an ordinary instruction already takes, so a rate of 1 is
no stall — ABS, MOV, NEG and C.cond cost nothing extra. Charging
them one cycle would make them uniquely slow among single-cycle
instructions.
§The +1 for a dependent consumer is not in this table
The manual’s note is that “if a floating-point result for these instructions is needed by the subsequent instruction, the latency is the execution rate plus one, due to the fact that an EX-to-RF bypass is not performed”. That extra cycle is not added here: the stall these numbers produce holds the whole pipeline, so the consumer spends its own cycle after the stall drains and arrives at rate + 1 on its own.
§Not modeled: the early exit
UM §7.5.6 and this table’s own note 2 say a multicycle operation whose result is obvious — a zero or infinity operand, a power-of-two multiplier — completes in two cycles instead. That is documented behavior we do not yet reproduce, so trivial operands are charged the full rate and the model runs slower than hardware there. Accuracy ledger C-29.