Problem Set 5

		 Harvard Extension School CSCI E-93:
			Computer Architecture

			      Fall 2024

	 Due: November 10, 2024 at Midnight ET (Eastern Time)

Total of 150 Points

Please submit your solution to this problem set using "git" with named
branch problem-set-5.

For this assignment, based on your architecture design from Problem
Set 2 with appropriate modifications made by you based on comments and
design changes, implement the following program.

You will need the programs you created for Problem Set 4 as input to
this assignment.  If you have not completed Problem Set 4 yet, it must
be completed for you to test and complete this assignment.  Please
talk with the professor or with one of the teaching fellows if this is
a problem.


Write a software simulator (emulator) for your instruction set
architecture design.  The emulator should simulate the entire
instruction set including Input/Output to the serial (RS-232) ports.
For a description of the Input/Output system, refer to
https://cscie93.dce.harvard.edu/fall2024/io_interface.txt.

The emulator should contain an array which will contain the simulated
memory.  That array must be at least 64K bytes in size and at most 2M
bytes in size (all of the memory is byte-addressable by 21 bits).  If
your architecture requires only 16-bit or 32-bit word access to
memory, the memory may be organized as 16-bit or 32-bit words.  If
your architecture allows more than one of byte, 16-bit word, and
32-bit word accesses to memory, keep in mind that the memory system we
are providing is organized as little endian.

Initially, the emulator should either read the name of a file
containing an image of memory in the .mif format described in class
from the command line or should prompt for such a file name.  You do
*not* need to be able to parse the entire MIF specification; you only
need to be able to read any MIF file emitted by your assembler.  Next,
the emulator should initialize its simulated memory with the contents
of the input .mif file.  Remember that the memory system we are
providing allows only the low 64K bytes of memory to be initialized
for a DE2-115.  The emulator should initialize all registers to their
power-up state -- probably this is just that the PC (Program Counter)
is set to zero.

Next, the main loop should commence.  The emulator must simulate all
actions taken by your architecture and the state of all your
registers.  For example, the main loop might set the IR (Instruction
Register) to contain the contents of the simulated memory at the
location given by the PC.  Then, the PC would be incremented.  Next,
depending on the contents of the IR (i.e., depending on what is the
current instruction), various other operations would occur --
performing arithmetic or logical operations, altering other registers,
reading or writing the simulated memory, etc.

The emulator must also simulate the I/O (Input/Output) interface to
the serial (RS-232) ports.  The PS/2 and LCD ports and their
control/status bits need not be implemented.  It is acceptable to
assume that serial (RS-232) input and output are always ready.  If you
implement this approach, any attempt to read a character will stall
until a character is typed (if the input is buffered as a line, the
input operation will stall until a complete line is typed).  Extra
credit will be awarded for simulating the input ready bit.

Because I/O is memory-mapped (i.e., is accessed via memory locations),
it is probably advantageous to write accessor functions to allow
reading and writing of memory.  That way, any access to an I/O device
register location in memory can perform the correct I/O operation
rather than simply accessing the simulated memory location.

The default mode for your emulator should have no debugging output and
should run your machine code exactly as your hardware will.  In
addition, your emulator must have the option of tracing your program's
execution.  In the simplest approach, this would be displaying the PC
of each emulated instruction before executing it.  More elaborate
approaches might include displaying all registers before executing
each instruction, displaying only those registers that were modified
before executing each instruction, displaying all registers in a
separate continually-updated window, perhaps including the use of
color to indicate which registers were modified, etc.  These
approaches will be awarded extra credit.

Extra credit: Optionally, before execution of each instruction,
display the instruction about to be executed in the same format that
the assembly language defines.  This can be accomplished in two
different ways.  The first approach is to start with the numerical
representation of the instruction in memory and to create an assembly
language symbolic instruction that your assembler would accept -- this
is action is called "disassembling."  Note that the disassembly will
probably not have access to the symbol table from the assembler and
therefore will replace symbols with hexadecimal numbers/addresses.
The second approach is to display the actual source line that was
input to your assembler.  In this approach, the source line might be
emitted to the MIF file as a comment after the code on the same line
as the assembled hexadecimal representation of that instruction.

Extra credit: Provide a method to optionally allow a single
instruction to be executed and then return control to the emulator
rather than running the emulated program to completion.  This is
called single stepping.  When control is returned to the emulator
command prompt, the current PC should be displayed along with all
registers (or just registers modified since the previous instruction).

Extra credit: Allow breakpoints to be set and cleared at addresses of
instructions in memory.  This allows a program to run until it reaches
a breakpoint.  When control is returned to the emulator command
prompt, the current PC should be displayed along with all registers
(or just registers modified since the last command prompt from the
emulator).

Extra credit: Allow watchpoints to be set and cleared at addresses of
*data* in memory.  This allows a program to run until it would attempt
to read or write data at specified addresses.  Control should be
returned to the emulator command prompt *before* the instruction that
would access or modify the data in memory.  When control is returned
to the emulator command prompt, the current PC should be displayed
along with all registers (or just registers modified since the last
command prompt from the emulator).

You must verify that your emulator works correctly by running the
final program (problem 9) from Problem Set 4.  That is, write a
program in your assembly language to prompt for two signed decimal
integers (each of at least 2-bytes (16-bits) in size) and to multiply
one by the other and then to output the resulting integer product in
decimal as described in Problem Set 4.

Because this is the first time that you will be able to actually
execute a program written for your computer, we expect that producing
a correctly executing final program (problem 9) from Problem Set 4
will likely require a number of revisions to your Principles of
Operation document, to your final program, to your assembler, and to
your emulator.  Expect to make these revisions so that all of your
documentation and your code is correct and that they are mutually
consistent.

Please include with this assignment an up-to-date copy of your
processor's block diagram and an up-to-date copy of your Principles of
Operation manual.


			Last revised 30-Oct-24