WEBVTT 00:00:01.090 --> 00:00:06.300 In order for multiple processes to be able to run on the same computer, using a shared 00:00:06.300 --> 00:00:11.350 address space, we need to have an operating system that controls which process gets to 00:00:11.350 --> 00:00:16.350 run at any given point in time and ensures that the state that is currently loaded into 00:00:16.350 --> 00:00:20.190 the system is the state of the current process. 00:00:20.190 --> 00:00:24.660 Through the following example we will take a closer look at how the operating system 00:00:24.660 --> 00:00:26.540 for the beta works. 00:00:26.540 --> 00:00:31.760 We begin by examining the code responsible for maintaining the current processor state 00:00:31.760 --> 00:00:36.470 as well as scheduling which process should run at any given point in time. 00:00:36.470 --> 00:00:42.410 The operating system uses a structure called MState to keep track of the value of the 32 00:00:42.410 --> 00:00:45.390 registers for each of the running processes. 00:00:45.390 --> 00:00:50.860 The UserMState variable holds the state of the currently running process. 00:00:50.860 --> 00:00:56.240 The ProcTbl or process table, holds all the necessary state for each of the processes 00:00:56.240 --> 00:00:58.470 that runs on the machine. 00:00:58.470 --> 00:01:05.899 For each process, it stores the value of all of its registers in the State variable. 00:01:05.899 --> 00:01:08.729 Additional state may be stored per process. 00:01:08.729 --> 00:01:14.130 Examples of some additional state that would go in a process table are a page map per process 00:01:14.130 --> 00:01:16.840 if we want to use virtual memory. 00:01:16.840 --> 00:01:22.219 Another example, is a keyboard identifier, that associates hardware with a particular 00:01:22.219 --> 00:01:23.389 process. 00:01:23.389 --> 00:01:29.158 The Cur, or current variable, holds the index of the currently running process. 00:01:29.158 --> 00:01:34.479 When we want to switch control from one process to another, we call the Scheduler. 00:01:34.479 --> 00:01:39.289 The Scheduler first stores the state of the currently running process into the process 00:01:39.289 --> 00:01:40.419 table. 00:01:40.419 --> 00:01:44.848 Next, it increments the current process by 1. 00:01:44.848 --> 00:01:50.869 If the current process was process N – 1, then it goes back to process 0. 00:01:50.869 --> 00:01:56.929 Finally, it reloads the user variable with the state for the new current process. 00:01:56.929 --> 00:02:02.319 In order to be able to run a diagnostic program on one process that samples the values in 00:02:02.319 --> 00:02:09.810 the PC of another process, a supervisor call named SamplePC is provided for you. 00:02:09.810 --> 00:02:15.930 The C portion of the SVC handler is provided for you here. 00:02:15.930 --> 00:02:22.860 It is incomplete, so our first goal is to determine what should replace the ???. 00:02:22.860 --> 00:02:30.510 We are told that the way SamplePC SVC works is that it takes a process number p in R0, 00:02:30.510 --> 00:02:36.340 and returns in R1 the value currently in the program counter of process p. 00:02:36.340 --> 00:02:42.250 The handler shown here reads register 0 from the UserMState data structure and stores the 00:02:42.250 --> 00:02:45.180 value into variable p. 00:02:45.180 --> 00:02:48.530 This is the number of the process that is to be monitored. 00:02:48.530 --> 00:02:54.079 In order to determine the value of the PC of process p, one can look up the value of 00:02:54.079 --> 00:03:00.150 the XP register that was saved for process p the last time process p was run. 00:03:00.150 --> 00:03:04.349 The XP register holds the value of the next PC address. 00:03:04.349 --> 00:03:12.069 So reading the XP register from ProcTbl[p] tells us the next value of the pc for process 00:03:12.069 --> 00:03:13.420 p. 00:03:13.420 --> 00:03:18.829 The pc value is to be returned in register R1 of the current program. 00:03:18.829 --> 00:03:27.000 This means that the missing code is UserMState.Regs[1] and that should be assigned the value of pc. 00:03:27.000 --> 00:03:32.879 Suppose you have a compute-bound process consisting of a single 10,000 instruction loop. 00:03:32.879 --> 00:03:39.129 You use the SamplePC supervisor call to sample the PC while running this loop. 00:03:39.129 --> 00:03:43.889 You notice many repeated values in the results of the SamplePC code. 00:03:43.889 --> 00:03:49.879 You realize that the reason this is happening is because every time your profiling process 00:03:49.879 --> 00:03:56.140 gets scheduled to run, it makes many SamplePC calls but the other processes aren't running 00:03:56.140 --> 00:04:00.700 so you are getting the same sampled PC multiple times. 00:04:00.700 --> 00:04:03.520 How can the repeated samples be avoided? 00:04:03.520 --> 00:04:09.409 To avoid repeated samples, we add a call to Scheduler() in our SamplePC handler. 00:04:09.409 --> 00:04:14.879 This ensures that every time that the profiler process is scheduled, it only samples a single 00:04:14.879 --> 00:04:18.899 PC value and then let's another process run. 00:04:18.899 --> 00:04:23.790 Suppose that you continue using the original version of your SamplePC handler, which does 00:04:23.790 --> 00:04:30.000 not call Scheduler, and you use it to test this code which repeatedly calls the GetKey() 00:04:30.000 --> 00:04:36.130 supervisor call to read a character from the keyboard, and then calls the WrCh() supervisor 00:04:36.130 --> 00:04:40.520 call to write the character that was just read. 00:04:40.520 --> 00:04:47.139 We want to answer the question of which PC value will be the one reported the most often. 00:04:47.139 --> 00:04:53.740 Address 0x100 which is the address of the GetKey() call is reported the most often because 00:04:53.740 --> 00:04:59.460 most of the time when GetKey() is called, there is no key stroke waiting to be processed. 00:04:59.460 --> 00:05:03.870 This means that the GetKey() call will get processed over and over again until there 00:05:03.870 --> 00:05:06.020 is finally a key to process. 00:05:06.020 --> 00:05:12.520 The result of this is that the PC value that shows up the most often is 0x100. 00:05:12.520 --> 00:05:17.000 The last question we want to consider is what behavior is observed when the profiler which 00:05:17.000 --> 00:05:21.509 is running in process 0 profiles process 0 itself. 00:05:21.509 --> 00:05:27.740 Assume that the profiler code consists primarily of one big loop which has a single call to 00:05:27.740 --> 00:05:32.949 the SamplePC supervisor call at instruction 0x1000. 00:05:32.949 --> 00:05:38.300 The rest of the loop processes the data that was collected by the SamplePC call. 00:05:38.300 --> 00:05:44.470 The question we want to answer is what is observed in the SamplePC results. 00:05:44.470 --> 00:05:48.229 We are given 4 choices to select from. 00:05:48.229 --> 00:05:53.630 The first choice to consider is whether or not all the sampled PC values point to the 00:05:53.630 --> 00:05:55.820 kernel OS code. 00:05:55.820 --> 00:06:00.139 This choice is false because if it were true it would mean that you somehow managed to 00:06:00.139 --> 00:06:05.830 interrupt kernel code which is not allowed by the beta. 00:06:05.830 --> 00:06:12.650 The next choice to consider is whether the sampled PC is always 0x1004. 00:06:12.650 --> 00:06:17.659 This seems like it might be a correct choice because the SamplePC supervisor call is at 00:06:17.659 --> 00:06:28.199 address 0x1000, so storing PC + 4 would result in 0x1004 being stored into the UserMState.Regs[XP]. 00:06:28.199 --> 00:06:35.129 However, if you look closely at the SamplePC handler you see that the XP register is read 00:06:35.129 --> 00:06:36.280 from the ProcTbl. 00:06:36.280 --> 00:06:42.819 But the UserMState regs are only written to ProcTbl when Scheduler() is called, so reading 00:06:42.819 --> 00:06:50.620 the value from ProcTbl would provide the last value of the PC when process 0 was last interrupted. 00:06:50.620 --> 00:06:56.620 To get the correct value, you would need to read UserMState.Regs[XP] instead. 00:06:56.620 --> 00:07:02.610 The third choice is that the SamplePC call never returns. 00:07:02.610 --> 00:07:05.919 There is no reason for this to be true. 00:07:05.919 --> 00:07:10.039 Finally, the last choice is "None of the above". 00:07:10.039 --> 00:07:14.360 Since none of the other choices were correct, this is the correct answer.