Burroughs B1700 memory utilization

by W. T. WILNER

Burroughs Corporation Goleta, California

INTRODUCTION

Squeezing more information into memory is a familiar problem to everyone who has written a program which was too large to fit into memory. Program compaction is also important to those who work on machines with virtual memory (such as the B55001) ; despite the almost unlimited amount of storage, one wants to keep program working-sets2 (collections of segments needed in core at the same time) as small as possible to reduce both the number and duration of segment swaps. In general, one seeks to raise the information content (or reduce the redundancy) of the blocks of information which one is using. In this discussion, "information content" will suffice as an intuitive notion.

One of the devices which hardware and software designers have provided to help with compaction is choice of container sizes. Machines can manipulate more than words: bytes, double words, and so on. Languages allow variables to be declared with different sizes, e.g., four-byte or eight-byte integers. Another category of compaction devices is encoding techniques. For example, memory addresses may be encoded literally, or as a "base-register-name/displacement" pair, or as an "indirect-reference-flag/ ref erence-table-index" pair, or so on. A third technique for raising information content is to group information according to time, that is, by keeping information which is likely to be needed at the same time in one place. For example, variable-length segments are more efficient than fixed-length pages, 3

partly because segments are made to contain coherent subprograms, which is a way of grouping according to time.

Ideally, then, a computer system very likely to utilize memory most efficiently would be one which could (a) manipulate any size bit string, (b) interpret any sort of encoding, and (c) administrate any segmen-tation scheme.

579

UNIQUE DESIGN REQUIREMENTS

Burroughs B1700 (described elsewhere in these Pro-ceedings4) is the only information-processing system (known to the author) which almost attains these ideals. The B1700 is specifically designed (a) to manipulate fields from zero to 65,535 bits long equally adeptly (which is a requirement of its defined-field design), (b) to interpret arbitrary "soft" machine language, or S-lan-guage, faster than a hard-wired system in the same price class could execute identical functions (which is a requirement of its generalized language interpretation design), and (c) to automatically move information in and out of memory according to any scheme (which is a requirement of its throughput objectives). As a result, the information content of fields in B1700 memory is exceptionally high, and memory is often utilized twice as efficiently as on other systems.

COMPACTION TECHNIQUES

A rbitrary field size

With defined-field design, fields may be defined to be just the size that is necessary, however many bits that may be, and other, arbitrarily-defined fields may begin in the very next bit. One bit will do for boolean variables, and it may truly be any bit in memory. Character strings may begin on any bit address. There is no such thing as byte alignment, or data specification. A major addressing boundary, if it can be called that, occurs between each of 244 (over 17 trillion) bits. Every bit can be fully utilized.

There are no locations and no field lengths which offer any processing advantage over other locations and lengths. Therefore, S-language designers are free to choose container sizes, such as for data addresses, which

From the collection of the Computer History Museum (www.computerhistory.org)

580 Fall Joint Computer Conference, 1972

are precisely as many bits long as desired. This simple freedom appears to account for half of all the program compaction which has been realized on the B1700.

S-language designers are further able to leave such things as branch address field lengths unbound until after compilation, when specific program details are known, such as the maximum number of instructions to be skipped by a branch instruction. It is just as easy to bind field lengths at run time as earlier; hence, S-lan-guage format can profitably change from program to program.

Frequency-based encoding

Given that fields may have arbitrary sizes, S-language designers (and users) may employ the varying-size containers generated by Huffman's algorithm for minimum redundancy codes. I) Briefly, the technique encodes elements by means of strings whose length varies inversely with the occurrence frequency of the elements; i.e., the most frequent element is represented by one of the shortest strings, and the least frequent element is represented by a longest string.

Huffman encoding constitutes one extreme form of representation, which may possibly stipulate a different length string for each element to be represented. The opposite extreme is uniform container size, e.g., words. Between these two extremes lie a range of encodings, which particular circumstances may merit, as will be illustrated later.

