Hello again, before we see processes in virtual memory lets talk a little bit more about control flow. There'll be some special things about control flow that's going to be useful to implement process extractions in virtual memory, okay? So, if you recall, processors do one thing, right? They execute one instruction after the other. From start up to shut down. 'Kay. So the CPU simply reads and executes a sequence of instructions one at a time. 'Kay. This is what we call control flow. 'Kay. From start up to shutdown we execute one instruction after the other. This is control flow. Okay. So, how do we change the control flow? Up to now we saw two ways. First, we saw jumps seen them when we saw Sandy program. Remember, there were jump instructions that changed the control flow. We used that to implement things like loops, conditionals, if then else etc. And we also saw call and return, which is used to implement procedures, okay? It's used to implement procedure calls and so on. And both of these changes of a control flow, they react to program states, they're part of your program and they react. To the program state, okay? So but the processor also needs to change the control flow to react to changes in system state, not, not program state, okay? So by, by, [INAUDIBLE] changes to system state I mean things like, what if the user hits control C at the keyboard? Somehow the program has to been interrupted, right? And if the user clicks on the mouse, or like me I'm using the pen here to write, on, on the slide, I'm changing the system state, and there's a program, in this case a Powerpoint program, is reacting to my pen touching the tablet here. Okay? So these are all things that external to the program. They're part of the system state, somehow the program has to react to it. And the way the program reacts to it is by changing its control flow. Okay? Other examples are when data arrives from the disk or the network adapter, somehow the program has to go and read data. From the network adapter and the disk and to, to process it. Okay? And also there's things like if you do division by zero, something that's undefined. So somehow the program has to, to do something it's control flow to deal with that situation. Or if the system timer expires, you know, from time to time. This is device, called the timer, the real timer, the real time timer in your system. That, from time to time it, it's, interrupts the processor to tell it like, a,a,a certain amount of wall clock time has passed. It's going to be useful to implement contact switches that we're going to see later in this module. But now the real question is, can jumps and procedure cause implement this. Well, you really can't, right, so they're not sufficient. We need systems for exceptional control flow for things that are not part of the program state. So, the way we implement control, exceptional control flow is by using what we call exceptions. Okay, so, an exception is transfer control to the operating system okay, in response to some events. For example, some change in process through a stage. So, here's how it happens. Okay, so, say that our, our user process is executing our codes and then this is the current instruction being executed. Then when, when, when a certain event happens that leads to a exception, for example we have a division by zero, or we have something called a page fault, or some I/O request completes, or even when you type Ctrl+C. In your in your keyboards. So the program gets interrupted and then there's, then exception happens. Okay? And the control is transferred to the operating system. Okay? So in this exception processing the os is done by the exception handler. Okay? The exception handler is nothing more than a piece of code in the operating system that handles what should be done when a certain event that's an exception happens. Okay, and whenever the operating system is done with processing that exception, it returns to the instruction that was that was being executed by the user process. It will return to the current instruction, it could be return to the next instruction or it could even decide to simply abort. The program, okay? So an important question is how does the system know which exception hander, handler to execute? Well, that's going to depend on the exception that happens. So, and there's something in your system called interrupt vector that all it does is it maps the exception. An exception, in each exception has a number. To the codes that handles that exception. So it's not, so the interrupt vector is just a table that's indexed by the exception number. And the contents of this table is a pointer to an instruction that many, that the first instruction to block off codes, that, treats that deals with that exception. Okay? So, it, it's an interact jump table. Okay? Great. So, and the way we do this, well each type of event has a unique exception number, okay? And, and that's, a number K. And this K is an index to the exception table. Also known as interrupt vector. So and then this handler is called every time a certain exception is executed. So, whenever exception K happens, the, handler K is executed. Okay, so there's two types of exceptions. The first time, the, the, the first type is an asynchronous exception. Also known as interrupts. And the reason they're called asynchronous it's because they are caused by events external to the processor. So they are indicated by setting the processors interrupt pins so the processor, right as you saw there's a bunch of pins in the processor. So these pins, we call interrupt pins. So whenever we put a signal in this interrupt pin, something happens inside the processor. So an exception is raised. And then the processor, executes, jumps to, to the piece of code responsible for dealing with that interrupt. For example this interrupt could be, time stopping the timer. Okay? Or you could be the mouse click, and so on, okay? So, for example, it could be hitting the Ctrl+C on the keyboard, as I said, just clicking on the mouse button or touching the touch screen like what I'm doing right now. A packet arrives from the network, and so on. Okay? So, now the other type of exceptions that we called synchronous exceptions and synchronous exceptions are caused by events that are triggered by executing an instruction, an instruction to something that's undefined, that's potentially bad. There's three types of synchronous exceptions. One is called traps is a just an intentional way of transferring the control flow to the operating system to perform some functions. In fact, that's, that's a fact of the operating system, API. A trap is a way of an application to transfer the attention to the operating system so you can do something for the application. Okay. We, we call that system calls. Okay? So that's, that's the operating system API. But there are also other types of traps. Whenever using GDB, we insert a break point into your code. It adds what we call break point trap. So you code continues, your code executes. Whenever it reaches this break point it sets a trap, it diverts execution, to the debugger. Okay? And, and so on. Okay? Great. So and the traps, they return control to the next instruction that's that call, the instruction after the one that caused this intentional trap. The other type of synchronous exceptions that we call fault. These are unintentional, was not intention of the program. Okay? But they are possibly recoverable. For example, if you have a page fault which you're going to see in more detail in in, in future memories when the program touch a piece of memory that is not actually in memory, that's a fault in the tran, trans, the transfer is, is the control is transferred to the operating system to deal with that situation. Okay. we're going to see an example on that a little later in this video, okay? So or we have, segment protection fault, which you might have seen segfault when execute some of your programs. It's exactly what happened. So, you, you might have touched a piece of memory that's undefined and then that's unrecoverable so your program is aborted. Another example of a fault is when you do division by zero, [UNKNOWN] division by zero is undefined that leads to an exception, and your program might have to deal with it. It can potentially be unrecoverable, okay? So, and in the case of a fault, the program either re-executes the faulty instruction or the program aborts. Finally, the last type of synchronous exceptions will be called aborts. They are unintentional and unrecoverable, okay? One example is when you have a parity error or machine check that happens because an instruction has touched something that is bad in your system, okay? And it just simply aborts the program because it is just unrecoverable. So now let's see an example of a trap. Okay an example, we using it to transfer control to the operating system. Okay. So, opening a file requires an operating system, service, okay? And that's going to be done using a trap, so for example every time your program opens a file, eventually it's going to open call this open function that takes a file name as a parameter and then some options on whether the file is for read, write or both. Okay. And if you look at the assembly code for this function open, you're going to see this instruction here int hex 80, okay. So, this diverts, this int is a, is a trap that diverts the execution to, so your process executing here. So, the it is example that your program is execute, whenever it reaches, it executes int. It, it's a, as I said it's an exception, it's a trap. Control is transferred to the operating system. And the operating system knows, based on a number it needs to open a file. So it opens a file and returns to here's the code so you can go have the manipulator file. Okay so in what the OS does here is has to find or create a file. And get it ready for reading or writing, okay? And then it returns the file descriptor. So that's why there's a pop here. Okay? Now another example, this is similar of a trap. Lets look at a example of a fault. Okay. Remember that a fault is an, is a asynchronous exception that happens due to something that you instruction that an instruction does, okay. So let's see what happens here. See that we have this piece of code here. Okay. So eventually we're going to touch memory. An now so the, the user just writes memory location. And if it so happens that if the portion of the users memory is currently on disk, it's not in actual memory, okay, you're going to see that in more detail in virtual memory, but it could happen that whenever you touch a memory location, the memory actually isn't there yet. So we have to transfer control to the operating system to actually map that page in. Okay? So here's our instruction that's being executed. Whenever we execute that instruction it could be that if it so happens that the page is not in memory yet. This leads to what we call page fault exception. Okay? The transfer again, transfer control to the operating system that's going to create a page and load it into memory. And whenever that's done it's going to go back. And note that now the difference that it's going to re-execute the memory access because now the page is there. So we can go and actually execute the, the memory access. Okay? So in a, in this case the page handler here that's executed by the operating system loads the page into physical memory. And returns to the faulty instructions. So, move has to be executed again. Okay. So, and hopefully the second time it's going to be successful it could map, if it could map the, the page. Now, if you touch a bad memory location, like let's say you just have a pointer problem, okay. You just had a pointer problem in your codes, so that could be an invalid memory reference. So, in that case, if you touch a piece of memory that's not mapped, but the OS cannot find a, the operating system cannot find a valid mapping as for [INAUDIBLE] codes. Okay, your execution, the execution of your program. So, let's look at this example again. We have our move instruction here. For re-executing [SOUND], it reaches the move instruction and then that leads to page fault because it's unmapped but the OS determines that, you know what, not only it's unmapped but this address is invalid. So what it needs to do, so just have to go and signal the processing like, unfortunately, I'm going to have to abort you. So it send this zigzag fault to the user process and the user process exits with a segmentation fault here. Okay? So, now to, to summarize. Exceptions are events that require non center control flow. That means that, not, with you know, jumps, or, call. Okay? They can be generated externally because of interrupts or internally in case of traps and faults. And, the exception is handled by the operating system. And when your operating system handles an exception, one of three things could happen. It re-executes the current instruction, in the case of, for example, page faults. It could resume the execution with next instruction. That is the case of doing a trap and using operating system services like opening file, reading or writing to a file. Or you might choose to abort the process in case, the exception is unrecoverable. See you soon!