A radical computer architecture implernenting aprogramminglanguage and a timeshared operating system directly in hardware,Symbol remains a valuable lesson in buildling complex systems.

RR@f09e0m nft th~NOh4W LWnguwjft7ffnbi ft7M@?$ fl

David R. DitzelBell Laboratories

One of the most radical computer architectures of thelast decade was the Symbol"g2 computer system, unveiledin 1971. The primary goal of the Symbol research projectwas to demonstrate with a full-scale working computerthat a procedural general-purpose programming languageand a large portion of a timeshared operating system couldbe implemented directly in hardware, resulting in a markedimprovement in computational rates.3 Another goal wasto show that such a task could be carried out by a relative-ly small group of people in a reasonable amount of timeby using appropriate design tools and construction tech-niques. Some features commonly provided by softwarewere implemented directly in Symbol's hardware with se-quential logic networks. These included

* Hardware compilation,* Text editing,* Timesharing supervision,* Virtual memory management,* Dynamic memory allocation,* Dynamic memory reclamation,* Dynamically variable field lengths,* Dynamically variable sized structures,* Automatic data type conversion, and* Precision controlled arithmetic processing.The announcement and initial papers on the Symbol

system occurred before the system was fully operational,as it was being moved to Iowa State University for finaldebugging, evaluation, and use. This article offers someparting thoughts on Symbol, based on the observations ofthe author and others during the last four years of its use.Evaluating Symbol turned out to be remarkably difficultfor technical and administrative reasons. Part of theproblem was that Symbol was so radically different fromtraditional computers that a controlled comparison waspractically infeasible. In defense of the original designers,

however, the reader should be reminded that Symbol wasintended to be a learning device rather than a commercial-ly viable product.

Historical background. As early as 1964, a group ofengineers at Fairchild's research facility in Palo Alto,California, decided that the future of VLSI technologydictated the use of hardware for traditional softwarefunctions. They also believed that existing programminglanguages had been influenced too heavily by the underly-ing hardware and that valuable programmer time was un-necessarily being spent performing functions such asmemory management because of unreasonable computerarchitectures. A high-level language computer was seen asa way to reduce rising software costs.Though Symbol was an experimental machine, the

project was taken seriously. From the beginning there wasa strong commitment to build a real and functionalsystem. Considerable effort was spent on techniology,packaging, and computer-aided design tools. Anew high-speed logic family, complimentary transistor logic, wasdeveloped along with the dual in-line integrated circuitpackage, now the industry standard. A substantial com-puter-aided design system4'5 was written to do simulation,placement, and wire routing, check timing and loading,and maintain a system for documenting the circuitry ofmore than 20,000 packages.An initial decision was to implement Symbol entirely in

hardware, primarily as an experiment to probe the limitsof the hardware/software interface. A top-down designwas started with the user, the programming language, andthe operating system foremost in mind. Before any hard-ware was constructed, a design was completed for a newprogramming language, operating system, and user ter-minal interface. A high-level instruction set was then