As a simple illustration of frequency-based encoding, suppose a defined-field computer with a six-instruction repertoire exhibited the following frequency counts of instructions in a program whose size was to be compacted:

Instruction

#1 #2-#6

Frequency

1000 5@200

Total 2000

Using ordinary encoding techniques, a three-bit field would be used to represent six quantities. The program's 2000 instructions would then be represented by 6000 bits. If, on the other hand, we allow variable-length, frequency-based encoding, the most frequent instruction could be encoded with only one bit. The bit would signify either the instruction or that three more bits follow, carrying the encodings of the remaining five

instructions, viz.:

Opcode

1 0111 0110 0101 0100 0011

Instruction

#1 #2 #3 #4 #5 #6

Occurrence

1000 200 200 200 200 200

Total Bits

1000 800 800 800 800 800

5000

One thousand bits are eliminated, increasing memory utilization by:

6000 - 5000 1 01 = 16 701 6000 X 00 /0 /0 (1)

A better encoding would use two bits for one of the five less frequent instructions, since the remaining four could still be encoded in four bit opcodes, viz.:

Opcode

1 01 0000-0011

Instruction

#1 #2 #3-#6

Occurrence Total Bits

1000 1000 200 400

@ 200 3200

4600

Fourteen hundred bits are eliminated, increasing mem-ory utilization by 23.3 percent. Note that this encoding has no unused bit combinations; it can be used for exactly six instructions. More redundant codes have room for other opcodes.

Time-based representation

In addition to representing information in fields according to occurrence frequency, one may improve memory utilization by rearranging fields according to dynamic frequency. That is, fields which are needed most often in memory may be collected into a common segment, in a time-analogy to minimum spatial re-dundancy. The B1700's interpreters are equipped to record program profile statistics6 which determine what pieces of code spend the most time being executed. By designing S-languages which allow arbitrary grouping of data or program pieces into segments, one may permit program representations in which most-of ten-used constructs appear in short, coherent segments while relatively unused portions reside in large, discontinuous (from the standpoint of flow of control) segments. Bits in each segment have similar time-utilization, just as the varying length of fields in Huffman encoding grant similar space-utilization to the bits in a particular field.

From the collection of the Computer History Museum (www.computerhistory.org)

Dynamic field size

A defined-field computer must transmit a ,field length as well as a bit location to memory for each access since arbitrary field lengths are permitted. Consequently, it is just as convenient to have operand lengths dynamically changeable as fixed. Length constants must be stored somewhere between requests to memory, and it is no less efficient to keep them in addressable fields. This opens up the possibility of Dial-A-Precision FORTRAN, where the operand fields in the FORTRAN S-language can be adjusted on the fly to be long enough to hold a required precision, for example, during inner product calculations. This capability is planned for the B1700 software, but is not in the initial releases.

APPLICATION TO SPECIFIC S-LANGUAGES

Since all high-level languages on the B 1700 are compiled into novel S-languages of Burroughs' own invention, opportunities exist in these contexts for improved memory utilization. S-languages for. existing machines, such as System/360 machine language, prohibit compaction because the fields are locked on to non-defined-field hardware formats.

SDL S-language

Burroughs supplies B1700 customers with a language and interpreter which have been designed to be most efficient in a compile-time environment. Named Systems Development Language, SDL, it has been used to program all B1700 compilers. SDL is constructed from an extendable base language which has been used, in augmented form, to write the B1700's Master Control Program (which performs supervisory functions such as 1/0,' multiprogramming, multiprocessing, virtual mem-ory management, etc.) and, in a different form, to write sorting applications.

SDL opcodes

Opcodes are encoded into three lengths: four, six, and ten bits. Of the sixteen four-bit combinations, ten name the most frequent instructions, five indicate that two more bits specify the remainder of a six-bit instruction field, and one signifies that six more bits are needed to define the operation. The design trade-off between space and time in opcode representations does not vary linearly between the extremes of Huffman encoding and fixed container size. One fixed field length allows

