Designed and built 15 years ago with modest funding andSSI technology, the Symbol system demonstrated the feasibility

ofHLL direct hardware implementation.

ftmbd 001Rex RiceR2 Consulting

Reflection on the Symbol IIR computer a decade anda half after its inception suggests that we tried to incor-porate too many advanced features about 15 years toosoon. There is a strong temptation to measure the systemby today's standards, forgetting the state of computertechnology in 1966 when the design was committed. Toprovide the proper perspective for evaluating decisionsabout Symbol's architecture, a few words about the 1966environment follow.

The environment in 1966

Below are some of the considerations that dictatedSIIR design decisions.

(1) The semiconductor components available in 1966had several simple gates per package. A complex compo-nent in a DIP was a dual flip-flop.

(2) There were no semiconductor RAMs, ROMs,PROMs, EROMs, etc.

(3) There were no microprocessors, MSI, LSI, or VLSIcomponents.

(4) Microcoding, in its infancy, was not generally used.(5) There were no software computer design tools for

use in system development. The few tools developedhelped express the system in logic equations and in place-ment of the components on PCBs. No good simulators,emulators, test programs, or other aids were available.

(6) 12 x 14-inch PCBs were not available from ven-dors; the first Symbol boards were made in Fairchild'sR&D laboratory to prove they could be designed, placed,routed, and fabricated. Unfortunately, these early PCBs,delivered to Iowa State University, had a nasty habit ofgenerating microcracks. A second-generation set ofboards was not developed.

(7) Research budget limitations allowed the use of onevery small core memory and one very small head per trackdisk.

(8) Timesharing and business data-base processing offiles were developing; rather large and complex softwaresystems were running, and it was apparent that softwarecomplexity was a major problem.

(9) CRT terminals were mostly used by computer pro-fessionals as a system console. On-line application ter-minals, word processing, etc., were in their infancy.We decided that many items that could be coptrolled by

high-level-language operators would be left soft, becausewe could not yet adequately define the operators. We alsowanted to get hardware running and had a limited amountof engineering energy. Our intent was to run Symbol onreal commercial problems, analyze the operations forinefficiencies, and then define additional types of opera-tors. First, we wanted to observe general system opera-tion-particularly memory management and paging-todetermine bottlenecks and new higher-level operators. Thehandling of file sorts and library management is in thisclass. Second, we wanted to expand Symbol machine lan-guage hooks to permit the development of new (at thatpoint undefined) HLL operators. An example of thiswould be a new translator, which would compile a numberof different HLLs rather than the one specific language.Unfortunately, we'd just gotten the machine to a limpingstate when we turned it over to Iowa State University. Wenever had the opportunity to shake out the system.Many design decisions made at Fairchild were in the in-

terests of expediency, to get the first hardware running andgain experience. The designers were aware of many defi-cient items, which later showed up in operation at ISU. Theintention was to construct a new system known as Symbol11 (dropping the "R," which signified the research model).

0018-9162/81/0700-0049500.75 '3 1981 IEEEJuly 1981 49

The number II implies that both smaller and larger systemsusing the same principles could be developed. Unfortu-nately, this did not take place. It would be unfortunate ifthe design of future HLL systems is affected by inappropri-ate conclusions drawn solely from the SIIR language and itsISU hardware implementation. 1-6

General observations

The students at ISU who analyzed Symbol had little op-portunity to interact with its architects after the system wasdelivered,. Furthermore, the design and construction facili-ties developed at Fairchild following the Symbol projectwere not available at ISU. Many of the conclusions reachedby students analyzing the system related to difficulty in im-plementing changes. Of course, these conclusions werebased on the tools available to the students. Since the origi-nators had a different perspective on the ease of makingchanges and on implementing a new and improved Sym-boll it is appropriate to round out history by adding the de-signers' view to certain points made in the published paperson Symbol.

It will be unfortunate if a consensus on theease of implementing HLL operators and

their efficiency of execution is based on theprimitive SPL example that is available.

Several originators differ with the opinion that Symbollanguage was too high, believing rather that it was not highenough. We agree, in general, with the ISU conclusion thatmore hooks to machine operators were needed. However,the ISU comparison of Symbol with traditional machinesemphasizes details of Symbol such as source code compac-tion while ignoring the large operating systems normally re-

quired in standard computers-and the storage space andexecution cycle requirements that go with them. Thismisses the whole point of Symbol. Ignoring these massiveprogramming systems is the same as saying there is no soft-ware problem. Once again, it should be emphasized thatSymbol was an experimental system aimed at business dataprocessing end users, not at professional programmers

