|
|
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.