A Brief History of the Rice Computer

Adam Thornton


The Rice Institute Computer under Construction: Console typewriter, Register light Panel, and Control Unit, October 23, 1959. Photograph courtesy of Sigsby Rusk.

Funding for this project has been provided by the Rice Undergraduate Scholars Program. Joel Cyprus was the faculty advisor.


Back to my home page.


Some of the major figures in the Rice Computer Project, October 23, 1959. Photograph courtesy of Sigsby Rusk.

Historical Overview

Pressures and Goals

There were two major purposes in designing the Rice machine. The first was to provide a platform on which members of the Rice community could do research that would have been impossibly time-consuming without access to a computer. This was, in fact, the major reason that the project was started: Zevi Salsburg wanted a machine as powerful as Los Alamos's MANIAC II to simulate fluid flow. He did not, however, have any desire to move to Los Alamos, and therefore needed a computer to be built at Rice.

The other goal of the machine was to do research into how computers should be built. In the years following John von Neumann's death, the Atomic Energy Commission became quite interested in funding computer research: Salsburg's request came at a time when the AEC's goals could be better met by funding the development of a new system than by offering to build a copy of MANIAC II or to buy a stock IBM computer.


Towards the end of 1956, Zevi Salsburg, John Kilpatrick, and Larry Biedenharn, all Rice professors, decided they needed a computer "like the one at Los Alamos."[1] The Atomic Energy Commission, to whom they applied for funding, told the three that, if they could procure an engineer, grant money for a computer's development would be forthcoming. Martin Graham, who had been working at Brookhaven National Laboratory and had done the transformer coupling for Los Alamos's MANIAC II, was invited down to Houston in February of 1957, and became an associate professor in the electrical engineering department at Rice University.

Graham designed the hardware of the Rice Computer, and most of his plans were implemented by Joe Bighorse, the project's head technician. "Joe Bighorse," claimed Graham, "is the best technician I ever had work for me. Anywhere."[2] The combination of a skilled engineer and an excellent technician--as well a Rice alumnus's donation of the use of his tool and die shop for the machining of the computer--produced an extremely well-engineered machine at all levels of design. Since Rice was getting custom machining, the physical layout was designed to hardware requirements rather than having hardware made to fit off-the-shelf structural components. Construction on the machine proceeded from 1958-1961. A copy of the machine was also built at the University of Oklahoma.

Parts of the machine began functioning in 1959, and the computer finally became fully operational in 1961. While not the first computer on campus--a Litton LGP-30 shared by the Mechanical Engineering and Chemical Engineering departments was in use in 1957[3]--it quickly became Rice's primary computer and remained in that role until supplanted by an IBM 7040, followed by a Burroughs B5500, in the late 1960's[4]. Graham took a year-long sabbatical at the University of California at Berkeley in 1964; when he returned in 1965, he ran afoul of departmental politics and the Dean of the School of Engineering[5], and returned to Berkeley on a permanent basis in 1966. Sigsby Rusk assumed the leadership of the Computer Project. Most of the graduate students who had helped with the construction of the machine, such as Ted Schutz, Joel Cyprus, Phil Deck, and Dwayne Chesnut, had left by 1964, and Joe Bighorse departed shortly after Graham.

The R1 was decommissioned in 1971 when the cost of maintaining and powering it had become prohibitively expensive for the limited amount of computation it was able to provide. The R1 was initially named "The Rice Institute Computer" and then became "The Rice University Computer". It acquired the "R1" moniker when it was being used in the design of the Rice Research Computer, a tagged-architecture ECL machine modeled on John Iliffe's Basic Language Machine[6]. Presumably "R2" was a convenient designation for the Rice Research Computer, as Rice's second machine, and "R1" was thus coined as the obvious label for Rice's first computer.

Funding For the Rice Computer

A three-year AEC grant of $250,000 was forthcoming for machine development, supplemented by a five-year Shell Oil grant for $150,000. At some point before 1964, the NSF took over control of funding the project from the AEC: SPIREL and the AP1 assembler were developed with NSF funds. By 1968, external funding for the R1 had essentially ceased.

Evolutionary History of the Rice Computer

The R1 had its architectural roots in the Brookhaven computer and in Los Alamos's MANIAC II, both tagged-architecture machines. Graham had worked closely with the MANIAC II, and it served as the model for many of the R1's features. However, while the Los Alamos computer had 48-bit words and 24-bit instructions, the circuitry necessary to decode two instructions per word was complex, and 24-bit instruction words were seen as too limiting; thus, a 56-bit word with one instruction per word was chosen.