developing a variety of operating systems; The originatorsappreciate the work at ISU that led to suggestions on

hooks, efficiency improvement, and language expansion.

We hope to eventually incorporate that data into a futuredesign.

Reflections on implementing HLLs

Language expansibility. Many published commentshave been made about SPL, the Symbol ProgrammingLanguage, and the desirable features it lacks. We believethat the basic decision to separate the data file structureand data type identification from the program string andput them in the data base was and is correct. Once this

50

decision is made, a non-von Neumann memory system re-sults and a number of other consequences follow. Onecan implement such a system with extremely low-leveloperators, high-level operators, or a mixture; we chose toresearch the effectiveness of HLL operators. (Note the re-cent activity on data-driven systems.)

Given this data, file delineation separation, and auto-matic memory management, we developed a set of ma-chine-implemented operators and hooks that could beeasily assembled into HLL operators.7-10 An example ofthe machine-level instruction is the fetch-and-followmemory operator available to the hardware functionalunits. We proved conclusively to ourselves that any high-level set of operations that could be specified preciselycould be directly executed.Our intent was to program many applications, identify

and isolate common operations, and harden them on thenext version. We made a managerial decision to freeze im-plementation of the language at the SPL level in order toget the first hardware running. Among other items, weplanned to eventually include file library managementoperators and direct sort. We had already invented meth-ods to reduce the number of memory cycles necessary toaccess a random field. We were aware that business datasuch as payroll files have large numbers of identicalrecords and are special types of tree files. We did notproperly define operators to handle this useful case direct-ly. For the record, the originators left library file han-dling, page faulting, debugging, etc., soft in order togather data on what was important to implement in thenext hardware. The studies at ISU in this area providedmuch valuable data for use "next time."

It will be unfortunate if a consensus on the ease of im-plementing HLL operators and their efficiency of execu-tion is based on the primitive SPL example that isavailable.

Hardware expansibility. Symbol comprised a set offunctional modules, each of which performed specifictasks. The splits were made so that the CPU and the pro-posed small operating system were not interrupted to per-form housekeeping functions or control program prog-ress. Basically (even way back in 1966), we decided it wasmore efficient to provide infrequently used hardwarefunctional modules if they eased operating system re-quirements and/or gave efficient execution. In the 80s,this fundamental decision is even more appropriate.With only low-level integrated circuits available and

with only a single, centralized, small core memory, wechose not to put load-sharing duplicate functional units inthe system. We were well aware of this possibility andplanned for it in future systems. Our bus-oriented struc-ture and systems controls were naturals for duplication,load sharing, and/or graceful system degradation.Modern systems can have local semiconductor RAM

and microcontrol at each functional unit. The microcon-trol can be used in the field to include both corrections andnew operators. Both hardware and software systems needthis dynamism; an HLL machine is basically no different.Hardware is now cheap enough that extensive error

checking, error correction, and system diagnostics canand should be incorporated. We wanted them on SIIR but

COMPUTER

couldn't afford the space, power, and cost. This causedISU much grief.The next Symbol was planned to have back-end proces-

sors moved out to the disk heads and word processors andcommunications processors moved out front.

Translating other HLLs. It has often been stated thatthe SIIR translator "compiles" only SPL. The implica-tion is either that other languages cannot be effectivelyimplemented or that it is too difficult to design a flexibletranslator to compile several languages.' 1-14 The origina-tors planned to design and construct a later version of thetranslator that could implement additional HLL operatorsand would be flexible enough to allow compilation ofother high-level languages. The design did not appear dif-ficult to develop. Some commentators on Symbol are notaware of this and make the false assumption that all di-rectly implemented instructions must be frozen at hard-ware specification time. In fact, with modern hardware,the control of such a translator could be soft through mi-crocontrol and other means.The SIIR translator was implemented to get some hard-

ware running and evaluated. The SPL translator processwas so efficient and took such a small amount of systemtime that it was not deemed a worthwhile expenditure ofengineering talent to clean it up before operating the sys-tem. Further, translation was so fast that the source wascompletely retranslated as an interrupt on any source pro-gram change. This was preferable to requiring the operat-ing system to do tedious (but necessary) housekeeping tokeep track of the detail changes. This overt easing of soft-ware elsewhere is not emphasized by authors of papers onthis aspect of Symbol. The "amazing" speed of the Symboltranslator was the direct result ofa grammar designed to beeasy to parse plus the fact that virtual memory managementwas directly hardware implemented.The debugging problems encountered with the transla-

