"Delayed" instructions on the MIPS/SPIM simulator -- summary post

[ A more appropriate title to my earlier post might have been: "Why is Joe
    so confused by these delay slots?" :-) ]


I thought I might summarize what I've learned. Yes, the MIPS has branch
and load delay slots, and Yes, the normal branch and load instructions
have such delay slots (there are no other, "special" instructions with
this feature). The question is whose responsibility it is to see that
these slots are filled correctly (either with nops or useful work).


By default, the MIPS "virtual" architecture (as presented by the
assembler) appears w/o delay slots, thus making it easier to write
assembly code. If you want to handle the delay slot filling yourself, you
have to override this default (e.g. you might use the .noreorder directive
in your asm code).


Now, here's the situation when using SPIM. By default, SPIM presents this
virtual architecture to the user; this means there are no delay slots
apparent to the user. My confusion started when I wrongly assumed that
SPIM would thus fill all the delay slots with NOPs. When I traced the
code in SPIM and didn't see any NOPs, I couldn't understand what was going
on --- "how could the code be working w/o NOPs in the delay slots?" (SPIM
does not reorder to fill delay slots). Turns out that SPIM takes an
easier approach: when run in default virtual mode, all instructions take
one cycle, period. Thus, there really truly are no delay slots!


When you run SPIM in "bare" mode however, the delay slots become visible
to the programmer. In this case, the same branch and load instructions
now have a single delay slot, and it becomes the programmer's
responsibility to fill them correctly. This of course is what I wanted,
and have since confirmed their existence via simple experimentation. (Now
why didn't I try those experiments first? :-)


Thanks for all the help,


    - joe
--
Joe Hummel
ICS Graduate Student, UC Irvine
Internet: jhummel@ics.uci.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.