Lecture 1 Notes

CS 111 Fall 2005

Class Assignments & Grading

1. 4 Programming Labs (with up to 2 partners per group): extra-credit options available. (1/3 of overall grade)
2. Mid-term and Final (open book, open notes, closed computer). (mid-term and final combined cover 1/3 of overall grade)
3. Mini-labs (3-4 assignments). One-page reports (2-3 assignments) and scribe notes. (The mini-labs, reports, and scribe notes combined to cover the last 1/3 of the overall grade)
4. Class participation is important and will be considered within the final grade.

Late Policy:

3 free late days are given to each student to be used as necessary. The 3 late days can be combined to extend the due date of a single assignment by 3 days. Or they can be used separately (i.e. extend the due date of 3 different assignments by 1 day). Late days are used as a unit: if you turn in an assignment one hour late, that will count as a whole late day. Otherwise any late assignment will be penalized a letter grade per day, after the due date. NO EXCEPTIONS.

Assignment Submission:

If any collaboration was made in designing a lab or project make sure to include proper recognition when turning in the assignment.

Rules:

1. INTERRUPT THE PROFESSOR! If your confused or have a question, don’t be afraid to interrupt the professor to ask, he wants you to!
2. Please include your name before you ask a question.



CS 111 Course Goals

The primary goal of this course is to help the student understand the aspects of low-level software design. How would a programmer (you!) use the operating system to allow specific control of system resources (namely hardware)? When we say low-level we’re talking about programming at the C and assembly level, not a very high level language (i.e. visual basic). Within this course you will understand the fundamentals of I/O operations, processor and memory interactions, and how your program will fit as a whole in the computer. Finally, Taking this course will give you a greater appreciation of how important details are in software development.



Operating System Goals

When designing a operating system there are four main topics the designers have to keep in mind. These are: Performance, Robustness, Efficiency, and Functionality.

Performance
When we talk about performance we are describing such things as: How fast can the computer access a hard-disk to read information? If one system can read a block from a particular disk 4 times faster than another one, then we can rightly say the system that reads faster has better performance.
Robustness
When we discuss robustness we are asking: Is the system safe from attack and from errors in its parts? An example being: if a computer's hard-disk were to suddenly die would the computer be able to keep running? If so, the computer system is awfully robust!
Efficiency
When we discuss efficiency we are asking: Does the system have a lot of overhead? Are system resources being minimally used? Are we spending the least amount of energy to get the information we need (most bang for our buck)? For example, we could make a system that has 4 disks running in parallel, each disk containing the exact same information. We could often read data from disk faster on this system, since we could read different parts of the file from different disks, and thus read from all disks simultaneously. Even though this method would give us good performance (remember disk speed?) it would be very inefficient. Think about it, we have to spend 4 times the amount of disk space to get the same information!
Functionality
When discussing functionality we ask: Can the system support many different kinds of applications? For example, can it be used to play a game like Doom one day, and then used for your taxes the next day? A highly functional computer will allow you to use and install a wealth of applications that can be applied to many different domains. Functionality involves compatibility and a system with low functionality would probably only let you run software specifically catered for that system (remind you of anything?)

When designers incorporate these four goals into there system they must make trade-offs, as we have seen with performance vs. efficiency. A middle ground must be met where all 4 goals work together to give the best overall system for the user.



Interfaces and abstractions

This subject concerns how the operating system lets the programmer interact, indirectly, with the hardware. Consider a disk: When the system wants to store a set of information on the hard-disk it writes a series of 0’s and 1’s magnetically onto a plate of metal. However a simple windows users sees this as “saving a file to disk”. Thus the operating system has provided an interface to allow the user to use the hardware and it has also abstracted the idea of saving a set of binary code with the idea of “files.” Thus the operating system will be providing a simulation of the hardware for the programmers use. A list of common abstractions are: Files, network port, thread, process, window, stream, memory, CPU. All of these abstractions combine to make up the virtual machine which is a simulation of the computers hardware acting. This course will be based on how an operating system designs these abstract ideas for the computer hardware, and how the operating systems interface is used to control the hardware by the programmer. We will not be discussing Windows vs. MAC OS X.



What is an operating system?

