![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to p5 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps2 / 01.cacm|
Return to p5 CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps2 / 01.cacm |
1.1 root 1: .\" @(#)p5 6.1 (Berkeley) 4/24/86
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: .]
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.