The indirect addressing modes were designed into the machine at the request of John Kilpatrick. He was influenced, in turn, by IBM's advertising for its 709 line of machines, which touted indirect addressing as its major new feature. However, the Rice machine delivered far more powerful indirect addressing modes than IBM's product.[7]

Shell, as part of the funding agreement, had the right to know what the R1 project was doing, whether or not the results were ever published. Bob Barton, the head of Shell's research division left for Burroughs in the early `60's; it is probably not coincidental that the architecture of the Burroughs B5000--designed by Barton--closely resembles the Rice Computer[8,9]. In fact its "descriptor" addressing is very nearly the same as the R1's codeword scheme[10], and the use of tag bits was similar in each machine.

The codeword was the lasting legacy of the Rice machine; it became the basis for capability-based protection, which appeared in Iliffe's Basic Language Machine. The segmentation that codewords allowed was a major factor in the development of the CTS system, one of the earliest multiprogramming environments. While the R1 did not have much direct evolutionary influence on the history of computer design, its large register set (for the time), its indirect addressing capability, and its use of codewords all had significant influence on subsequent generations of computers.


Physical Configuration


The Rice University Computer was designed as a 54-bit vacuum tube machine capable of addressing a maximum of 32,768 words of main memory[11]. The word length was actually sixty-three bits: in addition to fifty-four bits of data, there were two tag bits and seven bits of Hamming error-correction code. Memory was initially implemented in CRT storage tubes, which could each store 8192 bits. Thus each tube represented a one-bit wide slice of the total memory. 63 bits of memory and a diagnostic CRT exactly filled a square 8x8 frame[12].

Control information and program input for the machine took place through a paper tape reader and through the console switches and console typewriter. The paper tape was prepared offline on a Frieden Flexowriter. Output could be routed to a line printer, a paper tape punch, or the console typewriter. Two magnetic tape units were available early in the project; later, two more tape units and a limited disk subsystem were attached[13]. Additional devices were added by and for various users throughout the machine's lifespan.


The nucleus technology for the computer consisted of vacuum tube triodes, although almost all circuitry added to the machine after 1963 or so was emitter-coupled (ECL) transistor-based logic. The most innovative part of the R1's electronic design was its unusual single-sided gate, which had two advantages: first, since it was single-sided, a new function could be added simply by adding a diode at half the circuitry cost of adding functionality for a typical double-sided design. Second, converting from output to input levels had been a difficult problem: inputs had to be in the range of 10V, and output was typically around 150V; both level conversion and the problem of maintaining a consistent ground voltage proved difficult. Graham had solved the problem at Los Alamos National Labs by realizing that the signals were pulses, and thus amenable to AC techniques. Hence, a 15-to-1 winding on a pulse transformer would translate output to input levels, and give a floating voltage differential with no grounding problems. With a single-sided gate, all that had to be done was to put a prewound 30-turn winding onto the new function as the primary, and add a two-turn winding when wiring the new circuit into place.


Single Sided Gate Circuit. Rice, 1958, Appendix A


Circuit used to connect multiple input gates B[1-4]. Rice, 1958, Appendix A.

The Rice computer ran at a logic speed of approximately 1 MHz.[14] The basic design was asynchronous: the machine signaled that an operation had completed by setting an internal voltage. For example, the adder had one capacitor per stage; since capacitor current is the derivative of voltage with respect to time, when the voltage levels in the adder had stabilized, no current would come through the capacitor bank, and a flag would be raised signifying that the machine had finished with the addition and carry[15].


The initial memory configuration consisted of 63 Radechon CRT tubes forming an array of 8192 memory words[16]. A bit was stored by applying a charge to a region of the tube, and detected by circuitry at the tube's target; mica target tubes were used, rather than the sapphire target that allowed a greater bit density but at a much higher price and with lesser reliability. One curious feature of the memory design was that the bits were laid out in a cross, rather than in a square, on the circular face of the tube; the cross, while requiring more complex address decoding, wasted less area.

The memory was structured in an 8x8 array of tubes providing 63 memory tubes and a display CRT. The 64th tube was used for debugging the other tubes: when memory errors began to accumulate, test leads could be clipped to the offending tube and a picture of its bit pattern would appear on the display tube. Memory access time was on the order of ten microseconds, and a write to memory took twenty microseconds[17].

