Cebollita MIPS Simulator

Introduction

The Cebollita toolkit provides a basic MIPS simulator. Two user interfaces are provided: graphical and text-oriented. Unlike SPIM, this simulator does not include an assembler -- it loads and runs executables produced by other Cebollita tools.

Starting the Simulator

The graphical simulator is started as follows:

java sim.UI [exefile]

[exefile] is the filename of an executable in the Cebollita EXE format. The simulator's loader will load the text and data segments, set up the stack and global pointers appropriately, and jump to the entry point of the program.

The Simulator Window

Once the simulator starts, the user should see a window like the following:

The window is split into four panes, which show, respectively:

Instruction memory (based on wherever the PC is)
Data memory (based on where $GP points)
Stack memory (based on where $SP points)
Machine registers

Right-clicking on an instruction will set/unset a breakpoint at that location.

Breakpoints

If the user hits the "Show Breakpoints" button, a window like the following will be produced (assuming they've set two breakpoints):

Each line shows the address and instruction at which a breakpoint was set. Clicking on a breakpoint will "seek" the instruction memory window to the address of the breakpoint.

Console Based Simulator

For the console-oriented folks, there's a simple console oriented simulator as well. Start it as follows:

java sim.Mips a.out

Typing "help" will give a list of commands. Here's an overview of what's currently implemented:

Command Meaning

help Dump a help message.

s Step one instruction

r Run the program

trace Toggle tracing (be verbose)

show Show the machine state

sb [addr] Set a break at the given address

db [addr] Delete a break at the given address

lb List all breakpoints

rm [addr] Read memory at [addr]

wm [addr] [value] Write the memory at [addr] with the given [value]

lm [addr] [words] List [words] of memory starting at [addr]

q quit

Command	Meaning
help	Dump a help message.
s	Step one instruction
r	Run the program
trace	Toggle tracing (be verbose)
show	Show the machine state
sb [addr]	Set a break at the given address
db [addr]	Delete a break at the given address
lb	List all breakpoints
rm [addr]	Read memory at [addr]
wm [addr] [value]	Write the memory at [addr] with the given [value]
lm [addr] [words]	List [words] of memory starting at [addr]
q	quit

Simulator Details

The simulator has two basic modes of execution.

System mode: In this mode, the simulator actually manages many of the system services, namely system calls. A set of system calls is provided to perform basic IO, which is all simply handled in software. These are defined below. Beginning users will probably spend most of their time running the simulator in this (default) mode. Most of the details below need not worry them in that case.

Bare mode: In this mode, the simulator is given a "disk image" rather than an executable as an argument. Upon startup, the simulator's "BIOS" loads the OS loader (bootloader) from the given disk image. The bootloader must be able to fit in a single 512 byte block and run in a location independent manner. Its job is to load the OS into low memory. The OS is standard-looking executable and the bootloader can just slam it into memory starting at location zero. (Detail: the OS is linked as if it starts at location 20, because the top 5 words are always the executable descriptor -- the OS can reuse this space later, if it wishes. The OS should have its exception handling routines (trap handler) as the first thing in its text segment. The machine will automatically jump to location 20 on exceptions...) Once the kernel is loaded, the bootloader should jump to its entry point (as specified by the executable) and it's off to the races. In this mode, memory mapped IO is used, and it's the kernel's responsibility to provide system calls to read/write from these addresses to perform IO. If the kernel wishes to load/run other processes, it must manage the base & length registers accordingly to perform address translation for that process.

Memory mapped IO: By default, the machine has a single CharacterDevice, a single BlockDevice, and a single RAM. The ram is 64KB in size, by default. The Character device is connected at address 0x40000000 and the BlockDevice is connected at address 0x40000010. Details of the operation of these devices can be found elsewhere (currently in the JavaDoc). In bare mode, the user has to write code that uses these devices to do IO. In system mode, these devices are typically unused, in favor of doing IO through the system calls. However, depending on the IO interfaces provided to the user, student's can happily write their own memory mapped IO routines for system mode. (Specific documentation

Differences: The MULT and DIV instructions currently do not simulate the HI/LO registers as on a MIPS machine. MULT and DIV are encoded as normal R-type instructions, where the destination register takes the product (or quotient). Users wishing to implement modulus must do simulate the process in software.

R2000 Coprocessor 0: Simulates the coprocessor to some extent, with some differences from a real MIPS machine (base and length registers), the other 4 are the same. Currently reg 12 isn't used...

0: base register (used for addr translation in user mode)
1: length register (used for addr translation in user mode)
8: Bad address value
12: interrupt mask & enable bits
13: Cause (exception type and pending interrupts)
14: EPC (exception PC)

MIPS Subset

The simulator only implements a subset of the MIPS ISA. In particular, only the following instructions are implemented:

Arithmetic: ADD, ADDI, SUB, MULT*, DIV*, SLT, SLTI
Logic: AND, ANDI, OR, ORI, XOR, XORI, SLL, SRL, SRA, SRLV, SRAV, SLLV
Control: JALR, JR, J, JAL, BEQ, BNE, BLEZ, BGTZ
Memory Access: LW, SW, LB, SB
Random: SYSCALL, BREAK, RFE, MTC0, MFC0

Notes:

MULT and DIV behave differently than on a real MIPS Machine. They look and act like regular R-type instructions. They do not make use of the HI and LO registers -- rather they simply place the 32 interesting bits of their result into the destination register.
No floating point instructions are implemented.
No pseudo-ops are implemented...

System Call Simulation

The following system calls are simulated:

Service	Number	Args	Result
print_int	1	$a0=integer
print_string	4	$a0=string
read_int	5		integer in $v0
read_string	8	$a0=buffer $a1=length
exit	10

By and large, these system calls behave like the ones described in Patterson & Hennesey A-49. Input and output occur via the console window from which the simulator was launched.

dugan@cs.washington.edu