University of Wisconsin Computer Sciences Header Map (repeated with 
textual links if page includes departmental footer) Useful Resources Research at UW-Madison CS Dept UW-Madison CS Undergraduate Program UW-Madison CS Graduate Program UW-Madison CS People Useful Information Current Seminars in the CS Department Search Our Site UW-Madison CS Computer Systems Laboratory UW-Madison Computer Sciences Department Home Page UW-Madison Home Page

Program 5

CS/ECE 354, Fall 2003

Send e-mail questions to Eric Robinson erobinso@cs.wisc.edu
Due Wednesday, December 3, before 5pm


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

Program Statement

Reuse the user-level program from program 4 together with an interrupt-driven kernel. Add code to the user-level program that times and prints out the number of seconds it takes the user to type the alphabet each time. Also add code to identify in which run the user entered the input faster. As for Program 4, if the number of seconds is the same for both runs, the program states that test number 1 took less time.

The user input is shown in bold. All other display is generated by the program.

Sample program run 1


Typing test:  Type the string exactly as seen,
followed by the return key when finished.
abcdefghijklmnopqrstuvwxyz
aaadefghijklmnopqrstuvwxyz
 ^^
Number of errors: 2
Number of seconds to take the test: 9
Repeat the test:
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz

Number of errors: 0
Number of seconds to take the test: 12
The better score was on test number 2
Input was faster on test number 1

Sample program run 2


Typing test:  Type the string exactly as seen,
followed by the return key when finished.
abcdefghijklmnopqrstuvwxyz
aaaaa
 ^^^^^^^^^^^^^^^^^^^^^^^^^
Number of errors: 25
Number of seconds to take the test: 3
Repeat the test:
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyzZZZ

Number of errors: 3
Number of seconds to take the test: 21
The better score was on test number 2
Input was faster on test number 1

This program uses the user-level program saved from Program 4 together with an interrupt-driven kernel. The interrupt-driven kernel is provided for you in the file

/p/course/cs354-common/public/bin/interrupt.kernel

This interrupt-driven kernel already handles the I/O syscalls putc, getc, and puts, as well many interrupts. Copy the file (to your own directory), and modify your copy. The simulator includes one more I/O device that we call the clock. This device sends regular interrupts at the rate of one each second. The provided kernel works as is, but it is missing the code to handle interrupts from this clock. You must write the code within the kernel to handle clock interrupts. The clock is handled like any other I/O device. The memory mapped I/O location ClockStatus works the same way as all the other device status words. Your kernel implementation uses the clock interrupts to generate a representation for how much time has passed. This is a simplified version of system time.

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 elapsed time (in seconds) since the the program began running. Use the value 15 in register $2 ($v0) as a function number for this new syscall.

Requirements

  1. Follow the requirements from Program 4 that have to do with following conventions and the functionality of the user-level program.
  2. Your kernel must not miss clock interrupts.
  3. Identify where you have added code to the kernel by placing the comments
    #################################
    # ADDED KERNEL CODE

    before the code you add, and the comments
    # END OF ADDED KERNEL CODE
    #################################

    after the code you add. This will make the job of grading easier.
  4. Your program must follow the input/output format shown in the sample runs.
  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 the recommended approach in Program 4, step 3) together in the same file with the interrupt-driven kernel. The kernel goes first within the file. Double check that this code works using isim. It should work without modification.
  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 elapsed time in seconds, when it is requested by a user program.
  5. Add code to the user-level program to gather and then print the needed timing statistics. Note that this time should be rather close to what you observe by looking at a clock that has a second hand.

Hints

  1. Clock interrupts in the simulator occur at a rate of one per second.
  2. The amount of code that you write (from scratch) for this program is small. You make additions to the user-level program getting and printing timing information. You also make additions to the interrupt-driven kernel to handle clock interrupts and to implement the new syscall.
  3. Single stepping in isim with interrupts is difficult because the clock interrupt occurs every second. For debugging purposes, you can turn off all interrupts initially by executing as the first instruction after __start the following instruction:
    __start:  mtc0   $0, $12 # Initialization code to turn off all interrupts.
    
    While interrupts can later be enabled by a similar instruction, this should be thought of as a debugging tool, and should not appear in your final code. (This is a privileged instruction, and should not appear in user-level code. Also note that this instruction technically should not work in the simulator, since an attempt to execute a privileged instruction from within a user-level program should cause a trap.)
  4. If you do not have a working user-level program, you may use the program from the posted solution. Make sure that you cite the program author, if you use code that is not your own.

Handing In the Program

Turn in your combined kernel and user-level MAL program by running the script:

     handinP5 program5.s
where program5.s is an example name of the file containing the program. The handinP5 script submits your program for you. No printout will be turned in.