The memory was surprisingly reliable, although its quality did drop off radically as it aged. The only major problem reported with the tubes during the early years of the project was one in which no bits from a certain tube could be read. Examination of the tube with the diagnostic leads revealed that the bit pattern had shrunk significantly from its proper size. Upon examination, the problem was traced to a faulty resistor: the voltage divider on the accelerator had burned out, raising the acceleration voltage from 15 kV to 20 kV and thereby decreasing the electron deflection radius.[18]

Since reading a bit from the tube target is slightly destructive, tight loops could cause read-around errors, as bits that had previously been turned on would get weaker and weaker each time the nearby bits were read. The operations manual addresses this: "as a general safety rule one should not try to read one particular word more than 1000 times within one continuous 50 millisecond period."[19]

In 1966, an 8K bank of RCA core memory was added to the Rice computer; it had an access time of one microsecond and a cycle time of two microseconds. In 1967, 16K of Ampex core (1 microsecond cycle, 400 ns access) was added, bringing the machine to its full capacity of 32K words. Shortly thereafter, the original electrostatic memory was decommissioned, as it had become extremely error-prone due to its age.

Peripherals and I/O

The principal means of input to the Rice Computer was via a Frieden Flexowriter, punching seven-hole paper tape, which was then read by a paper tape reader attached to the machine. The character code was six bits, with the seventh reserved for control functions such as delete. The console typewriter could be used to enter a word directly into the instruction or S registers, and to display the contents of any fast register.

The R1 was designed with a line printer capable of 300 lines per minute. The printer used a six-bit character code and printed 108 characters per line. A print image was constructed by arranging 18 words per half-line in a continuous memory block and then issuing a "print left" or a "print right" instruction. A full line could be printed by arranging two 18-word blocks and then issuing a "print left (do not advance paper)" instruction and then a "print right" instruction[20].

The tape system of the R1 never functioned very reliably. While 4 tape drives were provided for, no more than two were generally working at any one time. Tape data was randomly accessible and its block format functioned something like a rudimentary file system: for example, the AP1 PLACER program was defined to exist at block 100.02 of the MT system tape[21]. The large hydraulically-actuated Bryant disk (which had mammoth 39-inch platters) was added in 1967 or 1968, but was even less reliable than the tape drives and was generally felt to be more trouble than it was worth[22]. Additional I/O was added to the machine more or less on an ad hoc basis: Sigsby Rusk designed an A/D converter in `62 or `63 from fast ECL logic, capable of 8-bit resolution at 100kHz, and wireframe animations of a sort were produced using a D/A converter to drive an oscilloscope, which was then photographed one frame at a time on a 16mm movie camera. The very flexible nature of the R1's instruction set made it easy to connect any of these peripherals to the system and add instructions to communicate with them.

Layout and Power Requirements

The Rice Computer occupied the south end of Abercrombie Lab's second floor, filling a square area about twenty-five feet by twenty-five feet[23]. The R1 itself consumed approximately 20 kilowatts of power[24], and the machine plus its associated peripherals and air conditioning drew roughly 100kW[25]. This was provided by a Navy surplus generator that delivered 120 volts AC at 400 Hz, using a significant amount of custom-built rectification hardware.

Machine Architecture

Basic Structure

The machine was designed to have fifty-four bit words and fifteen-bit addresses; full-length words would also have two tag bits, giving a maximum of four "types" indicated by tags. There were eight full-length (54 bits, expanded to 56 in 1966 or 1967)[26] registers and eight fifteen-bit address registers. The registers had an access time of 1 microsecond, making them an order of magnitude faster than the electrostatic storage. The machine also had a number of mode lights and switches. These were tri-state: they could be set to on, off, or neutral from the system console. In the neutral position, mode choice was under software control.

Register Allocation

The addresses were memory-mapped into addresses 0-7 of the machine. The "A-Series" full-length registers were laid out as follows:

A Series Register Memory Mapping
00Zero register (constant zero)
1UUniversal (math) register (55 bits--contained overflow bit)
2RRemainder (for math operations)
3SStorage (for math operations)
4-7T4-7Fast temporary storage

