Wednesday, April 22, 2015

Transcription

1 Wednesday, April 22, 2015 Topics for today Topics for Exam 3 Process management (Chapter 8) Loader Traps Interrupts, Time-sharing Storage management (Chapter 9) Main memory (1) Uniprogramming (2) Fixed-partition multiprogramming Review topics for Exam #3 1 Finite state machines, languages and grammars 2 Structures and arrays in Pep/8 3 Code generation and optimization 4 Loaders, traps, interrupts Process Management (Chapter 8) In Chapter 8 Warford looks at some of the aspects of the Pep/8 operating system (OS) Some aspects of OS operation continue in Chapter 9 We know that the Pep/8 OS handles - loading of user programs into memory - certain "trapped" instructions - those with opcodes (NOPn), (NOPaaa), (DECI), (DECO) and (STRO) A real operating system will also - handle "interrupts" from external devices such as printers and discs - possibly share resources between multiple concurrent users These resources would include CPU time, main memory and secondary memory Comp 162 Notes Page 1 of 10 April 22, 2015

2 Loader The Pep/8 loader reads a text file containing hexadecimal numbers terminated with "zz" and stores data in locations 0 onwards in main memory The code of the loader is short (See page 392) It looks like there is error checking done elsewhere and this code does not do any When run, the program will always start with the instruction at address 0 In contrast, a real loader reads a file that is likely to Be in some kind of binary format Have multiple sections with individual load-addresses Have an error-checking component Allow user/assembler to specify the program start address A load file format more general than the one Pep/8 uses might look like the following start address of program when executed number of blocks following (N) block1 - load-address block1 - byte-count block1 - data byte block1 - data byte blockn - load-address blockn - byte-count blockn - data byte blockn - data byte checksum The checksum could be very simple - for example a number so chosen that when all the bytes of the load file are added up (including the checksum) the result is zero In this way the loader can detect some instances of file corruption At the assembly language level, a typical way for the user to specify the start address of a program is to add a label after end as in the following Comp 162 Notes Page 2 of 10 April 22, 2015

3 a: word 2 b: word 99 sub: lda ret0 loop: lab: start: stop end start So now we don't need to begin a program with "br main" to skip over data regions Traps We know that five of the instructions at the assembly language level (NOPn, NOPaaa, DECI, DECO and STRO) have no machine language counterpart (compare Fig 52 with Fig 46) So what happens when program execution reaches an instruction with one of the five special opcodes (001001, 00101, 00110, 00111, 01000)? What happens is termed a "trap" (or synchronous interrupt) There are three steps 1 Information is saved on the system stack (distinct from the user stack see Figure 439) 2 Control is transferred to the operating system where appropriate action is taken 3 Control is then returned to the user program Step 1 What information is saved? In general, the data that must be saved is the "Process Control Block" and consists of contents of vital registers and variables In the case of Pep/8 we save 10 bytes worth of information - see end of page so that the operating system can freely modify registers and status bits without messing up the user program (but see below) For example, if we have lda 999,i deci M,d After deci executes we would expect that Register A still contains 999 Step 2 In the last word of the Pep/8 memory is a pointer to the "Trap Handler" (see Fig 439) The system follows this pointer and executes the code there The first thing the code does is to figure out which of the five special instructions was encountered (NOPn, NOPaaa, DECI, DECO or STRO) then call Comp 162 Notes Page 3 of 10 April 22, 2015

4 an appropriate subroutine using one of two jump tables and CALL with indexing (see code listing in Fig 86) Step 3 At the end of each of the subroutines that processes one of the special instructions, we return to the instruction following the CALL in the trap handler This instruction is a RETTR (RETurn from TRap) instruction which pops stored data from the system stack then returns control to the user program Note that one of the three instructions (DECI) may change some of the information saved by the user program (the status bits) For example, in the following we branch depending on the value of N not on the value of M lda M,d deci N,d brlt lab ; sets status bits depending on value of M ; sets status bits depending on value of N The trap instructions (NOPn and NOPaaa) don't do anything They can be replaced by user-defined instructions For example, if we wished to implement a multiply instruction we could use one of the two NOP opcodes and add code to the operating system to perform multiplication (Asynchronous) interrupts Traps are synchronous - you can look at a program and know exactly when they will occur Interrupts are asynchronous For example, the program could request a disc transfer then continue processing When the transfer is complete the disc sends an interrupt signal to the CPU The time required to complete a disc transfer is variable so we don't know exactly how many instructions will be executed before the interrupt happens In Pep/8 another difference between traps and interrupts is that traps are not nested While dealing with a trap, a second one cannot occur In a real system it is possible that while we are dealing with one interrupt (eg, from a disk) a second one might occur (eg, from a printer) We can take two possible approaches (a) (b) all interrupts are equally important When dealing with one we switch off interrupt detection until processing is finished some interrupts are more important than others When dealing with one interrupt we can be interrupted but only if the new one is more important The CPU uses a few bits in a status register to record its current priority level Model (b) is typical Different devices have different priorities (eg, a printer might have a low priority compared with a network communications card) The priority of the CPU itself is variable and thus the CPU would only be interruptible by some signal more important than the process it is currently running Comp 162 Notes Page 4 of 10 April 22, 2015

5 Imagine how a person performing a low-level task (doing homework?) handles interrupts of varying importance What importance rating would you assign to the following on a scale of 1 (low) to 10 (high)? Computer announces You ve got mail Phone rings (with voice mail) Text message arrives Doorbell rings Smoke detector goes off Fire alarm goes off in your building We can see the differences between (a) and (b) by considering the following system in which there are three sources of interrupts: Printer (P), Disc (D) and Communication Line (C) For simplicity, assume that each interrupt takes 15 CPU cycles to process We can determine the start and finish times for the interrupts for each strategy (a) Equal priorities Interrupt Time of Request Start Finish P D C P D (b) Priority(P) < Priority(D) < Priority(C) Interrupt Time of Request Start Finish P D C P D Comp 162 Notes Page 5 of 10 April 22, 2015

