Computer Architecture CSC 364

Help Page and Information Page


Computer Simulator Project
Melody Donoso
Fall 2004

This page describes the interactive computer architecture simulator I created for CSC 364: Computer Architecture. It describes the functionality and operation of the simulator and its features.

Resource Links:
Trolltech - Creators of Qt
Check out more simulators
My CSC 364 Class
Smith College

Links to The Other Forms of the Simulator and the Opcode Set
Look at the Control Unit form
Look at the MUL and DIV forms
Memory Opcodes for SMIS Instruction Set

Introduction

The Simulator was made using Trolltech's Qt, a platform for C++ application development and GUI programming in particular. The purpose is to simulate how the hardware of a computer works and interacts at a fairly low level. The simulator has its own instruction set, SMIS (Sophisticated Move Instruction Set), which it can use to run different programs: the default program executes the first 3 levels of Pascal's triangle. Here is a screenshot of the main simulator window:

This form is made of several parts: the Processor, the Memory, the User Control Panel, and a debugging/message window at the bottom.

User Control Panel
The Control Panel lets the user interact with the simulator. The Load button loads a program that the simulator will execute into memory. The Execute button runs the program to completion. Step executes a single memory instruction at a time. Quit quits all forms of the simulator. Reset resets all values in the simulator (including those on any other forms opened from the main form) to their original state, with the exception of the cache, which retains its contents in the simulator until they are overridden. The Help button opens this help and information website. The Hex check button toggles the mode of the memory and cache between hexadecimal and decimal.

Debug/Messaging Window
This window gives the user feedback about what's happening in the program. It notifies the user when a MUL (multiply) or DIV (divide) instruction is encountered because these are special instructions in this simulator - their execution is illustrated in separate forms. This window gives other feedback or status messages to the user, such as notifying the user when all microcommands composing a particular microinstruction have been executed in case the user accidently tries to re-execute microcommands using the microcommand execution button on the control unit.

Memory
All instructions in memory are expressed as integer opcodes.
Look at the Memory Opcodes for the SMIS Instruction Set - the assembly language instructions the memory opcodes correspond to.
Memory is formatted as single-column table where every element in the table is 'stored' in memory at the address specified as the row number of the table. Whenever memory is accessed, the Memory Address Register (MAR) 'AddrReg' shows the address in memory accessed, and the Memory Data Register (MDR) 'DataReg' shows the data at that address in memory.

Within Memory is the cache. The cache is direct-mapped write-through cache, which means that whenever something is written to the cache it is also written to memory. Whenever the simulator needs to find something in memory it first checks the cache, and cache hits and cache misses are recorded immediately below the cache in the 'H' and 'M' text areas.

Processer
The Processor contains the Arithmetic and Logic Unit (ALU), the Control Unit, and a set of registers 'R0', 'R1', Stack Pointer (SP) and Program Counter (PC). It also has counters for the number of memory Instructions and micromemory instructions (Cycles) executed.

Registers
Registers R0 and R1 store 32-bit values used in the simulator's computation. The Stack Pointer holds the address where return or other values would be pushed on the execution stack. The Program Counter holds the address of the next Instruction (opcode) in memory that will be executed.

ALU
The Arithmetic and Logic Unit is the part of the processor which does computation at the binary level. The simulator does not go into further detail about how the ALU works in general, but gives a demonstration of how the ALU completes the binary MUL and DIV operations, which is the purpose of the 'Show MUL' and 'Show Div' buttons. These buttons open separate forms which are filled with the appropriate bits when a MUL or DIV instruction is encountered in memory.
Look at the MUL and DIV forms
The ALU receives data on the A and B busses labelled 'A -In' and 'B - In', and places its result on the the bus labelled 'C - Out'. The A and B busses can receive the contents of any of the registers, which can then go through the ALU, which will perform some arithmetic or logical operation on those inputs, and put the result on the C bus. From the C bus, data can be placed directly into any one of the registers. The C, S, and Z bits to the left of the ALU are flag bits used in the ALU's computation.

Control Unit
Each instruction is made of up some number of microinstructions, each of which is made of some number of microcommands. The microcommands comprising microinstructions consist of bus-level commands, such as 'A <- R0', which would mean 'A bus gets contents of R0'. The control unit performs the microinstructions that each instruction opcode requires, and is shown as a separate form containing the micromemory. Microinstructions break down memory instructions into actions which can be accomplished by transferring signals on the hardware, such as loading the contents of R0 onto the A bus, or letting the contents of the B bus through to the C bus. The control unit contains an additional register - the Instruction Register (IR), which holds the current memory opcode - the instruction in memory which is currently being executed. The 'Control Unit' button toggles the Control Unit form opened and closed.
Look at the Control Unit form


Functionality and Features
Or, 'how to use the simulator in order to understand it'. The simulator executes whatever program is loaded into memory, assuming that the program consists of valid SMIS instructions (see the instruction set link at the top of the page). The usefulness of the simulator is in allowing the user to follow what happens at a low level as the program is executed. Pressing 'Execute' will execute the program in full, and give the user no insight except for the number of cycles and instructions executed, and the number of cache hits and misses. Executing one instruction at a time using Step lets the user see the results of those instructions in the main simulator form, at least if the user refers to the instruction set (top of the page) in order to know what instructios the memory opcodes correspond to.

For example, the opcode 13 corresponds to the assembly instruction mov R0, immediate: when opcode 13 is executed in memory, the user can expect the next value in memory (always used as the immediate value) to be loaded into R0.

Opening the Control Unit form allows the user to execute the program at an even more detailed pace. Look at the Control Unit Form for details of it's functionality.