Burroughs B1700 Memory Utilization 581

TABLE I-Comparison of SDL Opcode Encoding . Against Extreme Methods

Total Bits Encoding for MCP's Utilization Decoding Method Opcodes Improvement Penalty Redundancy

Huffman SDL 4-6-10 8-bit field

172,346 184,966 301,248

43% 39% 0%

17.2% 2.6% o. %

.0059

.0196

.4313

parallel decoding of all bits in the field, mInImIZIng time, but requiring much storage (except when all elements have identical occurrence frequencies, but that is contrary to computer behavior). Huffman codes may require much more decoding time, since bits may need to be examined serially until the length of the field manifests itself, but the codes can minimize storage. In the middle, SDL's three lengths come very close to minimizing storage, and also incur very little extra decoding time, as Table I indicates. Figure 1 presents the same figures graphically. The reason for Figure l's exponential curve is that there are several orders of magnitude between the frequencies of the most and least frequent elements in the set to be encoded. There is a great deal to be gained in such circumstances even by encoding the $ingle most frequent element in a shorter field than the others (as was illustrated also in our example). If the opposite were true, if all elements were uniformly frequent, then the trade-off curve wo:uld be linear (or nearly so, depending on what multiple of the encoding radix the number of elements is).

Huffman enCOding""

57%,--+----+--~~--------------------~

50%+---~----r_------~r_------~--_r----_+

1.00 1.026 1.05 LlO Decoding time

1.15 1.17

Figure I-Performance of SDL encoding compared to extreme techniques

1.20

From the collection of the Computer History Museum (www.computerhistory.org)

582 Fall Joint Computer Conference, 1972

Redundancy

We can compare these techniques on a less intuitive basis. "Information content" may be precisely defined in terms of the probability of a message's occurrence (as opposed to its meaning). Shannon's entropy function7

I

H = - L Pi log Pi (2)

