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