os161 mips

We are using mips r3000!

  • risc architecture (reduced isa)
  • some instruction shave imediate operands
    • values are constants within the instruction itself
    • addi r2, r1, 2048
    • instruction format: | ADD | IMM | R2 | R1 | 2048 |
  • registers!
    • 32 general purpose registers
    • r0 hardwired to 0
    • r31 is a jal (jump and link)
    • hi/lo are two 32 bits for multiply and divide
    • PC is the program counter

Branches and jmumping

  • branches and jumping have a branch delay slot
    • the instruction following a branch or jump is always executed prior to destination of jump
    • this means that the instruction after the jump or branch is executed ontop before the branch happens

why does this happen?

  • there are stages of executing an instruction!
    1. load instruction
    2. register file
    3. load into ALU
    4. D-cache
    5. register fileo
  • the instructions don't get loaded at the same time!

instruction 1: ------| IF | RD | ALU | MEM | WB |----------------------------

instruction 2: --------------| IF | RD | ALU | MEM | WB |--------------------

instruction 3: ----------------------| IF | RD | ALU | MEM | WB |------------

  • used to implement function calls
  • return register ra is used to return from function call

mips register conventions

  • (2-3) v0-v1: value returned by subroutine
  • (4-7) a0-a3: first four parameters for subroutine
  • (16-23) s0-s7: subroutine variables which must store and restore it
  • (28) gp: global pointer for some systems to maintained to the global point
  • (29) sp: stack pointer

jumping to subroutines

when we switch/jump to a subroutine, we push the values we want to save to the stack before we jump! doing this repeatedly we can create stack frames on stack frames so we preserve the state of the current subprocess even if we call other processes.

context switches

  • a context switch can refer to:
    • a switch between threads
      • saving, restoring state associated with a thread
    • a switch between processes

process abstrations!

os structure

from the hardware as the lowest level, you can haev layers of os functionality:

from top down:

monolithic kernel

  • processes | usermode
  • os services: Files, networking, etc ---- ABI
  • scheduler | kernel
  • dispatcher ---- ISA
  • hardware

and the kernel is the blanket term for the content between abi and ISA

but generally, you want to shrink the maount of code that is runnign in privileged mode. This means you can take out the os serves out of the kernel as a library

micro/exokernel

  • processes | usermode
  • os services |
  • scheduler ----
  • | priviliged mode (kernel)
  • dispatcher ----
  • hardware

library OS!

Since we could switch out the tailord OS services (system libraries), we can swap them out and run processes on TOP of different system libraries (bootstrap with different init systems)

using this, these libraries give different "flavours" of the operating system. However, the library os's (think libc) aren't really secure and have simplified resource maagements. This means that functionally, they are insecure!! As a result, you need a security monitor layer ontop of the dispatcher within priviliged mode.

The drawbridge system

Traditionally, library os's change the api. that means that applications written aren't exactly portable beyond one library os.

Drawbridge refactors the OS! You have a set of API compatible OS services within the library that makes use of host OS kernel services.

Picoprocesses

  • picoprocesses are an isolated process weith different syscall interface than normal processes. In this case, it could be a security monitor! (I dont fully understand picoprocesses, but to my understanding its just a process that only uses kernel syscalls)

back to virtual machines