The Zero register was not really a register at all, but a quick way to get the constant zero. The U register was used in all math operations as the object acted upon, and would, after the operation was performed, contain the result. R was primarily used for intermediate calculation results, the remainder after a division, and the lower half of a product after multiplication; a general mechanism existed to use U and R together as a double-length register. S was used as the actor in all math operations: the subtrahend, the divisor, or the multiplier, for instance.[27]

The 16-bit[28] B registers, which were primarily used for indirect addressing, were as follows:

B-Series Register Memory Mapping
0CCControl (Program) Counter
7PF1Pathfinder (subroutine return) register 1

CC was used as the fifteen-bit location that told the program the absolute memory address being executed. Since this was a general-purpose register, relocatable code was made very easy, since the program "always [knew] where it [was]"[29] and the contents of CC could be examined and modified by the program. The B-registers could be individually specified in the instruction such that the program would fetch its instruction from (CC + Bx), which allowed for relocatable subroutines. On any transfer of control, the contents of CC would be put into PF1 and the contents of PF1 into PF2. This allowed hardware maintenance of the program execution stack and made shallowly nested subroutines very fast.

There were additionally the I (Instruction) 54-bit register, which held the instruction for decoding, the SL and ML (sense light and mode light) 15-bit registers, which contained the settings of console switches controlling machine operation, the 16-bit X (increment) register, which could be used as an addend to the B-registers, which was useful for indirect addressing), and PF2, the second pathfinder register, which, as described above, was to PF1 as PF1 was to CC.

The mode light register allowed the programmer to specify the mechanism by which rounding of numbers would take place, whether to trap to a specified address on encountering a tag, whether to repeat a single instruction indefinitely, and other control functions.


The Rice machine used a forty-eight bit mantissa and a six-bit exponent; the exponent was not a power of two, but rather a power of 256; this gave a greater range of allowable numbers at some cost in precision. The mantissa was defined to represent a number between (1 - 2-47) and zero. In that way, the absolute value of the number could lie between approximately 10-89 and 1074, with twelve decimal digits of precision.

Fixed point numbers followed the same format, but ignored the exponent and its sign, thus restricting the absolute value of the number to the range between (1 - 2-47) and zero, but allowing forty-eight, rather than forty, bits of precision.

Instruction Structure

[30] The instruction word was made of four fields. For our purposes, it is helpful to think of a 54-bit word as made up of 18 octal digits.

Instruction Word Structure
11Inflection on F
2F address
23Instruction class
4-7Four operation Triads
38Inflection on store
9Store address
410Inflection on Memory address
11-131 bit: Indirect Address bit
8 bits: B Modification of M
14-18Memory Address

While a brief description of the function of the various fields of the instruction word is given below, the full analysis of the instruction architecture is too long to be presented here. The Rice Computer was basically a microprogrammed machine: the instruction set was so rich and regular that each "instruction" could itself be programmed to some degree.[31] However, since each instruction had to access memory, which was very slow compared to the computer's cycle time, overall machine performance suffered.

Field 1

The F address was a Fast Register address (0-7), as seen above. Bit 1 of IF determined whether an A (0) or B (1) Register was to be loaded. The Inflection bits' meanings were the same as everywhere else they appeared: "00" meant no sign change, "01" meant to change the sign, "10" meant to take the absolute value, and "11" meant to take the negative of the absolute value. In this case these operations were performed on the contents of the F register before it went into U. If a 16-bit register was loaded into U, the right fifteen bits of U got the B-value, the next 38 bits were set to zero, and the sign bit was retained.

Field 2

The Instruction Class triad was interpreted as follows:

Instruction Class Triad
0Test or Transfer
2Fetch, Store, or Tag Operations
3Reserved for Future Use (never used)
4B-Register, Console Lights, and Special Register Operations, and Shifts
5Bitwise Logical Operations
6Input/Output Commands
7Special Functions (by 1964, Analog Input Commands)

The remainder of the field was 12 bits of instruction code. Their use varied wildly with the instruction class. For example, in Class 2 operations, if the first triad was 0, the contents of U were stored in the memory location pointed to in field 4. If it were 2, the memory location would get the contents of U added to the contents of S. Other values caused other operations to be performed.


This allowed further microprogramming of the instruction. Essentially, with no increase in instruction time, one could store either U or R in a register, or increment any of the B registers either by 1 or by the contents of the X register.

Field 4

