Successful rescheduling of instructions depends on enough instructions being independant of each other. When this is not the case, a partial ordering of instructions. The simplest example of a partial ordering of instructions would be two ALU instructions in a row, where one depends on the result of the other. For example:

ADD R1, R2, R3
ADD R4, R1, R5

The second instruction must stall at least until the first has finished the execution of the addition. If you have an instruction indepentent of both, you could possibly move it between the two. Loads and stores not referencing the same registers as ALU commands, and loop iteration variables can many times be used for this. Like so:

ADD R1, R2, R3
ADD R4, R1, R5
LW F2, 40(R6)

could be changed to

ADD R1, R2, R3
LW F2, 40(R6)
ADD R4, R1, R5

With no loss of correctness, at least one of the stalls caused by waiting for R1 to be written to (or have executed the add, and forward) is thus removed. The problem of doing this consistently and well is twofold: first, how can you determine which instructions are dependant on each other, and which are 'merely' dependant on registers (that is, you could rename the target register in an instruction with no loss of correctness). For now, the examples are simple enough that you can test it by hand. Second, are there enough independant instructions to eliminate all stalls? For small loops, this may not be the case and you will need to stall a bit unless you unroll.


Prev Next