tor at ISU can be attributed to the poor documentationsupplied with the system and insufficient design effort atFairchild. The originators still believe that an inexpen-sive, fast, efficient, and seldom-used hardware transla-tor/compiler is superior to a software compiling system.Software compilers cause paging, occupy memory, takeexecution time, and frequently interrupt the CPU to useits processing capability while a vast number of users areon-line developing programs.

Error diagnostics certainly can and should be improvedover Symbol 11.5-6 In fact, due to lack of operating ex-perience and the desire to get something working, the firstSymbol's diagnostics were left to be developed in soft-ware. Unfortunately, this development was difficult be-cause of insufficient hooks.

Using modern design methods (CAD software) andVLSI (gate arrays, for example), hardware is relativelyeasy to implement. Further, modern architecture and mi-crocontrol (in RAMs) make HLL operator changes easyto design and document. The author disagrees with theconclusion that developing a mostly hardware-imple-mented operating system is more expensive and time-consuming thatn developing a traditional softwareoperating system. In both soft and hard systems the big-gest job is defining and precisely specifying what is

July 1981

desired. The key points are that certain operations in ahardware translator should be left soft and that ap-propriate hooks must be available to both the HLL andthe machine operation-level instructions.Data types and structures are functions of the files

established by the user, not functions of compiling. Infuture Symbol-like systems, multiple types of dynamic,execute-time file-access mapping techniques should beimplemented. This is a memory management and not atranslator/compile function. For example, a batch pro-cessing file should have a different indexing techniquethan an on-line, real-time inquiry file. Improved file-indexing systems are needed. In a Symbol-like system, in-dexing can be dynamically changed at execute time andneed not be bound at compile time.

Symbol code compactions. An analysis has beenpresented on the efficiency of code compaction in Sym-bol.12'14 The desire to get a system up and running, highcomponent costs, and the design effort involved led theoriginators to decide against squeezing codes on the firstsystem. We intended to analyze programs run and latermake decisions on redesign. There was far more concern

The originators still believe that aninexpensive, fast, efficient, and seldom-usedhardware translator/compiler is superior to a

software compiling system.

with reducing the normal massive operating system soft-ware than with the efficiency of a few hundred less-compact statements in a source program. The originatorssuspect that this analysis considered only a very small por-tion of the total software problem more or less in-dependently-the analysts missed the woods while look-ing at the leaves. The originators would have preferred acomparative analysis to total storage requirements ofSymbol and a 360/65 running the same multiple-user con-current business programs. The only program available tothe designers that compares total memory requirements isincluded in Table 1. Although the program run is trivial, itstill shows some interesting comparisons. With modernhardware, code compaction is feasible and could be in-cluded-if it is believed to be important.

Interrupt Jandling.15 The originators were aware thatthere would be problems of efficiency in handling inter-rupts. Here again, SIIR design was frozen and hardwarewas built to obtain on-line experience. The commentsmade in ISU studies on these efficiencies are very appro-priate. 10'16 Some specific deficiencies studied in SIIR areattributable to the fact that only two flip-flops were in apackage, making local memory extremely expensive.Consequently, its use was minimized. In today's environ-ment, this restriction is nonexistent. The SIIR designershad intended to store all necessary information on inter-rupts and to reaccess this data with a minimum number ofmemory cycles. The design deficiencies encountered were

51

due to the specific implementation, not direct HLL im-plementation. With modern hardware, it would be easy toleave certain controls soft while leaving most execution ofhigh-level operators hard. This would allow for adding in-structions or buried machine-level operators to clean upinterrupts as specific problems develop.

I/O and word processing.11'15 At the time Symbol IIwas designed, there were no semiconductor memories, noword processors, and very few on-line CRT terminals forend-user applications. Comments based on today's tech-noloy are appropriate for next-generation HLL systemsbut do not properly reflect the 1964-66 environment inwhich the design was committed.The original design premise was that the I/O processor

would enter data and programs from the outside worlddirectly into virtual memory, using no functional unitother than the memory manager. Similarly, output fromvirtual memory passed through this unit. We had limitedmanpower, expensive circuits, and no local memory. TheI/O processor was a nice place to do some output format-ting, so this was added. As the project developed, we in-cluded terminals for word processing and put some of thelogic in the terminal and used the I/O processor for an in-terface. Thus, our first try on the I/O processor resultedin a kludge. In retrospect, we should have separated ter-minal word processing into a function and output format-ting into another function. Our half-hearted attempt todesign the terminal word processor, coupled with our in-experience in this area, yielded an inadequate user inter-face. This weakness and a lack ofsome newHLL operatorsrequired ISU to write a significant (in Symbol terms) editor.

