.\" This module is believed to contain source code proprietary to AT&T.
.\" Use and redistribution is subject to the Berkeley Software License
.\" Agreement and your Software Agreement with AT&T (Western Electric).
.\"
.\"	@(#)p5	8.1 (Berkeley) 6/8/93
.\"
.\" $FreeBSD$
.SH
VII. TRAPS
.PP
The \*sPDP\*n-11 hardware detects a number of program faults,
such as references to non-existent memory, unimplemented instructions,
and odd addresses used where an even address is required.
Such faults cause the processor to trap to a system routine.
Unless other arrangements have been made,
an illegal action causes the system
to terminate the process and to write its
image
on file
.UL core
in the current directory.
A debugger can be used to determine
the state of the program at the time of the fault.
.PP
Programs that are looping, that produce unwanted output, or about which
the user has second thoughts may be halted by the use of the
.UL interrupt
signal, which is generated by typing the ``delete''
character.
Unless special action has been taken, this
signal simply causes the program to cease execution
without producing a
.UL core
file.
There is also a
.UL quit
signal
used to force an image file to be produced.
Thus programs that loop unexpectedly may be
halted and the remains inspected without prearrangement.
.PP
The hardware-generated faults
and the interrupt and quit signals
can, by request, be either ignored or caught by a process.
For example,
the \&shell ignores quits to prevent
a quit from logging the user out.
The editor catches interrupts and returns
to its command level.
This is useful for stopping long printouts
without losing work in progress (the editor
manipulates a copy of the file it is editing).
In systems without floating-point hardware,
unimplemented instructions are caught
and floating-point instructions are
interpreted.
.SH
VIII. PERSPECTIVE
.PP
Perhaps paradoxically,
the success of
the
.UX
system
is largely due to the fact that it was not
designed to meet any
predefined objectives.
The first version was written when one of us
(Thompson),
dissatisfied with the available computer facilities,
discovered a little-used \*sPDP\*n-7
and set out to create a more
hospitable environment.
This (essentially personal) effort was
sufficiently successful
to gain the interest of the other author
and several colleagues,
and later to justify the acquisition
of the \*sPDP\*n-11/20, specifically to support
a text editing and formatting system.
When in turn the 11/20 was outgrown,
the system
had proved useful enough to persuade management to
invest in the \*sPDP\*n-11/45,
and later in the
\*sPDP\*n-11/70 and Interdata 8/32 machines,
upon which it developed to its present form.
Our goals throughout the effort,
when articulated at all, have always been to build
a comfortable relationship with the machine
and to explore ideas and inventions in operating systems
and other software.
We have not been faced with the need to satisfy someone
else's requirements,
and for this freedom we are grateful.
.PP
Three considerations that influenced the design of
.UX
are visible in retrospect.
.PP
First:
because we are programmers,
we naturally designed the system to make it easy to
write, test, and run programs.
The most important expression of our desire for
programming convenience
was that the system
was arranged for interactive use,
even though the original version only
supported one user.
We believe that a properly designed
interactive system is much more
productive
and satisfying to use than a ``batch'' system.
Moreover, such a system is rather easily
adaptable to noninteractive use, while the converse is not true.
.PP
Second:
there have always been fairly severe size constraints
on the system and its software.
Given the partially antagonistic desires for reasonable efficiency and
expressive power,
the size constraint has encouraged
not only economy, but also a certain elegance of design.
This may be a thinly disguised version of the ``salvation
through suffering'' philosophy,
but in our case it worked.
.PP
Third: nearly from the start, the system was able to, and did, maintain itself.
This fact is more important than it might seem.
If designers of a system are forced to use that system,
they quickly become aware of its functional and superficial deficiencies
and are strongly motivated to correct them before it is too late.
Because all source programs were always available
and easily modified on-line,
we were willing to revise and rewrite the system and its software
when new ideas were invented, discovered,
or suggested by others.
.PP
The aspects of
.UX
discussed in this paper exhibit clearly
at least the first two of these
design considerations.
The interface to the file
system, for example, is extremely convenient from
a programming standpoint.
The lowest possible interface level is designed
to eliminate distinctions
between
the various devices and files and between
direct and sequential access.
No large ``access method'' routines
are required
to insulate the programmer from the
system calls;
in fact, all user programs either call the system
directly or
use a small library program, less than a page long,
that buffers a number of characters
and reads or writes them all at once.
.PP
Another important aspect of programming
convenience is that there are no ``control blocks''
with a complicated structure partially maintained by
and depended on by the file system or other system calls.
Generally speaking, the contents of a program's address space
are the property of the program, and we have tried to
avoid placing restrictions
on the data structures within that address space.
.PP
Given the requirement
that all programs should be usable with any file or
device as input or output,
it is also desirable
to push device-dependent considerations
into the operating system itself.
The only alternatives seem to be to load,
with all programs,
routines for dealing with each device,
which is expensive in space,
or to depend on some means of dynamically linking to
the routine appropriate to each device when it is actually
needed,
which is expensive either in overhead or in hardware.
.PP
Likewise,
the process-control scheme and the command interface
have proved both convenient and efficient.
Because the \&shell operates as an ordinary, swappable
user program,
it consumes no ``wired-down'' space in the system proper,
and it may be made as powerful as desired
at little cost.
In particular,
given the framework in which the \&shell executes
as a process that spawns other processes to
perform commands,
the notions of I/O redirection, background processes,
command files, and user-selectable system interfaces
all become essentially trivial to implement.
.SH
Influences
.PP
The success of
.UX
lies
not so much in new inventions
but rather in the full exploitation of a carefully selected
set of fertile ideas,
and especially in showing that
they can be keys to the implementation of a small
yet powerful operating system.
.PP
The
.UL fork
operation, essentially as we implemented it, was
present in the \*sGENIE\*n time-sharing system.
.[
lampson deutsch 930 manual 1965 system preliminary
.]
On a number of points we were influenced by Multics,
which suggested the particular form of the I/O system calls
.[
multics input output feiertag organick
.]
and both the name of the \&shell and its general functions.
The notion that the \&shell should create a process
for each command was also suggested to us by
the early design of Multics, although in that
system it was later dropped for efficiency reasons.
A similar scheme is used by \*sTENEX\*n.
.[
bobrow burchfiel tenex
.]