Stream Exercises

Home Class Info Links

Lectures Newsgroup Assignments

Below are exercises suitable for submission to the Code Critic after reading Chapters 1 through 16 of the textbook. Don't forget the rules of the queue.

The exercises are:

• Simpletron Simulator

Exercise: Simpletron

Especially Relevant Readings: Chapter 9, Chapter 10.6, Chapter 15, Section 16.1-16.4, Section 18.12, and the links given below.

Use TDD, pointers, dynamic memory allocation, string streams, and exceptions (WHEW!) to implement the Simpletron machine simulator (Exercises 8.18 and 8.19). That's a lot of concepts, but each one is valuable, fairly simple (at least as far used here), and makes the resulting solution much simpler.

Read Exercise 8.18 to see what SML looks like first.

• You won't need MULTIPLY or DIVIDE.
• You need to add CLEAR -- operation code 22 -- to set a specific location in memory to 0. For example, 2208 would clear memory location 8.
• For simplicity in coding and testing, each call to WRITE should print a space and then the data

Then read Exercise 8.19 to see how to implement the Simpletron Simulator. Specifically, you will use TDD to implement the class Simpletron with the following public API:

• Simpletron( istream &in, ostream &out ) creates an instance of the simulator that reads input when needed from in and writes output when needed to out.
• void Simpletron::load( int[] program ) loads an SML program passed as an array of integers into the simulator.
• int Simpletron::run( ) runs the SML program loaded, sets the appropriate error code, and returns the index (zero-based) of the last instruction executed.
• int Simpletron::getErrorCode( ) returns the error code.

Follow the description given in the book for implementing the simulator, except:

• Do not dump memory on HALT. Printing should only happen when a WRITE is executed.
• load() should dynamically allocate the memory for the program, rather than using a fixed array size. This is what real operating systems do.

After running a program, possible error codes are:

• 0, if the program stopped normally with HALT
• Simpletron::NO_PROGRAM_LOADED if no program has been loaded
• Simpletron::ILLEGAL_INSTRUCTION if the program stopped because an unknown operation code was seen
• Simpletron::ILLEGAL_ADDRESS if the program stopped because an illegal operand address was seen, i.e., an address larger than the program size.

Don't worry about any other kind of error, e.g., arithmetic overflow. Use class constants to define the non-zero error codes. When an error is detected, the simulator should stop immediately, set the appropriate error code, and return. Use exceptions to do this cleanly and simply without cluttering up the rest of the code.

For example, the code fragment below makes a Simpletron simulator, runs it on the SML program in Figure 8.40, then checks that it stopped on the instruction 4300, the output was the sum of 12 and -8, and there was no error code:

istringstream in( "12 -8" );
ostringstream out;
Simpletron sml( in, out );
int program[] = { 1007, 1008, 2007, 3008, 2109, 1109, 4300, 0, 0, 0, -99999 };
sml.load( program );
CPPUNIT_ASSERT_EQUAL( 6, sml.run( ) );
CPPUNIT_ASSERT_EQUAL( string(" 4"), out.str( ) );
CPPUNIT_ASSERT_EQUAL( 0, sml.getErrorCode( ) );

-99999 marks the end of program input. -99999 is not stored in memory as part of the program.

The 0's in the program reserve space for data. The call to load() above should allocate 10 words of memory, 7 for the instructions, and 3 for the data. This memory should be freed up if another program is loaded, orif the simulator's destructor is called. Be sure to use C++'s memory allocation functions, not C's.

Use stringstreams to enable automated testing of the simulator. Our example code above:

• Creates an istringstream with the input "12 -4"
• Create an empty ostringstream
• Constructs a simulator with those streams
• Runs an SML program.
• Gets the output written by the simulator with out.str()

Tasks

Use TDD to develop this simulator. Here are some test programs, and the results your simulator should. I strongly recommend you work on these test programs one at a time. Write the test code for the first one, get it to work, before moving onto the next one. Do not write any code to handle bad instructions or addresses until you get to tests that require that.

Now write some SML code of your own:

• Write the SML program to do Exercise 8.18 part (a). Then create a simulator instance with the input string "12 4 8 -1 3 -1 -1". Use this instance to run your SML program three times. The final output should be " 24 3 0" with a 0 error code.
• Write and test the SML program for Exercise 8.18 part (c). Use the input string "4 5 9 -2 3". The final output should be " 9" with a 0 error code.

Finally, test creating two simulator instances with the same input and output streams. Run one simulator on the "add two numbers" code and the other on code with an illegal instruction. Verify that both simulators exit on the correct instruction, that the correct total output was printed, and the both still have the correct error code for their particular program, after both programs have run.

Submit to Code Critic:

• Your test code, your header code and your implementation code

Clearly label each section of code.

Wrap Up

When the above has been approved via the Code Critic, run make handin.

Email the Zip archive produced by your Makefile with the Subject EECS 211: Simpletron.

Comments? Contact the Prof!