share/doc/psd/01.cacm/p5

   1 .\" This module is believed to contain source code proprietary to AT&T.
   2 .\" Use and redistribution is subject to the Berkeley Software License
   3 .\" Agreement and your Software Agreement with AT&T (Western Electric).
   4 .\"
   5 .\"     @(#)p5  8.1 (Berkeley) 6/8/93
   6 .\"
   7 .\" $FreeBSD$
   8 .SH
   9 VII. TRAPS
  10 .PP
  11 The \*sPDP\*n-11 hardware detects a number of program faults,
  12 such as references to non-existent memory, unimplemented instructions,
  13 and odd addresses used where an even address is required.
  14 Such faults cause the processor to trap to a system routine.
  15 Unless other arrangements have been made,
  16 an illegal action causes the system
  17 to terminate the process and to write its
  18 image
  19 on file
  20 .UL core
  21 in the current directory.
  22 A debugger can be used to determine
  23 the state of the program at the time of the fault.
  24 .PP
  25 Programs that are looping, that produce unwanted output, or about which
  26 the user has second thoughts may be halted by the use of the
  27 .UL interrupt
  28 signal, which is generated by typing the ``delete''
  29 character.
  30 Unless special action has been taken, this
  31 signal simply causes the program to cease execution
  32 without producing a
  33 .UL core
  34 file.
  35 There is also a
  36 .UL quit
  37 signal
  38 used to force an image file to be produced.
  39 Thus programs that loop unexpectedly may be
  40 halted and the remains inspected without prearrangement.
  41 .PP
  42 The hardware-generated faults
  43 and the interrupt and quit signals
  44 can, by request, be either ignored or caught by a process.
  45 For example,
  46 the \&shell ignores quits to prevent
  47 a quit from logging the user out.
  48 The editor catches interrupts and returns
  49 to its command level.
  50 This is useful for stopping long printouts
  51 without losing work in progress (the editor
  52 manipulates a copy of the file it is editing).
  53 In systems without floating-point hardware,
  54 unimplemented instructions are caught
  55 and floating-point instructions are
  56 interpreted.
  57 .SH
  58 VIII. PERSPECTIVE
  59 .PP
  60 Perhaps paradoxically,
  61 the success of
  62 the
  63 .UX
  64 system
  65 is largely due to the fact that it was not
  66 designed to meet any
  67 predefined objectives.
  68 The first version was written when one of us
  69 (Thompson),
  70 dissatisfied with the available computer facilities,
  71 discovered a little-used \*sPDP\*n-7
  72 and set out to create a more
  73 hospitable environment.
  74 This (essentially personal) effort was
  75 sufficiently successful
  76 to gain the interest of the other author
  77 and several colleagues,
  78 and later to justify the acquisition
  79 of the \*sPDP\*n-11/20, specifically to support
  80 a text editing and formatting system.
  81 When in turn the 11/20 was outgrown,
  82 the system
  83 had proved useful enough to persuade management to
  84 invest in the \*sPDP\*n-11/45,
  85 and later in the
  86 \*sPDP\*n-11/70 and Interdata 8/32 machines,
  87 upon which it developed to its present form.
  88 Our goals throughout the effort,
  89 when articulated at all, have always been to build
  90 a comfortable relationship with the machine
  91 and to explore ideas and inventions in operating systems
  92 and other software.
  93 We have not been faced with the need to satisfy someone
  94 else's requirements,
  95 and for this freedom we are grateful.
  96 .PP
  97 Three considerations that influenced the design of
  98 .UX
  99 are visible in retrospect.
 100 .PP
 101 First:
 102 because we are programmers,
 103 we naturally designed the system to make it easy to
 104 write, test, and run programs.
 105 The most important expression of our desire for
 106 programming convenience
 107 was that the system
 108 was arranged for interactive use,
 109 even though the original version only
 110 supported one user.
 111 We believe that a properly designed
 112 interactive system is much more
 113 productive
 114 and satisfying to use than a ``batch'' system.
 115 Moreover, such a system is rather easily
 116 adaptable to noninteractive use, while the converse is not true.
 117 .PP
 118 Second:
 119 there have always been fairly severe size constraints
 120 on the system and its software.
 121 Given the partially antagonistic desires for reasonable efficiency and
 122 expressive power,
 123 the size constraint has encouraged
 124 not only economy, but also a certain elegance of design.
 125 This may be a thinly disguised version of the ``salvation
 126 through suffering'' philosophy,
 127 but in our case it worked.
 128 .PP
 129 Third: nearly from the start, the system was able to, and did, maintain itself.
 130 This fact is more important than it might seem.
 131 If designers of a system are forced to use that system,
 132 they quickly become aware of its functional and superficial deficiencies
 133 and are strongly motivated to correct them before it is too late.
 134 Because all source programs were always available
 135 and easily modified on-line,
 136 we were willing to revise and rewrite the system and its software
 137 when new ideas were invented, discovered,
 138 or suggested by others.
 139 .PP
 140 The aspects of
 141 .UX
 142 discussed in this paper exhibit clearly
 143 at least the first two of these
 144 design considerations.
 145 The interface to the file
 146 system, for example, is extremely convenient from
 147 a programming standpoint.
 148 The lowest possible interface level is designed
 149 to eliminate distinctions
 150 between
 151 the various devices and files and between
 152 direct and sequential access.
 153 No large ``access method'' routines
 154 are required
 155 to insulate the programmer from the
 156 system calls;
 157 in fact, all user programs either call the system
 158 directly or
 159 use a small library program, less than a page long,
 160 that buffers a number of characters
 161 and reads or writes them all at once.
 162 .PP
 163 Another important aspect of programming
 164 convenience is that there are no ``control blocks''
 165 with a complicated structure partially maintained by
 166 and depended on by the file system or other system calls.
 167 Generally speaking, the contents of a program's address space
 168 are the property of the program, and we have tried to
 169 avoid placing restrictions
 170 on the data structures within that address space.
 171 .PP
 172 Given the requirement
 173 that all programs should be usable with any file or
 174 device as input or output,
 175 it is also desirable
 176 to push device-dependent considerations
 177 into the operating system itself.
 178 The only alternatives seem to be to load,
 179 with all programs,
 180 routines for dealing with each device,
 181 which is expensive in space,
 182 or to depend on some means of dynamically linking to
 183 the routine appropriate to each device when it is actually
 184 needed,
 185 which is expensive either in overhead or in hardware.
 186 .PP
 187 Likewise,
 188 the process-control scheme and the command interface
 189 have proved both convenient and efficient.
 190 Because the \&shell operates as an ordinary, swappable
 191 user program,
 192 it consumes no ``wired-down'' space in the system proper,
 193 and it may be made as powerful as desired
 194 at little cost.
 195 In particular,
 196 given the framework in which the \&shell executes
 197 as a process that spawns other processes to
 198 perform commands,
 199 the notions of I/O redirection, background processes,
 200 command files, and user-selectable system interfaces
 201 all become essentially trivial to implement.
 202 .SH
 203 Influences
 204 .PP
 205 The success of
 206 .UX
 207 lies
 208 not so much in new inventions
 209 but rather in the full exploitation of a carefully selected
 210 set of fertile ideas,
 211 and especially in showing that
 212 they can be keys to the implementation of a small
 213 yet powerful operating system.
 214 .PP
 215 The
 216 .UL fork
 217 operation, essentially as we implemented it, was
 218 present in the \*sGENIE\*n time-sharing system.
 219 .[
 220 lampson deutsch 930 manual 1965 system preliminary
 221 .]
 222 On a number of points we were influenced by Multics,
 223 which suggested the particular form of the I/O system calls
 224 .[
 225 multics input output feiertag organick
 226 .]
 227 and both the name of the \&shell and its general functions.
 228 The notion that the \&shell should create a process
 229 for each command was also suggested to us by
 230 the early design of Multics, although in that
 231 system it was later dropped for efficiency reasons.
 232 A similar scheme is used by \*sTENEX\*n.
 233 .[
 234 bobrow burchfiel tenex
 235 .]