Documentacion Spim

SPIM S20: A MIPS R2000 Simulator
1 th 25

the performance at none of the cost"

James R. Larus larus@cs.wisc.edu Computer Sciences Department University of Wisconsin Madison 1210 West Dayton Street Madison, WI 53706, USA 608-262-9519

Copyright c 1990 1997 by James R. Larus This document may be copied without royalties, so long as this copyright notice remains on it.

1 SPIM
SPIM S20is a simulator that runs programs for the MIPS R2000 R3000 RISC computers.1 SPIM can read and immediately execute les containing assembly language. SPIM is a selfcontained system for running these programs and contains a debugger and interface to a few operating system services. The architecture of the MIPS computers is simple and regular, which makes it easy to learn and understand. Theprocessor contains 32 general-purpose 32-bit registers and a well-designed instruction set that make it a propitious target for generating code in a compiler. However, the obvious question is: why use a simulator when many people have workstations that contain a hardware, and hence signi cantly faster, implementation of this computer? One reason is that these workstations are not generally available.Another reason is that these machine will not persist for many years because of the rapid progress leading to new and faster computers. Unfortunately, the trend is to make computers faster by executing several instructions concurrently, which makes their architecture more di cult to understand and program. The MIPS architecture may be the epitome of a simple, clean RISC machine. In addition,simulators can provide a better environment for low-level programming than an actual machine because they can detect more errors and provide more features than an actual computer. For example, SPIM has a X-window interface that is better than most debuggers for the actual machines.
I grateful to the many students at UW who used SPIM in their courses and happily found bugs in a professor's code. Inparticular, the students in CS536, Spring 1990, painfully found the last few bugs in an already-debugged" simulator. I am grateful for their patience and persistence. Alan Yuen-wui Siow wrote the X-window interface. 1 For a description of the real machines, see Gerry Kane and Joe Heinrich, MIPS RISC Architecture, Prentice Hall, 1992.


1

Finally, simulators are an useful tool for studyingcomputers and the programs that run on them. Because they are implemented in software, not silicon, they can be easily modi ed to add new instructions, build new systems such as multiprocessors, or simply to collect data. The MIPS architecture, like that of most RISC computers, is di cult to program directly because of its delayed branches, delayed loads, and restricted address modes. This di culty istolerable since these computers were designed to be programmed in high-level languages and so present an interface designed for compilers, not programmers. A good part of the complexity results from delayed instructions. A delayed branch takes two cycles to execute. In the second cycle, the instruction immediately following the branch executes. This instruction can perform useful work that normallywould have been done before the branch or it can be a nop no operation. Similarly, delayed loads take two cycles so the instruction immediately following a load cannot use the value loaded from memory. MIPS wisely choose to hide this complexity by implementing a virtual machine with their assembler. This virtual computer appears to have non-delayed branches and loads and a richer instruction setthan the actual hardware. The assembler reorganizes rearranges instructions to ll the delay slots. It also simulates the additional, pseudoinstructions by generating short sequences of actual instructions. By default, SPIM simulates the richer, virtual machine. It can also simulate the actual hardware. We will describe the virtual machine and only mention in passing features that do not...