diff --git a/docs/modules/module-06.md b/docs/modules/module-06.md index da4170a..d84146f 100644 --- a/docs/modules/module-06.md +++ b/docs/modules/module-06.md @@ -38,14 +38,14 @@ Set the TICK field of the process table entry of the selected process to 0. /* When the process goes to swap, TICK starts again */ Call the release_page() function in the Memory Manager module to deallocate the valid code pages of the process. -Invalidate the Page table entry correpsonding to the code pages. +Invalidate the Page table entry corresponding to the code pages. For each heap page that is not shared and is valid { /* Shared heap pages are not swapped out. */ Get a free swap block by calling the get_swap_block() function in the Memory Manager module. Store the disk block number in the Disk Map Table entry of the process curresponding to the heap page. Use the disk_store() function in the Device Manager module to write the heap page to the block found above Call the release_page() function in the Memory Manager module to deallocate the page. - Invalidate the Page table entry correpsonding to the page. + Invalidate the Page table entry corresponding to the page. } Get two free swap block by calling the get_swap_block() function in the Memory Manager module. @@ -56,7 +56,7 @@ Call the release_page() function in the Disk Map Table entry of the process corresponding to the heap page. Use the disk_load() function in the Device Manager module to copy the heap page found above to the memory. Free the swap block by calling the release_block() function in the Memory Manager module. - Set the Page table entry correpsonding to the page. Reference bit is set to 0, valid bit and write bit are set to 1. + Set the Page table entry corresponding to the page. Reference bit is set to 0, valid bit and write bit are set to 1. Invalidate the Disk Map Table entry corresponding to the heap page. } @@ -107,7 +107,7 @@ Get two free memory pages by calling the get_free_page() function in the Use the disk_load() function in the Device Manager module to load the two stack pages to the memory allocated above. -Set the Page table entries correpsonding to the two stack pages. The pages are valid, unreferenced and writable. +Set the Page table entries corresponding to the two stack pages. The pages are valid, unreferenced and writable. Call the release_block() function in the Memory Manager module to deallocate the two swap blocks. @@ -134,4 +134,4 @@ Called by timer interrupt. - \ No newline at end of file + diff --git a/docs/os-design/close.md b/docs/os-design/close.md index d1d5aee..82f2c69 100644 --- a/docs/os-design/close.md +++ b/docs/os-design/close.md @@ -49,7 +49,7 @@ If the Resource identifier field of the Open File Table entry from Per-Process Resource Table entry. -Call the close() function in the File Manager module with the Open File Table index as arguement. +Call the close() function in the File Manager module with the Open File Table index as argument. Invalidate the Per-Process Resource Table entry. diff --git a/docs/os-design/exec.md b/docs/os-design/exec.md index 76463c3..0fadd3e 100644 --- a/docs/os-design/exec.md +++ b/docs/os-design/exec.md @@ -57,7 +57,7 @@ to invoke the memory manager module for allocating a fresh user area page (why?) Set SP to User Area Page Number * 512 - 1 /* Start fresh in the new kernel stack */ -Initilize the Per-process Resource Table by setting all entries to -1. +Initialize the Per-process Resource Table by setting all entries to -1. In the Process Table entry of the current process, set the Inode Index field to the index of Inode Table entry for the file and set the state as RUNNING. diff --git a/docs/os-design/fork.md b/docs/os-design/fork.md index 39102ef..ad1c482 100644 --- a/docs/os-design/fork.md +++ b/docs/os-design/fork.md @@ -72,7 +72,7 @@ to the new UA Page, MODE, TICK and Kernel Stack Pointer to 0. /* Kernel Context of the child process is empty */ -/* PID, PTBR, PTLR fields of the child's process table is initilized by the get_pcb_entry function.*/ +/* PID, PTBR, PTLR fields of the child's process table is initialized by the get_pcb_entry function.*/ Copy the per-process resource table and per-process disk map table. For every open file of the parent, increment the Open Instance Count in the Open File Table. @@ -104,4 +104,4 @@ Restore SP to User SP and return to the parent process. !!! note - At each point of return from the system call, remember to reset the MODE FLAG and switch back to the user stack. \ No newline at end of file + At each point of return from the system call, remember to reset the MODE FLAG and switch back to the user stack. diff --git a/docs/os-design/multiusersyscalls.md b/docs/os-design/multiusersyscalls.md index e6c68ff..553557e 100644 --- a/docs/os-design/multiusersyscalls.md +++ b/docs/os-design/multiusersyscalls.md @@ -249,7 +249,7 @@ This system call is used to login a new user. It can be executed only from the l Get the User Table entry curresponding to the username. If an entry does not exist, return -1. - Use the ecrypt statement to encrypt the password supplied as input. + Use the encrypt statement to encrypt the password supplied as input. If the encypted input password does not match the ENCRYPTED PASSWORD field in the user table entry, return -1. diff --git a/docs/os-design/term-handler.md b/docs/os-design/term-handler.md index f07ce06..64b846a 100644 --- a/docs/os-design/term-handler.md +++ b/docs/os-design/term-handler.md @@ -39,7 +39,7 @@ ireturn; !!! question - When interrupts or system calls are invloked, the mode changes from user to kernel. Registers are backed up using the BACKUP instruction in the case of interrupts and not in the case of system calls. Why? + When interrupts or system calls are invoked, the mode changes from user to kernel. Registers are backed up using the BACKUP instruction in the case of interrupts and not in the case of system calls. Why? diff --git a/docs/os-spec/expos-abstractions.md b/docs/os-spec/expos-abstractions.md index 0ef7acc..8a4099f 100644 --- a/docs/os-spec/expos-abstractions.md +++ b/docs/os-spec/expos-abstractions.md @@ -17,7 +17,7 @@ eXpOS provides the following fundamental abstractions to an application program: ### The eXpFS logical file system -The eXpOS kernal provides a hardware independent logical file system model (called the **experimental file system or eXpFS**) for application programs. The application program views files as being organized and stored in the eXpFS logical file system. Application programs are not permitted to access files directly. Instead, they must invoke the appropriate **file system call** for creating, modifying or accessing files. The OS routine implementing each system call internally translates the request into disk block operations, hiding the hardware details from the application program. +The eXpOS kernel provides a hardware independent logical file system model (called the **experimental file system or eXpFS**) for application programs. The application program views files as being organized and stored in the eXpFS logical file system. Application programs are not permitted to access files directly. Instead, they must invoke the appropriate **file system call** for creating, modifying or accessing files. The OS routine implementing each system call internally translates the request into disk block operations, hiding the hardware details from the application program. eXpFS support three kinds of files - **data files, program files** (executable files) and a special file called the **root file.** The root file is a meta-data file that contains the list of all files in the file system. A data file consists of a sequence of words. A program contains a header, a sequence of machine instructions called text and static data, if any. @@ -38,7 +38,7 @@ A detailed discussion of the file system structure, file system calls and XEXE f ### The eXpOS process Abstraction -It was noted earlier that at the end of bootstrap, eXpOS loads into memory a program stored in a pre-determined part of the disk and creates the first process called the INIT process. Once a process is created, it can spawn new processes using the **fork** system call. When a process spawns a new process, the former is called the **parent process** and the later is called the **child process**. A process can decide to terminate itself using the **exit** system call. +It was noted earlier that at the end of bootstrap, eXpOS loads into memory a program stored in a pre-determined part of the disk and creates the first process called the INIT process. Once a process is created, it can spawn new processes using the **fork** system call. When a process spawns a new process, the former is called the **parent process** and the latter is called the **child process**. A process can decide to terminate itself using the **exit** system call. * In the extended eXpOS specification, the INIT process is called the LOGIN process and is executed directly by the kernel. This process invokes the login system call to log a user in. Once a user is logged in, the shell process is created for the user and the original login process waits for the termination of the user shell, to log in the next user. @@ -92,10 +92,10 @@ The file sharing semantics between users in Multiuser extension to eXpOS is desc ### System Calls -The eXpOS system calls are software interrupt routines of the eXpOS kernal which are loaded into the memory when the OS is bootstrapped. These routines define the services provided by the OS to application programs. These services include accessing files and semaphores, creating new processes , sending a signal to another process etc. +The eXpOS system calls are software interrupt routines of the eXpOS kernel which are loaded into the memory when the OS is bootstrapped. These routines define the services provided by the OS to application programs. These services include accessing files and semaphores, creating new processes , sending a signal to another process etc. -Application programs are not permitted to directly access files/semaphores or create new processes. Instead they must invoke the corresponding system call routines. System calls are kernal routines and operate in **privileged or system mode**. Thus when an application program invokes a system call (by invoking the corresponding software interrupt), a change of mode from unprivileged mode to privileged mode occurs. The system call code checks whether the request is valid and the process has permission to the resources/actions requested and then perform the request. Upon completion of the interrupt service routine, control is transferred back to the user process with a switch back to the unprivileged mode. +Application programs are not permitted to directly access files/semaphores or create new processes. Instead they must invoke the corresponding system call routines. System calls are kernel routines and operate in **privileged or system mode**. Thus when an application program invokes a system call (by invoking the corresponding software interrupt), a change of mode from unprivileged mode to privileged mode occurs. The system call code checks whether the request is valid and the process has permission to the resources/actions requested and then perform the request. Upon completion of the interrupt service routine, control is transferred back to the user process with a switch back to the unprivileged mode. eXpOS system calls can be classified as file system calls, process system calls and system calls for access control and synchronization. The following table lists the system calls. A detailed specification can be found [here](systemcallinterface.md). diff --git a/docs/roadmap/stage-16.md b/docs/roadmap/stage-16.md index d9b3f08..767077b 100644 --- a/docs/roadmap/stage-16.md +++ b/docs/roadmap/stage-16.md @@ -27,7 +27,7 @@ infer that the execution of the IN instruction is complete. As noted above, the IN instruction is typically executed from the Terminal Read function. Since it is not useful for the process that invoked the Terminal Read function to continue -execution till data arrives in P0, **a process executing the IN instruction will sets its state to WAIT_TERMINAL and invoke the scheduler**. The process must resume execution only after the XSM machine sends an interrupt upon data arrival. +execution till data arrives in P0, **a process executing the IN instruction will set its state to WAIT_TERMINAL and invoke the scheduler**. The process must resume execution only after the XSM machine sends an interrupt upon data arrival. When the console interrupt occurs, the machine interrupts the current process (note that some diff --git a/docs/roadmap/stage-17.md b/docs/roadmap/stage-17.md index 2ec7d69..ffcdab7 100644 --- a/docs/roadmap/stage-17.md +++ b/docs/roadmap/stage-17.md @@ -237,7 +237,7 @@ memory page and updates the WAIT_MEM_COUNT and MEM_FREE_COUNT in the system stat Since the page storing the kernel context has been de-allocated, before making any function call, a stack page has to be allocated to store parameters, return address etc. It is unsafe to invoke the Get Free Page function of the memory manager module before allocating a stack page (why?). ??? question "Q2 Why should the OS set the WRITE PERMISSION BIT for library and code pages in each page table entry to 0, denying permission for the process to write to these pages?" - ExpOS does not expect processess to modify the code page during execution. Hence, + ExpOS does not expect processes to modify the code page during execution. Hence, during a fork() system call (to be seen in later stages), the code pages are shared between several processes. Similarly, the library pages are shared by all processes. If a process is allowed to write into a code/library page, the shared program/library will diff --git a/docs/roadmap/stage-18.md b/docs/roadmap/stage-18.md index 9dd6bc3..4aab8ab 100644 --- a/docs/roadmap/stage-18.md +++ b/docs/roadmap/stage-18.md @@ -35,7 +35,7 @@ acquired the disk, the PID of the process is also stored in the disk status tabl constant [DISK_STATUS_TABLE](../support-tools/constants.md)gives the starting address of the Disk Status Table in the[XSM memory](../os-implementation.md). After the current process has acquired the disk for loading, it initializes the Disk Status -Table according to the operation to be perfromed (read/write). The process then issues the +Table according to the operation to be performed (read/write). The process then issues the load statement to initiate the loading of the disk block to the memory page. As mentioned earlier, the XSM machine does not wait for the transfer to complete. It continues with the execution of the next instruction. However, virtually in any situation in eXpOS, the process has to wait @@ -155,4 +155,4 @@ Compile and load the modified and newly written files into the disk using XFS-in !!! assignment "Assignment 1" - Use the[XSM debugger](../support-tools/xsm-simulator.md)to print out the contents of the Disk Status Table after entry and before return from the disk interrupt handler. \ No newline at end of file + Use the[XSM debugger](../support-tools/xsm-simulator.md)to print out the contents of the Disk Status Table after entry and before return from the disk interrupt handler. diff --git a/docs/roadmap/stage-19.md b/docs/roadmap/stage-19.md index 2c3a2d2..9961cad 100644 --- a/docs/roadmap/stage-19.md +++ b/docs/roadmap/stage-19.md @@ -52,7 +52,7 @@ application, but because the OS had not loaded the page and set the page tables. present strategy of "lazy allocation" to be described now. The strategy followed in this stage is to start executing a process with just one page of code and two pages of stack allocated initially. When the process, during execution, tries to access a page that was not - loaded, an exception is generated and the execption handler will allocate the required page. + loaded, an exception is generated and the exception handler will allocate the required page. If the required page is a code page, the page will be transferred from the disk to the allocated memory. Since pages are allocated only on demand, memory utilization is better (on the average) with this approach. @@ -247,4 +247,4 @@ Compile and load the modified and newly written files into the disk using the XF Write an ExpL program to implement a linked list. Your program should first read an integer N, then read N intergers from console and store them in the linked list and print the linked list to the console. Run this program using shell version-I of stage 17. !!! assignment "Assignment 2" - Use the [XSM debugger](../support-tools/xsm-simulator.md) to dump the contents of the Exception Flag registers upon entry into the Exception Handler. Also, print out the contents of the Disk Map Table and the Page Table after the Get Code Page function (inside the Memory Manager module). \ No newline at end of file + Use the [XSM debugger](../support-tools/xsm-simulator.md) to dump the contents of the Exception Flag registers upon entry into the Exception Handler. Also, print out the contents of the Disk Map Table and the Page Table after the Get Code Page function (inside the Memory Manager module). diff --git a/docs/roadmap/stage-20.md b/docs/roadmap/stage-20.md index fde64e8..e41a50a 100644 --- a/docs/roadmap/stage-20.md +++ b/docs/roadmap/stage-20.md @@ -31,7 +31,7 @@ to the child, and the kernel stack of the child is set to empty (that is, KPTR f process table entry of the child is set to 0.) -Fork system call returns to the the parent process. The parent resumes execution from the +Fork system call returns to the parent process. The parent resumes execution from the next instruction following the INT instruction invoking fork. Upon successful completion, fork returns the PID of the child process to parent process. @@ -103,9 +103,9 @@ stored in the PPID field of the process table of the child. [STATE](../os-design - The [per-process resource table](../os-design/process-table.md#per-process-resource-table) has details about the open instances of the files and the semaphores currently acquired by the process. Child process shares the files and the semaphores opened by the parent process. Hence we need to copy the entries of the per-process resource table of the parent to the child. We will discuss files and semaphores in later stages. (There is a little bit more book keeping work associated with files and semaphores. Since we have not added files or semaphores so far to the OS, we will skip this work for the time being and complete the pending tasks in later stages). -- Copy the [per-process disk map table](../os-design/process-table.md#per-process-disk-map-table) of the parent to the child. This will ensure that the disk block numbers of the code pages of the parent process are copied to the child.Further, if the parent has swapped out heap pages, those will be shared by the child. (This will be explained in detail in a later stage). The eXpOS design guarentees that the stack pages and the user area page of a process will not be swapped at the time when it invokes the fork system call. Hence the disk map table entries of the parent process corresponding to the stack and user area pages will be invalid, and these entries of the child too must be set to invalid. +- Copy the [per-process disk map table](../os-design/process-table.md#per-process-disk-map-table) of the parent to the child. This will ensure that the disk block numbers of the code pages of the parent process are copied to the child.Further, if the parent has swapped out heap pages, those will be shared by the child. (This will be explained in detail in a later stage). The eXpOS design guarantees that the stack pages and the user area page of a process will not be swapped at the time when it invokes the fork system call. Hence the disk map table entries of the parent process corresponding to the stack and user area pages will be invalid, and these entries of the child too must be set to invalid. -- Initialize the [page table](../os-design/process-table.md#per-process-page-table)of the child process. As heap, code and library pages are shared by the parent process and the child process, copy these entries (page number and auxiliary information) form the page table of the parent to the child. For each page shared, increment the corresponding share count in the [memory free list](../os-design/mem-ds.md#memory-free-list)(why do we do need to do this?). Initialize the stack page entries in the page table with the new memory page numbers obtained earlier. Note that the auxiliary information for the stack pages is same for both parent and child (why?). Copy content of the user stack pages of the parent to the user stack pages of the child word by word. +- Initialize the [page table](../os-design/process-table.md#per-process-page-table)of the child process. As heap, code and library pages are shared by the parent process and the child process, copy these entries (page number and auxiliary information) from the page table of the parent to the child. For each page shared, increment the corresponding share count in the [memory free list](../os-design/mem-ds.md#memory-free-list)(why do we do need to do this?). Initialize the stack page entries in the page table with the new memory page numbers obtained earlier. Note that the auxiliary information for the stack pages is same for both parent and child (why?). Copy content of the user stack pages of the parent to the user stack pages of the child word by word. - Store the value in the BP register on top of the kernel stack of child process. This value will be used to initialize the BP register of the child process by the scheduler when the child is scheduled for the first time. @@ -132,7 +132,7 @@ The context-switch (scheduler) module is modified in this stage. The BP register has to be initiazed by the scheduler for the first time as child is in created state. Refer to the detailed schedular algorithm [here](../modules/module-05.md). -- When the process is in created state, add folllowing steps before switching to user stack. +- When the process is in created state, add following steps before switching to user stack. - Store the value in the first word of the kernel stack to the BP register. #### Exit System Call diff --git a/docs/roadmap/stage-23.md b/docs/roadmap/stage-23.md index f3148a0..764f5a8 100644 --- a/docs/roadmap/stage-23.md +++ b/docs/roadmap/stage-23.md @@ -4,7 +4,7 @@ original_url: https://exposnitc.github.io/Roadmap.html --- !!! note - - Familiarize with eXpOS file system and implemtation. + - Familiarize with eXpOS file system and implementation. - Add support for file creation and deletion to the OS by implementing Create and Delete system calls !!! abstract "Pre-requisite Reading" @@ -117,4 +117,4 @@ Compile and load the newly written/modified files to the disk using XFS-interfac Write an ExpL program to take file name(string) and permission(integer) as input from the console and create a file with the provided input. (It is recommended to have .dat as extension for data files.) Run this program using shell. Using XFS-interface check if the entry for the file is created in inode table and root file. !!! assignment "Assignment 2" - Write an ExpL program to take file name(string) as input from the console and delete a file with provided input. Run the program using shell. Using XFS-interface check if the entry for the file is deleted from inode table and root file. Check the program for different files- like files created using Create system call, files not present in disk and files loaded using XFS-interface having some data (eg- sample.dat used in stage 2). \ No newline at end of file + Write an ExpL program to take file name(string) as input from the console and delete a file with provided input. Run the program using shell. Using XFS-interface check if the entry for the file is deleted from inode table and root file. Check the program for different files- like files created using Create system call, files not present in disk and files loaded using XFS-interface having some data (eg- sample.dat used in stage 2). diff --git a/docs/roadmap/stage-27.md b/docs/roadmap/stage-27.md index 93a8f5a..2e5ba2e 100644 --- a/docs/roadmap/stage-27.md +++ b/docs/roadmap/stage-27.md @@ -27,7 +27,7 @@ When does the OS check for MEM\_LOW/MEM\_HIGH condition? This is done in the [ti We will modify the timer interrupt handler in the following way. Whenever it is entered from the context of any process **except** a special **swapper daemon process** (to be described later), the handler will inspect the TICK status of the swapped out processes and the memory availability status in the system status table to decide whether a swap-in/swap-out must be initiated. If swap-in/swap-out is needed, the timer will set the PAGING\_STATUS field in the system status table to SWAP\_IN/SWAP\_OUT appropriately to inform the scheduler about the need for a swap-in/swap-out. The timer handler then passes control to the scheduler. Note that the timer does not initiate any swap-in/swap-out now. We will describe the actions performed when the timer interrupt handler is entered from the context of the swapper daemon soon below. -We will modify the eXpOS scheduler to schedule the swapper daemon whenever PAGING\_STATUS field in the system status table is set to SWAP\_IN/SWAP\_OUT. The OS reserves PID=15 for the swapper daemon process. (Thus the swapper daemon joins login, shell and idle processess as special processess initiated by the kernel.) **The swapper daemon shares the code of the idle process, and is essentially a duplicate idle process running with a different PID. Its sole purpose is to set up a user context for swapping operations.** A consequence of the introduction of the swapper daemon is that only 12 user applications can run concurrently now. +We will modify the eXpOS scheduler to schedule the swapper daemon whenever PAGING\_STATUS field in the system status table is set to SWAP\_IN/SWAP\_OUT. The OS reserves PID=15 for the swapper daemon process. (Thus the swapper daemon joins login, shell and idle processes as special processes initiated by the kernel.) **The swapper daemon shares the code of the idle process, and is essentially a duplicate idle process running with a different PID. Its sole purpose is to set up a user context for swapping operations.** A consequence of the introduction of the swapper daemon is that only 12 user applications can run concurrently now. If the timer interrupt handler is entered from the context of the swapper daemon, then it will call the Swap-in/Swap-out functions of the pager module after inspecting the value of PAGING\_STATUS in the system status table. **Thus, swap-in/swap out will be initiated by the timer interrupt handler only from the context of the swapper daemon.** @@ -49,7 +49,7 @@ The handler must check whether the current process is the [swapper daemon](../os If the current process is the idle process, there are two possibilities. If swapping is ongoing (check PAGING\_STATUS), one can infer that Idle was scheduled because the swapper daemon was blocked. In this case, the timer must invoke the scheduler. (The scheduler will run Idle again if the daemon is not unblocked. Otherwise, the daemon will be scheduled.) The second possibility is that swapping was not on-going. This case is not different from the condition to be checked when timer is entered from any process other than the paging process, and will be descibed next. -Generally, when the timer handler is entered from a process when scheduling was not on, the handler must decide whether normal scheduling shall continue or swap-in/swap-out must be inititiated. Swap-in must be initiated if the value of MEM\_FREE COUNT in the system status table is below MEM\_LOW. Swap-out must be inititated if either a) memory availability is high (MEM\_FREE\_COUNT value exceeds MEM\_HIGH) or b) some swapped process has TICK value exceeding the threshold MAX\_TICK. +Generally, when the timer handler is entered from a process when scheduling was not on, the handler must decide whether normal scheduling shall continue or swap-in/swap-out must be inititiated. Swap-in must be initiated if the value of MEM\_FREE COUNT in the system status table is below MEM\_LOW. Swap-out must be initiated if either a) memory availability is high (MEM\_FREE\_COUNT value exceeds MEM\_HIGH) or b) some swapped process has TICK value exceeding the threshold MAX\_TICK. Another modification in the Timer interrupt is to increment the TICK field in the [process table](../os-design/process-table.md) of every NON-TERMINATED process. When a process is created by the Fork system call, the TICK value of the process is set to 0 in the process table. Each time the system enters the timer interrupt handler, the TICK value of the process is incremented. The TICK value of a process is reset to zero whenever the process is swapped out or swapped in. Thus the tick value of a process that is not swapped out indicates for how long that process had been in memory without being swapped out. Similarly, the tick value of a swapped out process indicates how long the process had been in swapped state. The swap-in/swap-out algorithms will use the value of TICK to determine the process which had been in swapped state (or not swapped state) for the longest time for swapping in (or out). diff --git a/docs/support-tools/spl.md b/docs/support-tools/spl.md index fc1e4d3..0154c64 100644 --- a/docs/support-tools/spl.md +++ b/docs/support-tools/spl.md @@ -444,7 +444,7 @@ call 511; /* Transfers control to the first page in memory */ Each SPL System Call Handler/Interrupt Handler/Module is designed to occupy a maximum of two pages of continuous memory in the XSM machine. (Sometimes, the generic term "module" is abused to indicate all types of routines of the above categories, though we avoid this usage here). They contain protected mode code that carries out certain functions as determined by the OS programmer. -The following suggests certain programming conventions which are recommend while designing SPL modules and interrupt handlers. +The following suggests certain programming conventions which are recommended while designing SPL modules and interrupt handlers. These routines may be entered as a result of: 1. A **system call handler** is entered upon execution of a software interrupt from an application (user mode) program. @@ -519,4 +519,4 @@ The **reset** instruction when executed from primary core of the [NEXSM machine] **SYNTAX :** `reset;` This statement translates to the [RESET machine instruction](../arch-spec/nexsm.md#additional-privileged-mode-instructions). - \ No newline at end of file + diff --git a/docs/tutorials/xsm-interrupts-tutorial.md b/docs/tutorials/xsm-interrupts-tutorial.md index f364d4c..58f099f 100644 --- a/docs/tutorials/xsm-interrupts-tutorial.md +++ b/docs/tutorials/xsm-interrupts-tutorial.md @@ -31,7 +31,7 @@ Then, every time the machine completes executing ten instructions in unprivilege 2. Set IP to value stored in the interrupt vector table entry for the timer interrupt handler. The vector table entry for timer interrupt is located at physical address 493 in page 0 (ROM) of XSM and the value 2048 is preset in this location. Hence, the IP register gets value 2048. - The machine then switches to to privileged mode and address translation is disabled. + The machine then switches to privileged mode and address translation is disabled. Hence, next instruction will be fetched from physical address 2048. (See Boot ROM and Boot block section in [XSM Machine Organization](../arch-spec/machine-organization.md) documentation) @@ -77,7 +77,7 @@ After the execution of each instruction in unprivileged mode, the machine checks disk/console/timer interrupt. If so, the machine does the following actions: 1. **\***Push the IP value into the top of the stack. -2. Set IP to value stored in the interrupt vector table entry for the timer interrupt handler. The vector table entry for timer interrupt is located at physical address 493 in page 0 (ROM) of XSM and the value 2048 is preset in this location. Hence, the IP register gets value 1. The machine then switches to to privileged mode and address translation is disabled. Hence, next instruction will be fetched from physical address 2048. (See Boot ROM and Boot block section in [XSM Machine Organization](../arch-spec/machine-organization.md) documentation) +2. Set IP to value stored in the interrupt vector table entry for the timer interrupt handler. The vector table entry for timer interrupt is located at physical address 493 in page 0 (ROM) of XSM and the value 2048 is preset in this location. Hence, the IP register gets value 1. The machine then switches to privileged mode and address translation is disabled. Hence, next instruction will be fetched from physical address 2048. (See Boot ROM and Boot block section in [XSM Machine Organization](../arch-spec/machine-organization.md) documentation) !!! note If the value in the SP register after incrementing SP is an invalid address (i.e., not in the range 0 to PTLR\*512-1) then the machine generates an **illegal memory access exception** (see section below on exception handling). The machine will re-execute steps (1) and (2) immedietly after retrun to unprivileged mode, before executing any other instruction in unprivileged mode. @@ -105,7 +105,7 @@ the XSM machine raises an exception. a) **Illegal Memory Access:** Occurs when any address generated by the application lies outside its logical address space. This also occurs when the process tries to write into pages whose [Write access bit](../arch-spec/paging-hardware.md) is not set in the page table. Recall that the logical page number generated for a valid instruction should be between 0 and the value of (512 \* PTLR) - 1. b) **Illegal instructions:** Occurs when an application tries to execute an instruction not belonging to the instruction set or when an operand/data in an instruction is not legal. (Example: MOV 4 R0, MOV IP, 4) c) **Arithmetic exception:** Occurs when there is a division/modulus by zero. (Example: DIV R0, 0) -In all the above cases, the typical action is for the exception handler code is to pass control to other privileged mode OS routines to terminate the application and schedule other applications. d) **Page fault:** This is the most significant exception handling function that must be understood clearly. A page fault occurs if an instruction contains an address whose logical page number is within the range 0 to PTLR-1 and the [valid bit](../arch-spec/paging-hardware.md) in the corresponding page table entry is set to to 0. +In all the above cases, the typical action is for the exception handler code is to pass control to other privileged mode OS routines to terminate the application and schedule other applications. d) **Page fault:** This is the most significant exception handling function that must be understood clearly. A page fault occurs if an instruction contains an address whose logical page number is within the range 0 to PTLR-1 and the [valid bit](../arch-spec/paging-hardware.md) in the corresponding page table entry is set to 0. Page fault exception can occur either during instruction fetch or operand fetch. Suppose during execution of an application, the value of IP reaches value – say 3000. The next fetch will try to translate the logical address 3000 to physical address using the page table. The logical page number corresponding to address 3000 is 3000 DIV 512 = 5. The machine must look up the page table entry corresponding to logical page 5. If the valid bit for this entry is set to 0, the page reference is invalid. In this case, the machine will raise an exception. @@ -136,4 +136,4 @@ c) **EC** (Exception Cause): The EC register will indicate the cause of the exce d) **EMA** (Exception memory address): _The value of this register is relevant only in the case of illegal memory access._ The illegal memory which was tried to be accessed is stored in the register. Either the address referred to is outside the range 0 - 512\*(PTLR-1) or a write is attempted to a page which is [read-only](../arch-spec/paging-hardware.md). -**The [XSM interrupt/exception handling documentation](../arch-spec/interrupts-exception-handling.md) gives a more detailed technical description of the actions performed by the machine when interrupts or exceptions occur. You may have a quick look at the documentation now, but refer to relevant sections of the documentation only as and when required.** \ No newline at end of file +**The [XSM interrupt/exception handling documentation](../arch-spec/interrupts-exception-handling.md) gives a more detailed technical description of the actions performed by the machine when interrupts or exceptions occur. You may have a quick look at the documentation now, but refer to relevant sections of the documentation only as and when required.**