Field 4 determined the address of a word to be brought to the S register and the final address to be loaded into the I register. The last 15 bits were a memory address; the remaining bits indicated whether to add CC, PF1, or any combination of B1-6 to that address; then either the contents of the resulting address or the address itself, modified by the inflection bits, would be loaded into S and, optionally, part of it would go into I.

Indirect Addressing

The Rice Computer provided (through the B-registers) support for up to six levels of indirection; this would typically be used to define multi-dimensional arrays, for instance. The B-register mechanism was later expanded upon through use of codewords. This actually had the potential to create problems, as SPIREL, the control program monitor, made calls through the codeword mechanism, and parameters were held in the B-registers; if the programmer had naively used the B-registers to provide for array indexing, then his data could easily get overwritten by system calls. Conversely, use of the B-registers could overwrite memory managed by SPIREL.

Tag Bits

Another major feature of the Rice Computer was its use of tag bits. While words were nominally 54 bits long, they contained an additional two tag bits which would allow the words to be marked with any of four tags. This was a useful general mechanism, since tags could be applied to both code and data. An obvious use of tagged code was to provide debugging facilities by, for instance, halting the machine and printing the register contents whenever an instruction tagged with "01" appeared.

Tagged data was more complex. A common use was to delimit sparse matrices or matrices made up of variable-length rows; one tag could be used to mark "end of row", and a second tag as "end of matrix". Another clever use was to provide for operations on a vector of data with a single instruction. A trap would be set so that, upon encountering a tag, the machine would come out of repeat mode. Then the instruction would be set up to turn on repeat mode and operate on a word indexed through an automatically incremented B-register. Thus, a single instruction would operate on each word in the vector until it encountered the "end of vector" tag, whereupon repeat mode would be turned off and the program would move ahead to the next instruction.



John Iliffe was the principal designer of the system software for the R1; he was aided by Jane Griffin (now Jodeit), Jo Kathryn Mann, and Mary Shaw. The major pieces of system software were SPIREL, an operating system of sorts, the AP1 symbolic assembler, and GENIE, a higher-level language compiler. There were, additionally, many user applications, some of which will be discussed.


The "codeword" was a unique feature of the R1's architecture. Codewords provided memory segmentation in software. A memory segment could contain either instructions, data, or further codewords, and was addressed via a codeword. The codeword therefore acted as a pointer to a block of memory. A codeword contained both the length and the address of the block it pointed to, as well as several bits to indicate indexing modes used by the B-registers. One bit within the codeword would be set to indicate that the memory object pointed to was itself made up of codewords; there was no limit in principle to the depth to which codeword references could be nested, thus making possible associative arrays of arbitrary dimension. In practice, a hardware trap was implemented such that more than 39 levels of nested codewords were assumed to be a circular reference and would halt execution[32]. What made the codeword unique was that by enforcing (in software) data typing within a segment, a codeword could present a generic interface to an object in memory. As Iliffe puts it:

The use of codewords encouraged the use of an "object-oriented" view of program design which decoupled the physical extent and existence of entities from the operations applied to them.[33]

Codewords also allowed dynamic memory allocation, and, had there been a way to ensure that memory references had to be made through codewords, would have easily allowed implementation of a security system and multiprogramming. Codeword use will be further discussed under SPIREL, as it was only within the SPIREL system that codewords were made available.


SPIREL was less what we would consider today an operating system and more a control program monitor: a set of loosely coupled routines that allowed the programmer to call certain system services such as printing the contents of a block of memory, allocating a block of memory, tracing program execution, or reading the system clock. All entry to SPIREL was made through codewords--one would load the control word telling SPIREL what to do into register T7, and then transfer control to the word pointed to by the codeword at address 126 (in AP1 nomenclature, TSR *126)[34], which contained the address of the XCWD (Execute Control Word) SPIREL instruction.

Dynamic memory allocation took place through either the TAKE SPIREL command or through the SETX command. TAKE was a mere five words long and grabbed a linear block of memory whose length was specified by the programmer; there was no corresponding instruction to return this memory once done.

