Nintendo Ultra64, Programmer'S Manual

Page: 134 / 331

134
Advanced Information
Figure 6-1
Real-time Clock Watching on the RSP
Since IMEM is relatively small, critical sections of code can also be profiled
by inspection, examining the code and following the pipelining rules, “Mary
Jo’s Rules” on page 43
Dividing the number of instructions a section of code uses by the number of
clocks it takes to execute the section gives you a ratio that expresses
dual-execution efficiency and VU pipeline usage. A perfect ratio of 2.0
means you are executing two instructions per clock (one SU, one VU) with
no pipeline delays. A ratio less than 1.0 means you are experiencing
execution stalls due to data dependencies and/or not keeping both
execution units busy.
Inserting dummy display list instructions (temporarily customizing the
microcode) to mark coarse timing boundaries is another useful trick.
In the RSP microcode:
# Checkpoint the clock before the critical section:
mfc0 $1, $c12
sw $1, 0($0)
(Perform the critical section)
# Checkpoint the clock after the critical section:
mfc0 $1, $c12
lw $2, 0($0)
sub $1, $1, $2
sw $1, 0($0)
After the task has completed, this value can be retrieved by the application code on the CPU:
while (__osSpRawReadIo((u32) (SP_DMEM 0x0),
(u32 *) &(scratch_int)))
;
Depending on what you are timing, take care to consider that the RDP Counter is only 24 bits (be careful of wrap
conditions).
A more complex example might DMA data to DRAM for later analysis instead.