gives a measure of the average information content of I independent events with individual probabilities {pd. If we consider an SDL opcode in the MCP program as an event, and calculate Pi log2 Pi for all 73 opcodes, then we find H = 4.55, which may be- interpreted as the average number of bits needed for an opcode. To compare the encoding techniques of Table I using this criterion, we have:

Average content Technique (bits/ opcode)

4.58 4.88 6.51

binary Huffman SDL 4-6-10 8-bit field

which shows that our chosen technique is very close to the minimum value of 4.55.

The redundancy factor of an encoding technique may be calculated as

optimum message length Redundancy = 1 - (3)

encoded message length'

which ranges from zero (no redundancy) to one (infinite redundancy). To derive the redundancy column in Table I, we compared the total bits in the MCP via each technique against 4.55 X 37,656 (the total number of MCP opcodes) = 171,349, which is the smallest number of bits that may be used under the assumption that opcodes are decoded independently.

Redundancy, despite its quantifiability, is not a good independent design criterion. If pursued too extremely, there are disadvantages (such as intricate and slow decoders). If ignored, of course, there are extreme disadvantages (total system inefficiency). One must consider it in balance with all other design criteria, and attempt to reduce it without sacrificing performance in other areas. Most importantly, one must not sacrifice the unquantifiable criteria, such as ease of use, which appear to be most significant. It is interesting, however, that the B1700's S-language concept (which was pursued primarily to improve ease of use) has the desirable side effect of taking actual opcode representa-

tions out of the programmer's attention (because the possibility of working with machine language is removed), and this allows further efforts to remove redundancy, because opcodes no longer have to be human-engineered. Ease of use and high memory utilization are not orthogonal design criteria and in-creasing one need not decrease the other.

Significance of opcode compaction

Opcodes, in SDL's case, occupy nearly one-third of the entire program space because the choice of S-lan-guage significantly reduced all other kinds of fields. Compaction of opcodes contributed the most toward reducing overall SDL program size.

SDL data addresses

Locations of variables, or data addresses, are the second most populous fields, after instructions. SD L is a block-structured language and the SDL machine (for which the SDL S-language is the machine language) is a stack-structured processor, so data is accessed by a pair of integers, one giving the lexicographical level on which the variable was declared in the SDL program, and the other giving an occurrence number, or ordinal position, of the declared identifier in its block. The level identifies a (dynamically varying) region of the stack and the occurrence number indicates a displacement into the region where the variable may be found.

In order to accommodate extremely large programs, the language designers decided to allow up to 1024 variables on any lexicographical level, and up to sixteen nested levels. The largest data address, thus, would require fourteen bits, ten for displacement and four for level. Once the compilers and the MCP were written and debugged in SDL, the actual usage of bits in data address containers was studied, in order to apply frequency-based encoding techniques. Table II gives the usage statistics for the B1700 MCP. Using the arbitrary fourteen-bit container, 9174 addresses require 128,436 bits. The usage study found that 66.1 percent of the occurrence numbers could be contained by a five-bit field and 78.4 percent of the level numbers were either the current level or level zero, which could be encoded in one bit. All together, if these shorter fields were made available, only 94,900 bits would be required, which is a 26.1 percent improvement in memory utilization. By mutual consent of the two SDL compiler writers and the SDL interpreter writer, it was agreed that the S-lan-guage would be changed to include a new data address format: level fields of one or four bits, occurrence

From the collection of the Computer History Museum (www.computerhistory.org)

Burroughs B1700 Memory Utilization 583

TABLE II-Occurrence of Actual Field Lengths Required by B1700 MCP Data Addresses

Level Field Displacemen t field size Size 0 1 2 3 4

0 136 31 12 29 67 1 478 355 397 628 762 '2 162 143 272 283 223 3 56 45 68 86 64 4 0 0 0 0 0

832 574 749 1026 1116

Relative Level

Contents 0 1 2 3 4

0 521 416 411 501 409 -1 234 135 178 354 567 -2 44 23 159 136 102 -3 13 0 1 35 29 -4 16 0 0 0 -5 4 0 0 0 -6 to -15

number fields of five or ten bits, and two prefix bits to indicate which of the four possibilities followed. Locations in SDL are thus eight, 11, 13, or 16 bits long.

Because this scheme is so different from conventional techniques, it is difficult to establish the exact advantage in memory utilization. If we consider a conventional scheme which can address as many variables, it is reasonable to require that two bytes of address field be used, since it is certainly possible for a program with 216 variables to be executed by the SDL interpreter. Another way of reaching the same conclusion is to consider the fourteen-bit maximum container; without defined-field design, fields must be byte-multiples (at least), so two bytes are needed. For 9,174 addresses of 16 bits each, 146,784 bits are needed. Hence, the four-way SDL encoding offers 35.4 percent memory utilization.

SD L code addresses

Program points are addressed by a pair of integers' one giving a segment name and the other specifying the starting bit of an instruction in the segment, relative to the start of the segment. Program segments are stored separately from data segments. * As a consequence, code * This is so that protection can be efficiently implemented and so that reentrancy is free, i.e., more than one program can execute a segment concurrently without requiring a different representation from that which a one-program version would use and without executing any instructions specifically to administrate reentrancy.

9 0

5 6 7 8 9 Total

130 189 345 635 0 1574 1182 1116 701 0 0 5619 408 107 13 0 0 1611 44 7 0 0 0 370 0 0 0 0 0 0

1764 1419 1059 635 0 9174

5 6 7 8 9 Total

342 231 108 46 0 2985 871 689 439 205 0 3672 454 329 167 300 0 1714

93 146 305 41 0 663 3 24 40 41 0 133 1 0 0 2 0 7

0

addresses may be structured differently from data addresses. This freedom is advantageous for com-paction, too, because usage information may be applied independently to each kind of field. Code address requirements are typically very different from data address requirements. Programs usually have many more variables than segments, so fewer bits are needed for segment names than for variable addresses. Seg-ments usually contain more bits (thousands) than blocks contain variables (less than a hundred), so more bits are needed for displacement fields than for occur-rence number fields.

SDL designers wanted to allow over a billion bits for programs, in up to 1024 segments of up to one million bits each. At the same time, they surmised that many references to the first 32 segments might better be encoded in five-bit segment names, and references to the first 4096 bits and the first 65,536 bits might be more efficiently encoded in 12- and 16-bit fields, respectively. These shorter options were included in the preliminary S-language design which was used during MCP and compiler construction and check-out.

Prior to release, actual usage was studied to evaluate the appropriateness of the design choices. * A sample of

* On the B1700, S-language design may be changed at any time. Programmers see only higher-level language which is independent of S-language format. Hardware sees only microcode, which is indifferent to S-language format. Many S-language revisions can, in fact, be implemented simply by changing some literal fields in the interpreter and compiler.

From the collection of the Computer History Museum (www.computerhistory.org)

584 Fall Joint Computer Conference, 1972

TABLE III-Occurrence of Actual Field Lengths Required for B1700 MCP Code Addresses

Segment Displacement field size Field Size 0-2 3 4 5 6 7 8

0 4 0 0 0 0 0 0 1 0 0 0 0 0 0 0 2 14 0 0 0 0 0 2 3 0 0 0 0 6 0 0 4 7 0 0 0 0 0 0 5 4 0 0 0 0 3 140 6 4 2 0 2 1 4 13 7 5 0 0 0 2 18 5 8 6 0 0 0 0 4 4

44 2 0 2 9 29 164

2,090 code addresses from the B1700 MCP corroborated the design team's choices, including that of a null segment field, for references within the same segment. Table III gives the occurrence of the actual field require-ments for the code address sample. Actually, a fraction of 1 percent improvement in memory utilization could be achieved by changing from a five-bit segment field to a six-bit field, but if future SDL programs turn out to be smaller than present Burroughs compilers, the usage statistics will eventually prefer the present fields, so no change was made. SDL code addresses, then, have the following format:

field description

3 bits 0,5 or 10 bits

displacement

0,12, 16 or 20 bits

Of the eight permitted variations, the most frequent is 15 bits long; three description bits, no segment field, and 12 displacement bits. Except for the null address (only three bits long), this is the shortest option, so it is to be expected that a proper frequency-based encoding of code addresses would make this the most commonly used format.

Comparing this schem~ against conventional hard-ware is no less puzzling than it was for data addresses. Perhaps we may consider that the SDL machine can directly address 230 (over one billion) bits of instruction storage. An equally capable byte-oriented machine needs to address 227 bytes directly, so four bytes are needed. The SDL representation uses 74,303 bits for 3,767 addresses in the B1700 MCP, whereas the byte-oriented machine would need 120,544 bits (ignoring the extra capacity that four bytes allows). In terms of memory

9

0 0 4 7

16 19 47 39 23

155

10 11 12 13 14 15 Total

0 153 1 39 33 102 332 0 0 1 0 5 1 7 0 2 1 0 0 0 28 5 9 6 9 0 0 42

42 12 42 28 0 0 147 32 36 66 25 5 0 309

110 37 80 166 36 0 502 78 132 147 168 9 0 603 12 5 40 26 0 0 120

268 376 389 461 88 103 2090

utilization, the ability to define eight different code address formats yields a 38.4 percent advantage for the B1700.

SDL profile statistics

While an SDL program is running, the SDL interpre-ter records each segment transition in an array which is automatically allocated to each program. This monitor-ing, performed by microcode, adds less than 7.4: percent to the running time. At the end of the run, SDL code is interpreted which prints the number of times each segment was entered, a compiler-estimated traversal time for each segment, and . the product of the two, giving an indication of which segments used the most execution time. SDL programmers can also indicate at compile-time which sections of their program should be monitored closely, down to each conditional expression, so that exact frequency counts can be obtained for each bit of code in the program. Subsequent monitoring involves additional code, but the amount is always less than a 1 percent increase. Assuming segment and procedure frequency counts have been utilized to focus one's attention on c;mly a few procedures, execution overhead for conditional expression monitoring is under 72 percent in most cases. Thus, the B1700 can indicate to programmers what the time-utilization of their program sections is, at very low cost. By grouping similarly utilized sections into segments so that segment transitions are lessened, temporal memory utilization can be increased.

Other S-languages

Only SDL designers were able to apply accurate usage statistics to their design because the entire world's

From the collection of the Computer History Museum (www.computerhistory.org)

I

I': 1.1

supply of SDL programs was available to them. COBOL, FORTRAN, BASIC, and RPG (the initial set of languages for the B1700) S-language designers collectively extracted usage statistics from over nine million bits of sample programs, but can only guess at their verity.

COBOL S-language

Opcodes are represented by three- or nine-bit fields; the seven most frequent instructions are encoded into seven of the eight three-bit codes, and the eighth is an escape code which indicates that six more instruction bits follow. Operands are prefixed by a single bit which indicates literal operands or variables. Literals consist of a type field (two bits), a length field (three or eleven bits), and the literal string itself. Operands are indicated by a string of fields which give segment and displace-ment location, length, type, character code semantics, and subscript information. Frequent operand descrip-tions do not appear in-line; they are placed into a table by the compiler and their table index is used in-line. COBOL S-language even includes a sub-S-Ianguage which defines editing operations. This implies that the COBOL interpreter contains a sub-interpreter which handles the editing program strings. These program strings, like operand descriptions, may appear either in-line or tabulated.

COBOL, more than any other language on the B1700, has taken advantage of the ability to leave object code format undefined until after the compiler has seen a program. Segment descriptions, displacements within segments, variable-length data's size fields, operand descriptors, data addresses, and branch addresses are all stored in fields whose size is made just large enough to hold whatever maximum value is needed for the particular program. This capability appears to reduce COBOL object program sizes by 46 percent; that is, if the length of these containers were fixed for all pro-grams, the average program size would be 85 percent larger. Of course, the amount of compaction is so large because the chosen S-language provides many opportu-nities to eliminate wasted space.

The overall appropriateness for COBOL's S-language is difficult to assess. One faces the same evaluation problem as trying to say how much better one machine design is than another at implementing COBOL. So far, the only secure comparisons which we have obtained pertain to overall throughput and resource require-ments. From a set of twenty ANSI COBOL programs of diverse application and varying size, we have concluded that COBOL programs tend to occupy 70

Burroughs B1700 Memory Utilization 585

percent less memory on the B1700 than they do on a System/360 model 30. Such a drastic reduction in memory also improves running speed, which averages around 60 percent faster than the 360/30. The B1700, when interpreting its COBOL S-machine, even seems to out-do the B3500 system, whose hardware was designed to execute and compile COBOL programs. Program storage requirements are 60 percent less, and execution times are comparable.

RPG S-language

In order to reduce the number of interpreters active at anyone time on single-processorB1700s, the initial release of RPG uses the same S-language as COBOL. From a set of 31 RPG programs used for benchmarks, we observed that program storage is typically 50 percent of System/3 size (although one program with a pre-ponderance of character strings in its representation was only 25 percent smaller, due to the fact that eight bits are used on both systems to represent characters). Execution speed is between 25 percent and 50 percent faster than System/3, due to the conciseness of the instruction stream and S-language advantage. COBOL S-instructions are interpreted at an average rate which is six times slower than System/3's average instruction rate (36 usec. vs. 6 usec.). To achieve 50 percent faster running time, each S-instruction must, on the average, accomplish twelve times more work than each System/3 machine instruction. Obviously, size alone cannot adequately measure program compaction.

FORTRAN S-language

FORTRAN also uses an opcode format of three or nine bits in each field, with seven short ops and one escape code. Data and code addresses have a common format, usually 24 bits long: field description bits (six) which control interpretation of the rest of the address and of the operand as well; a segment field (ten bits) which either names a segment or a place where a segment name can be found; a displacement field (eight bits) which locates operands within a segment; and possibly more fields, depending on context.

Summarizing seven moderately-sized jobs, FORTRAN programs tend to occupy 50 percent of the space needed on a System/360, and 40 percent of the space needed on a B3500. (Note that these figures and those for COBOL imply that the B3500 is better at representing COBOL programs than a 360 and not as good at representing FORTRAN programs, which is well-known.)

From the collection of the Computer History Museum (www.computerhistory.org)

586 Fall Joint Computer Conference, 1972

DISCUSSION

Inherent limitations

Although choice of S-language format has been completely free on the B1700, there are implied restric-tions due to the semantics of the higher-level languages for which S-languages have been invented. Contempo-rary languages, and FORTRAN especially, reflect the kind of hardware which their designers knew existed: sequential, word-oriented processors. Defined-field de-sign offers significantly different machinery, and lan-guages have yet to be defined which unconsciously assume defined-field capabilities, namely, that data and programs may be represented in any format whatever. Good as the B1700's memory utilization is, it tends to be better for programming languages which have a large number and variety of data and program formats.

Diminishing returns

Modifying interpreters to accommodate S-language refinements has a definite cost, including reprogram-ming affected portions of compilers and recompiling source programs. Our experience indicates that after identifying and improving seven or eight redundant aspects of a language, information content is relatively uniform among various S-language fields. Further re-finements may not be worthwhile. This also implies that only first-order usage statistics need be collected, which keeps analysis costs down.

User optimization

When several alternative encodings seem equally attractive and their design trade-offs are well drawn, their invocation may be placed under user control. Each programmer knows individually whether his local system is time- or space-rich at any given hour, so he can give simple indications to a compiler about what options should be exercised. In COBOL, for instance, all data addresses can be forced either into the operand table to minimize program storage, or in-line to speed up execution by eliminating the table indirection. Since the interpreter is already capable of decoding both forms,

there is no compile-time or execution-time overhead associated with this degree of user optimization.

CONCLUSION

Defined-field design permits the definition of S-lan-guages which are more efficient at memory utilization than contemporary machine structure. Because access-ing and manipulation of arbitrarily-sized bit strings is handled al;ltomatically by B1700 hardware, various encodings may be selected solely on their inherent merit, with respect to program storage and decoding time; their suitability to the B1700 is irrelevant because the hardware is uniformly adept at manipulating all sizes of fields. One is free to choose problem representations which equalize the information content of fields in memory. Experience with compaction techniques, such as variable-length, frequency-based encodings, indicate that memory requirements can be reduced from 25 percent to 75 percent, compared to byte-oriented systems.

BIBLIOGRAPHY

1 Burroughs B5500 information processing systems reference manual Burroughs Corporation Business Machines Group Sales Technical Services Systems Documentation Detroit Michigan 1964

2 P J DENNING The working-set model for program behavior Comm ACM 11 5 May 1968 p 323ff

3 E G COFFMAN JR T A RYAN A study of storage partitioning using a mathematical model of locality Comm ACM 15 3 March 1972

4 W T WILNER Design of the Burroughs B1700 Proc FJCC72 Vol 41

5 D A HUFFMAN A method for the construction of minimum redundancy codes Proc IRE 40 September 1952 pp 1098-1101

6 D EKNUTH An empirical study of FORTRAN programs Software-Practice and Experience 11971 pp 105-133

7 C E SHANNON W WEAVER The mathematical theory of communication The University of Illinois Press Urbana Illinois 1949

From the collection of the Computer History Museum (www.computerhistory.org)