6 Time-sharing Given the comparatively long time it takes to service an I/O request, it is desirable to have many tasks for the CPU to work on so that when one is held up waiting for an I/O transfer, it can switch to another In addition, to avoid one program hogging all the CPU time, the OS could allocate CPU time in slices, eg 01 seconds Thus, we would need the system clock to be able to send interrupt signals too The following diagram represents states of a program: Start loaded Runnable selected Running normal/ abnormal end Finished I/O complete time-slice exhausted Waiting for I/O Issues I/O request In a time sharing system, a program is unlikely to run to completion in a single burst of CPU time Thus, the execution of two programs may be interleaved This could be a problem if they are both updating a common data item Consider programs A and B Time A: read (X) X = X - 1 write(x) B: read (X) X = X -1 write (X) One of the changes to X is lost We can define a "critical section" of a program as one which must not be interleaved with the critical section of any other program There are mechanisms beyond the scope of this course to force the serialization of critical sections Here is a simple one that assumes each program can access a global variable whose_turn which you can think of as analogous to a police officer directing traffic Program A: while (whose_turn!= A) {} // loop waiting <critical section> whose_turn = B Program B: while (whose_turn!= B) {} // loop waiting <critical section> whose_turn = A Comp 162 Notes Page 6 of 10 April 22, 2015

7 Warford looks at other solutions to the problem but they are beyond the scope of this course Storage management (Chapter 9) We have seen how an OS can share CPU time among processes Another resource it has to allocate is main memory which must be apportioned between itself and user programs The storage management mechanism has to ensure that user programs do not interfere with the OS or with each other In Section 91 Warford considers five increasingly sophisticated memory-sharing techniques: (1) Uniprogramming - like Pep/8 (2) Fixed partition multiprogramming (3) Variable partition multiprogramming (4) Paging (5) Virtual memory Two problems that must be solved by a memory management mechanism: (a) (b) how to stop a program interfering with other programs (including the OS) how to get a program to run correctly given that the assembler does not know where that program will be located in memory at run-time In addition, we want to make efficient use of memory and CPU time Here are the 5 techniques (1) Uniprogramming (2) Fixed-partition multiprogramming (3) Variable-partition multiprogramming (4) Paging (5) Virtual memory Each, apart from the first, attempts to solve a problem with the previous technique Comp 162 Notes Page 7 of 10 April 22, 2015

8 (1) Uniprogramming The memory is divided into User space and Operating System space User Program Space Operating System Only one user program can run at a time A fixed set of addresses is available for a user program The Assembler knows what addresses these are and generates absolute addresses, typically zero upwards How to protect the operating system? ( In Pep/7, user programs were able to overwrite the operating system In Pep/8 the operating system locations are write-protected) For speed, we could use a hardware memory protection scheme When the system is in user mode (running user program instructions), addresses coming out of the Memory Address Register are checked against the contents of a LIMIT register If they are greater than the value in the register, an "access violation" interrupt is generated In Pep/8 the value in the limit register would be FBCE 16 (see (Figure 437) LIMIT MAR compare Error (Access violation) In general, think of addresses coming out of the program as being intercepted by a Memory Management Unit The MMU may check and modify the addresses before thay are passed to the actual memory The Operating System is responsible for setting the value in the LIMIT register When the system is in operating system mode (handling a trap or interrupt for example), error checks are not Comp 162 Notes Page 8 of 10 April 22, 2015

9 performed thus the OS can read and write anywhere If we use SP instead of LIMIT we prevent users from executing code on the stack in a possible buffer-overflow exploit Disadvantage of Model 1 - there is nothing for the CPU to do when the user program is held up waiting for I/O (2) Fixed partition multiprogramming Imagine the user space part of the main memory divided into N partitions P 1, P 2, P N The partitions need not be the same size P 0 P 1 P 2 P 3 Operating System The operating system has a table showing where each partition begins and ends In the case of the example above, the table might be something like Partition Base Limit Each partition can hold one user program Now when one program is held up, eg waiting for I/O to complete, the OS may be able to switch to another one in memory that is runnable Comp 162 Notes Page 9 of 10 April 22, 2015

10 Clearly the assembler does not know which partition a program will be in when it is loaded so how does a program run correctly in any partition? The assembler assumes programs will start at zero thus the addresses in an object program are really relative to the beginning of its partition We extend the idea from Model 1 of addresses being intercepted by hardware and use a pair of registers: BASE and LIMIT These are loaded with the appropriate pair of values from the table So when the program in Partition 2 is running, BASE=30000 and LIMIT=41999 To the address coming out of the MAR (the logical address) we add the contents of the BASE register and check the result of the addition against the LIMIT register If the result of the addition is an address outside the partition we generate an error otherwise pass the modified address to the memory hardware BASE LIMIT MAR ADD compare Error (overflow) Error (Access violation) As the OS switches from one user program to another it loads the BASE and LIMIT registers with the appropriate values Disadvantage of memory model 2 - the partitions are set ahead of time The table shown above is fixed in size and the contents are also fixed What if we want to run a program that is bigger then the biggest partition? Reading In Chapter 8, you can skim the code of the trap handlers for DECI, DECO and STRO and skip the more advanced solutions to mutual exclusion described in p 428 to the end of the chapter Section 91 dealing with the memory models is quite good Comp 162 Notes Page 10 of 10 April 22, 2015