Introduction Continued

Friday, September 3

Instruction Fetch and Execute Cycle

The instruction fetch and execute cycle of the computer was discussed.

	Boot program in ROM
	Why instructions must be fetched from RAM
	Execution of instructions
	Checking for interrupts and how hardware handles interrupts
	Necessity for timer interrupt

Acknowledgement

In the following much of the information presented, including the figures, is from the book The Design of the UNIX Operating System by Maurice Bach.

Hardware Support Needed for Unix

In order to be able to port Unix to a new architecture, certain features must be present in the hardware of that architecture.

user/supervisor modes

user instructions that can be executed in user and supervisor modes as well as privileged instructions that can be executed only in supervisor mode (these instructions are the kind that set address registers, psw bits, and so forth that one would not want a user to be able to set in a multiuser operating system).

interrupts and exceptions, in which the hardware saves the current PC in a known location, sets the u/s bit to supervisor mode, and resets the PC with a predetermined address which the OS designer ensures is the location of the proper interrupt handler. Note: "interrupt" usually refers to an external interrupt from something like the clock or a disk drive, whereas an exception is an interrupt that occurs as the result of executing an instruction (e.g. a divide by zero exception).

processor execution levels, in which interrupts can be turned off at different levels, for example, in order from highest to lowest:

Machine errors

Clock

Disk

Network Devices

Terminals

Software Interrupts

A software interrupt acts the same as a hardware interrupt or exception. It occurs when special instructions, called trap, or supervisor call, instructions are executed. These instructions are provided so that user programs can call OS routines to perform hardware tasks that users (running in user mode) are not allowed to do (i.e., they are performed with privileged instructions).

Consider the following example:

A high level user program may include a line like

Read(A);

The compiler may translate this into something like

Syscall 3 -- perform a system call with parameter 3, 
          -- which means to read from the keyboard
Pop SP, A -- the Syscall 3 routine places the value read 
          -- from the keyboard onto the system stack, this
          -- value is popped into the location with
          -- symbolic address A

In actuality, this is a more complex operation, because reading from the keyboard means reading ascii characters that must be converted into a numeric value if A is, say, an integer variable. Still, the concept is that in order to perform the read, the user program must issue a system call, because the actual instructions to do the read are either privileged, or the address for accessing the keyboard is out of bounds to the user. All hardware tasks are thus performed by way of system calls to the operating system.

In this case, the execution by the processor of the Syscall instruction would do something like the following in one single machine instruction cycle:

	push the syscall parameter (3) onto the system stack so that the OS can determine which system call is being performed.
	set the u/s bit to supervisor mode
	push the current PC value (which points to the Pop instruction) so that the OS can return to that place after the syscall is finished.
	put a new value into the PC which is the address of the syscall routine in the OS.

Once this is done, the next instruction fetch retrieves the first instruction of the syscall routine in the OS and the syscall begins executing in supervisor mode.

Conceptual Design of Unix

The general philosophy that Unix follows in its design is a "concentric layered design." In this logical view of Unix, the Unix kernel (which is just another name for the operating system) "surrounds" the hardware. Users can only access the hardware (e.g., read from a disk) by calling kernel functions (by way of trap, or supervisor call, instructions) that perform the hardware access for the user. The layered approach just means that as other application programs are designed, they in turn may call user routines that have already been written to get the desired task done, and these routines my further call other routines or kernel routines. This layering can go on as far as desired.

Functional Design of Unix

Functionally, Unix looks more like the following. We just got started with this and will look at it some more.