SYSC 2001 Assignment 2 Test Harness

Disclaimer: I am in no way affiliated with the instructor or the TAs of this course. I am simply a student who wishes to offer friendly help to other students.

The second assignment of SYSC 2001 entails writing (in C++) an emulator for a fictitious processor architecture dubbed sIAS. While the only deliverable is processor.cpp, students are also expected to make significant changes to loader.cpp in order to verify their implementation of the processor operations (defined in the assignment outline).

This page offers example loader.cpp and Loader.h files that test your implementation of processor.cpp quite thoroughly.

As the instructor himself said, it is important to "get the details right" in this course. Inexperienced programmers may submit poorly implemented instruction sets simply because they are unable to test them properly. This page is here to mitigate that situation.

Instructions

1. First and foremost, make sure the assignment as it is given on the web site compiles and runs properly. This page isn't here to help with that part.
2. Make backup copies of your loader.cpp and Loader.h files. Download and replace them with the following:
   • loader.cpp
   • Loader.h
3. Edit your processor.cpp file:

   • Near the top, add another include file:

     #include "Loader.h"

   • At the end of your Pexecute function, add the following code:

     #ifdef VERIFICATIONS
     	Verifications::Check();
     #endif

     Make sure these lines of code are run after you've executed the instruction (e.g., loaded AC, etc.), every time, before returning from the function.

4. Compile and run. Any errors will be reported by a message such as the following:

   Verification failed: The register AC had an unexpected value at
     PC = 0x0100 (loader.cpp:48)     IR = 0x1000
     Expected: AC = 0xdead
     Actual:   AC = 0xeead

   You can use these errors as the driving force for writing the code for your Pexecute function (you write code for solving the latest error, until there are no more errors). In a way, this is test-driven development, a software engineering technique.

5. Important: A successful run is indicated by final register values of:

      AC = ffff  PC = 0000  IR = fffe MBR = fffe MAR = 0fff

   Any other final result means that there is an error somewhere (if there are no verification errors, perhaps your Pexecute is returning false when it shouldn't be).
6. Even more important: Don't forget to remove the 3 lines you added to processor.cpp in step 3 before you submit your assignment. Otherwise your assignment will not compile on the TA's computer and you will get 0.

Going Above and Beyond

Take a look at my Loader::Load function. It should be fairly straightforward to understand on the surface. Please add any new tests that you can think of that really stress the instruction set implementation. Please also send them to me over e-mail so that I can include them here (and test my own implementation!).

Internals

Essentially, the Loader::Load function plays two roles:

1. Filling up the memory (sIASmem) with useful data and code
2. Parallelly buildling a data structure of verifications (aka assertions, assumptions), about the state of the processor

A verification consists of:

• A pointer to the next verification (since verifications are part of a singly linked list)
• The source code line where the verification can be found, for the programmer's reference
• A mask of which bits are to be checked in the snapshot of register values
• A snapshot of expected register values

The verfications data structure is an architecture memory-sized array of pointers to singly linked lists of verifications. After every instruction execution, the PC of the just-executed instruction is looked up in this array. The resulting list of verifications is walked and the current values of the registers are compared to the expected values. Any discrepancies are reported and described and the process is aborted.

Author

The author of this page is Catalin Patulea. Feel free to e-mail me with questions and comments. If you would like to see some of the other things I've done, check out my web site.