Introduction
Tanenbaum's textbook does not deal with Hardware Support for Operating Systems
as a separate topic. Instead it introduces the appropriate material as it is
needed by the subject. I want to list as a separate topic some
hardware support for OS to stress how important hardware is for the efficient
and simple implementation of software functions. In fact it would be useful
for the student to reflect on the ways good hardware facilitates the code
generation of compilers. Also useful, whenever we discuss an Operating
Systems topic, is to ask "How does the hardware explicitly support this
functionality? help solve this problem? make the solution more efficient?".
Privileged Instructions, Protection, Supervisory Calls
Certain machine instructions cannot be used by everybody. For example, Halt
would be dangerous in the hands of malicious, or naive, users. Thus certain
instructions should be used only by privileged users. These instructions
are called Privileged Instructions. For this reason the computer will
execute in one of (at least) two modes: a User Mode where no privileged
instruction can be used; and a Supervisory (also called Kernel)
Mode where all instructions can be executed.
Protection from the uncontrolled use of machine instructions
is the consequence of the mode distinction.
When in supervisory mode the program will use a new stack,
have a different program status vector, access a different set of addresses
than in user mode.
We talk of Process Context when executing is in user mode or executing in kernel mode and the kernel is operating on the process's behalf, say, in response to a service request or an exception. We talk of System or Interrupt Context when the kernel executes in response to an interrupt or it carries out a system task. The system context uses its own separate stacks. It will have at least one for interrupts and one for each system task. The relation between context and mode is described by the following figure.
We talk of User Space for the set of objects seen while executing in a process in user mode. We talk of System Space (it is unique) for the set of objects visible while in kernel mode.
Transfer from user mode to
supervisory mode may happen because of the explicit execution of a
supervisory (or system) call instruction (also called SVC or a Trap) or
because of an interrupt or exception.
Transfer back from the supervisory to the user mode occurs because
of an explicit return instruction (usually called REI, REturn from Interrupt).
Each transfer into the supervisory mode
due to a supervisory call should save the state of the caller, it should
carry across the modes parameters of the
request, and it should be followed in the supervisor code by checks on
the legality of the request. The hardware should help identify the cause
for the transfer into the supervisory mode.
The transition user-to-kernel mode and back has to be very efficient.
This is not easy to do since there may be changes in address space which
force extra work in the caches and Translation Look-aside Buffer.
The code executed in supervisory mode is usually called the
executive, a portion of this code is
the kernel of the operating system.
The idea of separate modes and privileged instruction has been so successful
that uses for more than two modes have been found.
Interrupts, Priorities, Exceptions
Supervisory calls (traps)
are explicitly requested by a program for going
from the user to the supervisory mode. An Exception
is also a transfer
from user mode to supervisory mode that is caused by the execution of
a program instruction and occurs synchronously with it.
But now, usually at least, the transfer was not planned:
you are dividing by zero, using an illegal address, writing to a read-only
location, etc.
In the case of
interrupts the transfer between modes is caused by some external event
that occurs asynchronously with respect to the instruction that enabled
the interrupt. Priorities are used to mask out certain interrupts.
The computer is run at a priority, say p1; interrupts arrive at another
priority, say p2. The interrupt takes place only if p1 <= p2.
Priorities can also be used in scheduling processes.
It is possible to have also software interrupts.
A software interrupt is explicitly requested with an instruction.
Here is the scenario: we are executing at high priority; we request
a software interrupt; the interrupt will occur and will be handled
when the CPU priority is sufficiently lowered. It is possible to be
executing with a number of pending interrupts, both hardware and software.
Of course we could do without exceptions and interrupts if we checked
for the conditions that cause them ourselves in our software. But that
would be incredibly inefficient. It is so much better to have it done uniformly
once and for all in the hardware as part of the instruction interpretation
cycle.
It is highly desirable for interrupts not to interfere with the execution
of instructions. In particular we want to have precise
interrups, that is interrupts that when they come in the middle
of the execution of an instruction, either are delayed to after
completion of the instruction, or they roll back execution to just before
the instruction; i.e. instructions should be atomic with respect to interrups.
Atomic Instructions and Synchronization
As we shall see, certain resources in a system must be accessed in
Mutual Exclusion and the concurrent execution of processes
must be synchronized. We will see also that certain sections of
code cannot be interrupted. But disabling/enabling of interrupts works well
only when we have a single processor. In multiprocessing systems we need
other solutions. We will see that software solutions to this problem are
difficult and time consuming. Again the hardware comes to the rescue with
instructions like TestAndSet and Swap that can be easily used to
implement synchronization and mutual exclusion mechanisms. The
atomic machine instructions carry out a read/modify/write
cycle without interference from other processors.
Memory Protection and Virtual Memory
Virtual Memory is supported by substantial hardware facilities. The first
support is for Memory Protection, to determine who has access to which
portion of memory and with which rights (Read, Write, Execute). A basic
mechanism is through base and limit registers. Of course hardware
has to be available to translate virtual addresses to physical addresses.
Illegal addresses, or protection violations, result in exceptions. Other
hardware has to be available to facilitate page/segment replacement
algorithms.
Clocks
Time and its measure play a fundamental role on the computer, both as
physical time, i.e. the time as we measure with our watches, and as logical
time, i.e time as used to order events in time ("this happens before that").
The hardware provides clocks, one to give us the exact time for "now", another
to count down a specified time interval and to create an interrupt when that
time has elapsed.
The student should have a clear idea of how a single countdown clock can be
used to generate scheduled timer interrupts for any number of concurrent processes.
I/O Control
Hardware provides instructions to start I/O operations and, if the operation
is not synchronous (i.e. completed at the end of the start operation), to
determine when the operation is completed. The start operation is not
difficult to do [either special I/O instruction or, for memory mapped I/O,
a simple memory write operation]. The completion of the I/O operation can be
recognised by reading some status location (polling), or more conveniently,
with an
interrupt. We have already seen how user/supervisor modes help deal
with interrupts. Handlers must be available for the interrupts. In general
software in the form of Device Drivers must be available to provide
for the user programs a uniform virtual interface to all the devices
supported by the operating system.
Conclusions
A complete understanding of the interplay of software and hardware functions
is crucial for the good computer scientist. As the functionality and costs
of the hardware change, the design decisions and constraints used in the
software have to be re-evaluated. Viceversa, software needs may drive the
re-evaluation of hardware decisions and the implementation of new hardware
features.
With good reason whole conferences of the ACM and IEEE are dedicated to
the subject of interactions between software and computer architecture.
http://www.cis.temple.edu/~ingargio/cis307/readings/hrw-support.html
ingargiola.cis.temple.edu