Home

CS 450

1. can access them typedef struct params int op_code operation code IDLE EXIT READ WRITE etc int device_id TERMINAL COM_PORT byte buf_addr buffer address int count_addr size of the buffer params e op_code is the main concern of ours for now it will be either IDLE or EXIT as described before e Byte unsigned char e We will discuss later how to access these parameters R3 Variables Needed Example oS to save and manipulate the stack segment SS and stack pointer P e unsigned short ss_save e unsigned short sp_save e unsigned short new_ss e unsigned short new_sp e The process that is currently running will not be in any queue but we still need to keep track of it so we need a variable to hold a pointer to that process s PCB We designate this cop current operating process e PCB cop e Temporary system stack e char sys_stack SYS_STACK_ SIZE e Use a symbolic constant for the sys_stack_size make it at least 1024 Stack Manipulation using Dos h e Save stack pointers e sS_save _SS e Sp_save _SP e Restore stack pointers e _ SS ss_save e _SP sp_save e Switch to temporary stack using intermediate variables e new_ss FP_SEG amp sys_stack e new_sp FP_OFF amp sys_stack SYS_STACK_SIZE e SS new_Ss e _SP new_sp e Make a far pointer to stack top e stack_top MK_FP ss_save sp_save PO is executing and generates an interrupt by calling sys_req IDLE CPU refer
2. or hardware to indicate to the CPU that some event has occurred e When an interrupt is generated the CPU calls an interrupt handler to handle that specific interrupt e The address of all the interrupt handlers in a system are maintained in interrupt vectors The CPU can find the interrupt vector for a specific interrupt using the interrupt s ID e Interrupt handlers e Push context info onto a stack Turbo C automatically does this for you e Interrupts can occur at any time they are not predictable therefore the complete system state has to be preserved e Execute something l l l e Interrupt handlers should do only what is absolutely necessary and contain as little code as possible _ e Pop context information from the stack and restores it Turbo C automatically does this for you e Restoring the system state so whatever what running before the interrupt can continue Interrupt Keyword e Interrupt keyword Turbo C Only e Used to designate interrupt handlers automatically injects assembly code that saves CPU register values into the functions designated as interrupt handlers e Not part of the ANSI C Standard specific to Turbo C e Prototype for interrupt handler e void interrupt name e Note there cannot be parameters and there cannot be a return value e In Module R3 you will write an interrupt handler of your own You will then use a support software function to set the address in the interrupt vector of an unused dos int
3. CS 450 Module R3 Next Week e R2 is due next Friday e Make sure to correct all errors with R1 e Correct errors in the documentation as well it will be checked and graded again e Make sure in your sys_init call you change the parameter to MODULE_R2 Ifyou have completed any extra credit make sure you tell me when I am testing your system so I can test it e Late demonstrations will not be accepted e Ifa residual problem from R1 prevents the testing of an R2 command you will lose points Documentation Due with R2 e Manuals e Programmer s Manual add on to what you did for R1 User s Manual add on to what you did for R1 do not include temporary command e Temporary Commands Manual same as user s manual but with only temporary commands e Code Turn in a complete copy of your source code all C and H files except MPX_SUPT with your documentation R3 Introduction R3 is due along with R4 on Friday Oct 25th e We are now ready to implement the functions that are needed to allow the MPX system to execute processes and switch between them e You will be writing two interrupt handlers e The dispatcher will give the first process on the ready queue control of the CPU thus allowing it to execute e The sys_call handler will handle interrupts generated by MPX programs and call the dispatcher to run the next ready process Review Interrupts amp Handlers e An interrupt is a way for software
4. d dispatch these processes infinitely many times If your system crashes after doing this a couple of times you more than likely have a memory leak ee Tips and Hints e Change your sys_ init call to have the parameter MODULE_R3 e Sys call and dispatcher should be short functions Neither should require more than 30 40 lines of code Do not use printf statements inside your dispatcher and sys_call functions They will cause problems ad make your code harder to debug e Remember to always manipulate _SS and _SP in consecutive simple statements e Suspended processes and blocked processes should never be run To test your program try loading the processes and then blocking suspending a few before calling dis atch Only those in the ready not suspended state should run and all others EE remain in their appropriate queues until they have been run e Do not declare variables inside of interrupt handlers make any variables you need to use in an interrupt handler global Most R3 errors can be traced back to R2 functions e Read T project manual for R3 there is more pseudocode available in the manual
5. ences interrupt vector for interrupt 60h and calls your sys_call interrupt handler Sys_call looks at the parameters and sees that PO wants to continue to execute so it places PO back on the queue Sys_call calls dispatcher Dispatcher checks the ready queue sees that P1 is ready to run Dispatcher performs a context switch which allows P1 to execute P1 has been executing and generates an interrupt by calling sys_req EXIT CPU references interrupt vector for interrupt 60h and calls your sys_call interrupt handler Sys_call looks at the parameters and sees that P1 wants to terminate Sys_call frees all memory allocated to P1 10 Sys_call calls dispatcher 11 Dispatcher checks the ready queue sees that P2 is ready to run 12 Dispatcher performs context switch allowing P2 to execute 1 2 3 4 5 6 T 8 9 Ready Queue 80 F PO OO a a Interrupt Vector Table Procedure sys_ call Parameters none Returns null e Sample Prototype e void interrupt sys_callQ Sys_call is not directly called It is invoked indirectly by MPX processes requesting to go IDLE or EXIT Sys_call interprets system call parameters puts the currently running process back in a queue or deletes it depending on the nature of the interrupt Then calls the dispatcher to allow the next process on the ready queue to run Sys_call outline e When an MPX process generates an interrupt the sys_req function places t
6. errupt 60h to point to your handler Therefore whenever an MPX process generates interrupt 60h the CPU will call your interrupt handler Generating Interrupts in MPX e MPX processes will use the sys_req function to generate an interrupt When a process generates an interrupt it will have a status associated with it R3 R4 the statuses are IDLE means the program is not done terminating so put it back in the ready not suspended state and reinsert it into the ready queue e EXIT program wants to terminate so delete its PCB from memory e Other statuses such as READ and WRITE will need to be handled in Module R6 Dos h functions e You will need to include dos h e include lt dos h gt e Construct a far pointer e unsinged char MK_FP unsigned int SEGMENT unsigned int OFFSET o Get the segment of a far pointer e unsigned char FP_SEG void e Get the offset of a far pointer e unsigned char FP_OFF void R3 Overview e Two interrupt handlers e Dispatcher e will be called by the MPX OS e Sys_call e will be triggered by an interrupt e Temporary Function e Load Processes e Temporary Commands e To call dispatcher e To load test processes Context When a process is interrupted the values in all of the CPU registers must be saved This information will be placed on the stack by Turbo C but to access it you will need to define a C structure the PCB s context e Sample is below note that you can call t
7. he parameters on the stack In sys_call you need to access those parameters to uncover the reason the interrupt was generated e Access the stack and get the parameters e params param_ptr params MK_FP _SS _ SP sizeof context e Switch to temporary stack e Check the parameters might be useful to do in a SWITCH statement as we will be adding to this later e Ifparam_ptr gt op_code IDLE e Process wants to continue executing e Set cop state to ready e Insert cop into the ready queue in priority order e Ifparam_ptr gt op_code EXIT e Process wants to terminate e Delete cop free its memory e Set cop null e Call the dispatcher Procedure Dispatcher Parameters none Returns void Sample prototype e void interrupt dispatch The dispatcher will be responsible for running processes from the ready queue e When the dispatcher is called this means that the process that is currently running doesn t need to run anymore and another process should be given control of the CPU e The dispatcher is called directly from the sys_call handler SPRES The first time the dispatcher is run it needs to see if the stack pointers SS and SP have been saved yet if not you must save them so dispatcher has a way of returning to the function which originally called it e Check to see if ss_save is NULL e If yes save the stack pointers _SS _SP to the save variables e Now we need to find the next process that wil
8. he structure whatever you want but you MUST use the same datatypes and have the registers in the same order typedef struct context unsigned int BP DI SI DS ES unsigned int DX CX BX AX unsigned int IP CS FLAGS context Context Switching e An important part of this Module is context switching Context switching allows the system to replace a process that is currently running with a different process Ina context switch you must e Save the context of the running process e Replace it with the context of the process you want to run e Turbo C automatically saves 12 registers for you when you use the interrupt keyword However the SS and the SP must also be saved and Turbo C does not do this automatically e In Turbo C you can directly access the SS and SP using _SS and _SP You should save them into variables of type unsigned short o ou assign new values to the SS and SP using the dos functions mentioned earlier e _SS FP_SEG sys_stack e _SP FP_OFF sys_stack SYS_STACK_SIZE e When assigning new values to _SS and _ SP you should use intermediate variables e When accessing saving or changing the SS and SP you must do so in consecutive uninterrupted steps Parameters e Parameters cannot be passed to an interrupt handler in the normal way e When an MPX process generates an interrupt sys_req will place certain parameters on the process s stack e We need a structure to represent the parameters so that we
9. l run e Find the first process in the ready queue that is not suspended e Ifno PCB is ready we need to restore the MPX state e Set the cop variable to NULL e Restore the stack pointers SS SP using the save variables e Return e Ifa PCB is found that is ready we need to perform a context switch to allow that process to run e Set the cop variable equal to the process that is next in line to run e Remove the process from the ready queue and set its state to RUNNING e Context switch e Set _SS and _SP equal to the PCB s stack pointer using dos h functions e Return R3 Initialization We need to set the interrupt vector to point to your system call handler sys_call This is so the interrupt instruction generated by MPX processes causes sys_ call to be called If you call your system handler sys_call you would need to use the command sys_set_vec sys_call e Returns o if no problem e Returns ERR SUP_INVHAN if invalid handler name e You should also set all of your stack save variables to null in the initialization e You also need to modify your allocate_pcb function R2 specifically when you set the stack_top pointer you should set it to e Stack_top Stack_base Stack_size sizeof context Test Processes e On Dr Mooney s website is a file named procs r3 c This contains 5 test processes we will use to test R3 In order to use these however you will need to create a procedure load_procs to load these p
10. rocesses into your MPX system Load Processes outline e Need to do the following sequence 5 times once for each process Assumed that you have created a PCB np and a context npc np Call your setuppcb function give PCB name ex testproc1 or test1 Pa 0 class APPLICATION npc context np gt stack_top npc gt IP FP_OF E amp test Ra npc gt CS FP_SEG amp testi_R3 npc gt FLAGS 0x200 npc gt DS _ Ds npc gt ES _ ES Insert np into the ready queue in priority order Repeat for each test process testi_R3 is a func name in procs r3 c e You should also include uniqueness checks on the process names Temporary Commands e Load processes e Will call your load_procs function to load the test processes from procs r3 c e No parameters e Suggested commands load load_test loadrg etc e Dispatch e Will call dispatcher e No parameters e Suggest commands go dispatch e Do not combine these commands you should have one command to load the processes and a separate command to call dispatcher How to use procs r3 c Put prototypes for the test processes in your R3 C or R3 H file ex void testi_R3 void Link procs r3 c with your project when you compile DO NOT INCLUDE IT Use your load command to load the processes Use your dispatch command to run them You should see all 5 test processes run with lines like e Test n dispatched loop count 1 You should be able to load an

CS 450

Contents

Download Pdf Manuals

Related Search

Related Contents