The development of this timesharing system led to insights onmicroprogrammable organization, instruction sets, reliability,

and software and firmware development tools.

The Maxc SystemsEdward R. Fiala

Xerox Palo Alto Research Center

The process of developing a computer systemis not only inherently interesting; it also leads tosignificant organization concepts that the buildersare often impelled to share with others. So it wasin our development of the Maxcl and Maxc2 time-sharing systems at the Xerox Palo Alto ResearchCenter between 1971 and 1977. From this develop-ment came some ideas of system organizationthat are now seen to have contributed to thesuccess of the effort:

The high availability achieved is attributable tothe simple microprogrammable organization ofthe machines.

Microprogramming organization promotes sim-plicity by placing much of the complexity infirmware.This organization of a computer provides theenvironment for multiple instruction sets.

Causes of failure in integrated circuitry wereevenly distributed, but memory error correctionwas found to be important to overall reliability.

Tools for software and firmware developmentand design automation are necessary for efficientdevelopment.

The Maxcl and Maxc2 systems

The Maxcl system was designed and completedduring the period from February 1971 to April1973. Maxc2 was designed during 1973, shelved

for two years, then finally built and debuggedbetween June 1975 and April 1977. Despite beinga one-of-a-kind system, Maxcl has been one ofthe most consistently available systems on theARPA network since 1974. We attribute this highavailability to the system's simple microprogram-mable hardware organization and input/outputstructure.Maxc is a medium-scale computer designed

to run the Tenex timesharing system' and Interlisplanguage2 developed by Bolt, Beranek, and New-man for ARPA. Tenex was developed on a DECKA10 processor3.4 modified by a large paging boxdesigned by BBN. Our principal reasons for choos-ing Tenex were to acquire Interlisp for artificialintelligence research and to connect to the ARPAnetwork56 so that the PARC staff could be partof the research community sponsored by ARPA.The overall mainframe organization of Maxcl

is shown in Figure 1 and discussed in the relatedbox. High-speed operation was not a major designobjective for the Maxc systems. For significantlyhigher performance, the slow access time of MOSmain storage would have to be bypassed by somecache or instruction prefetching scheme. Themethods considered were sufficiently complicatedto discourage us from pursuing them.For PDP-10 emulation Maxc2 achieves an overall

power (including- swapping delays and storageaccess time) about 20 percent greater than aKA10, 20 percent less than a KI10, or 40 percentless than a KL10 with similar memory and I/Ogear. These comparisons ignore the special advan-

