... "
The Synthesis Kernel
Calton Pu, Henry Massalin and 21 ~; John loannidis Columbia University
ABSTRACT: The Synthesis distributed operating system combines etticient kernel calls with a high level, orthogonal interface. The key concept is the use of a code synthesizer in the kernel to generate specialized (thus short and fast) kernel routines for specific situations. We have three methods of synthesizing code: Factoring Invariants to bypass redundant computations; Collapsing Layers to eliminate unnecessary procedure calls and context switches; and Executable Data Structures to shorten data structure traversal time. Applying these methods, the kernel call synthesized to read Idevlmem takes about 15 microseconds on a 68020 machine. A simple model of computation called a synthetic machine supports parallel and distributed processing. The interface to synthetic machine consists of six operations on four kinds of ohjects. This combination of a high-level interface with the code synthesizer avoids the traditional trade-off in operating systems between powerful interfaces and efficient implementations .
., Complliing .\'yslt'nIS, Vol. 1 • No.1' Winter IIJI!I! I I I. Introduction and data, and synthetic 1/0 units to move data in to and out of the synthetic machine. The synthetic machine interface and kernel code synthesizer A trade-off between powerful features and efficient arc independent ideas that have a synergistic eliect. Without the implementation exists in many operating systems. Systems with code synthesizer. even a sophisticated implementation of synthetic high-level interfaces and powerful features, like Argus lO and Eden/ machines would be very inetlicient. Each high-level kernel call require a lot of code for their implementation, and this added would require a large amount of code with a long execution time. overhead makes the systems slow. Systems with simple kernel I nstcad, the kernel code synthesizer generates specialized routines calls, like the V kernel,' Amoeba,') and Mach,' have little to make kernel calls short. Without a high-level interface, more overhead and run fast. However, the application software then layers of software would be needed to provide adequate becomes more complex and slower because extra code is required functionality. The synthetic machine supplies high-level system to make up for the missing kernel functions. Our goal in calls to reduce the number of layers and the associated overhead. developing the Synthesis distributed operating system is to escape In Synthesis, application programmers will enjoy a high-level from this trade-off. We want to provide a simple but high-level system interface with the efficiency of a "lean and mean" kernel. operating system interface to ease application development and at To test these ideas. we have designed and implemented a the same time offer fast execution. prototype system, with a simplified kernel code synthesizer that To achieve our goal, we combine two concepts in Synthesis. implements a subset of the synthetic machine interface. The most important idea is the inclusion of a code synthesizer in Encouraged by positive results of the prototype, which confirmed the kernel. The code synthesizer provides efficiency through the our expectations on its performance, we are now implementing generation of specialized code for frequently-executed kernel calls. the full version of Synthesis. For instance, when the programmer asks the operating system to In Section 2, we describe how the code synthesizer generates open a file. special routines to read and write that specific file are and optimizes code in the kernel. In Section 3, we summarize the returned. Through the generation of these frequently-executed sy'nthetic machine interface and illustrate the powe~ of the . system calls, Synthesis reduces operating system overhead. For interface with an emulation of the UNIX system uSing synthetic example, typical Synthesis read routines average an execution path machines. We outline the current Synthesis prototype in Section of 20 to 30 machine instructions. In contrast, the 4.3 BSD read 4, including some measurements to illustrate the efll.cie~cy gained call contains on the order of 500 lines of C code (Appendix 8). with synthesized code. Section 5 compares SyntheSIS With related The second idea is an orthogonal interface called a synthetic work, and Section 6 concludes with a summary of progress. machine. To a programmer, a synthetic machine presents a logical multi-processor with its own protected address space. Two reasons motivated this model of computation: to take advantage 2. Kernel Code Synthesizer of general-purpose shared-memory multiprocessors, and to support the growing number of concurrent programs. The Typical operating system kernel routines main.tain ~he syste~l state synthetic machine consists of three basic components: synthetic in data structures such as linked lists. To perlorm Its fUllc\lon, a ('PUs to run the program, synthetic memory to store the program kernel routine finds out the system state by traversing the. appropriate data structures and then takes the correspondlllg action. In current operating systems. there are few sh~rt cuts to reach frequently-visited system states, which may reqUire lengthy ThIS ro:~arch IS panlally supponed by Ihe New York SlalO: ('enler for Advanced '1 echnology, ('ompuler and InlorrnaliclII Sy5lems, NYSSTF CAT(H7~5. data structure traversals.
The S\'/J/h"JIj Kt'IIlt'/ I ] I 2 ('allon Pu. I\enry Massallll and John loannldls - The fundamental idea of kernel code synthesis is to capture As an example, we can use UNIX open as Ferratt and read as frequently visited system states in small chunks of code. Instead Fs"",,/' and the tile name as the constant parameter pl. Constant of traversing the data structures. we branch to the synthesized global data are the process id, address of kernel buffers, and the code directly. In this section. we describe three methods to device that the file resides on. F erralt consists of many small synthesize code: Factoring Invariants. Collapsing Layers, and procedure templates, each of which knows how to generate code Executable Data Structures. for a basic operation such as "read disk block" or "process 'ITV input." The parameters passed to P'ta" determine which of these 2.1 Factoring Invariants procedures are called and in what order. The final F,,,,,,II is created by filling these templates with addresses of the process table and The factoring invariants method is based on the observation that a device registers. functional restriction is usually easier to calculate than the original function. Let us consider a general function: 2.2 Collapsing Layers F",'1(P I .P 2•...• pn) The collapsing layers method is based on the observation that in a By factoring out the parameter pI through a process called layered design, separation between layers is a part of specification. currying. I. we can obtain an equivalent composite function: not implementation. In other words, procedure calls and context switches between functional layers can be bypassed at execution [F·r~alt(p I )1(P 2..... pn) :; F ",,(P I ,p 2. . .. pn ) time. Let us consider an example from the layered OSI model: F",att is a second-order function. Given the parameter pl. Ferralt Fb'lI(p I,p 2, ... ,p,,) ~ returns another function. 1","",,1. which is the restriction of Fb., that has absorbed the constant argument pI: Fappll<'a(P I.Fplmn/(JJ 2,FuuwlI( ... F,JUlaJlIdpn) ... »)
F,rtUJI/(p 2.... ,pn) C Fb.,(P l,p 2, .... pn ) Fapp/,ca is a function at the Application layer. that . calls successive. . lower layers to send a message. Through m-Ime code sub.sl1tutlon If F<"'ult is independent of global data, then for a given pI, F in F 1 we can obtain an equivalent l1at functIOn by of prt'Uf1' uPI' ,n" . . F,rra" will always compute the same F,"""I regardless of global eliminating the procedure call from the Application to the state. This allows F"If'O"(p I) to be evaluated once and the resulting Presentation layer: F,maJl used thereafter. If f~maJl is executed m times. generating and using it pays off when F~~;I/(a(P I.p 2.FJtnwn( ... ») ==
Cosf(Fata"(P I ))+ m·Cost (F,maJ/(P 2..... pn)) < Fappil .... (p I,Fplmn,(p2,F"uwlI( ... »)
m·Cost(Fb/,(P I. ... ,pn») The process to eliminate the procedure call can be e~bedded into two second-order functions. F;;;~~:~, returns code eqUivalent to As the "factoring invariants" name suggests, this method F and suitable for in-line insertion. I·~~W(~. incorporates that prt'J~1rI resembles the constant folding optimization in compiler code code to generate F,(:';/,IICII' generation. The analogy is strong. but the difference is also ·,·"~/, (P I Fc"a,. (P 2 ... ),F,:t:p/' ."aV' 1,1' 2,· .» significant. Constant folding in code generation eliminates static f illlp""''' , plt'Unl. t .-", code. In contrast. Factoring Invariants skips dynamic data This technique is analogolls to in-line code substitut~o.n for structure traversals in addition to eliminating code. procedure calls in compiler code generation. In addl~lon to the elimination of procedure calls and maybe context SWitches, the
'(h.> Srnlht's/.I' ht'rIIl'I I 5 14 Coil lUll I'u. lIellry Ma~!.aIJII and John loanmdls resulting code typically exhibits opponunities for funher • Inflated kernel size due to code redundancy. optimization, such as Factoring Invariants and elimination of data copying. • Structuring of kernel and correctness of its algorithms. ~y induction, F~;~~:~, can eliminate the procedure call to the • Protection of synthesized code. Session layer, and down through all layers. When we execute One imponant concern in Synthesis is kernel size inflation due F:;;';J:'~" to establis.h a vinual circuit, the F~l rlie S)'nllieSlS Arm ..1 I 7 If, (ahun I'u. II ,'n I)' Ma~!>ahn and John loannidls points. This protection mechanism is similar to C-lists to prevent application of the Collapsing Layers method decreases the cost of the forgery of capabilities. II> indirection and hierarchy in Synthesis. Synthesized routines run in supervisor state. The transition The Synthesis kernel implements the root synthetic machine from user to supervisor state is made via a trap instruction. Thus, running on the real machine. The scheduler, memory synthesized code can perform privileged operations such as management, and file system are part or the multiplexor program accessing protected buffer pages. Just before returning control to running in the root synthetic machine. Actual user programs run the caller, the synthesized code reverts to the previous mode. within child synthetic machines. The conceptual nesting of synthetic machines docs not introduce run-time overhead because of code synthesis, in particular Collapsing Layers. 3. Synthetic Machines Many existing operating systems have entities corresponding to a synthetic machine. Some examples arc the virtual machine in 3.1 Model 0/ Compwalion VM/310 and the UNIX process, which arc similar to a synthetic machine with only one SCPU, or Mach tasks I and Distributed V The synthetic machine is the unit of protection. Data in a teams,7 which are similar to multiple synthetic CPUs. Although synthetic machine are freely shared within it, but are carefully these systems share the same von Neumann model of protected from access by other synthetic machines. Each computation, their kernel interfaces are less orthogonal than the synthetic machine runs one program, and has three kinds of synthetic machine interface that now we describe. components: 3.2 Sylllhelic Machine Ifllerface • synthetic CPUs (SCPU) to run the program, • synthetic memory (SMEM) to store the program and data, For each synthetic machine, the creale kernel call is generative, • synthetic I/O units (SIO) 10 move data into and out from the synthesizing code for the executive kernel calls: terminate, synthetic machine. reconfigure, and query. To destroy a synthetic machine, we call terminate. During a synthetic machine's lifetime, reconfigure Each synthetic machine may have any number of SCPUs, SMEMs, changes its state, and q/lery reads its state. The synthetic machi~e and SIOs. Each SCPU is a thread of control scheduled on a kernel calls arc summarized in the second column of Table I (With physical CPU. Each SMEM is a segment of memory, accessible the Synthetic Machine heading). from all SCPUs of the same synthetic machine. Analogous to synthetic machines, each component must be Examples of SMEM include program segments and shared created before it can be used. The generative create kernel call memory between synthetic machines. Each SIO provides input or returns the code synthesized for the executive kernel calls, which output to the synthetic machine. Examples of SIO are ordinary include read and write in addition to terminale, reconfigure, and tiles, devices, and network communications. query. The read kernel call moves data into a syn~hetic ma~hine, An interesting example of a program running in a synthetic while write moves data out from it. Table I contall1s a partial machine is a multiplexor supporting other synthetic machines to summary of the interface to synthetic components. Duri~g form a hienuchical structure similar to VM1310. Y Child synthetic execution, if new situations require new code, the synthellc . machines are scheduled as any other SCPU, but they may "sub components may be resynthesized using the crcale kernel call With schedule" their own SCPUs with different scheduling algorithms. the REUSE option and a modified set of parameters. Similarly, their SMEMs are allocated by the parent synthetic machine. The SIO system calls for the child synthetic machine are synthesized from the parent's SIO system calls. Careful 'fht' Synlht'.m ht'Tllt" 19 I H (·"lton i'u. lIenry Ma~~ahn and Juhn Illannldl~ The synthetic machine interface is object-oriented. Synthetic Synlhellc SynlhellC Synlhcuc Synlhellc machines and synthetic components are encapsulated resources. Machme CPU Memory I/O and users must ask them to perform the kernel calls defined in .. creales pons. Table I. Pioneer object-oriented systems such as Hydra,lb Eden,2 " cr"",,, crealel an creales a Ihread allocales opens files. and Argus lU have achieved performance adequate for a prototype, (leneral,Ye) SMACtf of conlrol memory allocales devices while Mach is comparable to 8S0 UNIX. I We believe that synthesized code will take the performance of Synthesis one step kills an SMACtf frees ahcad of current systems. In Section 4.2, we justify our "''''.,lIal,. and all ils kills a Ihread memory kills pons. (ClC~ul,ye) componenls of conlrol closes files expectations with preliminary measurements. resumeslsuspen. resumeslsuspcn. changes lseek. r«onftgur.. an SMACtf, sepu. chanles proleclion, changes 3.3 Resource Sharing and Protection (cleculive) changes 115 priorilY. iniliales proleclion lIS pnorll)' wail on evenl sharing To support the shared-memory model of parallel processing, all gelS priorily, gels priori I),. &eu size. aeu device SCPUs within a synthetic machine share the same address space qu..,.' gels SMACH Id. &eu stale. s ..ning type, ....te. and thus. SMEMs can be used for communication and sharing (UCCUllvc) gelS uld leIs SCPlJ Id address devi.ce pointer bctween them. Semaphores control the synchronization between reads file. SCPUs. Currently, we are developing a high-level language to r ..wi ree. messages. support concurrent programming with synthetic machines. (el TIl,' Svnth,·S/.I I("mt'i 2 I 20 ('dllon I'u. Ilcnry Mas!iahn and John loanllIdls - 4. U!ork in Progress 4.2 First Version o/"Sojiware The fust version of Synthesis kernel is being written incrementally 4. J Target Hardware on top of a small kernel. ll At the moment, the Factoring Invariants method has been used in all input and output devices For single-CPU systems, Synthesis is intended 10 run on a von (SIO). including terminal 1/0 and a RAM-based file system. In the Neumann-style CPU with memory management unit and large round-robin scheduler, the Executable Data Structures method physical memory. The Synthesis prototype runs on an provides fast context switch between synthetic machines and experimental machine based on a 6H020 processor al 2() MHz wilh synthetic CPUs. a 16-bit-wide bus.) For debugging and measurements, Ihe We arc designing the message passing kernel primitives to prototype hardware provides single-step and real-time trace support distributed processing. At the core of the high-level facilities. In addition, a ROM-based monitor contains an message passing support is the optimization based on the assemhler, a disassembler, and a process manager, with a C-slyle Collapsing Layers method. inlerface. 11 Other commercially available machines are SUN-], The first program we measured reads one character from the Macintosh II, and similar products. With multiple SCPUs in the memory special-device file (equivalent to UNIX Idevlmem). Since same address space and SIOs to send/receive messages, Synthesis the only significant part of the program is the system call to read a supports parallel machines of both shared-memory model and byte, this program shows the promise of efficiency gained with message-passing model. synthesized code. A single example does not "prove" our For efficiency and lack of code synthesis support in high-level approach, but it shows how far code synthesis can go. languages, we are using 6H020 assembly language to write the first InC, the program is: full version of Synthesis kernel. Our own assembler supports Hinclude ")") ( .llhll' I'll. IIl'IIIY MJ~~alln. alill John loann,d,~ In this example, we have a more common situation where the SIO. Even the file servers return synthesized code to speed up lile overhead of a system call is amortized over a larger amount of access. useful work. A music synthesizer program has been written to run as an The numbers actually measured on the prototype system application on the prototype system. The application consists of appear in the "Measured" column of Table 2. For comparison six SCPUs in three stages. First, a note sequencer running in one purposes. we translated the numbers measured from the prototype SCPU feeds a four-voice sampling synthesizer, one voice per system into corresponding ones for a 68020-based machine SCPU. The voices from the second stage go to a summing running at 16 MHz. with a 32-bit data bus. This configuration is program in a sixth SCPU, which sends its output to the digital-to similar to SUN-3 and liP 9000/320 workstations. The translation analog converter port. The music synthesizer runs in real-time was obtained by hand-counting the CPU cycles for such machines. with a 25 kHz sampling rate and has demonstrated the speed of and the results appear in the column titled "Corrected." The our 1/0 operations and context switches. same programs were run on the UP 9000/320 workstation with the We are developing a variant of the C language, called HP-UX 5.17, SUN-3/50 with the SUN-OS 3.2, and Masscomp Lambda-C, to support code synthesis in a high-level language. MC5600 model 56S-02, with the RTU UNIX 3.1 operating system. Lambda-C will serve several purposes. First, we plan to build a The results appear in the same table. columns HP, SUN-3. and portable version of Synthesis, written in this language. Second. Masscomp. we believe that code-generating programs make for efficient applications. not just operating systems. A high-level language ro Corrected HP SUN-) Mauromp such as Lamhda-C will make these methods available to .. gram rMeasured ------~------_.-- Prog. I 1.6 sec 1.2 sec 17 sec 48 sec 29 sec application programmers. Third. type-checking of synthesized ------._--- code is non-trivial, and we need languages to support it. Prog. 2 20 sec 2.0 sec I S sec 4.9 sel' 4 S sec G------Table 2: Measured Figures and Comparison 5. Comparison with Other Systems 4.3 ProlOlype Experience The main ditlerence between Synthesis and other operating systems is in the combination of the synthetic machine interface Of the three synthetic components, we have found SIO to benefit and the kernel code synthesizer. No other operating system otters the most from synthesized code. Most of the improvement comes a high-level interface and the potential to generate efficient code. from the elimination of code that check parameters and states, UNIX iJ has evolved into a large system with Fourth Berkeley since these remain the same from call to call. A concrete Distribution '2 and AT&T System V. Although the interface example. the read system call in 4.3 BSD, is included in Appendix remains approximately the same in the many different variants of B. UNIX. the synthetic machine interface is more orthogonal. To the The current prototype includes a UNIX-like hierarchical tile best of our knowledge, no UNIX system uses a kernel code system. In addition. several file systems will co-exist in Synthesis. synthesizer. 1 'j Some file systems will consist of file servers running in synthetic The V kernel and Amoeba are two examples of small machines, with well-known SIO ports for local and remote file distributed operating system kernels. They both encourage layers service. Others, like the current hierarchical tile system, may be of software to be written on top of the kernel. Synthesis diners from both by the high-level synthetic machine interface, and the incorporated into the kernel. accessible through a special type of code synthesizer. 24 (OIlton I'll, Ill-nry Mils~ahll. and John loanllldis Machi offers an object-oriented interface that is isomorphic to W~ ~e1icve that the unique combination of simplicity and a specialized synthetic machine. A Mach task corresponds to a efllclency makes Synthesis an excellent system to write and synthetic machine; Mach thread, an SCPU; Mach port, the execute programs. network SIO; Mach messages, network SIO read and write; and Ackno .... ledgment.\" Mach virtual memory, an SMem. The synthetic machine uses the same interface for all 110 activities, and child synthetic machines We would like to thank Perry Metzger, Mike Schwartl, and Eric may be nested within a parent. As with other systems, Mach does Jul for their comments that improved the presentation of the not usc a kernel code synthesizer. paper. Gail Kaiser, Chip Maguire, Rajendra Raj, and Jonathan Emerald)./> is an object-oriented, integrated language and Smith helped with a previous version of the paper. Equally system. Synthesis lacks the language support in Emerald, in important, we would like to thank Ed Hee and Paul Kanevsky for particular the sophisticated typing system. In compensation, their varied contributions to the project, and AI Lash for although Emerald objects may be constructed at run-time (in a assistance in procuring laboratory facilities. AMD, Hitachi, Intel, way similar to synthesized code), its kernel calls are not Motorola, and Mupac contributed with hardware parts for the synthesized. project. 6. Conclusion We have combined two ideas in Synthesis. First, a kernel code synthesiler produces specialized and extremely efficient code for system calls. Second, an orthogonal, object-oriented, and high level interface has been derived from a simple model of computation. This combination gives Synthesis unique advantages. The kernel code synthesizer reduces the high-level interface ineffIciency problem. The high-level interface removes the slowdown due to multiple layers of software built on small kernels. Efficiency derived from the code synthesizer has been demonstrated on a prototype system. An example is a specialized read system call, which takes about fifteen microseconds. In comparison, the HP-UX and Masscomp RTU systems running on similar hardware need a few hundred microseconds for an equivalent, non-specialized read call. We expect to do even better in our full system, with very efficient SIO kernel calls including Iile systems, network communications, and other devices. We are implementing the full version of Synthesis for SUN-3 workstations and a 68020-based machine. After the kernel, we will design and implement language support, transaction processing, and real-time support, all taking advantage of synthesized code. n,.. St'lI/h",m A'I'fII'" 27 26 (alton I'u, Henry Mas!kIltn and John loannldis -----_.. I Appendix A: cl ock s addr op-codea instruction ------Trace of Generated Code 27---- 003F8008 4E41 trap 28 00000800 4EBO 10A6 0000 jar «(SYSYARS),PROCTBL,dl*4) FF3C 003f8000 7061 .oveq tl00000061, dO 16 003f2EOC 1030 05fl 003F .ove.b ([SHKPOINTER) , dO 003fll002 223C OOOF 4240 .0ve.1 tlOOOf4240, d2 1 ZE08 27---- 003F1I001I 4E4l trap 'I 10 1 003F2EE4 5Z89 003f 2EDB oddq.1 '1, SEEKPOINTER 20 t OOOOOACE 411E7 40EO ( 1) .0va•. 1 ~ H ("Ih>n I'u. Iknry Mas~hn. OInd John loanrlldls Appendix B: UN JX Comparison References I. M. Accetta. R. Baron, W. Bolosky. D. Golub, R. Ra~hid. For comparison purposes, we have analyzed 4.3 BSD since its A. Tevanian, and M. Young, Mach: a new kernel foundation for Sl).Urce was available. First we introduce some terms. A jile UNIX development. Procl't'd;"gs tifthl' 19H6 USIiNIX COllterellCl', dt:laiptor is an indirect index into an entry in the system open file pages 93-112, USENIX Association, 19116. . table. Each such "open tile structure" includes the address of the 2. G. T. Almes, A. P. Black, E. D. Lalowska, and J. D. Noe, The Eden first lllIIcil' (which contain the actual data stored in the file) of that system: a technical review, II:'I:'/:' Tran.l'tlC't;of/J Oil So/ill'are file and pointers to the set of functions used to manipulate this tIle }:'''gill('erillg. SI:-I I (I ):43-58, January 19115. . type, which are either the inode or the slX"ket operations. 3. James Arleth, A 680)(} A!lIlt;II.lw Developm('n/ SY.Wt'III. Master's Now, let us examine what happens when a file is opened. thesis, The Cooper Union for the Advancement of Science and Art, First, copen(} checks permissions and allocates an open tile New York City, 19114. structure. Then namei interprets the path name taking care of 4. J. R. Rell, Threaded code, COlllnlllnit'atitillS vfACM, 16(6):370-372, special cases like symbolic links and mounted file systems. If the June 1973. inode maknode file exists, its first is returned. Otherwise, is called 5. A. Black, N. Ilutchinson, L Jul, and H. Levy, Object structure in the to create the actual fIle. Then, the open file structure is filled out Emerald system, Proceedillgs of the Fint Allllllal Conferel/ce vn and the file descriptor leading to it is returned. The length of the Object-Oriented Pro~rammil/g. S),.I'tellls, l.angllagl'.I·. alld Applications, source code for all this is of the order of 1000 lines of C. pages 78-86, ACM, September 19116. Now, let us see how we can read from that open file. read 6. A. Black, N. /lutchinson, E. Jul, II. Levy, and I.. Carter, Distrihution massages its arguments and calls rwuio. The "open file structure" and abstract types in Emerald, If.·EE TrtllIsactiolls 01/ SoJiH'art' is examined to check for permissions, and validity checks are Ellgineerillg, SE-12( 12):65-76, January 1987. performed for the buffers. Then inoJw (the generic function to 7. D. C1lt:riton, The V kernel: a software base for distributed systems, read or write a file), is called indirectly. It does consistency n'El-.' Svjill'are, 1(2):19-4], April 1984. checking. then calls another function (rwip). In the case of a 8. D. Cheriton and W. Zwaenepoel, Thc Distributcd V kernel and its regular or a block-device file, special processing is done to take performance for disklt:ss workstations, Procet'dings of'tht' Nlflth advantage of the block 1/0 interface. then the block read (bread) S},!lIposilllll 01/ OPl'rtltlllX .\·I'.I'telll.1 Pril/dplt',\', pages 129-140, function eventually invokes the device driver to do the actual ACM/SIGOPS, October 1983. operation. For character-device files. the device driver is invoked 9. H. M. Deitc1, AI/ IlIfrodllction to Operating Systems, Addison-Wesley directly. Finally, the system call returns the number of characters Publishing Company, revised lirst edition, 1984. read. 10. B. II. Liskov and R. W. Scheiner, GUilHlians and Actions: lingUistic Just going through the code and not counting all the secondary support for rohust, distributed programs, PrtJce('ding~ (If'the Ninth procedures called, we counted more than 500 lines of C code. A Anl/llal Symposilllll Oil I'rilldplt,.I' t~" Progrlll1l1nin~ La"glt(J~t's, pages great deal of that code consists of multiple validity tests. case 7-19, January 19112. statements etc. This is because a large variety of cases has to be II. II. Massalin, A 680/0 Mliititasking Del'eIolmlellt ....'I'.I'tem, Master's handled by the same piece of code. thesis, The Cooper Union for the Advancement of Science and Art. New York City, 1984. 12. J. S. Quarterman, A. Silbcrschall, and J. L. Peterson, 4.2BSD and 4.3BSD as examples of the IJNIX system, ..tCM Compllting SlIn'L'}'S, 17(4):379-4111, December 1985. Tit., SI'II/h ... m /0."""'1 31 JO ('allon Pu. tlenry Ma~!>alin. and John loannldls 13. D. M. Ritchie and K. Thompson, The UNIX Time-sharing System, CommuntcationJ uJ.KM, 7(7):365-375, July 1974. 14. J. E. Stoy, Denotat;()nal St'nuwtics: The Scott-Stracht'}' Approach to Programming Language Theory, The MIT Press, 1977. 15. A. S. Tanenbaum and S. J. Mullender, The DeJlgn oj a Capahility Based Distrihllled Operating System, Technical Report IR-!!S, Department of Mathematics and Computer Science, Vrije Universiteit Amsterdam, November 1984. 16. W. A. Wulf, E. Cohen, W. Corwin, A. Jones, R. levin, C. Pierson, and F. Pollack, Hydra: the kernel of a multiprocessing operating system, Communications oJiKM, 17(6):337-345, June 1974. (sllhmllll'd St'pl n. /91J7; (U"Ct'plt'd Nav. 5. /987) ] 2 ( ,IlIOn I'u. HC:llry Massahn, and John loanntdis A