SETX was by far the more interesting command. Once activated it overwrote TAKE, which then became unavailable. SETX, while also a mechanism to allocate a given length memory block, provided much more functionality. Memory, once allocated, could be freed. Further, if the total free space in the machine was enough to satisfy a memory allocation request but the memory was not in a contiguous block, SETX would automatically shuffle storage blocks around to provide a sufficiently large contiguous memory block. This was possible only by using the codeword mechanism: since memory was accessed through its associated codeword, to move the location of an object, the system had only to copy the data from one memory block to another and then patch the codeword to point at the new block. Similarly, memory blocks could be lengthened or shortened on the fly by patching the length descriptor in the codeword. A stack, starting at address 176008, pointing to codewords referencing allocated memory, was kept in a codeword referenced by the B6 register, and interface routines to push and pop the stack were given in SPIREL as SAVE (*136) and UNSAVE (*137).

The only major problem with this approach is that programs which used the pathfinder registers could easily conflict with SPIREL's use of memory: the pathfinder registers returned absolute addresses rather than codewords, and hence, loading programs after allocating memory via SETX could cause a routine to be placed in the middle of data pointed to by a codeword. The workaround was to load all programs before calling SETX to allocate memory.[35]

A program could therefore request and free just the amount of memory it needed for its objects at run-time; each memory block could map directly to a high-level program object, and there was no need to determine the object's maximum size at all. This naturally leads to an object-oriented programming model, but one that is enforced in the machine's architecture, rather than "stuck on at the end by C++"[36].

"Undoubtedly, dynamic memory allocation based on logical units of program was the major innovation [of the R1],"[37] claims Iliffe. Codewords also provided a basis for implementing multiprogramming and security, although these were not actually done on the R1, as there was no way to enforce access solely through the codeword mechanism. They did, however, surface in that role on Iliffe's Basic Language Machine[38,39].


AP1 was the symbolic assembler developed for the R1. It was basically a natural outgrowth of the instruction set. Support for symbols and for relocatable code (via symbolic labels) was part of the initial design. John Kilpatrick apparently provided the impetus for implementing an assembly language with an easy mnemonic structure[40].

There were actually two versions of the assembler: AP1 and AP2. AP1 was designed to produce standalone programs, while AP2 was used for inline code within Genie. They were nearly identical in form, differing chiefly in their representation of numbers--AP1 assumed numbers were in octal unless a "d" was prepended, while AP2 assumed decimal unless a "+" was prepended[41].

Both included a number of pseudoinstructions to insert remarks or octal or decimal data into a program, or to include printer or Flexowriter output.[42]


Genie was the system application compiler. It depended heavily on SPIREL to achieve its aims and therefore would only be used when the programmer went to the trouble of using system access calls to manage his program.

Genie "definition sets" could consist of any number of programs, although it was usual to only have one program per definition set. Names (variables, functions, named constants, etc.) could be up to five characters. There were three categories of variables: internal, external, and parametric. Internal variables were global only to the program in which they appeared, and could only be statement labels, integers, floating point numbers, or booleans--in other words, scalar quantities.

External variables could be scalar or non-scalar. Non-scalar variables would refer to a program, a vector, or a matrix. These variables would simply point to a codeword, which would then reference some object in memory. External variables were accessible to all programs in the machine, as they were memory structures pointed to by symbolically-named codewords.

Finally, parameters were used for passing information to and from programs within a definition set; they would be internal or external variables to the calling function. Any data type was acceptable as a parameter.

Since functions could be passed as generic codewords, this made an object-oriented view of problems to be solved a very natural approach. One surprising feature of Genie was that, while "[e]very Genie program is a function [and] may be used as such by any other Genie program...it may not use itself."[43] This seems odd, as tail recursion appears to be a very intuitive mechanism to use with such a calling convention, and the overhead of saving context would not have been large.

Arithmetic operations were fairly standard. The only surprising feature to modern eyes is that exponential operations were actually indicated with superscription[44] using the superscription capability of the Flexowriter. Similarly, accessing an element of a vector or matrix was done using the subscription capability of the Flexowriter[45].

Control transfer was provided with what was essentially a GO TO: the statement was CC = #LABEL, where LABEL was a statement label within the program; conditional branching was handled by CC = #A1 if P1, #A2 if P2, ... , #An if Pn, thus providing a rudimentary switch statement[46]. Loop structuring was fairly advanced for the time: a FOR...REPEAT construct was given[47], and FOR loops could be nested.

Execution of functions could be either implicit or explicit. With a function that returned a single value, implicit execution--for example, "A = F(P) + 2" was allowed. For a function returning multiple values, "EXECUTE F(P)" would have been required[48].