0018-9162/78/0500-0057$00.75 ` 1978 IEEE 57May 1978

COMPUTER58

tage of Maxc for running the Interlisp system(discussed later) and are based upon the perform-ance reported by Bell et al.4 A comparison basedonly upon CPU speed would show a factor of aboutfour difference between the KAIO and KL10.A number of other computer systems7-14 are

based on microprogrammable processors similarin various ways to Maxc. Peuto and Shustek,15Hollaar,16 and Smith"7 discuss ideas that are alsoof interest. The BCC-500 system, developed bythe Berkeley Computer Corporation and now at theUniversity of Hawaii (nothing published), is alsosimilar. Another system that emulates the PDP-10instruction set is the Superfoonly system at theStanford Artificial Intelligence Laboratory (nopublished references on Superfoonly architecture).

Microprogrammable processorcharacteristics

The Maxc microprogrammable processor layout,shown in Figure 2, is largely general purpose withlight specialization for the Tenex virtual memoryand PDP-10 instruction decoding. PDP-10 special-ization consists of (1) a function for setting theoverflow, carryO, and carryl bits in the flagregister for arithmetic; (2) two special bus destina-tions that route instructions and indirect wordsinto registers; and (3) a bus destination and bussource to manipulate byte pointers. Tenex virtualmemory specialization consists of (1) the 1024 x18 MAP memory, which contains execute, read,and write permission bits and the absolute address

Hardware Parameters of the Maxc Systems

Main storage 393,216-word x 48-bit, 800-nsec access

Secondary storage Eight Century Data Systems2314-equivalent disk driveswith 3M disk packs

Input/Output Controlled by Data GeneralNova 800 minicomputer

Technology The microprocessor is com-posed of TTL IC's with asprinkling of Schottky in time-critical places. PC boards areused for the instruction mem-ory, main storage, and ALUsections. Wirewrap is usedelsewhere.

Cycle time 200 nsec/microinstructionWord size 36 bits (memory words also

have four tag bits)Microstore 2048 words x 72 bits RAMInstruction rate 9 to 10 cycles/simple PDP-10

instruction

Maxc2 is similar, but has a cycle time of 150nsec, twice as much microstore, and one of ourAlto minicomputers to control peripherals. Thememory and disk control sections are identical.The Maxc2 microprocessor, about 25-percentdifferent from Maxcl, uses denser storage IC's toprovide twice as much microstore; the bus struc-ture was significantly modified to increase speed.Maxc2 is not connected to the ARPA network andis accessed from Alto minicomputers within PARC.MOS main-memory words contain 36 data bits

and 7 bits for error correction/detection (5 otherbits unused). The memory routes requests fromfour independent ports into independent memoryquadrants. Both the microprocessor and controlcomputer treat memory as an input/output device.The microprocessor uses one port exclusively for

disk traffic and another for interpreting instruc-tions.The control computer (Nova on Maxcl, Alto on

Maxc2) appears in two roles. It has completecontrol over the processor and memory, includingpowering up and down and changing memoryinterleaving and error correction. It is used to load,start, and debug microprograms and to trouble-shoot hardware problems. Under Tenex, it runsinput/output drivers for all system peripherals(except the disks) as a slave to Tenex; communi-cation takes place through main memory using anancillary hardware signal in each direction toinitiate communication. When a fatal error occurs,such as a double memory error or microprocessorhalt, it again becomes the master and takes appro-priate action.To give some idea of machine size, here is the

approximate IC count for various sections of themain frame:SectionMicrostoreInternal memoriesALUDisk controlOther micropro-cessorMemory port393,216x48 storageControl computer

1/0processormemory

Maxcl Maxc2832 480312 224300 300260 + 60/unit 260 + 60/unit850 850

720 72018,500 18,500Nova Alto

191274

1,408It is clear that the major part of the system and

its construction costs was in the memory. How-ever, an equivalent system designed today wouldbenefit from 16K x 1 MOS RAMs for main storageand other new parts provided by the semiconduc-tor manufacturers.

May 1978 59

Arithmetic/Logic Unit Skbk 52x3

(instruction) Stc,e_

Control X

KMR e2

COMPUTER60

for each 512-word page in the virtual memory;(2) a collection of functions that read, write, orread-modify-write the virtual memory, makingvarious access checks in the MAP.Several aspects of the microprogrammable pro-

cessor design in Figure 2 may be of generalinterest. First, the input multiplexing to the P-register allows cycling the 72-bit value in P and Qby any amount between -3 and +39. The 36-bitcycler output can then be masked by a right-justified mask before loading this result into theP-register. The cycler/masker was not present inearly design iterations, and most tightly micro-programmed loops disappeared when it was added.The cycler/masker is used widely throughout sys-tem microcode.The second aspect of general interest is the way

instruction decoding is carried out. A PDP-10instruction in the MDR (memory data register)is first split so that the opcode, index field, ACfield, and indirect bit wind up in registers. Thenthe D (dispatch) memory is addressed by theopcode and three 12-bit microaddresses read fromD are pushed onto the stack ('simulated calls').The main loop of the emulator then "returns" toeach of the microaddresses on the stack to emulatethe instruction.This three-microaddress technique is particularly

appropriate for PDP-10 emulation, because thePDP-10 instruction set is divided into familieswhose members are typically characterized inseveral different ways. These include ways ofobtaining arguments (from memory or immediate),common actions performed by all members (e.g.,move, compare, test, add, subtract, or multiply),and several ways of disposing of the result (e.g., toAC or memory, or both AC and memory). Thus,the three microaddresses indicate one routine forsetting up arguments, one for doing the work,and one for disposing of the result. Consequently,families require very little microcode. For exam-ple, the family of 64 test-and-set opcodes is imple-mented by only 8 microinstructions.Our Maxc machines use fairly wide microinstruc-

tions (72 bits), as shown in Figure 3, so that manysections of the processor can be controlled in parallelby microprograms. Several observations aboutmicroinstruction decoding are worth making.

First, it is frequently worthwhile to encodemicroinstructions tightly. On Maxcl about 27 per-cent of the processor IC's are in the microstore;on Maxc2 about 18 percent. There is a tradeoffbetween microinstruction bits and decoding logic,and designets should make this tradeoff carefully.

Maxc microinstructions are not very tightlycoded-a paper study showed that afl of the powerof the machine could have been obtained with54-bit microinstructions and a little more decodinglogic. Frieder and Miller"8 also discuss encoding inthe setting of two-level interpretation.Another valuable technique is having several

ways to encode common actions. On Maxc thereare four microinstruction fields, bus source (BS),bus destination (BD), function 1 (Fl) and function2 (F2), that can loosely be called "function" fields;these control activities outside the ALU sectionof the microprocessor. The most common bussources are encoded in BS, most common busdestinations in BD, and practically everythingelse in Fl. Fl also duplicates common BD andBS encodings to allow several sources to be OR'edon the (open-collector, low true) bus or severaldesinations to be loaded; F2 duplicates common Flcodes and implements several other functions usedin conjunction with Fl. In this way, if one wantsto do two things at once in an instruction, it isnearly always possible to encode them.

A few opinions about machine features

Hardware capabilities can be divided into severalcategories:

1. Input/output operations absolutely requiredto carry out some task.

2. Functions generally useful in a wide varietyof ways, not aimed at any particular application.3. Special-purpose capabilities provided toshorten particular time-critical tasks for specificapplications.4. Features of marginal usefulness that "fellout" of the hardware design.5. Facilities for hardware checkout or mainte-nance.

Category 4 features should be avoided, sincethey create compatibility problems on later ver-sions of the same machine. For example, thePDP-10 has over 50 absolutely redundant opcodesand 50 more that are rarely used, probably falloutfrom an early PDP-6 implementation. However,every subsequent PDP-10 has had to stay com-patible, and diagnostics have to check these op-codes. IBM has also had trouble with not usefulfeatures and strange, seemingly unimportant sideeffects in its 1401 and 360 designs. As a result,

Figure 3. The Maxc microinstruction is fairly wide (72 bits), permitting many sections of the processor to be controlled inparallel. Different opcode fields are related to different processor functions.

May 1978 61

different machines in the same family and sub-sequent machines that are compatible throughmicroprogramming are needlessly complicated andslow.The proper treatment of category 4 features 'is

to purge them from software and documentationas early as possible and from the hardware, ifit does not cost much.There is a corollary to this argument also. Oper-

ations useful and inexpensive in the current hard-ware environment, but expensive in likely futurehardware environments should be avoided. De-signers should weigh current utility against com-patibility problems in future implementations.Many areas with complicated logic inside the

Maxc processor have caused few difficulties ineither initial checkout or subsequent maintenancebecause a few lines of diagnostic program realis-tically check them out and pinpoint failures. How-ever, two time-consuming checkout problems weredisk transfers (including interrupt system) andmultiport memory competition. The long logicpaths in these sections mean that diagnosticscannot pinpoint failures. Hardware features to helpcheckout these areas would have been useful.With regard toproperties of a microprogrammed

processor that make it perform quickly on somerange of tasks, the following generalizations areoffered: Most tasks have one or several "mainloops," the speed of which largely dominates theoverall system speed. Special-purpose features(category 3) are frequently required to make thesecritical routines go quickly. My opinion is that ageneral-purpose machine of the same complexitycannot approach the efficiency of a machine witha few such special features. On the other hand,general-purpose features such as the cycler/maskerdiscussed above art also useful. Thus, it seemsthat a practical machine should have both specialand general capabilities.

System availability

System availability is summarized in Table 1for the period from April 3, 1977 (when Maxc2was made available to users), to January 10, 1978.Failures of noncritical input/output devices suchas tape drives and IMP were not logged-thesedo not crash the timesharing system, and mostusers are never aware of such failures.We run each system until it crashes, then repairor bypass whatever failed and carry out orschedule preventive maintenance, if this seemsrequired.Each system has one extra disk drive normally

used for file system backup. When a disk drivefails, we switch it out of the file system and recon-figure. In some cases this results only in a shortservice interruption and the timesharing systemcontinues in the new configuration. Repairs todisk drives switched out of the file system and

Table 1. Reasons for failure are widely distributed(12 of the 13 port failures on Maxc2 were caused by asingle intermittent failure).

Reason for Downtime No. of occurrencesMaxcl Maxc2

Memory failures 4 2Port/connector failures 7 13Processor failures 7 1Disk failures 3 2Power supply failures 0 1Power/air conditioning failures 3 2I/O and control computer failures 4 5Software/firmware bugs 6 2Operator errors 2 4Undiagnosed failures 2 3Preventive maintenance 5 1Software/firmware development 3 5System reconfiguration 1 2

Total 47 43 in 283 days

to other peripherals are normally carried out whilerunning the timesharing system.The fact that all secondary-storage devices are

identical and interchangeable has undoubtedlycontributed to high system availability. It is ad-visable that other sites seek a simple storagearrangement also. Some sites use low access timedrum devices for swapping, but our experiencesuggests that additional disk drives or main stor-age modules provide a better enhancement ofsystem power because maintenance complicationsthat result from introducing an additional kindof peripheral are avoided.The most significant contributor to reliability

has been main-memory error correction. Duringthe first six months of operation, we replacedabout 12 failing lKxl MOS RAMs per month:this has gradually declined to about three failures amonth during the last three years. However,because of error correction, a negligible numberof these failures has caused crashes. Even if thefailure rate had been lower, protection againstintermittent and pattern-sensitive failures wouldfully justify error correction.When Tenex restarts, it runs a short memory-

diagnostic program that records areas affectedby bad storage IC's; Tenex does not use thesebad areas. Only when the amount of storageaffected becomes significant do we schedule down-time and replace bad IC's.The majority of processor IC failures are solid.

This is fortunate since it means that a problemcan be fixed and will not result in more crasheslater. However, when an intermittent failure doesoccur, it may cause reliability problems for a con-siderable time. In Table 1, for example, 12 of the13 port failures on Maxc2 were caused by a singleintermittent failure.Our experience operating the Maxc systems

has not suggested any low-cost method for signifi-

COMPUTER62

cantly improving availability or reducing operatingcosts. The table shows that reasons for downtimeare distributed fairly evenly over many causes,so no single improvement would be particularlysignificant. Perhaps applying memory error cor-rectiorn end to end, so that port as well as storagecomponents were guarded, would be better. Be-yond that, the operating system could be devel-oped so that more disk and memory failures donot cause system crashes.

Firmware characteristics

The original Maxc system emulated the PDP-10user mode instruction set. For supervisor mode,we implemented additional instructions to controldisks, priority interrupt system, and virtualmemory map, and to signal the control computer.In 1976 we added an additional instruction setspecially designed to support Interlisp. Table 2shows roughly how the microcode is dividedamong different uses.

Table 2. Some 2000 microinstructions implement theMaxc system, although 5000 more are used in thediagnostics.

Use Instruction Count

PDP-10 instruction set 744Interlisp instruction set 472Tenex Map 157Disk 228I/O instructions 237Priority interrupt system 107Other 93

Total 2038Diagnostics '5000

The microprogrammed hardware organizationgreatly simplified implementation of complicatedparts of the system. For example, the very com-plicated Tenex virtual-memory scheme was imple-mented efficiently with little special hardware-anon-microprogrammable organization, such as theBBN pager, would have required several hundredmore IC's. Also, disk control hardware was sim-plified because main memory transfers, headerchecking, preambles, postambles, and checksumsare all handled by firmware rather -than hardware.For floating-point instructions, the main advan-

tage of microprogrammed organization is flexi-bility. Correct implementation of floating point issufficiently obscure that it is hard to design ahardware floating-point unit correctly, but in ourmicroprogrammed machine this complexity is con-fined to the firmware, where it is much easier tochange.

May 1978

Diagnostic firmware on a microprogrammablemachine is simple and can generally pinpoint prob-lems more precisely than on a non-microprogram-mable machine. On Maxc a very small kernel ofworking hardware must be debugged with testsequences from the control cornputer. Thereafter,firmware diagnostics are used for testing andgenerally pinpoint failures to three or four IC's.The Maxc firmware contains redundant checks

that cause a halt when inconsistencies are detect-ed. These checks are inserted in places where noexecution time or space penalty is incurred. Also,a diagnostic instruction executed occasionally byTenex verifies by checksum that the microstoreand constants in other internal memories of theprocessor are correct and does a few other simpletests that checkout most of the processor hard-ware.

Finally, microprogrammed organization hasmade possible an additional instruction set calledByte Lisp into which Interlisp programs are com-piled. Concurrent use of multiple instruction setsis a powerful concept elaborated more fully below.

Systems with multiple instruction sets

The PDP-10 instruction set is a well-developed"classical" set with a huge repertoire of simpleinstructions for doing logic and arithmetic andmoving data from place to place. In addition, ithas a few more complicated instructions for deal-ing with special data types (floating-point numbersand pushdown stacks). However, if one compilesa high-level language program into the PDP-10instruction set, the result falls far short of whatis possible.

Classical instruction sets result in compiledprograms that are slower and larger than is easilyachieved by a special-purpose instruction set. Toillustrate, in the course of enhancing the MaxcInterlisp implementation, we identified five or sixkey places where programs were spending con-siderable time (function call and return, type test-ing, garbage collection, etc.). We added specialPDP-10 instructions to reduce the time spent inthese places. This resulted in about a 25-percentspeed improvement over the unmodified instruc-tion set. Special-purpose firmware of this sort hasfrequently been used on microprogrammablesystems'9-21.The Byte Lisp instruction set, based upon

Deutsch,22 uses the same virtual memory andregisters as the Tenex instruction set, but instruc-tions are 9-bit bytes rather than 36-bit words, andopcodes are specialized to operations staticallyfrequent in Interlisp programs.-2325 Byte Lisp com-freueninIntrlip 2325ms Lipcmpiled functions average 72 percent smaller and15 percent faster (on top of the 25 percent men-tioned above) than PDP-10 compiled functions.

63

Code size is more significant in Interlisp than intypical application programs. In a typical applica-tion program, program storage, if significant, isusually dominated by size of data objects beingmanipulated. In this kind of application, a classicalinstruction set works fine (perhaps modified byspecial microcode in some time-critical places).However, Interlisp is a large system into whichfeatures have been added continuously for aboutten years. The standard system has about 200,000words of PDP-10 compiled code (some systems aremuch larger), and the typical working set is aboutone-half PDP-10 compiled code. When compiledinstead into Byte Lisp, program disk storage isreduced by about 50 percent and working-set sizeof programs being executed by about 30 percent.Naturally, the performance comparison is differ-

ent on a machine like the PDP-10 with large 36-bitwords from what it would be on a machine thatused, say, 16-bit words. One would expect greaterspeed improvement and less size improvement onmachines with smaller word size. Byte Lisp is notan independent instruction set-Interlisp uses manyPDP-10-coded procedures, and some Byte Lispinstructions trap to PDP-10 coded subroutines forexecution. Because the other instruction set remainsavailable, Byte Lisp can concentrate on representingcompiled programs compactly without also havingto provide infrequently-used opcodes for unusualtypes of data manipulation.

In other words, Byte Lisp opcodes were chosenfor common operations in Interlisp compiled code-the goal was to represent compiled programs com-pactly. But the decision to execute an operation inmicrocode was governed by how much this wouldimprove performance. Thus, the inner loops of thegarbage collector were microprogrammed, sincethese consumed considerable CPU time, even thoughthey were statically infrequent in Interlisp. Con-versely, CONS, one of the three most commonoperations in Interlisp, was made an opcode becauseit occurred frequently in Interlisp compiled code;but CONS trapped to a PDP-10 procedure for exe-cution since microprogramming would not haveimproved performance much.Extra instruction sets such as Byte Lisp do not

require much additional microstore because theyshare support machinery with the classical instruc-tion set (e.g., the divide and multiply microcode isshared), and because the map, disk, priority inter-rupt, and I/O microcode do not have to be replicatedfor additional instruction sets. Because Byte Lispand PDP-10 instruction sets use a common virtualmemory and registers, the Tenex operating systemis almost unaffected by the existence of the extrainstruction set.The use of microprogramming to implement alter-

native instruction sets has been used on a numberof systems (e.g., 1401 compatibility on IBM 360),and the idea of instruction set specialization for ahigh-level language is also popular (e.g., Algolspecialization on Burroughs machines). However,the idea of cooperating, compatible instruction sets

is not generally appreciated, and this is the ideatha.t has been successful on Maxc.As a result of these experiences, it appears that

on a microprogrammed machine, the desired archi-tecture is a family of instruction sets sharing com-mon word size, common registers, and a commonvirtual-memory organization (which should be verylarge-262,144 words on Tenex is much too small).One of the instruction sets should incorporateoperations for input/output and other classical bit-manipulation operations. Other instruction setsshould be provided for principal compilers. Theseinstruction sets need not be self-sufficient, but cantrap to the general instruction set in situationswhere microprogramming does not offer muchadvantage.

Software tools for system development

Overall time required to design and build theMaxcl system and to get Tenex running on itsatisfactorily for users was about 26 months-12months to design the system, 8 months to debugthe hardware, and 3 (non-overlapping) months eachfor firmware and Tenex software; an additional 3months of software debugging were required aftersystem release before it was reliable. The softwareand firmware debugging actually took longer, butmost time overlapped hardware debugging. Itmight be more accurate to say that most firmwaredebugging time was spent debugging hardwareand most software debugging time was spent debug-ging the firmware. During the course of theMaxcl/2 development and other projects we havegradually developed a number of software tools thatspeed up the development cycle of systems suchas Maxc.To speed up hardware design, we have developed

design automation software to mechanize aspectsof creating and revising logic drawings, wire lists,etc. Our current software tools would substantiallyreduce the 12 months required for Maxcl hardwaredesign, if that were to be repeated today. Twoother design automation systems, SUDS and theS-1 design system, both at the Stanford ArtificialIntelligence Laboratory, are similar to the PARCsystem. Unfortunately, there are no publishedreferences on any of these systems.

In addition, we developed a machine-independentmicroassembler called Micro and a hardware/firm-ware debugging program called Midas. Other effortsalong this line are numerous.26-40 These softwaretools run on the control computer (Nova on Maxcl,Alto on Maxc2). The nature of the hardware inter-face used by the control computer is discussed inthe hardware box.

In bringing up a new hardware system quickly,it is essential to have substantial diagnostic soft-ware/firmware support as soon as possible. It isimpractical to launch into hardware debuggingwithout this support. There is a brief period between

COMPUTER64

the point when hardware design is complete and thetime when the first hardware assemblage is readyfor checkout. This period has been getting shorteras design and construction automation has progres-sed. Debugging delays are avoided by providing alarge%complement of debugging firmware/softwareduring this small time period.Micro is a cross-assembler that runs on an Alto

minicomputer. It is possible to define a naturalmicroassembly language for a wide range of ma-chines by means of memory, field, macro, andneutral definitions in the Micro language. We havesuccessfully used Micro to define assembly lan-guages for four different microprogrammablemachines.-Micro differs from conventional macroassemblers

in its unusual parsing algorithm and use of neutralsymbols and left-arrow clauses. Roughly speaking,the definition file for a particular machine consistsof memory definitions for each of the target mem-ories (S, D, R, L, and IM on Maxc), definitions ofvarious fields within memory words, and macro andneutral definitions that transform symbolic expres-sions into field stores in memory words.Neutral definitions are used to represent classes

of objects. For example, on Maxc the ALU opera-tions (defined by the P+Q, P-Q, etc. macros) are inthe class defined by the neutral "ALU;" bus destina-tions (X-, Y.-, etc.) are defined by the neutral"B-;" legal data paths are represented by macrossuch as "B-ALU."The following example shows how macros and

neutrals are used to assemble data for an instruc-tion memory word:XQ-P+Q, P-777777R, GOTO[XAC,G=11; *Typicalmicroinstruction

"X-P+Q" and "Pi-777777R" above are left-arrowclauses and GOTO is a macro. In expanding the"XS-P+Q" clause, Micro first parses "P+Q;"this is a single symbol because "+", "-", etc. areordinary symbol constituents without special mean-ing in Micro. Evaluating the "P+Q" macro storesthe code for "add" into the ALUF field of the micro-instruction and leaves behind the neutral "ALU."Then evaluating "X-" stores the code for load-Xinto the BD (bus destination) field of the microin-struction and leaves the neutral "B -." Finally,evaluating the macro "B-ALU" stores the code forbusS-ALU into the BS (bus source) field of themicroinstruction.Micro also contains an assortment of operations

for manipulating integers, controlling conditionalassembly, handling literals, and dealing with memoryaddresses. These are similar to features in conven-tional macroassemblers and are not discussed here.Midas is a largely machine-independent cross-

debugger used for hardware and firmware checkout.Because most of Midas is machine-independent, itcan be adapted to a new hardware system quickly.On the Maxc systems, Midas runs on the controlcomputer; versions of it exist for other micropro-grammable systems as well.

The machine-independent part of Midas containssoftware for displaying registers and memory words,for loading microprograms assembled by Micro, andfor driving register and memory tests with variousdata patterns. Most software for controlling stop,go, breakpoints, etc. is also machine-independent.An elaborate command file facility (really a program-ming language) is used to run diagnostic micro-programs and report failures. Most of the docu-mentation for Midas is also machine-independent.The machine-dependent part of Midas consists of

procedures to read-write registers and memories,to start and stop the hardware, and to symbolicallyprint registers, memories, and other signals readfrom the hardware.Midas displays the names and values of registers

and memories on the large Alto display, and usesthe keyboard and a pointing device called the"mouse" to enter new commands. The displayedvalues are automatically updated at breakpointsand other times when the state of the microproces-sor is modified.During the earliest stage of hardware debugging,

registers and memories in the processor and mem-ory system are read and written from Midas througha hardware interface to the target machine. A basickernel of processor hardware is debugged by thesetests from the control computer. When registersand memories can be read and written successfully,subsequent debugging is carried out by diagnosticmicroprograms that halt on detected errors. Theuser interface to diagnostic microprograms is provid-ed by Midas command files that control loading,display of interesting memory words, execution, andfailure reporting of the diagnostics.On Maxc a sequence of basic diagnostic micro-

programs tests registers, memories, and functionswith cycled ones and zeroes. These are supple-mented by random-number reliability tests forvarious sections of the microprogrammed processor.PDP-10 programs are used to test disk and mainstorage reliability. Main storage failures and about90 percent of processor failures are fixed withoutresorting to the use of a scope. Only disk controland port failures are troublesome.On another machine, to avoid checkout problems

with long logic paths, we have made about 2000internal processor signals available through multi-plexers. A simulator incorporated in Midas checksconsistency of these signals at each clock whilesingle-stepping through random microinstructions;this has been a helpful checkout aid. The StanfordAl S-1 project is also using multiplexers to helpwith checkout.The major problem in using these 2000 signals

is one of observation-a human cannot notice verymany of them at once, even if they appear on thedisplay. To alleviate this problem, the signals arearranged in symbolically named 16-bit units, andeach of the 16-bit units can be exploded into acomplete symbolic printout when desired. Commandfiles display the collection of signals in any hardwaresubsection.

May 19786 65

When running the simulator, current readout,readout at the previous clock, and signals detectedas being wrong are stored in separate tables insideMidas. The display can window any one of thesetables. The simulator reports inconsistent signalnames and the three tables can be looked at todiscover what isn't working.

Conclusions

The most important conclusion I have drawnfrom my experience with the Maxc projects is thata hardware system should be simple. Diagnosticfirmware/software must be thorough, and a "firm-ware/software overkill" position should be strivedfor with respect to hardware debugging and main-tenance. Hardware simplicity and diagnostic supportmust not be considered too narrowly-systemperipherals must also be included.Microprogrammable hardware organization con-

tributes to simplicity by moving complications outof the hardware and into the firmware, where theycan be checked out easily and, once checked out,will not be a source of future trouble.The use of a control computer has also been of

great value in developing and maintaining the Maxcsystems. It is an invaluable aid in debugging ortroubleshooting the microprogrammed processorkernel that must work before diagnostic firmwarecan start pinpointing failures.In addition, software tools should be developed

by design organizations. Design automation softwareis probably most important. The Micro and Midasprograms for firmware development and hardware/firmware checkout are two other valuable tools wehave developed.

Finally, microprogrammable hardware organiza-tion allows additional instruction sets and otherspecial-purpose microcode to be added at littleextra cost. This potential should be exploited byproviding a family of instruction sets, each tailoredto the requirements of a commonly used high-levellanguage. The instruction sets should use commonword size, common virtual memory, and commonregisters so that they can reside harmoniously in asingle operating system. -

Acknowledgement

The group that designed, built, and debuggedMaxcl/2 consisted of C. Thacker, B. Lampson,E. Fiala, E. McCreight, E. Taft, P. Heckel, L.Deutsch, H. Sturgis, C. Simonyi, R. Shoup, T.Strollo, L. Clark, and M. Overton.

References

1. D. G. Bobrow, J. D. Burchfiel, D. L. Murphy, andR. S. Tomlinson, "A Paged Time Sharing System forthe PDP-10," Proc. Third Symposium On OperatingSystems Principles, Stanford Univ., October 18-20,1971.

2. Warren Teitelman, Interlisp Reference Manual, XeroxPalo Alto Research Center, December 1975.

3. The PDP-10 Software Documentation Group, PDP-10Reference Handbook, Digital Equipment Corp.,Maynard, Massachusetts, 1971.

4. C. G. Bell, A. Kotok, T. N. Hastings, and R. Hill,"The Evolution of the DECsystem 10," CACM, Vol.21, No. 1, January 1978, pp. 44-63.

5. L. G. Roberts, "The ARPA Net," in Computer-Communication Networks, N. Abramson and F. Kuo(eds.), Prentice-Hall, Englewood Cliffs, New Jersey,1973.

6. L. G. Roberts, "Network Rationale: A 5-Year Reeval-uation," Digest of Papers, COMPCON 1973, p. 3-6.

7. J. L. Gilgoff, "Microprogramming the IBM System/360 model 60/62," IBM-TR-00.1139, May 1964.

8. C. R. Campbell, D. A. Neilson, et al., "Micro-program-ming the Spectra 70/35," Datamation, Vol. 12, No. 9,September 1966, pp. 64-67.

9. W. T. Wilner, "Design of the Burroughs B1700,"AFIPS Conf Proc., Vol. 41, 1972 Fall Joint ComputerConference, pp. 489-497.

10. P. Kornerup and B. D. Shriver, "An Overview of theMathilda System," SIGMICRO Newsletter, Vol. 5,No. 4, January 1975, pp. 25-53.

11. Lewis Gallenson, Alvin Cooperband, and Joel Gold-berg, "PRIM System: Overview," ISI/RR 77-58,March 1977.

12. Lewis (allenson, ,Joel Goldberg. and Alvin Cooper-band: "The PRIM System: An Alternative Archi-tecture For Emulator Development and Use," Proc.Tenth Annual Workshop on MicroprogrammingOctober 5-7, 1977, Niagara Falls, New York.

13. M. A. McCormack, T. T. Schansman, and K. K.Womack, "1401 Compatibility Feature on the IBMSystem/360 Model 30," CACM, Vol. 8, No. 12,December 1965, pp. 773-776.

14. Special Issue on Computer Architecture, CACM,Vol. 21, No. 1, January 1978.

15. B. L. Peuto and L. J. Shustek, "Current Issues inthe Architecture of Microprocessors," Computer,Vol. 10, No. 2, February 1977, pp. 20-25.

16. L. A. Hollaar, "A Programmably Loadable ControlStore for the Burroughs D-Machine," IEEE Com-puter Society Repository R74-309.

17. L. W. Smith, "Instruction Sequencing System,"IBM Technical Disclosure Bulletin, April 11, 1969,pp. 1496-1497.

COMPUTER66

18. Gideon Frieder and Jill Miller, "An Analysis of CodeDensity for the Two Level Programmable Controlof the Nanodata QM-1," Proc. Tenth Annual Work-shop on Microprogramming, Niagara Falls, NewYork, October 5-7, 1977, pp. 26-30.

19. R. Belgard, "A Generalized Virtual Memory Packagefor B1700 Interpreter Writers," SIGMICRO News-letter, Vol. 7, No. 4, December 1976, p. 31.

20. S. Habib, "Microprogrammed Enhancements toHigher Level Languages-An Overview," Proc. Sev-enth Annual Workshop on Microprogramming, PaloAlto, California, October 1974, pp. 80-84 (preprint).

21. F. R. Broca and R. E. Merwin, "Direct Micropro-grammed Execution of the Intermediate Text Froma High-level Language Compiler," Proc. ACM 1973Annual Conference, pp. 57-62.

22. L. Peter Deutsch, "A Lisp Machine With VeryCompact Programs," Proc. Third International JointConf on Artificial Intelligence, Stanford University,August 20-23, 1973.

23. R. Greenblatt, "The LISP Machine," MIT Report,1975.

24. R. Brody, "Tuning the Hardware via a High LevelLanguage (ALGOL)," AFIPS Conf Proc., Vol. 42,1973 National Computer Conference, p. 518.

25. T. R. Bashkow, A. Sassion, et al., "System Designof a Fortran Machine," IEEE Trans. on ElectronicComputers, EC Vol. 16, No. 4, September 1967,pp. 485-499.

26. R. C. Calhoun, "Diagnostics at the Microprogram-ming Level," Modern Data. Vol. 2, No. 5, May 1969,pp. 58-60.

27. J. M. Hemphill and S. A. Szygenda, "DerivingDesign Guidelines for Diagnosable Computer Sys-tems," Proc. First Annual Symposium on ComputerArchitecture, Gainesville, Florida, December 1973,pp. 131-135.

28. G. W. Karcher and J. Y. Hsu, "A Cross AssemblerImplemented on IBM 360 for Variably DefinedMicrocode," SIGMICRO Newsletter, Vol. 5, No. 3,October 1974, p. 89.

29. D. J. Dewitt, M. S. Schlansker, and D. E. Atkins,"A Microprogramming Language for the B-1726,"Preprints, Sixth Annual Workshop on Micropro-gramming, College Park, Maryland, September 1973,pp. 21-29.

30. R. H. Evans, L. H. Moffett, and R. E. Merwin,"Design of Assembly Level Language for HorizontalEncoded Microprogrammed Control Unit," Preprints,Seventh Annual Workshop on Microprogramming,'Palo Alto, California, October 1974, pp. 217-224.

31. G. L. M. Noguez, "Design of a MicroprogrammingLanguage," Preprints, Sixth Annual Workshop onMicroprogramming, College Park, Maryland, Sep-tember 1973, pp. 145-155.

32. P. W. Mallett and T. G. Lewis, "Approaches toDesign of High Level Languages for Microprogram-ming," Preprints, Seventh Annual Workshop onMicroprogramming, Palo Alto, California, October1974, pp. 66-73.

33. J. D. Atkins, "Paradigmatic Universal MicrocodeAssembler," Workshop on Microprogramming,Grenoble, France, June 1970.

34. W. T. Wilner, "Microprogramming Environment onThe Burroughs B 1700," Digest of Papers, COMPCON1972, San Francisco, September 1972.

35. M. Gasser, "An Interactive Debugger for Softwareand Firmware," Preprints, Sixth Annual Workshopon Microprogramming, College Park, Maryland,September 1973, p. 113-119.

36. W. G. Bouricius, "Procedure for Testing Micro-programs," Preprints, Seventh Annual Workshopon Microprogramming, Palo Alto, California, October1974, pp. 235-240.

37. B. C. Hodges and A. J. Edwards, "Support Soft-ware for Microprogram Development," SIGMICRONewsletter, Vol. 5, No. 4, January 1975, pp. 17-24.

38. C. Vickery, "Software Aids for Microprogram Devel-opment," Preprints, Seventh Annual Workshop onMicroprogramming, Palo Alto, California, October1974, pp. 208-211.

39. T. M. Whiteney, "A Test Procedure for Micro-programmed Systems," Preprints, Third AnnualWorkshop on Microprogramming, Buffalo, New York,October1970.

40: R. Gossler, "Development Systems for Microcom-puter Programming," Elektronik (Germany), Vol.26, No. 5, May 1977, pp. 36-43.

Edward R. Fiala has been a memberof the research staff at Xerox PaloAlto Research Center since 1971, whereIhis main interests have been in operat-ing systems and the development ofnew computers. From 1968 to 1970he was employed as a system program-mer by Bolt, Beranek and Newmanand by Berkeley Computer Corp. Amember of ACM, he received his

SM in electrical engineering from MIT in 1968.

May 1978 67