Operating Systems

Evolution of
Operating Systems

A. Frank - P. Weisberg
 :Assembler
A computer will not understand any program written in a
language, other than its machine language. The
programs written in other languages must be translated
into the machine language. Such translation is
performed with the help of software. A program which
translates an assembly language program into a machine
language program is called an assembler. If an
assembler which runs on a computer and produces the
machine codes for the same computer then it is called
self assembler or resident assembler. If an assembler
that runs on a computer and produces the machine codes
2 for other computer then
A. Frankit
- P.is called Cross Assembler.
Weisberg
 Assemblers are further divided into two types: One Pass
Assembler and Two Pass Assembler. One pass
assembler is the assembler which assigns the memory
addresses to the variables and translates the source
code into machine code in the first pass
simultaneously. A Two Pass Assembler is the
assembler which reads the source code twice. In the
first pass, it reads all the variables and assigns them
memory addresses. In the second pass, it reads the
source code and translates the code into object code.

3 A. Frank - P. Weisberg
 Compiler
It is a program which translates a high level language program into a
machine language program. A compiler is more intelligent than an
assembler. It checks all kinds of limits, ranges, errors etc. But its
program run time is more and occupies a larger part of the
memory. It has slow speed. Because a compiler goes through the
entire program and then translates the entire program into machine
codes. If a compiler runs on a computer and produces the machine
codes for the same computer then it is known as a self compiler or
resident compiler. On the other hand, if a compiler runs on a
computer and produces the machine codes for other computer then
it is known as a cross compiler.

4 A. Frank - P. Weisberg
 Interpreter
An interpreter is a program which translates statements
of a program into machine code. It translates only one
statement of the program at a time. It reads only one
statement of program, translates it and executes it.
Then it reads the next statement of the program again
translates it and executes it. In this way it proceeds
further till all the statements are translated and
executed. On the other hand, a compiler goes through
the entire program and then translates the entire
program into machine codes. A compiler is 5 to 25
times faster than an interpreter.
5 A. Frank - P. Weisberg
 By the compiler, the machine codes are saved
permanently for future reference. On the other
hand, the machine codes produced by
interpreter are not saved. An interpreter is a
small program as compared to compiler. It
occupies less memory space, so it can be used
in a smaller system which has limited memory
space

6 A. Frank - P. Weisberg
 Linker
• In high level languages, some built in header
files or libraries are stored. These libraries are
predefined and these contain basic functions
which are essential for executing the program.
These functions are linked to the libraries by a
program called Linker. If linker does not find a
library of a function then it informs to compiler
and then compiler generates an error. The
compiler automatically invokes the linker as the
last step in compiling a program.
7 • . A. Frank - P. Weisberg
 Not built in libraries, it also links the user defined
functions to the user defined libraries. Usually
a longer program is divided into smaller
subprograms called modules. And these
modules must be combined to execute the
program. The process of combining the
modules is done by the linker

8 A. Frank - P. Weisberg
 Loader
Loader is a program that loads machine codes of
a program into the system memory.
In Computing, a loader is the part of
an Operating System that is responsible for
loading programs. It is one of the essential
stages in the process of starting a program.
Because it places programs into memory and
prepares them for execution

9 A. Frank - P. Weisberg
 Loading a program involves reading the contents
of executable file into memory. Once loading
is complete, the operating system starts the
program by passing control to the loaded
program code. All operating systems that
support program loading have loaders. In many
operating systems the loader is permanently
resident in memory.

10 A. Frank - P. Weisberg
 ?Evolution of an Operating Systems
• Must adapt to hardware upgrades and new
types of hardware. Examples:
– Character vs. graphic terminals
– Introduction of paging hardware
• Must offer new services, e.g., internet support.
• The need to change the OS on regular basis
place requirements on it’s design:
– modular construction with clean interfaces.
– object oriented methodology.
11 A. Frank - P. Weisberg
 Evolution of Operating Systems
• Early Systems (1950)
• Simple Batch Systems (1960)
• Multiprogrammed Batch Systems (1970)
• Time-Sharing and Real-Time Systems (1970)
• Personal/Desktop Computers (1980)
• Multiprocessor Systems (1980)
• Networked/Distributed Systems (1980)
• Web-based Systems (1990)
12 A. Frank - P. Weisberg
 Early Systems
• Structure
– Single user system.
– Programmer/User as operator (Open Shop).
– Large machines run from console.
– Paper Tape or Punched cards.

13 A. Frank - P. Weisberg
 Example of an early computer system

14 A. Frank - P. Weisberg
 Characteristics of Early Systems
• Early software: Assemblers, Libraries of
common subroutines (I/O, Floating-point),
Device Drivers, Compilers, Linkers.
• Need significant amount of setup time.
• Extremely slow I/O devices.
• Very low CPU utilization.
• But computer was very secure.

15 A. Frank - P. Weisberg
 Simple Batch Systems
• Use of high-level languages, magnetic tapes.
• Jobs are batched together by type of languages.
• An operator was hired to perform the repetitive
tasks of loading jobs, starting the computer, and
collecting the output (Operator-driven Shop).
• It was not feasible for users
to inspect memory or patch
programs directly.

16 A. Frank - P. Weisberg
 Operator-driven Shop

17 A. Frank - P. Weisberg
 Operation of Simple Batch Systems
• The user submits a job (written on cards or
tape) to a computer operator.
• The computer operator place a batch of several
jobs on an input device.
• A special program, the monitor, manages the
execution of each program in the batch.
• Monitor utilities are loaded when needed.
• “Resident monitor” is always in main memory
and available for execution.
18 A. Frank - P. Weisberg
 Idea of Simple Batch Systems
