The OS 215 Project. 2 OS 215 Project Outline Architecture of the Simulator Environment Z215 Hardware Organization and Architecture Generic Operating System.

Slides:



Advertisements
Similar presentations
Processes and Threads Chapter 3 and 4 Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community College,
Advertisements

More on Processes Chapter 3. Process image _the physical representation of a process in the OS _an address space consisting of code, data and stack segments.
Chapter 3 Process Description and Control
Slide 3-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 3 3 Operating System Organization.
Architectural Support for OS March 29, 2000 Instructor: Gary Kimura Slides courtesy of Hank Levy.
Figure 2.8 Compiler phases Compiling. Figure 2.9 Object module Linking.
The Operating System Project Start Here Version 4.10: September 2014.
OS Fall ’ 02 Introduction Operating Systems Fall 2002.
Page 1 Processes and Threads Chapter Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.
Introduction to Operating Systems – Windows process and thread management In this lecture we will cover Threads and processes in Windows Thread priority.
Home: Phones OFF Please Unix Kernel Parminder Singh Kang Home:
OS Spring’03 Introduction Operating Systems Spring 2003.
Computer System Organization S H Srinivasan
The OS 502 Project. 2 OS 502 Project Outline Architecture of the Simulator Environment Z502 Hardware Organization and Architecture Generic Operating System.
1 Process Description and Control Chapter 3 = Why process? = What is a process? = How to represent processes? = How to control processes?
Operating Systems (CSCI2413) Lecture 3 Processes phones off (please)
Process Description and Control A process is sometimes called a task, it is a program in execution.
OS Spring’04 Introduction Operating Systems Spring 2004.
Process Description and Control Chapter 3. Major Requirements of an OS Interleave the execution of several processes to maximize processor utilization.
Protection and the Kernel: Mode, Space, and Context.
Chapter 3 Process Description and Control Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community College,
Chapter 3 Process Description and Control Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community College,
Chapter 3 Process Description and Control
Recall: Three I/O Methods Synchronous: Wait for I/O operation to complete. Asynchronous: Post I/O request and switch to other work. DMA (Direct Memory.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
CE Operating Systems Lecture 11 Windows – Object manager and process management.
Device Drivers CPU I/O Interface Device Driver DEVICECONTROL OPERATIONSDATA TRANSFER OPERATIONS Disk Seek to Sector, Track, Cyl. Seek Home Position.
Operating Systems Lecture November 2015© Copyright Virtual University of Pakistan 2 Agenda for Today Review of previous lecture Hardware (I/O, memory,
Processes and Process Control 1. Processes and Process Control 2. Definitions of a Process 3. Systems state vs. Process State 4. A 2 State Process Model.
Interrupt driven I/O. MIPS RISC Exception Mechanism The processor operates in The processor operates in user mode user mode kernel mode kernel mode Access.
Lecture Topics: 10/29 Architectural support for operating systems –timers –kernel mode –system calls –protected instructions.
We will focus on operating system concepts What does it do? How is it implemented? Apply to Windows, Linux, Unix, Solaris, Mac OS X. Will discuss differences.
Operating Systems 1 K. Salah Module 1.2: Fundamental Concepts Interrupts System Calls.
1 Computer Systems II Introduction to Processes. 2 First Two Major Computer System Evolution Steps Led to the idea of multiprogramming (multiple concurrent.
The Operating System Project Start Here Version 4.20: September 2015.
Process Description and Control Chapter 3. Source Modified slides from Missouri U. of Science and Tech.
Interrupt driven I/O Computer Organization and Assembly Language: Module 12.
Managing Processors Jeff Chase Duke University. The story so far: protected CPU mode user mode kernel mode kernel “top half” kernel “bottom half” (interrupt.
1 Process Description and Control Chapter 3. 2 Process A program in execution An instance of a program running on a computer The entity that can be assigned.
Interrupts and Exception Handling. Execution We are quite aware of the Fetch, Execute process of the control unit of the CPU –Fetch and instruction as.
Copyright © Curt Hill More on Operating Systems Continuation of Introduction.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Operating Systems Overview: Using Hardware.
CSCI/CMPE 4334 Operating Systems Review: Exam 1 1.
Processes and Threads Chapter 3 and 4 Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community College,
Multiprogramming. Readings r Chapter 2.1 of the textbook.
WORKING OF SCHEDULER IN OS
Process concept.
Process Management Process Concept Why only the global variables?
CS 6560: Operating Systems Design
A Step By Step Picture of How Processes Schedule (Using Test4 and TestX as examples) Version 4.40: September 2017.
Day 08 Processes.
Day 09 Processes.
CS 3305 System Calls Lecture 7.
Intro to Processes CSSE 332 Operating Systems
Structure of Processes
The Execution Of Sleep()
Process Description and Control
Lecture Topics: 11/1 General Operating System Concepts Processes
Process Description and Control
Architectural Support for OS
Process Description and Control
Process Control B.Ramamurthy 2/22/2019 B.Ramamurthy.
CSE 451: Operating Systems Autumn 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 596 Allen Center 1.
Process Description and Control
CSE 451: Operating Systems Autumn 2001 Lecture 2 Architectural Support for Operating Systems Brian Bershad 310 Sieg Hall 1.
Unix Process Control B.Ramamurthy 4/11/2019 B.Ramamurthy.
CSE 451: Operating Systems Winter 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 412 Sieg Hall 1.
Chapter 2 Processes and Threads 2.1 Processes 2.2 Threads
Architectural Support for OS
CS 502 Spring 99 WPI MetroWest/Southboro Campus
Presentation transcript:

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 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 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 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 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 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

19 The Execution of test 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 The Execution of test1 test.c z215.c base.c Z215_ CLOCK switch_context SVC OS_ Init August, 2004 test1a main SLEEP OS_ Create_Process Interrupt_Handler Timer Queue Start_ Timer Z215_ DELAY_TIMER Z215_ IDLE

21 The Execution of test1a 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 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