A set of instructions to read from paper or magnetic tape, to punch tape, or to print, were also included, as was support for inline assembly code in the AP2 format. An interesting feature of Genie was that, if compilation required more physical memory than was available, a scratch tape was mounted and the tape would be used as temporary storage for code. In that manner, programs of arbitrary length could be compiled.

Genie would typically have been used for complex mathematical programs that did not require complicated data structures. Assuming that the only entities the programmer wanted to use were supported Genie data types, it would have been easier to code a program in Genie. If the program needed only a few features not available in Genie, it would have been possible to code a program in Genie with additional functionality added in AP2. AP1 would only have been necessary to get Genie implemented and to write programs which extensively used features of the machine not supported by Genie, such as the Mode Light Register. The assembler would also have been used to write programs which bypassed SPIREL entirely and ran on the bare hardware.[49]

User Programs

The Rice Computer was designed not only to do research into how best to build computers, but to get work done for faculty members as well. John Kilpatrick was probably the first user to get a nontrivial program running; what he implemented was a program to solve the pentomino problem, which asks how many ways the set of twelve figures made of five unit squares can be arranged in a sixty-square-unit box[50]. Graduate students Joel Cyprus and Dwayne Chesnut completed their Ph.D. theses on the R1, Cyprus by solving the minimum number of different circuits necessary to perform majority-logic synthesis for boolean functions of four inputs, and Chesnut by stochastically investigating energy states in the H2+ molecule[51]. Salsburg investigated the packing of spheres in N-dimensional space to represent fluid flow. All of these were done in the period 1961-1964, before SPIREL and Genie got up to speed; consequently, they were, for the most part, written on the bare machine.

Since the R1 was built and maintained at Rice, it could be extraordinarily responsive to users' needs. Monte Carlo circuitry was added to the machine for Kilpatrick and Chesnut's work. Jean-Claude DeBremaeker added a digital seismograph to the Rice Computer and a new tape mode to drive it. This was made easy through the availability of Class 7 (Special Function) Instructions and through the mode lights. When a disagreement arose over the best way to do something, such as how to best implement floating-point zeroes, the mode lights were useful in effecting a compromise. This became a battle between Graham and Kilpatrick: should a zero result in a floating point calculation be represented as a zero mantissa with the original exponent, to show the precision to which it was zero (Kilpatrick's sentiment), or should it be represented as a zero mantissa with a zero exponent, so that it would be represented by the machine as a "real" zero, identical to the contents of the zero register (Graham's feeling)?[52] The arithmetic unit was wired both ways and attached to a mode switch, allowing the user to choose which way he wanted to run the machine.

In the later years of the R1's existence, more projects were attempted on it as it became less a research machine and more a general-purpose workhorse. An ALGOL compiler was attempted but never completed. Gary Sitton attempted a voice-recognition program for his Master's Thesis[53], using Sigsby Rusk's analog-digital converter.

Finally, the R1 was an integral part of the design of the R2. The R2 was to have been implemented using ECL logic. The ECL flatpacks were to be mounted in plastic carriers from which protruded "combs" of metal teeth connecting to the pins of the packages; if an electrical connection was to be made, the tooth would be left attached. If not, it was to be punched off. Layers of these carriers were to be sandwiched together to provide a complex three-dimensional structure implementing the computer's logic. The antiquated R1 was used to deduce the optimal layout for the interconnected combs which supported the R2's ECL logic, print the wiring map, and punch the tape which drove the die that would punch the teeth off the combs[54].

Use of the Machine

Idiosyncrasies of the Computer's Use


There was essentially a three-level power structure defining access to the machine: people developing the machine or its software had the highest priority. Second came faculty members doing research on it, and third were graduate students. Chesnut claims to have logged approximately 2,000 hours of machine time, mostly between midnight and 8 AM, while working on his thesis[55], and comments that he and Cyprus were almost certainly the R1's heaviest users.


A user would sign up for a ten-minute block of computer time; this is another reason that graduate students would tend to work in the middle of the night, when they could use the machine uninterrupted for long periods. Verification was handled in an interesting manner: a user would get a "key"--a printed circuit board whose characteristics allowed determination of who was using the machine. Insertion of this key into a slot would cause a paper tape to be punched, so a log of machine use could be produced.

Chesnut recounts that he once noticed an intermittent floating point error that seemed to occur once a minute while he was using the machine. The only other sixty-second clock he could think of was the key; the problem, in fact, was that the lead carrying the pulse of data from the key had been routed too close to the accumulator and would scramble its contents.[56]