• Reduce setup time by batching similar jobs.
• Alternate execution between user program and
the monitor program.
• Rely on available hardware to effectively
alternate execution from various parts of
memory.
• Use Automatic Job Sequencing – automatically
transfer control from one job when it finishes to
another one.
19 A. Frank - P. Weisberg
 Control Cards (1)
• Problems:
– 1. How does the monitor know about the nature of
the job (e.g., Fortran versus Assembly) or which
program to execute?
– 2. How does the monitor distinguish:
(a) job from job?
(b) data from program?
• Solution: Introduce Job Control Language
(JCL) and control cards.

20 A. Frank - P. Weisberg
 Control Cards (2)
• Special cards that tell the monitor which programs to run:
$JOB
$FTN
$RUN
$DATA
$END
• Special characters distinguish control cards from data or
program cards:
$ in column 1
// in column 1 and 2
709 in column1

21 A. Frank - P. Weisberg
 Job Control Language (JCL)
• JCL is the language that provides
$JOB
instructions to the monitor: $FTN
– what compiler to use ...
– what data to use FORTRAN
• Example of job format: ------->> program
...
– $FTN loads the compiler and transfers
$LOAD
control to it. $RUN
– $LOAD loads the object code (in place ...
of compiler). Data
– $RUN transfers control to user ...
program. $END
22 A. Frank - P. Weisberg
 Example card deck of a Job

23 A. Frank - P. Weisberg
 Another Job/Steps example

24 A. Frank - P. Weisberg
 Effects of Job Control Language (JCL)

• Each read instruction (in user program)

causes one line of input to be read.
• Causes (OS) input routine to be invoked:
– checks for not reading a JCL line.
– skip to the next JCL line at completion of
user program.

25 A. Frank - P. Weisberg
 Resident Monitor
• Resident Monitor is first rudimentary OS.
• Resident Monitor (Job Sequencer):
– initial control is in monitor.
– loads next program and transfers control to it.
– when job completes, the control transfers
back to monitor.
– Automatically transfers control from one job
to another, no idle time between programs.
26 A. Frank - P. Weisberg
 Resident Monitor Layout

27 A. Frank - P. Weisberg
 Resident Monitor Parts
• Parts of resident monitor:
– Control Language Interpreter – responsible
for reading and carrying out instructions on
the cards.
– Loader – loads systems programs and
applications programs into memory.
– Device drivers – know special characteristics
and properties for each of the system’s I/O
devices.
28 A. Frank - P. Weisberg
 Desirable Hardware Features
• Memory protection
– do not allow the memory area containing the
monitor to be altered by a user program.
• Privileged instructions
– can be executed only by the resident monitor.
– A trap occurs if a program tries these instructions.
• Interrupts
– provide flexibility for relinquishing control to and
regaining control from user programs.
– Timer interrupts prevent a job from monopolizing
29 the system. A. Frank - P. Weisberg
 Offline Operation
• Problem:
– Card Reader slow, Printer slow (compared to Tape).
– I/O and CPU could not overlap.
• Solution: Offline Operation (Satellite Computers) –
speed up computation by loading jobs into memory
from tapes while card reading and line printing is
done off-line using smaller machines.

30 A. Frank - P. Weisberg
 Main/Offline Computers

31 A. Frank - P. Weisberg
 Spooling (1)
• Problem:
– Card reader, Line printer and Tape drives slow
(compared to Disk).
– I/O and CPU could not overlap.
• Solution: Spooling -
– Overlap I/O of one job with the computation of
another job (using double buffering, DMA, etc).
– Technique is called SPOOLing: Simultaneous
Peripheral Operation On Line.
32 A. Frank - P. Weisberg
 Spooling System Components

33 A. Frank - P. Weisberg
 Spooling (2)

• While executing one job, the OS:

– Reads next job from card reader into a storage area
on the disk (Job pool).
– Outputs printout of previous job from disk to
printer.

• Job pool – data structure that allows the OS to select

which job to run next in order to increase CPU
utilization.
34 A. Frank - P. Weisberg
 We assumed Uniprogramming until now
• I/O operations are exceedingly slow (compared
to instruction execution).
• A program containing even a very small
number of I/O operations, will spend most of its
time waiting for them.
• Hence: poor CPU usage when only one
program is present in memory.

35 A. Frank - P. Weisberg
 Memory Layout for Uniprogramming

36 A. Frank - P. Weisberg
 Memory Layout for Batch Multiprogramming

Several jobs are kept in main memory at the same

time, and the CPU is multiplexed among them.

37 A. Frank - P. Weisberg
 Multiprogramming (1)

38 A. Frank - P. Weisberg
 Multiprogramming (2)

39 A. Frank - P. Weisberg
 ?Why Multiprogramming
• Multiprogramming (also known as
Multitasking) needed for efficiency:
– Single user cannot keep CPU and I/O devices busy
at all times.
– Multiprogramming organizes jobs (code and data)
so CPU always has one to execute.
– A subset of total jobs in system is kept in memory.
– One job selected and run via job scheduling.
– When it has to wait (for I/O for example), OS
switches to another job.
40 A. Frank - P. Weisberg
 Example of Multiprogramming
p1 p2 p3 kernel I/O
}
scheduler
I/O request

{
device driver
}scheduler

Time slice exceeded

}scheduler
Interrupt
{
device driver
}scheduler
41 A. Frank - P. Weisberg
 Components of Multiprogramming

42 A. Frank - P. Weisberg
 Requirements for Multiprogramming
• Hardware support:
– I/O interrupts and DMA controllers
• in order to execute instructions while I/O device is busy.
– Timer interrupts for CPU to gain control.
– Memory management
• several ready-to-run jobs must be kept in memory.
– Memory protection (data and programs).
• Software support from the OS:
– For scheduling (which program is to be run next).
– To manage resource contention.
43 A. Frank - P. Weisberg