The OS 215 Project

1. The OS 215 Project

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. Simulator Environment 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. OS 215 Test Suite (test.c) test0 test1a test1b test1x test2a test2b ... OS 215 Operating System(base.c, scheduler_printer.c) Z215 Hardware Simulator (z215.c) Native Operating System (Windows NT, HP-UX, Solaris, etc.) Native Hardware Platform (IA-32, PA-RISC, Sun Workstation, etc.) Look at the Addendum to get lots of other nice pictures of this layout.

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. 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. Z215 Registers and Vectors

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. 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. 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. 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. 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. 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. 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. 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. 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. Components In The Starter Code o o o o o o o o o test0 test1a test1b test2g Test.c OS_ Switch_ Context_ Complete O.S. SVC interrupt_handler fault_handler OS_ Init z215.c Z215_ IDLE Z215_ DELAY_ TIMER Z215_ SWITCH_ CONTEXT Z215_ DESTROY_ CONTEXT Z215_ MAKE_ CONTEXT main Z215_ CLOCK August, 2006

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

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

19. The Execution of test0 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. 2 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! 3 4 We go out to test0. It is time to run the user code. 5 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. 6 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. 7 Z215_CLOCK is a hardware routine that keeps track of the time. It passes back this time to svc. 8 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. 9 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. 10

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

21. The Execution of test1a 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. 2 We come to os_create_process, a routine YOU write. Here we create the context, create the PCB, and then call Z215_SWITCH_CONTEXT. 3 4 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. 5 6 svc hands control of the SLEEP request to start_timer, a routine YOU write. 7 start_timer, enqueues the PCB of the running process onto the timer_queue. 8 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. 9 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. 10

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

23. The Execution of test2a and test2b test2a test.c 4 5 GET_PROCESS_ID OS_ Create_Process Process_Management SVC base.c 6 Dispatch OS_ Init 3 12 9 2 Interrupt_Handler Fault_Handler 11 8 z215.c Z215_MEM_READ Z215_MEM_WRITE switch_context main 1 10 7 August, 2006

24. The Execution of test2a and test2b 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. 2 We come to os_create_process, a routine YOU write. Here we create the context, create the PCB, and then call Z215_SWITCH_CONTEXT. 3 4 os_create_process calls Z215_Switch_Context which transfers control to test1a. The test may do system calls as we saw in test1*. The example we see here is GET_PROCESS_ID. 5 6 svc hands control of the system call to the appropriate handler. 7 The test does a Memory Request (either read or write). That request ends up in the hardware. If the hardware can handle it, you’re done. 8 If hardware can NOT handle the call, then a page fault is generated. You do the work in your fault handler to make the memory access successful. After completing the page_fault work, always call your dispatcher to schedule the same or a new process. NEVER return from the fault handler. 9 Reads and writes are handled the same way. 10