First page Back Continue Last page Overview Graphics
Consider the following code fragment running on a processor using a 4 stage pipeline.
Set a breakpoint (*) at line 5
line 1 move #23, R1 fetch, decode, operate, store
- line 2 move #15, R2 fetch, decode, operate, store
- line 3 add R2, R1 fetch, decode, operate, store
- line 4 add R1, R4 fetch, decode, operate,...
- * line 5 move R1, R3 fetch, decode,...
What do we expect to find in R1? when the instruction in line 5 is fetched, the instruction in line 1 has been completely executed but the instruction in line 3 has only been decoded so the value in R1 is still 23.
We should be careful in debugging programs for pipelined processors. In the above example, the break point is set at line 5. Before executing line 5, one might check the value in R1 to make sure that it is correct. This is a common practice for debugging a program on a CISC-based processor. However, for RISC-based processors, this practice must be used with care since the value of R1 is still being calculated in the pipe and is not yet available.
Even though the debuggers for RISC processors usually provide methods for checking the intermediate results in each stage of the pipe, it may still not be as straight forward to find the needed information as with a CISC processor.