Table 1.Comparison summary of "powers of 2" run on Symbol IIR and an Itel

370 AS-5 (IBM 370.158).The problem generates a table oi the powers of 2 to 180 digits. It compares compilationof a standard operating system with an HLL machine. The CPU time for a considerableamount of multiplication is included. This problem does not exercise the Symbol file-accessing mechanism. Note the billing of 5141 times more main memory time, the useof 15.6 times greater CPU execution time, and the 5.39 factor in elapsed time and thesmall Symbol system software requirements.

ITEM SYMBOL IIR IBM 370 IBM/SIIR(ITEL AS-5) RATIO

CPU TIME .621 SECONDS 9.68 SECONDS 15.6

MAIN CORE TIME(BILLED) .41 (2K SECONDS) 2108 (2K SEC.) 5141

DIRECT ACCESSES 0 84 0

PAGES PRINTED 12 27 2.25

MAIN CORE(ASSIGNED) 1312 BYTES 42,528 BYTES 32.4

SYSTEM SOFTWARE "1024 BYTES \v27,000,000 26,367BYTES

STORAGE CYCLE 2500 NSEC 400 NSEC .16

CLOCK CYCLE 180 NSEC ? ?

ELAPSED TIME 23 SECONDS 124 SECONDS 5.39

RESIDENT SYSTEMSOFTWARE ''1024 BYTES v1,000,000 BYTES 100

Even with the software added at ISU, the terminal systemdoes not meet modern standards.

These deficiencies are specific to SIIR, not generic tothe implementation of an HLL. Hooks and microcodecontrol that allow expansions and additions would largelyremedy them. Many modern systems do the text editing

Logic was hardwired. The available circuitfamily had only dual AND/OR circuits or aquad inverter in a DIP. Hardware such asthis simply could not cope with variabledata and file formats for reasonable

numbers of packages.

and record formatting in local processors. Local proces-sors that incorporate a low-level Symbol-type "local" au-tomatic memory management and appropriate HLLoperators can provide flexible and useful word processors,text editors, and output report format generators. Their in-put to the system bus and output from it make the terminalsjust another HLL functional unit.

Memory management system. Symbol II memory man-agement can be improved. In light of today's technology,the bases for decisions made in 1966 seem distant. As men-tioned above, the only memory available that the projectcould afford was a small, slow core memory. Registers hadto be constructed from 14-pin DIPs with two flip-flops perpackage. Logic was hardwired. The available circuit familyhad only dual AND/OR circuits or a quad inverter in aDIP. Hardware such as this simply could not cope withvariable data and file formats for reasonable numbers ofpackages. Because of hardware costs, we decided not topack instructions, not to use packed data file formats, notto dynamically hardware pack pages, and to use only oneform of page indexing. In modern technology, the smallCAD-supported design effort required and low hardwarecosts remove these restrictions.The Symbol IIR system should not be judged too harshly

for its 1966 restrictions. The originators had the necessaryconcepts and were considering patent applications toalleviate many of -these shortcomings, which are notgeneric to direct implementation of HLLs. Table 1 il-lustrates the effectiveness of the particular implementa-tion, based on the only comparative run available fromISU. It shows a remarkable efficiency, even without theabove-mentioned improvements. The Symbol IIR couldpotentially run up to 32 terminals (although that manywere never implemented) on a shared, time-sliced basis.The example in Table 1 shows a total of 1024 bytes of sys-tem software (mostly for printout of hardware debug for-mats) to run this problem in that timesharing environment.The hardware-driven memory management system pre-

sented one of our most interesting design challenges.9"t'17We chose to directly implement alphanumeric, variablefield length data with variable file structures. By variablewe mean that any field, record, group, or file structurecan be dynamically varied at execute time. Early in theproject, we chose to separate all memory management

52COMPUTER52

from the user's application instruction stream and to ad-dress by name (i.e., tag); hence the name Symbol, forsymbolic addressing. One reason for this was to preventprogrammers from having the capability of addressingbeyond the program bounds of their job or inadvertentlyaddressing beyond their dynamically assigned virtualmemory spaces. The objective was to give novice pro-grammers free access to the language and virtual memorywithout risk of taking the system down. Further, we didnot wish to bind file formats at compile time or inhibit thecompression of fields and files by local processors at anytime. Stated simply, we separated program operationsand structure from data structure.

