home *** CD-ROM | disk | FTP | other *** search
- .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
- .]
-