Program 6, Part B

Purpose

This program is intended to provide understanding in the areas of interrupts and exception handling.

Program Statement

Reuse the letter counting program (from program 6A) together with an interrupt-driven kernel. Add to the letter counting program to time how long it takes (in seconds) for the user to type in the strings. Also add to the program to time how long it takes to print out the counts. At the end of the program, print out the two times as shown in the sample run below.

This program uses the user-level program saved from Program 6A together with an interrupt-driven kernel. The interrupt-driven kernel is provided for you in the file
~cs354-1/public/bin/interrupt.kernel
This interrupt-driven kernel already handles the I/O syscalls putc, getc, and puts. Copy the file (to your own directory), and modify your copy. Note that this kernel works as is, but it is missing the code to handle clock interrupts. You must write the code within the kernel to handle clock interrupts. The clock is treated as any other I/O device, and clock interrupts occur at the rate of one per second. The memory mapped I/O location ClockStatus works the same way as all the other device status words.

Since the user-level program needs access to timing information, utilize the generality of the syscall instruction to add a new function for syscall. This new type of syscall is to return the current time (in seconds) to the user-level program. Use the value 15 in register $2 ($v0) as a function number for this new syscall.

A sample execution of the program looks like
Letter counting program.
Enter a period as the first character on a line to end the program.
Count the letters in my strings.
There are two lines in my input.
.
Counts of the letters:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
1 0 1 0 7 0 1 2 5 0 0 2 2 6 2 1 0 4 4 8 2 0 1 0 2 0

Number of seconds to enter the strings: 18
Number of seconds to print counts: 2

Requirements

  1. Your kernel must not miss clock interrupts.
  2. Identify where you have added code to the kernel by placing the comment
    # NEW KERNEL CODE
    before the code you add, and the comment
    # END OF NEW KERNEL CODE
    after the code you add. This will make the job of grading easier. Adding a few blank lines before and after the new code will also help.
  3. Make your program work the same as the sample run.
  4. Use MAL/TAL instructions only.
  5. Your program must be well commented.

Recommended Approach

  1. Copy the interrupt-driven kernel to your own directory.
  2. Put the user-level program (saved from Program 5) together in the same file with the interrupt-driven kernel. The kernel goes first in the file. Double check that this code works using isim. It should work unmodified.
  3. Add code to the kernel to handle clock interrupts. Again, double check that this code works using isim. It should work exactly the same as the previous step. Clock interrupts should be occurring, and the kernel code will handle them, but this does not change the functionality of the user-level program.
  4. Add the new syscall (syscall 15) to the kernel that allows the kernel to supply the current clock time in seconds, when it is requested by a user program. A good idea at this point is to write a mini-test program (a user-level program) to test the new syscall. The mini-test program could time how long it takes a user to enter a single character.
  5. Add code to the user-level program to time how long it takes for the user to enter the strings and to print out the letter counts (as specified above). Test the code again with isim to make sure that the results look reasonable.

Hints

  1. Clock interrupts in the simulator occur at a rate of one per second. You can think of these as clock ticks.
  2. The amount of code that you write (from scratch) for this program is small. You make additions to the user-level program to do timing and print out timing results. You also make additions to the interrupt-driven kernel to handle clock interrupts and to implement the new syscall that returns the current value of time.
  3. The simulator works on top of a window manager, which works on top of an operating system, which is rather dependent on a file server. All these layers together tend to make I/O really slow as seen when running a program in the simulator. Don't be surprised if it takes a second (or so) to display each character while running a program.
  4. Single stepping in isim with interrupts enabled does not work for debugging. It cannot work, since the clock interrupts once per second.

Handing In the Program

You must "hand in" your program (the SAL source code) to the computer directly by

cp p6B.s ~cs354-1/handin/username/P6B/.

just once, where "p6B.s" is the name of the file containing your SAL source code and "username" is your CS login. No printouts will be turned in. I will run your program several times using different test data.