An operating system is used to co-ordinate the access programs get to hardware resources on the computer. Without an operating system the computer would only be allowed to perform one task at a time. It would only be allowed to run program by program sequentially. The operating system is what allows true multi-tasking for a computer. You can think of the operating system as the computers boss. It tells the programs what resources they can and can’t use. The operating system makes sure everything’s working correctly and that the computers running smoothly. Thus it co-ordinates the use of the computers hardware to allow many programs to be ran simultaneously. An example would be the operating system allocates specific areas of memory for each program so that different processes don’t write or read from the same memory location causing errors. And a good operating system will make protection boundaries to make sure this never occurs. (Mac OS 9 and before, for example, didn't isolate programs' memory spaces -- different processes could write and read on each other's memory!)

The operating system isolates applications, protecting the computer hardware from misbehaving applications and protecting applications from each other. For example, the MC6800 processor had an instruction that caused the processor to toggle some of its bus lines as quickly as possible. On some configurations, the lines could eventually burn up! This kind of instruction was given its own jokey name: HCF, for Halt and Catch Fire. (Citation: the jargon file by Eric Raymond et al.) The operating system must make sure that user level processes can't execute this kind of instruction. Even when hardware won't explode, the operating system tries to make sure that applications don't misuse it -- that they fairly share the CPU and disk, for example. Applications can't access hardware directly; they access the operating system instead, which mediates hardware access.

The operating system has a lot of power and privilege. So why not build everything into the OS? (It's fun to program when you have a lot of power and privilege!) So why not build an OS that comes with a whole bunch of applications, like a Spanish-English translator, built in to the privileged portion (the kernel)? This would be a mistake and here’s why: An OS should be as small and simple as possible. We want the OS to handle the computers hardware based on the 4 previous goals stated above. Aside from that the user should decide what applications go and don’t go on the computer. Maybe you wouldn’t like the Spanish-English translator that came with the OS? What if it was too complicated? Or maybe not complicated enough? Either way the OS wants to give the user the power to handle what the computers hardware will be used for!



Mechanism, Not Policy

The OS is based on Mechanism, not policy. When we talk about mechanism we mean a neutral means of accomplishing a task. The minimal way to accomplish a task, safely. Such as reading bytes from the hard-disk. Policy in the OS would not be right because it would decide how a function should work. The OS provides a mechanism, not policy so that a program can read and write from memory as it needs, while allowing the program to use the computer safely with others.



Diagram

The following is a diagram that describes how a computer could possibly handle a mouse click from a user. We want the mouse click to signal a program to be ran from hard-disk that prints “hello world” onto the screen.





Polling vs. Interrupt

Now one possible way we could handle the mouse click from the user is we can have hardware events that write directly into memory. If the mouse was clicked than we could say memory location 0×8000 will be set. Thus our program will constantly be checking that memory location until it is set and it will finally print “hello world.” This method is known as polling and it is quite inefficient. By doing this we have an endless loop freezing up the CPU and not allowing it to run any other code!
However we do have another method and it is known as interrupts. What happens with interrupts is the following: whenever a certain event occurs such as a mouse click the CPU finishes its current instruction and proceeds to jump from its current position(in memory) to a certain memory location specified by the mouse click interrupt. Interrupts solves the problem of “freezing up the CPU” because it allows the CPU to run other processes while our single program waits for the mouse click. Now someone might say, hey this isn’t bad? But its still not good, and here’s why: If the CPU jumps to a certain memory location every time the mouse is clicked than only one program can react to a mouse click! What if we have an operating system like windows and we want a mouse click to access different windows on the screen? That certainly couldn’t be fixed with this method of interrupts!



The Kernel

The kernel is what’s known as the heart of the OS. It is always running in the background and is known as the “trusted code.” It is called “trusted” because it has full control over all the computers resources and it must provide interfaces that allow programs to safely share the computers resources. If it lied your computer probably wouldn’t work too well.
To solve the interrupts problems, the kernel has a special portion known as the interrupt handler. The interrupt handler is used to designate which program will use the interrupt. Thus if you have multiple programs on the screen it is the kernels interrupt handler that chooses how each mouse click works. If you click on the mp3 player the mp3 player will come to the forefront. Otherwise if you click the “hello world” program than the message will print to the screen. How the kernel controls the CPU to handle this is the following: When the “Hello World” program gets to the instruction that says “wait for mouse click” The kernel blocks the process from the CPU and frees the CPU to run other processes. On top of freeing up the CPU the kernel designates that whenever a mouse click is made within the “hello world” program window, the program should be unblocked and its instructions should resume on the CPU.