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
in the current directory.
A debugger can be used to determine
the state of the program at the time of the fault.
Programs that are looping, that produce unwanted output, or about which
the user has second thoughts may be halted by the use of the
signal, which is generated by typing the ``delete''
Unless special action has been taken, this
signal simply causes the program to cease execution
used to force an image file to be produced.
Thus programs that loop unexpectedly may be
halted and the remains inspected without prearrangement.
The hardware-generated faults
and the interrupt and quit signals
can, by request, be either ignored or caught by a process.
the \&shell ignores quits to prevent
a quit from logging the user out.
The editor catches interrupts and returns
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
is largely due to the fact that it was not
The first version was written when one of us
dissatisfied with the available computer facilities,
discovered a little-used \*sPDP\*n-7
and set out to create a more
This (essentially personal) effort was
to gain the interest of the other author
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,
had proved useful enough to persuade management to
invest in the \*sPDP\*n-11/45,
\*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
We have not been faced with the need to satisfy someone
and for this freedom we are grateful.
Three considerations that influenced the design of
are visible in retrospect.
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
was arranged for interactive use,
even though the original version only
We believe that a properly designed
interactive system is much more
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.
there have always been fairly severe size constraints
on the system and its software.
Given the partially antagonistic desires for reasonable efficiency and
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.
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,
discussed in this paper exhibit clearly
at least the first two of these
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
the various devices and files and between
direct and sequential access.
No large ``access method'' routines
to insulate the programmer from the
in fact, all user programs either call the system
use a small library program, less than a page long,
that buffers a number of characters
and reads or writes them all at once.
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.
that all programs should be usable with any file or
device as input or output,
to push device-dependent considerations
into the operating system itself.
The only alternatives seem to be to load,
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
which is expensive either in overhead or in hardware.
the process-control scheme and the command interface
have proved both convenient and efficient.
Because the \&shell operates as an ordinary, swappable
it consumes no ``wired-down'' space in the system proper,
and it may be made as powerful as desired
given the framework in which the \&shell executes
as a process that spawns other processes to
the notions of I/O redirection, background processes,
command files, and user-selectable system interfaces
all become essentially trivial to implement.
not so much in new inventions
but rather in the full exploitation of a carefully selected
and especially in showing that
they can be keys to the implementation of a small
yet powerful operating system.
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.