1 / 22

R4

R4 . Dynamically loading processes. Overview. R4 is closely related to R3, much of what you have written for R3 applies to R4 In R3, we executed procedures which were statically linked to our MPX executable

kenyon
Download Presentation

R4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. R4 Dynamically loading processes

  2. Overview • R4 is closely related to R3, much of what you have written for R3 applies to R4 • In R3, we executed procedures which were statically linked to our MPX executable • In R4, we will add command which will dynamically load an executable from disk into dynamically allocated memory. The location of this memory is to be stored into the PCB using the “Load” field, and the point at which execution is to begin in the loaded information should be stored in the “execute” field.

  3. Suggested structure // PCB structure typedef struct PCB{ struct IOCB iocb; char pname[20]; //Process name at least 8 characters int pclass; //A code identifying the process as an //application process or a system process int priority; // range -128 ~ +127 int state; // Running, Ready, Blocked, Suspended Ready, or // Suspended blocked struct PCB * previous; // pointer of the previous PCB in the queue struct PCB * next; // pointer of the next PCB in the queue unsigned char * stack_base; // Stack pointer to the base unsigned char *stack_p; //stackptr int memory; unsigned char *load; //pointer to where the process is loaded unsigned char *execution; //pointer to execution addr } PCB;

  4. Components • A “dispatch” command responsible for invoking the dispatcher for the first time. • “Load program” command which replaces the “create process” command from R2. This command is responsible for creating and initializing a PCB and loading the program that the process will run. (it will use the commands from R2); • “Terminate program” command is responsible for terminating a process and freeing the memory allocated to hold that processes program.

  5. Hints and reminders • Sys_call_handler this interrupt handler is invoked by the executing process, via the 8086 int instruction. Sys_call_handler should: • Save the _SS and _SP into temporary variables. (these local variables should be static..) • Save the current stack information back into the PCB via MK_FP • SWITCH TO A LOCAL (STATIC) TEMPORARY STACK • Determine which action was initiated (IDLE or EXIT) • Dispatch the next process.

  6. Dispatcher: Dispatches the ready processes in a round robin fashion. The PCB at the front of the queue becomes the running process. • Use global variables to save the _SS and _SP of the 1st program to invoke the dispatcher • Get the next ready process • Restore the _SS and _SP from the “stack_pointer” in the PCB • If there is no ready process, restore the _SS and _SP from the original calling process and exit the dispatcher.

  7. MAJOR HINT (modifying _SP and _SS) • If the value of these registers is to be altered, the _SS and _SP must be modified in this order SS then SP. • It is important that they be modified by two consecutive machine instructions!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! • This means via SIMPLE ASSIGNMENT STATEMENTS!!!! NOT ASSIGNMENTS CONTAINING FUNCTION CALLS!!! • IDEALLY DON’T: _SS = FP_SEG(cop->stack_ptr); • Instead: temp_ss = FP_SEG(cop->stack_ptr); temp_sp = FP_OFF(cop->stack_prt); _SS = temp_ss; _SP = temp_sp;

  8. Changes with R4 • Processes are no longer automatically loaded at the beginning of execution. • The are not compiled into your MPX executable • There is a special load command which will load a single process in the suspended state • A dispatch command with will dispatch read processes • There is a special Unload/kill/terminate command which will manually terminate a process.

  9. Load Program Command • This command is an expansion of “create PCB”. It should: • Allocate and set up a new PCB • It will receive the arguments: • Process name • Program file name • Priority • Directory name (my addition to the project)

  10. It will call “sys_check_program) to determine that the program file exists, determine the memory size it requires, and to calculate the “offset” at which execution is to begin in the loaded module. • It will then call sys_alloc_mem to allocate memory in which the program executable will be loaded. This becomes the “load” address of the process. • The “load address” + the “offset” becomes the execution address of the process • “sys_load_program” is invoked to use the MS_DOS relocating loader to load the program into memory starting at the “load” address.

  11. When created the new process should be placed in the suspended state. ( a resume command via the comhan is needed to place the process into the ready state.) • The “context” of the process must also be initialized as in R3, however the CS and IP should be initialized using the “execute address” field from the PCB

  12. The algorithm for this function is: • Check arguments • Check program • Create and setup PCB • Allocate program memory • Load program • Initialize PCB fields (load, execute, and memory size) • Set up PCB context • Place PCB into the suspended ready queue.

  13. Terminate process • This command should terminate a process by deallocating its PCB and releasing its allocated program memory. • This is an extension of the Delete PCB command of Module R2. The PCB should be deallocated as in Delete PCB. • In addition, the program memory must be released using the sys_free_mem support procedure. • The only argument for this command is the process name. An error message should be displayed if the specified process does not exist

  14. Dispatch • Temporary command which dispatches the processes in the ready queue in round-robin order. • It should be identical to your dispatcher in R3.

  15. Sys_Check_program • This routine attempts to access a program file to determine if it exists and is valid. • The file specified must be in MS-DOS exe format. • If the file is valid, this function also returns: • the amount of memory which must be allocated to load the file • The location (relative to the start of the load area) at which execution should begin.

  16. The prototype for the function is: int sys_check_program (char dir_name[], char prog_name[], int *prog_len_p, int *start_offset_p);

  17. dir_name: specifies the pathname for the directory to be searched for the specified file. Only one directory will be searched. The pathname may be absolute or relative, and may contain a drive specifier; if it is null, the current directory will be searched. • prog_name: specifies the file name for the program to be checked. This name should be given with no extension. The file is assumed to have the extension .MPX (although its type is EXE). • prog_len_p: address of a variable of type int which will receive the program length in bytes. This specifies the exact number of bytes which must be allocated for loading this program (including code, data and stack segments). The MS-DOS loader requires that the allocated region be paragraph-aligned. • start_offset_p: address of a variable of type int to receive the offset in bytes from the start of the load area at which execution should begin. This is assumed to be the first location in the code segment.

  18. The returned value will be zero if no problem occurred; otherwise it will be an error code. Possible error codes are: •  ERR_SUP_NAMLNG pathname is too long  • ERR_SUP_FILNFD file not found  • ERR_SUP_FILINV file is not validThe symbols for these codes are defined in MPX_SUPT.H

  19. Sys_load_program • This is called to request the actual loading of a program from a valid program file • Uses the built-in relocating loader of MS-DOS • The file is expected to be checked and measured using “sys_check_program” • Calls “sys_check_program” again to verify the file size • The prototype is: int sys_load_program (void *load_addr, int max_size, char dir_name[],char prog_name[]);

  20. load_addr: specifies the starting address of the memory region into which the program should be loaded. This is normally the address returned by sys_alloc_mem. This address must be aligned on a paragraph boundary; all blocks allocated by sys_alloc_mem meet this criterion. • max_size: specifies the size of the available memory region. An error will be signaled if the program exceeds this size. In this case no loading will occur. • dir_name: specifies the pathname for the directory to be searched for the specified file. Only one directory will be searched. The pathname may be absolute or relative, and it may optionally include a drive specifier; if it is null, the current directory will be searched. • prog_name: Specifies the file name for the program to be loaded. This name should be given with no extension. The file is assumed to have the extension .MPX (although its type is EXE).

  21. Errors • The returned value will be zero if no problem occurred; otherwise it will be an error code. Possible error codes are: •  ERR_SUP_NAMLNG pathname is too long  • ERR_SUP_FILNFD file not found  • ERR_SUP_FILINV file is not valid  • ERR_SUP_PROGSZ  program too big for region  • ERR_SUP_LDADDR invalid load address (e.g., not aligned)  • ERR_SUP_LDFAIL load failed

  22. Test processes • 5 test procedures are provided for your use in testing R4: • PROC1.MPX through PROC5.MPX • Supplied with your support software. • These execute similarly to R3, but execute until “terminated”

More Related