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
- 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
- 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
- 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 / Disk3 / Disk4 / Parity
Block 0
Block 1 / X
Block 2
Block 3
Block 4
Block 5
… / … / … / … / …
Block 798
Block 799
Block 800 / X / X
Block 801
… / … / … / … / …
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 / Disk2 / Disk3 / Disk4 / ParityBlock 0
Block 1 / W / W / W / 3 writes
Block 2
Block 3
Block 4
Block 5
… / … / … / … / …
Block 798
Block 799
Block 800 / W / 1 write
Block 801 / W
… / … / … / … / …
Block 999
Parity / 3 writes
Redistribute writes so that we don’t concentrate on row or column:
Disk1 / Disk2 / Disk3 / Disk4 / ParityBlock 0
Block 1 / W / 1 write
Block 2 / W / 1 write
Block 3 / W / 1 write
Block 4
Block 5
… / … / … / … / …
Block 798
Block 799
Block 800 / W
Block 801 / W
… / … / … / … / …
Block 999
Parity / 1 write / 2 writes