Lecture Note 1
Lecture Note 1
A computer system can be divided roughly into four components: the hardware, the operating system,
the application programs, and the users.
The hardware—the central processing unit (CPU), the memory, and the input/output (I/O) devices
provides the basic computing resources for the system.
The application programs—such as word processors, spreadsheets, compilers, and Web browsers—
define the ways in which these resources are used to solve users’ computing problems.
The operating system— controls the hardware and coordinates its use among the various application
programs for the various users
We can also view a computer system as consisting of hardware, software, and data. The operating
system provides the means for proper use of these resources in the operation of the computer system.
An operating system is similar to a government. Like a government, it performs no useful function by
itself. It simply provides an environment within which other programs can do useful work.
User View
The user’s view of the computer varies according to the interface being used. Most computer users sit in
front of a PC, consisting of a monitor, keyboard, mouse, and system unit. Such a system is designed for
one user to monopolize its resources. The goal is to maximize the work (or play) that the user is
performing. In this case, the operating system is designed mostly for ease of use, with some attention
paid to performance and none paid to resource utilization—how various hardware and software
resources are shared. Performance is, of course, important to the user; but such systems are optimized
for the single-user experience rather than the requirements of multiple users.
In other cases, a user sits at a terminal connected to a mainframe or a minicomputer. Other users are
accessing the same computer through other terminals. These users share resources and may exchange
information. The operating system in such cases is designed to maximize resource utilization— to assure
that all available CPU time, memory, and I/O are used efficiently and that no individual user takes more
than her fair share.
In still other cases, users sit at workstations connected to networks of other workstations and servers.
These users have dedicated resources at their disposal, but they also share resources such as
networking and servers, including file, compute, and print servers. Therefore, their operating system is
designed to compromise between individual usability and resource utilization.
Recently, many varieties of mobile computers, such as smartphones and tablets, have come into
fashion. Most mobile computers are standalone units for individual users. Quite often, they are
connected to networks through cellular or other wireless technologies. Increasingly, these mobile
devices are replacing desktop and laptop computers for people who are primarily interested in using
computers for e-mail and web browsing. The user interface for mobile computers generally features a
touch screen, where the user interacts with the system by pressing and swiping fingers across the screen
rather than using a physical keyboard and mouse.
Some computers have little or no user view. For example, embedded computers in home devices and
automobiles may have numeric keypads and may turn indicator lights on or off to show status, but they
and their operating systems are designed primarily to run without user intervention.
System View
From the computer’s point of view, the operating system is the program most intimately involved with
the hardware. In this context, we can view an operating system as a resource allocator. A computer
system has many resources that may be required to solve a problem: CPU time, memory space, file-
storage space, I/O devices, and so on. The operating system acts as the manager of these resources.
Facing numerous and possibly conflicting requests for resources, the operating system must decide how
to allocate them to specific programs and users so that it can operate the computer system efficiently
and fairly. As we have seen, resource allocation is especially important where many users access the
same mainframe or minicomputer.
A slightly different view of an operating system emphasizes the need to control the various I/O devices
and user programs. An operating system is a control program. A control program manages the execution
of user programs to prevent errors and improper use of the computer. It is especially concerned with
the operation and control of I/O devices.
How, then, can we define what an operating system is? In general, we have no completely adequate
definition of an operating system. Operating systems exist because they offer a reasonable way to solve
the problem of creating a usable computing system. The fundamental goal of computer systems is to
execute user programs and to make solving user problems easier. Computer hardware is constructed
toward this goal. Since bare hardware alone is not particularly easy to use, application programs are
developed. These programs require certain common operations, such as those controlling the I/O
devices. The common functions of controlling and allocating resources are then brought together into
one piece of software: the operating system.
In addition, we have no universally accepted definition of what is part of the operating system. A simple
viewpoint is that it includes everything a vendor ships when you order “the operating system.” The
features included, however, vary greatly across systems. Some systems take up less than a megabyte of
space and lack even a full-screen editor, whereas others require gigabytes of space and are based
entirely on graphical windowing systems. A more common definition, and the one that we usually
follow, is that the operating system is the one program running at all times on the computer—usually
called the kernel. (Along with the kernel, there are two other types of programs: system programs,
which are associated with the operating system but are not necessarily part of the kernel, and
application programs, which include all programs not associated with the operation of the system.)
The matter of what constitutes an operating system became increasingly important as personal
computers became more widespread and operating systems grew increasingly sophisticated. In 1998,
the United States Department of Justice filed suit against Microsoft, in essence claiming that Microsoft
included too much functionality in its operating systems and thus prevented application vendors from
competing. (For example, a Web browser was an integral part of the operating systems.) As a result,
Microsoft was found guilty of using its operating-system monopoly to limit competition.
Today, however, if we look at operating systems for mobile devices, we see that once again the number
of features constituting the operating system is increasing. Mobile operating systems often include not
only a core kernel but also middleware—a set of software frameworks that provide additional services
to application developers. For example, each of the two most prominent mobile operating systems—
Apple’s iOS and Google’s Android—features a core kernel along with middleware that supports
databases, multimedia, and graphics (to name a only few).
Computer-System Operation
A modern general-purpose computer system consists of one or more CPUs and a number of device
controllers connected through a common bus that provides access to shared memory (Figure 1.2). Each
device controller is in charge of a specific type of device (for example, disk drives, audio devices, or
video displays). The CPU and the device controllers can execute in parallel, competing for memory
cycles. To ensure orderly access to the shared memory, a memory controller synchronizes access to the
memory.
Once the kernel is loaded and executing, it can start providing services to the system and its users. Some
services are provided outside of the kernel, by system programs that are loaded into memory at boot
time to become system processes, or system daemons that run the entire time the kernel is running. On
UNIX, the first system process is “init,” and it starts many other daemons. Once this phase is complete,
the system is fully booted, and the system waits for some event to occur.
The occurrence of an event is usually signaled by an interrupt from either the hardware or the software.
Hardware may trigger an interrupt at any time by sending a signal to the CPU, usually by way of the
system bus. Software may trigger an interrupt by executing a special operation called a system call (also
called a monitor call).
When the CPU is interrupted, it stops what it is doing and immediately transfers execution to a fixed
location. The fixed location usually contains the starting address where the service routine for the
interrupt is located. The interrupt service routine executes; on completion, the CPU resumes the
interrupted computation. A timeline of this operation is shown in Figure 1.3.
Interrupts are an important part of a computer architecture. Each computer design has its own interrupt
mechanism, but several functions are common. The interrupt must transfer control to the appropriate
interrupt service routine. The straightforward method for handling this transfer would be to invoke a
generic routine to examine the interrupt information. The routine, in turn, would call the interrupt-
specific handler. However, interrupts must be handled quickly. Since only a predefined number of
interrupts is possible, a table of pointers to interrupt routines can be used instead to provide the
necessary speed. The interrupt routine is called indirectly through the table, with no intermediate
routine needed. Generally, the table of pointers is stored in low memory (the first hundred or so
locations). These locations hold the addresses of the interrupt service routines for the various devices.
This array, or interrupt vector, of addresses is then indexed by a unique device number, given with the
interrupt request, to provide the address of the interrupt service routine for the interrupting device.
Operating systems as different as Windows and UNIX dispatch interrupts in this manner.
The interrupt architecture must also save the address of the interrupted instruction. Many old designs
simply stored the interrupt address in a fixed location or in a location indexed by the device number.
More recent architectures store the return address on the system stack. If the interrupt routine needs to
modify the processor state—for instance, by modifying register values—it must explicitly save the
current state and then restore that state before returning. After the interrupt is serviced, the saved
return address is loaded into the program counter, and the interrupted computation resumes as though
the interrupt had not occurred.