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