1. The OS 215 Project

2. 2 OS 215 Project Outline Architecture of the Simulator Environment Z215 Hardware Organization and Architecture Generic Operating System Structure The Test Suite –Phase 0 Tests –Phase 1 Tests –Phase 2 Tests

3. 3 Simulator Environment Native Hardware Platform (IA-32, PA-RISC, Sun Workstation, etc.) Native Operating System (Windows NT, HP-UX, Solaris, etc.) Z215 Hardware Simulator (z215.c) OS 215 Operating System (base.c, scheduler_printer.c) OS 215 Test Suite (test.c) test0test1atest1btest1xtest2atest2b... All elements inside the heavy box are in a single process, running a single thread of execution. All I/O devices of the Z215 are simulated entities. This includes the timer device and the disk devices. Try to treat the Z215 Hardware Simulator as a “black box” and use the Z215 architecture specification instead. Look at the Addendum to get lots of other nice pictures of this layout.

4. 4 Z215 Architecture Dual-Mode architecture –User mode (see A.4) High level language, augmented with –Z215 General Purpose Registers –Macros for simplifying reentrant programs –Systems Calls, provided as macros (do not rewrite!) Z215 “Programs” are written as C functions taking a void parameter and having a void return. Example Program: void test0( void ) { SELECT_STEP { STEP( 0 ) printf(“This is test 0”); GET_TIME_OF_DAY( &Z215_REG_1 ); STEP( 1 ) printf(“Time of day is %d\n”, Z215_REG_1); TERMINATE_PROCESS( -1, &Z215_REG_9 ); STEP( 2 ) printf(“Error: Test should be terminated, but isn’t\n”); break; }

5. 5 Z215 Architecture (cont.) –User Mode (cont.) Address space for user programs is divided into –C code “program” memory for instructions and for local variables. This, for all intents and purposes, is not constrained in size. –User “data” memory, referenced through a virtual address space, and called MEMORY, and accessed from user space through the MEM_XXXX macros. No programs in phase 1 access this user memory. –Kernel Mode Instruction set includes C language instructions, plus –access to all the Z215 registers –access to Z215 physical memory (MEMORY) –access to the privileged instructions of the Z215 instruction set I/O primitives memory primitives context switching primitives –These are all available through provided macros

6. 6 Z215 Registers and Vectors

7. 7 Interruption Handling by the Z215 Interruption Sources –Interrupts TIMER_INTERRUPT from the delay timer DISK_INTERRUPT from disk 1, 2,... –Faults INVALID_MEMORY fault CPU_ERROR fault PRIVILEGED_INSTRUCTION fault –Traps SOFTWARE_TRAP for each system call –TO_VECTOR contains an address for each category of interruption source.

8. 8 Interruption Handling In os_init (the OS boot code), the OS sets values for each of the entries in TO_VECTOR. On the Z215, there is a total enumeration of all interruptions (exceptions) SOFTWARE_TRAP CPU_ERROR INVALID_MEMORY PRIVILEGED_INSTRUCTION TIMER_INTERRUPT DISK_INTERRUPT DISK_INTERRUPT + 1 … LARGEST_STAT_VECTOR_INDEX

9. 9 Z215 Hardware Actions on Interruption Let the interruption number (called exception in Appendix A) be x. User registers are saved in Z215 Hardware Context Hardware sets –STAT_VECTOR[SV_ACTIVE][x] = TRUE –STAT_VECTOR[SV_VALUE][x] = interruption specific info Execution mode is set to kernel Hardware begins execution at Interrupt, Fault, or Trap entry point as defined by TO_VECTOR Note that INTERRUPT_MASK is not set to TRUE. The operating system must do this if that is the desired mode of operation.

10. 10 OS Responsibilities on an Interruption On Entry –Mask interrupts (if desired) –Clear the Interruption Source set STAT_VECTOR[SV_ACTIVE][x] to FALSE –Determine the cause of the interruption and process accordingly On Exit –Unmask interrupts (if not already done). –For Interrupts, simply return –For traps and faults, ultimately exit the OS by performing a context switch (even if that switches back to the original process). This operation restores the user registers from the Z215 Hardware Context and sets the execution mode back to user.

11. 11 Interruption Causes Use STAT_VECTOR[SV_VALUE][x] to determine an interruption cause and influence processing: –For SOFTWARE_TRAP, value is the system call number. Use this to enter a switch statement to process system calls. –For CPU_ERROR, value is given by error codes (see table in Appendix A) –For INVALID_MEMORY, value is virtual memory page causing the fault –For PRIVILEGED_INSTRUCTION, value is 0 –For all interrupts (timer and disk), value is given by error codes (where one of the possibilities is ERR_SUCCESS)

12. 12 Z215 Hardware Context The context is the state of the executing CPU, essentially its registers. The Hardware context is essentially a register set, plus an entry address. The OS only deals with the handle to a context. Typically this is stored in the process control block. Z215 Operations for manipulating contexts –Z215_MAKE_CONTEXT(handle, start address, kernel flag) –Z215_DESTROY_CONTEXT(handle) –Z215_SWITCH_CONTEXT(save/destroy flag, handle)

13. 13 Operating System Structure Organize into functional areas –What are the functional areas of the Operating System? –What are the abstract data types required? –Class participation, putting together an OS structure… Next steps (Milestone 3) –Strawman functional spec for each module defined in the block diagram. –For each module set of interrelations with other OS modules portions of the Z215 interface being invoked by the module Set of system calls realized within the module –For system calls Categorization by module Attributes: blocking vs. non-blocking, save/destroy context

14. 14 Milestone: test0 Code given previously. Nearly the simplest user program possible. Requirements –Core OS os_init –TO_VECTOR trap_handler –System call switch –Process Management module os_create os_terminate –Timer module os_get_time

15. 15 The Test Suite: Phase 1 Test1a: Add SLEEP, requires timer multiplexing and interrupt handling, infrastructure for multiple processes. Test1b: Interface tests to CREATE_PROCESS Test1c: Multiple instances of test1a; demonstration of FCFS scheduling (by using same priorities) Test1d: Likewise for different priorities Test1e: Suspend/Resume interface test Test1f: Suspend/Resume on real scheduling Test1g: Change Priority interface test Test1h: Change Priority on real scheduling Test1k: Misc. error tests

16. 16 Components In The Starter Code Test.c z215.c O.S. Z215_ CLOCK Z215_ MAKE_ CONTEXT Z215_ DESTROY_ CONTEXT Z215_ SWITCH_ CONTEXT Z215_ DELAY_ TIMER Z215_ IDLE SVC fault_handler OS_ Switch_ Context_ Complete OS_ Init August, 2004 test0test1atest1btest2g o o o o o o o o o interrupt_handler main

17. 17 OS Components – What you need to Build Test.c z215.c O.S. Z215_ CLOCK Z215_ MAKE_ CONTEXT Z215_ DESTROY_ CONTEXT Z215_ SWITCH_ CONTEXT Z215_ DELAY_ TIMER Z215_ IDLE SVC Interrupt_Handler Device Queue Start_ Device Ready Queue Give_Up_CPU Dispatcher Make_Ready_ To_Run OS_ Switch_ Context_ Complete OS_ Init August, 2004

18. 18 The Execution of test0 test.c z215.c base.c Z215_ CLOCK switch_context SVC OS_ Switch_ Context_ Complete OS_ Init August, 2004 test0 main Z215_ HALT 4 10 9 7 8 6 5 3 2 1

19. 19 The Execution of test0 4 10 9 8 7 6 5 3 2 1 The program starts in main(). A temporary context is created and the simulation starts by requesting to run on that context. os_init is a routine in the operating system. For right now, all it does is create a context that will allow test0 to run. We come to os_switch_context_complete before we go out to the new code in test. Who knows what you might want to do with this! We go out to test0. It is time to run the user code. Test0 does a system call get_time_of_day. A system call produces a software interrupt that causes execution to go to svc, the software service routine. svc must get the time in order to service the system call. It calls the hardware to do that. It passes by reference a variable in which the time can be placed. Z215_CLOCK is a hardware routine that keeps track of the time. It passes back this time to svc. svc passes back the time to test0. test0 prints out that time as part of its code. test0 does a terminate_process system call – it’s all done with its job. It makes this call and again the execution ends up back in svc. Svc must handle this terminate_process request. Eventually this code will be more complicated, but for right now, since there’s nothing else for the OS to do, it simply ends the simulation by halting the processor.

20. 20 The Execution of test1 test.c z215.c base.c Z215_ CLOCK switch_context SVC OS_ Init August, 2004 test1a main 4 10 9 7 8 6 5 SLEEP 3 2 1 OS_ Create_Process Interrupt_Handler Timer Queue Start_ Timer Z215_ DELAY_TIMER Z215_ IDLE 11 12 13 14

21. 21 The Execution of test1a 4 10 9 8 7 6 5 3 2 1 The program starts in main(). A temporary context is created and the simulation starts by requesting to run on that context. os_init figures out what test you want to run. It passes the identifier for that test to os_create_process. We come to os_create_process, a routine YOU write. Here we create the context, create the PCB, and then call Z215_SWITCH_CONTEXT. Os_create_process calls Z215_Switch_Context which transfers control to test1a. Note: Test1a does various system calls, but we’re looking only at SLEEP in this picture. Test1a does a system call SLEEP transferring control to svc. svc hands control of the SLEEP request to start_timer, a routine YOU write. start_timer, enqueues the PCB of the running process onto the timer_queue. Start_timer calls the Z215_DELAY_TIMER to give the request for a future interrupt. The timer starts thinking about the time, but interrupts in the future!! Start_timer realizes there’s nothing else to do and so calls Z215_IDLE. This routine says to idle the processor until an interrupt occurs. Svc must handle this terminate_process request. Eventually this code will be more complicated, but for right now, since there’s nothing else for the OS to do, it simply ends the simulation by halting the processor.

22. 22 The Execution of test1a 10 When the delay timer expires, an interrupt is generated. This causes the processor to go to the interrupt handler. In the interrupt handler, take the PCB off the timer queue. This is the process that has been sleeping! When you return from the interrupt_handler, execution returns back to start_timer, to the line AFTER your call to Z215_IDLE. Start_timer returns to svc. svc returns to test1a. 11 12 13 14