Frequently Asked Questions

Answers

MIPSim is an editor and simulator for writing, testing and debugging MIPS assembly language code for MIPS architecture.

I am still thinking of this and willing to do it. But I assure you that it won't happen before I properly edit and document the source code of MIPSim.

I am aware that MIPSim lacks many features at the moment but I believe that it is currently good enough for academic use. I may work on it in the future depending on how useful it is to you. I definitely won't invest more time in it if no one finds it useful.

MIPSim is a native Microsoft Windows application. So, no you will not be able to run MIPSim on Linux directly. However Wine, the Microsoft Windows Emulator for Linux, can successfully run (i.e. emulate) MIPSim on Linux. Although user interface appears to be a little buggy, core functions work perfectly fine.

When I started developing MIPSim simulation speed was not a concern in the first place, because MIPSim is an education-oriented simulator. Although it is still not the most important thing, I worked too much on the optimization of MIPSim in the later stages of development. I even re-designed and implemented the core of the simulator from scratch at some point and I believe that it is now one of the fastest MIPS simulators out there.
To achieve highest performance you have to disable real-time user interface updates from the options dialog (which I don't recommend unless simulation speed is really important to you) because updating user interface elements such as memory and register views are much more expensive in terms of time than simulating instructions.
After all MIPSim is a simulator and like all other simulators it is much more slower than a real MIPS processor due to the nature of simulators. This is because of the fact that simulators need to execute tens to hundreds of instructions on the computer in order to simulate a single instruction on the simulated machine. Moreover, since the simulator is one of many applications running on the computer it has to share CPU intensity with other applications and the operation system. Roughly I can say that MIPSim is 100 to 250 times slower than a real MIPS processor when real-time user interface updates are disabled, otherwise it is much more slower than that.

MIPSim simulates little endian byte order.

Because they are not implemented ;) It is actually one of the few things I will work on if I continue developing MIPSim. By the time you can and you should try and learn how to write MIPS assembly code without using any pseudo-instructions, it is good practice. It isn't like there are pseudo instructions that can save you hours anyway, it is usually two lines of code. Besides, it is always good to know what exactly is going on under the hood and pseudo instructions are not ideal for that - my two cents.

Normally instructions are stored in the data memory along with stack and heap, though they are logically seperate. MIPSim doesn't show encoded instructions in the memory view for the sake of simplicity. If you want to see how your program would look like in the memory, in hexadecimal or binary representation, you can use Encode Instructions tool.

MIPSim always starts debugging and execution from the label called "main". If there is no such label in the code, then the execution starts from the first instruction. If you want the execution to start from a specific instruction rather than the first instruction, you can insert a label called main to the place where you want the execution to start.

Just right click on the register or memory value you want to change and you will be able to change it.

A few things can cause infinite loops in MIPSim. One of them is erroneous assembly code of course, but I assume that your code is fine and there are no infinite loops in it. A second cause may be the value of the return address register ($ra) before the execution starts. Since there is no instruction in MIPS assembly language to terminate execution, MIPSim automatically terminates execution whenever the current PC register points to a memory word which does not contain an instruction. If you have stopped the previous execution in the middle of it the return address register may be pointing to a valid instruction. If you doubt that this causes the infinite loop try resetting the registers (under the Tools menu) before executing the code. This should fix it if that's the real cause.