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

  1. 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

  1. 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

  1. 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 / Parity
Block 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 / Parity
Block 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