I've written quite a lot of assembly language code for a several chips, and of course lots of code in high-level languages. Before OSU8, I rarely used software simulators. My only experiences with software simulators were to try them out, usually to conclude they're more trouble than they're worth. Why bother fiddling with a cpu simulator when you could just run the code?

When you're designing a new CPU, you just can't run the code. Worse yet, how can you discover something is lacking in the instruction set until you write some code and try running it? Though these web pages are separate, as if each step was done before beginning the next, in reality writing the using this software simulator lead to revisions in the instruction set, causing assembler and simulator to change.

Later, the software simulator turned out to be absolutely necessary for evaluating the circuit simulations. Code could be run in the software simulator, and in the simulation of the actual hardware, and by comparing the results mistakes in the hardware could be identified.

Designing the Simulator

The simulator was started when the assembler was able to handle about half of the opcodes. My largest concern was how to verify that the simulator and assembler are producing correct results?

The best strategy I could devise was to make a self-contained disassebler, check it very carefully, and use it from both the assembler and simulator for display. If the assebler generates an incorrect opcode, the separate disassembler would be likely to display the mnemonic and operands of that incorrect opcode. Likewise, if the simulator does the incorrect action of an opcode, it would still be likely to display the correct text, making the bug as obvious as possible. This separate disassembler appears in the file osu8dasm.c.

The heart of the disassebler is a function called one_instruction(), which executes one instruction. The machine state is stored in global variables, including the program counter, so this function requires no input variables. The main() function runs in a loop, accepting interactive input from the user, and calling functions to implement the user interface.

Example Run

add text from an example run of the simulator, with some comments explaining key points.

OSU8: Simple 8-Bit Microprocessor Design; Paul Stoffregen
http://www.pjrc.com/tech/osu8/simulator.html
Last updated: February 24, 2005
Status: These pages are a work-in-progress
Comments, Suggestions: <paul@pjrc.com>