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)

test0 test1a test1b test1x test2a test2b ...

All elements inside the heavy box are ina single process, running a single threadof execution.

All I/O devices of the Z215 are simulatedentities. This includes the timer deviceand the disk devices.

Try to treat the Z215 Hardware Simulatoras a “black box” and use the Z215 architecturespecification 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

Name Bits Usage

Z502_REG_ARG1 …Z502_REG_ARG6

32 For passing system call parameter values

Z502_REG_1 …Z502_REG_9

32 General purpose

Z502_REG_PROGRAM_COUNTER 32 Points to next location in user program

Z502_REG_PAGE_TABLE_ADDR 32 Points to page table

Z502_REG_PAGE_TABLE_LENGTH 32 Length of page table in 32 bit entries

Z502_REG_CURRENT_CONTEXT 32 Handle for current contextZ502_REG_INTERRUPT_MASK 32 Interrupt enable/disable

TO_VECTOR 3 x 32 Addresses of interruption handlers

STAT_VECTOR 2 x Nx 32

Exception statuses

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

test0 test1a test1b test2go 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_HandlerDeviceQueue

Start_Device

ReadyQueue

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

SVCOS_

Switch_Context_Complete

OS_Init

August, 2004

test0

mainZ215_HALT

4

10

9

7

8

6

5

3 2

1

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

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

5SLEEP

3

2

1

OS_Create_Process

Interrupt_Handler

TimerQueueStart_

Timer

Z215_DELAY_TIMER

Z215_IDLE

11

12

13

14

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

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