MIPS architecture, OSs

• MIPS – 32-bit load/store RISC architecture – load delay slots

– hardware mul and div

– on-chip MMU instead of register file – MIPS registers

• Operating System Overview – brief history

– basic function: scheduling

– basic function: resource management – basic function: I/O

– auxiliary function: APIs

– auxiliary function: interfaces

MIPS architecture

• developed at same time as SPARC

• used in the DECstation processors (before Alpha chip)

• 32-bit

• RISC

• 32 32-bit registers

• load-store architecture (limited addressing modes)

• no register file, but on-chip MMU

MIPS load delay slots

• branch operation takes more than one CPU cycle

• delay slots let us use that cycle for other operations

• memory operation takes more than one CPU cycle

• example on SPARC:

        ld      [%o2 + 3], %o3
        add     %o3, %o3, %o4

the second operation is delayed by hardware until the value appears in %o3

• MIPS has no such hardware; instead, it has load delay slots, in which you cannot expect the new value to have been loaded

MIPS instructions

• mul and div instructions are treated like floating point instructions:

– special registers hi and lo

– execution takes multiple cycles

– execution of other operations can go on concurrently

– (div and mul added to later SPARC models)

• no condition codes:

– branches compare registers to zero

– comparison instructions store result into registers register

• different opcodes for register-plus-register add and for register-plus-immediate add

MMU vs register file

• MIPS has on-chip MMU (off-chip for original SPARC):

– faster memory accesses

– faster access to MMU registers

– tighter integration

• SPARC has register file:

– faster procedure call (often don’t have to save registers on stack)

– slower context switch

MIPS registers

• 32 32-bit registers

• %g0 always zero

• %at result of comparison instruction

• %o0, %o1 result of function calls

• %i0-%i3 first 4 arguments to function

• %t0-%t9 registers not preserved across subroutine calls

• %l0-%l8 registers preserved across subroutine calls by callee

• %g1 global pointer

• %sp stack pointer

• %i7 subroutine return address

MIPS calling convention

• no register file

• if callee uses any of %l0-%l8, must:

– push registers onto the stack before using them

– pop registers from the stack before

returning

• if callee is calling another function:

– must save %i7 (return address) before calling other function

– must restore %i7 before returning

Operating System Development I

• computers initially had no OS

• program to read and execute program on disk, drum, paper tape, or punched cards, was entered into memory using toggle switches

• over time, people developed libraries of common functions, e.g. for memory management

• to optimize performance, a supervisor program would read punched cards, execute the program, print the result, and go on to the next program

• the supervisor should be protected against accidental or malicious corruption by user programs

Operating System Development II

• multiprocessing computers gave the supervisor more functions:

– scheduling the user processes for execution – allocating resources (memory, disk space)

to users or user processes

– doing I/O, to enforce protection and allocation, user programs could no longer do I/O directly

• virtual memory gives the OS the power to protect users from each other

Operating System Highlights

• IBM OS 360: OS for a family of machines • IBM Virtual Machine: OS provides you with

a simulation of a smaller, slower machine • Multics: interactive multiprocessing on

special-purpose hardware (36-bit words!)

• CP/M, DOS: OSs for tiny machines

• Unix: subset of Multics on cheaper hardware • Xerox, MacOS, Windows: the user interface

is the OS

• micro-kernels: everything that can be is a user process, interaction between user processes mediated by micro-kernel

• real-time, embedded OSs: predictability, small footprint

Operating System Functions

• basic: – scheduling: who runs when

– resource allocation: who gets what

– protection: who can see or change what – I/O: talking with the rest of the world

• visible:

– APIs are what application programs use, what application programmers associate with an OS

– user interfaces (window systems, shells) are what users associate with an OS

Scheduling

• input is a set of processes (address spaces), each with one or more threads to run

• each thread has a state:

– running (at most one)

– ready

– blocked waiting for I/O

– sleeping until time T

• output is a decision of which thread to run next

• scheduler is invoked:

– on some system calls (e.g. exit)

– when threads block

– on interrupts (e.g. timer interrupts)

Resource Allocation

• input is a set of resources:

– distinguishable resources (e.g. network interfaces, specific disks, time in a real-time system)

– interchangeable resources (e.g. memory, disk space, time in a non-real-time system)

• input is a sequence of requests for resources

• output is a sequence of granting of or denial of resources

• resource management is state-dependent: what may not work today might work tomorrow

• scheduler can be thought of as a resource manager for CPU time

Protection

• input is a set permissions for system resources:

– file permissions

– memory permissions (e.g. read-only for process P)

– device permissions (e.g. supervisory processes may read raw network packets)

• input is a sequence of requests for resources (e.g. memory accesses)

• output is a sequence of granting of or denial of resources

• protection is state-dependent: what may not work today might work tomorrow

I/O

• generalization (e.g. in Unix “everything is a file”) is key to designing good APIs

• modularization: system has an API for modular device drivers, may even be able to load device drivers at run time

• system calls may result in calling the upper half (top half) of device drivers

• interrupts result in calling the lower half (bottom half) of device drivers