0018-9162/81/0700-0055$00.75 (L 1981 IEEEJuly 1981 55

designed, using multiple processors to support it and theoperating system. These processors were implemented ac-cording to the initial system design. Symbol remains oneof the prime examples of a completely top-down ap-proach to computer system design.At the time that the fabrication of Symbol was com-

pleted and debugging began, the semiconductor industrywas in a recession. A managerial decision was made not tocontinue the project through a second, more commercial-ly viable design that Iowa State University was to havereceived for evaluation. Instead, Iowa State Universityobtained the original machine from Fairchild in 1971,through a grant from the National Science Foundation,for the purpose of bringing the machine to full operationso that the unique ideas of the architecture could be morefully documented and evaluated. The machine was broughtinto useful operation by 1973. Work on the system soft-ware and hardware was done by a group of about six peo-ple, mainly graduate students. Funding for the projectterminated in 1978. Shortly afterwards, hardware failuresforced the machine to be permanently decommissioned.

Symbol Programming Language

Part of the initial motivation for Symbol was the beliefthat existing programming languages had been unduly in-fluenced by architectures not designed to support high-level languages. Therefore, a new language was designedwhich was free of these machine artifacts. The SymbolProgramming Language, or SPL, was designed to be con-cise, yet powerful, in keeping with the mainstream ofgeneral-purpose procedural languages. In many ways,SPL can be viewed as a mixture ofAPL, Algol, and Lisp.All of the features of SPL contribute directly to programexecution rather than to easing compilation or memorymanagement. Because the instruction set and architectureof Symbol are so directly tied to the language it im-plements, the reader may wish to consult one of the manydescriptions of SPL3,6-9 for further details.SPL was designed for processing character-oriented

data that could be dypamically variable in type, shape,and size. Rigid type and size declarations were omittedfrom the language since they were seen to burden the user.Conversions and space management are handled auto-matically by Symbol's hardware. Data objects in SPL areeither scalars-that is, a sequence of characters that mayhappen to fit the definition of a number, boolean, orstring-or structures whose elements are scalars or otherstructures. Structures are explicitly representable in thelanguage and may be of any shape representable by a tree.Procedures pass parameters via call-by-name, also knownas call-by-substitution. Storage for all variables is notallocated automatically upon procedure entry; instead,storage is allocated for each variable on demand and re-tained upon procedure exit, as with static variables.Scoping rules are such that a variable is known only local-ly, unless explicitly declared to be global. Control flow isaccomplished with IF-THEN-ELSE-END statements andGOTOs. Though originally proposed, no looping con-structs were provided due to implementation complexity.

SPL also has ON blocks, similar in many ways to ONblocks in PL/I.Many features of the Symbol architecture are a direct

result of supporting the unusual requirements imposed bySPL. For example, the statement

A -This is a strings;

may require that new storage be allocated for the variableA. The statement

A-5 + 1;

would then change the internal type of A to numeric,though this would be of no concern to the user. Even fur-ther, the statement

A[500]-<1 1213>;

would change A from a scalar numeric into a structurewith 499 null elements and a 500th element that wasanother structure with the three scalar elements 1, 2, and3. Finally, the memory allocated for this large data struc-ture would be automatically reclaimed if the user were toreassign it to have the value of a simple scalar. All of thememory management, internal structure representation,and type information is handled automatically by Sym-bol's hardware.SPL turned out to be both a blessing and a curse. While

the language was simple to learn and easy to use, it wasdifficult to convince people to convert to it. SPL also mis-judged the trend toward more strongly typed languages.The computing science community seemed to consider alanguage "without declarations" as a heresy. On theother hand, programmers generally found SPL delight-ful, with its minor inadequacies leaving them room topropose language extensions.10-13 Among SPL's morememorable features were its treatment of strings as first-class objects, its ability to explicitly represent structures,and its powerful string operators, such asMASK andFOR-MAT.'4 However, much of SPL's power was not used intypical programs. Structures rarely needed to be totallyheterogeneous. Arbitrary precision arithmetic was usedmainly to present (admittedly) biased demonstrations ofone of the few things Symbol was faster at than most com-puters. Call-by-name was perhaps too powerful.

Symbol system architecture

The Symbol computer system is composed of eightrelatively autonomous processors the translator, thecentral processor, the system supervisor, the input/out-put processor, the memory reclaimer, the memory con-troller, the channel controller, and the drum controller.These processors and the major data paths are shown inFigure 1.The translator15'16 is a hardware-implemented com-

piler, assembler, linker, and loader that generates an in-ternally executable representation of the user's sourceprogram. The execution of this internal instruction set iscontrolled by the central processor, 17 which is composed

COMPUTER56

of four subprocessors. The instruction sequencer is re-

sponsible for fetching instructions, executing some di-rectly and delegating the rest to another subprocessor.The arithmetic processor'8 performs traditional arith-metic operations with precision-controlled decimal arith-nmetic. The format processorl9handlescharacter-orientedoperations as well as the packing and unpacking ofnumbers. Lastly, the reference processor controls allscalar and structure identifier referencing.The rest of the processors handle in hardware many

functions typically found in a software operating system.The system supervisor oversees the entire system, sched-uling the memory reclaimer, input/output processor,translator, and central processor. Page replacement forvirtual memory is also handled by the system supervisor.The channel controller provides communication fromuser terminals to the system's core I/O buffers. The in-put/output processor is responsible for transferring in-formation between these buffers and virtual memory. Inaddition, the input/output processor contains a hard-wired text editor, driven from a special editing keyboard.One of the more unusual aspects of Symbol is that the

memory structure is not organized as a contiguous set ofsequentially organized storage cells. Instead, storage isviewed by most of the processors as a limitless supply ofvariable-length storage strings, whose storage cells (ma-chine words) are logically sequential but not necessarilyconsecutively addressed in memory. Implementation ofthe Symbol memory structure consists of four hierar-

chical levels. At the lowest level, a core memory and a ro-tating magnetic drum constitute physical memory. Next isa paged virtual storage system consisting of 224 64-bitwords, of which 4096 2K-byte pages were implemented.The memory controller, with a set of high-level memoryoperations, maps virtual storage on to "logical stor-age.,20,21 The other processors can request memory onlythrough the memory controller with these "logical mem-ory operations." At the highest machine level are theCPU instructions which operate on the user data struc-tures. The user is never aware of these levels because hisonly interface to the machine is with the high-level SPL.

Symbol instruction set

Although the high-level SPL was implemented withoutsoftware, Symbol does not execute the source programdirectly. Instead, much like other computers, Symbol hasan internal instruction set. Unlike most computers,however, the instruction set is non-von Neumann and at avery high level, with almost a one-to-one mapping be-tween tokens in the source code and instructions in the ob-ject code.22 A program consists of three parts: a sequenceof instructions called the object string; a set of descriptorsfor each procedure called name tables; and variablestorage. Symbol is a stack machine. Instructions areordered in reverse Polish notation and make use of an ex-pression evaluation stack.

July 1981 57

Table 1.Symbol instruction set.*

8 9 A B C D E FNAMEt LINK TO NUMERIC

0 INPUT BLOCKt TO FROM RECLAIM TABLE SIMPLEGROUP POINTER VARIABLE + +

ASSIGN LINK TO NUMERIC1 OUTPUT DATA GROUP STRUCTURE + -

2 DISABLE (NSERT NUMERICGROUP -+

FETCH LINK TO NUMERIC3 ENABLE STRING TERMINAL LABEL --

HEADERFETCH DIRECTt LINK TO NUMERIC

4 EXACT AND PARAMETER DATA IN TRUEFOLLOW NAME TABLE ZERO

IF FALSEt FETCH INDIRECTt LINK TO STRING5 GOTO EMPIRICAL THEN UNRESOLVED START

JUP REVERSE PARAMETER SUBSRIPFOLLOW LINK TO STRING

6 PAUSE AND TEMPORARY ENDFETCH DATA

7RETURN SYSTEM ~~~~~~ENDFETCH7 RETURN SYSTEM BLOCK DIRECT TRANSFERt

STORE PARAMETER LINK TO8 BEFORE LIMITED IN AN D STRUCTURE

ASSIGN REUNFIELD

9 | SAME ABS STORE SOURCE9 SAME ABS ~~~~~~~~~~~ONLYPOINTER

A AFTER LTE * STOREAND INTEGERIZE LINK TOINSERT INEEIE FIELD (IN)END STORE LINK TOB NOT GTE + STATEMENT DIRECT NEGATE STRUCTURE(IN)

DELETE FIELD LINK TO BEGINC AN LESS LIMIT TO END MARK SUBSTRUCTURE VECTOR

D OR NEQ - EQUAL DELETE PERFORM BEGIND OR NED - EGUAL ~~~~~~~~STRINGSUBSCRIPTION STRUCTURE

DELETE LINK TO ENDE JOIN GREATER FORMAT PAGE DATA IN

LIST N.T.(IN) VECTOR

STORE ENDF MASK - / INTERRUPT TERMINAL STRUCTURE

HEADERSTUURIRequires address field.*Reprinted from Program Measurements on a High-Level Language Computer by David R. Ditzel. Computer, Vol. 13. No. 8. Aug. 1980. p 64. 1980 IEEE.

Table 1 shows the instruction set with the internal bitrepresentation in hexadecimal. There are approximately50 instructions, only six of which require an address field.Addresses are 24 bits long and address 64-bit words. Forhardware busing simplicity, and each word contains amaximum of two instructions, each halfword instructionconsists of an eight-bit opcode, optionally followed by a24-bit address. All operators are generic. Operand types,sizes, and lengths are determined from descriptors andtype tags associated with each operand.The translator produces a name table for each block

(main program, procedure, or ON) in the SPL source. Allteferences made in that block to labels, procedures, orvariqbies are made through the descriptors in that block'snamne table. The first word of a name table is called the"blofk control word," which contains status informa-tion about the entire block. Following the block control

word is a succession of entries for each identifier in theblock. Each entry consists of the ASCII name of the iden-tifier, followed by a one-word data descriptor for theidentifier, called the "identifier control word." The con-tents of the block control word and the identifier controlword are shown in Tables 2 and 3.The advantages of Symbol's instruction set would ap-

pear to be its semantic conciseness and uniform mech-anism for referencing data. Perhaps more important thanthe benefits derived from it are the unexpected conse-quences from the high-level nature of the instruction set.

Code compaction. There are several problems with thehigh-level nature of the instruction set, only a few ofwhich are specific to Symbol. The high-level and postfixstack orientation of the instruction set were expected togive good code compaction. However, closer examina-

COMPUTER58

tion revealed that Symbol's code was much less compactfor typical programs than that on traditional machinessuch as the IBM 360 or PDP-1 1.

Several factQrs account for this poor code density. Asubstantial fraction of the object code consisted of non-

functional end-of-statement operations, debugging linkspointing to the source program, and no ops. Code densitywas also lost because opcodes, which are one byte inlength, could be placed only in the first or fifth bytes ofthe eight-byte word, thus wasting three bytes fQr each op-

code not requiring an address field. The translator con-

tributed to the problem by producing extremely poor

code, at times even replicating nonfunctional instruc-tions. The strict one-to-one correspondence betweensource and object code resulted in the absence ofmany in-structions-for example, increment, set to zero, and ap-

pend a character-that could have been useful in optimiz-ing for common special cases. Symbol's unusual memorystructure also hindered code compaction by prohibitingany address calculations, thus precluding space saved byusing relative addressing techniques. The lesson learned isthat code compaction does not necessarily result from high-level instructions. Factors of two or three in code densitycan be lost without careful integration of the instructionset, compiler technology, and memory structure.Program measurements from Symbol23 were used in

the design of another Symbol-like system to see if codecompaction could be considerably improved for use in a

VLSI microprocessor.24,25 The results indicated that, al-though the instruction space could be made very compact,the use of descriptors as in Syrnbol make the final differ-ence relatively minor with respect to more traditional com-puters. The expected space savings from high-level instruc-tions was not significant due to the high frequency oflower-level operations typically found in modem programs.

High-level instructions and interrupt-handling. Anunexpected lesson was that there are times when instruc-tions can be at too high a level. Because of the variable-length operands and high-level operations, hundreds or

even thousands of memory references could be requiredto execute a single instruction. This had rather severe con-sequences on interrupt-handling (page fault, disk servic-ing, user interrupt, process switch, etc.). Proper interrupt-handling requires the ability to stop execution, handle theinterrupt, and then resume execution of the original in-struction at the point of the interrupt. For efficiency, it isimportant to be able to stop execution of an instruction(without completion), save all state information active inthe processing of the instruction, and resume execution ator near the point of interruption-rather than restart ex-

ecution of the instruction from the beginning. For a high-level algorithm, the state information that must be savedcan be rather large.A large fraction of Symbol's design bugs resulted from

the failure to save all the necessary state information. Thistype ofbug was extremely difficult to track down becausethe fatal interrupt was often generated nondeterministi-cally from combinations of disk interrupts, clock time-outs, or users pressing interrupt buttons. Another prob-lem was the inability to save all the necessary informationfor particular stages of the algorithm. These oversights

July 1981

were eventually fixed, sometimes at the expense of storingstate information at "convenient checkpoints." Restart-ing at such checkpoints not only repeated needless workafter task shutdowns but, even worse, caused hundreds ofmore state saves than were necessary, significantly de-grading system performance.

Optimization. Code optimization in Symbol would bedifficult to achieve because of the generalized nature ofthe operations. The addition of lower-level instructionscould have allowed optimization of many special cases.For example, incrementing a variable on Symbol couldtake over a dozen memory references due to its stack

Table 2.Block control word format.

BIT POSITION MEANING0 CONTROL WORD (ALWAYS 1 FOR BCW)1 START OF NAME TABLE (ALWAYS 1 FOR BCW)2 END OF NAME TABLE4t THIS BLOCK TRANSLATED IN PRIVILEGED MODE5t GLOBAL LINKING DONE6t LEFT ADDRESS FIELD VALID7t RIGHT ADDRESS FIELD VALID

8-31t FORWARD LINK IN LIST CONNECTING ALL NAME TABLES37 BLOCK IN USE38 BLOCK RECURSED

40-63t BACKWARD LINK TO BCW OF ENCLOSING BLOCKOTHERS UNUSED

tThese bits are used by the translator and not by the ceniral processor.

Table 3.Identifier control word format.

BITS MEANINGO CONTROL WORD (ALWAYS 1 FOR IDCW)1 START OF NAME TABLE (ALWAYS 0 FOR IDCW)2 END OF NAME TABLE

3-4 00 FOR NORMAL LOCAL VARIABLES01 FOR GLOBAL VARIABLE10 FOR IDENTIFIERS WHICH MAY NOT BE GLOBAL11 FOR PROCEDURES (MULTILEVEL GLOBAL)

0-3 INDICATES VARIABLE WITH VALUE IN NAME TABLE WHENALL FOUR BITS ARE SET. THE IDCW IS A SCALAR\VALUE(NOT ALLOWED FOR LAST IDCW IN NAME TABLE)

5 VARIABLE WITH INITIAL VALUE IN OBJECT STRING6 VARIABLE IS STRUCTURE-VALUED IF 1, SCALAR-VALUED IF

07 FLAG BITS 32-39 VALID

8-31 FOR VARIABLES, POINTER TO VALUE (ZERO IF SPACE NOTYET ASSIGNED). FOR LABEL OR PROCEDURE, POINTERTO OBJECT STRING ENTRY POINT

32-39 IF BIT 7 IS 0, TWO-DIGIT CURRENT POINTER INDEX USEDDURING SUBSCRIPTION. IF BIT 7 IS 1, THEN BITS 32-36ARE:

32 ON BLOCK FEATURE ENABLED34 IDENTIFIER IS A LABEL35 IDENTIFIER IS A PROCEDURE36 IDENTIFIER IS AN INDIRECT FORMAL PARAMETER

40-63 FOR IDENTIFIERS WITH ON BLOCKS, POINTER TO ON BLOCKCODE. FOR STRUCTURES WITHOUT ON BLOCKS, CURRENTPOINTER ADDRESS

OTHERS UNUSED

59

mechanism and indirection through descriptors. The uni-form referencing to data structures meant that a compilercould not optimize accessing for special cases; in par-ticular, a tremendous performance penalty was paid be-cause the memory structure made it impossible to per-form traditional indexing and address calculations. Evenif such indexing were possible, there would be an incom-patibility because of the inability to do binary arithmeticfor addressing on the decimal-only machine.

Descriptors and tags. Because Symbol was one of the fewexamples of a descriptor-based machine and a tagged ar-

chitecture, a few comments are appropriate. Operand- andinstruction-tagging were useful in catching occasionalmachine errors where, for a number of reasons, a memory

reference returned an incorrect value. There are no in-stances where data could possibly be mistaken for programor vice versa. Tagging did, in fact, report many machine er-rors that might have gone undetected in a traditionalmachine. Tags were also of great benefit in debugging andin developing sophisticated software debugging tools.

Descriptors had an even stronger impact on Symbol,both positively and negatively. Descriptors were in-

valuable in efficiently implementing the dynamic typingpresent in the language and in providing benefits for de-bugging tools. On the other hand, implementing recur-sion in SPL was a task left to system software, and it turnedout to be extremely inefficient. A simple test of recursionwith Ackermann's function would show Symbol to be atleast three orders of magnitude slower than traditionalmachines. The main problem was that the descriptors forthe entire procedure had to be copied upon a recursive callif the descriptors themselves might be modified in thecall-a virtual certainty in Symbol.

Need for a systems language. One of the problems withthe Symbol language and instruction set was that theywere not efficient for lower-level tasks common to sys-tems programming. The support tools on Symbol couldhave been more effectively supported through a systems-oriented language such as BCPL,26 Bliss,27 or C.28 Whileinefficiencies in short-lived user programs could be toler-ated, the same cannot be said for system software. TheSymbol Programming Language turned out to be inap-propriate for systems programming. It is recommendedthat even on computers that intend to support only one

A Symbol "terminal" could consist of up to 99 physical 1/0devices. The terminal shown at left used a modified IBMSelectric typewriter, editing keyboard, status display, cardreader, and line printer. The book next to the typewritercontains operating system and utility source listings. Thephoto above, a side view of the Symbol mainframe, showsthe maintenance processor (far left), power supplies for+4.5 volts at 1000 amps (below the mainframe), and diskmemory, core memory, and paging drum (background).The front view of the mainframe (photo at right) shows aprinted circuit card on an extender for testing. Each cardheld 200 lCs. Wing panels indicate the value of bus sig-nals-100 on the left, 100 on the right, and 50 on top.Additional wire on the PCB was used for "bug" fixes.Each processor could be monitored from a "processor ac-tive" lamp on the system's control panel.

60 COMPUTER60 COMPUTER

user language, a significant effort should go into support-ing an underlying systems language. Addition of a fewlower-level instructions could have made Symbol an ef-fective multilanguage system.

System software and the hardwiredoperating system

The functions of a complete timeshared operatingsystem were implemented directly in hardware by thesystem supervisor,29 aided by the memory controller,memory reclaimer, channel controller, drum controller,and input/output processor. Although system softwarewas intended by the designers to handle only certain ex-ceptional conditions, it was actually used to a muchgreater extent. The research team expended substantialeffort in developing loaders, text editors, improveddiagnostics, debugging packages, library routines, and afile system. This software was considered to be essential inmaking the system/user interface tolerable. System soft-ware accounted for several thousand lines of code by theend of the project. Some of the success of this softwarewas due to the foresight of the designers in providing

"hooks" in the hardware for software intervention,allowing the system to retain some flexibility despite itshardwired implementation.30Symbol answers two important questions about the

benefits derived from implementing major parts of anoperating system in hardware. First, it would seem thatthe overall design costs of developing a hardware-im-plemented operating system are much higher than anequivalent software implementation. Thus, the desire tolessen the cost of developing an operating system was notachieved. While software costs were reduced, overall costs

Symbol deserves as much recognition as asuccessful operating system machine as it

does for being a high-level language machine.

were not. Traditional software bug fixes were merely ex-changed for a "Request for Hardware Modification"sheet. The bound RFHMs were over four inches thick-and accounted only for changes made after the "debugged"system was delivered to Iowa State University! I

The second and more positive point is that the im-plementation of the hardwired operating system seems tohave been successful from a performance and program-ming standpoint. Though the inflexibility ofthehardwareoften prohibited changes towards more "modern" oper-ating system concepts, the implementation was successfulin terms of the original design goals. Using hardware forheavily used functions such as process-scheduling, virtualmemory management, memory allocation, and schedulingofmultiple processors seems to have been a wise trade-off.It was also shown that complex hardware can be suc-cessfully interfaced to the software part of the operatingsystem. In terms of the overall design, Symbol deserves asmuch recognition as a successful operating systemmachine as it does for being a high-level languagemachine.

A tale of two processors

While hardwired implementation of high-level func-tions has its merits, a look at two of Symbol's processorsmight prove insightful. Perhaps the most striking aspectof Symbol to a user was the amazing speed at which pro-grams were compiled-70,000 to 100,000 statements perminute. The Symbol translator3l is probably the only ex-ample of a compiler implemented entirely with randomlogic. The translator is perhaps the most amazing of Sym-bol's processors, not only because of its tremendous com-piling speed but also simply because it worked at all. Oneof the benefits of this tremendous translation speed wasthat no object files were saved. This was an advantage insaving storage space and in ensuring that object programsalways reflected the current source program.

There is no intent to imply, however, that such speedsare generally obtainable from a hardwired compiler and ahigh-level instruction set. The performance figures ofSymbol's translator are somewhat misleading in that the

July 1981 61

speed came primarily from two other factors. First,SPL6,7 had a grammar designed to be easy to parse. Non-optimal code was generated in one pass with backpatch-ing and without the need for building compile-time datastructures. The high translation speed could not be ex-pected in a proper implementation of a compiler for SPLor most programming languages in use today. Second, thetranslator did almost nothing more than crude code-generation and assembly. Error diagnostics were next tononexistent, though in the majority of cases syntax errorsin programs were detected. Our experience suggests thatcompilers should only be constructed using a high-levelprogramming language. Compiler complexity can per-haps be attacked more successfully by using modern com-piler writing tools32'33 than by developing high-level in-struction sets. The poor design of the translator was un-doubtedly due in large part to both the low-level im-plementation with which the designer was forced to workand the infantile state of compiler technology in the early1960's.Debugging the translator hardware was extremely dif-

ficult, because register-level flowcharts and wire listsproved to be totally inadequate forms for documentingthe conceptual process of translation. In no way could thedesign, implemention, and debugging of the Symbol'stranslator have been cost-effective when compared to acompiler programmed in a high-level language. The hard-ware dedicated to the translator was not cost-effective,since the logic was rarely in use and a similar functioncould have been performed by the central processor.Perhaps a more reasonable trade-off would have been toprovide the central processor with special-purpose hard-ware to aid with the various translation functions. Thiswould have had the additional benefit of allowing special-purpose hardware to be used for other functions besidestranslation.

Essential utilities of a system such as a texteditor and compiler need the ability to

change and grow, both to correct bugs and toadd new features.

Even more than the translator, the I/O processor34 suf-fered from the rigidity of a hardwired implementation.To offload the central processor, the I/O processor con-tained a hardwired text editor that ran extremely quickly.Unfortunately, the pushbutton-operated editor was sodifficult to use and so primitive that all on-line editing wasdone in the central processor with software text editors.The strict separation of the I/O processor and the centralprocessor did not allow the primitives in the hardwiredtext editor to be shared by the software text editors.

Two lessons are evident. First, essential utilities of asystem such as a text editor and compiler need the abilityto change and grow, both to correct bugs and to add newfeatures. The hardwired approach did not permit suchgrowth. The functional division was at too gross a level-for example, the specialized hardware in the translatorprovided an all-or-nothing service.

Second, special-purpose hardware is made flexible bymodularizing primitive operations so they can be con-trolled by the software. If the sequencing of the primitivesin the I/Q processor had been controllable by software thatwas accessible by the central processor, the performance ofthe software editors might have been much closer to that ofthe hardwired text editor. Much of the problem with Sym-bol was that the designers thought they knew how userswould want to use the machine. Whenever the actual use ofthe machine deviated even slightly from this, the hardwirednature of the translator, editor, and operating systemlocked the user into a mold he did not want to be in.

Memory management: A case ofstrange bedfellows

One of Symbol's unique features was its mixture of vir-tual memory with the implementation of noncontiguous"logical storage" strings. Symbol provided direct hard-ware support both for a paged virtual memory and fordynamic data structures. The hardware supported theallocation, deletion, and manipulation of storage stringswhich were constructed by linking together eight-wordgroups. Linked lists of such storage strings were used torepresent tree structures which were accessed in SPL asheterogeneous arrays. The sizes and shapes ofthese struc-tures were dynamically variable.The designers of Symbol foresaw and attempted to

mitigate the adverse interaction of the system's uniquecombination of memory management and virtual mem-ory. They realized that particular machine functions hadcharacteristic memory access patterns. For example, thesource code was used in program editing, but not at allduring execution. In program compilation, source codeand object code were scanned only once, whereas thename tables were scanned repeatedly. Hence, the design-ers decided that each page should be used for a single pur-pose and that page lists would be maintained to segregatethe pages according to their use. When memory was allo-cated, the crude usage class for the needed space was spec-ified by the hardware. This usage class determined whichpage list the system would consult to find the neededspace. Symbol maintained three separate page lists-onefor source code, another for object coce, and thethird forall other needs. Once any space on a page was allocated,the page was inserted on the appropriate page list.Thereafter, that page would be used only for further allo-cations of space of the same usage class. This schemeworked well for program editing and for constructingname tables and object code at compile time. However, atexecution time, all data accessing involved one page list,so there was no advantage to this scheme at that time.

It would have been worthwhile to experiment withadding more page lists to Symbol-lists of pages usedsolely for the stack, for temporaries, or for large struc-tures. Most likely, this would have limited the scatteringof these objects by restricting them to a segregated set ofpages. Unfortunately, implementation of additional pagelists would have required extensive modifications through-out the central pIrocessor. For this reason, it was neverattempted.

COMPUTER62

In Symbol, a single large structure could come to oc-cupy small portions of a large number ofpages. There wasno mechanism for compacting these structures. Modifi-cations to the memory allocation strategy attacked theproblem by preventing some of any reclaimed space oneach page from being founfd, except for expansion by ob-jects which already occupied a portion of that page. Thiswas known as the "space available list threshold" tech-nique. 35 Measurements taken on Symbol programs whichhad had significant paging activity indicated that this ap-proach reduced the number of page faults dramatically.The greatest benefits were realized when one sixth to onefourth of each page was reserved for the expansion men-tioned above.

Programs were developed that allowed theuser to examine in detail the state of hisprogram at the source program level.

Experiments were performed that reduced Symbol'spage size from the built-in 2K-bytes per page to as low as256 bytes per page. The use of smaller pages usually re-duced the paging activity for a fixed main memory size.This technique worked whenever severe scattering was en-countered, regardless of its origin. Unfortunately, the useof small pages could hurt where sequential access to alarge body of code or data was typical. Furthermore, thecost of the overhead associated with a large number ofpages could become significant. We cannot help but spec-ulate that the ability to request contiguous allocation of'large structures would have reduced paging considerably,even though it would have contradicted the declaration-free character of SPL.

Debugging on Symbol

Software. An outstanding benefit from the high-levelnature ofthe Symbol computer was the efficacy of the de-bugging tools36'37 produced for the system. Programswere developed that allowed the user to examine in detailthe state of his program at the source program level. Forexample, at a user-generated interrupt, the programmercould ask the inquire subsystem where the program wasexecuting and have the statement in execution decompiledfor display. The decompilation process was remarkablyeffective, and generally differed from the original sourceprogram only with respect to spaces and redundantparentheses. Since Symbol was a descriptor-based andtagged architecture, the current types, names, and valuesof all identifiers in the user's program were known.

There was never any need for a programmer to realizethat his program was being translated into an inter-mediate form for execution-one of the strongest pointssupporting the claim that Symbol was a high-level lan-guage computer system.38 In addition to the benefits thatthe machine offered for debugging, the dynamic type-checking mechanisms in the hardware proved veryvaluable for detecting occasional machine errors such astrying to use instructions as data or vice versa.

Hardware. One of the questions the implementationof Symbol was supposed to answer was whether or notexttemely complex hardware could be designed and de-bugged. The answer provided is that complex hardwarecan be designed and debugged, but only by investingtremendous effort and time. Although Symbol had beendebugged by 1971 to the point where it could run simpleprograms, hardware bugs were still being found invarious processors in 1978. Experience with debuggingthe Symbol system and more conventional software proj-ects suggests that bugs in hardware occur in much thesame way that they do in software. However, the prob-lems associated with finding and removing hardware bugsare far more severe.Changes to hardware are more time-consuming than

changes to software. Modifications to Symbol had to bedone with extreme care. Changes often had unexpectedside effects because the conceptual details of an algorithmwere not documented as they might have been with soft-ware. Because of this lack of conceptual documentation,it was not uncommon to cure the symptom rather than theproblem. Often, changes could not be made because ofphysical limitations, such as the number ofbus pins or thenumber of IC packages that would fit on a board. Hard-ware errors and bugs were not always deterministic.Therefore, it was first necessary to ascertain whether abug was due to an incorrect algorithm or a circuit failingbecause of a bad component.Any similar-scale hardware project must make special

efforts to provide the maximum possible effort for devel-oping design and debugging tools. The state of the art inconstructing and debugging digital systems is far behind thesame technology for software systems. This is probablyconnected with the limited use of high-level engineeringsystems such as Scald39 or Draw.40 Computer-aided debug-ging is a necessity. Symbol needed the ability to trace andstore the last several thousand operations in real time andhave the trace information analyzed automatically. Thelimited trace facility on Symbol perturbed the system to theextent that some errors would go away *hen traced. Fur-thermore, when a problem could be traced reliably, readingthrough hundreds of lines of hex-bit'pjatterns to find theoffending error often proved to be beyond human ability.

von Neumann realities

Symbol is a classic example of -a distinctly non-vonNeumann architecture. Features that take it out of thevon Newmann class are the noncontiguous memory struc-ture, automatic memory management, distinguishabilityof instructions from data, self-describing nature of struc-tures, and high-level instruction set. An early paper com-mented that

as implemented in the Symbol hardware, however, anytask requiring the variable field length processing andstorage or the dynamic structure features of the languageshould show a considerable performance gain over con-ventional software/hardware systems.3

Experience with Symbol suggests that this is probablytrue, but unfortunately there were not enough tasks ofthis type.

July 1981 63

Programs on Symbol, as on most computers, tended todo relatively simple operations. Arithmetic operationsusually involved adding or subtracting very small inte-gers-little use was made of the 99-digit precision-controlled arithmetic. Character strings most frequentlywere only a single character, rarely exceeding a dozencharacters in length. While some use was made of dynam-ically variable arrays, arrays were almost always homo-geneous and, once grown, remained static. At the machinelevel, it hurt a great deal that the memory structure anddecimal arithmetic processor precluded indexing with ad-dress arithmetic. Object code, name tables, and source fileswere always static objects after their creation; conse-quently, a better storage organization for them wouldperhaps have been a traditional contiguous linear store.The moral of this story is that the traditional von

Neumann computer perhaps is not so ill-suited to theoperations actually performed by typical programs. SPLand Symbol hardware were more powerful than theaverage user required. Some of Symbol's more advancedfeatures could have been implemented by software on atraditional machine to achieve a more cost-effective solu-tion to the same problems. Perhaps the conclusionswould have been different in another environment, butSymbol was not as much of an advantage over the vonNeumann machine as had earlier been hoped.

Microcode

The hardwired nature of the Symbol machine is oftencriticized for its inflexibility. Microcoding has been sug-gested as an implementation solution that is flexible andstill efficient.During the 1960's, when technology decisions were

being made, ROMs suitable for microcode lacked speed,lacked density, and were prohibitively expensive for thequantities required for Symbol. If one were to design thesame processors today, microcoding would obviously besuperior to a random logic implementation. Part of theSymbol experiment, however, was to push the limits of acompletely hardwired implementation, and microcodewould not have accomplished this.

This significant lessons learned from Symbol are notones concerned with whether or not it should have beenmicrocoded. Instead, they concern what has been learnedabout system complexity, refinement of complex sys-tems, debugging ofcomplex systems, functional division,and instruction set design. In fact, in many instancessystem software needs to be installation-modifiable. Amicrocode implementation generally would not fall intothis category.

Was Symbol really an HLLCS?

Why Symbol is considered to be one of the few realhigh-level language computer systems is crucial to note.The Symbol machine with- and only with-the softwaredeveloped for it meets the HLLCS definition38 because it

* Uses a high-level language for all programming,debugging, and other user/system interactions,

* Discovers and reports syntax and execution errors interms of the high-level language source program,37and

* Does not have any outward appearance of transfor-mations from the upper programming language toany internal languages.

Perhaps the most crucial part ofmeeting this definitionin any system is being able to debug a program at thesource language level. The Symbol architecture facili-tated this with high-level instructions that allowed objectcode to be easily decompiled back into source, and in theself-describing nature of all data objects that allowed theunambiguous interpretation of any data storage. A high-level language computer system is different from andmore important than just a machine with a "high-level"instruction set.

Conclusion

The existence of the working Symbol computer systemclearly demonstrates that a high-level instruction set, acompiler, automatic memory management, and a majorportion of a timeshared operating system can be im-plemented successfully in hardware. Use of the Symbolsystem showed to a lesser degree that the costs of buildingsuch a system are not less than building an equivalentsystem in software; that the ability to evolve a system isperhaps more important than having a very fast func-tional unit that is never used; and that performance gainsobtained from a hardwired implementation are easilylost. A "high-level" instruction set does not guaranteebetter performance, nor does it solve "the software prob-lem." In designing a high-level language computer sys-tem, one must carefully examine the cases under which asimpler architecture might perform equally well.41

Building complex hardware is proneto the same bugs and fundamental design

errors that plague complex software systems.

Symbol taught us a great deal about building complexsystems. The top-down design approach made it neces-sary for the entire system to be conceived before any of itwas implemented; the results show that this is dangerous.Building complex hardware is prone to the same bugs andfundamental design errors that plague complex softwaresystems. Symbol contained many excellent and uniquesolutions to individual problems, but the complex in-teractions of all of these solutions made the entire systemcumbersome and slow. Refinement and iterative im-provement are steps that most software systems must gothrough before reaching acceptable levels ofperformanceand utility; this step was desperately needed with Symbol.Performance might have been improved more than anorder of magnitude if many of the known inefficienciescould have been tuned or removed. Despite the construc-tive criticism offered in this article, the Symbol experienceremains a very positive first step in the design of high-levellanguage computer systems. E

COMPUTER64

Acknowledgments

Rex Rice, William R. Smith, and the Symbol design teamat Fairchild have to be commended for their innovative at-tempt to create a totally new architectural philosophy.Were it not for the premature cancellation of the Symbolproject, the computing industry might be different today.Financial support provided by the National Science Foun-dation under Grant GJ33097X kept Symbol alive, enablingthe author and a handful ofdedicated students to probe theinner workings ofthis remarkable machine. Sections ofthisarticle came from works coauthored with William A.Kwinn and Robert F. Cmelik and presented at the 1980Workshop on High-Level Language Computer Architec-ture.22'37'42 Their efforts are greatly appreciated. Theeditorial criticism of K. Kwinn on this and other articlesgreatly improved the author's otherwise obfuscatorywriting style. P. C. Hutchison is appreciated for the manyhours he spent as a data base from which the solution to anyhardware or software problem could be extracted. TheSymbol project at Iowa State University was administeredunder the direction of R. M. Stewart and R. J. Zingg.

References

1. R. Rice and W. R. Smith, "SYMBOL-A Major Depar-ture from Classic Software Dominated von NeumannComputing Systems," AFIPS Conf. Proc., 1971 SJCC,Vol. 38, AFIPS Press, Montvale, N.J., 1971, pp. 575-587.

2. W. R. Smith et al., "SYMBOL-A Large ExperimentalSystem Exploring Major Hardware Replacement of Soft-ware," AFIPS Conf. Proc., 1971 SJCC, Vol. 38, pp.601-616.

3. G. D. Chesley and W. R. Smith, "The Hardware-Imple-mented High-Level Language for SYMBOL," AFIPSConf. Proc., 1971 SJCC, Vol. 38, pp. 563-573.

4. B. E. Cowart, R. Rice, and S. F. Lundstrom, "The Phys-ical Attributes and Testing Aspects of the SYMBOLSystem," AFIPS Conf. Proc., 1971 SJCC, Vol. 38, pp.589-600.

5. M. A. Calhoun, "SYMBOL Hardware Debugging Facil-ities," AFIPS Conf. Proc., 1972 SJCC, pp. 359-368.

6. H. Richards, Jr., SYMBOL IIR Programming LanguageReference Manual, Report ISU-CCL-7301, Cyclone Com-puter Lab., Iowa State University, Ames, Iowa, 1973.NTIS accession number PB-221 378.

7. H. Richards, Jr., and C. Wright, "Introduction to theSYMBOL 2R Programming Language," Proc. ACM-IEEE Symp. High-Level-Language Computer Architec-ture, ACM, New York, 1973, pp. 27-33. NTIS accessionnumber PB-228 115/AS.

8. T. A. Laliotis, "Architecture of the SYMBOL CornputerSystem," in High-Level Language Computer Architec-ture, ed. Y. Chu, Academic Press, New York, 1975.

9. G. J. Myers, Advances in Computer Architecture, JohnWiley & Sons, New York, 1978.

10. P. C. Hutchison, Extensions to a Block-Structured Pro-gramming Language to Support Processing of SymbolicData and Dynamic Arrays, Special Report ISU-CL-7705,Cyclone Computer Lab., Iowa State University, Ames,Iowa, 1977.

11. R. W. Black, Structured Programming in the SYMBOL-2R Programming Language, Special Report ISU-CL-7405,Cyclone Computer Lab., Iowa State University, Ames,Iowa, 1976.

12. D. R. Ditzel, "Pattern Matching for High Level Lan-guages," SIGPLANNotices, Vol. 13, No. 5, May 1978,pp. 46-55.

13. R. E. Wolf, SYMBOL 2-R Compatible Tree Manipula-tion, Special Report ISU-CL-7602, Cyclone ComputerLab., Iowa State University, Ames, Iowa, 1976.

14. D. R. Ditzel, "MASK and FORMAT: Operators forEditing and Formatting," SIGPLAN Notices, Vol. 12,No. 11, Nov. 1977, pp. 28-35.

15. J. W. Anderberg, Source Program Analysis and ObjectString Generation Algorithms and Their Implementationin the SYMBOL 2R Translator, Report NSF-OCA-GJ33097-CL7410, Cyclone Computer Lab., Iowa StateUniversity, Ames, Iowa, 1974. NTIS accession numberPB-230 614/AS.

16. J. W. Anderberg and C. L. Smith, "High-Level LanguageTranslation in SYMBOL 2R," Proc. ACM-IEEE Symp.High-Level-Language Computer Architecture, ACM, NewYork, 1973. NTIS accession number PB-228 117/AS.

17. P. C. Hutchison and K. Ethington, "Program Executionin the SYMBOL 2R Computer," Proc. ACM-IEEE Symp.High-Level-Language Computer Architecture, ACM, NewYork, 1973. NTIS accession number PB-228 780/AS.

18. A. C. Bradley, An Algorithmic Description of the SYM-BOL Arithmetic Processor, Report NSF-OCA-GJ33097-CL7301, Cyclone Computer Lab., Iowa State University,Ames, Iowa, 1973. NTIS accession number PB-222 972.

19. M. C. Dakins, NonnumericProcessing in theSYMBOL-2RComputer System, Report NSF-OCA-GJ33097-CL7410,Cyclone Computer Lab., Iowa State University, Ames,Iowa, 1974.

20. H. Richards, Jr., and R. J. Zingg, "The Logical Structureof the Memory Resource in the SYMBOL-2R Computer,"Proc. ACM-IEEE Symp. High-Level-Language ComputerArchitecture, ACM, New York, 1973. NTIS accessionnumber PB-228 118/AS.

21. R. J. Zingg and H. Richards, Jr., "SYMBOL: A SystemTailored to the Structure of Data," Proc. Nat ' ElectronicsConf., Vol. 27, National Electronics Conference, Inc.,Oak Brook, Ill., 1972, pp. 306-311. NTIS accessionnumber PB-221 286.

22. R. F. Cmelik and D. R. Ditzel, "The High Level LanguageInstruction Set of theSYMBOL Computer System," Proc.1980 Workshop High-Level Language Computer Ar-chitecture, Ft. Lauderdale, Fla., May 1980, pp. 238-246.

23. D. R. Ditzel, "Program Measurements on a High-LevelLanguage Computer," Computer, Vol. 13, No. 8, Aug.1980, pp. 62-72.

24. D. R. Ditzel, "Investigation of a High Level LanguageOriented Computer for X-Tree," MS thesis, University ofCalifornia, Berkeley, Calif., 1979. Available as Comput-ing Science Technical Report No. 88, Bell Laboratories,Murray Hill, N.J.

25. D. R. Ditzel, "Architectural Support for ProgrammingLanguages in the X-Tree Processor," Digest of PapersCompcon 80 Spring, pp. 335-339.*

26. M. Richards, "BCPL: A Tool for Compiler Writing andSystem Programming," AFIPS Conf. Proc., 1969 SJCC,Vol. 34, pp. 557-166.

27. W. A. Wulf, D. B. Russell, and A. N. Habermann,"BLISS: A Language for Systems Programming,"Comm. ACM, Vol. 14, No. 12, Dec. 1971, pp. 780-790.

28. B. W. Kernighan and D. M. Ritchie, The C ProgrammingLanguage, Prentice-Hall, Englewood Cliffs, N.J., 1978.

29. W. R. Smith, "System Supervisor Algorithms for the SYM-BOL Computer," Digest ofPapers Compcon 72, pp. 21-26.

30. H. Richards, Jr., and A. E. Oldehoeft, "Hardware-Soft-ware Interactions in SYMBOL-2R's Operating System,"

July 1981 65

Proc. Second Ann. Symp. ComputerArchitecture, 1975,pp. 113-118. NTIS accession number PB-239 220/AS.*

3i. T. A. Laliotis, "Implementation Aspects of the SYMBOLHardware Conipiler, " Proc. First Ann. Symp. ComputerArchitecture, ACM, New York, 1973, pp. 111-115.

32. S. C. Johnson and M. E. Lesk, "Unix Time-Sharing Sys-tem: Language Development Tools," Bell System Tech-nical J., Vol. 57, No. 6, 1978, pp. 2155-2175.

33. B. W. Leverettet al., An Overview oftheProductionQual-ity Compiler-Compiler Project, Report CMU-CS-79-105,Carnegie-Mellon University, Feb. 1979.

34. W. E. Jones, The Role of the Interface Processor in theSYMBOL IIR Computer System, Special Report NSF-OCA-GJ33097-CL7304, Cyclone Computer Lab., IowaState University, Atines, Iowa, 1973. NTIS accessionnumber PB-227 454/AS.

35. W. A. Kwinn, Memory Management Ppliciesfor a Hard-ware Implemented Computer Operatiqg System, SpecialReport MCS72-03642-CL7801, Cyclone Computer Lab.,Iowa State University, Ames, Iowa, 1978.

36. D. R. Ditzel, Interactive Debugging Tools for a BlockStructured Programming Language, Report MCS72-03642-CL7802, Cyclone Computer Lab., Iowa State Uni-versity, Ames, Iowa, 1978.

37. D. R. Ditzel, "High Level Language pebugging Tools onthe SYMBOL Computer System,`Ptoc. 1980 WorkshopHigh-Level Language ComputerArqh,tecture, Ft. Lauder-dale, Fla., May 1980, pp. 247-255.

38. D. R. Ditzel and D. A. Patterson, "Retrospective on High-Level Language Computer Architecture," Proc. 7th Ann.Symp. ComputerArchitecture, 1980.*

39. T. M. McWilliams and L. C. Widdoes, Jr., SCALD: Struc-tured Computer-Aided Logic Design, Technical ReportNo. 152, Digital Systems Lab., Stanford Universityi Stan-ford, Calif., Mar. 1978, pp. 2233-2249.

40. A. G. Fraser, "UNIX Time-Sharing System: CircuitDesign Aids," Bell System Technical J., Vol. 57, No. 6,1978, pp. 2233-2249.

41. D. R. Ditzel and D. A. Patterson, "The Case for theReduced Instruction Set Computer," Computer Architec-ture News, Vol. 8, No., 7, 1980.

42. D. R. Ditzel and W. A. Kwinn, "Reflections on a HighLevel Language Computer System or Parting Thoughts onthe SYMBOL Project," Proc. 1980 Workshop High-LevelLanguage Computer Architecture, Ft. Lauderdale, Fla.,May 1980, pp. 80-87.

Additional sources on Symbol

Agrawal, O., "Applicability of Buffered Main Memory toSYMBOL 2R Like Computing Structures," PhD dissertation,Iowa State University, Ames, lqwa, 1974.Alarilla, L. M., Jr., Storage Linking Techniques for theAutomatic Management of Dynamically Variable Arrays,Report ISU-CL-7403, Cyclone Computer Lab., Iowa StateUniversity, Ames, Iowa, 1974.Bretl, R. F., A Hierarchic Control Structurefor UserProgramsin theSYMBOL System, Special Report ISU-CL-7501, CycloneComputer Lab., Iowa State University, Ames, Iowa, 1976.Chu, Y., "Significance of the SYMBOL Computer System,"Digest ofPapers Compcon 72, pp. 33-35.Falk, H., "Hard-Soft Tradeoffs," IEEE Spectrum, Vol. 11,No. 3, Feb. 1974, pp. 42-43.

Jones, W. E., A Microprocessor-Based Input/Output Systemfor an Interactive Computer, Special Report ISU-CL-7503,Cyclone Computer Lab., Iowa State University, Ames, Iowa,1976.

Laliotis, T. A., "Main Memory Technology," Computer, Vol.6, No. 9, Sept. 1973, pp. 21-27.

Organick, E. I., Proc. AFIPS Workshop Influence ofProgram-ming Languages on Computer Systems Architecture, AFIPSPress, Montvale, N.J., 1971.

Rice, R., "The Hardware Implementation of SYMBOL,"Digest ofPapers Compcon 72, pp. 27-29.

Rice, R., "A Project Overview," DigestofPapers Compcon 72,pp. 17-20.

Richards, H., Jr., Controlled Information Sharing in theSYMBOL-2R Computer System, Special Report ISU-CL-7601,Cyclone Computer Lab., Iowa State University, Ames, Iowa,1976.

Smith, C. L., C. T. Wright, and R. J. Zingg, "Problems in thePush-Down Stack Approach to the Implementation of HighLevel Languages," Digest ofPapers Compcon 76 Spring, pp.96-98.*Zingg, R. J., and H. Richards, Jr., "Operational ExperienceWith SYMBOL," Digest ofPapers Compcon 72, pp. 31-35.

These digests and proceedings are available from the Order Desk, IEEEComputer Society, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720.

David R. DitzeI is a member of the technicalstaff at Bell Laboratories' ComputingScience Research Center in Murray Hill,New Jersey. His current research actjyitiesinclude computer architecture, instructionset analysis, VLSI, computer-aided 4esigntools, and personal computing systems. HehaBS in eectrical engineering and a BS incomputer science from Iowa State Univer-sity, where he participated in the Symbol

project for four years. In 1979, he received an MS in computerscience frotn the University of California, Berkeley. Ditzel is amember ofTau Beta Pi, Eta Kappa Nu, Phi Beta Kappa, Phi Kap-pa Phi, ACM, and the IEEE.

COMPUTER66