The IJVM Simulator simulates the example computer in Structured Computer Organization, 4th ed; Andrew S. Tanenbaum; Prentice Hall; 1999. Since this computer runs a limited subset of integer Java Virtual Machine instructions, Tanenbaum named it the Integer Java Virtual Machine (IJVM).
Every level of the hardware is accessible to the user:
Main memory can be viewed as an array of bytes (the format of an IJVM machine language program) or as an array of 4-byte integers (the integer data format).
At its core, the simulator runs microprograms that are written by the user or loaded from a file. When you run the simulator, it automatically loads the IJVM interpreter. When running this microprogram, the simulator can run IVJM machine language programs. Programs can be executed in the following modes:
Even when a program is running with no interruptions, the user can break into the program to exam registers, the control store, and main memory. Execution can be resumed in any mode.
Single-stepping through a machine language program presents some difficulties. Typically, a microinstruction does more than one thing at a time. Consequently, there is no point in the machine language interpreter at which the execution of the previous machine language program has ended and the execution of the next one is about to begin. The instruction at address 0x002 in the control store comes closest:
0x002 PC=PC+1; fetch; goto (MBR OR 0x0)
At this point in the microprogram, the opcode for the next machine language instruction has already been fetched (as a part of the execution of the previous machine language instruction) and is available in the MBR. The unconditional branch goes to the microinstruction at the control store address specified by that opcode. However, even though this instruction (at 0x002) begins the interpretation of the next machine language instruction, the execution of the previous machine language instruction may not yet be complete. In particular, if the previous instruction initiated a memory access, that access will not be completed until after this microinstruction has been executed.
Here is the dilemma. If the simulator halts before executing the microinstruction at 0x002, the value in the PC register will correctly point to the address of the next machine language opcode but any memory accesses initiated by the previous instruction will not yet have been completed. On the other hand, if the simulator stops after executing the microinstruction at 0x002 then any memory accesses initiated by the previous machine language program have been completed but the value in the PC register will not point to the opcode of the next machine language instruction because it (the PC) has been incremented by this microinstruction (at 0x002).
When single-stepping through a machine language program, I thought it more important that memory accesses be completed. Consequently, when single-stepping through a machine language program, the simulator will always stop after executing the microinstruction at address 0x002. As a result, you will notice (if you look) that the value in the PC register is always one more than the address of the opcode for the next instruction.
This design decision had one other ramification. When the computer is reset, the PC register points to the last address in the address space of the computer. The machine language interpreter executes the instruction at 0x002 twice before it actually begins interpreting the machine language instructions. Consequently, you will have to click the IJVM Step button twice before you actually begin executing your machine language instructions. The first time, the MBR contains 0 (meaning a NOP is the next instruction to be executed) and the fetch of the first opcode of your program is initiated. The second time, the NOP instruction has just been executed and the MBR contains the first opcode of your program (which will be the next instruction to be executed).
A number of tools are provided to allow the user to interact with the simulated computer:
Tutorials in both microprogramming and assembly language programming are provided.
Assembly Language Tutorials
There is already a simulator (written by Ray Ontko and Dan Stone) available for the example microarchitecture presented in Tanenbaum's text. This simulator was written to remedy some of the shortcomings of that early effort. It corrects some implementation errors, provides much more access to the simulated hardware, and provides a much improved user interface.