CSPIM is a MIPS I processor simulator. There are already a number of different MIPS simulators available on the internet, for example:
- Simulator in the Nachos educational OS.
- gxemul; his page has links to many other MIPS simulators/emulators.
- qemu dynamic translator.
but all are parts of larger projects (mostly whole-system emulation), and none of them is designed to meet the two basic requirements of mine (though Nachos seems to come close):
- Library interface, so that all aspects can be easily controlled from the host application.
- Ability to run in freestanding environment (i.e. an environment without the standard C library).
Given that MIPS I is an extremely simple architecture, it was easier to write a simulator with clean interface from scratch, rather than adapting an existing code (some of which I don't want to mess with because it's GPL'd). The name CSPIM is purposefully chosen to resemble SPIM, which is actually only an interpreter of MIPS assembly source code (i.e. it is not able to execute any kind of binaries).
Download the current release: cspim-1.0.tar.gz.
- Simulates the basic MIPS I instruction set in little-endian mode. This also means that the host application must be running on a little-endian CPU!
- Able to load and execute ELF binaries produced by mipsel-elf-gcc cross-compiler (see demo applications for correct compile/link flags).
- Clean library interface which makes it usable in a wide variety of applications.
- 64-bit clean code which has been tested with 32-bit gcc and both 32-bit and 64-bit SunCC.
- Safe code which does not let the simulated program "escape" the simulated CPU and mess up the host application.
- Delivered with a CPU "torture test" that tests every single instruction for correct execution.
- Implements most of SPIM system calls and is binary-compatible with SPIM's interface.
- It is able to interpret itself.
Floating-point arithmetic and big-endian mode
Both features may be implemented in the future. Neither is high priority.
Not planned at all
The following features/deviations from the real CPU's behavior are not planned to be implemented at all because they are not needed to correctly run executables generated by gcc.
- System control processor (paging, caching, exception status register).
- Accurate branch delay slot exceptions (the real CPU/OS resumes the branch instruction; CSPIM resumes the delay slot).
- If a branch instruction tries to transfer control to invalid memory area, the exception is reported immediately for the branch instruction itself, and not for the target PC.
- Delayed loads are not simulated; i.e. a load instruction behaves as if there were no delay. This is no problem, because it is assumed that gcc generates correct code. It is also in accordance with MIPS I spec which says that disobeying delayed load restriction has undefined behavior.