Burroughs B1700 memory utilization

by W. T. WILNER
Burroughs Corporation
Goleta, California

INTRODUCTION

UNIQUE DESIGN REQUIREMENTS

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/reference-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 segmentation scheme.

Burroughs B1700 (described elsewhere in these Proceedings 4) 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-language, 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
579

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-language format can profitably change from program to
program.

instructions, viz.:
Opcode

1
0111
0110
0101
0100
0011

Instruction

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

Occurrence

Total Bits

1000
200
200
200
200
200

1000
800
800

800
800
800
5000

One thousand bits are eliminated, increasing memory

utilization by:

Frequency-based encoding

6000 - 5000
1 01
6000
X 00 /0

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

Frequency

#1
#2-#6

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

16 701

(1)

/0

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

Occurrence

Total Bits

#1
#2
#3-#6

1000
200
@ 200

1000
400
3200
4600

Fourteen hundred bits are eliminated, increasing memory 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 redundancy. 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-often-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)

581

Burroughs B1700 Memory Utilization

TABLE I-Comparison of SDL Opcode Encoding

.
Against Extreme Methods

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 memory management, etc.) and, in a different form, to write
sorting applications.

Encoding
Method
Huffman
SDL 4-6-10
8-bit field

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

172,346
184,966
301,248

.0059
.0196
.4313

17.2%
2.6%

43%
39%
0%

o. %

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).

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

Huffman enCOding""
57%,--+----+--~~--------------------~
50%+---~----r_------~r_------~--_r----_+

1.00

1.026

1.05

LlO

1.15

1.17

Decoding time

Figure I-Performance of SDL encoding compared to extreme

techniques

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

1.20

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

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 increasing one need not decrease the other.

L Pi log Pi

H= -

(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
(bits/ opcode)
4.58
4.88
6.51

Technique
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
Redundancy

1-

optimum message length

encoded message length'

(3)

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-

Significance of opcode compaction

Opcodes, in SDL's case, occupy nearly one-third of

the entire program space because the choice of S-language 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-language 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
Size
0
1
'2

3
4

Relative
Level
Contents
0
-1
-2
-3
-4
-5
-6 to -15

Displacemen t field size

4
5
6

Total

67
762
223
64
0

130
1182
408
44
0

189
1116
107
7
0

345
701
13
0
0

635
0
0
0
0

0
0
0
0
0

1574
5619
1611
370
0

1026

1116

1764

1419

1059

635

9174

Total

411
178
159
1
0
0

501
354
136
35
0
0

409
567
102
29
9
0

342
871
454
93
3
1

231
689
329
146
24
0

108
439
167
305
40
0

46
205
300
41
41
2

0
0
0
0
0
0

2985
3672
1714
663
133
7
0

136
478
162
56
0

31
355
143
45
0

12
397
272
68
0

29
628
283
86
0

832

574

749

521
234
44
13
16
4

416
135
23
0
0
0

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.

addresses may be structured differently from data

addresses. This freedom is advantageous for compaction, 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. Segments usually contain more bits (thousands) than
blocks contain variables (less than a hundred), so more
bits are needed for displacement fields than for occurrence 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
Field Size
0
1
2
3
4
5
6
7
8

Displacement field size

11
9
10

12

13

14

15

Total

0
0
0
5
42
32
110
78
12

153
0
2
9
12
36
37
132
5

1
1
1
6
42
66
80
147
40

39
0
0
9
28
25
166
168
26

33
5
0
0
0
5
36
9
0

102
1
0
0
0
0
0
0
0

332
7
28
42
147
309
502
603
120

268

376

389

461

88

103

2090

0-2

4
0
14
0
7
4
4
5
6

0
0
0
0
0
0
2
0
0

0
0
0
0
0
0
0
0
0

0
0
0
0
0
0
2
0
0

0
0
0
6
0
0
1
2
0

0
0
0
0
0
3
4
18
4

0
0
2
0
0
140
13
5
4

0
0
4
7
16
19
47
39
23

44

29

164

155

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 requirements 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

displacement
0,5 or
10 bits

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 hardware is no less puzzling than it was for data addresses.
Perhaps we may consider that the SDL machine can
directly address 2 30 (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

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 interpreter records each segment transition in an array which is
automatically allocated to each program. This monitoring, 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)

Burroughs B1700 Memory Utilization

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

':
I
1.1

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 displacement location, length, type, character code semantics,
and subscript information. Frequent operand descriptions 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 programs, 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 opportunities 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 requirements. From a set of twenty ANSI COBOL programs
of diverse application and varying size, we have
concluded that COBOL programs tend to occupy 70

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 preponderance 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

there is no compile-time or execution-time overhead

associated with this degree of user optimization.

DISCUSSION
Inherent limitations

Although choice of S-language format has been

completely free on the B1700, there are implied restrictions due to the semantics of the higher-level languages
for which S-languages have been invented. Contemporary languages, and FORTRAN especially, reflect the
kind of hardware which their designers knew existed:
sequential, word-oriented processors. Defined-field design offers significantly different machinery, and languages 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 reprogramming 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 refinements may not be worthwhile. This also implies that
only first-order usage statistics need be collected, which
keeps analysis costs down.

CONCLUSION
Defined-field design permits the definition of S-languages which are more efficient at memory utilization
than contemporary machine structure. Because accessing 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

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,

manual
Burroughs Corporation Business Machines Group Sales
Technical Services Systems Documentation Detroit
Michigan 1964
P J DENNING
The working-set model for program behavior
Comm ACM 11 5 May 1968 p 323ff
E G COFFMAN JR T A RYAN
A study of storage partitioning using a mathematical model
of locality
Comm ACM 15 3 March 1972
W T WILNER
Design of the Burroughs B1700
Proc FJCC72 Vol 41
D A HUFFMAN
A method for the construction of minimum redundancy codes
Proc IRE 40 September 1952 pp 1098-1101
D EKNUTH
An empirical study of FORTRAN programs
Software-Practice and Experience 11971 pp 105-133
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)