 I know you guys are all like really decided to take a moment and savor and enjoy that incredible, super cool. You want to see something like that. Again, just turn on your TV and it's on. This is the judge. I have to make like a last bet or something. There has to be something to stake here. I mean, how about this? I had this idea the other day. I'm a Patriots fan and it's difficult for me to talk about the Super Bowl game that they're on. It's like a very dark spot in my life. I don't want to tear up a little bit, so I'm not going to talk about it that much. But anyway, so I thought, here's what I'll do. The Patriots play the Giants, the New York football Giants. I know that it's like Eastern New York or whatever. I mean, at this point, given how the build season went, you guys all have got to come together as a state, I think, to support the New York football Giants. So, if you're interested in there being some sort of consequences for me for showing you all these Patriots videos next Monday, send your suggestions to staff at mail.cse421.net. And whatever the best suggestion is for something I should do or something I should wear on a Monday, if the Patriots do in fact lose, if they win, then I'm just going to come in here and we'll spend the whole class watching highlights. They lose. I'm not going to want to talk about it, but I will, you know, I'll do something fun for you guys. So, if you have a suggestion, email staff. It has to cannibal nudity or, you know, affinity or other things, but if you have something that's kind of fun and cute, then it would be suitably embarrassing for me to go ahead and send it. All right, so, today we're going to talk, Monday we're going to talk a little bit about the special powers that the Colonel has and how the Colonel gets to use those special powers and privileges. Oh, I know. So, today we're going to talk about multi-plants. So, today's the first class. A lot of operating systems class start with this kind of historical overview of operating systems, where they show you these pictures of these big machines that were, you know, filled entire rooms and buildings back before you were born. And I decided not to do that for this class, but that doesn't mean that we're not going to cover that. So, I'll dribble it in a little bit and get some pieces. So, today we will talk a little bit about history, about, you know, the love story. I think of it as a love story between geeks and computers that essentially created modern society, right? I didn't think about it. And then we're also going to talk a little bit about preemption, just how the Colonel gets control on most modern systems, and what it means to switch context. So, what do I actually have to do to transition the CPU for money, one, go out of execution, two, no, okay? So, first, again, before I miss this, we have a couple of lessons today. So, almost all of Simon Zero is out. I'm almost going to get the rest out today. The parts that are left will be similar to the GDB scripting sessions, but they're just good. I mean, you've already done the first thing out there. I just want to prove that you did it. So, I'm going to ask you to build another kernel in the scripted for me. And then I'm going to give you a really, really short introduction to Git, and then you're going to do a little bit of the game, right? So, this is a version control system that we're going to be using throughout the semester, but we're going to sort of drift a little bit to Git on you on every assignment. So, this assignment will just be very, very, very preliminary stuff. Yeah? Is it still the same version of the script that I'm supposed to use? Yeah, yeah. So, it's still due on Monday, right? I don't think these parts will take you guys more than half an hour. So, I'd like to get it in on Monday so that we could move on. Okay, so the website now has lots of information about the class, including the recitations, office hours, and I am getting better about getting the slides up on the web faster. Right? So, it should be up, you know. It's usually when I get around to it, but when I'm getting the process done, so it will happen more regularly. And I actually converted a lot of the videos already, and I just need to get them off and do a little bit of what was I packing necessary to do it. Okay? So, there's been a little bit of staff turnover. You know, I'm a tough bastard to work with. So, what happened was that we had to shuffle some people around. So, we lost Taifun, who's going to be, I think, TA 305 now, but we picked up Anu Deepa, who's back there, stand up, wave. I don't think I've actually introduced the TAAs properly. So, let me do that now. It's Anu Deepa and Fung, who's running the camera. And so, these guys are going to be grading their assignments, so they're good people to be nice to. They're also going to be holding office hours. Sanali, who many of you have hopefully already seen are very capable of leading recitations, is now going to lead all the recitations. So, four recitations a week, Sanali is going to be teaching every one of them. So, you know, and I expect that by Friday she's just going to be really nailing it. So, you know, if you're going to recitations, you're going to deal with Sanali. If you turn in assignments, you're going to deal with these guys. So, all of you guys should know these people. And then, okay, so just a reminder, when you contact your course staff, if you use prof at mail.csc41.net, that gets to me and that comes to the right place. So, I get a lot of e-mail, and if you guys just help me out a little bit, it'll help me sort out what you know. I want to read e-mail from you guys, but if it ends up in my inbox, it gets ignored for weeks, potentially months, potentially there's probably some stuff in there from 2010. All right, so, and then lastly, it will be off the hours today from time to 12. Fung's going to hold those, and Anu Deepa's going to hold out. Anu Deepa's going to hold out for hours tonight from 5 to 7. But, you know, go easy on her. She just joined the class a couple days ago, but she should be able to help you with some good beginning stuff, okay? The question is about sort of course logistics. Sorry about the website. That was totally my fault. A lot of people wrote in and said, oh, it's not working, and I was like, it's going to be for me. Okay, so last announcement about the ACM student chapter, another general industry meeting tonight at 6 p.m. All right, so great turnout last night. They're doing a lot of cool stuff this semester, so if you're interested in kind of extracurricular computer science activities, these really guys talk. All right, so let's go back to Monday, right? You guys remember Monday, right? A couple days ago. Seems like all the time. Monday, in fact, I'm truly, we've done that exception, and we've talked about interrupts, okay? So questions on this material, if that's any questions on things we've talked about on Monday. Any questions? So let me just remind you of something. And I know people say this, and it doesn't only matter, but I can say it to them because maybe it will matter to somebody. If you have a question in this class, right? The typical psychology of someone who has a question in a large lecture class is they think, I'm stupid, I'm the only person who's confused. But let me tell you something. There's two possible sources of confusion, right? One is you, and the other is me, okay? And I am much, much more likely to be the source of your confusion. And if I'm the source of your confusion, I can confuse a bunch of other people in the class too, right? And those people would be very, very happy if you raise your hand and ask the question that they are starting with the question. So please speak up. I don't care if we get through all the material every day, I'd rather people understand the material that we do have. So if you have a question, raise your hand, ask it, and I'll talk to you about that. All right? Keep that in mind. Okay, so let's go back. Monday review. Why does the operating system need special criticism? Don't shout out. Everybody think about it for a minute. Right. So I want to multiply some resources, but why do I need special privilege to do that? To get a source of information. And then after I allocate it, what do I need to make sure of? That people don't violate the allocation that I've created. So I'm going to divide the resources and I need to enforce that division, okay? Great. All right, second question. True or false? These interactions require special privileges. Again, quiet. Everybody think about it for a second? Right here. True. Anyone want to say false? Why? Because permission is only needed for one time. Right. So there's actually an existence. Now, this is kind of a tricky question. I would say maybe true or false or it would be the right answer. This is false or. So exo-permanoles, which we'll talk about later, provide a design point indicating that at least it's possible to completely separate these two apprehensions and functions, putting in the resource multiplexing as the only privileged component, or the only privileged portion, and all the abstractions are implemented in essentially unprivileged libraries. Right. Now, when those abstractions like for, for example, need to allocate resources, they do need privilege, right? So in order for for to put in the average space, it does need to ask the privileged part of the operating system to allocate some kind of, implementing these abstractions can usually be done other than the parts that require allocating resources. Okay. Operating modes. So, how does the processor provide the system with these structural permissions? More generally, at startup, what happens? What's that? Ring zero is ready. I'm getting closer to the answer I'm looking for. What is ring zero? Kernel mode, right? Special operating modes. Through a privileged or chrono mode, which allows the chrono to use special instructions and also to address memory instructions. Okay. Interop talent. What happens when an interop occurs? What does the CPU do? First, first. If you guys start calling on answers, not everybody gets to think about it. First set. First step is to recall something. Recall the staff information. So, okay. So actually there's three steps and they don't really have to happen in this order. But one of them is reporting some state about the interop that happened. What's the second one? I'm not going to call this. So what's another thing? So I need to record some state about what happened. What else? Goes to the interop panel. Jump to the interop panel and what's the third important thing? Most. Anybody want to volunteer? Enter. Go to the instructions and that's entering the interop panel. We already have that one. There's a third thing. So I heard it over here. So enter privileged mode, right? This is how the operating system, the CPU transitions into privileged mode. When something that needs the kernel that it needs the kernel to help with, it jumps into privileged mode and starts executing to the kernel. The kernel is what loads the interop. Okay, hardware interrupts. Okay, so hardware interrupts occur when blank. Did I get it? In the back right there. You. Probably. But that's a subset of the answer. Disk read is completed. What's that? Disk read is completed. What is it? Disk. Okay, so that's an example of one. But what is general? Why do I have hardware interrupts? A request for hardware. Yeah, device says hey I need some attention. I need some love. I need some love. Something happened and I want to tell everybody about it. So when our dog finishes his food, he gets really excited and he runs around the house jumping up and down and that's kind of his way of interropping up. He's like hey that's my food, that's something really cool. Because then he gets more food of a different kind of his life. Alright, what are three examples of hardware interrupts? Over here in the monthly part of the room. Recept. Recept. Yeah, okay that might be next going down the line. Another example of a hardware interrupt. Who knew? An echo packet is received. When an echo packet is received. An echo packet is received. Good. When, I don't say DVD before it's empty, right before. Sure. I have different ones, but what else? Yeah. A lot of different examples, things that involve them. Alright, song corner interrupts. Alright, similar. Software interrupts occur when? Dictating. There's a problem? Mm-hmm. An unexpected problem. Okay, you're close. You're close. Save that answer for the next section. Alright. Hardware interrupts, software interrupts occur when? What's that? Seedness. Not quite the signal. Remember, there were two different, we had software interrupts and software something now. We're going to get through the stuff here. Over there. Offer interrupts happen when? Yes. The program needs help. The application needs help. The application needs to be able to do something on its behalf. So examples of software interrupts. We've talked about system calls in this class, right? We've talked about four system calls. Can anyone name three of them? Back here. System calls. Examples of system calls. Fourth, exact. Wait, exit. We've talked about four of them already. There's a bunch more. Those will cause software interrupts. That's how, when you call four, the kernel starts to run. Can you guys turn on the volume? Discrete, request, diswrite, request. They are also in software interrupts. No, those are hardware interrupts. No, request from the... Oh, sorry, sorry. Software to read, yes. So that's another portion of the system call interface. Read, write, open, set or tell. Yes, those will similarly cause software interrupts. Alright. Now, come back to the person who's listening about it here. Software exceptions occur when... There's a problem. There we go. Software's caused some kind of problem or some sort of exceptional condition, right? So examples of exceptions. Page fault. Page fault? That's a good example. Memory overflow. Depends on how it happens. Go ahead and write it here. Five by zero. That's not going to be as big. Five by zero. But let's see, one more. One more? No pointer exception. No pointer exception, right? So that'll actually cause a memory fault. Segmentation. So that's what creates a segmentation? No pointer. Do you mind me? The other one I had was an attempt to use some sort of religious formula. That will also cause an exception, which the kernel will be able to do. Alright. Okay, so last couple things. We talked, we said that the kernel could ignore certain interrupts, particularly device interrupts, by setting a bit mass that essentially indicates that those interrupts will not cause the interrupt server to change the query. So why would I want to do that? We don't have to do that. I know where you're going. It's an important priority. I want to establish priorities for certain interrupts. Certain interrupts may create other interrupts. Okay? Finally, so how does the interrupts protect the interrupt handle with user applications? First of all, what would happen if user applications could override the interrupts? They could just do anything they wanted to. They could control the devices, right? The opportunity is to stay between these buggy user applications and these important devices that I want to operate from. Do you remember how the interrupts protect the interrupt? Sure. This is going to do something. It loads the interrupts and that spotting memory is not sure. In an area of memory that is not accessible to user applications, make sure that they can't overwrite those. Okay. Any other questions about this? You said about interplanetary the three steps. Do they have to be performed in order? No, they're not used to perform that order. In the perspective of the operating system, they all just kind of happen together. If you look in your code base, and I've got to show you a little bit of code today, but not much, but you guys, at least for me, I really get help when I think about this material by looking at code. Hold on. The code in your OS 160-month source tree is a great thing to look at. All there, it's incredibly well-commented. That's one of the nice things about a pedagogical operating system, is that David did a fantastic job of commenting particularly parts that are complex and strange, like the assembly stuff. There are page-long comments explaining exactly what two instructions do. If you read that stuff, I think it'll make more sense. The idea is there is an exception entry point that's loaded. You can actually see where the kernel loads the exception handlers. It's kind of fun. But then the exception handlers install it. There's an entry point, and in that entry point the interrupts are off. The kernel is in privileged mode and basically, that's the code that's executing, that's the code that's been loaded and that's interrupt slot. You mentioned page 4 as one of the software interrupts. Exception. So actually, this is a good question. What is the difference between a software interrupt and a software exception? In terms of from the perspective of software. When is the test work attention-reward? Well, it's not even a demand. It's not intentional. An exception happens when the kernel is entered but the user application didn't expect it to happen. I executed an instruction. I thought I was executing this instruction. And I don't realize that the kernel has actually been trapped into something that's happened. And then in the case of memory address translation, that instruction is restarted and it will complete. So, what was your question? No, I was thinking actually that it's a software interrupt. Right. So it's not a software interrupt because the way the virtual address translation works, this is my favorite part of Operating Systems. It's a beautiful abstraction that's built to allow programs to execute. But the nice thing about virtual memory is that programs don't have to ask to use it. Programs just use a memory address like it's a real address. And behind the scenes, the Operating System is translating those addresses so that they actually map down to hardware physical memory potential. So that's why it's an exception. I just run the instruction from the perspective of an application and again, I don't realize that the kernel was required to load a translation for that. So again, we'll come back to this. If every time you needed to use a memory address you had to request help from the kernel to be terrible. Your programs would be so slow. We'll talk a little bit about why today because it turns out that context switching in and out of the kernel is not free. It's actually fairly expensive. We want to make sure that if you had to do that on every memory access you'd just forget it. We wouldn't have a full memory. It would never work. Yeah, so there are these basically I think that that's true and that's one of the reasons why when they start running they set the interrupt mask so that no other interrupts can block them. So hopefully what will happen is if I create another interrupt I'll exit the interrupt services chain I'll turn the interrupts back on over again. So normally nested interrupts get really, really weak and you normally try to avoid that from happening. What that means is that in our panelists' time to be very, very short compact is to just do a few things. If the disk is signal that it's right I might not actually read all the data. I might just tell the kernel, hey there's some data to be read and then the next time the kernel gets around all right, any other questions about this? Good, good questions today. All right, so let's talk about CPU limitations. So again one of the points of the abstractions that the office system creates to manage the CPU are that there are problems, limitations I should have called these problems, but really limitations. So what are some of the limitations of the CPU? So historically in old machines most machines were a unit processor particularly personal machines were a unit processor machines. Why? So you might have thought why were these machines unit processor machines? Anybody want to venture or go out? Oh okay, so that's a model of computing but you might have been able to say hey my machine would go faster if I had more than one processor. Cost, right? CPUs are expensive. They're the most complex portion of your system. So you're not going to throw, I mean you might have had 10 Gs 10 years ago the machine with like 16 processors in it. This isn't even multi-core. So yeah, coordination between external cores is much more external processors is much more difficult than internally cores. Right, right it is and I'm not going to talk about that, it's more of a hardware thing but you're right. So multi-core dealing with multi processors is more complicated than dealing with multi cores because multi processors share less state and communication between them. So now we have most of your machines, even laptops even phones and tablets now are multi-core machines. If you take it in a hardware plus it's why, right? Why did we, you know, for so long this one core model, we're fine. So why would we abandon it and not push that one more core machine? Speed limitation. So more speed but for years I had one processor and it's got faster, faster, faster, faster. So I hit it sealed and what happened, and again I don't want to get into the harder details because I'll get them wrong probably but at some point our quest for density ran up against some fundamental limitations, right? One of those power and other is thermal management. So you guys never had those old, anyone have a Pentium 4 system back in the day? Anybody besides me? Remember the heat sink on that thing? It was like a football, right? I'm serious. You look in your system now with these core dual machines much, much smaller profiles. So those Pentium 4s, you could fry eggs I think people actually did that. You could probably go find videos showing people cooking things on their keyboard just using the heat part. So at some point you got smaller and smaller and denser and then we blew up and we decided to go out rather than keep going small. Alright so, but generally multi-cores hasn't solved the scheduling problem that we have. What? I mean, I have an 8-core machine on my desk. Fantastic machine, I love it. It never feels slow. But, in general there are still fewer what than what? Processing. Can you get a coin? Of course it's in processing, right? I still got, you know, in a given day I'll actually... In a given day I've got, you know, 18 Firefox windows open I've got a couple virtual machines and I've got six terminals. So in general there's still a lot more tasks than there are cores even on a 3D. Alright, so the other thing in CPU limitation this isn't so much a limitation it's just a feature of the CPU it's important. This is actually really critical to what we're going to talk about today. What is the relationship between the CPU and other parts of the CPU and too many answers? It's too minimal, right? So what is the CPU much much more what than other parts of the system? Fast! It's smarter too, but whatever there's a lot we've done. We're supposed to do one thing quickly, right? So the CPU is so fast that accessing hardware devices creates these long periods of time where if I'm not clever my CPU every time you did a disagree the process the entire machine waited for that and the CPU is sitting there for longer than the time you would want. And it turns out that these are addressed in different ways, right? So memory is typically so typically loads and stores will cause I shouldn't quote numbers but a small number of CPU cycles stalled. Maybe 20 or 50 CPU instructions go by waiting for that memory read to complete, right? This is usually something that's addressed in hardware, right? So if any of you guys have studied hardware and looked at out of order execution and those kinds of systems, that's how this is done, right? By the CPU playing games internally, right? To reorder instructions and hide those links, right? Larger latencies like latencies to disk which can be incredibly long from the scale of the CPU are handled by the operator the next week. But one of the more interesting sources of latency on the system is you, right? I mean, so I was when I was looking at this, I decided to look at research that was done on human perceptual limitations. So there's a paper about 10 years ago that explores different you know, different ways of thinking about perceptual limitations in terms of latency, right? What kind of latency are humans sensitive to? So according to this, there's this kind of 15 millisecond rule of thumb that they really couldn't figure out how to justify it. That's one number, right? So frame rates for video, right? It turns out most, what I found out is most cartoons. So the point at which your brain will start to process moving images as, you know, flashing images as actual motion is I think something like 15 frames per second. And if you ever watch Saturday morning cartoons that's usually the speed at which those go. At least maybe the old ones. They were probably drawn by hand and so there was no, you know, you just wanted to get over the bar where it would start to look like motion rather than a bunch of frames would be flat, right? But for video to look smooth what are most movies done that? 30, right? 30 frames per second. I think it's actually like 29.97. There's probably some fraction that makes that sense. So that's the point at which your brain starts to look smooth and then this paper pointed out that back in the days of the old telephone system there was a real attention to keeping latency for telephone communication below 100 milliseconds. If any of you guys have ever used some sort of internet telephony product or maybe you've made a phone call overseas using some sort of dodgy phone card that creates these pretty long latencies, you'll know that at some point if there's enough of a delay in human conversation the conversational pattern starts to break down. So it becomes hard to talk to somebody because you say something and you're not sure if they're answering or not because they're still listening to you, so you know what I mean. But let's express these delays in terms of a 1 gigahertz processor. How many cycles? 15 milliseconds. Who could do this math quickly? How many cycles does that work? 15 milliseconds on a 1 gigahertz process. This is not hard math. But I know, there are big numbers. 15 milliseconds. Class. This is not the number of instructions. A lot of instructions are the most ones. But anyway, the point is that that's a huge number. So in the time that you think nothing has happened on your computer, actually a lot can happen. A lot can happen. And that's how we create the illusion of the currency of your computer. So keep this in mind when you come up with it. So let's start a little fun history lesson. Okay. So back, again, you know, long ago in the land before time, dinosaurs were on the earth. I mean, I look like that sometimes. I know. In PC, there's only like 25 years going on. 85 was the first PC. Yeah, so we'll get to PC, right? That's where this all starts to break down. Right? So the first computers, and this just in case, because it blends in really nicely doesn't, this terminal is overlaid here. That's not farther. It was blended in to me. It's actually real. Wow, we did all this work so it could draw a terminal like that. So anyway, so these guys are a program in one of these original ancient computers, a Harvard Mark one. And actually there's pieces of this that are still on campus. And back then, they did an odd thing at a time, which we wanted. Back then, I mean, computers were like really powerful calculators, right? I mean, they essentially, they're usually given some sort of computational path that was hard to do. Like, for example, World War II, when did a lot of computers spend a lot of time doing simplistic trajectories for bombs and other things, right? Calculating these, what now would you do in a fraction of the site like, oh wow, the answer in five days is so fast. So it's really astonishing, and I think it's something that's worth kind of meditating on a little bit, how fast computers have gotten and how cheap they've gotten. Because it really is that I think the driving force of modern society explains most of what we're building with economics today. It's just, and also the relationship between humans and computers, right? So it used to be, one of the ways that people explain this is that computers were really, really, really expensive, right? So these computers were super expensive. They were probably built by hand, they were made one at a time, just years and years to get them up and running. If humans, in comparison, were cheap, right? So ancient days of computers, humans cheap, computers fast, right? Now it's completely reversed, right? Computers are dirt cheap, and it's the one thing that's not scaling and computing, what is the one thing that has never scaled when it comes to computing and particularly to human-computer interaction? So computers have gotten faster and have gotten larger memory, they can do more at one time, they can do more faster, they can store more data, what can they not do? No, no, no, I always improved. I kept up, but I always improved, right? Yeah. Programming? I think programming has probably improved slower than I would want, right? I think the limitation between you and your computer now is that they don't get better. I think users have gotten better. Do you see a computer? Intelligence, artificial intelligence? AI has gotten better, do you see Watson? Oh, go watch Watson play jumpers. I mean, that's pretty awesome. So it's something more fundamental. Human interaction with computer? What particularly about it? Response. So the response time to also the amount of time in your day, right? The amount of time in your day is not scaling, right? And one of the things, you know, one of the things when we talk about modern computing, and there are people like me who actually, despite the fact that I love computers and I'm frustrated about how much time I have to spend being with them, right? And I would like that time to do other things. So my time is not scaling, right? Going forward I think computing is a field speaking very philosophically is figuring out how to manage people's time. If you guys could get done, the same thing you do with your computer now, half the time, you know, you have more time to, you know, watch the Patriots in the Super Bowl or, you know, go for a cup of coffee with friends. So learning how to manage user time is really important. Anyway, sorry. Okay, so at some point, unfortunately, so this is like the garden for the geese. And I use that term with a huge amount of respect and a huge amount of love. I consider myself a geek. I think you can use that term because something kind of describes those guys. So this is the garden, right? The geeks had their computers and pretty much they had the computers all by themselves. And at some point, people wanted to use these computers. And that was frustrating for the geeks because that's my toy. I don't want you to use it. Imagine if your computer under your desk was the only computer in the world, right? Or the only computer in Buffalo. And there were all these people that were like, hey man, can I use your computer and want to play Angry Birds? Like, I'm doing my really important, you know, OSMO 61 homework, and they're like, I don't care, I want to play Angry Birds. Anyway, so, and essentially what you did in the early days of the computer was not that recent anymore, but the woman who taught me this class, when she was programming her assignments at Harvard, she did things on punch cards. And how did punch cards work? You programmed a stack of cards, you took them somewhere, and someone said, okay, and they put them in a queue, and then those cards got fed into the computer, and maybe like six hours later, if you were lucky, you would get a card back and it would say air. And then three, right? And you're like, oh, okay, and that's how things work, right? So people queued up to some, right? But at some point, people wanted to actually interact with the computer, right? People wanted their own chance to get in front of the computer, right? What is this similar to today? Actually, our department actually still has remnants of this, right? So has anyone used the Sunray Workstation? Dump Turtles. Dump Turtles. This is kind of the thin climb. I don't know what these are, I just grabbed this picture off the internet. These look like they might be smart enough to actually be real computers. But for a while, there was just this idea of you had a terminal, and all those terminals were essentially connected to the same computer, right? There was no computer here, there were just wires that led from every one of these terminals back to some mainframe and sitting there and oh man, there's 50 people logged on. From what I was told, there was a perceptible delay with these systems. If you were the only user, it was great, right? There were 100 people logged on? Oh boy. You're going to be used to long delays for your keystrokes, right? So, but at this point, this creates this problem, right? Which here, here I have a one-program system, here I have a one-program and a time system. And now I've got to figure out, you know, how do I support, I love how these show up like a second late. It's a little surprise party that you're going to do. So, now what are we going to do? So it turned out that, you know, the geeks build operating systems to solve this problem, right? And one of the, actually we'll get to, one of the first, that you raise in your hand, or is it holding your bottle off? I'm not going to be excited. You can come from a long line, it's a long line of questions. No, it's in the machine. So essentially, what we'll see, and we'll come back to this very important point when we talk about scheduling, is that all these things that your computer does now, I mean, they all, it's like computer revolution, right? They all trace back to these early systems. A lot of them do, a lot of the concepts, and a lot of the key assets, come out of, and again, it's tough, it's a computer scientist, and I think it's something that you have to make some mental effort to do to remember and think about what these early systems were like, right? And think about, because now systems are so fast that it's almost like you can't make any mistakes, right? But back when these computers were really slow, you know, the states were routine, right? So, if I've got one big computer and I only have one job, right? I mean, all I really need to do is figure out how to schedule the humans, right? I mean, this is a human scheduling problem. So back in the day, it was like, you know, you would show up and you'd go into the room and there's a computer and it was yours to use, you know? You just had to turn off the lights and clean up things when you got, right? So this is not a computer scheduling problem, it's just a human schedule, right? So at some point, what started to happen is that there was this group of, you know, computer priests, maybe we'll call them, they had to take over the operation of these computers. And what they did is, again, they did back processing. So you would bring a program to them to run and they would run it for you and at some point they would return the result, right? And in a batch scheduling, essentially, every job just runs until it finishes, right? And there's actually still systems that are built like this today and there's still good reasons sometimes to build things like this today, right? But, you know, again, I ran Firefox, so Firefox was done. Okay, I'm using applications that are interactive, so these aren't great examples, right? The point is that things ran until they finished, the machine stopped, I reloaded something else, not a random list. So this was a very easy model. Now, the question here, of course, is that, you know, going back to my idea of operances as multiplexing and providing abstractions, is there any multiplexing going on? No. So that component of operances and to some degree, operating systems of these kind of machines are really just libraries of useful functionality that programs might want to use, right? You might want to say, hey, you know, here's a library that makes programming this computer easier. I don't know who this is, but... All right, so what are the problems with batch scheduling, right? So simple batch scheduling, every program has complete access to the machine until it finishes actually, right? Now, go back to my problems or limitations with the CPU. What problem does this create? Way faster than the other components. Could be, I don't even know what. Could be, I don't even know what, right? Why? Because some of the software are running the only part of the CPU. For example, to take... access memory takes 40 cycles. Right, all right. And access disks, even on these slow systems, everything was slow, right? So an access disk might take thousands of cycles. But because there's no other program that's using the machine, during those thousands of cycles, nothing happens, right? You just sit there waiting for the disk to finish whatever it was. So, to some degree, multi-programming emerged out of a desire to hide these latencies, right? To exploit these latencies, to say, hey, as long as the CPU is not doing anything, right? I might as well use it to run some other program, right? I might as well use it temporarily to run some other program. So, your program will only run as fast as the I-O that it does, right? Whereas, if I'm clever and I intervene the I-O with a CPU access of two programs, I might be able to actually, depending on their access patterns, I could complete two programs at a time that it takes me to run each one of them separately, right? Because if one is using the disk while the other is using the CPU and I just keep handing back and forward, then they will both complete at the same time, and it's a time it would have taken either one of them to run by itself. So, the solution, again, is to context-switch the machine, right? So, context-switching is the idea of stopping one program from running, saving its date, and starting another one. So, the signal that these are not running in completion, and I will fast-step with the systems they would run until they blocked, right? So, they would run until they did something where they didn't need the CPU anymore. Like, for example, you know, read something from this, or try to grab some input from the keyboard, or, you know, use the Internet, right? It's definitely an Internet back-back. So, the idea is that these, you know, this is one of the first, you know, this is the birth of context, right? This is why I was done earlier, and this is simply to hide the latency, so to speak. So, now that I'm doing this, I'm multi-busting, right? So, now I need an operating system, right? Now, I might need an operating system in the form we know today, because it's possible that, you know, that these applications can cooperate to do this. But, one of the births of operating system software was simply to hide these latency. That's important to remember. All right, so, now, what's this, so the other, the next big thing, in my opinion, that happens to machines is that they become interactive, okay? These old machines, again, despite the fact that I have interactive applications up here, which is a bug in the slide, right? These old machines are non-interactive. You show up, I mean, you interact with a person, right? The person who's managing the machine. That's when you get your touch cards doing and then they hand them back, right? So, maybe they'll look down at your shoes. But anyway, so, so, now, people actually want to interact with these machines, right? And this interactivity creates the next set of problems, right? Because interactivity means that either if I have multiple users using the same machine, right? I need to operate the machine so that the machine seems responsive to everybody. If I have one user using the machine, that's a problem because they may want to run multiple things at the same time. And so, now I need to create this illusion of incorrect, right? I need to create the illusion that multiple things are running at the same time. So, how do I do this? Who has an idea about how, how do I implement this, this illusion? Right, so, go back to those human perceptual limits, right? People won't notice, right? So, the operating system essentially is like, no one, people aren't going to notice if I'm just, no, grab the CPU from Firefox for a minute and let this other thing, right? So, if you zoom in here, this is designed to show that the occurrence is that, and again, on my machine or your machine, this thing is way bigger, right? There's probably like 40 different applications running quote unquote at once, right? Well, what's actually happening? So, I'm going to zoom in here, right? Zoom in, and then I get bored of doing the slide, so this is kind of the finish, right? So, this is actually what's happening, right? Zoom out, this is what it looks like to you as the user. If you zoom in, this is what it looks like to the machine, right? Run Firefox for a bit of time, stop, run the triple, stop, run Firefox, stop. If I do this fast enough, I think I would get the time axis here, the human won't notice. The user won't. And both applications are the same, responsive and like they're operating. The question is about this. I think this is pretty good. But this will create some order on those users. Yes, yes, yes. I'm coming to that. So, how do I do this, right? First of all, how does it always get controlled? We talked about this last time, right? You've got hardware interrupts, and software exceptions, right? These are how the operating system gets controlled. The question is, what if a long period of time goes by where the disk doesn't need any attention, there's nothing that shows up on the network card, the program doesn't make a system call and it doesn't divide by zero? How does the operating system get controlled? How do I implement it? Timer. Timer, right. You guys know this, that was good. Timer interrupts. So, every modern system has a timer. And that timer generates interrupts at a fixed rate. And those interrupts are the basis for a program. So, the timer is always firing. And the timer ensures that, you know, never will, you know, one millisecond or 100 microseconds or whatever it is, go by without the operating system getting a chance to run. And every time the timer interrupts, you know, the rest of the interrupt handling is unchanged, right? Just like a trap in the U.S. where I look around and see what needs to be done. And one of the things I might do is I might stop the current thread, save its context, and start something else. But this is the mechanism how, this is what, you know, this is what allows me to create a schedule. I have to have this time. So, the idea here is that now I have timers, right? And from the perspective of a thread, this creates this issue interesting to a thread, right? To a thread, to a process, it looks like I'm just executing a stream of instructions, right? But what could actually happen at any time? At any time, I might be stopped and another thread might run, and I might start running again. And from what the operating system, the goal of context switching is to make this look completely seamless, right? I don't want the thread to notice, right? When the thread starts running again, it should never even know that it was stopped, right? Now, it probably can know, right? What's one way that it can find that? It could look at the time, right? It could grab the time from... So, this is not to say that it really looks like, you know, that there's no way for a thread to know that it stopped. But really the idea is that when it starts running on the CPU, the CPU should essentially be exactly as it was. If it's not, then weird things could happen, right? Because it's not expecting that something's going to change in between two random variables. So what state do we need to save in order to implement this, right? Thread's running along, it's using the CPU, it's, you know, doing stuff with registers, it's, you know, writing stuff to memory, so what do I need to save? One more time. What do I need to save? The addresses. The addresses, right? So there's something about memory I need to save. Okay, but what's more fundamental to the CPU? Program counter is an example of what? A register, right? So that's what CPUs are, right? CPUs execute instructions and they change the state of register, right? So the register state is constantly changing. And if I'm going to stop a phone and restart it, I need to make sure primarily that I save the register, right? So every register with the exception of a couple on the next. There are a couple kernel-only registers that applications are not supposed to make any assumptions about what happens to those. And I'm not even sure that several of them are used, right? There are a couple of kernel-only registers, right? That are not guaranteed to be saved across the house, but everything else, right? So the first thing that what I do when I trap into the kernel is I save the thread state of the thread that was running. I'm going to show you that code in a second, right? Why do I have to do that first? I'm going to interrupt it while you're there. I'm going to go back. Okay, that's one reason. I do want to go back. But why do I have to do it first? Hey, guess. So the kernel is going to start running. What does that mean? The state of the registers is going to change, right? I'm going to start running my kernel code, right? My kernel code is going to use the registers that the application was just using. So if I don't save them right away, if I say I'll save them in a few minutes, right? By the time I get around to saving them, they're my register state, not the front one. The first thing I have to do is save the registers. Yeah? What is the saving those registers that code? I'll show you. All right. So, okay. I said at the beginning of class that I wasn't going to do this that much, but I can't call myself because I think this is cool. And I think I'm trying to entice you guys into your own code, right? So this file is in your source group, right? exception nips.s That's an assembly. Everything they label.s is an assembly file, right? This is the common exception handling code that is jumped to by both types of exceptions on nips. You can actually go and see how this is of money, but I've just cut out a little piece, right? And again, David has just a fantastic job of explaining what's happened and what the state of the world is, right? So, when I get this code, and arcs are off, right? And I'm in privilege mode, so the processor did this for us, right? The processor has loaded some values into or maybe we didn't, actually. I think K0 and K1 are done in the very, very top of the exception handling code. So those are kernel registers that the application is not supposed to make any assumptions, though. This code has used those, right? Yeah, well, it's not allowed to make assumptions about those registers. We're really even using them, right? So what does this code do, right? Can anyone read the code comment? Right? So it allocates space on the stack. And then it starts storing instructions, so this goes on for a while. If you go look at this code, there's a block of code about that big, right? Where address by address, register by register, I'm pushing all of the registers that were in use by the process onto my stack, okay? This is how I see it. If you look at the exception return code, what do you think happens? You can just call it my stack. Exact opposite, right? I pop them off my stack, right? So this instruction is swap word, which takes an address, which is, that's a pp9 as a register and then this is an offset from the stack point, right? So this stores this at 1.36 on the stack, right? And then 1.32, 1.28, this is the instruction for bytes wide. So, and then this is, so this is putting this on your stack. Once it gets to the C code, what you see is what's called a trap frame, right? So the trap frame is a CD data structure that holds and again, this goes on for longer, right? But these are the saved registers that the exception handling code put there for us, right? So by the time you get to C code, you actually get a point into one of these structures and you can access that structure and for some of the code you're writing in assignment 2, you will have to make some selective changes to the trap frame, right? Because system calls, the semantics of system calls is that they return their arguments through register. So you get a system call and it returns the process expects that some of the values that are required by the system call are passed through register. So you actually put them on the trap frame and then the exception return code will do the work of making sure that they're in the registers when the thread starts. Any questions about this code? When does the return happen? Like, for example, first you said that the kernel will save the mode, right? So, like, can you give an example where it will return or pop the whole thing? So if you look here so what actually happens is this, I believe, this code does this work in assembly, right? And then it calls the C function. It jumps into a C function. That function executes. When that function returns it continues running. So the parallel code to this is just below this in this file. So you can go look at it, right? And essentially, again, it reloads all the registers and then there's a special MIPS instruction called return from exception. And jumps, you know, jumps back into the user code, right? And again, this is all here, right? So you guys want to see how this works. If you're confused about something that we've talked about in class, everything that we've talked about is all here, right? So sometimes, and again, it is something that code can be a little daunting, but it is really well covered. If you'll look at it, suddenly code another operating system, you would never have, probably the longest time it might be that this aren't expected to know this time. All right, so... Let's see, do I have time for this? No, I don't. Okay, we'll do this next time. And next time, so next time, we'll finish up the last two slides of this today. We're going to talk about state, state transitions, a little bit about threading libraries and how they work. All right, let's follow the next slide. We'll probably go a little slower and maybe do a lot more. I'll see you later.