home *** CD-ROM | disk | FTP | other *** search
/ minnie.tuhs.org / unixen.tar / unixen / PDP-11 / Trees / V7 / usr / doc / cacm / p5 < prev    next >
Encoding:
Text File  |  1979-01-10  |  7.2 KB  |  229 lines

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