CS3220 Computer Architecture
Tutorial 6 2002
1. A computer terminal is two I/O devices packaged together: an input keyboard and an output
screen. They appear to be one device because anything you type in immediately appears on
the screen, but that is actually due to a piece of echo software in the I/O processor which
sends everything received from the in channel to the out channel. To enable each I/O
operation, the I/O processor sends a request signal to the device being activated.
a. Explain why the response from the screen to REQ is a boolean, while the response from
the keyboard is a byte;
-
Screen has to tell I/O processor whether it is ready to
receive output;
keyboard sends keystroke of the user after receiving REQ
b. Normally, the I/O processor sends an interrupt signal INT to the central processor when
the user presses the return key; explain why;
-
When Return is pressed, the user has typed in a complete
line for the program in control of the terminal to process;
the line might be data which the program is waiting for
or a processing command for the operating system including
request to run some other program;
it is also necessary for the CPU to receive input so that the
buffer can be cleared to receive the next line typed by the
user
c. When is it necessary for the I/O processor to interrupt the CPU on behalf of the screen?
When the screen has finished producing a line or a page
and is ready to receive a new line/page
d. Sketch a simple program on the I/O processor to control the terminal.
Assume that after each keyboard interrupt the CPU will receive the input in the buffer
returning a request in the same buffer asking I/O processor for additional input (no
output) or process output which CPU has put into buffer.
loop: buffer <- REQ(keyboard)
REQ(screen)
buffer -> screen
if end(buffer)==Return
then {buffer <- INT
loop2: if buffer==NIL
then goto loop
else {REQ(screen)
buffer -> screen
goto loop2}}
2. Sketch an disk controller program taking into consideration:
a. You first need to find out if the device is ready and whether a SEEK is necessary.
b. You are using a split cycle bus so that a SEEK/READ/WRITE request is followed by a
wait.
c. The controller interrupts the CPU after each operation to ask for more work to do.
loop:
receive (command, track, sector)
REQ (currenttrack)
wait
if track<>currenttrack
then { SEEK (track)
wait }
if command==Read
then buffer <- read (sector)
else write (sector, buffer)
wait
INT
goto loop
3. A RAID with both row parity and column parity checks can reconstruct data for multiple
failures on the same row or on the same column. What if there are three failures on a right
triangle so that there are two failures on the same row and two on the same column?
Disk1
Disk2
Block 0
Block 1
Block 2
Block 3
Block 4
Block 5
Disk3
Disk4
Parity
X
…
Block 798
Block 799
Block 800
Block 801
…
…
X
…
…
…
…
X
…
…
…
Block 999
Parity
X = faulty drives/blocks
Recover fault in Disk 4, Block 800 using column parity for disk 4
Recover fault in Disk 2, Block 1 using row parity for Block 1
Now only Block 800 of Disk 2 is faulty. Can recover using either row or column parity.
Also, how to avoid write concentration on the parity row/column?
Disk1
Block 0
Block 1
Block 2
Block 3
Block 4
Block 5
Disk2
Disk3
Disk4
Parity
W
W
W
3 writes
…
Block 798
Block 799
Block 800
Block 801
…
W
W
…
…
Block 999
Parity
…
…
…
1 write
…
…
…
3 writes
Redistribute writes so that we don’t concentrate on row or column:
Disk1
Disk2
Block 0
Block 1
Block 2
Block 3
Block 4
Block 5
Block 999
Parity
Disk4
Parity
W
1 write
1 write
1 write
W
W
…
Block 798
Block 799
Block 800
Block 801
Disk3
…
…
…
…
W
…
W
…
1 write
2 writes
…
…
…