Other Peculiarities

Another bizarre feature of the machine, mentioned in The New Hacker's Dictionary, was the "grind crank"[57]. The R1 had a single-step mode; at some point, someone evidently got tired of toggling the stepper switch for each and every instruction and connected a crank and cam to it, so that one revolution of the crank would cycle through sixty instructions[58]. That having been done, one could put the machine into single-step mode and turn the crank until near the critical part of the code, when one could step through the instructions one by one.

There was no distinctive culture surrounding the Rice Machine. While there was a certain esprit de corps, there was nothing like the atmosphere of MIT's Tech Model Railway Club, which became the progenitor of modern hackish culture. Phil Deck provided the only distinct saying connected with the R1. Apparently, in any situation in which blame could conceivably be assessed, Deck would ask, "What you mean-um we, kemosabe?"[59] This behavior was both endemic enough and obnoxious enough that it is vividly remembered 35 years later.[60]

Funding the Project

The funding of the R1 was also highly idiosyncratic: having two large grants was used very advantageously. Whenever an expensive item was to be bought using AEC funds, the AEC would have to approve the request. What Graham typically did was to order an item and submit the requisite forms for AEC approval, while claiming that the computer project would pay from its Shell funds. When the approval was returned, the funds would be swapped. This ensured that there was always enough in the Shell grant to cover large-ticket items until the approval came back.[61] The Army auditor sent by the AEC from Austin also left a lasting impression: she apparently refused to authorize payment for the brown craft wrapping paper used to mask off parts for painting, on the grounds that such paper was, in the opinion of the United States Army, "stationery".[62]


Joel Cyprus at work on the Arithmetic Unit, July 29, 1960.[63]

Success of the R1's Goals

The Rice computer met both its goals. The machine certainly provided useful basic computer design research. It also served well as a research tool for many years in a wide variety of fields.


The R1 was a fascinating machine; evolutionarily, it spanned a huge range of technologies, from the vacuum tubes used in its initial construction to the high-speed ECL used in its later peripherals. Graham's and Iliffe's perspectives on it differ interestingly--Graham speaks from a hardware viewpoint and believes "the electronics were really pretty good." [64] The quality of the machine's assembly and the usefulness of indirect addressing were the features that he particularly stresses, as well as the extensibility inherent in a computer with a microprogrammed instruction set in which the hardware could be modified freely. Graham strongly defends the choice of technologies as the best decision available at the time of construction.

Iliffe, on the other hand, remembers the codeword as the most significant thing about the Rice Computer: "Undoubtedly, dynamic memory allocation based on logical units of program was the major innovation."[65] He, in fact, feels that the B-register indirection scheme, while "cute"[66], could easily have been replaced by more efficient code. One suspects the fact that the hardware indexing mechanism got in the way of codewords contributes to his feelings. The ease with which the machine was modified is also a bone of contention: Iliffe, far from viewing this as a way to make the machine responsive to user needs, feels that the special-purpose hardware badly hurt the computer's reliability.[67].

The R1 was a tool for ten years of research at Rice. Over the course of its extraordinarily long lifespan it was used for everything from solving the pentomino problem, to optimizing synthesis of boolean logic, to molecular dynamics, to speech recognition. The quality of the technical team assembled to design and build its hardware and software has rarely been equaled. In the final analysis, it is remarkable that such a computer, whose basic technology was obsolete before the machine was fully online, built with a small budget, worked so well for so long.

Directions for Future Research

A further investigation into the history of the R1 and of early computing at Rice would certainly prove fruitful. A complete review of the secondary literature is badly needed. More of the people involved with the R1 project certainly should be contacted, including Jane Jodeit, Ted Schutz, and Joe Bighorse. Additionally, more information about research that used the R1 after 1964 would be helpful, and a wide variety of users' perspectives would be invaluable.

Tracing the machine's genealogy through the Burroughs B5000 and determining to what extent codeword segmentation influenced early experiments in multiprogramming promises to be another rich area of inquiry. It would also prove worthwhile to try to track down schematics and technical descriptions--if such still exist--for the peripherals added to the R1 late in its lifetime. It would also be interesting to trace the role of the R1 in the development of the R2 and to try to assemble a picture of the R2 project in its entirety. Such a project would be another significant step towards preserving the history of computer research at Rice.

Back to my home page.