Next, we approached the problem of generating nametables and using them as symbolic access mechanisms.2'7We also had to tackle the problem of rapid access to thedata file structure to access the desired variable(s). Manyschemes were explored on paper and discarded. As Sym-bol II was delivered, we were still busy inventing improvedjump and rapid access techniques.A tree file structure was implemented for SIIR because

it was easily definable and, in the academic sense, coveredall possible cases. In retrospect, we should have givenmore attention to optimizing operations on files such asthose used in business data processing, where a file con-sists of a large number of records with identical formatsand where the variables are the lengths of data in eachfield and the number or records. We should have lookedat inquiry activity, where a large number of accesses movesmall amounts of data. Had these tasks been in mind, wewould have implemented a number of dynamically change-able memory access mechanisms to be applied as needed. Ihave recently spent many hours investigating different filestructures, fast access mechanisms, and relational database operations; it is clear that the memory access defi-ciencies identified in SIIR at ISU result solely from thespecific implementation.The proper size of words, groups, and pages was the

subject of extensive debate among members of the designteam. We considered a range of architectures, from thosehandling one byte at a time to those in which very largepages moved intact into and out of main memory. Al-though we didn't like hardware artifacts, we had to com-promise and use the available memory hardware and cir-cuit family for implementation. We settled on a 64-bitword, an eight-word group, and a 32-group page. We de-cided not to pack an eight-byte word with more than onefield, due to logical complexities in using available cir-cuits. For the same reason, we moved complete pages be-tween main memory and disk.We were pleased to have the studies done at ISU on the

efficiency of various page sizes. With modern hardwarethere is no problem in choosing dynamically variable pagesizes, My recent review of the many schemes consideredfor SIIR indicate that one should not move pages, butrather the specific packet that has been symbolically ad-dressed. Modern hardware and back-end functional unitscan make this approach effective.

Other architectures. Using the standard microcompo-nents available today (gate arrays, VLSI, etc.) the func-tional units in Symbol could each be contained on several

small printed circuit boards. The busing structure -databuses, control buses, interrupt buses, etc. - designed intoSymbol IIR permits multiples of existing or new units tobe added. It does not take much imagination to conceivenew and different HLL functional units to plug in.

For example, a Tandem-like system in which all unitsare duplicated (even many times) to provide load-sharingand continuous operation is quite reasonable. The HLLnature of the operators should make the load-sharing or

Imagination and inventiveness are the mainingredients needed to put HLL systems

into operation.

function replacement easy through a very small softoperating system. Of course, provisions must be made forcontinuous power, cooling, etc. Duplicate files, file ac-cess, and file maintenance can easily be accommodated.Another possibility is to provide multiple source

language to SPL translators. For example, a Cobolsource-to-SPL translator could be plugged in. It would beable to flush Cobol-organized data files into the Symbolsystem and make the appropriate format changes.Operated in reverse, it could produce Cobol data filesfrom the Symbol formats. Computation would be donewith HLL source.

Imagination and inventiveness are the main ingredientsneeded to put HLL systems in operation. There are nogeneric problems to inhibit or prohibit their use. Once oneseparates data delineation and definition from the in-struction stream and invents appropriate hardware dataaccess mechanisms, the rest will follow. We are alreadybeginning to see data-driven machines, and many systemsprovide special-purpose processors dedicated to specifictasks. We are only a step away from new generations ofdirect HLL implementations.

Our fondest desires

Due to early termination at Fairchild, we were unableto evaluate Symbol. The following lists what we wouldhave done, if only...

* We wish that we had been able to program, operate,and evaluate SIIR.

* We wish someone had programmed real businessdata processing jobs, say an airline reservationssystem or a business payroll file, in both SPL to runon Symbol and in Cobol to run on the 360-158 andthen compared the results.

* We wish we had been able to instrument Symbol IIRand a 360/65 to count total clock cycles, memorycycles, and memory occupied for a job run.

* We wish a group of novice programmers had pro-grammed business data processing jobs in SPL andin Cobol and then debugged their programs. Wewish we could have compared their experiences.

* We wish we could have incorporated improvementsand developed a commercially viable HLL machine.

July 1981 53

In retrospect, it is amazing that we were able to designand build Symbol, considering the small effort and dollarexpenditure and the low level of circuit integrationavailable. We are pleased with its performance on the pro-grams run.The effectiveness and ease ofHLL direct hardware im-

