Commit | Line | Data |
---|---|---|
22b29f24 TL |
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 | .] |