plementation should not be judged on the basis of thisresearch prototype machine whose specifications andhardware were firmed up in 1966. A new HL'L machine,with modern hardware and automatic hardware memorymanagement, should be designed and constructed. E

Acknowledgments

I wish to express my deepest gratitude to GordonMoore and Robert Noyce for their enthusiastic support ofthe Symbol program during development at the FairchildCamera and Instrument Research Division. Particularthanks to William Smith for his major contributions, in-vention, and effort, which helped make Symbol II a reali-ty. The Symbol II design and construction team at Fair-child provided enthusiastic and energetic support to theprogram; to its members go my most sincere thanks. RoyZingg at Iowa State University took an unproven andunreliable system and through insight, hard work, andperseverance brought it into operation. He then guidedstudents in evaluating it and in developing thesis material.Without him, Symbol would not have seen the light ofday. Finally, I thank the NSF for providing financial andmoral support, which allowed Iowa State to bring Symbolto an operating state and then made it possible forstudents to evaluate it.

References

1. R. Rice and W. R. Smith, "SYMBOL-A Major Depar-ture from Classic Software Dominated von NeumannComputing System," AFIPS Conf. Proc., 1971 SJCC,Vol. 38, 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, "ThePhysical 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, Vol. 40, pp.359-368.

6. D. R. Ditzel, "High Level Language Debugging Tools onthe SYMBOL Computer Systems," Proc. 1980 WorkshopHigh-Level Language Computer A rchitecture.

7. H. Richards, Jr., "SYMBOL IIR Programming LanguageReference Manual," Report ISU-CCL-7301, CycloneComputer Laboratory, Iowa State University, Ames,Iowa, 1973. NTIS accession number PB-221 378.

8. H. Richards, Jr., and C. Wright, "Introduction to theSYMBOL-2R Programming Language," Proc. Symp.High-Level-Language Computer Architecture, ACM,New York, 1973. NTIS accession number PB-228 115/AS.

9. R. J. Zingg and H. Richards, Jr., "SYMBOL: A SystemTailored to the Structure of Data," Proc. Nat'l ElectronicsConf. 1972, pp. 306-311. NTIS accession number PB-221286.

10. H. Richards, Jr., and A. E. Oldehoeft, "Hardware-Software Interactions in SYMBOL-2R's Operating Sys-tem," Proc. 2nd Ann. Symp. Computer Architecture,1975, pp. 113-118. NTIS accession number PB-239220/AS.*

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

12. G. J. Myers, Advances in Computer Architecture, JohnWiley & Sons, Somerset, N.J., 1978.

13. J. W. Anderberg, "Source Program Analysis and ObjectString Generation Algorithms and Their Implementationin the SYMBOL 2R Translator," Report NSF-OCA-GJ33097-CL7410, Cyclone Computer Laboratory, IowaState University, Ames, Iowa, 1974. NTIS accessionnumber PB-230 614/AS.

14. D. R. Ditzel and W. A. Kwinn, "Reflections on a HighLevel Language Computer System, or Parting Thoughtson the SYMBOL Project," Proc. 1980 Workshop High-Level Language Computer Architecture.

15. W. R. Smith, "System Supervisor Algorithms for theSYMBOL Computer," Digest ofPapers, COMPCON 72,pp. 21-26.*

16. D. R. Ditzel, "Reflections on the High-Level LanguageSymbol Computer System," Computer, Vol. 14, No. 7,July 1981, pp. 55-66.

17. H. Richards, Jr., and R. J. Zingg, "The Logical Structureof the Memory Resource in the SYMBOL-2R Computer,"Proc. Symp. High-Level-Language Computer Architec-ture, ACM, New York, 1973.

*These proceedings available from the Order Desk, IEEE ComputerSociety, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720.

Rex Rice, an independent consulting engi-neer specializing in digital systems, has beenactively engaged in the computing field since1949. He has published over 50 papers andholds more than 20 computer patents. He isbest known for his work at Fairdhild: inven-tion of the dual in-line package; manage-ment of the first large silicon memory pro-gram, the Illiac IV main memory; and early

4: perception of work in bus-oriented, func-tionally split array logic systems. The Symbol computer which heconceived and the program which he managed (1966-70) to devel-op it have provided the most sophisticated direct implementationof a high-level language in hardware presently in existence. Manyof its features are just now appearing in new systems.

Rice, who received his BA in mechanical engineering at Stan-ford in 1940, has taught graduate computer courses at USC. He isan IEEE fellow, a member of the Computer Society GoverningBoard, and the founder of Compcon.

COMPUTER54