1972 05_#40 05 #40
1972-05_#40 1972-05_%2340
User Manual: 1972-05_#40
Open the PDF directly: View PDF 
.
Page Count: 1234
| Download | |
| Open PDF In Browser | View PDF |
AFIPS
CONFERENCE
PROCEEDINGS
VOLUME 40
1972
SPRING JOINT
COMPUTER
CONFERENCE
May 16 - 18, 1972
Atlantic City, New Jersey
The ideas and opinions expressed herein are solely those of the authors and are not
necessarily representative of or endorsed by the 1972 Spring Joint Computer Conference Committee or the American Federation of Information Processing
Societies, Inc.
Library of Congress Catalog Card Number 55-44701
AFIPS PRESS
210 Summit Avenue
Montvale, New Jersey 07645
@1972 by the American Federation of Information Processing Societies, Inc.,
Montvale, New Jersey 07645. All rights reserved. This book, or parts thereof, may
not be reproduced in any form without permission of the publisher.
Printed in the United States of America
CONTENTS
IMPLEMENTATION OF PROGRAMMING LANGUAGE
PROCESSORS
1
R. M. McClure
T. E. Cheatham, Jr.
B. Wegbreit
An appraisal of compiler technology ............................ .
A laboratory for the study of automating programming ........... .
11
Segmentation and optimization of .programs from cyclic structure
analysis ................................................... .
23
J. Baer
R. Caughey
37
45
51
K. K. Curtis
R. B. Lazarus
M. S. Lynn
53
59
69
77
B. Jones
J. O. Hammond
R. W. Kleffman
G. A. Smith
FRONTIERS OF LARGE-SCALE SCIENTIFIC COMPUTATION
The interplay of computer science and large-scale scientific calculation.
Computer architecture and very large problems ........ ; ......... .
Scientific applications of computers in the 70's ................... .
THE COMPUTER AS SUPERTOY-PANEL SESSION
(No papers in this volume)
TRAINING COMMERCIAL PROGRAMMERS AND SYSTEMS
ANALYSTS
The functions and elements of a training system .................. .
Planning data processing education to meet job requirements ...... .
Modular training-A new emphasis ............................. .
Training techniques today-Tomorrow .......................... .
SOFTWARE DESIGN FOR THE MINI-COMPUTER
The future of mini-computer programming ...................... .
103
The current state of mini-computer software ..................... .
Real-time fault detection for small computers .................... .
111
119
D. Waks
A. B. Kronenberg
J.' Ossanna
J. R. Allen
S. S. Yau
TECHNIQUES FOR DEVELOPING LARGE PROGRAMMING
SYSTEMS
An organization for successful project management ............... .
Commercial data processing machines in government applications .. .
Programming language efficiency in real-time software systems ..... .
129
141
155
D. Smith
J. D. Aron
R. E. Merwin
J. O. Henriksen
163
181
187
B. Friedland
D. H. Jacobsen
D. G. Wilson
199
P. E. Valisalo
B. D. Sivazlian
J. F. Maillot
205
219
225
235
R. L. Graham
Z. Manna
D. Scott
J. D. Ullman
MATHEMATICAL OPTIMIZATION THEORY AND ALGORITHMS
A review of recursive filtering algorithms ........................ .
On computational methods for dynamic and static optimization .... .
Piecewise linear approximations of fewest line segments ........... .
Experimental results on a new computer method for generating optimal policy variables in (s,S) inventory control problem .......... .
NEW THEORETICAL FRONTIERS OF COMPUTER SCIENCE
Bounds on multiprocessing anomalies and packing algorithms ...... .
Computation of recursive programs-Theory vs practice .......... .
Mathematical concepts in programming language semantics ........ .
Applications of language theory to compiler design ............... .
THE ARPA NETWORK
The terminal IMP for the ARPA computer network ................ .
243
S. M. Ornstein
F. E. Heart
W. R. Crowther
H. K. Rising
S. B. Russell
A. Michel
Computer communication network design-Experience with theory
and practice ............................................... .
255
Function-oriented protocols for the ARPA computer network ...... .
271
McROSS-A multi-computer programming system ............... .
281
H. Frank
R. E. Kahn
L. Kleinrock
S. D. Crocker
J. Heafner
J. Metcalfe
J. Postel
R. H. Thomas
D. A. Henderson, Jr.
Extension of packet communication technology to a hand-held personal terminal .............................................. .
295
L. G. Roberts
An overview of programming languages for special application areas .. .
The future of specialized languages ............................. .
299
313
AMBUSH-A case history in language design ................ , .. ;.
The data-text system-An application language for the social
sciences ...... , ..................................... , ...... .
321
J. E. Sammet
F. B. Thompson
B. H. Dostert
S. Warshall
333
D. J. Armor
LSI-Implications for future design and architecture .............. .
343
The rationale for logic from semiconductor memory ............... .
SYMBOL hardware debugging facilities ......................... .
The Rice Research Computer-A tagged architecture ............. .
353
359
369
S. F. Dennis
M. G. Smith
W. H. Davidow
M. A. Calhoun
E. A. Feustel
PROGRAMMING LANGUAGES FOR SPECIALIZED
APPLICATION AREAS
NEW TRENDS IN THE ARCHITECTURE OF COMPUTER
SYSTEMS
COMPUTERS IN INSTRUCTION-SOME CONSIDERATIONS
A generative CAl tutor for computer science concepts ............. .
Preliminary thoughts about a UNIversal TEAching Machine ...... .
379
391
Mainline CAl, necessary but not oppressive ..................... .
Should the computer teach the student or vice versa? ............ .
399
407
E. Koffman
J. K. Clema
R. L. Didday
M. Wessler
C. V. Bunderson
A. W. Luehrmann
OPERATING SYSTEM DESIGN CONCEPTS
Performance evaluation-A structured approach ................. .
Protection-Principles and practice ............................. .
411
PRIME-An architecture for terminal oriented systems ........... .
431
417
S. Kimbleton
G. S. Graham
P. J. Denning
H. B. Baskin
B. R. Borgerson
R. Roberts
GRAPHIC TERMINALS-PRESENT AND NEXT STATES
Computer graphics terminals-A backward look .................. .
The future of computer graphics ............................... .
439
447
A versatile computer-driven display system for the classroom ...... .
GOLD-A graphical on-line design system ....................... .
453
461
C. Machover
R. H. Stotz
T. G. Hagan
J. W. Will hide
L. J. French
A. H. Teger
FORMAL ANALYSIS OF ALGORITHMS
Establishing lower bounds on algorithms-A survey .............. .
Analysis of combinatory algorithms-A sampler of current
methodology ............................................... .
On the complexity of proving and disproving functions ............ .
On the structure of Blum measure .............................. .
471
E. Reingold
483
493
503
W. D. Frazer
A. N. C. Kang
T. S. Chow
Management information systems, public policy, and social change ... .
Geographic information systems in the U.S.-An overview ......... .
507
511
A. Gottlieb
R. Amsterdam
E. Andersen
H. Lipton
UNIMATCH-A computer system for generalized record linkage
under conditions of uncertainty .............................. .
New directions in legal information processing ................... .
523
531
M. Jaro
R. T. Chien
P. B. Maggs
F. A. Stahl
HOMLIST-A computerized real estate information retrieval
system ..................................................... .
541
D. J. Simon
B. L. Bateman
Organization of a natural resources data bank system for government
and research ............................................... .
The command terminal-A computerized law enforcement tool. .... .
545
553
A. J. Surkan
D. M. Hudak
Experience gained in the development and use of TSS/360 ......... .
Multics-The first seven years ................................. .
559
571
Organization and features of the Michigan terminal system ........ .
585
R. E. Schwemm
F. J. Corbat6
C. T. Clingen
J. H. Saltzer
M. T. Alexander
THE COMPUTER IN GOVERNMENT-A TOOL FOR CHANGE
INTERACTIVE SYSTEMS
DATA COMMUNICATIONS-THE PAST FIVE YEARS AND
THE NEXT TEN YEARS
Data communications-The past five years ..................... .
Data communications in 1980-A capital market view ............ .
593
611
Allocation of copies of a file in an information network ............ .
617
P. Walker
R. E. LaBlanc
W. E. Himsworth
R. G. Casey
MANPOWER FOR COMPUTERS-HEYDAY OR CUTBACK
Production and utilization of computer manpower in U.S. higher
education .................................................. .
Sources of trained computer personnel-A quantitative survey ..... .
627
633
Employment of trained computer personnel-A quantitative survey ...
641
Sociological analysis of public attitudes toward computers and
information files ............................................ .
649
J. W. Hamblen
B. Gilchrist
R. E. Weber
B. Gilchrist
R. E. Weber
R. E. Anderson
MICROPROGRAMMING ENTERS A NEW ERA
Microprogrammed significance arithmetic-A perspective and feasibility study ................................................ .
Architectural considerations of a signal processor under microprogram
control .................................................... .
A building block approach to multiprocessing .................... .
675
685
The interpreter-A microprogrammable building block system ..... .
705
659
C. V. Ramamoorthy
M. Tsuchiya
Y.S. Wu
R. L. Davis
S. Zucker
C. M. Campbell
E. W. Reigel
U. Faber
D. Fisher
PERFORMANCE PREDICTION-MODELING AND
MEASUREMENT
Modeling, measurement and computer power .................... .
725
Experiments in page activity determination ...................... .
Validation of a trace-driven CDC 6400 simulation ................ .
739
749
Instrumentation for the evaluation of a time-sharing, page demand
system .................................................... .
759
J. Rodriguez- Rosell
J. Dupuy
767
L. Seligman
775
H. G. Rudenberg
J. T. Quatse
P. Gaulene
D. Dodge
G. Estrin
R. R. Muntz
R. Uzgalis
J. G. Williams
J. D. Noe
G. J. Nutt
LSI PERSPECTIVES-ARCHITECTURE AND COST OF SMALL
COMPUTERS
LSI and minicomputer system architecture-Implications for multiprocessor systems ........................................... .
Approaching the minicomputer on a silicon chip-Progress and
expectations for LSI circuits ................................. .
The external access network of a modular computer system ........ .
783
COMPUTER SIMULATION AS A DECISION MAKER'S TOOL
An over-the-shoulder look at discrete simulation languages ......... .
A specialized language for simulating computer systems ........... .
791
799
1. M. Kay
P. B. Dewan
C. E. Donaghey
J. B. Wyatt
Discrete computer simulation-Technology and applications-The
next ten years .............................................. .
815
J. N. Maguire
The emergence of the computer utility .......................... .
827
Installation management-The next ten years .................... .
833
R.
H.
D.
R.
THE DILEMMA OF INSTALLATION MANAGEMENT
PROGRAM DOCUMENTATION-PANEL SESSION
(No papers in this volume)
THE ROLE AND SCOPE OF COMPUTER SYSTEMS DESIGN
RESEARCH IN A UNIVERSITY SETTING-PANEL SESSION
(No papers in this volume)
S. Manna
Waldburger
R. Whitson
M. Rutledge
AN EVALUATION OF THE STATE OF COMPUTER SCIENCE
EDUCATION
841
847
S. Amarel
M. S. Lynn
849
857
P. J. Denning
p.1 C. Fischer
865
875
885
897
H. F. Cline
G. Sadowsky
T. L. Jones
R. C. Noel
T. Jackson
907
J. D. Schoeffler
915
925
H. E. Pike
O. Serlin
933
937
E. W. Dijkstra
P. J. Denning
Magnetic disks for bulk storage-Past and future ................ .
945
J. M. Harker
H. Chang
Ultra-large storage systems using flexible media,' past, present and
future ...... " .................................. " ......... .
New devices for sequential access memory ....................... .
957
969
W. A. Gross
F. H. Blecher
Two direct methods for reconstructing pictures from their projections-A comparative study ............... , ................. .
PRADIS-An advanced programming system for 3-D-display ...... .
971
985
MARS-Missouri Automated Radiology System ................. .
999
Sailing-An example of computer animation and iconic communication
Computer description and recognition of printed chinese characters ... .
Computer diagnosis of radiographs ............................. .
1005
1015
1027
G. T. Herman
J. Encarnacao
W. Giloi
J. L. Lehr
G. S. Lodwick
D. J. Manson
B. F. Nicholson
S. M. Zwarg
W. Stallings
S. J. Dwyer
C. A. Harlow
D. A. Ausherman
G. S. Lodwick
A set of goals and approaches for education in computer science ...... .
Computer science education-The need for interaction ............ .
Operating systems principles and undergraduate computer science
curricula .................................................. .
Theory of computing in computer science education .............. .
SCIENTIFIC COMPUTATION-THE SOCIAL SCIENCES
Social science computing-1967-1972 ............................ .
PotentiaJ future developments in social science computing ......... .
A computer model of simple forms of learning in infants ........... .
An information management system for social gaming ............. .
PROGRAMMING· FOR PROCESS CONTROL AND REAL TIl\IE
APPLICATIONS
The development of process control software ..................... .
Future trends in software development for real-time industrial
automation ................................................ .
Scheduling of time critical processes ............................ .
ACM PRIZE PAPERS IN PROGRAMMING LANGUAGES AND
SYSTEMS
A class of allocation strategies inducing bounded delays only ....... .
On modeling program behavior ................................. .
A SPECTRUM OF MEMORY STORAGE SYSTEMS, NOW AND
IN THE FUTURE
GRAPHIC SOFTWARE
COMPUTERS IN SECONDARY EDUCATION
The impact of computing on the teaching of mathematics ......... .
Computing in the high school-Past, present and future-And its
unreasonable effectiveness in the teaching of mathematics ....... .
1043
W. Koetke
1051
W. Stenberg
LSI PERSPECTIVES-DESIGN AUTOMATION: DESIGN AND
SIMULATION
1059
1065
1071
1079
H. W. vanBeek
J. J. Teets
N. B. Rabbat
M. A. Mehta
H. P. Messinger
W. B. Smith
Computer-aided drug dosage ................................... .
1093
Automated therapy for non-speaking autistic children ............. .
1101
L. B. Sheiner
B. Rosenberg
K. L. Melmon
D. C. Smith
M. C. Newey
K. M. Colby
Computer-aided design of MOS/LSI circuits ..................... .
The role of simulation in LSI design ............................ .
Implementation of a transient macro-model in large logic systems .. .
Functions for improving diagnostic resolution in an LSI environment ..
DEVELOPMENTS IN BIOMEDICAL COMPUTER TECHNOLOGY
An inferential processor for interacting with biomedical data using
restricted natural language .................................. .
An information processing approach to theory formation in biomedical
research ................................................... .
The clinical significance of simulation and modeling in leukemia
chemotherapy .............................................. .
Interactive graphics software for remote terminals and their use in
radiation treatment planning ................................ .
Automated information-handling in pharmacology research ........ .
1107
D. W. Isner
1125
H. Pople
G. Werner
1139
T. L. Lincoln
1145
K. H. Ryden
C. M. Newton
W. Raub
1157
THE IMPLEMENTATION GAP IN MANAGEMENT
INFORMATION SYSTEMS
Where do we stand in implementing information systems? ........ .
MIS technology-A view of the future .......................... .
Selective security capabilities in ASAP-A file management system ..
1167
1173
1181
A graphics and information retrieval supervisor for simulators ...... .
NASDAQ-A user driven, real-time transaction system ........... .
1187
1197
J. C. Emery
C. Kriebel
R. Conway
W. Maxwell
H. Morgan
J. L. Parker
N. Mills
1207
1211
H. G. Cragon
M. J. Flynn
LSI PERSPECTIVES-THE BOUNDARIES OF COMPUTER
PERFORMANCE
LSI perspectives-The last five years ........................... .
Towards more efficient computer organizations ................... .
An appraisal of compiler technology
by ROBERT M. McCLURE
Consultant
stood that we are mainly talking about so-called "production" compilers. By this we mean compilers for important languages that are intended for translating programs that are expected to be run extensively. l\Ioreover, we restrict our consideration to compilers for
medium and large scale general purpose computers. The
subject of compilers for minicomputers and special
purpose computers is deserving of considerable study on
its own. Also research compilers, "quick and dirty"
compilers, and pedagogic compilers will not be considered in this commentary. Finally, it is inevitable that
someone's favorite technique will be given a short straw.
For this we plead for tolerance.
INTRODUCTION
Although the last decade has seen the implementation
of a very large number of compilers for every conceivable language, the literature on compiler writing is still
unorganized. There are many papers on formal languages, syntactic analysis, graph theoretic register assignment, and similar topics to be sure. But, they are
not very useful in helping the newcomer to the field
decide how to design a compiler. Even the recent books
in the field are more encyclopedic in nature than instructive. The best single book available is Gries,! which has
a good bibliography for further study.
The few open descriptions of compilers that do exist
rarely are candid about the mistakes that were made.
This is, after all, human nature. lVloreover the nature of
scientific publishing is not conducive to papers of an
evaluative or subjective nature. The principal reason,
therefore, for writing this paper, is not to add to the basic
body of scientific knowledge, but rather to provide a
few value judgments on how compilers are being written and should be written. Since subjective statements
should always be prefaced with "It is my opinion that",
the indulgent reader will understand that this phrase
should be applied to the entire paper.
There is an enormous amount of material to be studied in connection with compiler design. lVlost of it is
very difficult to read. vVe refer to the listings of the compilers themselves and associated internal documentation. At present there is no alternative to obtaining a
comprehensive knowledge of the field. Even if one is
willing to put forward the effort, however, much of the
material is difficult to obtain. The desire of computer
manufacturers and software houses to protect their latest ideas interferes with a free flow of information. The
result of this is the growth of an oral tradition for passing information much like the wandering troubadours of
yore. Until this changes, there will be hardships worked
on those who would like to learn the trade.
In order to reduce this paper to manageable size and
to make generalizations more useful, let it be under-
SYNTACTIC ANALYSIS
In the area of syntactic analysis or parsing, the necessary solutions are clearly at hand. Parsers are now routinely constructed by graduate students as class projects. The literature on the subject is extensive, and new
techniques are revealed regularly. Almost all compilers
are written using only two of the many available methods however: recursive descent or precedence. Rarely
are either used in pure form. Compilers that use both
methods intermixed are common. Although both of
these methods have their roots in the very earliest compilers, they remain the mainstays of the business.
Recursive descent
The basic idea in recursive descent is that there is a
one-to-one correspondence between the syntactic units
in the formal description .of the language and routines
for their recognition. Each routine examines the input
text by either scanning for specified terminal tokens
(usually produced by a separate lexical analyzer) or by
calling other routines to recognize non-terminal syntactic units. Figure 1 is a flowchart of one such simple
recognizer. Because most practical languages are defined recursively, the recognizers must themselves be
1
Spring Joint Computer Conference, 1972
2
6p-<"'"""OiO">- Ep--< ""'0"'"'>-~-<""'""'"'>-F
T
ERROR
Figure I-Recognition routine
recursive. Upon exit from each procedure, either the
required syntactic unit has been recognized· and the
appropriate actions taken, or an error message has been
produced.
Recursive descent analyzers are usually written so
that it is never necessary to "back up" the input stream.
If an impasse is reached, an error indication is given,
perhaps a correction attempted, and the scan resumed
at some readily recognizable token, such as ";". The
knowledge of the context at the time an error is discovered allows more meaningful diagnostics to be generated than with any other technique.
The use of recursive descent usually requires the rearrangement of the formal syntax, since left recursions
must be removed. Although this is not difficult, it does
somewhat spoil the clarity of the approach. For peculiar
grammars, it is easier to use recursive descent than to
transform the grammar into a form suitable for precedence analysis. Although the methodology is basically
ad hoc, recursive descent is the most widely used
method of syntactic analysis.
Recursive descent has one further advantage for a
language with a large number of productions. Precedence methods seem to require table sizes proportional
to the square of the number of syntactic units, whereas
recursive descent recognizers are roughly proportional
to the grammar size.
Precedence analysis
The idea that operators have varying degrees of
"precedence" or "binding-power" is quite old, and has
been used in some of the earliest compilers. The formalization of precedence relations between operators actually started with Floyd2 in 1963. Now it is more
customary to define precedence relations between all
syntactic units. While very few producti0Ii compilers
have used a formal precedence parser yet, the modern
implementation of these techniques such as described
by lVlcKeeman,3 is clearly destined for wider use.
The fundamental attraction of precedence methods
lies in the automatic construction of analyzers from the
formal grammar for the language to be analyzed. Parsers
built in this way can be quickly changed to reflect
language changes simply by changing the tables without
modifying the underlying interpretation algorithm.
Furthermore, if the tables are constructed by formal
methods, the language accepted is exactly that specified and no other. This considerably simplifies the construction of bug-free parsers.
There are some drawbacks to parsers built wholly
around precedence methods. For example, many
languages in everyday use, such as COBOL and FORTRAN can simply not be made into precedence languages. Even PL/I can only be fit into the correct mold
with considerable difficulty. 1Vloreover, the tables required can be quite large.
A major problem with precedence parsing methods is
the problem of recovery from source program errors and
the issuance of good diagnostics for such errors. Several
approaches to solving this problem have been tried with
only modest success. Various techniques for reducing
the size of the tables required, such as the introduction
of precedence functions, serve only to complicate this
problem.
Nevertheless, there are several conditions that suggest strongly that a precedence parser of some variety
should be tried. If, for example, a parser must be produced in the shortest possible time. Precedence parsers
tend to be easy to debug. A further advantage is gained
if the language is being designed at the same time as the
compiler, since the language can be made into a precedence language. Finally, a precedence parser is often a
most suitable alternative when recursive procedure calls
required for recursive descent parsing are either impossible (as in FORTRAN) or expensive (as in PL/I).
Mixed strategies
A number of compilers use the technique of recursive
descent for analysis of the larger syntactic units such as
statements, and turn to precedence methods for parsing
expressions. In this case, simple operator precedence
analysis is customarily used. There is no conceptual or
practical difficulty in accomplishing this since the expression recognizer requires relatively small tables which
may easily be hand constructed. The number of calls on
procedures is minimized (normally a high overhead
item) and perhaps the best of both worlds is achieved.
The idea of mixing parsing techniques can be generalized. It appears (with no theoretical foundation as
yet) that a good partition is achieved when the subgrammar to be parsed with a precedence parser results
in a relatively dense precedence matrix, and the subgrammar to be parsed with a recursive descent parser
would result in a relatively sparse (for legitimate symbol pairs) precedence matrix.
Appraisal of Computer Technology
INTERNAL REPRESENTATION
Generation of code occurs simultaneously with syntactic analysis only in very small compilers and quick
and dirty compilers. In most compilers the results of
syntactic analysis are stored for later code generation.
A number of ways have been described for the internal
representation of the results of parsing, two of which
have attained really wide usage: tree structures (most
usually a form known as triples) and late operator
Polish notation. Figure 2 illustrates several forms of the
representation of a simple expression. Form (a) is a
binary tree, called triples when recorded in the tabular
form shown, since each line consists of an operator and
two operands. The result of each operator is known implicitly by the line number of the triple. Form (b) is a
tree form with variable sized nodes. Form (c) is the Polish form and is actually the string that results from traversing the terminal nodes of a parse tree in a prescribed
order.
The simpler compilers prefer the Polish representation since subsequent processing usually amounts to
simply a linear reading of the text. Fortunately the
order in which action is to be taken by the code genera-
A+ B + C * D
3
tor is very nearly that of tokens in the Polish string anyway. Since this is also the order of generating the Polish
string, the only advantage gained from deferred generation is that obtained by a full reading of all of the text,
including declarations, implicit as well as explicit. Although optimization can be implemented on internal
representations in Polish form, tree forms are much
easier to work with.
A further advantage of Polish strings is that they may
be easily written on and read from sequential data files,
are conceptually simple, and require a minimum of additional space for linkage information. If memory space
is at a premium or the simplest representation is preferred, Polish strings are recommended.
Complete representation of the source program in
tree form is now growing in popularity, and has appeared in quite a number of the more recent compilers.
It is especially prevalent in compilers for major languages for the larger machine in which optimization is
important. The ease with which the program can be
searched and/or rearranged is the primary motivation
for this selection. For building a generation system based
upon formal semantics, an internal tree representation
is a good choice. Not only does it appear that code generation can be formalized but also that optimization
strategies can be formalized utilizing the idea of transformation sets defined over trees.
SYlVIBOL TABLES AND DICTIONARIES
1
*
C D
2
+
B
3
+
A (2)
1
C
2
3
D
4
B
5
6
*2 (1)
+3 (3)
BINARY TREE
(B)
FULL TREE
(c)
POll SH STR I NG
Figure 2-Internal representations
A
(1)
Considerable effort has gone into devising symbol
table routines that have all of the desirable properties
of compactness of storage required, speed of access, and
simplicity of construction. The result is that almost all'
compilers use some variant of the hash link method.
In this method, the symbol to be looked up is first
hashed into a reasonably small range such as 31 to 512.
This hash index is then used to access the head of a list
of symbols with the same hash value. This is shown
schematically in Figure 3., This hash chain is frequently
ordered, say alphabetically, to reduce further the lookup time.
The dictionary information associated with each symbol may either be included directly with the external
representation or be contained in a separate table. Since
in a multiple pass compiler, the external representation
is not required after the lexical analysis is complete,
the separation of symbol table and dictionary has become customary.
It is becoming increasingly important to make provision for symbol tables and dictionaries to grow beyond the bounds of the available main memory. This
presents no unusual problems for hardware systems that
4
Spring Joint Computer Conference, 1972
tive size of these tables could only be statistically determined, unnecessary limitation in the size of programs
that could be compiled frequently occurred. During the
1960's however, dynamic allocation of storage came
into· widespread use. Although many techniques have
been invented, only two have proven extremely popular: movable, contiguous tables, and block allocation.
o
~
N-l
HASH
TABLE
(CHAIN HEADS)
Movable tables
~l
B EE
\
tc
" - - - - 1
SYMBOLS WITH'IDENTICA'-.HASH VALUES
~
~
Figure 3-Hash chain symbol table
support virtual memory, but does require careful attention if it must be strictly software supported. The
simplest and usual method is to divide the space required into pages and to address this space through an
availability table. This method is used in the IBM
PL/I compiler (F-Level) to allow the compilation of
very large programs on a relatively small machine. In
designing symbol table methods for use with software
virtual memory, a premium is placed on minimizing the
number of references to different blocks.
Compilers for block structured languages with immediate code generation usually allocate new dictionary
entries in stack fashion. That is, new entries are placed
in first position on the correct hash chain. Searching the
hash chain then automatically gives the correct instance
of the symbol searched for. At block closure, all the
chains are pruned until an enclosing block number is
found. The table is then shortened to the level that
existed at block entry. In this way, symbol table entries
that are no longer needed by the compilation are
constantly discarded. Although PL/I is block structured, this very simple approach is not available without refinement. In PL/I, declarations may at any point
be made in enclosing blocks. For examples, lables on
entry statements belong to the immediately enclosing
block, implicitly declared variables belong to the outermost block, and variables declared with the EXTERN AL attribute are scopeless.
The conceptual simplicity of having tables in consecutive memory locations is a major reason for adopting the idea of "floating" tables. The additional burden
of referencing all entries indirectly through a current
table base pointer is a small price to pay for this simplicity. First used in compilers by Digitek in a series of
minicomputer compilers and by IBM in a COBOL compiler for the IBlVl 7090 in the early 1960's, the basic
ideas have been widely adopted. Modern computer
architecture that makes both base addressing and indexing simultaneously available makes implementation
extremely simple.
Every table is allowed to grow (or shrink) independently. Before any table expands, a check is made to see
if there is available space. If not, space is made available
1
1
~XX
2
3
4
~.I
4
IXXX)(
5
5
TABLE MANAGEMENT
BEFORE
Early compilers had fixed size tables for storing information needed during compilation. Since the rela-
AFTER
Figure 4-Movable table storage allocation
Appraisal of Computer Technology
by actually copying the data items in the tables to be
moved into another location in memory. Although copying data in memory to reorganize storage seems inefficient at first, it turns out to be quite satisfactory in
practice since it occurs rarely. Figure 4 shows how tables
are rearranged to allow available space for all tables to
grow.
The interesting questions about this form of allocation revolve around deciding how much of the available
space to allocate to each table. Garwick suggests that
space be allocated in proportion to how much each table
has grown since the last allocation. CITRUS (the storage allocation package in the IBlVl COBOL compiler)
required specification of the desired increment of space.
Most common is dividing the remaining space proportional to the current size of each table (with some prescribed minimum). All methods will run out of space
only when there is absolutely no more. This may not be
desirable, though, since considerable time will be spent
trying to squeeze in the last item before overflow occurs.
lVlovable tables seem to work best for relatively small
memories, for machines in which internal speeds are fast
relative to 1-0 speeds, or for systems in which all available memory is allocated to the compiler at the start of
any compilation.
List structures are complicated by the necessity to
use relative links rather than absolute addresses and to
identify the table pointed to.
B lock allocation
Block allocation methods are the second most popular
storage management technique. In this case, tables are
not kept in contiguous locations, and information is
usually linked together. Each routine that may add data
to a table is responsible for requesting a block of suitable size (sometimes a system fixed size) for the purpose
at hand. Usually space is allocated in multiples of the
basic element size of the table at hand in order to avoid
calling the main allocator too often. Since OS/360 implements this form of allocation as a primitive in the
operating system, this form of allocation has been quite
widely used on that machine.
This technique does have the principal advantage
that since table segments are not moved after allocation, absolute pointers may be used in list structures.
It suffers from the drawback that storage fragmentation
can occur and may prevent usage of all available flemory.
Block allocation is suggested whenever memory is a
resource to be shared with other simultaneous users of
the machine in a multiprogramming environment. This
is because it is desirable to minimize the amount of
,,)
memory required at any given time, and most main
memory allocation algorithms supported by operating
systems do not guarantee that additional memory will
be allocated contiguously with previously allocated
memory.
IMPLEl\1:ENTATION TECHNIQUES
Early compilers were invariably written in assembly
language; most still are today. It was originally felt
that only assembly language could yield the efficiency
that was required in such a widely used program as a
compiler, and that the required operations were not well
supported by higher level languages. Although it has
now been generally recognized that very little of any
compiler needs to be "tightly coded" to achieve nearly
the same efficiency, the tradition of assembly coding is
dying a slow and painful death.
A second reason usually given for writing a compiler
in assembly language was to minimize the space that the
compiler required for its code. Factors of 1.5 to 3 have
been cited. With the growth of main memory sizes available, the almost universal availability of random access
secondary storage, and the common use of dynamic
loading techniques, the requirement for small code has
been considerably reduced in importance.
Advocates of coding in "higher level" languages have
not always been completely candid in their arguments
either. It is frequently stated that one of the main motives for using a higher level language is the gain in readability that occurs. Anyone who has tried to read a
compiler written in FORTRAN knows that this simply
is not the case. A much stronger case may be made for
PL/I or ALGOL. The fluidity of these languages plus
the natural benefits of block structuring generally result in code substantially more readable than assembly
code.
A major drawback to most higher level languages for
coding compilers is that the native data types manipulated in these languages are neither those required in
either lexical scanning, nor those required for table
management. Both of these are vitally important in
compiling, and result in the construction of subroutines,
frequently in assembly code, to support them. The linkage overhead in using these routines can be substantial.
By all odds, the most compelling reason for using a
higher level language is the conciseness with which code
can be written. The sheer laboriousness of assembly code
is a major obstacle to its use. One of the best measures of
the suitability of a language for a particular purpose is
the number of characters that must be written to achieve
the desired result. Since error rates in programming are
almost independent of the language being written, con-
6
Spring Joint Computer Conference, 1972
cise programs will have fewer bugs than verbose programs.
LDS (Load Stack), and is written as:
LDS
LDS
A
B
Pops
One approach that has gained a number of particularly ardent adherents is that of writing compilers in an
interpretive language. This idea seems also to have
originated in the early 1960's. Although the COBOL
compiler for the IBJVI 1410 was written in interpreted
code, the main source of the popularity was the series of
(mostly FORTRAN) compilers 'vrit~en by Digitek. A
number of syntax directed compilers of the same vintage
utilized an internal representation of a similar nature.
The increased suitability of current computer instruction sets for compiler writing has caused the technique
to largely fall from favor for large machine compilers in
recent years. The technique has much to recommend it
for some applications, though, and it is worthy of a few
comments.
Since there have been no published papers on the
Digitek POP system, which appears to be the most
highly developed system, we will include here a somewhat more complete description than for the other ideas
discussed in this paper.
The name POP derives from the Programmed OPerators on the SDS 910 for which the first Digitek FORTRAN compiler was written. These were a series of unassigned operation codes that caused a trap to a location distinct for each such op-code. This enabled the
user to define the meaning of each of these op-codes by
a subroutine. Subsequently, for other machines which
did not have such a feature, a completely interpretive
system was substituted.
The POP system consists of a set of operations that
resemble single address instructions. The single operand
in each POP is either a single data element (usually an
integer but perhaps a pointer into a table, etc.), a character, a string of characters (this is handled indirectly), a
table (movable), or a flag. Additional data types are
defined as needed. Tables are implemented as contiguous, movable tables as previously described. A pointer
is defined as having a table number part plus an offset
into a table. Pointers are used for forming linked structures and for referencing data in tables if other than the
last item is to be referenced. Tables are normally used
like stacks. One table is distinguished as the main stack
and is often used as an implicit second operand. Another
table is distinguished as the stack used to save return
addresses in procedure calls. Recursion is therefore quite
natural.
To illustrate how this system is used, we will define
several of the more common POP's. The first POP is
This sequence of two POP's is interpreted as follows:
the data item A, a single work item, perhaps an
mteger, is placed on the main stack, extending it by one
word in the process. Then the item B is added to the
stack, extending it once again. At the conclusion the
stack appears as in Figure 5. The end of stack it~m is
referred to as item 0 and the next item (A) is referred to
as item 1.
The POP STS (Store Stack) is simply the converse.
For instance:
STS
A
STS
B
~irst
stores the end item of the stack in cell A, and shortens
the stack. The second POP stores the new end item in
cell B and shortens it once again. The net effect of the
four POP's we executed is to exchange cells A and B.
Similarly, the stack may be loaded with the end item
on any table by MOF (Move Off) which has as an
operand a table number. The effect of this is to lengthen
the stack and to shorten the table specified as the
operand of the instruction by moving one word of data.
This operation is usually defined to set a global flag to
FALSE rather than to move an item if the table specified is empty. The companion operation is lVI0N (Move
On). Hence to move the contents of one table into
another, the four instruction loop suffices:
LA
MOF
BRT
lVION
BRU
TAB LEI
ALLDONE
TABLE2
LA
2
END OF STACK
A
B
Figure 5-Picture of end of stack
1
a
Appraisal of Computer Technology
The two new instructions above are BRT (Branch True)
and BRU (Branch Unconditional).
Character scanning is done with primitives of the
form
CRS
character
The POP CRS (Character Scan) has as its operand the
internal representation of a character. If the specified
character is the next in the character input stream, the
input scanning pointer is advanced and a global flag set
to TRUE. Otherwise the global flag is set to FALSE.
Similarly a complete string may be matched with SCN
(String Scan), as in
SCN
"BEGIN"
Subroutine calling is done with BRS (Branch and
Save) which stores the return address in a stack. The
natural implementation of recursion leads most POP
written compilers to be of the recursive descent variety.
For instance the sequence of code required to recognize
the syntax SU1VI :: = TERl\1 {+ TERl\/I }* is as simple
as
BRS
TERM
SUM
CRS
"+"
BRT
SUM
RET
The POP system is fleshed out with instructions for
packing and unpacking data words, creating instructions, setting and testing flags, and so on almost ad
infinitum. In theory, a POP compiler can be moved
from one machine to another simply by writing a new
interpreter for the next machine. In practice, this is not
feasible because the bulk of the work in writing a compiler is in designing the code generation strategy, which
must be rethought for any new machine in any event.
POP compilers are considerably more compact in
code than machine coded compilers, especially where
there is an addressability problem (such as in a minicomputer). Fortunately this is the place that compactness is needed most. POP written compilers are, however, slower than machine coded compilers not only because of the interpretive overhead, but also because of
the redundant work done in moving data through the
stack. This problem is masked in minicomputers since
their computing power is very high relative to input
output speeds of paper tape and teletypes.
The synopsis is that POPs are a fairly good way to
write very small compilers for minicomputers and a
poor way to write compilers for large machines.
7
at least some mention. The idea of using a TWS is very
appealing, but in practice the use of TWS has not proven
much of a boon. The reason is quite simple. To date,
TWS has done a good job of lexical scan, parsing, and
the dictionary parts of a compiler, but has made few
inroads into the most difficult parts, namely code generation and optimization. Even if the facilities provided
by a TWS are valuable, the penalty of forcing a user
into a prescribed mold has been too stiff for most production compiler writers to bear.
CODE GENERATION
Code generation has traditionally been one of the
most ad hoc (and bug-ridden) parts of any compiler.
There is some evidence, though, that this is changing
rather rapidly. Formally, the generation of code is the
attaching of semantics to specific syntactic structures.
In the case of immediate generation, of course, opportunities for substantially altering the source order
are minimal and conversion of the parse back into sequences of instructions proceeds strictly on a local basis.
The actual generation of code is accomplished either by
open sequences of code that construct the required instructions or by the equivalent of macro sequences
selected by combination of the operator and the associated operand types. In the latter case, the macros
are usually described in a format similar to the assembly
language of the target machine. Conditional features
similar to conditional features in macro assemblers are
used to improve on the quality of code generated. Provision is normally made to test the state of the target
machine as well as supplementary information about
the operands. The macros also update the state of the
target machine.
In multipass compilers, there is now a move to systematize code generation by formal tree transformations so that all data conversions, register loadings, and
the like, are explicitly recognized in the tree structure.
Most of the current work in formal semantics is along
this line. Information may be collected during tree
traversals which aids considerably in the production of
high quality code.
Whether the code is produced by conventional or
table driven techniques is far less important that the
organization of the generation as a sequence of transformations rather than as a complex series of decisions
based upon global data left as side effects of prior generation.
Translator writing systems
OPTIMIZATION
As an implementation technique, the use of one of
the many extant Translator Writing Systems deserves
One of the most important differences between production compilers and experimental compilers is that
8
Spring Joint Computer Conference, 1972
most production compilers try much harder to generate
high quality code even at the expense of considerably
slower compiling. This tradition dates from the very
first FORTRAN compiler. At that time, it was felt
necessary to compete with hand generated code in
quality in order to gain acceptance. Since that time
much effort has gone into finding ways to improve the
quality of code generated by compilers. Unfortunately,
the matter is too tightly bound up with the specifics of
the language at hand. FORTRAN, for example, is relatively easy to optimize. PL/I, on the other hand, is
almost impossible due to the significance of side-effects
in the language. If, of course, optimization information
is supplied by the programmer (which is rarely done),
the problem becomes more nearly like that of FORTRAN.
After carefully sifting through all of the forms of
optimization that have been used however, there are
only two areas Qf optimization that have sufficient payoff to warrant consideration, unless super-optimization
is being attempted. That is, there are only two issues in
addition to strictly local improvements in generated
sequences. These two areas are register assignment and
address calculation.
Optimal register assignment
Also dating back to the earliest compilers is the problem of optimal assignment of the registers available in
the machine. If a computer has only one register of a
given class, or a very large number, the problem is
minimal or does not exist. However, for common
machines with 3 to 16 registers in a register class, the
advantage to finding the correct data items to maintain
in registers can be substantial. This is particularly true
of values used for array accessing. Although there have
been numerous papers on this subject, the general problem is still unsolved. Even the most satisfactory approaches require an excessive amount of computation
to find an optimal solution.
The consequence of this dilemma, is that most compilers that do not do flow analysis usually simplify the
problem by merely keeping a simple record of register
contents. Loads and stores are then done on a strictly
local basis. This works quite satisfactorily for all except
the most demanding requirements.
A ddress calculation
One of the most important forms of non-trivial optimization and one that requires at least a modicum of
flow analysis is the calculation of subscripts within a
loop by repeated addition of some precalculated value
to an address rather than a full recalculation of the address. This is best shown by the simple loop:
DO
K = 2T099;
A(I, J, K) = A(I, J, K +1) + A(I,J, K - 1);
END;
The address calculations required can be drastically reduced with only two observations. First, all three array
addresses are related to each other with only a constant
difference. Second, consecutive executions of the loop
body require only that the address be adjusted by a
constant amount. The first of these simplifications is
called common subexpression elimination. The second
is called recursive address calculation. (It has nothing
to do with recursion in the programming sense. Here it
is really an iteration.)
Gear4 reports on a reasonably straightforward way of
accomplishing this by consecutive passes over the parsed
program in alternating directions. Although his technique is applicable without alteration only to explicit
loops in the program with no local branching to disturb
the movement of code, with more extensive flow analysis
this can be generally accomplished.
Although common subexpressions other than subscript expressions can be located and moved, the benefits are not impressive and there are perils. The necessity
of avoidance of altering the side effects of the evaluation
is often underestimated. For this reason, more general
common sub expression detection is not often done.
Since programs that do considerable accessing of
multidimensional arrays spend a large part of the time
in address calculation, locating common index expressions and calculating addresses recursively in loops is
recommended as one of the first targets in any compiler
intended to produce very high quality code.
SUMMARY
This has been intended as a brief overview of the way
in which production compilers are written at the present
time as seen by one of the practitioners of the art. The
word art is used here as little has been accomplished in
applying engineering techniques to compiler writing
outside of the areas of lexical and syntactic analysis.
The parts associated with declaration processing and
code generation and optimization are still very ad hoc.
The need for researchers to find better descriptive devices for generation strategies and the miscellaneous
problems surrounding the creation of real object programs is still great. The need for compiler writers to
Appraisal of Computer Technology
apply the best that is already known is perhaps even
greater.
REFERENCES
1 D GRIES
Compiler construction for digital computers
John Wiley 1971
2 R W FLOYD
Syntactic analysis and operator precedence
Journal of the ACM July 1963 p 316 Vol 10
3 W R McKEEMAN J J HORNING
DB WORTMAN
A compiler generator
Prentice Hall 1970
4 C W GEAR
High speed compilation of efficient object code
Communications of the ACM August 1965 P 483 Vol 8
9
A laboratory for the study of
automating programming*
by T. E. CHEATHAM, JR. and BEN WEGBREIT
Harvard University
Cambridge, Massachusetts
INTRODUCTION
Weare concerned with facilities at a "higher level":
translating specifications which contain much less commitment to particular data and algorithmic representations than is usual with higher level programming languages, and performing rather more drastic reorganization of representation, implied computational steps, and
even implied method of computation than is done with
traditional compilers. We imagine our end product to
be programs in a higher level language. On the other
hand, we must note that the line between the kind of
facility we will describe and a good compiler is very fine
indeed and we will suggest that certain kinds of transformations sometimes made by conventional compilers
might better be approached with the tools and techniques described here.
The purpose of this paper is to describe a facility
which we characterize as a laboratory for the study of
automating programming. We view the laboratory as a
pilot model of a facility for practical production programming. The time and expense invested in programming today and the lack of confidence that most programs today actually do what they are intended to do
in all cases is surely dramatic evidence of the value of
such a facility. The need is particularly acute when the
task to be accomplished is complex and the resulting
program is necessarily large. Such situations are precisely those encountered in many research areas of computer science as well as in many production systems software projects. Dealing with this kind of complexity,
which is to say producing efficient verifiably correct
program systems satisfying complex requirements is a
significant, decidedly non-trivial problem.
The second section of this paper contains a critical
discussion of a wide variety of work and research areas
which are related; the third section is devoted to a
broad general description of the laboratory; the fourth
section then briefly describes the ECL programming
system, the intended host for the laboratory; the fifth
We are concerned in this paper with facilities, tools, and
techniques for automating programming and thus we
had best commence with discussing what we mean by
programming. Given a precise specification of some task
to be accomplished or some abstract object to be constructed, programming is the activity of producing an
algorithm or procedure-a program-capable of performing the task or constructing a representation of the
object on some computing system. The initial specifications and the resulting program are both couched in
some (programming) language-perhaps the same
language. The process typically involves such activities
as: choosing efficient representations for data and algorithms, taking advantage of known or deduced constraints on data and algorithms to permit more efficient
computations, verifying (proving) that the task will be
accomplished or that the object constructed is, in fact,
the one desired, demonstrating that certain performance
criteria are met, and so on.
The kind of facility currently available which might
be characterized as contributing to automating programming is usually called a compiler. It typically translates an algorithm from some higher level (programming) language to a lower level ("machine") language,
attempting to utilize memory and instruction resources
effectively and, perhaps, reorganizing the computational
steps, as implied by the higher level language representation, to move invariant computations out of loops,
check most likely (or cheapest) arms of conditions first,
and so on.
Weare not here concerned with traditional compilers;
indeed, we will assume the existence of a good compiler.
* This work was supported in part by the Advanced Research
Projects Agency under contract F-19628-68-C-0379 and by the
U.S. Air Force Electronics Systems Division under contract
F19628-71-6-0173.
11
12
Spring Joint Computer Conference, 1972
section discusses, in general terms, a variety of program
au tomation techniques to be employed; the sixth section
describes the basic components of the initial laboratory ;
and the seventh section summarizes what we hope to
accomplish with the laboratory and mentions several
open problems.
RELATED WORK
There is a considerable body of work and a number of
current research areas which are related to programming automation. lVlost of this work does not, at present,
provide anything like a complete system; much of it
does provide components of a system for automating programming and is thus directly related to and sometimes
directly usable in the laboratory we will describe.
We have divided the work to be discussed into seven
different areas: automatic program synthesis, mechanical theorem proving, automatic program verification,
program proof techniques, higher level programming
languages, equivalence of program schemata, and system measurement techniques. In each case we are discussing the "vork of several people; the bibliography cites
the recent work we feel is most relevant.
A utomatic program synthesis
The basic idea here is to construct a program to produce certain specified outputs from some specified inputs, given predicates asserted true of the inputs and
the outputs as related to the inputs. The basic technique
is to (mechanically) prove the theorem that there exist
outputs satisfying the predicate and then to extract a
program from the proof for constructing the outputs.
It has been suggested that these techniques can also be
utilized to transform programs, for example to transform a recursive procedure into an equivalent iterative
procedure using the two stage process of first deducing a
predicate that characterizes the recursive procedure and
then synthesizing an equivalent iterative procedure
which computes the outputs satisfying the predicate
deduced.
We view the work in this area to date as primarily of
theoretical interest and contributing to better mechanical theorem proving and proof analysis techniques. It
is often more convenient to produce an (inefficient)
algorithm than it is to produce a predicate; the two
stage process proposed for "improvement" of programs
is awkward and, we believe, highly inefficient as compared with the direct transformation techniques to be
discussed below.
111echanical theorem proving
The heart of any system for automating programming will be a facility for mechanical theorem proving.
At the present time there are two basically different approaches to mechanical theorem proving and a realization of both these approaches provide important components of our laboratory. One approach is to construct
a theorem prover which will, given enough resources,
prove any true theorem in the first order predicate calculus with un interpreted constants; the other approach
is to provide a theorem prover which is subject to considerable control (i.e., allO\vs one to employ heuristics
to control the strategy of proof) and which utilizes interpretations of the constants wherever possible for
efficiency. l\Iechanical theorem provers of the first sort
are now usually based on the resolution principle. We
term those of the second sort "programmable theorem
provers".
Resolution theorelll provers
Robinson's 1965 paper introducing the resolution
principle has been followed by vigorous activity in
implementing mechanical theorem provers based on this
principle. lVluch of the activity has been concerned with
developing strategies for ordering consideration of
resolvents; at the present time the breadth-first, unitpreference, and set-of-support general strategies have
been studied and other variations are being considered.
It is clear that a powerful resolution-principle based
theorem prover will be an important component of the
laboratory.
Prograllllllable theorelll provers
In the PLANNER system, Hewitt provides a facility
for programmable theorem proving in the sense that one
can very easily utilize interpretations of the objects and
operations entering into a theorem to control the
strategy of proof, one can make the choice of technique
used in any particular instance data dependent, and can
very readily employ any general mechanical theorem
prover, effectively as a subroutine. The use of a small
subset of Hewitt's proposed facilities by Winograd
(called micro-planner by him; see [Winograd 71], [Sussman 70]) in his program for understanding natural language gives dramatic evidence of the effectiveness of
the approach. We thus include a programmable theorem
prover on the style of Hewitt's and Winograd's as the
basis for the theorem proving component of our laboratory.
Laboratory for Study of Automating Programming
A utomatic program verification
The work in this area is concerned with mechanization of what we term "flow chart induction". Given a
representation of some algorithm as a flow chart with assignments, conditional branching, and looping, one appends to the boxes of the flow chart predicates asserted
true of the variables at various points in the computation and, in particular, of the inputs and the outputs.
The procedure is then to attempt to mechanically demonstrate that the whole is consistent and thus that the
program is correct.
Again, we view this work as primarily of theoretical
interest. The theorem proving techniques utilized in
King's system (see [King]) are particularly interesting,
however, as they utilize interpretations of the integers
and operations over the integers; while not general,
they do provide rather more efficient methods for proofs
concerning integers than is presently possible with the
more general resolution-type proof methods which do
not employ interpretations.
Program proof techniques
A number of workers have been concerned with developing proof techniques which are adapted to obtaining proofs of various properties of programs. These include some new induction methods-structural induction and flow chart induction-simulation techniques,
and so on. This work provides a very important basis
for proving the equivalence of various programs.
Higher Level Programming Languages
A considerable amount of work in the development of
higher level programming languages has been concerned
with providing languages which are particularly appropriate for certain application areas in the sense that
they free the programmer from having to concern himself with the kind of detail which is not relevant to the
application area in which he works. For example, APL
permits a programmer to deal with arrays and array
operations and relieves him of concern with the details
of allocation, accessing, and indexing of the array elements. SNOBOL 4 directly supports algorithms which
require back tracking, providing the mechanics automati cally and permitting one to write theorem-proving,
non-deterministic parsing, and such like algorithms very
easily. SETL provides general finite sets as basic data
objects plus the usual array of mathematical operations
and predicates on sets; it thus permits one to utilize
quite succinct statements of a wide variety of mathe-
13
mati cal algorithms and to considerably ease the problem
of proving that the algorithms have certain properties.
EeL (which we discuss in some detail in a later section)
provides a complete programming system with facilities
which permit one to construct extended language facilities such as those provided in APL, SNOBOL 4, and
SETL, and to carefully provide for efficient data representation and machine algorithms to host these extended
language facilities.
Equivalence of program schemata
There has been considerable interest recently in
studying various program schemata and investigating
their relative power, developing techniques for proving
their equivalence, and so on. Most of the work to date
is interpretation independent and while, for example,
many transformations from recursive specification to
iterative specification of algorithms have been developed, it is clear that many practical transformations
cannot be done without employing interpretations.
The most common use of interpretation dependent
transformations is in "highly optimizing" compilers.
There, a very specific, usually ad hoc set of transformations is employed to gain efficiency. Often the transformations are too ad hoc-under certain conditions they
do not preserve functionality (i.e., don't work correctly).
System performance measurement techniques
It is a quite straightforward matter to arrange for
various probes, monitors, and the like to permit measurements of the performance of programs, presuming
that appropriate test input data sets are available, and
a considerable amount of work has been done in this
area. However, there are two further areas which are
now the subject of investigation which we feel may yield
important components for our laboratory. These are
mathematical analysis of algorithms and automatic
generation of probability distributions for interesting
system parameters.
Mathematical analysis of algorithms
Several people have been working recently in the
area of developing methodology and techniques for the
mathematical analysis of algorithms to obtain estimates
and/ or bounds on certain critical parameters and for
developing (and proving) optimal algorithms for certain
functions. We envision the manipulation facilities of the
laboratory as being readily adaptable to providing
14
Spring Joint Computer Conference, 1972
mechanical assistance in this activity, particularly in
the area of aiding in the inevitable symbolic algebraic
manipulation required in carrying out a mathematical
analysis.
AutoDlatic synthesis of probability
distribu tions
Some recent work by Nemeth (see [Nemeth]) may,
when it is developed further, provide an interesting and
valuable component of the laboratory. What he is trying
to do is to develop algorithms for mechanically generating probability distributions for various parameters
from a computational schema augmented by given
probability distributions for input variables and functions employed. Use of techniques like his should prove
far superior to actually carrying· out the computation
for sample data values. A mixture of mechanical generation of distributions and carrying out portions of a
computation might, in the earlier stages, provide a
practical tool.
All the above work is related and relevant to automating programming, but none, in our opinion, is adequate alone. The need .now is to integrate these facilities, techniques, and so on into a system-a laboratory
for the study of automating programming.
THE APPROACH TO BE TAKEN IN THE
LABORATORY
The goal of such a laboratory is a practical, running
system that will be a significant aid to the construction
of real-world programs. Automating programming entails transferring to the computer those facets of
programming which are not carried out efficiently by
humans. It is our contention that the activity most in
need of such transfer is the optimization (in a very broad
sense of the word) of programs. The orientation of the
laboratory and the principal task to which it will be put
is that of taking an existing program and improving
upon it.
That optimization is, indeed, a key problem requires
little defense. If "program" is taken in a sufficiently
broad sense, it is easy to produce some algorithm which
performs any stated task. Given just the right language,
program synthesis is seldom a significant issue. For
many problems, the most natural task description is
precisely a program in an appropriate notation. The use
of an extensible language makes straightforward the
definition of such notation. For other problems, it may
be that a predicate to be satisfied is a better task statement, but this too is in some sense a program. The line
between procedural and non-procedural languages is
fuzzy at best and it may be erased entirely by the use
of theorem-proving techniques to transform predicates
into programs (and conversely).
As we see the problem, the issue is not arriving at a
program, but arriving at a good one. In most cases,
programs obtained from theorem provers applied to
predicates, from a rough-cut program written as a task
description, or even from the hands of a good programmer leave much to be desired. Often, the initial program
is several orders of magnitude away from desired or
even acceptable behavior. The larger the program, the
more likely this is to be the case. The reasons are generally such defects as inefficient representation of data,
failure to exploit possible constraints, use of inefficient
or inappropriate control structures, redundant or partially redundant computations, inefficient search strategies, and failure to exploit features of the intended host
environment. Recognizing the occurrence of such defects
and remedying them is the primary goal of the laboratory.
ECL AS A BASIS FOR THE LABORATORY
The ECL programming system and the ELI language
have been designed to allow rapid construction of large
complex programs, perhaps followed by modification
and contraction of the programs to gain efficiency. The
facilities of ECL permit one to compose, execute, compile and debug programs interactively. The ELI language is an extensible language with facilities for extension on three axes: syntax, data, and operations.
The ELI language plays four roles in the laboratory:
(1) it is the language used to construct the various components of the system; (2) it and its extensions are the
language used to state algorithms which are to be
manipulated by the system; (3) it is the target language
for transformations (i.e., ELI programs are transformed
into better ELl programs); and (4) it is the host language for the theorems constituting the data base. *
The features of ELI and its host system, EeL, which
are particularly relevant to the laboratory are the following:
(a) Data types (called "modes" in ELl) can be programmer defined usi~g several basic data types
(e.g., integers, reals, characters, etc.) and, recursively, several mode valued functions (e.g.,
construction of homogeneous sequences, nonhomogeneous sequences, pointers, etc.).
* That is, the parts of a theorem (i.e., the conditions, antecedent,
consequent, and recommendation list as described in the following
section) are couched in an extension of ELl and "glued together"
as an ELl procedure by operators defined as extensions; of
course, the theorems are not "executed" in the usual sense.
Laboratory for Study of Automating Programming
(b) Procedures can be generic in the sense that a
given procedure (say that for +) can have a
number of different bodies or meanings and the
selection of a particular body or meaning to be
used is determined by the mode(s) of the argument(s) utilized in some call of the procedure.
Thus, for example, it is particularly straightforward to accommodate refinements in representation of some general data type (e.g., sets) without doing violence to algorithms defined on it by
associating a new mode with a refinement and
defining new versions of operators particularized
to that mode via the generic mechanism.
(c) The compile-time, load-time, run-time, and the
like kinds of restrictions employed in most systems are not present in EeL. In particular, the
EeL compiler is a program which can be called
at any time; it is given a program to be compiled
and a list of variables (free in that program)
whose values are to be taken as fixed. It then
converts the program to a form which takes advantage of whatever efficiencies it can from the
freezing of values. There is no distinction between compiled code and non-compiled (interpretive) code insofar as their discernible effect when
executed.
(d) EeL provides storage allocation and reclamation
mechanisms which are quite sensitive to spacej
time efficiencies. Thus, the so-called "data compiler" goes to some lengths to utilize memory
efficiently when allocating a component of a
complex data structure containing several
"pieces" .
The use of both "stack" and "heap" mechanisms
for allocation and freeing of space is also provided.
(e) EeL provides for multiple concurrent paths and
permits complete user control over the environment for each concurrent path. In addition to
permitting strategies such as employing, say, a
general resolution theorem prover to be applied
to some difficult theorem in parallel with other
undertakings, this feature makes it particularly
straightforward to set up and run some program
in an environment of ones choosing; for example,
to gather statistics on its behavior in some
simulated "real" environment.
(f) Error conditions (both system detected and
those defined by user programs) are generally
handled by setting interrupts and each interrupt
is, optionally, handled by a user defined procedure. This feature is very helpful in test execution and evaluation of subject programs and permits construction of elaborate control mecha-
15
nisms when appropriate, as might be the case in
controlling the behavior of the programmable
theorem prover.
There are two extensions of EeL which provide particularly convenient linguistic facilities for stating algorithms; these are an extension which permits one to
deal with sets and set operations* and an extension
which hosts non-deterministic programs.
OPERATION OF THE INITIAL LABORATORY
The laboratory, like EeL, is intended for interactive
use. A programmer approaches it with a problem
specification and a set of requirements on how the
program is to perform. He and the system together
undertake to produce a program which meets the
specifications and requirements. The intention is tha~
the laboratory be a practical tool for everyday use, i.e.,
that hard, real-world problems with realistic performance requirements be brought to and handled by the
laboratory.
The problem specification may be an existing program
written in ELI, possibly a long-standing production
program. In this case, the presumption is that its performance falls short of that required and that the concern is with automating its tuning. Alternatively, the
specification may be an ELI program written in a very
liberal extension and constructed solely as a concise
algorithmic statement of the problem task. There may
be little expectation that such a program will meet any
non-trivial performance requirements. Significant improvements may be needed even to reach the desired
order of magnitude. Finally, the problem specification
may be a set of predicates to be satisfied. Here the
laboratory begins by constructing an initial ELI program using as its target an extension set' designed for
this purpose. Again, such a program may be several
orders of magnitude removed from acceptable performance.
In very general terms, the laboratory is a manmachine system for transforming the initial program to
an equivalent one which meets the stated requirements.
The heart of the system is a set of transformations, actually theorems concerning the language, which preserve functionality while improving the program. Deciding whether an arbitrary transformation either preserves functionality or improves the program is, of
course, impossible, but decision procedures for the gen-
* This extension permits us to capture most of the facilities
proposed for the language SETL. See [Schwartz 70] for a particularly cogent argument for providing sets and set operations in a
higher-level programming language.
16
Spring Joint Computer Conference, 1972
eral case are not needed here. The laboratory will employ specific transformations which under appropriate
circumstances-i.e., when their enabling predicates
hold-maintain program equivalence. Constructing
these transformations and verifying that the validity of
the enabling predicates do insure functionality will be a
task assigned to humans who may, of course utilize the
facilities of the laboratory to prove the validity. While
the functionality of the transformations may be assured,
such is not the case for their effectiveness. To obtain a
sufficiently powerful set of transformations it is necessary to include many whose utility is conditional, e.g.,
those which are effective only under circumstances
which are difficult or impossible to verify analytically,
or those which optimize performance in one metric at
thB(perhaps unacceptable) expense of another. In general, the transformation set will include transformations
which are mutually exclusive (i.e., only one of some subset can be applied) and some which are inverses (i.e.,
applying two or more repeatedly will lead to a loop).
Hence, choice of which transformations to apply is
governed specifically by the performance requirements
demanded of the program and the disparity between
these and the program at each state of optimization.
Determining program performance is a crucial issue.
There are two basic approaches, both of which are used
in the laboratory. The first is analytic. The system derives closed-form expressions for program behavior
based entirely on a static inspection of program structure and interpretation of the program operations. Then
given a description of an input data set, e.g., as a set of
probability distributions for possible input valnes, the
system can describe the exact program behavior. W'henever such closed form expressions can be obtained, this
is clearly the best certification of program performance.
However, at present our analytical techniques are too
weak for any but the simplest programs. The second approach is that of actually running the program on
benchmark data sets, data sets provided by the programmer as part of his performance specifications. Between these two extremes lies the spectrum of simulation: those portions of the program which can be treated
analytically are replaced by simulation blocks and the
rest of the program is run as is. The large area of mixed
strategy is particularly powerful since it allows one to
use only partially representative benchmark data sets
yet extrapolate meaningful results from them by the
use of analytical techniques.
The utility of the laboratory will be governed principally by the specificity of admissible performance
specifications and the degree to which they can be met
on the intended machine. Performance specifications
include the obvious bounds on execution time and
space. Alternatively, they might be cast in the form:
as fast or as small as possible. This is, however, only a
rough cut. Few problems and fewer host machines are
entirely homogeneous. In real time situations, optimizing total execution time may be far less important then
attaining a certain minimum for particular sections.
Similarly, the total space occupied by a program and
its data is far less important than the distribution of this
space over several storage devices of various capacities
and access speeds. Also, the intended host machine may
be a multiprocessor or provide multiprocessing capabilities by means of special processors (e.g., graphics) or
remote processors (e.g., a network). Partitioning the
computation among the various processors so that the
computation load on each is beneath prescribed limits
is another task of the laboratory.
The possible transformations for obtaining the desired
performance vary considerably in scope, power, and effectiveness. A sketch of those which currently seem to
have the greatest payoff may give the flavor of what
may be accomplished.
The most straightforward are those for reducing the
space occupied by data. Any field containing literal
data restricted to N possible values requires, of course,
no more than [10g2N] bits. What may not be quite so
obvious is that with an appropriate programming language, simply changing declarations is all that is required to control the storage allocated, perform the coding and uncoding on data access, and handle the necessary conversions. ELI is such a language; hence, the
class of transformations is readily obtained. In the case
of sequences of literal data fields (e.g., character strings),
further compression can be obtained by block encoding.
Relations can be represented in a variety of ways and
changing from one to another often results in significant
economics. Sparcely populated arrays can be changed
to lists or hash tables in which the array indices are retrieval keys. Conversely, the space occupied by pointers
(e.g., in list structure) can be reduced if linked lists are
replaced by arrays in which relations are represented by
small integer array indices occupying only a few bits.
One candidate for optimization of both time and space
is sets and set operations. There are a number of particularly efficient representations for sets applicable
only under certain conditions (e.g., bit vectors when the
number of elements is fixed and relatively small or lists
in canonical set order when the generation of new sets is
carefully controlled) or efficient only when the set operations are circumscribed (e.g., hash tables when the
operations' are union and intersection but not set complement). When such a representation is possible, its
use will often produce dramatic improvement over
standard list structure techniques.
Laboratory for Study of Automating Programming
Transformations for optimizing time are often subtle
and require sophisticated techniques for manipulating
program structures. Perhaps the best understood sort is
the transformation of recursive to iterative programs.
Even restricting attention to uninterpreted schemas,
there are several interesting schema classes for which
the transformation can always be carried out. By adjoining additional transformations which exploit the
properties of specific common program operations, a
very powerful tool for eliminating program recursion
may be obtained.
Time can always be saved at the expense of space by
substituting the definition of a routine for a call on it.
Where recursion is absent or has been previously removed, it is possible to perform repeated back substitution until all calls have been eliminated. While too costly
in space to be employed everywhere, it is very effective
if performed on the most frequently executed portions
of the program. Aside from the obvious virtue of eliminating the expense of function call, it has the more significant virtue of allowing each back substituted defining instance to be optimized independently-in the
context of the text into which it is placed.
The principal class of time optimizations is the elimination of searches. A few such transformations are simple, e.g., the replacement of association lists by hashed
structures or balanced trees, and the substitution of arrays for lists which are frequently accessed by indexing.
Searching is, however, not confined to .lists. Structures
of all sorts-arrays, queues, strings, and so on-are
frequently searched for an element or set of elements
having some property. When the density of hits is small,
blind search is inefficient. An appropriate method is to
adj oin bookkeeping records to the given structure and
add bookkeeping code to the program so as to keep track
of what would be the result of searching. When the incremental costs of maintaining the necessary records is
small compared to the search cost, this often provides a
significant optimization. Determining what records
must be kept and how to keep them are non-trivial problems, but ones which appear open to solution at least
for many significant program classes.
A related class of program optimizations is based on
reordering computations in operations on compound
structures. Any operation on a compound object must
be defined in terms of primitive operations or its primitive components. Given a sequence of operations on
compound objects, it is usually possible to reorder the
underlying sequence of primitive operations to reduce
some computational resources. Galler and Perlis (see
[Galler 1970]) discuss in detail the problem of saving the
storage required for temporaries in matrix operations
and mention that a variation on their technique can be
17
used to minimize time. It appears possible to generalize
these results to arbitrary data structures. First, recursion is eliminated from function definitions. Then each
compound operator is replaced by its definition until
only primitive operators appear (i.e., the back substitution optimization mentioned above). Then, program
loops are merged to carry as many operations as possible
on each loop. Finally, dependency analysis is used to
find common sub-expressions and eliminated unnecessary temporaries. Any number of ad hoc, type dependent, transformations can be added to this basic
framework. The basic technique, that of unwinding
compound operations and then winding them up again
in a more optional fashion, is broadly applicable.
Several sets of transformations are concerned with
effective utilization of the particular host machine(s).
These are therefore specific to the environment, but no
less important than their general cousins. The most
important is that of partitioning the computation
among several processors. In so doing, the first step is
to take a conventional sequential program and transform it to a representation which exhibits all the potential parallelism so that sequencing is dictated only by
data dependency. The next step is to partition the transformed program among the available processors in such
fashion that (1) upper bounds on computational resources demanded of each machine are obeyed; (2)
communication between processors is carried out satisfactorily along the available data paths and (3) the entire configuration has the desired performance characteristics. Item (2) can be reduced to item (1) by treating each data path as a processor with its own (perhaps
small) computational bounds. Item (1) is, of course, the
heart of the matter. The work of Holt, Saint, and
Shapiro provides a very promising approach to this and
has already demonstrated some success in certain restricted applications (see [Shapiro 69]).
This set of program transformations is only representative. Others will be added in time as users of the
laboratory gain practical experience with and understanding of program transformation. However large
such a collection, it is only a beginning and its exact
composition is only a secondary issue. lVlore important
is the problem of determining which transformations to
use and where, given a program and a set of performance
specifications. The first step is to refine the performance measurements so as to determine precisely where
the specifications are not being met.· Correlating the
various measurements with program text is straightforward.
Given the program text augmented with resource
utilization statistics, the next task of the laboratory is
to find places in need of optimization, find one or more
18
Spring Joint Computer Conference, 1972
appropriate transformations, verify whether they are
applicable and apply them. In choosing places to concentrate attention the laboratory starts simply by looking
for the areas with the largest cost relative to that desired. Given these obvious starting places, the key problem is tracing back from these when necessary to the
causes, perhaps at some point far removed in the program. In this step, and in the choice of transformation
classes to be attempted, there will be the opportunity
for explicit guidance by the programmer. If no guidance
is given, the laboratory will doggedly pursue possible
hypotheses but the search may be cut dramatically by
human intervention.
Even with this assistance, the proposed transformations must be taken as tentative hypotheses to be explored. Few transformations always result in improvement. Many optimize one resource at the expense of
others, while some transformations are of use only for
certain regions of the data space. Hence, in general, it is
necessary to continually verify that the transformed
versions of the program are indeed improvements.
Again, program analysis coupled with performance
measurement tools will be employed.
In summary, the principal functions of the laboratory
are choosing areas of the program to be optimized, carrying out pattern matching to'determine the applicability
of various transformations, performing these transformations, and arranging for explicit· guidance by the
programmer in this process. The laboratory consists of
a set of components for carrying out these activities in
concert.
COMPONENTS OF THE INITIAL LABORATORY
As we noted previously the laboratory is, essentially, one particular extension of ECL and· that the
internal representation for programs and data employed
in ECL will be utilized for programs being manipulated
(synthesized, transformed, proved to have some property, and so on). Here we will describe the several components in the initial laboratory-the several ELI
programs and/or ECL extensions which together constitute the initial laboratory. Before launching into the
discussion, however, we want to note the influence of
the work of Hewitt and Winograd on ours; the basic
components of the laboratory have very much the flavor
of the linguistic-independent components of Winograd's
version of Hewitt's PLANNER system. Our discussion
of the components is quite brief as our intention in this
paper is to provide an overview of the laboratory and
the general approach being taken. A detailed discussion
of the current versions of the components is provided in
a paper by Spitzen (see [Spitzen 71]).
Control
There is a top-level control path* which provides the
interface between the user and the laboratory. It provides for input of the program to be manipulated and
the associated performance criteria, if any. It then arranges that the program to be manipulated is put into a
canonical form and sets up a parallel path which provides the manipulation strategy by calling for the appropriate theorem or theorems to be applied. The control path then provides for dialogue between the system
and the user so that the system can request information from the user (e.g., verification that certain constraints hold in general, test data, and the like).
Programmable theorem prover
A "theorem" in the sense this term is used in the system consists of a condition which governs the applicability of the theorem, an antecedent, a consequent,
and a recommendation list. Given some program structure, an instance of substructure matching the antecedent can be replaced by an equivalent substructure
corresponding to the consequence so long as the condition holds. The recommendation list is basically a list of
predicates which govern the use of other theorems to be
used in manipulating the structure to match the antecedent in applying this one and it is the careful use of
this "governor" which permits the theorem proving to
operate in a practicable time frame. Note that in a very
strong sense theorems are really programs effecting
transformations which, through the conditions and
recommendation lists (arbitrary ELI predicates), can
establish elaborate control and communication arrangements.
Data base
The theorems which constitute the basis for the transformations and manipulations performed by the system
are housed in a data base. There is a continually growing static component of the data base which includes
the "standard" theorems. In addition there may be a
collection of theorems appropriate to certain particular
investigations with which we will augment the data base
at appropriate times. There is also a dynamic component
which varies as a program is being manipulated. For example, If we commence dealing with the arm "p2~e2"
* ECL provides multiprogramming; "path" is the ECL terminology for a parallel path of control.
~
Laboratory for Study of Automating Programming
of the conditional expression
[pf=:::}el; p2=}e2; . . .; pn=}en]
Then we would add the theorem appropriate to "--, PI"
to the data base and arrange that it be removed when
we get to the stage of treating the conditional expression as a whole in "higher level" manipulation of the
program structure containing it.
The data base is quite large and, as various new
facilities are added to the system, the data base will
grow. Its size plus the fact that one wants to be able to
select appropriate theorems (i.e., in accordance with a
given recommendation list) from the data base efficiently, make it imperative that a certain amount of
structure be imposed on the data base. Initially this
structure basically amounts to a collection of "threads"
through the data base, implemented by a combination
of list structure, hash, and descriptor coding techniques.
It is anticipated that getting an efficient structuring of
the data base as it grows will pose a non-trivial research
problem which we anticipate being attacked with the
tools provided by the laboratory itself.
19
Measurement techniques
In addition to the usual facilities for inserting probes
to provide measures of utilization of various functions
and data elements provided in EeL and the usual
ability to obtain measurements by sampling driven by a
real-time clock there are two measurement components
in the system which are less usual. Precise delineation
of potential inefficiencies sometimes requires very exact
timing data. Unfortunately it is usually impossible to
get very fine-grained timing from most contemporary
machines. Hence, the laboratory includes a machine
language simulator for its host machine, i.e., a program
which executes machine code interpretively and gathers
statistics as requested. This permits programs to be
run unchanged while collecting very precise data on
the distribution of program execution time and storage
requirements. This data, combined with that obtained
by inserting measurement probes into the program
permits performance measurements to be made to any
level of detail. The second measurement component is
an implementation of the "probability distribution
computer" described by Nemeth.
Pattern Matcher
The process of applying some theorem to some program structure involves matching the parts of the
antecedent to acceptable corresponding parts of the
structure; in general, of course, this will involve calls on
other theorems to manipulate the structure into an
appropriate format and/or the verification that certain
conditions maintain. It is the pattern matcher which
administers this activity; it will make tentative partpart matches, reject matches or attempt them in new
ways when subsequent failure to match occurs, and
so on.
Backtracking mechanism
The pattern matcher operates as a non-deterministic
program in the sense that it makes provisional matches
which must be "unmatched" and rematched when
failure occurs to match some subsequent part of the
antecedent to the program structure being manipulated.
A backtracking mechanism must therefore be provided
so that the effects of computations and variable bindings
can be "undone." The method we use to accomplish
this is to alter the basic ELI evaluator so that, when
backtrackable code segments are executed, any change
to the environment is preceded by recording the appropriate modification to the environment which will undo
the change in the event backtracking is required.
GOALS OF THE LABORATORY
It must be stressed that the laboratory is intended
for practical use, for the attainment of useful results
which would be difficult to obtain without its assistance.
It is the deliberate intention that one be able to approach it with a non-trivial program and obtain with it
a significantly improved version. Such programs will
include applications programs, system programs such
as the ELI compiler, as well as modules of the laboratory itself.
It appears that this will be achievable even with the
simple approaches to be taken in the initial version of
the laboratory. The use of programmable theorem
provers and search techniques have made it possible to
quickly endow the laboratory with considerable expertise, if not deep insight. On large production pro" grams (which commonly are so complex that no one
really understands their exact behavior) the laboratory
may be expected to make significant improvements by
more or less· mechanical means. Such mechanical skill
is precisely what is required to complement the high
level programmer. Initially, the laboratory will serve
as a programmer's assistant, suggesting possible areas
of improvement and carrying out the transformations
he chooses, but leaving the creative work to him. Even
at this level the laboratory may serve better than the
average junior programmer. Further, the initiallabora-
20
Spring Joint Computer Conference, 1972
tory will serve as a basis for developing more sophisticated control over the choice of transformations to
be applied.
A topic which falls out as another application of this
work is the modification or adaptation of programs.
Given a program which does a certain job well, it is very
common that it must be modified to handle a related
task or work under changed conditions. Usually such
modifications are done by hand, seldom with entirely
satisfactory results. Hence, automation of the process is
attractive. One method which has been occasionally
proposed for performing this is to construct a system
which when fed the existing program, deduces how it
works, and then performs the specified modifications.
This requires the system to dig the meaning and purpose out of the existing program-an operation which
is difficult at best and perhaps impractically expensive.
A solution which shows greater promise is to use the
laboratory to combine man and machine. If programs
are developed using the laboratory, then for any
production program, there is an initial program from
which it was derived. Given a statement of the new task
to be accomplished, the programmer can make his
modifications to the relatively transparent and simple
initial program. This is still hand labor, but at a much
higher level. Applying the laboratory to the optimization of the modified program results in a production
program with the desired properties. This puts creative
work in adapting a program into the hands of the
programmer while freeing himJrom the drudge work.
It is anticipated that as the programmer gains
experience with the system, he will develop his own set
of optimization techniques. By making it convenient
for him to add to the data base these transformations
along with patterns for recognizing potential situations
for their applications, we allow a certain degree of
growth in the expertise of the laboratory. Given a clever
population of users, the laboratory should grow to some
considerable level of sophistication, at least in areas of
interest to that user population. This scenario has, of
course, its limitations. Merely expanding the data base
would, in time, cause the system. to flounder in a sea of
possible but irrelevant transformations. Hence growth
of the system must ultimately depend on significant
improvements in global strategies, local heuristics, and
theorem provers. In particular, the need for specialized
theorem provers will very likely arise.
At present, it is not clear how to proceed in these
directions, nor is this surprising. One of the purposes
of the laboratory is to gain expertise in program manipulation, determine the limitation of current techniques, and advance to the point where the real
problems can be seen clearly. The initial laboratory is
a first step, but a significant step, in this direction.
BIBLIOGRAPHY
E A ASHCROFT (1970)
M athematicallogic applied to the semantics of computer
programs
PhD Thesis Imperial College London
E A ASHCROFT Z MANNA (1970)
Formalization of properties oj parallel programs
Stanford Artificial Intelligence Project Memo AI-110 Stanford
University
R M BURSTALL (1970)
Formal description of program structure and semantics in
first-order logic
Machine Intelligence 5 (Eds Meltzer and Michie)
Edinburgh University Press, 79-98
R M BURST ALL (1969)
Proving properties of programs by structural1·nduction
Comp J 12 1 41-48
D C COOPER (1966)
The equivalence of certain computations
Computer Journal Vol 9 pp 45-52
R W FLOYD (1967)
Assigning meanings to programs
Proceedings of Symposia in Applied Mathematics American
Mathematical Society Vol 19 19-32
R W FLOYD (1967)
Non-deterministic algorithms
JACM Vol 14 No 4 (Oct.)
B A GALLER A J PERLIS (1970)
A view of programming languages
Chapter 4 Addison-Wesley
C GREEN (1969b)
The application of theorem proving to question-answering
systems
Ph D Thesis Stanford University Stanford California
C GREEN B RAPHAEL (1968)
The use of theorem-proving techm·ques in question-answering
system'S
Proc 23rd Nat Conf ACM Thompson Book Company
Washington DC
P J HAYES (1969)
A machine-oriented formulation of the extended junctional
calculus
Stanford Artificial Intelligence Project Memo 62 Also appeared
as Metamathematics Unit Report University of Edinburgh
Scotland
C HEWITT (1971)
Description and theoretical analysis of plannar
Ph D Thesis MIT January
C B JONES P LUCAS
Proving correctness of implementation techniques
Symposium on Semantics of Algorithmic Languages Lecture
Notes in Mathematics 188 New York
D M KAPLAN (1970)
Proving things about programs
Proc Princeton Conference on Information Science and System
D M KAPLAN (1967)
Correctness of a compiler for algol-like programs
Stanford Artificial Intelligence Memo No 48 Department of
Computer Science Stanford University
J KING (1969)
A program verifier
Ph D Thesis Carnegie-Mellon University Pittsburgh Pa
J KING R W FLOYD (1970)
Laboratory for Study of Automating Programming
Interpretation oriented theorem prover over integers
Second Annual ACM Symposium on Theory of Computing
Northampton Mass (May) pp 169-179
D C LUCKHAM N J NILSSON (1970)
Extracting information from resolution proof trees
Stanford Research Institute Artificial Intelligence Group
Technical Note 32
Z MANNA (1969)
The correctness of programs
J of Computer and Systems Sciences Vol 3 No 2 119-127
Z MANNA (1969)
The correctness of non-deterministic programs
Stanford Artificial Intelligence Project Memo AI-95 Stanford
University
Z MANNA J McCARTHY (1970)
Properties of programs and partial function logic
Machine Intelligence 5 (Eds Meltzer and Michie)
J McCARTHY (1963)
A basis for a mathematical theory of computation
Computer programming and formal systems
(Eds Braffort and Hirschberg) Amsterdam North Holland
pp 33-70
J McCARTHY J A PAINTER (1967)
Correctness of a compiler for arithmetic expressions
Mathematical Aspects of Computing Science Amer Math Soc
Providence Rhode Island pp 33-41
R MILNER
An algebraic definition of simulation between programs
Stanford Artificial Intelligence Memo AI-142
A NEMETH
Unpublished; to be included in his Ph D Thesis Harvard
University
J A PAINTER (1967)
SemanUc correctness of a compiler for an algol-like language
Stanford Artificial Intelligence Memo No 44 (March)
Department of Computer Science Stanford University
M S PATERSON (1967)
Equivalence problems in a model of computation
PhD Thesis Cambridge University
G ROBINSON L WOS
Paramodulation and theorem-proving in first-order theories
with equality
Machine Intelligence Vol IV Ed by D Michie
21
J ROBINSON (1966)
A review of automatic theorem proving
Annual Symposia in Applied Mathematics Vol XIX
J T SCHWARTZ (1970-71)
Abstract algorithms and a set-theoretic language for their
expression
Preliminary Draft First Part Courant Institute of
Mathematical Sciences NYU
J M SPITZEN (1971)
A tool for experiments in program optimization
(in preparation)
R M SHAPIRO H SAINT (1969)
The representation of algorithms
Rome Air Development Center Technical Report 69-313
Volume II September
H A SIMON (1963)
Experiments with a heuristic compiler
JACM (October 1963) 482-506
J SLAGLE (1967)
A utomatic theorem proving wUh renameable and semantic
resolution
JACM Vol 14 No 4 (October 1967) 687-697
J SLAGLE (1965)
Experiments with a deductive question-answering program
Comm ACM Vol 8 No 12 (December) 792-798
H R STRONG JR (1970)
Translating recursion equations into flow charts
Proceedings Second ACM Symposium on Theory of Computing
(May) pp 184-197
G J SUSSMAN T WINOGRAD (1970)
M icro-plannar reference manual
MIT AI Memo No 203 (July)
R J WALDINGER (1969)
Constructing programs automatically using theorem proving
PhD Thesis Carnegie-Mellon University (May 1969)
B WEGBREIT (1971)
The ECL programming system
Proc F JCC Vol 39
R WINOGRAD (1971)
Procedures as representative for data in a computer program for
understanding natural language
Project MAC MIT MAC-TR-:4 February
Segmentation and optimization of programs from
cyclic structure analysis
by JEAN-LOUP BAER and ROBERT CAUGHEY*
University of·Washington
Seattle, Washington
INTRODUCTION
Phase 1
Modelling of computer programs by directed graphs,
where the vertices represent the computational tasks
and the arcs show the flow of control, has been used for
optimization purposes,1,10 parallel processing evaluation,2,8 and segmentation. 7 ,9,13 All these studies are
mainly based on the fact that a high proportion of the
execution time of a program is spent in loops. Although
the cyclic structure of programs can be theoretically
complex, it has been observed that the nested ness is
seldom vBry deep.6 Thus if one wants to optimize
programs written in a high-level language, the detection
of cycles by the compiler and its use in an optimization
phase may yield a definite improvement in execution
time without having to pay too heavily for excess
compiling time. In this paper we show how a compiler
could make use of an efficient cycle detection algorithm12
to model the embeddedness of cycles by an acyclic
directed graph. The latter can then be used for packing
purposes in case of a paging or "cache" memory system
as well as for predicting t he expected number of executions of a given statement for optimization purposes.
Directed graph model-/nstruction Sequences
The basic model is a directed graph G (W, U) where
W is the set of vertices {WI, W2, .•• , wm } and U is the
set of ordered pairs (or arcs) Uk = (Wi, Wj). Vertices
represent computational tasks and arcs show the flow
of control. Methods to analyze a FORTRAN source
program and transform it into an equivalent-in terms
of control-directed graph are now \vell-known. We
shall follow Russell's approach lO and therefore we
assume the uniqueness of an initial vertex WI and
terminal vertex w: as well as connectedness of the graph.
Appendix I shows the vertices and arcs generated from
the analysis of the current source statement according
to its type. Figure 1 gives an example program (executable statements only) and its directed graph representation. Associated with each vertex Wi is a volume
attribute Vi which represents the amount of memory
words required for the machine code generated by the
translated statement.
Thus given a source program, the first part of the
modelling process yields G (W, U) which can also be
conveniently represented by an m Xm (where m = ! W !)
Boolean connectivity matrix C,9 and a volume vector
MODELLING OF FORTRAN PROGRAMS
V(!V!=m).
For clarity of exposition we present the modelling
process as a sequence of four phases. However, actions
of phases 1, 2, and some of 3 are performed concurrently.
The source program itself is scanned only once. The
four phases are now described both functionally and
in terms of the basic data structures. Detailed algorithms
can be found in Reference 4.
For reasons which will become apparent in Phase 3
we now define the / nstruction Sequences (LS.) of a
source program.
Let A be thEY class of all FORTRAN executable
source statement types which do not have the attribute
of implicit flow of control* and A its complement with
respect to the class of FORTRAN executable source
statements. Let Z = SI, S2, ... , Si, ... , Sn be the
* Present
* I.e., these statements which have as a unique immediate
successor the next statement in sequence.
address: System Services Department, Snohomish
County, Everett, Washington.
23
24
Spring Joint Computer Conference, 1972
Z' can also be represented by a directed graph
READ (5,5) K1,Il,I2,13
IF (K1) 10,20,300
10
STOP
20
K1=1
23
K1 : K1 + 1
25
Il=Il+1
IF (Il) 25,30,30
8
30
12 = 12 + 1
IF (12) 30,35,35
10
35
40
IF «Il+I2+I3) .LT. 15) GO TO 23
3900
:1(1) = (I*Il
15
3995
M(I)
~
+
K1)
4000
CONTINUE
IF (K1 - 15) 23,400,400
If!,
Identify DO-loops and their embeddedness
2*M(I)
IF ('1(1) .LT. 25) GO TO 3995
16
19
400
IF (K1 - 50) 300,300,10
20
300
DO 200 J = 1,10
In this phase we record the membership of statements
in DO-loops in the following way. Each DO-loop is
represented by an m-dimensional Boolean vector, say
d i for the ith DO-loop, such that dik = 1 if the statement
represented by vertex Wk is in the DO-loop and d ik = 0
DO 195 I = K1,50
21
22
195
N(I,J) = 2*I/3*J
23
200
CONTINUE
24
Phase 2
DO 4000 I - 1,50
13
14
17
mination of the LS.'s and their interconnections is
easy and not time consuming (Figure 2 displays these
new structures for the example program of Figure 1).
It follows the same algorithms as the one used for the
generation of branch instructions by the compiler.
IF (13) 35,40,40
11
12
13 = 13 + 1
H (I, Y) where I is the set of vertices Ii representing
the LS.'s and Yk= (Ii, I j ) is an arcE Y if the terminal
statement Sim of Ii can transfer explicitly to a statement
Sjp of I j • This directed graph can also be represented
by a Boolean connectivity matrix M.
Given Z the string of source statements, the deter-
END
Figure l-Modelof a FORTRAN program
(executable statements only)
11 = (1,2)
16 = (12)
12 = (3)
17
13 = (4,5,6,7)
18 = (17,18)
14 = (8,9)
19
15 = (10,11)
1
10
= (13,14,15,16)
=
(19)
=
(20,21,22,23,24)
(a) Instruction Sequences.
finite string of source statements which comprise a
program, in the order (on ascending index) in which
they are initially submitted to a translator. An instruction sequence I k is a non-empty substring of consecutive
elements of Z written as
2
3
4
1
1
a a a a
a a a
such that:
(i) SkjEA for 1:::;j~m-1 and SkI is called the
initial statement of I k
(ii) SkmEA and Skm is called the terminal statement
ofh
(iii) Ik is the substring of Z of maximum length
which contains Skm.
Z is partitioned into instruction sequences and can
1
a
10
5
0
a
6
0
7
0
8
9
0
a
1
a
0
1
10
0
a
1
1
0
a
0
0
a a
a
0
0
1
1
0
0
0
0
0
0
0
0
1
1
0
0
0
a
0
a
1
0
0
0
1
a
0
0
a a a
0
a a
1
1
a
0
a
1
a
1
a
0
0
1
a
0
0
a
1
a a
0
a a
0
0
1
0
a a
0
a
a
0
0
0
0
(c) Matrix M
(b) Graph H(I,Y)
now be rewritten as:
Figure 2-Alternate representations of the example
FORTRAN program
Segmentation and Optimization of Programs
otherwise. At the same time, we build a (partial)
embeddedness Boolean matrix E+ which is such that
eij+= 1 if DO-loop j is nested within DO-loop i.
The construction of the d/s and E+ is up to this point
straightforward and mainly requires the same techniques as those used generally in the compilation of
DO-loops, that is the maintenance of a stack of currently active DO-loops and their associated terminating
labels. Figure 3 shows the d/s and E+ after DO-loop
processing for the example of Figure 1.
Phase 3
Identify the remaining elementary cycles
A general algorithm to detect the elementary cycles
in a directed graph has been recently published. 12 It is
based on a path extension technique with each vertex
of the graph being a potential starting point for a cycle.
In our case, the searching time of the exhaustive
detection-a function of the number of vertices and
arcs in the graph-can be greatly reduced by the
following two observations.
(i) Ignore the feedback arcs of the DO-loops since
the corresponding cycles have already been
detected.
Ve rtex Number
11122222
78901234
123456789
0000000000011110000000
0000000000000000001110
0000000
00000000
000
0
1
0
25
TABLE I-List of Origin-Destination statements and I. S.'s
Origin-Destination
Origin-Destination
2,3
2,4
2,20
3,24
1~ 2
1,3
1, 10
2,10
3,3
3,4
4,4
4,5
6,3
7,6
7,8
9,8
9,10
11,10
11, 12
12,5
16, 15
18,5
18, 19
19,20
19, 3
7,7
8,3
8,9
9,10
9,2
5,5
5,6
(ii) In FORTRAN only a subclass X of statements
(X CA) can be origin statements of cycles. This
subclass X corresponds to statement types*:
GO TO K
GO TO L, (Kl' K 2, ••• , Kp)
GO TO (Kl' K 2 , • • • , Kp), L
IF (E) K 1, K 2 , K3
IF (B) S where S is a GO TO statement
Only statements of type belonging to X can be
starting points of cycles in G (W, U), and they are
necessarily terminal statements of 1.S. 'so Thus ,ve are
going to reduce our cycle search by looking first for
cycles in H (I, Y) and then transform these into cycles
of G (W, U). This phase is going to be processed in
three stages.
0
Stage 1. Reduce domain of search of elementary cycles
of I.S.'s
Partial Embeddedness matrix E+
Cycles
...."u
>.
u
1
1
2
3
4
0
0
0
0
0
0
1
0
0
0
0
0
Figure 3-Array D (cycle vertex membership) and matrix E+
(cycle embeddedness) after DO-loop processing of the example
program
A list of paired origin-destination statements, where
the origin statements are the terminal statements of the
1.S.'s and the destination statements are those referred
to by the labels K i, is built during the scanning of the
source program Z. The forward reference labelling
problem is dealt with in the same manner as the compiler must do for generating code. The corresponding
list of origin-destination LS.'s is also constructed (cf.
Table I for our example) .
* We restrict ourselves to the analysis of main programs or
subroutines, that is we do not include CALL statements as
statements which imply transfer of control.
26
Spring Joint Computer Conference, 1972
Figure 4 shows M* and the reduced set of LS. starting
vertices.
I. S. Number
1
,...
1
2
3
4
5
6
7
8
9
1
0
0
1
1
1
1
1
1
1
1
1
Stage 2. Find elementary cycles of I. S.' s
The algorithm already referred to 12 is used with the
short-cut of skipping those vertices which are not part
of the reduced set of possible starting points. Figur~ 5
lists these cycles.
2
0
0
0
0
0
0
0
0
0
1
3
0
1
1
1
1
1
1
1
1
1
4
0
1
1
1
1
1
1
1
1
1
5
0
1
1
1
1
1
1
1
1
1
6
0
1
1
1
1
1
1
1
1
1
7
0
1
1
1
1
1
1
1
1
1
8
0
1
1
1
1
1
1
1
1
1
Each cycle of LS.'s must be converted into cycles of
the original graph (G-cycles). It is of course possible
that a single LS. cycle may yield several G-cycles.
For example, the LS. :
9
0
1
0
0
0
0
0
0
0
1
Corresponding vertex number
10
0
0
0
0
0
0
0
0
0
0
Stage 3. Conversion of I.S. cycles to original graph
cycles (G-cycles)
QJ
§
z
.
.
U)
1-1
Starter I. S. Number
3
4
5
6
7
8
Figure 4-Matrix M* and domain of starter I.S.'s
The domain of· possible starter nodes for the cycle
detection algorithm could be further reduced as follows.
Let (h,I j ) be an origin-destination pair of LS.'s. They
will be part of a same cycle if and only if mk/ = mjk* = 1
in the reflexive transitive closure M* of the connectivity
matrix M. If these relations do not hold the origindestination pair can be deleted. However, it is debatable
. if the gain incurred by this deletiori surpasses the cost
of generating M*, a process of order greater than n 2•
10 A=B
20 C=D
IF (E) 10,20,30
1
2
3
which has one LS. cycle, namely itself, yields two
G-cycles {l, 2, 3} and {2, 3}.
The conversion algorithm may be summarized as
follows: Let Ci=I a, Ifj, ... , Iu be an LS. cycle. Recalling the definition of an LS. one can write I a = Sa,l,
Sa ,2, ••• , Sa ,mao All Sa ,ma are part of all G-cycles
generated by Ci. Let (Sa,ma, Sfj,j) be a paired origindestination statement leading from I a to 1(3. Now the
sets d i corresponding to G-cycles are obtained as
follows:
1. Initialization step. d i o= rJ> (the empty set).
2. Let a be the index of the first LS. in Ci and 13
the index of the next LS. in sequence (if there is
only one LS. 13 = a) .
C = (3)
1
C = (4)
4
C = (3,4,5,6)
2
C
C
3
=
(3,4,5,6,7,8)
s
= (5)
C = (7)
6
Figure 5-List of cycles of instruction sequences
Segmentation and Optimization of Programs
3. For each origin-destination pair (Sa.ma,
For each d ia do:
S~.j)
do:
dil = diaU {S~.j, ... , S~.m~}
4. a=~; ~='Y (set to index of next LS.). (If a=u,
~
is set to the index of the first LS.)
If a = index of the first LS. then stop; the d/s are the
last dk~ generated; else go to step 3. Figure 6 shows the
set of G-cycles generated in the Boolean notation
adopted in phase 2.
Phase 4
Complete and reduce the embeddedness matrix E+
We now want to complete E+ which was defined and
partially built during phase 2. If d i and d j are two
G-cycles in Boolean representation, then letJij=dindj.
Elements of E+ will now be defined by:
27
1
2
3
4
5
6
7
8
9
1
0
0
0
0
0
0
0
0
1
2
0
0
1
0
0
0
0
0
0
3
0
0
0
0
0
0
0
0
0
4
0
0
0
0
0
0
0
0
0
5
0
0
0
1
0
0
1
1
0
6
1
0
0
0
1
0
0
0
0
7
0
0
0
0
0
0
0
0
0
8
0
0
a
0
a
0
0
0
0
9
0
0
0
0
0
0
0
0
0
-IfJi1 = d i then eii+= 1, eii+=O (d i embedded indj)
-IfJii= dithen eii+=O, eii+= 1 (di embedded in d i )
-If Jij~di~dj then eji+ = eij+ = O.
Since the embeddedness of the DO-loops between
themselves have already been recorded, these tests are
done only for the pairs of cycles i, j where 1:::; i:::; n
(n number of cycles) , k p (if cycle does not fit entirely in a
page) go to step 16 (part C) .
B. [The cycle fits in (remainder of) page].
A. [Initialization].
1. If h=k (i.e., vector T completely traversed)
then end.
2. Let h be the index of the next (initially first)
cycle in vector T and dj be the Boolean representation of this cycle.
h=h+l;
Page
Number
j=T(h).
3. Let n be an index varying from 1 to m (the
number of vertices in G). Set n = O.
11. cp=cp+vdh ; Vq=Cp (This is part of the merging
process) .
12. n=n+1.
13. If djn = 0 go to step 15.
14. Vn = O. Merge Wn into Wq (for an explanation of
merging see below) .
15. If n=m go to step 1 (i.e., to part A) else go to
step 12.
C. [The cycle overflows a page].
4. If cp=O go to step 7.
16. cp=vn.
5. If CP+Vdh~P (i.e., if the current cycle will not
go over a page boundary) go to step 11.
17.
18.
19.
20.
6. Set cp = 0 (Start a new page) .
7. n=n+1.
8. If djn = 0 (i.e., vertex n does not belong to cycle
j) go to step 7.
n=n+1.
If djn = 0 go to step 22.
If Vq+vn>p go to step 21.
Merge Wn into Wq and Vn into Vq; cp=cp+v n;
Go to step 22.
21. q=n; cp=vn.
22. If n=m go to step 1 else go to step 17.
30
Spring Joint Computer Conference, 1972
TABLE III-Volume Vector for Example Program
Vertex 1 2
111
3 4 5 6 7 8 9 0 1 2
1 1 1 1 1 1 122 222
3 4 5 6 7 8 9 0 1 2 3 4
Volume 8 4 2 2 3 3 3 3 3 3 3 5 5
The merging process is defined by:
-To merge Wn into Wq replace qth row of C by the
logical sum of itself and the nth row of C, and
replace the qth column of C by the logical sum
of itself and the nth column of C. Set the nth
column and row of C to all O's.
-To merge Vn into Vq replace Vq by vq+v n in the
memory volume vector V and set Vn to O.
The remaining task is to assign those nodes which
are not members of cycles. It is done by following part
C above, after first initializing both q and n to 1.
Figure 8 shows the result of packing for p = 8 (a very
small page size only for illustration purpose) and the
volume vector of Table III. Although this algorithm
is crude-and we see below how to improve it-it is
worthwhile to compare its outcome with what would
have been obtained by usual compiling techniques.
Figure 9 shows how the code would be allocated in a
straightforward manner with vertices allowed to run
over pages.
As can be seen the total number of pages required for
the generated code is smaller in the usual compiler's
case (7 instead of 10). However, the goal of the packing
algorithm is to improve the residency of the pages, i.e.,
the locality of the code. In general the number of data
pages needed for efficient execution is much greater
than the number of code pages; the packing algorithm
thus helps in leaving more main memory space to data
during long bursts of execution. For example, loops
(W6, W7) (WIO, Wll) and (W22) occupy one page instead
of two. Moreover, as stated earlier, the packing algorithm can be improved. A first clean-up pass could
be implemented as follows:
If after the merging process, Cji = 1 (i.e., pages i and
j are connected) and Vi+Vj~P (the sum of their
memory volumes is less than a page), then merge
Wi into Wj and Vi into Vj.
In our example, pages 16 and 17 would be merged,
as well as pages 18 and 19, thus leading to a definite
improvement in the second part of the main cycle.
A more sophisticated clean-up pass would be first to
"squeeze" those elementary cycles which are leaves of
the forest, by allowing vertices to run over pages. (In
6 5 4 3 4 4 5 5 8 3
2
our example WI6 would be in pages 15 and 16.) Then the
clean-up pass defined above would be invoked. Figure
10 shows the results of the improved algorithm. The
main loop requires now only 8 pages; the number of
interpage transitions is diminished, and the locality of
the code is improved.
EXPECTED NUMBER OF EXECUTIONS OF
SOURCE STATEMENTS
The knowledge of the expected number of times a
given source statement is going to be executed can be
an important factor in the optimization of high-level
source programs. 6 ,IO It allows replacement of compilergenerated code by a tighter hand-coded version in the
Figure 9-Usual memory allocation by a compiler
(all pages have volume 8)
Segmentation and Optimization of Programs
event of an often-repeated statement. In the context
of the previous section, the traversal of the tree could
be monitored by the maximum expected number of
executions, instead of being directed by maximum
levels, thus leading to a better residency of pages of
code.
In this section we show how these numbers can be
estimated when i) the probabilities q/ of traversing
the arcs (Wi, Wj) corresponding to paired origindestination statements are known, and ii) when the
mean number of times the feedback arc of a DO-loop
is set up to be traversed is known. These parameters of
the source program will have to be "guessed" or instrumented. Io In the former case they represent a first pass
at the analysis of the program and only well-known
sections of it should be optimized. In the latter, they
correspond to an "a posteriori" optimization of a
production run. In both cases, we assume that we have a
31
Markovian process, i.e., the qJ stay invariant each
time Wi is reached.
Travel'sal of the directed graph
The method we outline is an outgrowth of studies
related to the prediction of performance of multiprocessors. 2 •8 Let fi be the expected number of executions of vertex Wi, Pi its probability of being reached
from the initial vertex WI when all feedback arcs of the
graph have been removed. In the case of a stochastic
cycle, i.e., one which is not a DO-loop, this feedback
arc is the one corresponding to the last paired origindestination statement encountered when transforming
the LS. cycles to G-cycles, and of probability not equal
to 1. After normalizing the probabilities of arcs incident
out of vertices which are origins of feedback arcs, one
computes the Pi as:
k
(1) pi=
L
pjq/ where
Wj
(j = 1, ... , k) are the
j=I
immediate predecessors of
all fi are set to 1.
Wi.
At initialization
The traversal of the directed graph represented by
the original embeddedness matrix E is performed aEl
follows.
1. Let dI , d2, ••• ,dk be the leaves of the graph.
Partition these leaves into classes El = {d1 },
E 2 = {d2 },
•••
,Ek = {d k }.
2. If two classes Ei and E j are such that there
exists diEEi and djEE j such that dindj~cp, let
Ei=EiUEJ and suppress E j •
3. Repeat step 2 until no suppression occurs.
4. Compute the fi (up to that point) of each
vertex member of a cycle belonging to one of the
Ei left after step 3, as explained belmv.
5. Suppress from E all the leaves and repeat steps
1 to 4 until all cycles have been treated.
Steps 1 to 3 are facilitated by the use of the tabular
representation of the graph. They involve mainly the
partition of cycles into classes with the equivalence
relation being "to have a common father with at least
one member of the class."
Computation of f/s corresponding to leaf cycles
Figure 10~Parking after "squeeze" and "clean-up" passes
Let Ek = {d il , d i2 , ••• , d ile } be a class as defined
above. We shall give expressions for the fi of vertex
members of d ij in supposing first that the cycles are at
their maximum depth of embedded ness.
32
Spring Joint Computer Conference, 1972
there exists no arc (Wi, wi') such that Wi Ed i1 - {wd
and W/~di1.
Let (N -1) be the mean number of times the DO-loop
has been set up for and p the probability of the feedback
arc of a stochastic cycle. For a DO-loop:
(a)
o
o
I
\
\
b
N
ii= L j Pr[wi( j) ]
i=1
and
/
But
Pr[w;(j)
J~
C)
p<*i(l-p,*)N-;,
Hence:
= N Pi*
L
(N-l)
i=1
j-1
N
Pi*i-1(1- p/) (N-1)-(i-1)
or
h=Npi*=ihPi*.
(b)
p
Figure ll-Regular Markov chain (sub case 1 of case 1)
Case 1. Ek has a unique member d i1 = {Wh' ... , Wi,
... , Wt} where (Wt, Wh) is the feedback arc.
Let Pi* be computed as in (1) in considering only
the subgraph corresponding to d i1 and Ph = 1. We note
Pr[wi( j)] as the probability of executing wd and j
times only.
Subcase 1. There is no branching out of d i1 , that is
For a stochastic cycle: the process can be considered
as a regular Markov chain as shown in Figure l1.a. by
introducing an extra arc of probability 1. Now if P is
the regular transition matrix, (Ilh' ... , IIi, ... , lIt, lIe)
the limiting probability vector, it is known that the
mean first passage time to return to a given state is
mii= l/Il i. In our case, mee= l/Il ee represents the mean
number of steps, and h = IIi/lIe.
If one is interested only in ih, ii, it, the graph is
equivalent to the one in Figure l1.b. whose transition
matrix is:
o
0
o
1
o
o
0
o
1
o
p
0
o
o
1-p
1
0
o
o
o
and since IIi = p/II h, then ii = P/ih. Now ih could be
computed by the ratio Ilh/ll e but directly one can see
that:
Sub case 2. There is some branching out of total
Segmentation and Optimization of Programs
33
probability l-Q where Q=Pt*. In the DO-loop case:
Pr[Wh(j)J=Qi- 1(I-Q) (j=I, ... ,N-l);
Pr[wh(N)J=QN.
Hence
p
G
1
p
Now
Pr[wi(k)] =
i:
i=k
,
Pr[wh( j) ] (j) p/ k (I-Pi*) i-k
k
t2
(k= 1, ... ,N)
and
N
Ji=
L: k Pr[wi(k) ]
k=l
i:
Pr[wh(k) ] t j
k=l
(~) Pi*i(1-Pi*)k- i
3=1)
Figure 13-Regular Markov chain (subcase 1 of case 2)
matrix
010
N
=p/
L: k Pr[wh(k)] •
k=l
(X-I)
k
~.
3=1
Pi*i-1 (1- p/) (k-1)-(j-1)
)-1
o
0 Q l-Q
p
0 0
I-p
100
0
which yields
N
=Pi*
0
L: k Pr[wh(k) ]=P/Jh.
1
k=l
In the stochastic case, the computation of Jh corresponds to the Markov chain of Figure 12 of transition
p
1
Figure 12-Regular Markov chain (subcase 2 of case 1)
Jh= l-Qp
Analysis similar to subcase 1 would yield Ji = Pi*jh.
In summary for this first case, the computation of the
Ji involve only the computation of the Pi* and of the
Jh as given above.
Case 2. Ek has more than one member.
Subcase 1. All cycles are stochastic.
Again we have recourse to the ::.vrarkov chain approach. Of interest are the Ji of the heads and tails of
the cycles. A typical example is shown in Figure 12 of
transition matrix;
o
1
0
0
0
o
0
1
0
0
p
0
0
I-p
0
o
p'
0
0
I-p'
1 0
0
0
o
34
Spring Joint Computer Conference, 1972
approach. To do so an N -folding of the structure must
be performed as shown in Figure 14.a. To obtain fh2
andft2 a reduction as in Figure 14.b. is performed giving
a transition matrix
(a)
p
I-p
0
0
p
0
I-p
0
p
o
o
I-p
1
o
o
o
which yields
1
fh1= - - (l-p)N'
(b)
1- (l-p)N
p(l-p)N
p
andft1=fh2,ft2= (l-p)fh2 as in subcase 1.
1
If for both cases 1 and 2, the cycles are not embedded
in any other cycle, the fi are multiplied by Ph the
probability of reaching the first head. If they are
embedded in other cycles, the fi computed at the next
level will be multiplied by those just obtained until all
cycles have been treated.
CONCLUSION
Figure 14-Subcase 2 of case 2
which yields
p
fh1=
1+ (l-p) (I-p')
,
1
fh2=ft1= (l-p) (I-p')
and
1
ft2= -1-p'
Subcase 2. One member of Ek is a DO-loop (there
can be no more than one due to the Syntax of
FORTRAN).
Consider again Figure 13 but suppose now that the
second cycle is a DO-loop. It could be possible by using
methods of renewal theory to determine the fi in this
case. However we can still use the Markov chain
In this paper we have presented a model of Fortran
source programs with particular emphasis on the cyclic
structure. Applications of the model to segmentation
and optimization have been introduced. Algorithms
needed to extract information from the high-level
language in order to build the model have been given.
A packing algorithm, whose goal is to reduce the
number of interpage transitions in a paging or cache
memory system, has been presented along with its
application to an example program. The cyclic structure
of the program has also been used to compute the
expected number of executions of each statement of the
source program.
The results of the packing algorithm, which is meant
to increase the locality of the generated code, could also
be used in paging mechanisms with anticipatory
control. The expected numbers of executions could
serve in the packing of data into pages, the data with
high correlation being allocated in the same pages. This
latter problem needs more investigation and it is in this
Segmentation and Optimization of Programs
direction that extensions of the model and new algorithms should prove useful.
REFERENCES
1 FE ALLEN
Program optimization
Ann Rev in Aut Prog 5: pp 239-302 1969
2 J L BAER
Graph models of computations in computer systems
PhD Dissert UCLA 1968
3 J L BAER
Matrice de connexion minimale d'une matrice de precedence
donnee
RIRO 16: pp 65-73 1969
4 R T CAUGHEY
Automatic segmentation of FORTRAN programs from cyclic
structure analysis
MS Thesis Univ of Washington 1971
5 F H DEARNLEY G B NEWELL
A utomatic segmentation of programs for a two-level store
computer
The Computer Journal 7 3 pp 185-187 May 1968
6 D E KNUTH
An empirical study of FORTRAN programs
C Sci Depart Report CS-186 Stanford Univ 1970
7 T C LOWE
Automatic segmentation of cyclic structures based on
connectivity and processor timing
Comm ACM 13 1 pp 3-9 Jan 1970
35
8 D F MARTIN G ESTRIN
Models of computational systems cyclic to acyclic graph
transformations
Trans IEEE EC-16 pp 70-79 Feb 1967
9 C V RAMAMOORTHY
The analytical design of a dynamic look-ahead and program
segmenting scheme for multiprogrammed computers
Proc ACM 21st Nat Conf Thompson Book Co pp 229-239
1966
10 E C RUSSELL G ESTRIN
Measurement based automatic analysis of FORTRAN
programs
Spring Joint Conf Proc 34 pp 723-732 1969
11 J M S SIMOES-PEREIRA
.
On the Boolean Matrix Equation M' = U Mi
i=l
Journal ACM 12 3 pp 376-382 July 1965
12 J C TIERNAN
An efficient search algorithm to find the elementary circuits
of a graph
Comm ACM 13 12 pp 722-726 Dec 1970
13 E W VERHOEF
A utomatic program segmentation based on Boolean
connectivity
Spring Joint Comp Conf Proc 38 pp 491-495 1971
14 B W KERNIGHAM
Optimal sequential partitions of graphs
Journal ACM 18 1 pp 34-40 Jan 1971
15 J KRAL
One way of estimating frequencies of jumps in programs
Comm ACM 11 7 pp 475-479 July 1968
36
Spring Joint Computer Conference, 1972
APPENDIX I
Vertices and arcs generated by the graph modeling process.
Notation: Wi current vertex number; Wi+! next (sequential) vertex number;
statement of label n; Wz terminal vertex.
STATEMENT
GOTOn
GO TO (nl,n2, ... ,nk),j
GO TO j, (nl,n2, ... ,nk)
IF (e) nl,n2,nS
IF (e) S
(a) If S is not a GO TO RETURN
or STOP
(b) If S is a GO TO RETURN or
STOP
DO n I = M1,M2,M3
CONTINUE
PAUSE
RETURN
STOP
READ (a,b,END = nl,ERR = n2)list
WRITE (a,b)list
ENDFILE
REWIND
REWIND
BACKSPACE
Arith. Stats.
END
Wn
vertex corresponding to source
VERTEX GENERATED
ARCS GENERATED
(Wi,W n )
(Wi,W nl),(Wi,W n2), ••• ,(Wi,Wnk)
(Wi,W nl),(Wi,W n2), ••• ,(Wi,Wnk)
(w i,Wnl), (w i,W n 2), (w i, wns)
Wi,Wi+1
(w i,W i+1), (w i, W i+2)
Wi
(Wi,Wi+l)
Wi
(W i,W i+I), (Wn, W i+l)
Wi
(Wi,Wi+l)
Wi
(Wi,Wi+l)
Wi
(Wi,W z )
Wi
(Wi,W z )
Wi
(W i, W i+1), (W i,Wnl), (W i,W n2)
Wi
(Wi,Wi+!)
Wi
(Wi,Wi+l)
Wi
Wi
(W i,W i+!)
Wi
(Wi,Wi+l)
Wi
(Wi,Wi+l)
Wz
The interplay of computer science and
large scale scientific calculations
by KENT K. CURTIS
National Science Foundation
Washington, D.C.
refer to the machines which have until now dominated
scientific calculation. Other designs which attempt to
reflect some additional measure of understandi.ng of
scientific calculations have been considered and some
are of substantial current interest. Pipe-line systems
and the ILLIAC IV, are among those which come to
mind, but none of them has yet had opportunity to
prove its value. Even they, however, are the result of
adding only one more global observation to the design
criteria, the observation that many scientific calculations have the common property that they involve
the redundant use of identical operation sequences on
ordered sets of data. Hence, their appearance and
history does not vitiate the force of the earlier observation. On the contrary, they extend its force to the near
future.
They do, however, raise several interesting points.
First, the principal ideas of architecture underlying
each of the machines which are now being physically
realized are approxi.mately ten years old. Still, these
machines are only now being delivered and experience
suggests that it will be some time yet until the systems
will have been stabilized sufficiently and used sufficiently to be able to make a definitive evaluation of
them from experience. This is a long gestation period.
It suggests that we should not expect breakthroughs
in large scale scientific computing due to new ideas in
machine architecture in a short time scale. The machines which are now coming to life may be substantial
contributors to scientific computing ten years from
now, if they prove out, but it is unlikely that machines
which are still on the drawing board will contribute
until later .
It also suggests that unless we believe we already
have discovered the only important concepts in machine
organization (which is possible but would be most
remarkable, if true) we should be very interested in
reducing the time span from idea to realization. Ideas
in machine organization spring from an environment
The history of computing has been characterized by
the statement that what the manufacturer makes, the
customer takes. To the extent that this is true, it is not
only an interesting and perceptive comment on history
but also a testimonial to the remarkable nature of the
sequential, stored program, electronic computer. If
that invention had not fit so well from the beginning
to a wide variety of interesting problems, the development of hardware and software systems could not have
proceeded as independently of scientific motivation
as it did. Of course, scientific requirements have influenced systems design, but the prominent parameters
such as speed or memory size could be understood
without detailed knowledge of scientific problems or
programs and the parameters which might depend
upon the structure of programs could be ignored.
It is fortunate that that was true. There were important problems to solve in physics, chemistry,
meteorology, etc. We could work on those without
delay and let systems design take care of itself, with
ad hoc software adjustments when things became
intolerable. Computers worked so well there was no
apparent need for guidance by scientists of system
design. Better design might make an incremental
difference but that increment was not sorely missed
and barely worth an incremental effort.
Meanwhile, computer development followed an
internal dynamic of its own. It was influenced by the
fact that scientific requirements provided a ready
market for computers which were big and fast, but
the general purpose computer was a useful paradigm
and rapid advancement of electronics technology kept
many problems at bay. Computer engineers and
businessmen could do their own thing in their own way,
with unusual freedom. The computers they built have
reflected principally their own genius in taking advantage of technological opportunity, and that, happily,
has been sufficient.
In making these comments, let me note that they
37
38
Spring Joint Computer Conference, 1972
of experience to meet a perceived need. They need
testing to evaluate them. If the need is really important
it will probably persist until an answer is found. But,
on the other hand, if the need is important we would
rather not wait ten years. This line of thought argues
for research in such areas as description languages
which can describe complex systems and be translated
to a design and fabrication process and it argues for
support by the scientific community for such research.
I would like to return to this point later.
Second, a "paper machine" has very little weight.
At an early stage in the development of the machine
which is becoming ILLIAC IV, I spent some time with
several people who were active in hydrodynamics and
meteorological research to see what basis for estimating
performance could be established from analyses of the
actual codes which were of interest in those fields. My
question was, to what extent does the parallelism which
is available in this design offer an effective improvement in performance, considering the detailed structure of the computing algorithms, data management,
and I/O processes that are used in these problems? I
thought I understood how to do that kind of analysis,
at least in part, including modifying the codes for
parallel processing, but I did not know the codes. I
hoped that someone who knew the codes could be
motivated to undertake some analysis. I. was impressed with the degree of interest in the machine and
the lack of interest in attempting any analysis. I found
a uniform response that if the machine existed, they
would try it because it seemed intuitively attractive.
No one was willing to attempt an analysis of his programs, however, with a view to justifying construction
of the machine or influencing its design. In all fairness,
they did not know how to do it and neither did I. The
problem is harder and more subtle than I thought. The
question remains open and, indeed, I still do not know
how to find an answer with assurance except by extended experience. Responsible people still hold an
honest difference of opinion. Fortunately, the continued development of that machine did not require
the active support and involvement of the scientific
community it was intended to serve. Technological
opportunity supported by intuition and some analysis
has been sufficient. The experience suggests, however,
that there exists only a weak coupling between the
community of natural scientists and the community
of computer engineers. It also affirms the need to test
new ideas in machine design by actual construction of
machines and evaluation in a user environment.
Another interesting point which these machines have
emphasized is that more than one schema may be
applied to the solution of most problems and different
computer architectures may favor different schema.
This seems obvious but it required the actual development of parallel and pipe-line machines to stimulate
such rethinking of problem formulation and algorithms.
N ow this offers a rich field of research for numerical
analysts and computer scientists, where results may
be of direct interest to scientists. I personally believe
that this is a profoundly significant development which
may portend the appearance of a new degree of influence by computers and computer science in our
conceptualization of the scientific problems we attempt
to solve. More immediately, however, it means that
definitive evaluation of new ideas in computer architecture can only be made after good algorithms for
those architectures are devised. Is this backwards?
Should not the analysis of algorithms influence design?
Is this not another example of weak coupling between
communities with allied interests? Fortunately, we are
beginning to make progress on the theory of algorithms
which offers hope of benefit to both scientific computing
and computer design.
Let us return, now, to the remarkable success of
sequential computers in large scale scientific computing.
If one considers the spectrum of activities which now
comprises large scale scientific calculation one can
observe a number of common features.
(1) The conceptual theory upon which the computations are based was firmly established before the
invention of computers. That theory had been
well verified using experiments and calculations
which could be and were conducted without
computers, providing a solid basis for faith
that large investments of effort and money in
computing would not be wasted.
High energy physics might be considered to
be one outstanding exception to this since conceptual theory in that field is being developed
during the age of computers. If one considers
the actual computing being done, however, the
distinction disappears. The large-scale computing
is in analysis of data from experiments which are
patterned in their design and analysis after
particle physics concepts that were well established before computers were applied. Orders
of magnitude less computation is used in theoretical investigation exploring the conceptual
understanding of high energy physics. No theory
commands sufficient faith to justify a larger
investment of time and money.
(2) The conceptual theories are all expressible in
well formed mathematical or statistical models.
(3) Based on the conceptual paradigms, it is possible
to visualize, without using computers, interesting
problems which can be solved with computers.
Interplay of Computer Science and Large Scale Scientific Calculations
(4) Such problems can be solved, to a sufficiently
good approximation to be interesting, using
sequential machines operating for reasonable
lengths of time.
(5) These problems enjoy a high national priority
giving them access to the large amounts of
money and effort which have been required for
their study.
If you think about it, this is an interesting set of
properties. It suggests the roles which have been played
in fact by scientific motivation, technological opportunity, and public support in determining the
course of development of large scale scientific computing. It provides a basis for understanding why
scientific progress and the development of computer
technology could be so vigorous, so symbiotic, and yet
so independent. It provides a rationale for the observation that scientific inquiry has adopted the technology
provided rather than leading or strongly cooperating
in its development. At the same time, it points to
certain limits, which have been observed by the course
of events, in fact, on the regions of success in scientific
computing. If one may have faith in continuity, it
suggests some features which can be expected of developments in the near future.
One interesting observation which derives from this
set of characteristics is that although computing has
profoundly changed the style and methodology of
research in some fields, although it has opened nmv
questions for serious consideration, there has been no
departure from already established concepts. Computing has not yet altered our paradigms of nature in
a fundamental way. This is not surprising-the time
constant for developing fundamental physical theory
is much longer than the history of computers-but it
indicates that we should not expect the short time
scales associated with the development of technology
to be reflected in any obvious way, if at all, in the rate
we revise our fundamental underst9,nding of nature. It
also invites the question of whether computing should
be expected to ever become an essential component of
conceptualization. Are there interesting phenomena
which cannot be described within the framework of
mathematical or statistical models? Are there important questions to be posed which do not yield to
analysis by sequential procedures? What would it
mean to include a program operating in time as an
essential element in our description of a model, as we
now include time-dependent equations? It is an interesting conjecture. Considerations of real-time systems are suggestive.
Before going on, let us examine some possible inferences which may be drawn from the preceding
39
characterization of large scale scientific computing.
Certainly it is true that national priorities have strongly
influenced the choice of fields of investigation and
hence the visible progress. These priorities are changing
and efforts in large scale computation in fields other
than the physical sciences will receive more encouragement. Fields which have the property that they can
take advantage of existing technology, have well
posed questions based on well formulated mathematical paradigms, and have a sufficiently large community of interested and talented scientists who are beginning to emerge as partners with the physical sciences
in large scale computing. The National Science Foundation is playing a role in this through its interest in
the applications of computers to research in the natural
sciences, in social sciences, and in applied research.
One harbinger of change is the establishment of the
Computer Research Center for Economics and lVlanagement Science by the National Bureau of Economic
Research, Inc. with NSF support. We intend to take
advantage of other opportunities as they arise.
If we note, again, that it has taken a decade to develop the new machines which are now appearing and
that it will be some time, yet, before they can be
adequately evaluated we may guess that the new fields
which will join the ranks of large scale scientific computing in the next decade can be discerned now. They
are not many. Few disciplines enjoy the advantages
which the physical sciences have of almost universally
accepted, well established paradigms which adapt well
to existing computer technology. Advances in theory
might accelerate the entry of one field or another in
unexpected ways but advances in technology are unlikely to do so within a ten year time frame. I, myself,
am not aware of many well formed problems embedded
in widely accepted theory which are only awaiting a
technological breakthrough to be solved. Even if they
exist, it will take time to translate new ideas in technology into effective research application. The ideas
must first be converted into actually realized tools, a
task that may take more than ten years itself if we accept prior experience as a guide. The application of these
tools must then be developed. Although there is overlap in these activities, a reasonable expectation would
be that in ten years time we will be able to guess some
still in the future impacts we do not now discern but
the fully active members of the large scale computing
fraternity which will then exist are already recognizable today as having accepted theories which are
describable by mathematical or statistical models
amenable to solution by sequential machines. The
potential new members are distinguished from the
present members primarily by the fact that they are
only now adopting the mathematical methodology of
40
Spring Joint Computer Conference, 1972
the physical sciences and by the fact they they do not
yet enjoy high national priority status. Technology
notwithstanding, ten years is a short time in .the development of human thought. Even quantum theory
took much longer to evolve.
Another feature which emerges from considering
this set of properties is the prevalence in successful
scientific computing of certain mathematical or statistical models. Not only were the conceptual theories
well established before computers entered the scene
but the models used to describe those concepts and the
approaches taken to solve them were also well established. For example, finite difference approximations
of partial differential equations. We have always
quickly exhausted the capacity of the machines we had
to solve those problems in that way but we have not
become frustrated because technology advanced rapidly
enough to keep the game interesting. We have made
substantial advances in discovering faster, more efficient algorithms for carrying out these processes and
in understanding convergence and stability but basically
we have worked, not only in the same conceptual but
also in the same procedural framework that was common with desk calculators. (l\10nte Carlo techniques
might be thought to be an exception. I think not. As
with many things, computers made those already established techniques more effective.)
Now a new line of thought is beginning to emerge.
I am aware of it in meteorology but it may be present
elsewhere. Computers have enabled us to undertake
"ab initio" calculations which could never be approached before. (Indeed, some chemists now believe
that their theory is so sound and their computing
techniques so accurate that they can place as much
faith in the results of a calculation of a possible molecule
as they can in an experiment. They have some substantial basis, as is evidenced by the story of the noble
gas compounds but it reflects an interesting shift in
attitude.) This ability has enabled us to undertake
prediction with an accuracy never before possible and
the long range weather forecasting which has become
part of our daily lives is an outstanding result. But,
perhaps we are beginning to push the limit of that
ability using standard techniques. The predictive
power of a given mathematical model rests ultimately
upon the completeness and accuracy of the physical
data we can provide even if the model is in principle
perfect and we have infinite computing power. At some
point, decreasing the size of the mesh or increasing the
number of layers in a three dimensional atmospheric
model multiplies the computational steps required
without yielding a commensurate increas3 in useful
results. It has been suggested that in atmospheric
circulation problems, computers may be bringing that
limit within sight. A couple of weeks may be a limit
beyond which the model diverges from reality because
of limitations in physics, not computing.
This observation is suggestive. The problem has been
recognized before and some computer scientists have
studied significance arithmetic schemes to provide
continuous knowledge of the significance of quantities
throughout a calculation. This work has not yet entered
into practical applicatjon but interest may revive in it
as we find ourselves pushing the limits of data accuracy
more frequently. If true, it will offer a rich field for
research relevant to computer users.
But the observation is also interesting in another
dimension. I t would be surprising if a conceptual
theory can find mathematical expression in only one
model or if that model can be solved in only one way.
It would also be surprising if we have already chosen
the best model for all situations. In atmospheric circulation, some of the questions one wants to raise may
be answerable from a turbulence model which is statistical in nature and leads to a different computational
problem. This could be a better way to obtain some
results than solving the general field equations.
This phenomena is not new. Scientists have always
reformulated models and changed approximations
when they were unable to make further progress with
one particular line of attack. Instead, the last twenty
years have been unusual. Computers have increased the
power of certain traditional lines of attack so much
that we are only now approaching their limits. As we
reach those limits, more attention may be paid once
again to alternatives and to the real significance of the
numbers we compute.
Finally, this set of characteristics of successful
scientific computing can be helpful in anticipating the
near term impact of new developments. They suggest
that the most likely effect of technology will be to
help scientists do better the things they already know
how to do, perhaps, even stronger, the things they are
already doing. Before discussing specifics here, however, it is necessary to make note of a new current
which is beginning to influence the computing environment. While scientists and computer manufacturers
each followed their own independent but mutually
reenforcing interests, a third community, the community of computer scientists, was gradually emerging.
This is the community whose imagination is captured
by the intrinsic interest of complexity, systems, arid
computers and it is largely populated by bright young
people who grew up with computers as a background.
To the extent that computers have broken tradition,
these people have the advantage of growing up with
fewer ties to the old traditions. This community is nQw
taking shape and beginning to find things to say which
Interplay of Computer Science and Large Scale Scientific Calculations
have relevance to both scientific calculation and
computer design.
Neither the computer manufacturers nor the computer users have had much interest in computer
science. They have been preoccupied with technology
and have strongly flavored the definition of the term
"computer science" with their own interests. For this
reason it may be necessary to define more precisely
what I mean. To some degree, one man's science may
be another man's technology and neither can live in
good health ",ithout the other. This is especially true
if one looks at the actual occupations of people who
call themselves scientists, the things they really do
with their time and energy. The term science, however,
has a commonly accepted meaning which involves the
discovery and formulation of generalizations or principles that can be expressed in models describing phenomena. Computing has focussed attention on
phenomena which are as old as man but which have
been taken for granted; phenomena concerning information, complexity, and the processes for organizing,
describing, and analyzing. Computer science is addressing itself to these phenomena. Its success will have
meaning for all who are concerned with computers.
The conduct of computer science research is also
interesting. There is reason to believe that it must be,
at least in part, essentially complex and involve the
concerted effort of research teams. Professor Jack
Schwartz, of New York University, has used an
analogy which I find fruitful. He notes that mathematics is a solitary occupation which can be compared
to diamond mining. One digs through large quantities
of dross but in the end one finds a jewel which is small,
beautiful, and can be easily admired by all who have
eyes to see. Computer science, on the other hand, is
comparable to coal mining. One handles comparable
or greater quantities of material but none of it can be
thrown away. Everything must be preserved for use
and the process is intrinsically complex. This does not
preclude generalization and the discovery of principles
but it does say something about the process of finding
them and about the description of them which gives
them meaning.
With this preamble, let us return to the consideration of new technology. There are several things which
come immediately to mind. They cannot really be
separated-each influences the others-but you can
construct your own feedback loops.
(1) Machine architecture
This has already been discussed. The new architectural ideas which may affect large scale scientific
computation within ten years are already being built
41
in hardware. The long lead times involved make it
almost certain that the impact of other ideas will not
be realized in that time frame. New contributions
inspired by the machines now being built will increase
rapidly as those machines actually become available,
however, and will influence their use. These will be
in the areas of problem formulation, analysis of algorithms, data management schemata, operating systems, languages, and file management. I hope these
machines will be available for computer science research. I think they cannot be properly evaluated
without it.
(2) Solid state memory
It appears likely that we will soon have memories
available which are comparable in cost to present core
memories but comparable in speed to logic. This will
change one of the parameters of machine design which
has been nearly constant throughout the history of
computers, the ratio of memory time to logic time,
from about 100: 1 to about 1: 1. It would be most
surprising if this does not have some effect. Programming would seem to gain a new degree of freedom. One
possible effect may be more effective specialization of
machine function without specialization of machine
design. Floating point arithmetic might be programmed
again, not wired, for example, to give greater flexibility
of word size and significance arithmetic may have a
better chance for effective implementation.
On the other hand, the forces influencing change
are numerous, subtle, and complex. It is very difficult
to forecast but fascinating to watch as events unfold.
The foregoing statements assume that it is easier to
program than to build machines. But one can also
imagine ways in which this same memory development,
with proper inspiration and motivation, might lead to
simplifying the fabrication process. Modular building
blocks for machines and systems of machines might
then become part of our standard repertoire.
(3) Algorithms
This is an area where computer science will give us
an undisputed benefit. Theoretical limits on the speed
of algorithms will provide measures against which
to compare performance and will inspire improvement.
Analysis and classification of algorithms will begin to
give formal structure to programs and guides to optimize design of both programs and machines. From this
area will come the indispensable tools for understanding
the information processes which are possible for us to
use in solving problems.
42
Spring Joint Computer Conference, 1972
The benefit will be felt, not only in increased performance on our present problems, which may be
significant or not, but in providing us with constructive
procedures for thinking about the information processes
appropriate for our problems. It may seem facetious to
suggest that the science of algorithms will usurp the
role of calculus and numerical analysis as the primary
tools for description and problem solving. It certainly
is premature. But I will be interested to see what our
attitude is about this at the end of this decade.
(4) Languages
In the short history of large scale scientific computing
we have relied primarily upon one language, FORTRAN, and have accepted its limitations in the interest
of pursuing the scientific problems at hand. Again, it
has been the case that other languages migh t provide
an incremental gain but that has not been worth an
incremental effort by scientists to learn, to use, or to
develop. Improvements have been made and will continue. Computer scientists are developing automatic
code optimization procedures which may help performance and, perhaps, debugging. Monitoring schemes
and performance measurement studies are making it
possible to do time analysis of programs to increase the
efficiency of codes. Factors of two, three, ten, or sometimes fifty improvement result. But with respect to
learning languages, the scientific community has been
conserva tive.
N ow we may be reaching another kind of limit.
Programming is a human effort involving a long chain
of people and events before a complete program can
be made to work satisfactorily. Programming time
and the irreducible error rate at each step of the process
places a practical limit on the growth of complexity of
programs, generally by making the cost or time required to achieve a certain degree of complexity greater
than we can, or want to invest. In spite of large programming investments and outstanding successes we
are all aware of these limitations, and have had the
experience of thinking of interesting programs which
we were unwilling or unable to write. More significantly,
some of the programs we have already constructed
are maximally complex for our resources. FORTRAN
is becoming a restraint that can be felt.
It is clear that this restraint can be relaxed since
this is an area in which computer science has made
progress since FORTRAN was developed. Iverson's
APL, for example, is indicative as is Schwartz' SETL.
In still another direction, Hearn's REDUCE is building
a record of accomplishment. Within a decade, scientists
will be multilingual and have greater freedom for
scientific research as a consequence.
Another problem in the general area of languages
which computer science is attacking is the problem of
transportability of programs from one computing environment to another. Gradually, the structure of
programs, compilers, and operating systems is becoming clear. We are learning how to isolate the essentially machine dependent portions of codes, and to
bootstrap a system with minimum reprogramming
effort. The benefits of this development are already
being felt in economy of programming effort when
changing machines. Ultimately, it may make an important contribution to scientific communication by
making it feasible to exchange codes.
(5) Communications
This may make the most significant change in our
daily working environment and seems to have large
momentum, with stimulation from many sources. The
National Bureau for Economics Research Center,
which I mentioned earlier, is being estabHshed with
remote operation in mind from its inception. So is the
CDC-7600 installation at Berkeley for high energy
physics. ILLIAC IV, at Ames, will soon follow and it
_ seems likely that other centers for specialized disciplines
with planned remote operation will soon appear.
The trend seems natural and inevitable. Research
computing involves not only a computing machine but
also a corpus of appropriate programs and an operating
policy favorable to the work. Finally, and perhaps most
importantly, it involves a group of scientists and support staff which can work well together and communicate freely to develop the research methodology.
The success of this organization for research has been
demonstrated in the national laboratories. It is not
surprising that it carries over to computing with communications providing the means.
At the same time, this mode of operation is a departure from the organization of research computing
which developed during the fifties and sixties when
each institution built the local, general purpose computing capability which would best satisfy its overall
staff requirements within the limits of its resources.
This change requires an adjustment by all parties
concerned and the transition will take time to accomplish. It will be interesting to see what changes in
our working environment and relationships result.
These are several technological changes that may
affect scientific computing in the near future. Others
should be included, also. The availability of large data
files, improvement in man-machine interaction, progress
in data representation (including the question of what
data should be stored and what should be reconstructed), and others will have a significant impact.
Interplay of Computer Science and Large Scale Scientific Calculations
Yet each of these seems likely to have effects which
are rather specific to particular fields of research, in
the near term, and little influence common to all fields.
Color graphics may be an exception.
One other project, which NSF is undertaking, should
also be mentioned. That is a cooperative effort among
several universities and national laboratories to analyze,
certify, and document standard subroutines. The
resulting library should give us greater basis for confidence in results and less trauma in carrying out
research programs involving computing.
Before closing, I would like to mention the problem
of publication. Scientific computing has labored under
a handicap because it has not been possible to publish
programs. A number of factors are relevant but I am
not sure of their causal ordering.
(1) Attitude
Programming has been considered necessary but
menial even though it has been the principal occupation of many scientists in terms of time and energy.
(2) Language
Mathematics has a language which is concise and
makes the intellectual content clear. Often, the best
description of a FORTRAN program is the program
itself which is neither concise nor clear.
(3) Utility
A mathematical analysis of a theory or experiment
can be universally understood, generalized, and used.
43
A program is typically obscure, specific, and almost
universally useless.
The belittling attitude toward programming, which
is another carry-over of tradition, has certainly inhibited any attempt to solve the problem but failure
to overcome the other hurdles does not encourage a
change in attitude. It is a classical example of an
impasse, one which natural scientists will not solve
within the framework of their own disciplines.
It may be that computer science will make an important contribution here by developing the basis for
describing and communicating programs in a really
useful and general way. If that results, the benefit to
science of improved communication may be great. It
is interesting, though, that the path to this accomplishment will have been through byways such as automata
theory, formal languages, perhaps set theory, the study
of algorithms, and the structure of machines which
have almost no discernible relevance to physical science.
We have seen that although progress in large scale
scientific computing has been surprisingly rapid, it
has also been bound by tradition. We have also seen
that there is a long time constant in developing and
absorbing technology. Both of these facts tend to
become obscured by the activity around us but together they will continue to shape the near term future.
At the same time, a new influence is emerging through
the development of computer science which may provide the means to relax the constraints of tradition and
expand both our conceptual and procedural horizons.
The time scale for fundamental change, if it occurs,
can be expected to be long but a decade may reveal
the strength of the trend. It will be interesting to watch.
Computer architectllre and very large prohlems*
by R. B. LAZARUS
University of California
Los Alamos, New Mexico
large problems, though important, command only
limited funds.
Let us start by considering the role of logic elements.
They differ in cost, speed, size, power dissipation,
sensitivity, and reliability. In many cases, there are
inherent trade-offs among these properties. Let us
imagine an omniscient computer designer who has in
mind all possible computer architectures-no, make
that all possible computer designs-and who has full
knowledge of all available logic elements. For all
possible designs implemented with all available types
of element, he wants to find that combination giving the
maximum speed, subject only to the restrictions that
speed-to-cost ratio be not much higher than what is
now available and that the computer have a mean time
to failure of many hours.
He would immediately realize that the problem is not
well defined. He would ask what kind of calculation he is
to maximize the speed of, and be told, "Large problems,
as defined above." Noting that such problems have
"large numbers of variables," he would fold into his
task the consideration of the various kinds of memories
available. He would then come up against the following
major architectural problem.
Define access time as the time which must elapse
between a decision to fetch an operand from a given
address and the arrival of that operand at the desired
function unit. Then, for all large-memory technologies
today, the access time is long compared to the achievable average instruction execution time. (In other
words, you can't win by rebuilding the IBM 704 with
modern components.) What can be done? There
appear to be only two things to do. First, one can try to
minimize the number of operand fetches required during
the solution of the given problem. Second, one can overlap the fetching of operands, both with each other and
with computation.
It is interesting to ask whether these two things are
in conflict with each other. For machines with internal
For the purposes of this paper, "very large problems"
are defined by two properties: (1) There is an effectively
unlimited amount of physics and of spatial detail
which it would be useful to include if practical; and (2)
the calculation must be completed in a limited number
of hours. The best example is perhaps the global weather
problem. We will obviously never put in all the energy
sources or all the topography and we must obviously
calculate faster than real time.
Such problems need big machines in the sense of
operating as rapidly as possible on large numbers of
variables which describe or pertain to a single region of
space. It is the aim of this paper to consider questions
of computer architecture in this context.
The questions of primary interest are (1) what
computer architecture is best for such problems today,
and (2) what architecture may be best ten years from
now. These questions will not, in fact, be answered.
The following comments may, however, indicate why
the first question is unanswerable and help others in a
search for the answer to the second.
To keep the problem within a reasonable scope, it will
be assumed as a boundary condition that the cost per
unit of arithmetic of the ideal computer for large
problems must not be substantially greater than the
cost per unit of arithmetic of, say, an IBM 360/195 or
a CDC 7600. This assumption is intended to exclude an
architecture which offers a factor of n in speed if the cost
is up by a factor of, say, 3n. This admittedly excludes
an interesting area; if, for example, it becomes necessary
to control Los Angeles air traffic by computer and the
best available computer is too slow by a factor of three,
then it would certainly be interesting to know whether
the necessary computer could be built for a cost up
by a factor of nine. Nonetheless, the restricted question
would appear to be of sufficient interest, since many
* This
work performed under the auspices of the U. S. Atomic
Energy Commission.
45
46
Spring Joint Computer Conference, 1972
addressable registers, good coders (and compilers)
exploit the first; by clever use of the registers, they try
to minimize the number of times a given operand is
fetched. For the upcoming vector machines, on the
other hand, good coders will try to exploit the second;
they will maximize overlap by favoring the vector
commands, which stream operands from memory as
fast as the memories and memory buses permit.
Is there, then, a conflict or not? There is a conflict
only so long as the restriction on gate count (which may
come from cost, size, power, or reliability) prevents us
from having the best of both worlds. Here is precisely
where the question gets so sticky. Are we discussing
today's practical problems, or are we looking for fundamentals? This matter will be touched on again below.
In passing, it might be noted that this problem of
long access time cannot be solved merely by development of a very fast memory, because transmission times
for address and data would still be long. It is no help
to postulate a general scaling down of the whole computer, so that all function units can be very close to the
memory, because this will scale down the instruction
execution time as well. A very restricted solution is
suggested in the Appendix, but just for fun, since it
certainly cannot be achieved within the next ten years.
The long access time should probably be accepted as a
fact of life.
At this point, our omniscient designer might note
that, while memory access times are inherently long, it is
relatively easy to achieve high bandwidth by a variety
of methods. He might then pause to consider the
methods appropriate to various architectures and note
advantages and disadvantages.
The first technique uses a memory word which is two
or more machine words in length. In all plausible situations, the number is a power of two and the machine
words have consecutive effective addresses. For a
given memory technology, this increases potential
bandwidth as long as the read time increases more
slowly than the size of the memory word. Whether or
not it increases realized bandwidth depends on the mean
number of useful machine words which are acquired
by a fetch of a memory word. The technique is obviously
appropriate for instruction fetching and for feeding
streams of consecutive operands to a vector machine.
With many independent memory boxes (see next
paragraph), the technique is· also quite powerful for
most "naturally occurring" codes, if the boxes have fast
registers to hold the last memory word fetched, or in the
presence of a "cache" memory as in the IBM 360/85
and 195.
The second technique uses interleaving of many
independent memory boxes. We may assume with no
loss of generality that the number of boxes is a power
of two and that they are interleaved on the low order
bits of the memory word addresses. This technique is
also obviously appropriate for feeding streams of
consecutive operands to a vector machine. Let us
examine the behavior of such a memory for a sequence
of fetches from random addresses; for simplicity, assume
there is only one machine word per memory word.
Suppose we have an infinite list of random addresses,
a clock, and the logic to pass one address per cycle
to the appropriate memory box. If the order in which
the fetches get accomplished is irrelevant (and if we
have sufficient logic), then our steady state will either
be one fetch per clock cycle or else all boxes working to
capacity, depending on whether the clock is relatively
slow or relatively fast compared to the memory cycle
time. In either event, that steady state will constitute
maximum available data rate.
If our list has precedence relations (as it certainly
must when we mix in stores as well as fetches), or if we
do not have facilities to queue up an arbitrarily ~ong
list, or if we do not have the logic to scan an arbitrarily
long list in one clock cycle, then we wHl have conflicts
and loss of data rate. It is probably not fruitful to
derive results for random addresses, since there is a
great deal of correlation in real cases.
It is worth noting that additional processors may be
able to share a memory "for free" whenever a single
processor leaves most boxes idle most of the time. Such
idleness could be because of a relatively slow clock cycle
or very many boxes, or it could be because of too many
precedence relations in the work of a single processor
(assuming that multiple processors have no, or at
least negligible, precedence relations among each other).
The third technique uses separate memories serving
separate processors. This is the technique of the
ILLIAC IV, where each memory-processor pair works
on a separate portion of the large problem. The potential
bandwidth is simply the product of the number of
such pairs and the bandwidth of an individual pair.
The realized bandwidth is less by the mean fraction of
processors doing useful work.
By this time, our designer, being merely omniscient
and not divine, has developed a headache. He returns
to his consideration of logic elements, having in mind
that there are several ways to get whatever bandwidth
he needs from memory. He takes a quick look at the
possibility of using the best of everything. He imagines
a design of eight super-processors with independent
instruction streams, where each super-processor consists
of 64 slave processors, each combining the arithmetic
Computer Architecture and Very Large Problems
capabilities of a '7600 with vector streaming capabilities.
Before bothering to add up the price, he sees that the
mean time between failures will be a few minutes.
Concluding, then, that he must compromise, that he
may use only a subset of the techniques which enhance
speed for certain kinds of work, he realizes that his
problem is still not well defined. He calls in a friend who
knows all about programming, numerical analysis, and
applied mathematics. He asks for guidance on the fundamental arithmetic and data flow requirements of the
large problems under consideration.
Unfortunately, his friend points out two difficulties.
First of all, there are trade-offs between the amounts of
arithmetic and the amounts of· data flow, at both the
programming and mathematical levels. Second, the
properties of any important computer which may come
into existence will themselves influence the development of mathematical techniques.
The second point is brushed aside, and a new problem, this time well defined, is stated as follows. For all
possible computer designs, implemented with all
available types of element and applied to today's large
problems with all well-known mathematical methods,
which combination of design, implementation, and
calculational method gives the fastest solution, subject
again to cost and reliability restrictions?
Perhaps these gentlemen are busy somewhere
solving this well defined problem. Unfortunately, they
have not been heard from, and the problem is too
difficult for ordinary mortals. What should be done?
What actually has been done in recent years is as
follows. Various designers have chosen some mediumsized area in the design-implementation space, looked
for a local optimum with respect to some set of pieces of
problems, and proceeded to create a computer. During
the creation time, mathematicians have made some
exploration of the calculational method (and programming technique) space by analysis and simulation.
After creation (if successful), programmers can be
expected to find quite rapidly the actual optimum with
respect to programming technique; over the years, the
mathematicians will also move us steadily toward the
optimum with respect to calculational method. In this
way, points are located empirically in the space of
interest, namely the design-implementation-method
space.
It is time now to look more specifically at the present
state of affairs. Consider the approximately 16 year
interval between the IBM 701 and the CDC 7600. A
typical large problem ran for about ten hours on the
701; a typical large problem runs for about ten hours
on the 7600. The ratio of work being done is perhaps
47
1000; the cost ratio is perhaps five, leaving an improvement factor of 200. Most of this factor, which amounts
to 40 percent per year, comes from raw component
speed. The rest comes from improved design (architecture, if you wish), including floating point arithmetic,
index register~, parallel input-output, sophisticated
arithmetic engines, and, finally, parallelism among
instruction decoding, addressing, data flow, and
arithmetic. Most of what came from improved design
was again due to improved component technology,
being obvious enough in principle but requiring large
component counts which, in turn, required cheap, small,
reliable components. For the large problems, not very
much at all, up through the 7600, came from what we
would now like to call really new architectural concepts,
like vector arithmetic, multi-processors, or parallel
processors.
The reason why architecture has apparently played
so small a role, to date, for large problems is precisely
that 40 percent per year is very big. If implementation
of a substantially new architecture requires a 50 percent
increase in cost and a two year delay, one is giving
away a factor of three to begin with. Furthermore, if
the architecture moves us away from the optimum in
method space (i.e., if new methods and/or reprogramming is required), one gives away a further factor;
it is generally considered that at least a factor of four
must be anticipated in order to motivate a substantial
change in method or program for a large problem.
To say this again in other words: As long as 40 percent
per year improvement keeps coining along "for free,"
the short term needs of the large problems under consideration here do not motivate a substantial architectural
change unless the anticipated speed improvement is
substantial. "Substantial" means a factor of four in
speed-to-cost over the competition after correcting
for delivery date at 40 percent per year, compounded.
There are, nonetheless, motivations. The first is the
need to shift onto a more rapidly rising curve, if there is
one, even if one takes an initial loss to do so. If routine
improvements will come at a greater rate with some new
architecture than with old architectures, then the short
term loss from making the transition will eventually be
overbalanced.
The second and more important motivation is the
need to explore the design-implementation space in
order to get ready for the time, which must come
sooner or later, when nothing approaching 40 percent
per year will be available in the implementation direction. The trouble is knowing where to explore, and
how much to spend on such exploration.
To begin with, it must be noted that the manufac-
48
Spring Joint Computer Conference, 1972
turers will continue to explore, through actual construction, architectures which look profitable. Although the
nature of the expanding computer market is such that
architectures will not look profitable if they are only
good for large problems of the type considered here,
some light will nonetheless be shed on our question
of the best machine for such problems. It will not be
shed optimally, but it will be shed, in some sense, for
free.
There is a key difference in the importance of time
between the commercial interest and the computer
science interest. In the fullness of time, it will make no
significant difference to computer science whether
something was achieved a year or two earlier or later.
But it can make quite a substantial difference to the
company which achieves it first.
All in all, this author sees no valid basis for criticizing
the nature of the action within the private sector. On
the other hand, it will be appropriate from time to time
for the Government to underwrite exploration of
important areas where the chance for profit is too far off
to attract private industry. Some comments may be in
order on how such exploration should take place. The
particular question of interest to this author is whether
the exploration should rely on simulation or on machine
construction.
Some years ago it was argued plausibly that the
effective speed, for real large problems, of a new
architecture could only be determined by implementing
that architecture in a real computer as big and fast as
anything else available. The argument was that only
then would the appropriate people be motivated to
optimize methods and programming. This may well
have been true some years ago, but it is probably not
true now. Two relevant things have increased in the
last few years, namely the ability to do simulation at
reasonable cost and the number of unemployed
scientists.
CONCLUSION
To find the best computer, one must explore the space
of computer design, componentry, mathematical
method, and, programming technique. For a given
computer design (or, at least, architecture), there has
been substantial progress from improved componentry.
This progress will continue for some time, but not
forever. There has also been substantial progress from
improved methods and programming techniques. This
progress will also continue for some time, quite possibly
forever.
On the other hand, one cannot say that, for a given
componentry, there has been or is about to be substantial progress from improved architecture. Part of the
reason is that the 40 percent per year of progress which
has been available without architectural change puts
a handicap on any development which requires more
time (because it is breaking new ground) between
choice of components and delivery. The rest of the
reason must be that no new architecture has
been invented which offers an order of magnitude
improvement.
Some day, the rate of increase of component speeds
must become small. At that time, architectural changes
which give small improvements in performance will be
profitable. In this area, it seems safe to assume that
exploration by industry will be adequate.
If, on the other hand, as seems likely, the practical
limit on gate count goes up by several orders of magnitude, substantial improvement will be available from
architectural changes, and only from architectural
changes.
It is on this basis of very large gate count that architectural exploration will be needed, in the opinion of the
author. If such exploration is to be carried out bel'ore
the large gate counts are actually available, it must of
course be done by simulation. The right time to begin
is probably about ten years before the results are
needed. Is that today? Was it, perhaps, a few years
ago?
APPENDIX
If a memory technology came about which could
give one function unit very fast access to all the words
in a large memory, if there were an architecture with a
crucial need for such very fast access from n function
units, if such access to a small (e.g., register) memory
were already in hand, and if the memory technology in
question were so cheap that one could afford n-fold
memory redundancy, then one might consider the
following.
Let each function unit have its own memory, and
let each memory start out with identical contents.
Define two types of storing, A and B. A Type A store
is the ordinary type, in which, logically, the old value
of some variable is instantly replaced by the new
value. A Type B store goes only to "empty" cell (i.e,
it replaces dead, or garbage, information) and the
information is not going to be refetchable for a long
time. Then require all problems to restrict Type A
stores to the small memory and make only Type B
stores to the large memory.
Many readers will lose interest at this point; there
Computer Architecture and Very Large Problems
are, nonetheless, many large problems which fit these
rules. What is proposed, obviously, is that Type B
stores be propagated from memory to memory at
leisure. The whole thing would likely be of interest only
if this propagation came from a natural diffusion
inherent in the physics of the memory. For example,
49
imagine that the binary storage element is a cell in a
long filament. The filament is stable with all its cells
zero or all its cells one. If any cell is changed, the
change propagates along the filament in both directions.
Each function unit gets at all the filaments at some
convenient station along their length.
Scientific applications of computers in the '70s
by M. STUART LYNN
Rice University
Houston, Texas
was required was another substantial injection of
federal or other support to achieve the necessary
breakthrough. In application after application a
similar pattern was followed: early promise with highly
simplified models indicated great things to come, only
to be followed in time with the limitations of reality,
as the complexities of highly nonlinear or otherwise
complex problems and indeterminate data circumscribed the bounds of possibility. The debris left behind in many of the goldfields became depressingly
familiar.
N ow we no longer attempt fifteen decimal places.
We talk instead of provoking lines of thought which
might not otherwise have occurred. This is probably a
healthy trend, although it is perhaps unfortunate that
we are still not learning from the past in some newer
application areas.
It is still fashionable to predict that what happens
in the future of computing will be a glorified extension
of what has happened in the past. Thus, the last decade has seen an explosion in all uses of computers
and therefore, so the fashion would dictate, this explosion must necessarily continue if the faith is not
to be shaken.
There is no doubt that exciting new ways of putting
computers to work will be found. This writer is in no
better position than anyone else to forecast what these
will be. It will, however, be the main thesis of this
discussion that the explosive rate of growth will not
continue, particularly in the area of scientific applications, but that the emphasis will be on making known
applications work, and work in a more meaningful
environment.
GOLDFIELDS
INDUSTRY TRENDS
The gold-rush of the sixties is over-this period was
characterized by taking a field of man's endeavor, any
field, multiplying it by three and attempting to automate it, independent of whether or not such automation could in any way be justified. Support was easily
available for anything and, as such practically every
field of man's interest was a candidate for computer
application. The fact that reality has fallen short of
promise has left a skeptical, if not nasty, taste in many
mouths. It is probably true, however, that we have
been left with a more realistic perspective as to the
meaningful uses of computers and, even more importantly, the limitations of such usage.
The gap between promise and reality is, for example,
evident in application areas dependent upon modelling
or simulation. Ten years ago it was customary to insist
that we were on the verge of modelling the world and
its component parts to fifteen decimal places; all that
In addition to the effects of left-over skepticism,
trends in the computer industry will also mitigate
against a continuation of the applications explosion.
It is certainly highly probable that the current computer overcapacity in this country, when combined
with the decreasing cost/performance curve of computer systems, will cause considerable pressure on the
industry to underwrite nmv applications as a means
of supporting continued expansion of the industry.
However:
• I t is likely that the most acceptable applications
will be those whose economic pay-off is readily
justifiable in the short-term, in view of past management experiences and of the current economic
climate. This would tend not to favor scientific
applications.
51
52
Spring Joint Computer Conference, 1972
• The effects of unbundling have already moved
the onus of applications research and development
more than ever on to the end-user. This will
continue. Whereas this has little impact on the
traditional user of computers, it reduces the prospects of important uses of computers materializing
among new user classes.
• The increasing pressure for rapid economic justification lessens the changes of serendipity yielding
new applications. The principal opportunities for
serendipity will continue to move back to the
universities; this is probably not a bad thing, except that universities are not always in the best
position to judge user needs over the long-term.
WHAT WILL HAPPEN?
This writer suggests that the following are likely to
be characteristic of scientific applications of the next
decade:
(1) The areas of application familiar today are
unlikely to change substantially. The relative
emphasis between areas is, however, likely to
change as a reflection of society's changing
priorities, as has already been observable over
the past three years. Thus, for example, as a
reflection of NASA's changing priorities, the
use of computers in support of this nation's
activities in space will shift toward the many
possibilities involved in applications relating to
the Earth Resources Program, a shift that has
already begun to take place. Again by way of
example, the ability to simulate ever more
complex molecules and chemical reactions will
have important applications in the petroleum,
chemical and pharmaceutical industries.
(2) Basis technological developments in support of
applications will not mature at anywhere near
the pace of the sixties. The emphasis will shift
toward making fuller use of existing technologies and in making them support each other.
Thus, for example, the concern of the sixties for
speed and compactness in algorithmic processes
will have diminished importance in the complex
environments of present and future operating
systems and as the cost of computing continues
to decrease. On the other hand, the unnatural
boundaries between such areas as numerical
analysis, mathematical programming, computational statistics, signal analysis, pattern recognition and control theory will continue to become
less well-defined.
(3) There will be more emphasis on total systems
implementation of known applications so that
they are economically (or otherwise) useful to
the end-user. This will include careful exploration of computing environments in order to
minimize overall costs and to maximize, inter
alia, user productivity and convenience. In this
context there will continue to be an increasing
emphasis upon reliable systems. Substantial
investment in research and development of
scientific computer applications will be closely
geared to their proven practicality and utility
in society as a whole.
(4) Basic methodologies already well understood
in established application areas will be brought
to bear upon newer areas. Examples of this are
to be found in the electric power industry and
in water estuarial modelling where only too
often the simulation techniques currently used
are primitive by comparison with what has
been developed in other application areas.
(5) The computer will continue to be brought to
bear, only with ever increasing emphasis, in
making the scientific research process itself
more efficient. Advances in the technology of
interfacing with computers will become sufficiently reliable and efficient that the use of such
technology will become widespread (many
scientists use computers today no differently
than they did ten years ago, in spite of the
changes that have taken place). The ability to
interact efficiently with large data bases, the
growth of extensible languages, the develop·ment of special processors configurable by the
user to meet his particular requirements, are
examples of technologies which will have an
impact upon ways in which scientists use computers.
This appraisal is not intended to be pessimistic.
Within the above confines, the opportunities for using
computers in exciting ways should be as great, if not
greater, than ever before. The challenge, however, is
one of turning more of the promises of the past decade
in to accepted reality.
The functions and elements of a training system
by B. A. JONES
Bankers Trust Company
New York, New York
"From a systems point of view, the design of an
operation which can successfully carry out the training
function becomes a problem of creating a system to
accomplish a given end result or objective. In the case
of training, this end result is to effect a group of planned
and predetermined behavior changes in the organization.' '1
The following are five basic functions that I feel are
essential for an effective training system that will allow
you to effect that group of predetermined behavior
changes:
I.
II.
III.
IV.
V.
3.
4.
5.
6.
Is this
Is this
Is this
Is this
an attitude problem?
due to a lack of resources?
due to a lack of reinforcement?
a procedures problem?
When this element of the training analysis has been
completed, the suggested solution to the initial request
or desired end result may be made. If the suggested
solution is to develop a training curriculum, the third
element in the training analysis, that of stating the
terminal behaviors, begins.
Once this has been accomplished, the design of the
training curriculum proceeds. It is at this point that
the cost of training, the length of training, the media,
the method of evaluation, may be determined.
The implementation and evaluation of the training
curriculum may end the analysis function. If the desired
end result was not obtained, it may be due to a bad
analysis or a poor design. Whichever is the case, a
reiteration through the process is essential. If the desired end result has been met, the final element is to
maintain the material. That is, if it is a one time only
curriculum, it is placed in a history file. If it is an ongoing curriculum, it is kept up-to-date.
When the suggested solution, the second element, is
not the design of a training curriculum, the Educational
Consulting function becomes crucial. Figure 2 illustrates
the elements of this function. It differs from the training analysis in that the training person acts only as an
advisor, i.e., he can suggest solutions but is not accountable for implementation or evaluation. Figure 3
lists some of the skills and knowledge necessary for
successfully performing the consultation function. The
questions asked during the follow-up emphasize the
advisory capacity of the consultant.
The third function of the training system, Training
System Support, is basically an administrative and
maintenance activity. However, the support is essential
for a training division if it is to effectively serve and
Training Analysis
Educational Consulting
Training System Support
Public Relations
Management
The elements of each of these functions become the
procedures necessary for the successful operation of the
entire training system. To better understand these five
basic functions it is necessary to look at their elements.
The training analysis function (Figure 1) and its
elements is the critical activity in determining training
requirements.
We begin the analysis by gathering valid data. That
is, in terms of performance, what is it you want the
trainee to do that he is not now doing, or what is it you
want him to do better? Determine whether these are
basic skills and knowledge he should possess or whether
they are supplemental skills and knowledge that will
upgrade his proficiency. This may determine the priority
of training.
The second element in the training analysis function
is to address performance standards by conducting a
deficiency analysis. At this point the following determinations must be made:
1. Is this a training problem?
2. Is this a feedback problem?
53
/
54
Spring Joint Computer Conference, 1972
Sell
Interview
Problem Solving
Advise
Help
Expertise in training
Communication
Analysis
Suggestions
Persuade
Confident
Confidentiality
Patience
Sensitivity
Follow-up
-did you decide?
-what did you decide?
-were you 'successful?
-may I help you?
Figure I-Training analysis function
assist its users. The elements of this function are
exhaustless, but three of these elements are vital.
Record keeping provides an historical reference for
each student and aids in defining what courses he
must yet complete in terms of his career development.
Record keeping is of great importance also in pre par-
Figure 3-Consultation skills and knowledges
Name,_ __
Course
Date__________ _
Title____________ Phone_________ _
Uptown
Department _________ Downtown
Division_________ _
OTHER
DEPARTMENT
r----
r- - ~
~
E. D. P.
PROBLEM
ECOGNITION
(Performanc
deficiency
I
N
TRA NI G
Supervisor's signature__________________ _
Current Responsibilities: _________________ _
-,-----It-----...,
PROBLEM
DEFINITION
The following information is helpful to the course instructors and
they would appreciate your cooperation in supplying it.
AL TERNATIVE
SOLUTIONS
(Recommended
solution if
advisable)
EXPERIENCE
Number of years/months in any Data Processing Function:
Programmer________ _
Systems Analyst_______
Other (please state) __________________ _
FOLLOW-UP
I
- _____ J
EDUCATION
Check highest Degree and indicate major:
High School______ --'-__ Undergraduate______ _
Graduate__________ Ph.D._________ _
Major__________ _
Figure 2-Consultation function
Figure 4-Systems analysis and design-Enrollment form
Functions and Elements of a Training 8ystem
ing a cost per student figure, developing and justifying
a yearly budget, and forecasting resources. Figure 4
illustrates such a form.
Equipment maintenance is necessary for an effective
and efficient training facility. It doesn't matter if the
facility has only a one person training staff, a conference
room, and an overhead projector, or is a large scale
multi-media facility with a full-time training staff.
Calvin R. Gould, put it this way:
A national meeting of professional communicators was ending its second day with a banquet
that featured a learned and distinguished
individual. Before the banquet, the speaker's
assistant set up a pair of 35mm projectors
and a screen. This person would be the projectionist and would work from a cued copy
of the speech. While this practice requires
that the speaker read his material, it is more
effective than asking for each slide, and if well
rehearsed, can be professionally done. The
audience quite properly expected a worthwhile
message from the speaker, a vice president
of a large manufacturing company. They
weren't to be denied. His initial remarks,
charging the audience with their responsibility
to world communications, proved he was going
to be a dynamic speaker. As the first slide
was projected the house lights went off right
on cue. Everything was working like clockwork, even the pause that followed the first
slide seemed effective and timely . . . except
it seemed to be longer than necessary .. ,
really too long. Finally the audience, the
projectionist, and the speaker all seemed to
realize simultaneously that the speaker's
lectern light went out with the house lights.
The fifteen minutes interruption required to
recover from this unfortunate situation was
enough to seriously damage the communications effectiveness of this presentation. I was
in the audience, and I have long forgotten
the message. 2
A schedule for the maintenance of equipment must
be established, fully documented and enforced. It should
include timetables for the changing of bulbs, the cleaning of equipment, periodic maintenance checks, etc.
Inventory control is important, since in the majority
of installations the training division has equipment that
can be borrowed by other departments. The unavailability of equipment can often lead to the cancellation
of a class. The availability of existing equipment should
DESCRIPTION
SLIDE PROJECTORS
QUANTITY
3
16MM PROJECTORS
55
CONDI- AVAILTION ABILITY
GOOD
YES
GOOD
NO
16MM CAMERA (BOLEX)
1
GOOD
NO
VIDEOCORDER (1/1 & 2")
3
GOOD
31" only
VIDEO CAMERA
1
SATISFACTORY
YES
T.V. MONITORS
5
GOOD
3 only
MARK IV
1
GOOD
NO
CASSETTE PLAYER
2
GOOD
YES
HEADPHONE SETS
4
GOOD
NO
3M FOIL MAKER
1
GOOD
YES
3M OVERHEAD PROJECTOR
1
SATISYES
FACTORY
PORTABLE SCREENS
GOOD
YES
6 FOOT MIC
GOOD
NO
GOOD
NO
GOOD
NO
NECK MIC
1
MARK V
35MM CAMERA
MP-3 CAMERA
1
REPAIR NO
GOOD
NO
Figure 5-Inventory and status report
be documented by an inventory and status report
form. Figure 5 illustrates the form used at Bankers
Trust.
The Public Relations function has two distinct elements. Within the organization, communication is with
users of data processing training. The promotion of
in-house courses and the selling of services are necessary
in order to establish and maintain credibility. The
external element is, on the one hand, to let the rest of
56
Spring Joint Computer Conference, 1972
FORECASTING
1
SET OBJECTIVES
1
ESTABLISH
PROGRAMS TO
MEET OBJ.
1
SCHEDULE
PROGRAMS
.1
WHAT'S TO DO
ALLOCATE
RESOURCES:
PEOPLE, MONEY,
TIME
1
GROUNDS RULES
HOW TO DO IT
PROCEDURAL
STANDARDS OF
REPETITIVE TYPE
WORK
SET
POLICIES
1
ESTABLISH
PROCEDURES
expert in management philosophy or management development, yet find it necessary to manage a training
system, I offer the following descriptions of the four
elements in the management function from Louis A.
Allen, president of Louis A. Allen Associates, Inc.
1. Planning
"Planning is the work a manager does to master
the future. Planning requires that a manager
think before acting. In the process of doing this,
he will map out beforehand what he expects to
accomplish, how he can best do it, and the limits
of cost and other factors that are significant.
The principles of planning stress the importance
of current decisions in limiting our potential
range of action in the future.
They point out that the further we project a
plan into the future, the more unstable and undependable it becomes. A key principle emphasizes the tendency of people to resist changes.
Resistance to change can be overcome primarily
by providing for participation and communication in the planning process. Plans are considered
in terms of the specific activities of forecasting,
establishing objectives, establishing programs,
scheduling programs, allocating resources, setting policies, and establishing procedures." 3
Figure 6 illustrates how our training staff at
Bankers Trust interprets this element.
II. Organizing
"Organizing is the work a manager does to arrange and relate the work to be performed so that
it can be carried out most effectively by people.
An organization is not people but the mechanism arranged to enable people to work most
effectively together. An organization chart is
helpful but the chart itself is not the work of
Figure 6-Management function planning sub-function
ADMINISTRATION
&
the world know what your organization is doing, and, on
the other, to make sure that you yourself are not re-inventing
the wheel.
The fifth function, that activity which permits the
combination of time, people, and money to efficiently
achieve the desired end result, is the Management function. It has four major elements: Planning, Organizing,
Leading, and Controlling. Within each element are
specific activities.
Since most data processing training staffs are not
SCHEDULING
Figure 7-E.D.P. training division
Functions and Elements of a Training System
organizing, for this is how one insures that the
most work is accomplished by the fewest people
at the least cost." 4
Figure 7 illustrates the organization of our training
division.
III. Leading
"Leading is the work a manager performs to get
people to take required action. Leading is the
energizing function that makes planning, control, and organizing possible. In studying what it
takes to lead, we find that there is no one best
management personality. The proper blend of
authoritarian and democratic leadership knowingly applied is best. The specific activities
within this function are decision making, communications motivating people, selecting people,
and the development of people. We are at the
present time within our element of control. A lot
of work has yet to be accomplished so that these
two elements of management will relate directly
to our responsibilities."s
IV. Controlling
"Controlling is the work a manager does to assess
and regulate work in progress and completed.
The control is the manager's means of checking
up.
While control by personal observation is often
necessary, the most desirable method is control
by exception. Here the principle of Least Cause
and the principle of Point of Control are important to ensure that the greatest amount of
control is applied where it will do the most good.
The significant activities inherent in good control
are establishing performance standards, performance measuring, performance evaluating,
and performance correcting." 6
It is apparent that, due to the sheer length of the
process, a training staff of more than one is desirable.
However, given that the training needs are clearly defined and not too abundant, and that time and money
are available, such a process can be implemented effectively by a minimal staff. To a great extent, this is
due to the increasing availability of vendor-supplied
training materials, and also to new, multi-media techniques for its presentation.
To properly select media that will meet training objectives, one must understand the advantages and disadvantages of each. The most commonly used (and
misused) media are the spoken and written word.
Several studies have indicated that we retain only 20
percent of what we hear. It has also been cited that the
average student possesses a reading level of eighth grade
57
or lower. Therefore, it is necessary for the trainer to
know his students' abilities and to adjust his communication methods accordingly.
The studies on learning further suggests that we retain 80 percent of what we see and as much as 95
percent of what we both hear and see. Thus, it appears
that a lecture supported with various media would
allow us to satisfy our objectives in the most efficient
and effective manner.
It has been my experience, being fortunate enough to
have access to a very sophisticated multi-media training facility, that the integration of various media into
our training system has accomplished several things:
1. This integration makes use of two or more senses
and
2. More easily establishes a relationship between
the unknown and the known.
3. Often, visuals can save teaching time because
they add to the student's ability to arouse and
retain interest in the subject.
4. Visuals tend to create a sense of involvement and
partici pation.
5. When color is used in visuals, the retention rate
is vastly increased.
There are certain obvious drawbacks when a training
facility is heavily involved with the use of audio/visuals.
I have stated earlier that the record keeping function is
essential in the smooth and effective operation of a
training facility; I would like to emphasize this importance when using audio/visual media. The hardware
required for the use of audio/visuals must be maintained as "Operational" at all times. It is most desirable
to have backup for each piece of equipment you are
using; the consequences are self-evident.
Staff resources must often be increased to support a
multi-media facility, e.g., for maintenance and ad.ministration. However, once standards and procedures are
developed for maintaining and scheduling equipment,
the advantages one can attain from the use of multimedia are considerable.
In summary, when selecting media for communicating to the Jearner, consider the following procedures:
1. Determine your training objectives first, then
determine the means whereby you can convey
them to the student.
2. Consider the physical constraints; how will they
affect the media you have selected? How many
students will you have at one time? Where will
they be trained?
58
Spring Joint Computer Conference, 1972
3. Determine as best you can the collective backgrounds and abilities of your students, and
which media will have the greatest appeal and
effectiveness for them.
4. Examine carefully the economics of the ideal
system, i.e., look carefully at the cost of
alternatives.
2 C R GOULD
Anatomy of a presentation
Audio-Visual Communications V June 1971 p 20
3 L A ALLEN
The management profession
New York McGraw-Hill 1964 p 109
4 Ibid p 173
5 Ibid p 246
6 Ibid p 324
SUMMARY
BIBLIOGRAPHY
A Training System (the process) is a methodology with
established functions, procedures, and activities one
can follow to effectively and efficiently achieve a desired result.
A properly evaluated multi-media system, when well
maintained, will improve the learner's ability to comprehend and retain the training supplied. This will allow
the training division to accomplish its objective, that
of giving the user of its services what he wants, when
and where he wants it.
REFERENCES
1 M W WARREN
Training for results
Reading Massachusetts Addison-Wesley 1969 p 15
L A ALLEN
The management profession
New York 1964
M M BROADWELL
The supervisor as an instructor
Massachusetts 1970
L BENNIGSON
The strategy of running temporary projects
Innovation Number twenty-four September 1971 pp 32-40
HARTMAN MATTHES PROEME
Management information systems handbook
New York 1968
o GLASER
The management of training
Massachusetts 1970
MWWARREN
Training for results
Massachusetts 1969
Planning data processing education
to meet job requirements
by JAMES O. HAMMOND
IBM Corporation
White Plains, New York
resource. If the data processing staff is selected and
trained to meet the requirements and needs of the
business of the parent company, then a data processing organization has gone a long way toward solving
efficiency problems not to mention personnel problems
and potential large cost savings that can be gained.
The staff human resource portion of a data processing
organization is the one addressed in this paper. More
specifically, ways of defining and structuring data
processing skills and job responsibilities are explained.
Approaches are included on ways of defining an education program to provide the knowledge and skills that
may not currently exist in the skills mix of the data
processing staff.
Keeping in mind that all the other key factors of
operating an efficient, productive data processing
organization have not been forgotten, concentrate
for a moment on how we might go about putting some
form and rationale to human resource selection and
training.
One of the most effective ways of relating data
processing skills requirements, and in turn DP education, to a data processing organization is to start with
the process being used to develop and implement data
processing products. Relating skill requirements to the
process is especially effective because the process is
normally a well established one with which most
company management are familiar both inside and
outside the DP organization. Since the DP process is
the mainstream around which the majority of all
other DP activities in a department revolve, it is most
likely a well defined and valid process. If the DP
department is just being organized or for some other
reason the process to be used is not well defined, then
first things should be first-the process should be
clearly resolved and defined.
The major steps of the DP process will vary from
one DP organization to another and, of course, from
The greatest single expenditure that a data processing
organization has today is for its human resource. This
has been dramatically illustrated in several well-known
studies. The cost of human resources continues to rise
in data processing. Computers and systems are becoming more -and more complex. It has become extremely difficult for programmers and analysts to
know all the essential things about a system. This is
especially true with the large, widespread teleprocessing networks. This complexity of sytems is forcing
more and more specialization in computer technology.
At the same time, small computer staffs find that although a few staff members may know all that is
required to support a system, it is frequently difficult
to identify job responsibilities in such a way that
maximum efficiency can be attained for the benefit of
the business.
Most data processing organizations have major
effects on their parent company's ability to meet the
needs of its business. It becomes of vital importance,
therefore, that the data processing or information
systems department, as they are frequently called,
be managed as efficiently as possible providing the
business support to its parent company in the most
optimum fashion. Obviously, the management of any
data processing department is an important key factor
in its success. In this day and age of national economic
lull and austerity moves in business to get more for
the dollar spent, it has become even more important
that management exercise its very best judgment at
all times to run the data processing department more
as a business and not just as a support function. In
other words, have as valid justification that the money
spent is worth what is being gained from the output.
There is another extremely important factor to
consider in maintaining a high efficiency level in a
data processing organization. This factor is the utilization of the staff employees or the bulk of the human
59
60
Step
Spring Joint Computer Conference, 1972
Example 1
I Study
II Design
III Develop
IV Install
V
VI
VII
VIII
IX
X
Example 2
Example 3
Example 4
Example 5
Concept
Definition
Develop
Acquisition
Operational
Evaluate
Concept
Definition
Develop
Operation
Determine Function
Develop System
Data Collection
Consider Alternatives
Select Solution
Formulate System
Review
Test
Install
Measure
Application Analysis
Design Synthesis
Feasibility Validation
System Design
Development & Test
Installation
Operation
Maintenance
Figure I-DP process steps
one company to another. This is expected and even
desired if the organization is being primarily tailored
to meet the needs of the parent company's business.
Figure 1 shows a selection of DP processes chosen
from the DP organization of several companies in the
United States. It can be seen, as was just mentioned,
that the steps in the processes do vary. It is interesting,
however, to notice that in spite of variations in the
steps of the process and that some of the steps are
called by different names with essentially the same
meaning, that there is a thread of commonality through
all the processes. There are some process steps that are
common to all data processing organizations regardless
of size, complexity, systems types, or structure. Three
of these common steps are design, install, and maintain.
It is important that the major steps of the process be
clearly defined in any given DP organization where the
human resources are being studied. Once this is done a
framework is established around which the human
resource requirements can be structured. The process
shown in Figure 2 has been selected for the purpose
of illustrating how we can go about relating the human
resource requirements to a DP process.
Considering the common thread through the proesses again-design, install, and maintain-these general terms can now be expanded into the selected
process.
Before we go further in skills requirements structuring, we must make sure that each step of the process
is defined well enough so that there is no miscommunication. I have attached the following definitions to each
step of this process. Keep in mind that there is no hing
fixed about the process and the associated definitions
that are being used in this example. Although, according
to surveys made, this is one of the more common
processes, the steps and definitions may be different
for various DP organizations.
So that we may continue our analysis, here are the
definitions that will be used.
Process Steps
APPLI CATI ON ANALYS I S
I.
II.
III.
IV.
V.
VI.
VII.
VIII.
DES I GN SYNTHES I S
FEASIBILITY VALIDATION I----Design
SYSTEM DESIGN
---1-
Applications Analysis
Design Synthesis
Feasibility Validation
System Design
Development and Testing
Installation
Operation
Maintenance
DEVELOPMENT &TESTING
Definitions
INSTALLATION
OPERATION
MAINTENANCE
-----'IJI-I------Install
Figure 2-The process
I. Applications Analysis
Maintain
This first step includes defining the problem,
analyzing and documenting the existing system,
describing the processing, defining output and
performance requirements, estimating the value
of what is required, and developing and present-
Planning Data Processing Education
ing the initial specifications to management
for their review and concurrence.
Basic
I ntermediate
61
Advance
APPLICATION ANALYSIS
II. Design Synthesis
Ski"s{~
This step includes establishing project planning
and control, checking and refining the systems
requirements and initial specifications, developing preliminary design alternatives and selecting
a solution that is most economically feasible
and best meets the requirements specified
(with supporting analysis from Feasibility
Validation). The system solution is then proposed to management where a decision must
be made whether to proceed into System Design
or consider alternative solutions.
III. Feasibility Validation
System
Support
Operations
APPLICATION ANALYSIS
DESIGN SYNTHESIS
DEVELOPMENT & TESTING
MAINTENANCE
Fi~ure
Skills{ ..
SYSTEM DESIGN
Ski"S{~
Skil S{
.•
Figure 4-Application development
IV. System Design
This step includes planning and designing the
details of the systems solution using the output
from Design Synthesis and the feasibility model,
selecting hardware and software, developing the
new procedures and test plan, and identifying
each program.
Here the process is completed and proved by
translating the system and program specifications into machine-readable code, testing and
debugging this code and documenting each
program module.
SYSTEM DESIGN
OPERATION
FEASIBILITY VALIDATION
V. Development and Testing
FEAS I BI LITY VALIDATION
I NSTALLATI ON
Ski"S{~
DEVELOPMENT & TEST I NG
This includes the processing testing the performance, technical feasibility and validity of
design alternatives or existing solutions by
creating prototypes, models or through simulation. Major cost and performance improvements can be made possible by the application
of standard solutions and generalized program
designs already available. Adaptations of existing systems or generalized programs may be
entirely adequate solutions; therefore, no further
design work would be required.
Application
Development
DES I GN SYNTHES I S
I
•
3-The process expanded
I
VI. Installation
This step includes converting data files, transactions, software and hardware used by the
existing system to meet the requirements of the
new system.
62
Spring Joint Computer Conference, 1972
TITLE:
SENIOR ASSOCIATE PROGRAMMER, DEVELOPMENT.
GENERAL CONCEPT:
AN ACTIVE MEMBER OF AN INTERNAL DATA PROCESSING SYSTEM APPLICATION TEAM, RESPONSIBLE FOR
DEFINING PROBLEMS, PROPOSING SOLUTIONS, DEVELOPING AND TESTING THOSE SOLUTIONS.
HE IS QUALIFIED TO SPECIALIZE IN THE AREA OF PROGRAM MODULE DEVELOPMENT.
SPECIFIC RESPONSIBILITIES:
(1) THE PRECISE DEFINITION OF PROGRAM MODULES (INPUT, TRANSFORMATION, AND OUTPUT) WHICH
WILL IMPLEMENT THE SYSTEM DESCRIBED IN SYSTEM DESIGN.
(2) THE DOCUMENTATION, FLOWCHARTING AND CODING OF THE MODULES SPECIFIED.
COMMUNICATES WITH:
TESTING SPECIALIST FOR RESULTS OF MODULE AND SYSTEM TESTS.
SYSTEM DESIGN SPECIALIST TO REQUEST MODIFICATION OF SYSTEM SPECIFICATIONS, IF THEY ARE FOUND
UNCLEAR.
MANAGER TO REPORT PROGRESS AND RECEIVE ASSIGNMENTS.
APPROPRIATE TOOLS, TECHNIQUES AND SKILLS:
ADVANCED PL/l
MODULAR PROGRAM DESIGN
PROGRAMMING TECHNIQUES
OPERATING SYSTEMS INTERFACE
PROMOTION POSSIBILITIES:
STAFF PROGRAMMER, DEVELOPMENT AND TESTING
SENIOR ASSOCIATE PROGRAMMER, SYSTEM DESIGN
Figure 5-Job description
VII. Operation
This step includes running the designed and
tested system (or application) on the computer.
VIII. Maintenance
This includes the maintenance of the software
systems programs and applications programs,
e.g., changes, extensions, and optimization.
There are specific skills, tools and techniques that
must be known and applied to accomplish each of the
steps in this process. If the organization is a large one, a
staff member might specialize in one or two of these
steps and be required to master a smaller number of
tools, but be able to apply these with considerable
expertise. A small DP organization would not have a
requirement for such extensive expertise; the staff
member may, therefore, be skilled enough to perform
several of the steps in the process to a much less level
of complexity.
At this point the DP organization functions and job
responsibilities can be related to the process that has
been described. The organization functions can be
identified as being three maIn segments of activity:
1. Application Development
2. System Support
3. Operations
Figure 3 shows how these organizational functions can
be related to the process. Notice the overlap among the
functions. For example, the system support function
overlaps the application development function in the
development and test step and installation step of the
process. In large installations where a high degree of
specialization may exist, these overlaps indicate the
points where responsibilities are passed from one
person or group to another. It is extremely crucial
that these key points of communication are identified
and the responsible staff members are made aware that
this "passing of the baton" so to speak, is an important
part of their responsibility. It is equally important
that they be adequately trained to carry out these
tasks with great efficiency.
Now take another cut at the same process from the
individual staff member point of view. For the purpose
of analyzing how this might be done, consider the applications development function alone for a minute. The
staff working within this function of a DP organization
Planning Data Processing Education
63
Responsibilities / Skills
(Be Able To:)
Application Analysis
Analyze existing system/applications
Document system
Define system requirements
Development and present initial specifications
Design Synthesis
Refine initial specification
Develop conceptual solutions-design alternatives
Identify and select known/existing solutions
Specify details of each design alternative
Estimate development, conversion, installation and operating
costs
Test and evaluate alternatives and select best solution
Present proposed system solution
Feasibility Validation
Create and test prototype systems
Construct and analyze or simulate models
Compare prototype or model to required systems performance
Technical Strength Definitions
o has no knowledge
1
2
3
4
understands capability and applicability
can use technique effectively
can maintain, modify and create new features
can synthesize and evaluate to reduce or eliminate analysis,
machine runs, development or tests based on his wide
knowledge of alternatives and depth of experience.
Systems Design
Development systems design work plan
Document system in detail
Design forms and reports
Finalize record and file requirements
Define data editing and validation rules
Select final hardware configuration and software
Document controls, audit trails, back-up procedure
Write new and revise old procedures
Plan system test and prepare test data
Prepare computer operations work flow
Document computer flow and identify each program
Development and Testing
Define program modules
Flowchart, code and document program modules
Design and implement program module tests
Implement system tests specification in system design
Figure 6-Programmer/analyst in application development environment
is made up for the most part of one of three types of
personnel: analysts, programmers, and managers. The
analysts are known as systems, application or program
in most cases. The analysts' job responsibilifes can
range across the analysis, synthesis, validation, and
design of DP systems and applications. Programmers
are generally of two primary types, applications
and systems. Applications programmers program
and test primarily business applications whereas system programmers program primarily control and
system applications. There are a wide range of job
responsibilities performed by programmers at all
levels of complexity. The managers referred to here are
technical managers. It is important to identify the job
responsibilities of higher management along with all
the other members of the organization but higher
managements' job responsibilities are broader, less
technical, and more administrative. For this reason they have been excluded in the sample being
used in this paper. The technical manager is one who
has direct supervision over a small staff of programmers or analysts and is able to understand technical
detail, at least within his assigned responsibilit·es.
There are numerous titles for programmers and
64
Spring Joint Computer Conference, 1972
RESPONSIBILITY (SKILLS)
(BE ABLE TO:)
BASIC
INTERMEDIATE
ADVANCED
APPLICATION ANALYSIS
ANALYZE EXISTING SYSTEM/APPLICATIONS
DOCUMENT SYSTEM
DEFINE SYSTEM REQUIREMENTS
DEVELOP & PRESENT INITIAL SPECIFICATIONS
DESIGN SYNTHESIS
REFINE INITIAL SPECIFICATION
DEVELOP CONCEPTUAL SOLUTIONS-DESIGN
ALTERNATIVES
IDENTIFY AND SELECT KNOWN/EXISTING SOLUTIONS
SPECIFY DETAILS OF EACH DESIGN ALTERNATIVE
ESTIMATE DEVELOPMENT,CONVERSION, INSTALLATION
AND OPERATION COSTS
TEST AND EVALUATE ALTERNATIVES AND SELECT
BEST SOLUTION
PRESENT PROPOSED SYSTEM SOLUTION
FEASIBILITY VALIDATION
CREATE AND TEST PROTOTYPE SYSTEMS
CONSTRUCT AND ANALYZE OR SIMULATE MODELS
COMPARE PROTOTYPE OR MODEL TO REQUIRED SYSTEMS
PERFORMANCE
SYSTEM DESIGN
DEVELOPMENT SYSTEM DESIGN WORK PLAN
DOCUMENT SYSTEM IN DETAIL
DESIGN FORMS AND REPORTS
FIN ALIZE RECORD AMD REQUIREMENTS
DEFINE DATA EDITING AND VALIDATION RULES
SELECT FINAL HARDWARE CONFIGURATION AND
SOFTWARE
DOCUMENT CONTROLS, AUDIT TRAILS BACK-UP
PROCEDURE
WRITE NEW AND REVISE OLD PROCEDURES
PLAN SYSTEM TEST AND PREPARE TEST DATA
PREPARE COMPUTER OPERATIONS WORK FLOW
DOCUMENT COMPUTER FLOW AND IDENTIFY EACH
PROGRAM
0
0
1
1
0
1
2
2
2
2
2
3
3
3
3
3
4
4
4
3
4
4
4
4
4
4
4
4
4
4
0
2
3
3
4
4
0
1
0
1
1
2
2
2
2
3
2
3
3
4
3
3
4
4
4
4
4
4
4
4
1
2
3
4
4
4
DEVELOPMENT AND TESTING
DEFINE PROGRAM MODULES
FLOWCHART, CODE AND DOCUMENT PROGRAM MODULES
DESIGN AND IMPLEMENT PROGRAM MODULE TESTS
IMPLEMENT SYSTEM TESTS SPECIFICATION IN SYSTEM
DESIGN
Figure 7-Programmer/analyst in application development environment responsibility (skills) matrix
analysts. It is best, of course, to define job levels using
the titles of a given DP organization. In Figure 4, the
levels-basic, intermediate, and advanced,-have been
used to relate job levels to the process. The bar graphs
under these levels give an indication of the approximate
average level required to perform the job responsibilities
in the corresponding process steps. For example, most
senior staff personnel have had experience and/or
training in development and testing before advancing
to more senior positions in either systems design,
feasibility validation, or design synthesis. This type
of structuring forms a rather neat array of potential
career paths.
Job levels, titles, and major responsibilities are
traditionally structured into a job description. Job
descriptions can range in form from the one sheet
summary shown in Figure 5 to very detailed descriptions. In all cases, it is worthwhile specifying the
Planning Data Processing Education
Basic
65
Advanced
In termediate
System Design
.-----------------------------------------------------------------------------------------------------------------------,
: Develop system design work plan
: Document system in detail
: Design forms and reports
: Finalize record and file requirements
: Define data editing and validation rules
0
0
1
1
0
1
2
2
2
2
2
3
3
3
3
3
4
4
4
3
4
4
4
4
.:i
4
4
4
4
4
0
0
1
0
1
1
2
3
2
3
2
3
3
3
3
4
3
3
4
4
4
4
4
4
4
4
4
4
4
4
4
:
:
:
:
J ______________________________________________________________________________________________________________________ _
Select final hardware configuration and software
Document controls, audit trails, back-up procedure
Write new and revise old procedures
Plan system test and prepare test data
Prepare computer operations work flow
Document computer flow and identify each program
1
2
2
2
2
Technical Strength Definitions
o has no knowledge
1
2
3
4
understands capability and applicability
can use technique effectively
can maintain, modify and create new features
can synthesize and evaluate to reduce or eliminate analysis, machine runs, development or tests based on his wide knowledge of alternatives and depth of experience.
Figure 8-Programmer/analysts-Responsibility matrix expanded
knowledge and skills required as well as promotion
possibilities. This information is valuable to management both in utilizing the employees best talents and
planning for his career advancement.
A further expansion is necessary of the knowledge
and skills required to do the jobs within each step of the
process. If some type of job analysis has not been performed on the data processing organization in question,
then now is the time. What the job involves, the complexity of the technical level, the associated responsibilities, and, last but not least, the knowledge and
skill level required to do the job all must be defined to
fulfill the requirements specifed in the steps of the
process. Much of this information can be structured
on the job description summary sheet that was just
described.
Job analysis should be done by professionals who have
had experience in making such analysis. This type of
study is usually performed for a fee by an outside
consultant. If the consultant is carefully chosen the
results will be well worth the money but be sure that he
has extensive data processing expertise on his staff to
participate in the analysis. Also make sure that his
analysis is going to be provided to you in a form that
fits your needs and is tailored to the process in your
organization.
There are many good approaches to job analysis
Most of them involve some type of general experience
questionnaire and the observation and interview of
selected employees doing their job. It is important to
make sure that the employees have a good underst' nding of what is being done and why job related questions
are being asked. Employees quickly become skeptical
and concerned when a lot of questions are asked about
their job and how it is performed. The cooperation
given by the staff in programs such as this will be
much better and with a more positive attitude if the
reasons are first clearly explained.
Under each of the process steps the major skills,
actions, and knowledge are identified that are important in accomplishing the step in the DP organization.
Try to refine these major items as much as possible so
they will be concise yet descriptive of the responsibility.
Sometimes it is difficult to express all the items purely
in the terms of skills. For this reason be practical and
realistic about the results by using a mixture of skills,
actions, and knowledge. This approach seems to render
a better level of definition.
Figure 6 shows how this expansion can be accomplished. Keep in mind that we are talking about the
application development function of the DP organization and the associated programmer and analyst staff.
For this reason the expansion shown is for the first five
steps of the process.
The technical strength definitions below show how
knowledge levels can be identified. Once again these
definitions should be prepared with the requirements of
the organization in mind. There must be an adequate
66
Spring Joint Computer Conference, 1972
range in the knowledge levels. With programmers and
analysts it is especially desirable to be able to identify
whether they can explain a concept and apply it as well.
Technical Strength Definitions
o
1
2
3
4
has no knowledge
understands capability and applicability
can use technique effectively
can maintain, modify and create new features
can synthesize and evaluate to reduce or
eliminate analysis, machine runs, development or tests based on his wide knowledge of
alternatives and depth of experience.
You will notice that these levels are primarily for
programmers and analysts so that we may continue
to expand our definition of the application development function.
All the data that is needed to put together a summary
skills matrix of a selected DP organization should now
be available. The data includes:
1. Definition of the steps in the DP process to meet
the needs of the business.
2. Definitions of job responsibilities to meet the
process requirements.
3. Association of these job responsibilities with
defined jobs.
4. Identification of the level and possibly the title
of each of the defined jobs.
5. List of the major relevant skills, actions, and
knowledge to meet the defined job responsibilities.
6. Define the strength levels of the skills and
knowledge requirements.
A summary skills matrix can now be constructed by
inserting the strength indicators required for each
defined activity of each process step. The strength
indicators are placed in the appropriate job title or
level column.
Figure 7 shows how the technical strength indicators
are added to the System Design step of the process.
The strength level definition and the job level to which
it is associated is determined primarily from the
data obtained as a result of the job analysis and survey
of the staff's skills.
When the summary skills matrix is constructed for
all members of the DP organization, it becomes an
invaluable management tool in planning and obtaining
the required skill mix. The skills matrix also acts as a
key index in planning tailored education for the staff.
This can lead to significant savings in education
expenses to a company.
Using the summary skills matrix and data from the
job analysis and knowledge surveys, a trained industrial
educator can determine what additional knowledge and
skills are needed to enhance that already possessed by
the staff. The identification of the missing skills and
knowledge is the foundation on which future training
Name:
Business System Design
Duration:
Five days
Audience:
Those with the responsibility for the detailed design of a
business system.
Prerequisites:
Experience in program development and testing or successful
completion of the development and testing curriculum.
Objectives:
Upon successful completion of this course, the student will be
able to:
Develop cost estimates and a work plan for scheduling and
controlling the work through the design phase.
Define the record content, file organization, storage requirements and access methods.
Define data editing and validation rules, controls and audit
trails.
Design the necessary forms and reports.
Complete the detailed documentation of the system, specifying
the input, output, processing and file requirements of each
program.
Prepare the systems test plan.
Topics *
Systems design cost estimating planning
and scheduling
Detailed record design, file organization
and access method specification
Editing, validation, controls and audit trails
Forms and reports design
Procedure writing
Systems test planning, test data and file
preparation
Program specification and documentation
Estimating programming development time
Case study
Total
Hours
2
4
2
2
2
4
4
2
8
30
* These topics teach to the 2 and 3 technical strength levels.
Figure 9-Course specification
Planning Data Processing Education
can be based. Much of this needed training can be
accomplished on the job or through self-study. Some
of it will require more formal classroom education.
In any case, the education will be tailored toward the
business needs and requirements since it is based on
a foundation geared toward that same goal.
Regardless of whether the training program required
is going to be developed in-house or contracted out to
an education company or computer manufacturing
company, it is good to have at least a general specification of the type of training needed.
Using the related job responsibilities boxed in on
Figure 8, a training specification can be written.
Job responsibilities that are related should be clustered
together so that eventually a series of topics or modules
can be defined to teach the relevant subjects. Related
topics, in turn, are normally grouped together to form
a course.
The course specification shown in Figure 9 is one
designed to teach to the 2 and 3 strength level on all the
job responsibilities boxed in Figure 8. Notice that the
course specification identifies the most pertinent facts
67
about the training needed. The audience, prerequisites
and a clear definition of the objectives are the most
important items. Individual topics that make up the
course and the approximate duration of each can be
included when they are needed. The purpose for using
a duration on each topic is to give some indication of the
depth that topic covers.
I said at the beginning of this paper that surveys show
that the greatest expenditure that a data processing
organization has is for its human resource. Actually it is
the knowledge that is being purchased. This statement
applies equally as well to most all human resource
requirements in industry. In Peter F. Drucker's
recent book, The Age of Discontinuity, he treats knowledge as one of the four discontinuities. Mr. Drucker
says, "Knowledge, during the last few decades, has
become the central capital, cost center and the crucial
resource of the economy."
Since knowledge is a very valuable and expensive
commodity it should be treated as such. Planned
education according to the needs of a business will
impart knowledge where and when it is required.
Modular training-A new emphasis
by ROGER
w.
KLEFFMAN
United Air Lines
Englewood, Colorado
basis, and to accomplish training on second or third
shift, or even on a part-time basis.
The balance of the paper presents the details relating
to this particular project. This includes principles of
course development, course descriptions, and the
required training sequence for positions on the project.
It should be stressed that no really new principles or
techniques are offered, only a new emphasis or applying
some old methods (and not so old, such as v:deo
modules) is advocated here.
INTRODUCTION
During 1970 and early 1971, United Air Lines and IBM
implemented a PARS-based (Programmed Airline
Reservations System) reservations system. This system
is written in Assembly Language Coding for the IBM
360/65. The software is special purpose, dedicated
to providing very fast response to remote airline reservations inquiries including: schedules and availability
between cities, passenger name data, and related
information. At the start of the project, there were
virtually no United personnel with PARS experience,
and the implementation phase included the development of a comprehensive training program. The
principle objectives of this program, over and above
that of preparing United programmers and operators
for participation in the project, included the capability
to be completely self-sufficient for PARS training at
United, the ability to administer training as personnel
became available to the project, and the desire to
maintain a minimal staff of professional trainers.
To achieve these objectives 12 special courses were
developed using the guidelines described as modular
training. These courses, developed by IBM for United,
were according to specific guidelines and standards.
The standards emphasize that courses should be
developed in short, self-contained parts, bring the
student into direct contact with source information
and use other media (e.g., video tapes, audjo tapes)
slides) to amplify material being presented to the
student. This assists the student in advancing at an
individual pace, and encourages self-sufficiency.
The basis for this paper is that an in-house training
program can be developed which is self-sufficient. The
need for outside training may exist for course development. However, generally development can be accomplished by line personnel with technical competance
designing training courses in accordance with welldefined 'standards and objectives. Once developed, it is
possible to administer the training on an "as needed"
MODULAR TRAINING
Modular training is the term used by United to
describe training in terms of courses divided into
specified units. A course is defined as: a set of objectives
that should be achieved by a target audience together
with training material, a time duration for the course,
and a plan for accomplishing the training. Training
courses are tutorial for programmers and operators on
this project in that training is viewed as the transfer
of information necessary for the student to carry out
job responsibilities in a defined area. This is in contrast
to training in a seminar environment by means of
exchange of ideas among participants. Under the
modular approach, the responsibilities for programming
and computer operator positions have been keyed to the
courses. Each position has an identified sequence of
training courses through which a student progresses
prior to full-time work assignment.
Under this modular training approach, each course is
admjnistered to a student by an advisor, an experienced
person with successful completion of the course or with
extensive experience within that area. The governing
elements of the course are a student guide and an
advisor's guide.
The student guide is a document which coordinates
the student's progression through training materjal.
It is designed to give the student the information
69
70
Spring Joint Computer Conference, 1972
REFERENCE 1
o
REFERENCE 2
REFERENCE 3
o
Figure I-Student guide
nec~ssary for a thorough understanding of the subject,
as Illustrated by Figure 1.
The intent of the student guide is to direct the
student through applicable training material in a given
order. This includes readings in references not cont~ined. in the guide itself (technical manuals, profesSIOnal J~urnals), or viewing video tapes (including local
productIOns keyed to specific elements of the project),
as well as utilizing the guide itself for tutorial material.
In particular the video tapes are a valuable means
for producing training material. Use of video tapes is
to deve' op standard, lecture-type modules and elimi~ates the requirement for an instructor to repeatedly
gIve the same stand up lectures. Video is also useful in
explaining standards and procedures, which can be
presented to the student as dictated by students responsibilities to the project. The advisor, however,
must always be available to answer questions or exchange dialogue with the student on the basis of the
information in the video tape.
By design the student guide cannot and does not
function alone as a self-sufficient course, such as in
p:ogrammed instruction. The advisor is a necessary and
VItal part of the course in modular training.
The format of the student guide includes:
A. Introductory Section
1. Course description and intended audience.
2. Course objectives.
3. Prerequisite
training
and/or
related
experience.
4. Recommended duration of the course.
5. Advisor/student relationship.
B. Reference Material
This section identifies all other manuals and
documents needed in the course.
C. Detailed Assignments
This section presents the series of steps which
lead the student through the material. It includes
reading assignments, identifies lectures, designates participation in workshops, and tests to
determine how well the student is learning and
applying the material. In courses involving
programming, actual coding experience is accomplished by assignments which are processed
on the computer.
A history log is maintained for each course containing
questions raised by students during the course. This
information is used to develop additional explanatory
material, quizzes, or more detailed references to aid the
student in acquiring a better understanding of the
subject.
COURSE ADVISOR
The second key element in modular training is the
Course Advisor. By design the course can be administered to a single person, to a formal class of students ,
or to several students who have started the course at
different times. Except for formal classes, the advisor
performs this roll on a part time basis. As a result, line
programmers can function as advisors as well as having
normal job responsibilities.
Under United's approach, only one person devotes a
full-time effort as the advisor for basic courses, and line
programmers act as advisors for advanced courses.
Each manager furnishes the advisor for advanced
courses for students who will receive assignments in
that manager's area. Only senior, experienced personnel
are used as advisors. This represents one of their job
responsibilities, and is a means of providing further
experience in the management aspects of dealing with
people.
The advisor has three primary responsibilities:
1. To serve as a point of reference for any questions
the student may have on the course material.
The advisor may not be able to answer every
question, and may have to get the answer from
another source. In any case, the response is on a
timely basis.
2. To administer quizzes and exams to the student
as required in the course sequence. The results
are always reviewed with the student to insure
complete understanding.
Modular Training
3. To emphasize the most pertinent parts of the
course relative to the student's work area, and to
evaluate the student's understanding of the
course. Here, the advisor's function is to tailor
the course to the student's needs. The advisor
takes the initiative in discussing the important
aspects of the course instead of passively waiting
for the student to ask questions. By probing the
student's thought process the advisor can fill in
any areas of weakness and correct misunderstanding. Normally, the advisor spends 7i to Y2
of the student's assigned course time, depending
on the advisor's familiarity with the course and
the extent of the student questions. For example,
if a student is training on a half-time basis, the
advisor can expect to spend VB to 7i of that time
in an advisory capacity. The advisor also provides up-to-date technical information on the
system, which minimizes the problems associated
with technical obsolescence of training material.
CAREER PATHS AND COURSE PROGRESSION
The U nited PARS project provides training for
programmers, data base personnel and computer
operator personnel. This section describes each job and
the training sequence required.
There are seven areas of programming responsibility:
1. Application Programmer
Develops programs in a real-time environment
which accomplish the airline reservations functions. These include display of airline schedules,
availability of seats inventory control, flight
information, and programmatic exchange of
information with other airline reservations
systems. Programming is done in ALC, the
assembly language used for coding on the IBM
360 series.
2. Schedule Change Programming
Includes an understanding of batch processing
as well as real-time programming, and has
significant impact on many system data records.
These include modifications to flight schedule
information and development of information
used to reaccommodate passengers. Programming in ALC under DOS and OS is included.
3. System Support Programmer
Has responsibility for the generation and
maintenance of systems, both OS and DOS,
PARS off-line support, together with file
maintenance and management reports. Programming languages include P LjI and FORTRAN.
71
4. Control Program Programmer
Has assignments in inputj output for disk and
tape, CPU scheduling, queue processing for input,
ready and deferred lists, interrupt handling and
on-line data collection.
5. Communications Programmer
Is involved with control and coordination of
communications between remote sites with
CRT terminals as well as with the other computer systems. There is heavy involvement
with hardware such as IBM 2703, WE201B
modems or equivalent, IBM 2948, and the IBM
2915 or equivalents.
6. Performance Evaluation Programmer
Analyzes the PARS system performance by
measuring and interpreting system characteristics including inputj output message size,
program core residency time and execution
time, file accesses and queueing. Simulates the
system by means of model(s) and predicts
system performance relative to proposed
modification.
7. Coverage Programmer
Has primary responsibility for the diagnosis
and immediate correction of on-line software
malfunctions, as well as monitoring on-line
system software integrity. Programming occupies a relatively sm9,ll amount of time.
Two Data Base jobs pertain to information records
in both the on-line and off-line systems. Programming
experience is not required for these jobs:
1. Data Base Specialist
Has the responsibility for the integrity of all
passenger information in the on-line system.
This can involve restructing parts of the data
base as a result of airline rescheduling as well as
corrections to erroneous on-line information.
2. Data Base Coordinator
Has responsibility for maintaining airline schedule information, pilot data information and
communications tables. These are processed in
the off-line system.
Computer Operations involves three tasks:
1. Data Control Clerk
Receives and monitors off-line processing jobs,
maintains tape and disk libraries, and JCL card
decks for off-line jobs.
2. Computer Equipment Operator
Operates all equipment in the off-line-system
72
Spring Joint Computer Conference, 1972
\ DATA
BASE
PROGRAMMER
\ OPERATIONS
1
b~ ~~,~
'I>{,.t(>4:{!z~ '" 8/j.A .AkJ(){(>~~4i.{J. (>O~~4 4 .e.:l'4l/j.t~~qt80
:Z-Oq
~~O~~~ ':4i; ~:Z-Oq&~:;;.tOq~(J~~..t!&.e :e 00 Oq.(>~O ~.(> 0 'l;e 0
.AkJ()~~(>:~-r4'~ (>{,~'I>~Ir..t~~Ir..t:r;O
~ ~
~~~
d
zH
zH
~
8
0
\0
(Y'l
d
zH
zH
«
I):;
8
fQ
D
R3
INTERNAL.~
SCHEDULE CHANGE-INPUT DATA
PREPARATION
OFF-LINE SCHEDULE CHANGE
ON-LINE SCHEDULE CHANGE
COMMUNICATIONS
'DATA COLLECTION
DATA BASE MANAGEMENT
SYSTEM OPERATOR TRAINING
TOTAL TRAINING DAYS
FOR REQUIRED COURSES
Rl
R2
Rl
R2
~./)
~
50
45
55
50
R8
Rq
RIO
Rl1
D
Rl
D
R~
80 10
3
R = Required
D = Desirable
Subscript indicates course sequence number
*Not required for all System Support Programmers
Figure 2-Career path training sequence
and assists in monitoring the on-line system
activities.
3. Console Operator
Has responsibility for operating the hardware
in the on-line system. Monitors and controls
system configuration, and applies corrective
action for hardware failures.
The training required for these positions is summarized in Figure 2. IBM/360 training is also shown
Modular Training
in presenting the training progressions. The total training days associated with the IBM/360 training and the
PARS training identify the time needed before an
individual is ready to accomplish productive work.
For example, a programmer with no 360 computer
background would require both IBM/360 and PARS
training. For applications programming, 40 training
days would be required. If the programmer already had
IBM/360 experience and no PARS experience, 25
training days would be required. The description of
PARS training courses is given in the Appendix. Both
the training results and the training duration are good
as evidenced by high comprehension rate and mininal
training period.
SUMMARY
As a part of the implementation of a PARS system,
United Air Lines has developed a comprehensive
training program using the modular method with
three objectives:
1. United is self-sufficient for PARS training
(N ote: PARS training requires IBM 360 knowledge as a prerequisite).
2. Training is administered as people are available.
3. Training is accomplished with a minimal
professional training staff.
Twelve courses were developed to achieve these
objectives for the different job responsibilities within
the project. More than sixty students were successfully
trained with this method.
An advisor is a key element in administering modular
training. The advisor is responsible for tailoring the
basic course to reflect the content of the student's
assigned area, and to monitor the student's progress.
Drawn from the line organization, the advisor is proficient in the assigned area and monitors the student's
progress by answering questions, administering quizzes,
and probing the student's understanding of the subiAp.t
matter.
Modular training with professionally competent
personnel acting as advisors eliminates the need for
formal classes, and training can be administered on an
"as availa;ble" basis, although a class can easily be
accommodated with this method. In addition, the
advisors have line responsibilities and thus the need
for a large, dedicated training staff is eliminated.
Currently, at United one person has full-time basic
training responsibility for the 70-80 project programming staff.
73
Advanced training advisors are furnished by the area
to which the student is assigned.
Generally only senior persons are advisors and
represent a part of the responsibilities of a senior
position. Being an advisor usually affords first exposure
to working with people in a management mode, which is
good experience if further advancement along supervisory lines is desired.
In particular, however, it was found that:
1. An advisor is indispensable to the program, and
cannot be passive. The advisor must actively
monitor and encourage the student's progress.
Experience has shown this method has favorable
results.
2. Prior to starting the training, there should be a
review meeting between the student, the assigned
manager and the advisor. The review will include
the sequence and duration of the courses for the
student, the approximate expected progress
(relative to whether the student will be in
training full-time or part-time), and the role and
responsibility of the advisor(s).
3. Practical problems, and quizzes which reflect the
course objectives are essential, especially for
programming courses. A simulation of the real
environment is necessary for coding and debugging problems. The course content must be
tutorial and serve as a transition into the work
environment.
4. Insofar as possible, training, especially the
advanced training, should be on a part-time
basis. This gives the student a better opportunity
to assimilate the many new concepts and
terminology as training exposes them. In fact,
terminology is a major factor on this project,
because the student is not only using EDP
terms, but also the special vocabularies associated with airlines and with the PARS system.
5. Update of course content caused by system
change is best accomplished by line personnel.
In this case they act as advisors but without
students, and have the responsibility for updating the applicable course content.
6. The student guide/advisor functions best in a
non-development environment. In a totally
developmental environment, scheduling is a
problem. Estimates of required program development time always seem to neglect factors which
were not expected to occur (sickness, machine
downtime, etc.) In either case, the line must be
staffed to accomplish both programming and
training requirements.
74
Spring Joint Computer Conference, 1972
Overall, modular training has worked reasonably well
for the United Airlines PARS project. The primary
objectives have been satisfied by a minimal professional
training staff and utilization of line personnel in the
training function. The advisory responsibility takes
time, however, and an advisor's schedule must include
time for training in addition to normal line responsibilities if modular training is to function properly.
This same method should also be able to work for
other projects. A student guide need not necessarily
be a reference unto itself, it may be a series of references
to other manuals, documents, video tape, et al. Video
tapes, in particular, afford the means of augumenting
course material and making it available for training
around the clock. There currently exists a dearth of
organized information and material which can be used
to construct a course. There is no prophet for rewriting a
document which can be used in its present format with
directions as to applicability. Both the student guide
and the advisor furnish this direction to the material
and provide tailoring specific to requirements.
APPENDIX A
Course descriptions
This Appendix presents a description of the 12
courses that were developed at United Air Lines.
These specific courses are applicable only to a relatively
small group of PARS users.
It should be noted that because the courses are
tutorial, quizzes form an important part of the course,
being geared to the course objectives. The student is
expected to achieve certain defined objectives, and the
quiz results represent, in part, how well the material
has been learned, as well as performance evaluation.
Training in PARS requires a knowledge of the IBM
360 hardware and Assembly Language Coding (ALC).
These are prerequisites for all the PARS Programming
Courses. Commercial video taped courses, augmented
by material particular to United's needs, satisfy these
requirements.
The PARS courses are divided into two sets; a basic
set which all programmers attend, and the advanced
courses, which are attended on an "as needed" basis.
The first three courses listed below are the members
of the basic set; all others belong to the advanced set
for programming except the operator course, which
is independent. Sixteen video tapes have been produced
by United to augment the basic PARS training. These
were produced based on an evaluation of the information in the history log, an invaluable tool for developing
training modules such as programming techniques,
project procedures, and the like. In addition, the video
modules are always available to the student on an
around the clock basis, thus helping to free training
from the prime shift dependency.
1. PARS System Description-3 days
This course presents the basic PARS hardware
and software descriptions, as well as concepts and
terminology associated with the airline industry
as well as PARS system. Emphasis is placed on
providing the fundamental information concepts
and terminology needed in other courses.
2. Applications Programs-5 days
This course presents the functions of all PARS
application program packages including programs within each package, and describes the
data records required by each program explaining
how these records are accessed and data is
manipulated. It relates airline reservations agent
actions and needs to the manipulation of the
applications programs and the data records.
3. Airlines Programmer Environment-17 days
This course is divided into three major areas
corresponding to the types of programmer activities in this real-time PARS environment:
1. Program Development
The availability and use of programmers tools
such as: entry control block, macros, and
conventions.
2. Program Maintenance
The PARS Program Library System, the
steps involved in entering programs, the
inputs necessary for program maintenance.
3. Program Testing
The concepts and procedures used in testing,
in generating test inputs and in interpreting
test results.
The course environment is designed to resemble,
as closely as possible, the expected environment
in the development group. The subjects discussed at length are those dealing directly with
the job of application programming.
Upon completion, the student is capable of productive assignment in applications programming
within the PARS environment.
4. ACP Fundamentals-5 days
This course introduces the programming t.echniques such as queuing, priorities, message
flows, and related items used by the Control
Program.
Modular Training
Upon completion the student is able to relate
the functions of the ACP program to his present
assignment.
S. ACP Internals-IS days
Airline Control Program Internals is concerned
with program listing level discussion, by topic,
of each of the functional units of the airline CPo
This includes communications, hardware input/
output, and services and facilities provided to
application programs.
Upon completion the student is prepared to
accept assignment in any functional area of the
Control Program. The student will lack only
what can be gained through experience.
6. Schedule Change Input Data Preparation-3
days
Editing and validation of modified schedule
information is the main objective of this course.
Upon completion the student is able to prepare
the input data required for Off-line Schedule
Change.
7. Off-Line Schedule Change-S days
Topics covered include concepts of off-line schedule change; off-line schedule change input and
processing, and a detailed analysis of the off-line
schedule change programs.
Upcn completion the student is able to communicate in the language of schedule change
with non-programmers and other PARS Application Programmers, use to use the appropriate
documents to extract the details of the schedule
change programs assigned as the student's responsibility.
8. On-Line Schedule Change-S days
This course presents the functions of all the
on-line schedule change programs, defines the
data records affected by the on-line schedule
change and describes how they are affected,
9.
10.
11.
12.
7S
explains the four logic phases of the on-line
schedule change, and relates the programs and
data records involved to each phase.
Communications-S days
This course presents PARS Communications in
general, and specifically as applied in United's
PARS System. This system exchanges communications with two other United Air Lines
On-line Computer Systems. In addition PARS
Communications is covered from the functional
level to a detailed program level which describes
the interrelationship of the programs, tables
and data records involved.
Data Collection-S days
This course describes the functions of the Data
Collection Programs and defines the facilities
provided by these programs, explaining how
system, file, program and message variables are
collected on-line, and reduced off-line. It identifies listing variables which are out of line from
data collection reports and determines from
these variables how system performance can
be improved.
Data Base Management-20 days
Data Base Management covers four major file
support functions and data base generation.
These include: Pool Directory Generatbn and
Maintenance, Recoup, Capture/Restore, Fixed
File Reorganization and System Test Compiler.
System Operator Training-S days
This course describes, in general terms, a typical
PARS hardware configuration and the PARS
software system. In addition performance of the
following operator tasks is explained: program
library maintenance and update, testing, system
load, all other off-line and on-line operator
activities, interpretation of error messages, and
use of functional messages appropriate to a
given job.
Computer training, present and future
by GORDON A. SMITH
Jet Propulsion Laboratory
Pasadena, California
INTRODUCTION
cassettes and a small workbook for those who want to
become familiar with data processing terms. One of the
major banks in Arizona has required its 132 branch
managers to review this course while traveling to and
from work. It is also an excellent device to augment
stand-up instruction for a new student. Several firms
today have canned video-taped courses along with
workbooks as a self-instructional means to replace the
very widespread utilization of PI or programmed instruction textbooks. To my way of thinking, there is
nothing more borjng, and less motivating, than sitting
down with a workbook, and saying I am going to learn
by myself and teach myself something, whether it is
data processing or any other area of interest.
Another firm, in addition to its video taped courses in
basic computer programming-COBOL, FORTRAN,
and so forth-has a considerable library of animated
motion picture films, along with associated workbooks
and other materials as a self-teaching means in support
of standardized automatic data processing (ADP)
curricula. Some of the films are excellent, and, in some
cases, we have utilized them to augment our classroom
course "Introduction to Computer Technology." A
firm in Illinois has developed a systems analysis course,
as well as courses in operating systems (OS) with a
thorough interaction between video tape, audio tapes,
and workbooks-none of the media being used for more
than 15 minutes at a time. There is a constant transfer
from one medium to another which provides not only
motivation but reinforcement. More of the physical
senses are used in the absorption of educational material. Of course, motion picture films are also used;
films themselves are a bit more cumbersome, but if
intermixed with other media, may become a viable
means of instructional transfer.
I believe that audio tapes, video tapes, motion picture films, and animated cartoons can effectively. be
used in a learning carrel. A carrel is nothing more than
an enlarged desk with various devices in it; one can
Before beginning this discussion, I would like to make
a few remarks concerning the Jet Propulsion Laboratory (JPL). The Jet Propulsion Laboratory is responsible to the National Aeronautics and Space Administration (NASA) for unmanned missions in deep space.
A worldwide tracking network encompasses Goldstone,
California; Madrid, Spain; Johannesburg, South Africa;
and Woomera and Tidbinbilla, Australia. In addition
to the deep space missions, there are a great number of
scientifically oriented projects throughout JPL. The
Laboratory has approximately 4,100 employees, as well
as some support contractor personnel.
All levels of personnel in JPL, as well as contractor
operations personnel, are involved with the educational
programs, starting with "Introduction to Computing"
through management training in the data processing
field.
Within almost every government organization, and
certainly within every NASA facility, a considerable
workload rests within the administrative and financial
operations. These are nonscientific endeavors which
hopefully will lead toward improved management information system controls. A commercial enterprise,
financial operations organization has a number of
similarities.
To begin with, I have prejudices against classrooms
of stand-up instruction only, or classrooms of videotaped lecturers only, or instruction in any single medium. Therefore, I will spend a few moments reviewing
some of the products of educational firms today leading
toward altmultimedia approach to the education and
training of commercial programmers, systems analysts,
or obviously, into some of the scientific fields.
Let me cite a few examples of ideas that have come
out of some commercial firms. For instance, there is one
firm in Ohio that has developed a course titled "ADP
Terminology." This course consists of 16 audio tape
77
78
Spring Joint Computer Conference, 1972
COMPUTER-ASSISTED INSTRUCTION
Figure I-JPL training carrel
instruct himself at his own speed, and hopefully, improve his motivation if he has a goal in mind (see
Figure 1). This type of self-instruction is extremely
worthwhile if it is also reinforced by a senior programmer or analyst. The multimedia approach will
create greater motivation.
For a moment, let's look at the benefits. In classroom
training, the teacher is usually - ")sponsible for maintaining a norm at the average class level. Very often
the faster student becomes quite bored because he is
ahead of the group, whereas the slower student is having a problem keeping up, and thus becomes rather discouraged. Most schools in the data processing field require the student to write, run, and debug test programs
on whatever type of equipment that school may possess.
There is a danger at times if the "school" has only the
equipment of one manufacturer and is not able to provide good classroom direction where students can effectively learn the differences between equipment of various manufacturers-either small-scale computers or
large-scaJe systems.
A list of the computer courses available at the Jet
Propulsion Laboratory, along with the computer selection procedure, is given in Appendix A; a set of computer-related job descriptions from the Computer
Education Directory published by Edutronics Systems
International, Inc., Los Angeles, Calif., is presented in
AppendixB.
Computer-assisted instruction, or CAl, is a relatively
new medium to augment the other media I have discussed; however, I am certain all of us will be influenced
by it over the next few years. I feel we are missing a
very worthwhile and cost-effective tool. Helen Lakin
at the University of Wisconsin noted there are 1,264
program descriptions in the publication Index to
Computer-Assisted Instruction. These descriptions are
from sources in the United States, Canada, Europe,
and Japan, representing elementary and secondary
school systems, colleges, and universities that have
complete CAl courses for credit. As an example, the
University of Southern California recently instituted a
complete course in Programming Language I by CAl
for three units of credit. Many universities are using
CAl as a self-teaching method very successfully for
both direct teaching and remedial education. In none
of these situations does it mean that there is not a
teacher available to answer questions or at least to
cover the highlights that may be misunderstood. In the
government area, certainly throughout the Department
of Defense, there are any number of programs that are
offshoots of simulation programs as well as specific
courses in CAL Many of the programs, however, are
tailormade to the particular command or to the
organization.
I t is extremely important that data processing organizations thoroughly evaluate available software
systems in today's market, whether they are proprietary or in the public domain. For the programmer or
systems analyst, where it can be shown to be costeffective, there is no better system than one with immediate feedback. From a motivational standpoint,
the one-to-one relationship without outside distraction
can be made a very viable and successful means of
instruction in this field. It seems strange that there are
not more schools or private firms teaching programming, systems analysis, or data processing management
on a computer terminal.
Briefly, from the principal title of the session, let's
consider the capability of the computer in CAL In
August 1970, a test project was instituted in the Communications Electronics School Battalion at the Marine
Corps Recruit Depot in San Diego, California. Twelve
terminals were connected by data link to a UNIVAC
1108 computer some 75 miles away. A stand-up class
was run concurrently with the CAl classes. Individuals
were psychologically matched, and each student proceeded through the course of instruction at his own
pace. Of considerable importance, the Marine instructors wrote their own courses for the computer after
Computer Training, Present and Future
only two weeks of instruction from the manufacturer. A
system of positive or negative reinforcement of learning
experience was presented to the student immediately.
The immediate benefits of the teaching experience were
the objectivity, data collection and reduction, and
standardization of instruction. Cathode ray tube terminals were employed. The results demonstrated substantially increased learning in the CAl class; and
subsequent to the test, far greater retention was
achieved. This demonstration has convinced Headquarters Marine Corps to initiate formal schools in
CAl at the Marine Corps Station at Twenty-Nine
Palms, California. Sixty terminals will be employed,
course time will be reduced by 20 percent, and instructor requirements by 75 percent of instructor manpower.
In the universities, there is a strong tendency to tie
CAl courses with other portions of the curricula. There
is a major tendency, of course, to deal primarily with
the fields of scientific uses of the computer, or, in other
words, its applications to physics, chemistry, biology,
genetics, etc., rather than to the straight business approaches; however, some universjties are improving
their curricula, from computer programming on into
the area of management information systems. There is
an excellent marriage between business management
and the tools the computer can provide.
GOVERNMENT USE OF COMPUTERS
The government was the first major user of computers, in the late 1940s and early 1950s. Commercial
data processing centers have become increasingly
widespread. Subsequent to unbundling, the government agencies developed their own schools and separate
series of grades within the Civil Service Commission
to handle the various levels of computer programmers
and systems analysts. One of the problems of government, as well as of all large business operations, is fre~
quently a lack of communication among similar services
and organizations. The Office of Management and
Budgets in Washington is examining improvements in
communication among similar elements of government,
where both can utilize the same software, hardware, or
systems approaches. Where there is coordination among
government entities, cost savings are very substantial.
Due to a low turnover, many large government entities
also realize that their management personnel, as well as
their programming personnel do not effectively utilize
the tools available today.
Many of the leading computer manufacturers emphasize more now than before the need for improved
management training) which, in a sense, goes beyond
79
the scope of this present paper. However, when speaking of education for computer programmers and systems
analysts, we must consider the people who are directing
the needs for this education and training. These needs
definitely stem, and should stem, from a better understanding by management of their own specific needs.
When management understands these needs and can
define them, then indeed they will do a much better
job in hiring personnel. This will establish the type of
training curricula these personnel should have had before being hired.
As a lesson from the government's interest in this
field, communicating between commercial firms possessing similar interests can assist industry in setting
standards or norms of personnel. In Appendix B are a
number of what I feel to be excellent definitions of
programmers and systems analysts. There is a need
throughout the United States today for an improvement in semantics of all facets of ADP terminology in
the entire field. Pers::mnel firms should seek for a common understanding, thus setting some type of definition
of various grades of programmers for the systems
analysts. In large industries, of course, these have been
indicated. However, they vary considerably from industry to industry. By an improvement in definition,
understanding, and attainment, the individuals in this
field should become more professional in their
community.
THE IMPORTANCE OF PRETESTS
Obviously, any paper may reflect the bias of the
individual writing that paper, who may promote those
things that are the most successful in improving his
responsibilities. Both with beginning programmers or
systems analysts, or with those who wish to enter this
field, I am a firm believer in computer pretests. Large
schools have pretests of one type or another. However,
when they are sel1ing courses, their pretests may not
be as restrictive as a pretest would be within my organization or within other organizations depending upon a
profit motive.
Pretests can aid in determining a person's ability to
absorb a particular instructional level. He takes the
test, analyzes the test himself, and, from the results, he
himself should be mature enough to state whether he
has the ability to go ahead as a computer programmer,
as a systems analyst, or in some other field of data
processing, or whether his capability in fact rests somewhere else, and not in the ADP field at all. Many of
the personnel with whom I have been associated who
have taken these pretests have suddenly decided they
80
Spring Joint Computer Conference, 1972
should not take FORTRAN or COBOL, but rather
should go back into a program we have titled "Introduction to Computers," or, in other words, the basic
groundwork-"What is a computer, what does it do,
how does it operate, how does it function, and what are
the various fields to which it could be applied?" The
next step (shown in Figure A-I) analyzes his particular
functional responsibilities, and, from there, determines
the type of course toward which he should direct himself: in other words, what computing system should he
be addressing? This last step is extremely important,
since a person who is completely educated in one type
of equipment, and then is thrown into another organization with an entirely different type of equipment,
normally has some problems adjusting. This can be
prevented if his training is directed toward the type of
equipment he is going to use in the first place. Within
an organization, a person's immediate supervisor is responsible for determining whether company time should
be devoted to such courses or whether the individual
would improve himself by taking courses outside of his
office hours.
FUTURE DEVELOPMENTS
Let's consider some probable areas where changes in
technology should considerably influence ADP education in the next decade. Increasing capability in the
multiprogramming aspects of large-scale computers will
permit a more economical approach toward computerassisted instruction. Initially, however, it should be
treated primarily as an augmentation or reinforcement
of courses rather than as the stand-alone desire of some
CAl enthusiasts. There will be an increasing need for
studies into the motivational aspects of all levels of
individuals, whether students are from grammar
schools or high schools, or are personnel in government
or industry.
According to the ETV Newsletter of July 26,1971, as
an example of the future development (and one that
I believe will be widespread some years from now),
the MITRE Corporation of Bedford, Massachusetts, is
conducting a feasibility study utilizing TVICAI
through cable TV distribution. In this instance, both
the voice and the stiH pictures are transmitted via
microwave and on cable TV to homes equipped with
special terminal and TV set combinations. The company is using its time-shared interactive computercontrolled information television (TICCIT) system to
display selective material on individual TV sets. Thus,
600 TV sets can receive separate information provided
by the computer at typical rate of one frame every 10
a
seconds. The viewer is then in a position to communicate back to the computer through a 12-button telephone. The overall software for the system is designed
under the sponsorship of the National Science Foundation, which can provide individualized educational
courses for home and school use. Over courses that
have a broad-scale interest in the future, therefore, it is
quite likely that up to 10,000 TV sets in one local area
could conceivably be tied into one major system with
a number of different programs being selectively
addressed.
Microcomputers of the future, costing as low as
$2 to $3 K with keyboard and tape cassette units and a
small TV light display, could be utilized by a number
of commercial and governmental operations where
specific instruction is required. * I believe the cassette
will playa large part in the future.
Along with educational programs, we consider the
terminal hardware development. Keyboards have
varied from the standard typewriter keyboard to colorcoded keys for some special studies. It is possible the
lightweight, touch-sensitive surfaces instead of keyboards may be utilized. Common phrases that could
have a general application to a number of educational
uses may be designed into either system.
Pictorial or handwritten input may be one area of
the future, as well as the very early development of
voice input (Culler Harrison, Inc., in Goleta, California, and the Bell Telephone Labs), and, lastly, one
I am certain a number of you have seen demonstrated,
the plasma array terminals developed by Dr. Donald
L. Bitzer of the University of Illinois in conjunction
with Owens Illinois Glass Co. As some of you may recall, the view plate which replaces the video tube consists of three layers of glass with gold wires and an
X/Y axis, imbedded in an electrolyte containing neon
gas. The dots of stimulated neon gas, 3600 per square
inch, may display pictures without computer regeneration, allowing both the computer and the user to modify
the display. A number of these terminals are presently
in manufacture by The Magnavox Co. for the University. I feel this type of approach ~rill contribute a
great deal to the ability of fairJy small computers having a capability to relate through educational systems
to a number of terminals.
The software field also has a major impact upon the
future of education and training to systems analysts
and programming personnel, in that language capa-
* F. W. Blackwell, The Probable State of Computer Technology by
1980, With Some Implications for Education, P-4693 R, The Rand
Corporation, Santa Monica, Calif., Sept. 1971.
Computer Training, Present and Future
bility should certainly be on higher level than it is at
present, including switchablemicroprograms, very
large memories, associative memories, and other variables at an economical cost which could contribute
considerably to a multi-user access. In a sense, with the
technological changes, both in hardware and software,
the aspect of the present programmer training should
change markedly from the existing languages and the
present direction. One of the interesting fallouts in
teaching FORTRAN to a group of high school students
on the West Coast recently resulted in improved ability
of the students in their other courses. Apparently
there is some relationship to the logical display of
FORTRAN which overlapped into an improved understanding by these students in other subjects within
their curricula.
Another aspect of the future is the multitude of
libraries of application programs available to all facets
of industry, government, and the educational community. With improved library maintenance and cross
correlation, hopefully, many users of the future will
be prevented from "reinventing the wheel" concept,
and will be forced to thoroughly review the application
programs available before they attempt to develop
training programs on their own. Therefore, extenE?ive
markets exist for personnel to improve the development of such a compendium. Along with these application programs, however, and one of the aspects that is
not as thoroughly covered today, is that of computer
costs associated with each application program. This
type of data will definitely have to be included in any
compendium of library programs (similar to COSMIC, *
which is operated today) .
In communications, I feel many of us have seen
limitations in our present telephone equipment; however, in the near future, firms similar to DATRAN,
whose microwave towers will be completely devoted to
data processing centers throughout the United States,
as well as improvements in our present communication
equipment and satellite interface, will aid considerably
in the more economical aspects of computing, as well as
the education and training in a CAl approach throughout major time-sharing networks.
In summary, there will be a considerable change in
programming languages, major changes in terminals
and hardware equipment, and a greater interest and
acceptance of computers.
81
RECOMMENDATIONS
For the educational, governmental, or business organization involved with its own educational development, it is essential to seek a multimedia mode of
educating personnel. Do not rely on self-instructional
manuals for the individual to develop an ability on his
own. Upon completion of internal or external schooling,
maintain an open view to periodic reinforcement of
whatever course the individual attends.
Whenever possible, seek or have developed pretests
to determine the level of investment your organization
would make with the individual. It is normally wiser
to allow management personnel the prerogative for selfcorrecting to determine their level of instruction. I feel
that senior and middle management are too often neglected in the general concepts of computer technology.
Be aware of the developments in the university and
governmental areas in education and training as they
may very often be obtained without cost to your organization. The NASA data bank (COSMIC) is an
example of this.
Lastly, in returning to the major subject of this
session, that of training of commercial programmers
and systems analysts, a thorough review of the commercial school, in addition to the very excellent training
offered by the major computer manufacturers, should
be made. University or high school evening classes very
often may be an economical advantage in this evaluation. Maintain an awareness of the development of
CAl as it is being used in grammar schools, secondary
schools, and universities. Most important of all, to the
prospective programmer or analyst, be aware of the
"state of the art" changes to prevent ccmplacency.
ACKNOWLEDGMENTS
This paper presents the results of one phase of research
carried out at the Jet Propulsion Laboratory, California Institute of Technology, under Contract No.
NAS 7-100, sponsored by the National Aeronautics and
Space Administration.
APPENDIX A-COMPUTER COURSES AT
THE JET PROPULSION LABORATORY,
CALIFORNIA INSTITUTE OF TECHNOLOGY
GENERAL INFORMATION
* The Computer Software Management and
Information Center
(COSMIC) is maintained for NASA by the University of Georgia
and provides a national data bank of software programs developed and debugged by government agencies and in the public
domain.
Definition of terms
Pretest. These are self-administered, self-graded tests
whose purpose is to help the individual determine that
82
Spring Joint Computer Conference, 1972
dance or upon the demonstration of proficiency in the
techniques or skills taught.
Survey
ARE YOU
A SCF
NO
The courses were developed in response to the major
needs expressed and measured through the Training
Needs Survey.
IBM COURSES
USER?
YES
SCFPROGRAM
LIBRARY
Schematic
A diagram of the courses available is shown
Figure A-l.
III
INTRODUCTION TO COMPUTERS
Figure A-I-JPL computer course selector
For Whom:
the course is correct and that the individual is neither
underpowered nor overpowered for the course material.
The pretest also provides a general feeling of course
content.
Prerequisites:
Description:
Time distribution charts
Objectives:
Each pie chart indicates the approximate distribution of the total time of the course required both in
and out of class. The symbol "I" refers to Instruction,
"P" refers to Participation, and "H" refers to
Homework.
Text Provided:
Pretest:
Time Distribution:
Certification
Certificates of completion are issued and recorded in
the personnel file. They are based either upon atten-
Those with little or no knowledge
of computers. Quota limited.
None.
Description and explanation of
computer purposes, parts and functions, computer languages, programming concepts, and the computers at JPL.
To gain a general understanding of
computer-related technology and
terminology.
Handouts.
Recommended.
Instruction: Lectures with audiovisuals.
Participation: Discussion.
Homework:
Simple
problem
assignments.
Computer Training, Present and Future
Schedule:
Four 2-hour sessions; 2 weeks. A
new class to be held each month
during the year.
Prerequisites:
"Programming
course.
Description:
Introduction to the elements of
FORTRAN and the methods of
writing programs in it. This course
includes several illustrative problem assignments.
Objectives:
To gain ability to write simple
programs in FORTRAN.
Text Provided:
FORTRAN
notes.
Pretest:
Recommended.
PROGRAMMING FUNDAMENTALS
For Whom:
Prerequisites:
Description:
Objec#ves:
Text Provided:
Pretest:
Time Distribution:
Those with no computer programming background who plan to take
other courses in computer languages. Quota limited.
None.
Introduction to computer programming, its logic, elements,
terminology, and procedures. Preview of FORTRAN, COBOL, and
X-BASIC.
To gain general awareness of computer programming concepts and
languages.
None.
Recommended.
83
Fundamentals"
IV
primer-class
Time Distribution:
Instruction: Video-taped lectures.
Participation: Discussion.
Homework: Problem assignments.
Schedule:
Schedule:
Instruction: Live and video-taped
lectures.
Participation: Discussion.
Homework : None.
Four 2-hour sessions; 2 weeks.
Classes to be held each month during the fiscal year.
Twelve 2-hour sessions; 6 weeks.
Classes to be given on a bimonthly
basis.
FORTRAN V
For Whom:
Scientific Computing
users. Quota limited.
Facility
Prerequisites:
FORTRAN Fundamentals and
"Beginning EXEC-8" courses and
experience using the UNIVAC
FORTRAN FUNDAMENTALS
For Whom:
Beginning FORTRAN programmers who will use the Scientific
Computing Facility. Quota limited.
1108.
84
Spring Joint Computer Conference, 1972
Review of FORTRAN Fundamentals. Explanation of more extensive capabilities of FORTRAN
for advanced programming technology.
Instructor:
Self-study program with group
discussion.
Text Provided:
1108 ANS COBOL-Programmers
Reference Manual.
Objectives:
To gain ability to write sophisticated programs in FORTRAN.
Pretest:
None.
Text Provided:
FORTRAN V Reference manual.
Pretest:
Recommended.
Description:
Time Distribution:
Time Distribution:
Instruction: Lectures.
Participation: Discussion.
Homework: Program assignments.
Schedule:
Instruction: Discussion leader and
films.
Participation : Self-study.
Homework: Simple problem assignments.
Schedule:
Ten 2-hour sessions; 3Y2 weeks.
Six to eight classes per fiscal year.
Four hours self-study approximately, plus 1-hour group discussion per week; 7 weeks. Four
classes per year scheduled.
BEGINNING COBOL
BEGINNING EXEC-8 CONTROL LANGUAGE
For Whom:
Prerequisites:
Those who will use the Administrative
Computing
Facilities.
Quota limited.
"Programming
Fundamentals"
and "Introduction to Computers"
courses or equivalent.
Description:
Introduction to the elements of
COBOL and methods of writing
programs.
Several illustrative
problem assignments are included.
Objectives:
To gain ability to write simple
programs in COBOL.
For Whom:
Beginning users of the Scientific
Computing Facility. Quota limited.
Prerequisites:
Ability to use X-BASIC, FORTRAN, or COBOL.
Description:
"Introduction to EXEC-8," the
Command Language of the
UNIVAC 1108 System. Preparation of run streams, compilation of
programs, assignment and manipulation of files.
Computer Training, Present and Future
85
Objectives:
To gain ability to prepare simple
jobs for running on the UNIVAC
1108.
Text Provided:
EXEC-8 OPERATING SYSTEMS-Programmers Reference
Manual.
Text Provided:
EXEC-8 Student Handbook.
Pretest:
Recommended.
Pretest:
None.
Time Distribution:
Time Distribution:
Instruction: Lecture.
Partici pation: Discussion.
Homework: Problem assignments.
Instruction: Lecture.
Participation: Discussion.
Homework: None.
Schedule:
Schedule:
Four 1Y2 hour sessions; 2 weeks;
classes to be held each month.
TEXT EDITOR FOR THE UNIVAC 1108
For Whom:
Scientific Computing Facility users
with access to conventional terminals. Quota limited.
Prerequisites:
"Beginning EXEC-8 Control Language" course and experience In
use of conversational terminals.
Description:
Explanation of features of the
UNIVAC 1108, Text Editor and its
use at· demand terminals, creating
and modifying data or files.
Objectives:
To gain ability to utilize more
powerful and convenient methods
of manipulating Source Files from
conversational terminals.
Text Provided:
Text Editor.
Pretest:
None.
EXEC-8 CONTROL LANGUAGE
For Whom:
Scientific
users.
Prerequisites:
Extensive experience with the SCF
computer system.
Description:
Explanation of the full capabilities
of the EXEC-8 Control Language,
system file formats, and programming debugging aids and methods.
Objectives:
Computing
Facility
To gain ability to prepare jobs for
the UNIVAC 1108, utilizing the
full capabilities of the system
available to higher level language
programmers.
Ten 2-hour sessions; 5 weeks; four
classes/year.
86
Spring Joint Computer Conference, 1972
5. Additional Courses: Additional courses are given
in integrated circuit design, computer-aided circuit analysis, integrated circuit application,
speed reading, telephone practice, computer
concepts, and techniques, utilizing audio/video
(animation) program, and \\'orkbooks on various subjects in the computer field in self-study
mode, self-study audio cassette/\vorkbook in
BASIC, FORTRAN, and a computer technology course put out by the AIAA discussing
computer technology media in the next decade.
Time Distribution:
APPENDIX B-COMPUTER-RELATED
OCCUPATIONAL DESCRIPTIOXS*©
OCCUPATIONAL DESCRIPTIONS
Schedule:
Instruction: Lecture.
Participation: Discussion.
Homework: None.
Five 2-hour sessions; 272 weeks;
two classes/year.
ADDITIONAL COVERAGE IN ADP
COURSE CAPABILITY
1. Systems Analysis and Design Course: This is a
30-hour course of self-study, utilizing textual,
audio, and video media (no single medium over
15 minutes at one specific period). It is an extensive, self-study program to develop skills in
systems work for data processing personnel
(DELTAK, Schiller Park, Illinois).
2. ADP Terminology: This is a course completely
in audio, on audio tapes for personnel who wish
to become familiar with data processing terminology. One of the recommendations for taking
this course is to utilize a tape unit in a car going
to and from work, listening and repeating the
words, as well as the explanation following. This
course was developed by a firm in Ohio, and is
being utilized throughout the United States
(DYNAPHONICS, Dayton, Ohio).
3. JPL/OS: The operating system for IBM's
360/75 computers. This program is completely
on video tape for self-instruction or reinforcement, primarily to be used by the computer
personnel having advanced knowledge of computer programs.
4. FORTRAN Fundamentals: In addition to the
classroom presentation, this course can also be
taken on a self-instructional basis by video tape.
The occupations described on the following pages are
considered to be the basic occupations most directly
concerned with electronic computing. These occupations, however, are still fluid.
Hiring requirements and qualifications for employment have not yet been fully standardized. As a consequence, a certain amount of overlap and duplication of
job duties and responsibilities will be noted among the
various occupational descriptions. The occupational
data, however, were assembled from many different
sources and are a reflection of the existing situation.
Since the data reflect the occupational situation as it
exists in varied localities and establishments, the descriptions must be considered as cOIp.posites of jobs,
and cannot be expected to coincide exactly with any
job in a specific organization. It will be necessary,
therefore, to adapt descriptions to fit individual jobs
before they can be used with complete accuracy.
The job descriptions are arranged in seniority order
of their main titles. The wording of the title that appears at the head of each description is a reflection of
common usage. Other titles, by which the job is known,
also appear at the head of each description in small
type. Between the main and alternate titles appears
the code number which identifies the job within the
present classification structure of the U.S. DICTIONARy OF OCCUPATIONAL TITLES.
The narrative portion of each job description is arranged as follows:
Occupational Definition-Thi~ provides a brief description of the duties involved in a particular occupa-
* © Edutronics Systems International, Inc., 1969 (Reprinted,
with permission, from Computer Education Directory, Edutronics
Systems International, Inc., Los Angeles, California, 1969.)
Computer Training, Present and Future
tion. It provides an understandjng of the tasks that are
performed, and the skills and knowledge that are necessary to the performance of those tasks.
Education, Training, and Experience-This section
provides an indication of the amount of education and
the level of training and experience usually required by
management for employment in the occupation. As
previously mentioned, the various occupations and the
qualifications are not standardized, and considerable
variation exists among employers as to required education, training, and experience. However, an attempt
was made to indicate the range of such hiring
requirements.
Special Characteristics-This section provides some
estimate of the worker trait requirements pertinent to
the specific occupations. I t has long been believed
that the ability of an individual to adjust to specific
types of work situations is as significant as the education and training qualifications he brings to the occupation. This seems particularly significant when dealing
with a group of relatively new occupations. Consequent]y, judgments have been in terms of a number of
components consisting of aptitudes, interests, temperaments, physical activities, and environmental conditions to which individual workers have to adjust.
A ptitudes-These are the specific capacities or abilities required of an individual in order to facilitate the
learning of some task or duty. This component is made
up of 11 specific aptitude factors, and is a modification
of the aptitudes contained in the General Aptitude
Test Battery developed in the U.S. Emp]oyment
Service. Those aptitudes were selected which seem to be
significant in the occupation and were identified in terms
of specific work situations. The factor of intel1igence,
however, was not rated because of the difficulty in
writing meaningful descriptive statements.
I nterests-This component is defined as a preference
for a particular type of work experience. It consists of
five pairs of bipolar factors, arranged so that a preference for one factor in a pair generally indicates a lack
of interest in the other factor in the pair. Those factors
were identified which seemed to be significant to the
job in question, and were identified in terms of specific
worker situations.
Temperaments-The temperament component consists of 12 factors defined in terms of specific work
situations that suggest different temperament trait requirements. Each work situation describes a type of
activity that demands a different adjustment on the
part of individual workers. Those temperament factors
were selected that appeared to be significant in the
occupation, and were identified in terms of specific
work duties.
87
Physical Activities and Environmental ConditionsThis refers to (a) the physical activities required to be
met by the worker; and (b) the physical surroundings
which make specific demands upon a worker's physical
capacities. There are six physical activities factors and
seven environmental conditions factors. Those factors
were selected that were significant in the occupation in
the sense that they met established criteria for successful performance.
MANAGER, DATA PROCESSING-(169.168),
DIRECTOR, DATA PROCESSING
Occupational definition
Directs and coordinates planning and production
activities of electronic data processing division. Consults with management to define boundaries and priorities of tentative projects, discusses equipment acquisitions, determines specific information requirements of
management, scientists, or engineers, and allocates
operating time of computer systems. Confers with department heads involved with proposed projects to
ensure cooperation and further defines nature of project.
Consults
with
SYSTEMS ENGINEER, ELECTRONIC DATA PROCESSING to define equipment needs. Reviews project feasibility studies. Establishes work standards. Assigns, schedules, and reviews
work. Interprets policies, purposes, and goals of organization to subordinates. Prepares progress reports to
inform management of project development and
deviation from predicted goals. Contracts with management specialists or technical personnel to solve problems. Revises computer operating schedule to introduce
new program testing and operating runs. Reviews
reports of computer and peripheral equipment production, malfunction, and maintenance to ascertain costs
and plan operating changes within his department.
Analyzes data requirements and flow to recommend
reorganization or departmental realignment within the
company. Participates in decisions concerning personnel
staffing and promotions within electronic data processing departments. Directs training of subordinates.
Prepares proposals and solicits purchases of analysis,
programming, and computer services from outside
firms.
Education, training, and experience
Two years of formal post-high school training in data
processing with courses in business. administration and
88
Spring Joint Computer Conference, 1972
accounting or engineering, or equivalent practical experience is necessary for small computer installations.
College graduation with major in one or more of the
above fields is preferred for large installations. Experience in systems analysis, programming, and computer
operations is desirable. In installations offering more
sophisticated services, such as operations research and
engineering simulation, a college mathematics major
coupled with experience listed above is desirable.
Special characteristics
Aptitudes:
Verbal ability to translate technical terminology into
terms understandable to management and department
heads.
Numerical ability to apply knowledge of linear or
differential equations in evaluating work of department,
preparing reports and proposals for management, and
selling services to outside users.
Spatial ability to read engineering drawings, charts,
and diagrams; to understand presentations, proposed
solutions, and progress reports of business or engineering problems.
Form perception to see pertinent detail in drawing
charts, diagrams, and other presentations.
Clerical perception to detect and avoid errors in
reading and preparing reports.
Interests:
An interest in scientific and technical subjects to cope
with wide range of technical and scientific problems
processed through computer.
A preference for business contacts with people in
directing activities of computer department and to sell
ideas or services.
Temperaments:
Must be able to direct, control, and plan the operations of the division, bringing together knowledge of
operations and information needs of departments, such
as accounting, purchasing, engineering, sales, and inventory control.
Required to deal with people such as management,
department heads, and manufacturers' representatives
to exchange information and ideas, discuss equipment
and their uses, elicit information from departments,
and to answer inquiries from department heads.
Ability to influence management and department
heads to enlist their support for acceptance, expansion,
and sophistication of computer systems; and ability to
sell excess computer time and services to outside clients.
Required to make judgmental decisions concerning
equipment needs, scope of assignments, allocation of
computer time, and organization of departments.
Required to make decisions based on factual data to
evaluate progress or success of computerized projects.
Physical Activities and Environment:
Work is sedentary.
Occasionally walks to various departments and
offices; stands during conferences and discussions with
management, department heads, and supervisor of
computer operations.
Talking and hearing required in conferences and during exchanges of information.
N ear visual acuity and accommodation required for
reading reports and charts.
Work is performed inside.
PROJECT DIRECTOR, BUSINESS DATA
PROCESSING (020.168), BUSINESS-SYSTEMS
COORDINATOR; LEAD ANALYST;
PROGRAM MANAGER; PROJECT
PLANNER; SENIOR SYSTEMS ANALYST,
BUSINESS
Occupational definition
Plans, directs, and reviews business electronic dataprocessing projects, coordinates planning, testing, and
operating phases to complete project with maximum
balance of planning and equipment time, man hours
and new equipment expenditures. Prepares project
feasibility and progress reports. Confers with department heads who provide input and use output data to
define content and format. Schedules and assigns duties
to OPERATIONS RESEARCH ANALYSTS based
on evaluation of their knowledge of specific disciplines.
Coordinates activities of workers performing successive
phases of problem analysis, solution outlining, solution
detailing, program coding, testing, and debugging
(error elimination). Reviews output data and related
reports, applying knowledge of systems, procedures,
methods, and data requirements of management and
other output users to ensure adherence to predetermined standards and devise techniques for improved
performance on similar future projects. Directs revision
of continuous control project to adapt it to new data
requirements or improve operations by using new
techniques or equipment.
Computer Training, Present and Future
Education, training, and experience
A bachelor's or master's degree in business administration, with extensive course content in accounting and
mathematics or statistics often is required. Employers
frequently waive academic training requirements for
currently employed workers with extensive systems
analysis, design and followup responsibility in electronic data processing, and supervisory experience in
tabulating-machine departments. Employers frequently
require a degree or equivalent experience either in industrial engineering, or the engineering discipline most
directly related to their manufacturing processes, when
expanding business data processing to an integrated
system that includes production forecasting, planning,
and control.
Background knowledge and experience usually include a minimum of one to three years' experience in
systems analysis and concurrent familiarization with
structure, work flow requirements, and standards of the
employing organization.
Current trend is toward greater mathematical sophistication than previously expected of workers at this
level. The need for advanced mathematics becomes
more urgent as computer applications become involved
not only with normal business data-processing, but also
with the involved problems of operations research.
Special characteristics
Aptitudes:
Verbal ability to elicit information and discuss project intentions, problems and progress, and to prepare
reports.
Numerical ability to analyze problems and develop
systems statements in form capable of being programmed. Mathematics varies from arithmetic and
algebra for simple, single-purpose systems design to
differential equations and mathematical statistics for
complex systems involving optimization, simulation, or
forecasting.
Spatial ability to develop, interpret, or integrate
operational workflow diagrams and charts.
Clerical perception to recognize pertinent detail and
avoid perceptual errors when working with verbal
material, which often is in highly contracted and
conventionalized form.
89
gar ding the potentialities, limitations, and alternative
methods of data processing, supervise analysts and
coordinate their activities.
A preference for activities that are technical in nature
to read and keep informed of computer development
and) new or more refined systems and procedures
techniques.
Temperaments:
Ability to perform a variety of duties involving frequent change, ranging from direct involvement in
problem analysis to coordination of subsequent work
processes until each project is operational.
Must be able to direct and plan an entire area of
work activity, assigning subordinates on the basis of
knowledge of individual specializations and abilities,
and control activities through personal contact and
reports.
Must be able to deal with people jn nonsupervisory
situations requiring considerable tact, to secure cooperation from management and all personnel affected
by project.
Required to make decisions on a judgmental basis
when supervising others and developing approaches to
problems on basis of past experience. Evaluates fixed
cost, time, manpower allocation, and output specifications to judge efficiency of project development and
operation.
Required to make decjsions based on factual data, as
in planning proposed system around capabilities and
limitations of a specific computer system.
Physical Activities and Environment:
Work is sedentary, with occasional standing and
walking required.
Occasionally lifts and carries books, charts, diagrams,
and other records seldom exceeding 10 pounds.
Talking and hearing to discuss problems and progress.
N ear visual acuity to work with reports, charts, and
diagrams and other printed or written records.
Work is performed inside.
SYSTEMS ANALYST, BUSINESS DATA
PROCESSING-(012.168) , COMMERCIALSYSTEMS ANALYST AND DESIGNER;
DATA-METHODS ANALYST; SYSTEMS
AND PROCEDURES ANALYST, BUSINESS
DATA PROCESSING
Interests:
A preference for prestige-type activities, and for
business contact with others to participate in conferences with management, advise and inform others re-
Occupational definition
Analyzes business problems, such as development of
integrated production, inventory control and cost
90
Spring Joint Computer Conference, 1972
analysis, to refine its formulation and convert it to
programmable form for application to electronic data
processing system. Confers with PROJECT DIRECTOR, BUSINESS DATA PROCESSING and department heads of units involved to ascertain specific output requirements, such as types of breakouts, degree of
data summarization, and format for management reports. Confers with personnel of operating units to devise plans for obtaining and standardizing input data.
Studies current, or develops new systems and procedures to devise workflow sequence. Analyzes alternative means of deriving input data to select most feasible
and economical method. Develops process flow charts
or diagrams in outlined and then in detailed form for
programming, indicating external verification points,
such as audit trial printouts. May work as member of
team, applying specialized knowledge to one phase of
project development. May coordinate activities of team
members. May direct preparation of programs.
Education, training, and experience
College graduation with courses in business administration and accounting usually is required for entrants
without prior experience in data processing. Some
employers, while requiring a college degree, do not require a specific major or course content. A successful
college record is regarded as proof of ability to reason
logically which is considered more important for successful performance than knowledge of techniques acquired in any specific area. Many employers waive the
formal education requirements for those workers employed in their establishments who have had several
years' manual and machine systems experience prior to
computer conversion. Business programmers without a
college degree can, through experience, acquire a background in business systems and procedures and may
thereby advance into systems analysis. Currently, the
trend is to require a knowledge of advanced mathematics because ofthe rapidly increasing sophistication
of business systems. Continuing education, through
specialized courses, self-study, and participation in
activities of professional associations, is the rule rather
than the exception in this occupation, as in all higher
level occupations related to the computer.
Special characteristics
Aptitudes:
Verbal ability to discuss problems and progress, prepare reports, and make annotations for graphic representations of work.
Numerical ability to select from alternatives to de-
velop optimum system, procedures and methods.
Mathematical investigation of such factors as variation
in volume of input data, and frequency of appearance of
exceptions to normal \vorkflow in processing is often
necessary. Level of mathematics varied from business
arithmetic and algebra to differential equations.
Spatial ability to visualize, prepare, and review twodimensional graphic representations of \vorkflow.
Form perception to identify nonverbal symbols on
records such as block diagrams and flow charts.
Clerical perception to avoid perceptual errors and
recognize pertinent detail in the recording and identifying of letters and numbers that often occur in abbreviated or acronymic combinations.
Interests:
A preference for activities that are technical and
analytical, and those that are abstract and creative in
nature to devise new or to modify standardized computer-oriented systems to meet the specific needs of an
organization.
Temperaments:
Ability to confer with personnel from other departments, develop flow charts, devise workflow sequence,
and prepare reports.
Required to deal with people in conference and
interview situations.
Required to make judgmental decisions to select
from alternatives when devising optimal system.
Required to make decisions on basis of factual data
to design system within machine capability.
Physical Activities and Environment:
Work is sedentary, with occasional standing and
walking. Occasional handling of source documents,
books, charts, and other records that seldom exceed
10 pounds.
Talking and hearing to discuss and confer with management and technical personnel.
N ear visual acuity to prepare and review workflow
charts and diagrams.
Work is performed inside.
OPERATIONS RESEARCH ANALYST(020.088), MANAGEMENT-OPERATIONS
ANALYST; OPERATIONS ANALYST
Occupational definition
Formulates mathematical model of management
problems by application of advanced mathematics and
research methods to provide quantitative basis for
planning, forecasting, and making decisions. Analyzes
Computer Training, Present and Future
problems in terms of management information requirements. Studies problem, such as selecting from competitive proposals a plan that affords maximum probability of profit or effectiveness in relation to cost or
risk. Prepares mathematical model of problem area in
form of one or several equations that relate constants
and variables, restrictions, alternatives, conflicting objectives, and their numerical parameters. Gathers,
relates, and identifies data with variables in model by
applying personal judgment and mathematical tests.
Specifies manipulative and computational methods to
be applied to formulations and refers to data processing
division for solving equations, programming, and
processing. Reviews operations and testing of model to
ensure adequacy or determine need for reformulation.
Prepares written, nontechnical reports to management,
indicating problem solution or range of possible alternatives in rank of desirability and probability of success
when there is no single solution. Writes followup reports,
evaluating effectiveness of research implementation.
May specialize in research and preparation of contract
proposals specifying the competence of an organization
to perform research, development, or production work.
May develop and apply time and cost networks, such as
Program Evaluation and Review Technique (PERT),
to plan and control large-scale business projects. May
work in areas associated with engineering, as when
analyzing and evaluating alternative physical systems,
such as production processes, in terms of effectiveness
and cost. May work alone or as member of a team.
Education, training, and experience
College degree with emphasis on advanced mathematics and statistics is usually the minimum educationa] requirement. A combination of advanced degrees
in mathematics and business administration is especially
desirable. A doctorate in mathematics is frequently
required. Specific training in operations research at the
graduate level is rapidly becoming a standardized requirement, as more schools offer courses in this interdisciplinary occupational area. Many workers have acquired the necessary background in mathematics
through education and experience in engineering and
the physical sciences, and knowledge of specialized
techniques through self-study and participation in
activities of professional organizations.
Special characteristics
Aptitudes:
Verbal ability to understand techn1cal languages of
various professional disciplines such as engineering and
91
accounting, to give oral reports and to prepare written
reports on results of research in lay terminology to
management.
Numerical ability to understand and work with such
mathematical specializations as game, queuing, and
probability theory, and statistical inference to prepare
formulations, specify manipulative methods and evaluate effectiveness.
Spatial ability to prepare and interpret charts, diagrams, graphs, and maps.
Clerical perception to recognize pertinent detail in
compilation and analysis of statistical data, and to
avoid perceptual errors in working with higher forms of
mathematics.
Interests:
A preference for activities that are technical in nature
to apply analytical, experimental, and quantitative
techniques in the solution of management problems
such as long-range forecasting, planning, and control.
Interests in devising mathematical equations, analyzing the methods used for their manipulation, and evaluating their practical effectiveness.
Temperaments:
Requires ability to perform a variety of tasks related
to the solution of various problems on all departmental
levels. This involves conversing in several professional
disciplines with personnel at all operating levels to
gather and relate data and opinions relevant to problem under study.
Must possess ability to make judgmental decisions
such as probability of continuity or change in conditions, and assign arbitrary weights and values to problem factors when conventional statistical methods are
not applicable.
Must possess ability to make decisions based on
verifiable data, such as tabular records of previous organizational experience.
Physical Activities and Environment:
Work is sedentary, and occasionally involves lifting
and carrying books, ledgers, and statistical tabulations
seldom exceeding 10 pounds.
Talking and hearing to discuss organization goals and
priorities with management and acquire data pertinent
to the problem from other organizational personnel.
N ear visual acuity to read and work with a variety
of data from many sources, and to refer to texts and
technical papers.
Work is performed inside.
92
Spring Joint Computer Conference, 1972
CHIEF PROGRAMMER, BUSINESS-(020.168) ,
COORDINATOR, COMPUTER
PROGRAMMING; LEAD PROGRAMMER
Occupational definition
Plans, schedules, and directs preparation of programs
to process business data by electronic data processing
equipment. Consults with managerial and systems
analysis personnel to clarify program intent, indicate
problems, suggest changes and determine extent of
automatic programming and coding techniques to use.
Assigns, coordinates, and reviews work of programming
personnel. Develops own programs and routines from
workflow charts or diagrams. Consolidates segments of
program into complete sequence of terms and symbols.
Breaks down program and input data for successive
computer passes, depending on such factors as computer
storage capacity and speed, extent of peripheral equipment, and intended use of output data. Analyzes test
runs on computer to correct or direct correction of
coded program and input data. Revises or directs revision of existing programs to increase operating efficiency or adapt to new requirements. Compiles documentation of program development and subsequent
revisions. Trains subordinates in programming and
program coding. Prescribes standards of terminology
and symbology to simplify interpretation of programs.
Collaborates with computer manufacturers and other
users to develop new programming methods. Prepares
records and reports.
Education, training, and experience
Graduation from a technical school or college with
training in business administration, computer programming, data processing mathematics, logic, and
statistics is the usual educational requirement. Usually,
a minimum of two years' experience in programming
for same or similar computer system, on broadscope
and complex projects is required. Experience should
indicate knowledge of organization structure and workflow, and also reflect proven ability to supervise others
and coordinate work activities of the group supervised
with that of other organizational units.
Special characteristics
Aptitudes:
Verbal ability to present oral and written reports and
recommendations and to read technical literature about
changes in techniques and equipment.
Numerical ability to program at level of linear and
Boolean algebra (logic) to minimize expensive programming and debugging time. Mathematics at level of
differential equations and probability theory frequently
required when an organization is developing or using
sophisticated, integrated management information and
forecasting systems.
Spatial ability to interpret systems statement, develop general and detailed computer flow charts, and
prepare block diagrams that indicate hardware
configuration.
Form perception to see pertinent detail in charts,
diagrams, and code sheets composed of symbols.
Clerical perception to refer to manuals and written
instructions and to review own work. This requires
accurate identification of numbers, letters, words, and
acronyms as well as ability to grasp general content.
Interests:
A preference for activities that are technical in nature
to apply mathematics and logic in converting proposed
business systems to computer-processable form.
Temperaments:
Ability to perform a variety of duties, covering problems from different but related areas of business activity
such as production and inventory control, and sales
analysis.
Must be able to direct, control, and plan development
of business data processing programs that will meet
current and future needs. This involves direction of
activities, such as program testing and revising, and
coordination of all phases of business programming
activities to meet schedules.
Required to deal with subordinates for purposes of
control and coordination, and with systems analysis
and management personnel to resolve questions of intent and programming difficulties.
Required to make judgmental decisions based on experience to assign personnel and select and apply
techniques that will produce least cost, fastest, or most
flexible programs.
Required to make decisions based on factual data to
evaluate adequacy of completed program by comparing
program, test and operating· runs with prescribed
standards of terminology, and time.
Physical Activities and Environment:
Work is sedentary. Lifts and carries source and output data, books, charts, and diagrams seldom exceeding
10 pounds.
Computer Training, Present and Future
Stands, walks, talks, and hears in instructiDnal and
conference situations.
N ear visual acuity to prepare, integrate, or modify
complex programs, using a variety of charts, diagrams,
and handbooks.
Work is performed inside.
PROGRAMMER, ENGINEERING AND
SCIENTIFIC-(020.188), PROGRAMMER,
TECHNICAL
Occupational definition
Converts scientific, engineering, and other technical
problem formulations to format processable by computer. Resolves symbolic formulations, prepares logical
flow charts and block diagrams, and encodes resolvent
equations for processing by applying knowledge of advanced mathematics, such as differential equations
and numerical analysis, and understanding of computer
capabilities and limitations. Confers with engineering
and other technical personnel to resolve problems of
intent, inaccuracy, or feasibility of computer processing.
Observes or operates computer during testing or processing runs to analyze and correct programming and
coding errors. Reviews results of computer runs with
interested technical personnel to determine necessity
for modifications and rerun. Develops new subroutines
for a specific area of application, or expands on applicability of current general programs, such as FORTRAN,
to simplify statement, programming, or coding of
future problems. May supervise other programming
personnel. May specialize in single area of application,
such as numerical control, to develop processors that
permit programming for contour-controlled machine
tools in source-oriented language.
Education, training, and experience
College degree with major in mathematics or engineering is usually the minimum educational requirement. A master's degree or doctorate in mathematics or
engineering is a common requirement where analysis or
programming is extremely complex or where work
duties involve basic research in mathematics or programming. From two to four years of on-the-job training, with gradually decreasing amounts of supervision
and with increasingly complex work assignments, are
regarded as necessary for the worker to become familiar
with at least one class of computer, programming language, and applications area. Short (one to four weeks)
93
training sessions are given by employers and computer
manufacturers to provide basic training and (later)
specialized training. Current trends toward simplification of programming languages and greater applicability
of generalized programs, and requirement of basic
computer orientation and programming courses for
college degree in physical sciences or engineering will
reduce on-the-job training time.
Special characteristics
Aptitudes:
Verbal ability to discuss problems and equipment
requirements with other technical personnel, to prepare
computer flow charts, written records, reports, and
recommendations and to read technical publications.
Numerical ability to interpret mathematical formulation, to select from alternative computational methods, to frame program within limitations of the computer to be used, prepare logical flow charts and diagrams, to convert program steps to coded computer
instructions, and to review work. Level of mathematics
may vary from arithmetic and algebra to advanced
differential equations in the course of writing a single
program, and may also include applications of numerical
analysis.
Spatial ability to prepare logical flow charts specifying sequences of operating instructions and flow of data
through computer system, to design input and output
forms, and to interpret detailed drawings, diagrams,
and other graphic data.
Form perception to see pertinent detail in charts,
diagrams, and drawings, and distinguish symbols in
subject matter areas such as physics and electrical
engineering.
Clerical perception to avoid perceptual errors in recording of alphanumeric and special symbologies.
Motor coordination to operate calculator or
computer.
Interests:
A preference for activities technical in nature to use
mathematics to reduce formulations to computerprocessable form.
Temperaments:
Required to make decisions on a judgmental basis,
using past experience and knowledge to select best
method of programming and coding a problem and
thereby avoiding costly, time-consuming analyses of
alternate techniques.
Required to make factual decisions, such as evalua-
94
Spring Joint Computer Conference, 1972
tion of program accuracy by computer acceptance,
presence of error messages or obvious output distortions.
Must be able to conform to accepted standards and
techniques in developing and testing programs, and in
writing instructions for digital-computer operator.
Physical Activities and Environment:
Work is sedentary, requiring occasional lifting and
carrying of source data, books, charts and diagrams
seldom exceeding 10 pounds.
Talking and hearing to confer and collaborate with
other technical personnel.
N ear visual acuity to prepare logical flow charts
from lengthy mathematical statements of problem, and
to convert program steps to coded computer
instructions.
Work is performed inside.
PROGRAMMER, BUSINESS-(020.188) ,
DIGITAL-COMPUTER PROGRAMMER
Occupational definition
Converts symbolic statement of business problems to
detailed logical flow charts for coding into computer
language. Analyzes all or part of workflow chart or
diagram representing business problem by applying
knowledge of computer capabilities, subject matter,
algebra, and symbolic logic to develop sequence of program steps. Confers with supervisor and representatives
of departments concerned with program, to resolve
questions of program intent, output requirements, input
data acquisition, extent of automatic programming and
coding use and modification, and inclusion of internal
checks and controls. Writes detailed, logical flow chart
in symbolic form to represent work order of data to be
processed by the computer system, and describe input,
output, arithmetic, and logical operations involved.
Converts detailed, logical flow chart to language processable by computer (PROGRAMMER, DETAIL).
Devises sample input data to provide test of program
adequacy. Prepares block diagrams to specify equipment configuration. Observes or operates computer to
test coded program, using actual or sample input data.
Corrects program error by such methods as altering
program steps and sequence. Prepares written instructions (run book) to guide operating personnel during
production runs. Analyzes} reviews, and rewrites programs to increase operating efficiency or adapt to new
requirements. Compiles documentation of program development and subsequent revisions.· May specialize in
writing programs for one make and type of computer.
Education, training, and experience
Minimum requirements are high school graduation
with six months to two years of technical training in
computer operations and in general principks of programming and coding, or equivalent job experience in
these areas. Current trend is to hire college graduates
for promotional potential with training in accounting,
business administration, and mathematics, and provide
them with a year of on-the-job training to qualify
them for programming. In installations concerned with
the application of the computer to more complex areas
such as market research and statistical forecasting, a
college degree in mathematics is preferred.
Special characteristics
Aptitudes:
Must possess verbal ability to understand and analyze oral or written statements concerning a variety of
business problems and to discuss them with others.
Must possess numerical ability to interpret workflow
charts, program problems, and understand machine
logic. Level of mathematics varies from arithmetic and
algebra for simple business data processing problems to
differential equations and mathematical statistics for
involved problems such as forecasting or optimization.
Must possess spatial ability to interpret diagrammatic representations of workflow, and to visualize flow
of data through computer system to prepare computer
block diagrams and logical flow charts.
Must possess form perception to see pertinent detail
in symbols when reading, interpreting, or preparing
charts, diagrams, and code sheets.
Clerical perception to detect errors in letters, words,
and numbers recorded on charts, diagrams, and code
sheets.
Interests:
An interest in activities technical in nature to effectively analyze problems, and to design logical flmv
charts and block diagrams.
An interest in activities that are carried out in relation
to processes, techniques, and machines to plan sequence
steps, to prepare instructions, and to test programs.
Temperaments:
Required to make judgmental decisions to plan
logical sequence of steps and prepare logical flow chart
for a project, keeping in mind capacities and limitations
of computer and integrated machine units.
Must be able to conform to accepted standards and
Computer Training, Present and Future
techniques in developing and testing programs, and
writing instructions for computer operators to follow.
Physical Activities and Environment:
Work is sedentary, requiring occasional lifting and
carrying of such items as source materials, run books,
and documentations seldom exceeding 10 pounds.
Talking and hearing to communicate with systems,
program coding, and operating personnel.
N ear visual acuity and accommodation required to
review statistical data and interpret charts and
diagrams.
Work is performed inside.
PROGRAMMER, DETAIL-(219.388),
JUNIOR PROGRAMMER; PROGRAM
CODER
95
Special characteristics
Aptitudes:
Verbal ability to recognize programming and coding
language consisting of abbreviated words, grouping of
numbers, symbols, or mnemonics.
Numerical ability to convert decimal numbers to
binary or other number systems.
Form perception to recognize and remember graphic
symbols (arrangement of lines and curves).
Clerical perception to select from handbooks codes
acceptable to computer, which involves accurate identification and recording of numbers, letters, and words.
Interests:
A preference for activities of a routine, concrete and
organized manner to code programs, using standardized
codes.
Occupational definition
Selects symbols from coding system peculiar to make
or model of digital computer and applies them to successive steps of completed program for conversion to
machine-processable instructions. Reads and interprets
sequence of alphabetic, numeric, or special characters
from handbook or memory for each program step to
translate it into machine language or pseudo (symbolic)
code that can be converted by computer processor into
machine instructions. Records symbols on worksheet
for transfer to punchcards or machine input tape.
Marks code sheet to indicate relationship of code to
program steps to simplify debugging of program. Confers with programming personnel to clarify intent
of program steps. Usually works as understudy to
PROGRAMMER, BUSINESS performing such additional tasks as converting flow charts and diagrams of
simple problems from rough to finished form, or making
minor changes in established programs to adapt them
to new requirements.
Temperaments:
Ability to perform repetitive tasks according to set
procedures, to refer to source books for symbologies and
select appropriate codes for each detailed step in program. Steps may number into the thousands.
Required to work to precise and established standards
of accuracy in recognition of steps of detailed program
and in selecting and recording codes. Any mistake can
introduce error into programs and either prevent
processing or distort output of program when processed.
Physical Activities and Environment:
Work is sedentary. Work sheets and code books seldome exceed five pounds.
Continuously handles pencils, work sheets, and code
books while interpreting program steps, finding representative coding, and posting codes to work sheets.
N ear visual acuity to select correct alphabetical,
numerical, or special symbols to convert detailed program to machine-processable form.
Work is performed inside.
Education, training, and experience
Must be high school graduate. Some training in programming, coding, and computer operations at technical school level is desirable. Experience in computer
operations is preferred, but six months of job experience,
most often in a clerical capacity, to become familiar
with company operations, workflow, standards, and
terminology is the minimum requirement. One to four
weeks classroom training in coding for specific computer is usually provided by employer or computer
manufacturer. Some employers favor college graduates
in order to enhance the worker's promotion potential.
SUPERVISOR, COMPUTER OPERATIONS(213.138), CHIEF CONSOLE OPERATOR;
SENIOR CONSOLE OPERATOR;
SUPERVISOR, DATA PROCESSING;
SUPERVISOR, ELECTRONIC DATA
PROCESSING
Occupational definition
Supervises and coordinates activities of workers who
operate electronic data processing machines. Assigns
96
Spring Joint Computer Conference, 1972
personnel and schedules workflow to facilitate production. Directs training or trains personnel in operation of
computers and peripheral and off-line auxiliary equipment. Works with programming personnel in testing
new and revised programs. Develops operating methods
to process data, such as devising wiring diagrams for
peripheral equipment control panels, and making minor
changes in canned (standardized) programs or routines
to modify output content or format. Directs insertion
of program instructions and input data into computer,
and observes operations. Aids operators in locating and
overcoming error conditions. Makes minor program
and input data revisions through computer console to
maintain operations. Notifies programming and maintenance personnel if unable to locate and correct cause
of error or failure. Revises operating schedule to adjust
for delays. Prepares or reviews records and reports of
production, operating, and down-time. Recommends
changes in programs, routines, and quality control
standards. Consults with MANAGER, ELECTRONIC
DATA PROCESSING about problems, such as including new program testing and operating runs in
schedule and arranging for preventive maintenance
time. Coordinates flow of work between shifts to assure
continuity. May supervise personnel engaged in keypunching, data typing, and tabulating.
Education, training, and experience
High school graduation is the minimum requirement.
Usually a minimum of one to three years' experience in
operating computers, peripheral, and off-line equipment
is required. A familiarization with programming and
coding techniques usually gained through experience in
computer operation or a course in programming are
additional prerequisites. However, a two-year post-high
school training course in electronic data processing
may reduce experience requirements. Training in business administration, mathematics, and accounting is
regarded as particularly desirable. Some employers require a college degree, particularly in large installations
where work duties are largely administrative, and also
in order to enhance the worker's promotion potential.
Experience in supervising personnel is desirable.
Special characteristics
Numerical ability to level of arithmetic and algebra
to cope with error or stoppage situations in computer
operations; to plan operating changes; and to prepare
variety of reports, often on a daily basis such as revision
of average time requirements for processing data or cost
allocations to departmental users.
Spatial and form perception to prepare wiring diagrams, wire control panels for peripheral machines, and
operate equipment.
Clerical perception to review records of production,
operating and down-time, and recognize pertinent detail
in computer printout dumps.
Interests:
A preference for business contact with others to confer with management, technical personnel, suppliers of
input data, and users of computer output, and to supervise and train subordinates.
A preference for activities that are technical in nature
to keep informed of new techniques for operation of
current machines.
Temperaments:
Ability to perform a variety of tasks subject to frequent change, such as training and assigning personnel,
accommodating changes in production schedules to
meet priority runs, maintaining records, and developing new operating procedures.
Must be able to direct, control, and plan the activities
of computer operators, satellite input-output computer
operators, on-line and off-line peripheral equipment
operators, and tape librarians.
Required to deal with people such as other departmental supervisors to resolve problems concerned with
the scheduling, adequacy, and accuracy of input data.
Required to make decisions on a judgmental basis to
set up work assignments that make maximum use of
workers' knowledge and ability, and most effective and
economical use of computers and peripheral equipment.
Required to make decisions on a factual basis when
developing schedules for processing programs, relating
such factors as date of program receipt, priorityassignment, estimated run time, and available computer time.
Compares output requirements against available equipment, and existing programs, routines, wiring diagrams,
and control panels to determine need for developing or
modifying operational methods, or altering operating
schedule.
Aptitudes:
Verbal ability to train and supervise subordinates,
confer with other supervisory and technical personnel,
and prepare records and oral or written reports.
Physical Activities and Environment:
Work is light, requiring frequent standing and walking and occasional lifting and handling of reels of tape,
Computer Training, Present and Future
decks of punchcards, and control panels weighing up to
20 pounds.
Talking and hearing to give oral instructions, assign
work, and train personnel. Confers with management
and others, discussing such items as budget requirements and staffing, machine capability, and production
problems.
N ear visual acuity to frequently analyze records, prepare reports, study program run books, and read
technical literature.
Work is performed inside.
COMPUTER OPERATOR-(213.382),
COMPUTER OPERATOR; CONSOLE
OPERATOR
Occupational definition
Monitors and controls electronic digital computer to
process business, scientific, engineering, or other data,
according to operating instructions. Sets control
switches on computer and peripheral equipment, such
as external memory, data communicating, synchronizing, input, and output recording or display devices, to
integrate and operate equipment according to program,
routines, subroutines, and data requirements specified
in written operating instructions. Selects and loads input and output units with materials, such as tapes or
punchcards and printout forms, for operating runs, or
oversees operators of peripheral equipment who perform these functions. Moves switches to clear system
and start operation of equipment. Observes machines
and control panel on computer console for error lights,
verification printouts and error messages, and machine
stoppage or faulty output. Types alternate commands
into computer console, according to predetermined instructions, to correct error or failure and resume operations. Notifies supervisor of errors or equipment stoppage. Clears unit at end of operating run and reviews
schedule to determine next assignment. Records operating and down-time. Wires control panels of peripheral
equipment. May control computer to provide input or
output service for another computer under instructions
from operator of that unit.
Education, training, and experience
A high school education meets the minimum educational requirements of some employers, but an increasing number of employers are demanding an additional
97
several months to two years of technical school training
in data processing. This training usually includes such
courses as data processing mathematics, accounting,
business practices, elementary programming, and operation of computers, peripheral equipment, and tabulating machines.
The employer or computer manufacturer usually
provides one to three weeks of formal instruction for
the specific computer system the worker will operate.
Length of subsequent on-the-job training and experience required to achieve adequate performance ranges
from a few months to one year because computer systems and equipment vary in complexity and need for
operator intervention. Except in small units, a minimum of three to six months prior experience in operation of peripheral equipment frequently is required.
Special characteristics
Aptitudes:
Verbal ability to comprehend technical language of
operating instructions and equipment manuals and to
explain clearly any operating problems and difficulties
in interpreting program intent.
Numerical ability at level of arithmetic to prepare
operating records, time computer runs, and adhere to
fixed operating schedule. While not always an operator
requirement, an understanding of data processing
mathematics (the number systems used, algebra and
logic) is almost essential to discuss operating difficulties
with programming personnel, and to progress from
routine production runs to the testing of new programs.
Spatial perception to wire control panels for peripheral equipment.
Form perception to identify flaws in input and output
materials.
Clerical perception to avoid perceptual errors in preparing operating records, and to recognize alphabetic,
numeric, and mnemonic symbols.
Motor coordination, to rapidly set up machines and
to move keys and switches to quickJy correct errors or
stoppages.
Interests:
A preference for working with machines and processes
to continuously operate and monitor the equipment
that comprises the computer system.
Interest in activities of concrete and organized
nature to operate machines according to specific and
detailed instructions.
98
Spring Joint Computer Conference, 1972
Temperaments:
Work situation requires ability to perform a variety
of work tasks subject to frequent change in the simultaneous operation of a console and a variety of peripheral equipment, the integration of which varies from
program to program, or even during a single operating
run, and which demands rapid transfer of attention
from one piece of equipment to another.
Accuracy required to operate system effectively and
minimize down-time and rescheduling of runs. Carelessness in following written and oral instructions can
cause extensive rebuilding of program or input data, or
even lead to irrecoverable loss of data.
Physical Activities and Environment:
Work is light. Lifts, carries, and positions tape reels,
punchcard decks, output forms, and control panels seldom exceeding 20 pounds.
Stands and walks frequently when loading and
monitoring machines.
Reaches for and fingers switches and keys on console
and peripheral machines. Wires control panels, loads
and removes input and output materials.
Talking and hearing to frequently exchange information concerning program and system requirements with
other workers and to receive or give instructions.
N ear visual acuity and .accommodation to follow
detailed operating log, monitor computer and peripheral
machines for signs of malfunction, and analyze console
messages or high-speed printer output for cause of
error or stoppage.
Color vision to distinguish between colored wires
when wiring control panels, to identify color-coded
cards or forms and to monitor colored display lights if
used.
Work is performed inside.
COMPUTER-PERIPHERAL-EQUIPMENT
OPERATOR-(213.382), ASSISTANT
CONSOLE OPERATOR; TAPE HANDLER
Occupational definition
Operates on-line or off-line peripheral machines,
according to instructions, to transfer data from one
form to another, print output, and read data into and
out of digital computer. Mounts and positions materials, such as reels of magnetic or paper tape onto
spindles, decks of cards in hoppers, bank checks in
magnetic ink reader-sorter, notices in optical scanner,
or output forms and carriage tape in printing devices.
Sets guides, keys, and switches according to oral instructions or run book to prepare equipment for operation. Selects specified wired control panels or wires
panels according to diagrams and inserts them into
machines. Presses switches to start off-line machines,
such as card-tape converters, or to interconnect on-line
equipment, such as tape or card computer input and
output devices, and high-speed printer or other output
recorder. Observes materials for creases, tears, or
printing defects and watches machines and error lights
to detect machine malfunction. Removes faulty materials and notifies supervisor of machine stoppage or
error. Unloads and labels card or tape input and output
and places them in storage or routes them to library.
Separates and sorts printed output forms, using decollator, to prepare them for distribution. May operate
tabulating machines, such as sorters and collators.
Education, training, and experience
High school graduate. Post-high school training in
operation of electronic or electromechanical data
processing equipment is desirable. Employers frequently
regard worker as understudy to computer operators
and apply same education and aptitude standards to
them.
Special characteristics
Aptitudes:
Verbal ability to read written instructions and handbooks and to communicate with supervisor about
operating functions.
Spatial ability to follow diagrams to wire control
panels, position and thread tapes onto spindles or position decks of cards1.n hoppers.
Clerical perception to identify and record, without
error, data such as dates, program numbers, departments, and routings on forms.
Motor coordination and finger and manual dexterity
to load and unload machines quickly and minimize
down-time, to thread ribbons of tape over guides and
through rollers, and to handle cards and tapes deftly
without bending, tearing, or otherwise damaging them.
Interests:
An interest in activities concerned with machines,
processes, and techniques to operate various machines.
Preference for activities of a routine and organized
nature to follow well-defined instructions for any of
several different machines.
Computer Training, Present and Future
Temperaments:
Worker must be adept at performing a variety of
tasks requiring frequent change to operate a number of
machines in varying combinations and sequences.
When operating peripheral equipment, must adhere
to established standards for accuracy, such as observing printer output forms for defects in alinement,
spacing, margin, and overprinting. Immediate response
to indication of error in operation of peripheral equipment is vital.
Physical Activities and Environment:
Work is light, involving frequent standing and walking when operating machines and lifting and carrying
tapes, cards, and forms not exceeding 20 pounds.
Reaches, handles, and fingers to mount tapes onto
spindles, position decks of cards in hoppers, and thread
tape through guides and rollers of peripheral units or
wire control panels.
N ear visual acuity to read labels on reels, to wire
plug boards from diagrams, to scan printout for error,
and to read operating instructions and handbooks.
Color vision to distinguish between various colors of
wires to ensure correct wiring of control panels.
Work is performed inside.
CODING CLERK-(219.388)
Occupational definition
Converts routine items of information obtained from
records and reports into codes for processing by datatyping or key-punch units, using predetermined coding
systems. Manually records alphabetic, alphanumeric,
or numeric codes in prescribed sequence on worksheet
or margin of source document for transfer to punchcards or machine input tape. May be designated according to trade name of computer system as CODING
CLERK, UNIVAC; IBM CODER.
Education, training, and experience
High school graduation usually is required. Training
of a day or two in a classroom situation or under the
direction of an experienced worker usually is provided
by the employer. Achievement of adequate speed, and
particularly the development of a high degree of accuracy, takes from one to three months. Achievement
of speed involves memorization of many of the codes.
Familiarization with standard business terminology and
abbreviations, and with special conventions used by
the employer can reduce the time necessary to achieve
adequate performance.
99
Special characteristics
Aptitudes:
Verbal ability to understand written and oral instructions, business terms, abbreviations, and mnemonic
contractions, and to explain difficulties to supervisor.
Clerical perception to scan and extract pertinent detail from source documents, and to avoid and detect
perceptual errors.
Interests:
A preference for activities of a routine, concrete,
organized nature to code according to a predetermined,
standardized system.
Temperaments:
Work activities are repetitive and short cycle in
nature. Converts each item into the equivalent code in
the allowable time cycle of a few seconds.
Must follow specific instructions to convert items to
their coded equivalents which are indexed in tables or
handbooks.
Physical Activities and Environment:
Work is sedentary. Reaches for, lifts, and handles
handbooks, papers, and forms seldom exceeding five
pounds.
N ear visual acuity to read and convert items to
codes.
Work is performed inside.
TAPE LIBRARIAN-(223.387)
Occupational definition
Classifies, catalogs, and maintains library of magnetic
or punched paper tape or decks of magnetic cards or
punchcards used for electronic data processing purposes. Classifies and catalogs material according to content purpose of program, routine or subroutine, and
date on which generated. Assigns code conforming with
standardized system. Prepares index cards for file
reference. Stores materials and records according to
classification and catalog number. Issues materials and
maintains charge-out records. Inspects returned tapes
or cards and notifies supervisor if worn or damaged.
May maintain files of program developmental records
and operating instructions (run books). May operate
key-punch to replace defective punchcards and produce
data cards to identify punchcard decks. May work in
computer room performing such tasks as loading and
removing printout forms, reels of tape, and decks of
cards from machines.
100
Spring Joint Computer Conference, 1972
Education, training, and experience
High school graduate, preferably with commercial
background. Three to six months experience as catalog
clerk, file clerk, mail clerk, or messenger with the company is desirable.
Special characteristics
Aptitudes:
Verbal ability to read information on labels describing contents of decks of cards and reels of tape and read
catalogs that contain standardized codes and
ab breviations.
Numerical ability to count, add, and subtract numbers to perform inventory functions.
Clerical perception to note pertinent detail on labels,
cards, or work schedules, and in code books to detect
error and avoid misinterpretation.
to machine and previously punched program card
around machine drum to control duplication and spacing of constant data. Loads machine with decks of
punchcards. Moves switches and depresses keys to
select automatic or manual duplication and spacing,
selects alphabetic or numeric punching, and transfers
cards through machine stations. Depresses keys to
transcribe new data in prescribed sequence from source
material into perforations on card. Inserts previously
punched card into card gage to verify registration of
punches. Observes machine to detect faulty feeding,
positioning, ejecting, duplicating, skipping, punching,
or other mechanical malfunctions and notifies supervisor. Removes jammed cards, using prying knife. May
tend machines that automatically sort, merge, or
match punchcards into specified groups. May keypunch numerical data only and be designated KEYPUNCH OPERATOR, NUMERIC.
Education, training, and experience
Interests:
A preference for working with things and objects,
following routine and organized patterns to classify,
catalog, store, and fill requests for cards and tapes.
Temperaments:
Follows specific instructions and established procedures to receive, store, issue, and purge materials.
Physical Activities and Environment:
Work is light, involving frequent standing and walking to carry reels of tapes or trays and drawers of cards
weighing less than 20 pounds between desk, handtruck,
file cabinets, and racks.
Reaches for and handles tapes and cards to store
them.
N ear visual acuity to read and assign identification
symbols and inspect materials for damage.
Work is performed inside.
KEY-PUNCH OPERATOR-(213.582),
CARD-PUNCH OPERATOR; PRINTINGCARD-PUNCH OPERATOR;
PRINTING-PUNCH OPERATOR
High school graduate preferred with demonstrated
proficiency in typing on standard or electric typewriter.
High school or business school training in key-punch
operation is desirable. Frequently, one week of training
is provided by employer or manufacturer of equipment.
Special. characteristics
Aptitudes:
Verbal ability to understand oral and written instructions, such as manufacturers' operating manuals,
and to Jearn operation of machine.
Clerical perception to perceive pertinent detail in
tabular material consisting of combinations of letters
and numbers, and avoid perceptual error in transferring
this data to punchcards.
Motor coordination to read work sheets and simultaneously operate keyboard of approximately 40 keys
to punch data on cards.
Finger dexterity to move switches on machine.
Interests:
Preference for organized and routine activities to
transfer data onto punchcards.
Occupational definition
Operates alphabetic and numeric key-punch machine, similar in operation to electric typewriter, to
transcribe data from source material onto punchcards
and to reproduce prepunched data. Attaches skip bar
Temperaments:
Must be able to perform repetitive duties of operating key-punch machine.
Ability to follow specific instructions and set procedures to transfer data onto punchcards.
Computer Training, Present and Future
Required to work to precise and established standards
of accuracy to key-punch data at high rate of speed.
Physical Activities and Environment:
Work is sedentary with infrequent lifting of decks of
cards when loading machine.
101
Reaches for and handles code sheets, business records,
and decks of cards; fingers switches and keys to operate
machine.
N ear visual acuity to read copy when key-punching.
Work is performed inside.
The future of minicomputer programming
by D. J. WAKS and A. B. KRONENBERG
A pplied Data Research, Inc.
Princeton, New Jersey
by typically providing little general-purpose software*
with their minis. Although manufacturers have recently attempted to provide reasonable program-creation software, the majority of available assemblers still
lack such de8irable features as macros, conditional
assembly, literals, and multiple location counters.
Program-execution software for most small computers is
often so weak that the user usually is left to write his
own disk handler, communications package, or real-time
executive. Even in cases where a manufacturer does
provide such software, it usually requires a configuration
that is uneconomically large.
The manufacturers' software planners seem to
exhibit the minicomputer syndrome more than many
of their customers. They continue to design separate,
single-application monitors apparently assuming that
the user will employ his mini only for real-time applications, file processing, communications, or report writing.
Thus, the user who wants a single monitor system to
support some combination or all of these must either
adapt a manufacturer-supplied monitor or build one
from scratch.
This lack of coherent manufacturer software support
has also been characterized by a lack of standardization
and conventions or standardization of poor or unworkable conventions in the software. This in turn has led
to a proliferation of software to dismay any ecologist.
For example, how many different assemblers now exist
for the DEC PDP-8 family? We were able to count a
baker's dozen in two minutes of trying; there must be
an equal number we didn't think of or don't know about.
Finally, this lack of standards and conventions has
resulted in incompatibility from one user to another.
Software modules created for one user's executive and
assembler can be neither assembled nor run at another
user's site. We have been involved in more than one
"Here is Edward Bear, coming downstairs now,
bump, bump, bump, on the back of his head,
behind Christopher Robin. It is, as far as he
knows, the only way of coming downstairs, but
sometimes he feels that there really is another
way, if only he could stop bumping for a moment
and think of it. And then he feels that perhaps
there isn't."
Beginning of Winnie-the-Pooh, A. A. Milne
INTRODUCTION
The minicomputer syndrome
The programming of minicomputers to date has
resembled Pooh Bear coming downstairs because
although we feel that there really is another way, we
rarely stop bumping. Programmers for small computers
have long exhibited what we call "the minicomputer
syndrome", which is a very low expectation of program
support and facilities on a minicomputer and a lack of
appreciation of the hardware and software tools one can
employ to attack and solve a programming problem.
l\iinicomputers came on the market when it was first
realized that small general-purpose stored-program
computers could be competitive with complex hardwired systems built from general-purpose logic modules.
Not at all surprisingly, the manufacturers of logic
m?~ules quickly became the leading developers of
mmIComputers. Since the programming process was
viewed as an unfortunately necessary step in making
the mini behave like the hard-wired system it was
replacing, very little general-purpose programming
support was provided with the minis. Thus the
. .
'
mmIComputer syndrome-the belief that primitive
computers require primitive programming support-was
born virtually at the same time as the mini itself.
Computer manufacturers have fostered this syndrome
* General-purpose
software can be classified as either programcreation software (text/file editors, language processors), or
program-execution software (monitors, device drivers, real-time
executives).
103
104
Spring Joint Computer Conference, 1972
project requiring that a program be manually transliterated from one dialect for a computer to another.
What is a minicomputer?
The paper is intended to describe programming for
minicomputers. What do we mean by "minicomputer"?
Let us begin by characterizing the small computer as
having:
(a) A short word and register length, always 18 bits
or less; a small computer, therefore cannot
perform single-precision floating-point arithmetic
through either the hardware or software.
(b) A main memory provided in modules of 8K words
or less (typically 4K words).
(c) An instruction set and, commonly, its addressing
mode which are restricted, usually having a
rather short operation code field in its machinelanguage structure.
One more characteristic is required to define what we
mean by a mini: if a machine passes the test for a small
computer, and you can't ordinarily buy it without an
ASR Teletype ®, it is a mini. If you can't ordinarily buy
it without a card reader, it isn't a mini, it's just a small
computer.
The virtual machine and the extensible machine
Let us digress for a moment and define some useful
concepts we will refer to throughout the remainder of
this paper. The concept of the "extended machine" was
first propounded by Holt and Turanski;1 we will use the
term "virtual machine" interchangeably with extended
machine. Here we are using the term "virtual" in its
dictionary2 sense: "Virtual, apparent, as contrasted
with actual or absolute." That is, the virtual or
extended machine is what the computer user, on some
level, sees and uses. Another way of saying this is to
describe it as the set of primitives with which he must
work. Watson 3 defines a "virtual processor" in a
timesharing system in a similar way. The "virtual
memory" concept in paged computers is a similar
derivation.
As it is, the computer user rarely sees or uses the
"actual or absolute" machine. To do so, he would have
to write all his code in machine language. Language
processors, executive systems, device drivers, et al., are
all extensions to the machine which substantially affect
®
Teletype, a registered trademark of the Teletype Corporation.
the user's view of the machine. For instance, a mInIcomputer with a disk operating system appears to be a
very different machine from one with only paper-tapeoriented software. A mini with a manufacturer-provided
real-time executive appears to be a very different
machine from one without it to the user with a data
acquisition and reduction problem. In this sense, then,
all available software and hardware options act as real
extensions to the "actual" machine.
When certain types of extensions are preplanned into
the computer hardware and software design, the
resultant machine is considered "extensible"-to the
extent that such extensions are planned. We characterize
these extensions as being expansions of primitives on
three distinct levels: the hardware or "firmware" level;
the system software level; and the applications software
level. On each level, the user can implement new
extensions, typically visible at the next higher level
(further away from the hardware) although sometimes
available at the same level.
The first and lowest level of extensibility is at the
hardware or firmware level. By hardware extensibility,
we mean the ability to add new operation codes,
typically for I/O but also for CPU purposes. Thus,
a supervisor call facility was added to a PDP-8 four
years ago to provide for user-supervisor communication
in a real-time system for TV control room automation.
This form of extensibility is designed-in, and encouraged, although only rarely used to augment CPU
primitives. By firmware extensibility, we mean extensions through modifications or additions to microcode
on those computers (such as all machines in the Interdata family) which have a two-level (micro and user)
programming structure. 6 This ability to modify or
augment the instruction repertoire of the machine is a
powerful way, albeit rarely exploited, to extend the
machine at the lowest level; the new primitives thus
created are fully comparable to the original instructions
of the actual machine.
The second level of extensibility is at the software level
through creation of system software. By system software,
we mean such obvious extensions as operating systems,
device drivers and interrupt handlers, and any programcreation software, especially language processors, which
can drastically change the primitives available to the
end user. Planned extensibility at this level implies such
hardware features as:
(a) A user mode/supervisor mode distinction, providing a trap of some kind against the execution
of .reserved instructions in user mode, and
providing some kind of "supervisor call" facility.
(b) An approach to I/O on the hardware level which
The Future of Minicomputer Programming
provides for substantial compatibility of the I/O
mechanisms from device to device, particularly
with respect to interrupts and status information.
(c) Some method for extended address mapping
which .provides for hardware protection and
relocation, thus relieving the mini user of his
worst problem-severe limitations on addressing.
The third and highest level of extensibility is on the
user software level. Planned extensibility provides the
end user with the capability of augmenting the apparent
set of primitives he uses in writing his programs. Such
long-used techniques as subroutines and macros both
constitute expansions of primitives, particularly when
used together, e.g., a macro used to generate a calling
sequence for a subroutine which performs some complex
function.
lVIany sophisticated programmers for minis, particularly those coming from a large-computer background,
habitually define large numbers of macros to provide
extended primitives comparable to those found in the
actual instruction set on large machines. In this way,
the experienced programmer of a minicomputer views
the problem of programming a mini as being no different
from that for a large computer, effectively countering
the purveyors of the "minicomputer syndrome" by
using the same techniques, approaches, and skills
developed for large computers. The manufacturer can
plan for extensibility on this level by providing the user
with macro features in the assembler and by providing
flexible hardware and software techniques for invoking
subroutines.
Let us close this introduction by noting that each
layer of extension, although providing a new set of
primitives to the next higher level, may also reduce the
original set of primitives available on that level. A set of
device drivers for I/O handling, once defined, usually
prevents the user from writing code to use a new I/O
device in a substantially different way from that
standardized by the drivers added as extensions; he also
loses, in the process, any capability of doing I/O
operations himself, since attempts to do so are trapped
by the hardware.
Additionally, a Basic system-editor, compiler, and
operating system combined-gives the Basic user a
different and more powerful set of primitives than he
has in assembly language, but deprives him of the
ability to perform operations in assembly language, even
though this might be far preferable for some aspects of a
given problem. Thus, the extended machine may look to
the user quite different from the original machine, with
some primitives added and others deleted, at the
extender's discretion.
105
The remainder of this paper is devoted to describing
many kinds of extensions which we see occurring now
and in the future. Since this paper is principally about
software, we will concentrate on extensions to the
second and third levels. However, we feel that current
hardware developments will encourage software-like
extensions at even the lowest level, and we will discuss
these implications also. Hopefully, viewing the minicomputer as more closely related to the large-scale
computer than the hard-wired controllers it was
originally designed to replace will lead to alleviating the
underlying symptoms of the minicomputer syndrome.
THE MINI AS A GENERAL-PURPOSE
COMPUTER
We will first discuss the minicomputer as it may be
viewed by the applications programmer in the future. To
do this, we will first examine a significant difference in
the evolution of larger computer software as opposed to
minicomputer software.
Both scales of computers developed from the same
base: machine-language programs loaded into memory
via manually produced media (cards or paper tape)
followed by console debugging with the user setting
switches and reading lights on the computer. In the
history of large computers, the first executive systems
were batch monitors, which were quite widely developed
by 1960. These batch monitors provided for submitting
"jobs" on decks of cards to the computer center where
they were eventually entered into the "job stream" and
run. All programming and debugging tools developed
for large computers during most of the 1960s were
oriented to batch operation; and today virtually all
operating systems for today's large computers are
optimized for batch processing. Nearly all commercial
programming, and most university programming, is
today done using batch monitors on computers including
the IBNI 360 and 370, the Univac 1108, and the CDC
6600 and 7600. Recently, a trend has started toward
providing some sort of support for interactive programming, debugging, and program execution. Except for
several large computers explicitly designed for interactive operation in time-shared applications (specifically the XDS 940 and the DECsystem-10, both
produced by companies previously known for minis),
the machines were originally designed for batch
operation and modified in both hardware and software
to support interactive operation. The IB::vr 360/67 is a
modification to the 360/65, the Honeywell (GE) 645 to
the 635, the Spectra 70/46 to the 70/45. These machines
seem to have been grudgingly provided by the manu-
106
Spring Joint Computer Conference, 1972
facturers to meet what they saw as a small, uneconomical, but prestigious market; none of them provide
nearly as good interactive operation as machines and
software designed to be interactive from the beginning.
In particular, a system like the DECsystem-l0 can
provide program interaction with the user on a
character-by-character basis through the user's teletypewriter; no machine based on a 2741-type terminal
can possibly do so, since the terminal and its supporting
computer-based interfaces are designed to operate
strictly on a half-duplex, line-at-a-time basis. But· the
trend would appear to be toward expanded interactive
and conversational uses of large computers, particularly
as management information systems make terminal
access to data bases desirable in real time.
l\1:inicomputer programming started in the same way
as the large computers. Paper tape was the primary I/O
medium, read in by an ASR-33 Teletype ®, with the
computer console used for all debugging. Since minicomputers cost so much less than large computers, there
was much less pressure to get away from consofe
debugging, particularly as it was recognized as being a
very cost-effective tool for a competent programmer.
When it became clear that it was possible to create
software tools to facilitate debugging, it was natural to
use the Teletype®, which was there anyway (recalling
our definition of a minicomputer), as the I/O device
around which to design the "monitor." The first
interactive programs for minicomputers, using the
"console teletypewriter" to provide interaction with the
user, were symbolic editors and debugging tools
(particularly DDT,7 a debugging system produced at
MIT for the PDP-I). Many other interactive systems
for minis are described in an earlier paper by one of the
authors.8 Interactive systems of all kinds are common
today on virtually all minicomputers. In addition to
symbolic editors and debugging ,systems, there are
full-scale Basic systems for one or several users on many
minis; several minis have Disk Operating Systems
designed for conversational control from the console
teletypewriter, single-user and multi-user interpretive
systems derived from JOSS ® running on one or more
terminals. etc.
N ow that minicomputer configurations often include
peripherals, such as mass storage on removable disk
packs, card readers, line printers, magnetic tapes,
formerly found only on large computers, we see a trend
toward the use of batch operating systems on minicomputers. Such systems, typically based on RPG
and/ or Fortran as higher-level languages, are closely
®
JOSS, a registered trademark of the RAND Corporation.
modeled after large-machine batch systems. The
resulting virtual machine thus looks almost, if not completely, like the virtual machines erected on larger-machine
bases. A user programming in Fortran or RPG, both
relatively standardized languages, cannot tell, when he
submits a deck and gets back his reports, whether it was
run on a large computer or on a mini (except, perhaps,
by the size of the bill!).
Thus, large computers and minis are becoming more
and more alike-at least from the point of view of the
applications programmer. The authors hope that the
significant advantages of interaction between the user
and the computer, so prominent in the development of
minicomputer software, will not be disregarded by the
mini manufacturers in their seemingly headlong rush to
"me-too" compatibility with larger computers and their
batch operating systems.
THE MINICOl\1:PUTER EXTENSION
SPECIALIST
Until now, the people who have played the largest
role in extending minicomputers have been the system
software designers and implementors and the hardware
engineers. We feel that the systems software designers
will have an increasing role as extension specialists in the
future by becoming knowledgeable in hardware
techniques.
Hardware/software extensibility
Already, the manufacturers of minis are providing
richer instruction sets and more designed-in extensibility in their newer computers. As an example, the
DEC PDP-II provides a rich instruction set, a novel
I/O structure, and virtually a complete elimination of
the addressing problem which once plagued most minis.
The Interdata System.s 70 and 80 provide substantial
encouragement for the user to employ microprogramming to extend the base machine, i.e., to produce
firmware. Almost all new minis provide modular
packaging, in which a hardware function, to add a new
primitive, can be easily wired on a single module and
plugged into the machine.
We see the continued growth of microprogrammed
processors, built around Read-Only Memories (ROM's),
as being in the vanguard of user-extensible machines.
The newest hardware facilities include Programmable
ROM's (PROM's) which can be written by the user on
his site; Erasable PROM's-·which can be manually
The Future of l\1:inicomputer Programming
erased after being written; and Writable RO~VI's (slow
write cycle compared to read, intended to be written
relatively infrequently), sometimes called "Read-:\Iostly
Memories" (or Rl\1:l\l's). All of these lead us to see a
trend toward making this form of extensibility available
by design, rather than by accident.
Thus, the extension specialist win be encouraged to
work on all levels of extensibility. He will be able to add
firmware in the form of lower level programming
(microprogramming) or as pre-wired primitives which
he can literally plug in as new functions (as on the
GRI-909 family). Writable ROM's promise additional
extensibility, even providing the systems programmer
with the ability to optimize the instruction set for each
application by loading a writable ROlVI from his system
initialization code. Thus, he might choose an instruction
set built around four-bit decimal numbers to run Cobol
or RPG programs, one featuring binary floating point oli
multiple-precision numbers for Fortran or Algol, one
with extensive byte manipulation for Snobol, and one
with primitive expression evaluation for PL/I.
Systems programmers will become more competent
at lower-level extension work, either by the firmware
being brought closer to the user in the form of writable
ROM's, or by the software designer being cross-trained
in hardware techniques. For many minicomputer
systems programmers, an oscilloscope is a familiar tool
in debugging complicated programs and systems. Every
sign indicates a growing encouragement for the systems
programmer to create his own desired environment
through extensibility. The DEC PDP-16 carries this to
its logical extreme by letting the user build his own
computer from a pre-determined set of modules using
software tools to aid the design and implementation
process.
Thus, we predict that the systems designer of the
future will increasingly be at home in both cultureshardware and software.
Programming automation systems
We also see a substantial growth and extension to
what we call "programming automation systems"techniques that provide the programmer with computer
aids in the programming process. 9 All programming
systems are designed to help the programmer through
the critical loop of program development, i.e., program
modification, language processing, debugging, and back
to modification. Thus, systems such as Basic and
JOSS ® provide for complete control over the critical
loop within the context of a single system with a single
language used to control all three functions. On
107
minicomputers, symbolic editors, language processors
and debugging aids are provided to "automate" these
three steps. For the systems programmer working on
logically complex and large programs, however, the
minicomputer does not really provide an optimum
environment. Unless it provides bulk storage and a line
printer, it is not well suited to editing and assembly.
Unless it has a console much better designed than most
mini consoles, it is also not particularly well suited to
debugging (and the newest consoles are even less useful
f or debugging). Thus, there seems to be a trend toward
the use of larger computers, particularly time-shared
systems, for supporting programming automation
systems designed to support smaller machines. A largemachine-based editor and assembler can do a lot to
facilitate the creation of programs, particularly since
the assembler does not have to be restricted in either the
features or the number of symbols which can be
accommodated. A good simulator, designed for debugging, can significantly improve the productivity of a
programmer by providing him with the necessary tools
to debug a program without the limitations of the
smaller machine. The authors have invested quite some
time over the last few years investigating this approach;10 several other organizations have also done so,
with some success. Several new computers, notably the
GRI-909 and the IB:\1 System 7, accentuate this trend;
they are only supported by larger host computers; the
actual machines are configured only to run programs,
not to create them.
For years, systems programmers for small machines
have felt, like Pooh Bear, that there must be a better
way than assembly language to write programs for
small machines. The so-called "implementation languages" have been in use for some time on larger
computers; languages such as AED,l1 BLISS,12 PL/I and
ESPOL13 have been used to create systems software,
including compilers and operating systems, for large
computers. We regard it as unlikely that implementation
languages will soon be operational on minicomputers,
due to their high initial cost and inefficiency of generated
code. (Only if substantial computer time is invested in
optimizing time and space will minis be able to support
such implementation languages.) We do feel that the
trend toward using larger computers to support minis
will continue, and that it will soon be possible for
systems programmers to use large-computer-based
implementation language processors and debugging
systems as accepted tools of the trade. Already a
compiler for the BLISS language, an implementation
language developed at Carnegie-:\lellon originally for
the DEC system-IO, has been produced to generate code
for the PDP-II on the DEC system-IO.
108
Spring Joint Computer Conference, 1972
THE MINI AS A BASE FOR DEDICATED
SYSTEMS
Over the past five years (which represents virtually
the entire history of the minicomputer in terms of
number installed), there has been a noticeable shift in
the hardware/software tradeoffs in pricing and using
minicomputers in dedicated system applications. Several
people have long maintained that the price of the
software for a dedicated system should, as a rule of
thumb, equal the price of the hardware. Although
apparently true four years ago, this cannot possibly be
true today. Hardware costs of minicomputer mainframes and memories have been decreasing exponentially at an apparent rate of about 25 percent a year,
while software costs have been slowly rising, at the rate
of inflation. Thus, if the hardware/software cost ratio
was around 1/1 four years ago, it is more like 1/2.5
today, and the gap is steadily widening.
All of the extensibility promised by recent hardware
developments, including the modular construction of
the new machines and the increasing use of ROM's,
should have an accelerating affect on the applications of
minis to dedicated systems, steadily reducing the cost
of the hardware required for a given task.
We see implementation languages beginning to
relieve the trend toward higher software costs and hope
they will continue to do so in the future. But we see
problems in the high cost of training existing programmers to use implementation languages, the lack of
acceptance by lower-level programmers, and general
questions arising as to whether such languages and
compilers really appropriately solve more difficult
problems (such as those that are space and/or time
critical) .
We predict that in the next few years the current
problems regarding implementation languages will be
vigorously attacked on several fronts, and we feel
reasonably certain that they will be increasingly used in
dedicated systems, particularly those which are neither
space nor time critical. For critical systems, we feel that
some time will be required before compilers for implementation languages, and indeed the languages themselves, are improved and tested to the point that they
can be of real value.
Several people, including one of the authors, have
used interpretive languages to simplify the construction
of dedicated systems. In this technique, an existing
interpreter, for a language such as ESp4 or FOCAL,15 is
modified so as to minimize the core requirements for the
interpreter by removing unwanted features and adding
additional ones. The resulting extended machine is thus
an ESI machine, or a FOCAL machine; the user
program in the higher level language is stored in
memory and executed completely interpretively. John
C. Alderman, in a paper presently in manuscript form,
has referred to such languages as "plastic languages", in
the sense that the systems programmer, in designing the
dedicated system, can modify the interpreter for the
language, and thereby change the virtual machine, in
much the same way as writable ROM's can be used.
Indeed, the two approaches can easily be combined; one
could wire the interpreter in an ROM and plug it into
the computer, thus creating an unalterable virtual
machine for FOCAL or ESI.
It should be noted that the use of the "plastic
language" technique is limited to those systems which
are not time critical, since the interpretive nature of
program execution makes the resulting virtual machine
relatively slow. One of the authors has been quite
successful in applying this technique to a proprietary
dedicated system, where its advantages are quite
significant particularly regarding ease of modification
of the higher-level application code.
SUMMARY AND SOME SPECULATIONS
In closing, we would like to summarize a few points
made earlier, and to exercise our license to speculate a
little on the near future of minicomputers.
First, the user of minicomputers for the solution
of general-purpose applications in data processing,
scientific programming, or engineering, will find minicomputers increasingly indistinguishable from larger
computers. With luck, he will not find that interactive
control, which now distinguishes most minis from larger
systems, has been thrown out in the wash.
Second, the cost/performance ratio of minicomputer
hardware will continue to improve at the same rate as it
has over the last five years.
Third, the minicomputer user will continue to
receive the benefits of cost/performance ratios through
decreases in cost for the same, or slightly improved,
performance while the large computer user will generally
continue to receive more performance at the same cost.
Fourth, and as a consequence of the above, all
applications of minicomputers will become increasingly
more economical. Thus, many applications which are
not performed on minis today, or many which are not
done on computers at all, will utilize minis in the near
future as prices continue to drop.
It might be argued that time sharing could just as
easily be used in the future to solve problems which do
not use computers at all now. It is undoubtedly the case
that time sharing will continue to be used for those
The Future of Minicomputer Programming
problems which require its unique assets, i.e., essentially
as much processor time, as much I/O, as much core and
disk space as required, when you need it, purchased on
an "as you use it" basis. But even at the most favorable
rates available today, time sharing is much more
expensive than using a mini. The lowest price we know
of for time sharing is about $8 an hour for as much time
as you can use, though this is on a relatively small
system with quite heavy loading and a lot of contention.
On the other hand, even at today's prices, a mini can
be bought for $5000. If this is written off over three
years, and used 40 hours a week, an effective price of
only about one dollar an hour can be approximated.
A few years from now, this should drop to around 25
cents an hour.
We see the possibility of people providing a variety of
"plug-in packages" for popular minis, quite likely
software provided in the disguise of ROM hardware to
provide the supplier with proprietary protection,
product standardization, and integrity against unauthorized user changes. Some of these standard plug-in
packages might be:
(a) The CO GO virtual machine for the civil
engineer.
(b) The JOSS@ virtual machine for the engineer and
statistician, replacing today's electronic desk
calculators.
(c) The small business virtual machine, providing
the retailer with a small machine capable of
performing routine bookkeeping.
(d) The homemaker virtual machine, providing the
busy housewife with a menu planner, household
controller, alarm system, and checkbook
balancer.
In conclusion, if the designers and product planners
of minis think more clearly on what minis can do in
both program creation and program execution, we may
see an end to the minicomputer syndrome.
109
"He nodded and went out ... and in a moment I
heard Winnie-the-Pooh-bump, bump, bumpgoing up the stairs behind him."
Ending of Winnie-the-Pooh, A. A. Milne
REFERENCES
1 A W HOLT W J TURANSKI
Extended machine-Another approach to interpretive storage
allocation
Under Army contract DA-36-039-sc-75047 Moore School of
EE U of Pa 1960
2 C J SIPPLE
Computer handbook and dictionary
Bobbs-Merrill Indianapolis 1966
3 R W WATSON
Timesharing system design concepts
McGraw-Hill New York 1970
4 PDP-7 CORAL manual
Applied Data Research Inc Princeton N J 1967
5 Broadcast programmer user's manual
Applied Data Research Inc Princeton N J 1968
6 I nterdata microprogramming manual
Interdata Ocean Park N J
7 A KOTOK
DEC debugging tape
Memo MIT-l rev MIT December 1961
8 D J WAKS
Interactive computer languages
Instruments and Control Systems November 1970
9 D J WAKS
The MIMIC programming automation system
Applied Data Research Inc Internal memorandum July
1971
10 MIMIC user's guide
Applied Data Research Inc Ref #01-70411M May 1971
11 AED manual
Softech Cambridge Massachusetts
12 BLISS-tO manual
Carnegie-Mellon Univ Pittsburgh Pa
13 ESPOL manual
Burroughs Corp Detroit Mich
14 D J WAKS
Conversational computing on a small machine
Datamation April 1967
15 FOCAL user's manual for PDP-8
Digital Equipment Corp
The current state of minicomputer software
by JOSEPH F. OSSANNA
Bell Telephone Laboratories, Inc.
Murray Hill, New Jersey
the most common in currently available machines. The
range of memory sizes available in a typical current
machine is from 4K words (K = 1024) to 32K words.
Basic instruction sets typically lack multiply and
divide, decimal and floating-point arithmetic, arbitrary shifting, and fancy character string manipulation. Although minicomputer memories are smaller
than those of large machines, the memory cycle times
frequently are similar, with the result that computing
speeds are similar in applications where a smaller word
size and the absence of some types of arithmetic are
not a factor. Basic input/output structures usually
employ a single time-shared bus with limited device addressing and with limited parallelism during data transfer. Features such as memory protection, relocation,
and segmentation are usually nonstandard or unavailable. Often few fast registers are included. The selection of peripherals standardly interfaced to a given
machine typically has been limited. In the past, the
only reliable peripherals available have been expensive
ones originally designed for the larger computer systems.
To some extent, what has just been said above is
becoming less true with time. The spectacular advances in integrated circuit technology in recent years
have resulted in dramatic price declines. Core memory
and peripherals have also become less expensive. The
price of a basic system consisting of the central processor (cpu), 4KX16 bits of core memory, and a Model
33ASR teletypewriter has dropped from about $25,000
in 1966 to about $8,000 in 1971. 1 The circuit technologyadvances have also made increased system
capability economically attractive. The following
amendments to the list of minicomputer characteristics
are presently apropos.
INTRODUCTION
Noone who has watched the spectacular growth of
the minicomputer industry needs to be told that people
are finding new small computer applications at an
astonishing rate. Undoubtedly there are many reasons
for this striking increase in minicomputer utilization.
Certainly one reason is the increasing sophistication
of minicomputer software. This paper will summarize
the development of this sophistication, and will try
to characterize its present state. Minicomputer hardware evolution will be discussed because of its effect
on minicomputer software evolution. The range of
minicomputer uses and users will be characterized
along with their varying software organizations. Commentary on techniques of minicomputer software
development is included. A number of examples of
both past and present minicomputer software systems
are presented.
MINICOMPUTER HARDWARE
A minicomputer is a "minicomputer" by nature of
its hardware which is relatively simple, physically
small, and comparatively inexpensive. This is accounted for by the following general characteristics
compared to the "ordinary" large computer.
•
•
•
•
•
•
Shorter word length
Smaller memories
Fewer and simpler instructions
$impler input/output capabilities
Minimal features
Fewer peripherals
• Instruction sets improving; fast multiply, divide,
and floating-point optionally available. More and
better addressing modes being designed.
• Memory protection, relocation, and segmentation
becoming optionally available.
In addition to the above, limited software support by
the manufacturer and lower marketing costs have
contributed to the lower price of the minicomputer.
Wordlengths range from 8 to 24 bits with 16 bits being
111
112
Spring Joint Computer Conference, 1972
• Larger sets of fast general registers becoming
common.
• New bus concepts are providing better input/
output structures.
• Priority interrupt structures and interrupt vectors
are becoming standard.
• Smaller and well designed peripherals are available
at reasonable cost.
• Less expensive disk storage is becoming available
in sizes commensurate with small machines.
Manufacturers have achieved this and are providing
increased software support without noticeably stemming the price decline.
These recent improvements in small machine architecture have attracted more sophisticated applications and more sophisticated systems designers. The
advent of inexpensive disk storage is probably the most
important occurrence influencing minicomputer software evolution.
A tabular summary of currently available minicomputers and their characteristics can be found in
Reference 2. Similar information along with projections
of the future of the minicomputer industry are given
in Reference 1.
In a survey conducted within Bell Laboratories in
the Spring of 1971 of approximately 200 minicomputer
systems the following usage breakdown was reported.
31 % Computerized testing of equipment and
devices.
19% Data acquisition and reduction.
18% General-purpose computing, some with data
acquisition.
15% Peripheral control (plotters, cameras, displays, unit-record equipment).
9% Intelligent graphic terminals and interactive
graphic systems; general-purpose graphicoriented computing.
7% Process control.
It is possible to observe different software organizations across these various types of users. Some of the
differences are clearly due to the nature of the applications. Many are due to the nature of available software
support, to the software experience of the programmers
involved, and to hardware limitations. In the next
section these differences are characterized.
SOFTWARE ASPECTS
MINICOMPUTER USES AND USERS
Most minicomputer systems consist of a generalpurpose small machine configured in a way suitable for
some particular application. Tailoring the size and
complexity of a system to the requirements of a particular job can result in an economy of specialization
that outweighs the economy of scale of using a part
of a larger machine. 3 ,4 Accordingly, one would expect
the range of applications to break down in a way that
reflects this economic bias. Auerbach1 reports that in
1970 minicomputer dollar sales were divided as follows.
45% Industrial and process control.
3% Peripheral control (COM, OCR, line printers,
etc.).
20% Communications control (concentrators,
switching) .
10% Computations.
22% Data acquisition and reduction.
Process control and data acquisition often involve
intimate connection to distributed sensors or laboratory
instruments. This is often infeasible for centrally
located large machines, especially when coupled with
the necessity for rapid control by the user and his program.
The choice of a software organization for a minicomputer system can profoundly affect hardware requirements, general efficiency, the range of applications, extensibility, and the ease of software maintenance and modification. The best organization in a
particular case depends on which considerations are
paramount. Other considerations include the following.
• Are the application programs to be run under an
operating system?
• Is there to be on-line secondary storage?
• Are there crucial real-time response requirements?
• Are there to be multiple simultaneous users?
• Is the system to be self-supporting-i.e., can the
application programs be developed and maintained
on the system?
• Is there a justification or need for core protection,
relocation, or some sort of virtual memory?
An "operating system" is a collection of basic and frequently used utility programs essential for convenient
and efficient use of a machine. For many people this
loose definition means the sum of all the programs they
use that were written by someone else and consequently
not easily modified. lVlost minicomputer operating
systems are simple and basic compared to those used
Current State of Minicomputer Software
on large machines. The most basic form of operating
system consists of programs to perform physical input/output and handle code and/or format conversion
of the transmitted data, and a program to bring the
user's program into core and give control to it. If the
minimization of core usage is paramount, the generality
of even a basic operating system may need to be foregone and only the absolutely necessary input/output
programming be included directly in the user's program.
Such inclusion of operating system functions in application programs is not uncommon on small machines.
If the same machine is to be used to develop the
user's programs, other support programs are needed.
An editor is needed to create and modify the user's
source text (unless he is doing it manually, for example
using cards). An assembler or compiler is needed to
translate this source text into executable machine code.
Optionally a debugger is useful for analyzing program
troubles. Operationally, the first two are run like user
programs, and the latter is usually combined with the
user program if needed.
If there is justification for on-line random-access
secondary storage such as a disk or drum, a different
perspective is possible. The less frequently used portions of any operating system and of the user's program
need not be permanently core resident, and core requirements can be minimized without foregoing the
convenience and generality of an operating system.
Further, support programs like those mentioned above
can be stored on disk for handy use (by disk will
usually be meant any such secondary device). Additional support in the form of libraries of user and utility
programs can be easily kept along with a binder program that can search libraries and combine collections
of program modules into executable units. Greater
convenience is obtained when the operating system
provides organized access to the disk by means of some
sort of a file system. A well designed file system is
usually the foundation of the better general-purpose
operating systems.
Real-time response requirements can have strong
implications for software system design. By real-time
we do not here mean the requirements of controlling
conventional peripherals such as disks, tapes, unitrecord equipment, or most communication lines. In
these cases a too-slow response usually causes retries
and degrades efficiency but is not ordinarily fatal.
What is meant are the response requirements of controlling such things as a steel rolling mill, a linear accelerator, or an oil refinery. Industrial process control
systems typically receive a variety of external stimuli
requiring a wide range of response times. This necessitates a hierarchical priority structure for the inter-
113
ruption and execution of programs. When there is
more than a few such programs the scheduling can become quite complex. Operating systems for such situations are usually different than general-purpose ones;
process control systems are discussed later. Data acquisition systems and communications control systems
can have real-time response probJems, if peaks can
occur that would temporarily tax their processing
capacity and it is important that no data be lost.
Unlike a process control system which supervises
known external processes with generally known chari
acteristics, a multi-user system such as a general-purpose time-sharing system faces user submitted tasks
of more-or-less unknown characteristics. For example,
resources such as processor time, core space, and file
system space demanded by the user processes vary
dynamically, and the system generally must schedule
adaptively and enforce various limits on resource
utilization. Even if a minicomputer system is economically justified when wholly committed to some
application, a multi-user capability can permit software development to take place while the main application is running. An example of a multi-user system
is given later.
Core protection is a hardware feature that enables
the operating system to make sensitive regions of core
storage inaccessible, thereby protecting those regions
from damage by being written or preventing information from being read. This feature is uncommon in
minicomputer systems that operate with debugged
programs, but is usually mandatory in multi-user
systems that permit users to write and execute arbitrary programs. Relocation is a hardware feature that
permits a program to be loaded at any convenient
place in core memory, and to be moved (while interrupted) to another place. This feature can be a great
asset to, for example, a process control system trying
to juggle a myriad of different sized programs between
disk and core. Virtual memory5 is a concept where a
program can think it has more core than it really has
or even than there is.
RETROSPECTION
When one looks at the minicomputer systems being
used in the early 1960s one sees minimal hardware with
typically no disk storage and minimal software support in the form of operating systems, compilers,
editors, etc. The temptation was therefore great to
make use of the nearest computer center with its big
machine, big disk, and varied software support.
One of the first minicomputer applications that the
114
Spring Joint Computer Conference, 1972
author came in contact with at Bell Laboratories circa
1964 was an experimental remote graphical display
system called GRAPHIC-1. 6 The hardware consisted
of a Digital Equipment Corporation (DEC) PDP5
computer with 4K X 12 bits of core, a modified DEC
Type 340 display scope, a 4KX36 bit display memory,
a light pen, Model 33ASR teletypewriter, and a card
reader. In addition there was a high-speed connection
to the direct data channel of a nearby IBM 7094.
Support software consisted of an assembler and postprocessor to assemble, merge, and link relocatable
programs to form executable units for the PDP5, a
display material assembler, and a library of input/
output and inter-computer communication programs.
These support programs ran on the 7094 and produced
cards that were read into the PDP5. End users of the
system could write in a higher-level graphical language
called GRIN6 which also ran on the 7094, and could
use the system to submit a regular batch job to the
7094. This dependence on the local big machine was a
natural yielding to the temptation to do software development in a convenient environment.
GRAPHIC-27, a successor system to the one above,
emerged in 1967 and is notable for its relatively sophisticated software. It is implemented on a DEC
PDP9 computer with 8K X 18 bits of core, a fast fixedhead disk, display, light pen, fast paper tape reader/
punch, and a dial-up 2000 bit/sec link to the local big
machine. As in the preceding case all the software for
the PDP9 was written using support programs on the
local computing center large machine, a Honeywell
Information Systems 635. The end user is provided
with a graphical programming language called GRIN-27
and an assembler, both of which run on the 635. In the
next version of the system these will run on the PDP9
itself. GRIN-2 provides the ability to control the manmachine interaction, to create and edit graphical data
structures, and to control the display. The system may
be used in a stand-alone mode or it may be connected
to the 635 and used in a mode where programs executing
in the 635 send over programs or data on demand to
the PDP9. One of the more interesting aspects of the
software in this system is that it provides a form of
virtual memory to the user program. To do this, each
user's program and data is broken up into blocks which
are assigned unique identification numbers (IDs). All
references between blocks are in terms of this ID and
an offset within the block. When a block is referenced
it is retrieved from disk or possibly from the big machine. Only the currently needed blocks are actually in
core at a given time. The user is relatively free from
worrying about the size of core; one user application
program consists of nearly 60K PDP9 words.
Another example is a small laboratory computer
system used for the acquisition and reduction of data
from a spectrometer. It originally consisted of a DEC
PDP8 with 4K X 12 bits of core, a Model 33ASR teletypewriter, a DEC Model 34D display, a home-made
analog-to-digital converter, an extended arithmetic
element, and interfaces to laboratory equipment. The
user wrote his own application software in a few months
using a DEC supplied editor and assembler on the
PDP8 itself. Both user and support programs were
stored on paper tape and had be be loaded using the
reader on the 33ASR. How long does it take to read
4K X 12 bits at the rate of 10 8-bit characters per second? This user eventually got 128K X 12 bit drum primarily to facilitate the acquisition of more data than
would fit into core. He now uses a DEC supplied diskbased operating system for program development and
to run his application. This system is typical of quite
a few minicomputer systems within Bell Laboratories.
A more recent (1968) example of a laboratory computer system designed for self-service by a variety of
users at Bell Laboratories is described in Reference 8.
The hardware consists of a Honeywell DDP224 with
floating-point instructions, 32K X24 bits of core, two
disk drives for 2.4 million word removable disk packs,
magnetic tape, a card reader, analog-to-digital and
digital-to-analog converters primarily for speech and
music, a console typewriter, various graphical input
and output devices, and miscellaneous devices such as
a piano keyboard. Extensive software support is provided for the user in the form of a simple disk operating
system with utilities for all the various devices, an
assembler, a Fortran compiler, an editor, a loader, and
a large library of useful programs. A simple file system
is provided along with disk utilities for physical disk
accessing. Disk conflicts are avoided by informal agreements and by many users having their own disk packs.
The operating system will bring whatever program the
user wants into core from disk but the user must manually transfer control to its starting location. This
machine has been very successfully used by more than
a dozen users for various research projects. A main
drawback is the necessity for users to sign up for time
on the machine, and a limited multi-user capability
would undoubtedly be welcome. The system is much
like a user-operated batch processing system. Even
though some of the applications involve real-time
response and are demanding of the processor, such
tasks as file editing and compiling could go on at a
lower priority or be done concurrently with less demanding tasks. Such an ability would require a better
file system for user isolation and some scheme for rotating user programs through or sharing core. In this
Current State of Minicomputer Software
system, such additions would be tantamount to a
complete redesign.
INTROSPECTION
Just as in the case of software design evolution on
big machines, the evolution of software on small
machines has not been homogeneous throughout the
field. The inertia inherent in the use of successful software can last for times comparable to the current age
of the minicomputer era. Most of the systems described
earlier are still working. There probably isn't any
early software design or development techniques that
isn't still being practiced today. The major impetus
for software design improvement comes from the introduction of more advanced machines and from the
infusion of fresh software techniciar s. Attracted by
the newer small machines and often experienced on
big ones, these fresh workers are beginning to achieve
on the minicomputer a decree of software design
sophistication previously seen only on larger machines.
In the next section an attempt will be made to characterize minicomputer software currently in common
use and to describe some forefront efforts.
CURRENT EXAMPLES
115
The number of task-oriented programs is usually
sufficiently large that economy dictates that they not
all be core resident; thus programs need to be brought
into core when needed. The existence of the shorter
real-time requirements as well as the desire for reasonable efficiency dictates that several programs reside
simultaneously in core. Thus a process control system
takes on the appearance of a multi-programmed timesharing system. In contrast with time-sharing systems,
the scheduling of the execution and interruption of
programs is more complex in process control systems. lO
The relative priority of programs is typically dependent
on process conditions, operator intervention, and even
such things as the time of day. While the general technique is to respond to hardware interrupts and place
programs into execution priority queues, provision
must usually be made for certain high priority programs to purge certain other low priority programs
from queues and for low priority programs to inhibit
their interruption at certain critical times. Some sort
of organized provision is required for the interlocking
of shared data bases. Although most of the programming is done in assembly language and in Fortran, a
number of process control oriented languages have
been developed and used. l l The process control field
has in some ways reached a greater level of sophistication than other fields of application.
Industrial process control
Communications control
All indications are that this field will be one of the
largest users of minicomputers.l Work in this field, not
all involving minicomputers, is relatively extensively
documented. 9,lO As indicated previously, process control
applications 'often involve a wide range of real-time
response requirements. Control algorithms involve the
operation of complex multi-loop negative feedback
systems. Most systems involve two forms of control:
direct digital control in which the computer directly
controls process variables; and supervisory control
in which the computer sets the operating points of
otherwise independent analog controllers. The response
required in direct digital control ranges from milliseconds to seconds, while that required for supervisory
control ranges from seconds to minutes. In addition,
there is usually an overall optimizing and adaptive
control function that slowly modifies the control
algorithms. On top of this response time hierarchy can
be management information and long-term scheduling
functions involving delays measured in days or weeks.
Direct digital control tasks are usually many in number
but relatively simple while supervisory control tasks
are fewer in number but relatively complex.
This field includes communication line concentrators
and controllers used as communication front-ends for
large computer systems, as nodes in communication
networks, and as message switching centers. The latter
application requires secondary storage while the others
do not. Data line concentration and control can usually
be done less expensively and more flexibly with a minicomputer than with wired hardware controllers.
An example of a minicomputer front-end is the line
concentrator used to interface varied terminal equipment to the Michigan Time-Sharing System. l2 This
system was experimental and its hardware complement
is not necessarily optimized. It consists of a DEC
PDP8 with 12KX12 bit of core memory, a Model
33ASR teletypewriter, a high-speed paper tape reader/
punch (to facilitate software development), an extended arithmetic element, an interface to the local
IBM 360/67's multiplexor channel, and interfaces to
standard telephone data sets operating at all the
standard speeds. The lower speed interfaces are bit
buffered and the faster ones are character buffered.
The system performs a limited form of terminal type
116
Spring Joint Computer Conference, 1972
identification of low speed asynchronous typewriter
terminals and handles a variety of IBM and teletypewriter terminals. Because the speed of operation of
each line is program controlled, statistical sharing of
the access lines reduces the required number of telephone ports. The system-terminal interface is better
human engineered than that obtained using standard
IBJ\;I hardware line controllers. Full duplex operation
of teletypewriters is standard and read-ahead of the
terminal keyboard is provided. 13
While such a system is less complex than many process control systems, the bit and/or character completion interrupt rate is high and the responding programs
can't dawdle. The low number of distinct tasks combined with the high task rate dictates that the software
all be core resident. The system described above was
equipped to serve 16 low speed asynchronous lines and
4 voice grade synchronous lines; however, a system
of this kind more typically can serve between 32 and
64 low speed lines along with several voice grade lines.
Paper tape operating systems
The above heading may overdignify the collection
of software that it refers to, but this kind of software
support is one the oldest and is still common. If one
has a typical basic minicomputer configuration consisting of a processor, 4K words of core, and a teletypewriter with paper tape handling, one either does
his software development using support programs
stored on paper tape or uses some other machine for
development and reserves the basic machine to run
the application. The main drawback with paper tape
based support is the slow rate of reading and punching
paper tape. This drawback can be largely mitigated
by adding a high speed reader/punch. Surprisingly
enough, the convenience of working on your own
machine and the fact that a cycle of editing, assembling,
and reloading may be shorter than the time required
to travel to and wait on the local computer center, may
make the use of a paper tape operating system feasible.
Of course, access to a good time-sharing system with
the right kind of program support or to another machine like yours but better equipped is probably preferable.
An example of a current paper tape system in DEC's
paper tape software for the PDP11. 14 It provides an
absolute loader for reading in all programs, a reasonable
text editor, an assembler, floating-point simulation, a
math package, a collection of input/output utilities,
and an octal debugger. The editor is used to create
and edit programs at the teletypewriter; during editing,
the old copy of the source is read off paper tape a block
at a time, edited, and then punched. Assembling a
program consists of reading in the assembler, feeding
the source program to the assembler twice, and receiving an executable object copy of your program from
the punch. Your program can then be tried by loading
it; after loading the loader will transfer control to it
automatically. If it works, fine; if not the octal debugger
can be loaded into vacant core (if any) and used to poke
around in the remnants. All of this is or is not as awkward as it seems depending on the alternatives open
to you. With enough core a simple core resident operating system containing all the support programs with
some core left for the user would be even more convenient; the additional cost is comparable to the cost
of the smaller disks.
Disk operating systems
It has been observed several times previously that
the addition of disk storage to a minicomputer system
makes a world of difference. Even the simplest diskbased operating system greatly magnifies the convenience of working on your own machine, which becomes like using a one-user time-sharing system. ::Vlultiuser systems are possible and desirable and are discussed later. Much of what is possible with disk is
possible in a slower more restricted way using randomly accessible magnetic tapes such as DEC's
DECtape,15 or even small tape cartridges.
An example of a recently available (circa 1968) disk
operating system for a machine that has been around
in some form for awhile is the PS/8 operating system
for the PDP8 family of machines. 16 It requires 8K words
of core and a disk or DECtape.
Another example is DEC's disk operating system for
the PDP11.I7 It requires at least 8K words of core, a
small disk augmented by DECtape, or a larger disk,
a high speed paper tape reader/punch, and a console
typewriter. The support software includes a command
interpreter, a reasonable text editor, an assembler, a
Fortran compiler, an octal debugger, a file utility
package, floating-point simulation, a math package,
and a linker to combine programs. The operating system
provides a reasonable file system and does input/output
for the user. Core is divided into five regions: a small
region at the bottom containing the interrupt vectors
which indicate the location of interrupt handling programs; next a small area for the resident monitor; an
area for the user program at the top of core; below that
the stack (where parameters are stored temporarily
during the transfer of control between programs); and
Current State of Minicomputer Software
a free area divided into blocks and used for buffers,
temporary tables, and device drivers brought into core.
To invoke a system support program such as the
editor or a user program written to run under the
system, the user types a request on the console keyboard which can include information about which
input and output devices are to be used during the run.
User programs can be used interactively and can be
interrupted for debugging.
Multi-user time-sharing systems
It is an accepted fact nowadays that the time-shared
use of a computer is one of the more effective ways of
increasing the productivity of a group of users in need
of computing service. The advantages of "working on
your own machine" are effectively extended to the
whole group at once. A multi-user system is inherently
more complex than a single user one; it is necessary
to multiprogram and/or swap user programs between
disk and core and to keep track of everyone's input/
output and machine conditions. It is helpful too, if
users can be prevented from injuring each other and
the system.
We shall present here, as an example of a multiuser
system, a system recently developed (primarily by
. K. L. Thompson) at Bell Laboratories which is felt
to be at the forefront of minicomputer software design.
This system utilizes a DEC PDPll/20 computer with
12KX16 bits of core storage, a 60 cycle clock, a 256K
work fixed-head disk, a disk drive for 1.2 million word
disk cartridges, a dual DECtape drive, 8 low speed
asynchronous line interfaces for remote typewriters,
and a little-used paper tape reader/punch.
Core is divided into an 8K word/region containing
the totally core resident operating system and a 4K
word region for the user program and his stack. The
system space includes about 2K used for a pool of
dynamically allocated buffers. The operating system
maintains an excellent file system, creates and manages
user processes executing core images), does input/
output for the user, and performs all scheduling functions. Scheduling is by placing ready-to-run users on
one of three queues, depending on whether the user
has interacted (has just typed an action character on
his console), some pending input/output has completed,
or the user has run out of time allotted for execution.
All users are swapped between the fixed-head disk and
the same region of core.
The main feature of this system is a versatile, convenient file system with complete integration between
117
disk files and all input/output devices. There are three
kinds of files; ordinary disk files, directories, and
special files representing physical devices. A directory
is like an ordinary file except that only the system can
modify it. The file system is a tree structured hierarchy
originating at a root directory. Any type of file can
occur at any level. Files have names of eight of fewer
characters. At any given time a user process is associated
with a particular current directory. When the user
program wishes to open or create a file, it gives the
system the file name of a file in the current directory
or it gives a path name which either specifies the absolute location in the tree or the location relative to
the current directory. If the reference is successful, the
system returns a file identification number to be used
for future references. File system protection consists
of associating with the file at time of creation the name
of the creator and permitting him to specify whether
he and others can read and write the file. Files are
formatless and are regarded as strings of 8-bit bytes.
Another feature of the system is the ability to initiate
asynchronously executing processes from within a
program or from command level. Commands are normally terminated with semicolons or new-lines; the
command interpreter creates a process to execute the
command and waits for its completion. If the command
is terminated instead by an ampersand, the same thing
occurs except that the command interpreter doesn't
wait. Argument strings typed with a command are
made available to the program by placing them on
the stack.
The name of any executable program can be used
as a command. The name is first searched for in the
current directory and if that fails it is then searched
for in a system library. A myriad of commands are
available including those for listing directories, moving, copying, and deleting files, changing the owner
and mode of a file, and changing the current directory.
Other programs available include a context text editor,
an assembler, a symbolic debugger, a linking loader, a
dialect of Basic, Fortran, a text formatter, games such
as chess, and various experimental languages.
The system operates 24 hours a day, seven days a
week. A user community of about a dozen people access
the machine regularly although it is not a service offering. The group that owns the machine uses it heavily
for preparing documentation using the editor and text
formatter. The maximum of eight simultaneous users
(limited by the number of lines) does not tax the
machine's capacity. Because of the lack of core protection, any user can write, assemble, and run a program that could damage the system and cause a system
crash. However, since most users use debugged pro-
118
Spring Joint Computer Conference, 1972
grams like the editor or text formatter, and because
those few who develop new programs are careful, surprisingly few crashes occur. A future version of this
operating system will be developed for a version of the
PDP11 having core protection and relocation.
Virtual memory systems
One of the more interesting areas in minicomputer
software is the use of virtual memory to manage the
core and secondary storage of a small machine. A
system in an earlier example, GRAPHIC-2, supported
a form of virtual memory without the use of special
hardware. Another similar example is a small timesharing system on a Honeywell DDP51618• A different
example involves the use of hardware assisted segmentation and paging on a specially modified Interdata
Model 319 •
CONCLUSIONS
There has been a decided evolution toward greater
sophistication in the design and use of minicomputer
software during the relatively short years of the minicomputer era, although many of the earlier methods
are still in use. A major force toward software improvement has been the introduction of new and better
machines and the advent to relatively inexpensive
disk storage. The expanding minicomputer field has
benefited from the attraction of fresh software design
talent often with large machine experience. Some
recent forefront efforts are yielding minicomputer
operating systems with features previously found only
on large machine systems.
REFERENCES
1 Minicomputers
Auerbach Technology Evaluation Series EDP Series No 4
Auerbach Info Inc Philadelphia Pa 1971
2 D J THEIS L C HOBBS
The minicomputers revisited
Datamation Vol 17 No 10 pp 25-34 May 15 1971
3 M V MATHEWS
Choosing a scientific computer for service
Science Vol 161 p 2368 July 5 1968
I
4 J R COX JR
Economies of scale and specialization in large computing
systems
Computer Design November 1968
5 P J DENNING
Virtual memory
Computing Surveys Vol 2 No 3 pp 153-189 September 1970
6 W H NINKE
Graphic-l-A remote graphical display system
AFIPS Conference Proceedings Vol 27 Part 1 1965 FJCC
Spartan Books Washington D C pp 839-846
7 C CHRISTENSEN E N PINSON
Multi-function graphics for a large computer system
AFIPS Conference Proceedings Vol 31 1967 FJCC
Thompson Books Washington D C pp 697-711
8 P B DENES M V MATHEWS
Laboratory computers: Their capabilities and how to make
them work for you
Proceedings of the IEEE Vol 58 No 4 pp 520-530 April 1970
9 Special issue on computers in industrial control
Proceedings of the IEEE Vol 58 No 1 January 1970
10 C L SMITH
Digital control of industrial processes
Computing Surveys Vol 2 No 3 pp 211-241 September 1970
11 H E PIKE JR
Process control software
Proceedings of the IEEE Vol 58 No 1 pp 87-97 January 1970
12 D L MILLS
Preprocessors in a data communication environment
Proceeding of ACM Conference on Problems in the
Optimization of Data Communications Systems
Pine Mountain Ga pp 286-310 October 1969
13 J F OSSANNA J H SALTZER
Technical and human engineering problems in connecting
terminals to a time-sharing system
AFIPS Conference Proceedings Vol 37 1970 FJCC
p 355-362
14 PDPll paper tape software programming handbook
DEC-11-GGPA-D Digital Equipment Corporation
Maynard Massachusetts 1970
15 PDPll peripherals and interfacing handbook
Digital Equipment Corporation Maynard Massachusetts
1971
16 PSI8 system user's guide
DEC-P8-MEFA-D Digital Equipment Corporation
Maynard Massachusetts 1970
17 PDPll disk operating system
DEC-II-SERA-D Digital Equipment Corporation
Maynard Massachusetts 1971
18 C CHRISTENSEN A D HAUSE
A multiprogramming, virtual memory system for a small
computer
AFIPS Conference Proceedings Vol 36 1970 SJCC AFIPS
Press Montvale New Jersey pp 683-690
19 B H LISKO V
The design of the venus operating system
Proceedings of the Third ACM Symposium on Operating
Systems Principles Stanford University pp 11-16 October
1971
Real-time fault detection for small computers*
by J. R. ALLEN
Bell Telephone Laboratories
Naperville, Illinois
and
S. S. YAU**
Northwestern University
Evanston, Illinois
INTRODUCTION
excessive storage, noncontiguous memory locations
or excessive execution time.5-7 Much of the previous
work attempts to locate faults as well as detect them.
While fault location is desirable, it is more expensive
and requires much more time and storage than fault
detection. Many applications do not require fault location. It may be more feasible to either interrupt the
task or perform the task manually during the diagnosis
and repair interval; the most important thing is to
recognize that the computer may be performing the
task incorrectly.
An earlier technique attempted to simulate each
instruction using different instructions and comparing
the simulation result with the actual result. 7 This
technique requires that the computer be somewhat
operational and that it be capable of comparing the
two results. A means is needed for determining that
the test routine is executed periodically.
In this paper, we propose a real-time fault detection
scheme for small computers which is effective for faults
in the central processor unit (CPU), core memory and
I/O bus. It requires an external monitor which is
simple, inexpensive, and interfaces to the computer's
I/O bus just as any other peripheral device. The monitor
periodically triggers a program interrupt, causing the
computer to execute a predefine test routine. During
the course of the routine's execution, several key bit
configurations are transmitted to the monitor. If the
computer fails to respond or if the bit configuration
does not match the one that is expected, then the
computer is assumed to be faulty and the device may
either cause a power down or sound an alarm.
The proposed technique compares favorably to the
previously referenced techniques in fault detection.
Certain faults will not be detected, however, because
Advancing technology and declining costs have led to
a sharp increase in the number and variety of small
computers in use. Because small computers are readily
suited for many real-time applications, a great deal
of work has been directed toward simplifying the interface between the computer and its peripherals. Hardware interrupting capability and a specially designed
I/O bus are required for peripheral device interfacing
in a real-time environment and such things as direct
memory access, data channels, and multilevel hardware
and software interrupt capability are common. These
machines tend to be parallel, synchronous computers
with a relatively simple architecture.
In a real-time environment, fault detection can be of
major importance. Much of the past work has been
directed toward the design of additional hardware,
internal to the computer, which allows critical feedback
loops to be controlled and often inserts special registers
for the maintenance task. 1- 4 These techniques require
that the maintenance circuitry be designed concurrently with the computer itself and have access to
components internal to the computer. Many problems
can arise from attempting to modify an existing computer. For example, critical timing and gate fan-out
can be disturbed, and most warranties become void
if unauthorized modifications are made to a computer.
Other techniques cannot be used for real-time fault
detection because they require manual intervention,
* Portions of this Work were supported by U. S. PHS Grant
No.5 POI GM 15418-04.
** Depts. of Electrical Engineering and Computer Sciences,
and Biomedical Engineering Center.
119
120
Spring Joint Computer Conference, 1972
INPUT
OUTPUT
Figure I-Typical computer architecture
internal modification to the computer is not allowed.
In the past, real-time fault detection has carried a price
tag comparable to the cost of the computer itself. A
major advantage of this technique is that its low cost
makes a great deal of fault detection possible in applications which would not previously have been cost
effective. The fact that the technique assumes that no
modification may be made to the computer means that
many existing systems could make use of the method
without extensive modifications.
COMPUTER ARCHITECTURE
The proposed fault detection method may be used
with a variety of small computers, all of which are very
similar in architecture. Included in this class of computers are such machines as Digital Equipment Corporation's PDP-8, PDP-9/15; Hewlett-Packard's HP2100; Honeywell's DDP-516; Data General's Nova1200 and N ova-800; Xerox Data System's Sigma-3;
and Hitachi's HITAC-10. All of these are parallel,
synchronous machines with hardware interrupt and
I/O bus.
Figure 1 shows a block diagram of a typical small
computer. The program counter (PC) contains the
address of the next instruction to be executed. The
memory buffer register CMB) serves as temporary storage
for information being written into and read from
memory. The address of the memory cell to be accessed
is placed in the memory address register (MA). The
decoded contents of the instruction register (IR) controls
the instruction sequencer. Other registers commonly
found are an accumulator (AC), general purpose registers
(GPR), an arithmetic register (AR) and an index register
(IX). Most small machines make use of some subset of
these registers.
Most of the logic functions are performed in the
general purpose logic unit (ADR). A pulse on the hardware interrupt lead will cause the instruction sequencer
to save the appropriate registers and to begin executing
a different program.
ADDITIONAL HARDWARE REQUIREMENTS
This section explains the function of each portion
of the block diagram for the monitor hardware shown
in Figure 2.
The DEVICE SELECT modules (DS1 and DS2)
are basically an array of AND gates which allow the
peripheral device control signals and data signals to
pass only when the proper device select code is present
on the device select bus. This allows several peripheral
devices to share the same I/O bus without interfering
with one another. Three device codes are required,
XX, XX, and YY. It is desirable to have one device
code (XX), which is the complement of the other to
verify that each bit of the device select bus can be set
to both logical states.
Device codes XX and YY cause the WIRED
REGISTER to be gated onto the Input Bus. The
WIRED REGISTER is constructed simply by attaching alternate bits to a voltage representing a logical
one and the remaining bits to logical zero. When
device code YY is selected, the "DEVICE = YY"
lead is enabled causing the contents of the WIRED
REGISTER to be complemented before being placed
on the Input Bus. Reading from both device XX and
device YY causes both a 1 and a 0 to be read from each
bit position. Many computers determine the status of
a peripheral device by executing an instruction which
causes the next instruction to be skipped if a status
FF is set. By executing this instruction with device
code XX the BUSY/IDLE FF will appear to be busy;
if device code YY is used, the "DEVICE = YY" lead
causes the FF to appear to be idle. In this way the
device status testing feature may be checked.
Device code XX is used when outputting bit configurations to the monitor for comparison to the
expected value. The INTERRUPT TIMER is simply
a monostable FF which, after an appropriate delay,
will cause a program interrupt to be sent to the computer and at the same time sets a FF, which enables
the RESPONSE TIMER. The testing frequency is
set by adjusting the monostable's delay time.
The RESPONSE TIMER is used to determine that
the computer is taking too long to respond and may be
"lost." If the RESPONSE TIlVIER is not reset or
disabled before it "times out," an OVERTIME signal
Real-Time Fault Detection for Small Computers
INPUT
BUS
DEVICE
SELECT
(DS1 )
~---t
DEVICE
DEVICE
STATUS
121
WIRED REGISTER
= 525252
= YY
DEVICE
CODE
(XX)
OR
(YY)
WIRED BUSY/IDLE
= BUSY
COMPUTER
PRffi
INTERRUPT
OUTPUT
READY
OUTPUT
BUS
DEVICE
SELECT
(DS2)
PI
DEVICE
CODE
(XX)
ROM
INHIBIT
FAULT
OJERTlrvE
Figure 2-Block diagram for monitor hardware
is generated, indicating that a fault has been detected.
A circuit to perform the RESPONSE TIMER function
is shown in Figure 3.
The ADDRESS COUNTER is simply a cyclic
counter designed to count modulo N, where N is the
number of responses expected during a normal test.
When the counter resets, a DONE signal is generated
which disables the RESPONSE TIMER and resets
the INTERRUPT TIMER. The ADDRESS
OVERTIME
Figure 3-Response timer
COUNTER is incremented after each output from the
computer to sequentially address the contents of the
read-only memory (ROM). The ROM need not be
large and may be built economically from a diode
array.
The respDnse from the computer and the expected
response, read from the ROM, are both buffered and
compared by the MATCH LOGIC. When enabled,
the MATCH LOGIC basically OR's together each bit
of the XOR of the two buffers to produce the MISMATCH signal. An OUTPUT READY signal from
the computer is used to load the BUFFER, enable the
MATCH LOGIC, reset the RESPONSE TIMER, and
incremEnt the ADDRESS COUNTER, all after appropriate delays.
If either a MISMATCH or an OVERTIME signal
is produced, the FAULT FF is set. This inhibits any
further output to the monitor, thus preserving the
contents of the ADDRESS COUNTER and the two
buffers as an aid for the diagnosis of the fault.
122
Spring Joint Computer Conference, 1972
The FAULT signal may be used in whatever way
seems appropriate; it may stop the computer, sound an
alarm, or trigger an interrupt to call some form of selfdiagnosis program, which may attempt to actually
locate the fault.
All circuits may be built using conventional methods
and commercially available logic gates. The total cost
of the hardware components is estimated at approximately $250.
GENERAL GUIDELINES
Small computers seldom have a large amount of
core memory, often as little as 4,000 words. Often,
external storage is limited to paper tape, which requires manual intervention to be read. In order for a
real-time fault detection scheme to be useful in these
circumstances, its memory requirements should be
small enough to allow it to remain resident in a very
small core memory and still leave room for the system
programs.
A large number of faults are severe enough to either
stop execution or at least to make sequential instruction execution impossible. No additional effort need
be made to detect such a fault; the resulting failure
to produce the required sequence of responses will
cause the fault to be detected. However, faults which
affect only a single bit position of a bus or register can
be among the most troublesome. This type of fault
may allow execution to continue, perhaps indefinitely,
without an indication the fault exists.
Certain portions of the computer are very difficult
to check under the assumed restrictions. Input-Output
leads, other than those used by the monitor, cannot
be checked without adding more hardware for each
set of leads. Such Input-Output leads include Direct
Memory Access, Data Channel, Console Controls, and
special device channels. These devices usually appear
as a data bus input which cannot be controlled. It can,
however, be determined that none of these inputs is
stuck at a one level as this would always cause the
output of the bus to be one.
The instruction control circuitry cannot be checked
directly. There are no instructions which access most
of the control leads. Therefore, the correct operation
of a control lead can only be determined by checking
conditions caused by that lead, such as the complementing of a register. A thorough check of the control
circuitry, under the given constraints, would be
lengthy. It can, however, be determined that most of
the gating signals can be produced. This can be done
by executing every instruction type and checking to
see that the proper data transfers have taken place.
This method would intuitively seem to be very effective and can be accomplished in a short period of time.
Because the test routine is periodically required to
change the contents of memory locations outside of its
own boundaries, the interrupt facility must be disabled
during the executio:l of the test. This is necessary to
insure that all locations are restored before control is
released by the test routine. Since it is undesirable to
lock out high-priority tasks for a long period of time,
the execution time of the routine should either be very
short or the routine should be segmented to allow the
servicing of high-priority tasks.
There are a number of ways to cause the external
monitor to recognize that a fault has occurred. One
of the most reliable ways is to design the test in such
a way that the computer will output an unexpected
bit configuration in the event of a fault. This technique
is demonstrated by the following example. The accumulator is first loaded with a bit pattern A and then
caused to skip over an instruction which would place
A on the I/O bus. After the skip, the AC was changed
to a pattern B and output to the monitor. If the skip
did not occur, pattern A would have been output and
would not have matched the expected pattern B.
Another method is to cause the program to "loop"
in the event of an error. The normal sequence of output
bit patterns will then cease and the monitor will recognize the cessation of response as an indication of a
fault. Use of these techniques reduces the read-only
memory requirements for the monitor.
TESTING TECHNIQUES
This section describes several techniques, which
may be used to test the various computer components.
Registers
Registers in parallel synchronous machines commonly resemble the configuration in Figure 4. Although
the actual circuitry may vary, the function is very
A
Figure 4-Flip-flop
Real-Time Fault Detection for Small Computers
simple and well defined. When lead C becomes enabled,
the information on lead A (usually a major bus) is
gated into the FF. When lead C is disabled, the FF
retains the state of lead A. A variation of this type of
register requires a fourth lead which clears the register
prior to the enabling of lead C which then OR's the
state of lead A into the FF. Verification that each bit
of a register can be set to both logical states completes
a functional test of the FF. A single possibility
remains-a stuck at 1 fault on lead C. This fault is very
severe because lead C is common to every bit of the
register. Having lead C stuck at 1 would cause lead A
to be fed directly into the FF and would totally incapacitate the register. In most cases the state of lead
A changes many times between the setting and the
reading of a register, thereby, destroying the original
contents. If this does not happen automatically, an
effort should be made to cause it to happen.
To check a programmable register, such as the accumulator, the register is first loaded with a bit configuration. The contents of the register are then output
through the I/O bus to the external monitor. The
programmable register is then loaded with the complement of the first bit configuration and its contents
again output to the monitor. This procedure also
checks the I/O bus drivers, and the outputs of each
bus between the accumulator and the I/O bus.
Not all of the registers generally used in small
machines are directly accessible under program control.
In these cases a variety of techniques must be used in
order to infer that the register can be set and read
correctly. Five such registers were described in the
introduction.
One of these registers is the arithmetic register (AR).
Because the contents of the general purpose registers
is commonly stored into AR so that AR may be used
as the operand, many tests of the general purpose
registers require the data flow to pass through AR,
testing it at the same time. This commonly happens
in the output instruction itself, meaning that no extra
effort is required to check AR.
The second nonprogrammable register is the memory
buffer (MB). This register is used to contain the data
word core memory read-write operations; it must be
capable of being set and cleared in order to correctly
access core memory. If two complementary words can
be read from memory, then the MB is operative.
The third nonprogrammable register is the instruction register (IR) which contains the OP code. This
register is different from the above registers in that its
contents are never gated to a point at which it could be
displayed. In this case a set of instructions may be
selected in such a way that together they incorporate
123
both logical states for each bit. If it can be verified
that each of these operations can be performed successfully, then it may be assumed that IR is operative.
The fourth nonprogrammable register is the memory
address register (MA). This register is tested in the
following manner: the contents of the sequence of
addresses (0, 1, 2,4, 8, ... ,2 n- \ where n is the number
of bits in MA, is saved in a test routine buffer area in
real core for future restoration. Second, two complementary flags X and X are written into location 0
and read back. The flag X is left in location O. Another
flag (Y) is then written into each of the other n locations. If, after the n write operations, the contents of
location 0 is still X, then the MA register is operative
and the n + 1 locations used for this test should be
restored. To see this, assume that a bit (A) of MA is
stuck at either 1 or O. This is not to say that bit A is
the only inoperative bit, but only one of possibly several. In this case, when an attempt is made to write
into location 0, the flag will actually be written into
another location (B). (If every faulty bit is stuck at 0,
then B =0.) Later when an attempt is made to write
into location 2A , this data will also be written into
location B, overwriting the original flag. In general,
location B will be overwritten once for every inoperative bit in MA. When an attempt is made to read from
location 0, the overwritten contents of location B will
be returned, which will no longer be the flag originally
placed there. It should also be noted that a fault in the
address decoding circuitry or the memory itself cannot .
mask a fault in the MA.
The fifth nonprogrammable register, the program
counter (PC), may be tested in much the same way as
the MA register. The first flag to be written into location 0 is the binary configuration of a "JUMP TO A"
instruction. Into the remaining n locations is written
a "JUMP TO B" instruction. After the MA register
has been checked, a transfer is made to location O.
This causes the PC to be loaded with a binary zero
and the "JUMP TO A" instruction there to be executed. At location A, a signal is made to the monitoring
unit that the transfer was successful and the contents
of location 0 are changed to a "JUMP TO C" instruction. The code at location C will cause the program to
loop, or output an unexpected word which will cause
an error conditipn to arise. The test routine then proceeds to transfer to each of the locations 1,2,3 ... 2n - 1•
Each transfer should cause a return to location B,
which simply continues the sequence. However, as
with the MA register, if any bit of the PC is inoperative,
then the "JUMP TO C" instruction will be executed
and an error condition generated.
All of the above registers are found in most com-
124
Spring Joint Computer Conference, 1972
logical state. This can be done by gating both a 1 and
a 0 onto the bus from every AND gate.
1
2--'L-~
3---1
4--""1-__
10
5-----I-~
6 --""'L___
Figure 5-Bus structure
puters and the methods described are generally applicable.
In the methods for checking MA and PC, it is important to insure that addresses 0, 1, 2, ... 2n - 1 do not
lie in critical parts of the test routine. This is simply a
matter of convenience; if this restriction is undesirable,
a slightly more general algorithm can be used to allow
complete freedom in the location of the test routine.
Since all of the n + 1 locations lie in the first 2n locations, the program could be loaded anywhere in the
second half of the memory.
Databu8
A computer data bus typically consists of some variation of the circuit shown in Figure 5. Although there
are many ways to implement this function, using different types of logic gates, nearly all faults will behave
as though one of the leads numbered 1-10 has become
frozen at one logical state. Certain varieties of logic
allow the OR function to be accomplished simply by
tying the outputs of gates A, B, and C together. This
arrangement also satisfies the above statement. One
input of each AND gate is usually common to all bit
positions and functions as a gating lead for transferring
data onto the bus.
A data bus may often be directly accessible to a
number of peripheral devices for such features as
direct memory access or a data channel. When this
happens, one or more of the AND gates in Figure 5
may have inputs which cannot be controlled without
interfering with certain of the peripheral devices. There
will, therefore, be a few of the AND gates which will
not be checked.
For the remaining AND gates, the objective is to
verify that each input and output can assume either
Control circuitry
Unlike a data bus or a register, the circuitry which
controls the gating and timing for the instruction execution is neither simple in function nor standard in
design.
The approach taken here is to include segments of
code in the test routine which will exercise each instruction and check to see that it is performed correctly. This thoroughly tests the instruction decoder
by providing it with all possible inputs. The control
circuitry is the most difficult part of the computer to
check because there is virtually no means of direct
communication between this circuitry and the I/O
bus. All tests must be made by performing an operation
and verifying that the correct operations have taken
place. It is possible, however, that something totally
unexpected may happen in addition to normal operation of the instruction. To detect a fault such as this
would require an extensive test for every instruction.
There is no method known, at present, which would
produce such a test using only the I/O bus with no
hardware modifications to the computer. If such a
method were available, it is likely that the storage requirement and execution time would limit its usefulness for a real-time environment. Fortunately, faults
which occur in the control circuitry are usually quite
severe and grossly affect the instruction execution.
Therefore, a thorough exercising of each instruction
appears to be the best approach to this problem and
may be relied upon to detect the majority of such
faults.
The length of the test can be reduced by studying
logic diagrams in an attempt to find sections of logic
used by more than one instruction. In some computers,
for example, indirect addressing is handled by the
same microinstruction cycle in every instruction. It
would not be necessary, therefore, to test indirect
addressing with each instruction.
Correct operation of certain instructions may be
assumed if execution of the test routine is not possible
without them. For example, it may be assumed that
the JUMP instruction is operative because the first
instruction executed after a hardware interrupt is a
JUMP to the routine which is to handle the interrupt.
Although the approach used in this case is largely
intuitive, if a little time is spent familiarizing oneself
with the computer's logic and timing, the number of
Real-Time Fault Detection for Small Computers
faults which can escape detection can be greatly reduced.
BIT 1
BIT 2
..
BIT N
,.....
r-
~
>
Logic function and condition logic
I.J.I
Most Boolean operations may be easily tested by
exhaustion of their respective truth tables.
As a general rule, small computers have a ripplecarry adder. Because the circuitry is simpler, this form
of adder is easier to check than one using carry-Iookahead. To check an adder, it is necessary to verify
that each bit position can both generate and sink a
carry. Both of these tests may be made simultaneously
for all bits by adding a word of alternating ones and
zeros to itself (252528 +252528) and then adding that
same word's complement to itself (52525 8 +52525 8).
It is also necessary to verify that each bit position can
propagate a carry. This is accomplished by adding 1 to
77777 8. Adding 77777 8+ 777778 verifies that every bit
position can simultaneously generate and sink a carry.
The remainder of the truth table may be verified by
adding 00000 8+00000 8, 77777 8+00000 8, and 00000 8+
77777 8.
It is desirable to consult the logic drawings in order
to determine how to test the overflow and conditional
transfer logic. Although the implementation of this
logic varies between machines, it is quite straightforward and simple to check.
Core memory
The core memory is, perhaps, the functional element
which will fail most frequently. This may be attributed
to the requirement for high-power circuits operating
under closer tolerances than the conventional logic
MA3
125
MA2
+Figure 6-Core memory bit slice
a:
o
I
x
'--
..
I
....
Y - DRIVERS
Figure 7-Memory addressing structure
gates used in the rest of the computer. Many faults
which occur in a core memory are the type which may
be present for a long time before being discovered, such
as a fault which affects only a rarely used part of memory. The ability to read and write at every address
does not mean that the memory is free from faults; a
faulty address decoder may read or write at two locations simultaneously.
Small computers commonly use a 2-1/2D arrangement for the memory address decoding. 8 This method
relies on a coincidence of current on an X-axis lead and
a Y-axis lead to select a core to be written or read. To
do this the address bits are divided into two fields,
which independently control the X and Y current
drivers. In addition, each of these fields is further divided into two subfields. For example, if there are n
bits in the field which selects the Y lead, then half of
these bits will select one of 2110/2 current sources; the
other half will select one of 2110/2 current sinks. Since
every source is connected to every sink, the independent selection of one source and one sink selects one of
the 2110 Y-axis leads. Different sources and sinks are
used for the read and write operations.
Figure 6 depicts the addressing scheme for a 16-word
memory requiring a 4-bit MA. Only a single bit position of the memory word is shown. Other bits of the
same word are selected by replicating the Y-axis
drivers for each bit position as shown in Figure 7.
During the write cycle, only the Y-axis drivers corresponding to bits which are to be set to 1 will be enabled. Because the read and write operations require
currents in opposite directions, separate drivers are
required for each of these operations. This means that
a fault may affect the read operation and not the wri~e
operation and vice versa.
The test procedure for checking the address decoder
is to select one of the four subfields, having length m,
to be checked first. The contents of each of the 2m
locations obtained by selecting all combinations of
these m bits and holding the remaining bits constant
126
Spring Joint Computer Conference, 1972
are stored in a buffer area. Each of the 2m locations
is then set to zero. Into one of the locations is written
a word of all ones. Each of the remaining locations is
checked to see that its contents is still zero. The originallocation is then checked and cleared. This process
is repeated for each of the 2m locations. Upon completion of .the test, the contents of the locations are restored and the test is repeated for each of the remaining three subfields.
To justify this test, assume that one of the input
leads to a read current source were stuck at O. This
would mean that at least one bit in the set of test words
could not be read as a one and would be detected by
the test. It is also possible that an input to a write
current source could be stuck at O. Because of a core
memory's destructive read-out, the corresponding bit,
or bits, could be read once and then never rewritten
as a 1. Again, at least one bit of the set of test words
would be stuck at 0 and the fault would be detected.
Suppose now that an input to a read current source
were stuck at 1. This means that one of the 2m addresses will select two read current sources at the same
time, dividing the read current. The result will now
depend upon the tolerances of the memory. The divided
currents may not be sufficient to cause a core to switch.
At least one test bit would then appear to be stuck at
o and the fault would be detected. The divided currents may, however, each be sufficient to switch a core.
During its execution, the test will cause a 1 to be
written by using lead A. Later, when an attempt is
made to read a 0 by using lead B, lead A will also be
selected and a 1 will be read. Similarly, an input to a
write current source may be stuck at 1. If the resulting
split in the write current is insufficient to switch a core,
the inability to write into certain test locations will be
detected as before. If each half of the divided current
is sufficient to switch a core, the writing of a 1 into some
location C will also write a 1 into some location D. This
extra 1 will be detected when location D is checked
for a O. Because this test is considerably longer than
the previous tests, it may be desirable to partition the
test. A very natural partition would be to check each
group of current sources separately.
The only way to check individual cores in the memory is to read and write using every location. Although
this must be a lengthy test, some time saving can be
realized if the locations are checked by reading a word
and writing its complement back into the same location. If the complement can be read back, the word is
good. This method makes use of whatever is already
in the memory location and, therefore, saves the time
which would have been required to save the contents
to the location and initialize the location. This test is
normally not included in the test program because of
the time required for its execution.
SUMMARY
This procedure has been applied to a DEC PDP-9
computer with two 8K core memory modules. The test
routine requires 550 words of core memory and a maximum of 8 milliseconds per pass. The time needed to
test the core memory increases with the size of the
memory itself; but, by segmenting the test so that only
a portion of the core is checked during each pass, it is
possible to increase the memory size without increasing
the amount of time required for a pass. All tests of the
CPU itself are made each pass, but 12 passes are required to completely test the memory. The hardware
monitor requires 58 words of read-only memory and
solely determines the frequency at which the tests
are made. This frequency may be adjusted according
to the work load on the computer.
This technique would seem to have many applications on small machines which have previously avoided
fault detection because of the cost or the need to make
hardware changes to the computer.
ACKNOWLEDGMENTS
The authors would like to thank IVlessrs. Gary F.
DePalma, G. Wayne Dietrich and J. S. Tang of Northwestern University for helping in the implementation
of this fault detection scheme on the DEC PDP-9
computer.
REFERENCES
1 E G MANNING
On computer self-diagnosis: Part I-Experimental study of a
processor
IEEE Trans Electronic Computers EC-15 pp 873-881 1966
2 E G MANNING
On computer self-diagnosis: Part II-Generalizations and
design principles
IEEE Trans Electronic Computers EC-15 pp 882-890 1966
3 R W DOWNING J S NOWAK
L S TUOMENOKSA
No 1 ESS maintenance plan
Bell System Technical Journal Vol 43 pp 1961-2019 1964
4 K MALING E L ALLEN JR
A computer organization and programming system for
automated maintenance
IEEE Trans Electronic Computers EC-12 pp 887-895 1963
Real-Time Fault Detection for Small Computers
5 C V RAVI
Fault location in memory systems by program
Proceedings of AFIPS Spring Joint Computer Conference
pp 393-401 1969
6 M S HOROVITZ
- Automatic checkout of small computers
Proceedings of AFIPS Spring Joint Computer Conference
pp 359-365 1969
127
7 T R BASHKOW J FRIETS A KARSON
A programming system for detection and diagnosis of machine
malfunctions
IEEE Trans Electronic Computers EC-12 pp 10-17 1963
8 P A HARDING M W ROLUND
Bit access problems in 2Y2D 2-wire memories
Proceedings of AFIPS Fall Joint Computer Conference
pp 353-362 1967
An organization for
successful project management
by DON SMITH, JR.
Computer Sciences Corporation
EI Segundo, California
INTRODUCTION
be exercised as a function that unduly limits imagination. The intent of control is to assure that considerations of product function, cost and schedule remain
clearly visible, and that decisions made which significantly affect such considerations are made consciously,
with the effect of such decisions having received due
consideration. Concerning the time at which control
should be initiated, it is felt that "control begins when
the first germ of an idea for a project appears in the
organization-a discernible effort which will require an
expenditure of organizational resources (human effort,
time, money, physical resources) and lead to an organizational objective."l References 2 and 3 contain related
reading not totally in accord with the above view.
There are, of course, many problems of software
production other than those related to project management that can prevent the end product from being
successful, such as: a faulty or unknown product definition; badly estimated product life; too rapid a development speed; major design problems; poor staffing; and
inappropriate marketing (see also Sections III and
IV of Reference 4). Good management can in many
cases, however, assist in minimizing such problems by
providing early visibility of the product and its problems, and by providing an environment allowing timely
remedial action.
Prior to continuing with the body of this paper, one
reference is particularly recommended for project
planners. This reference, by Bemer,5 contains an extremely comprehensive and useful "Checklist for
Planning Software System Production." Reference 4,
also by Bemer, is further recommended reading.
Successful software development requires that the
product be accepted, that schedules are met, and that
costs are acceptable. The number of software development efforts that do not meet one or more of these
criteria is large. Conversely, there are many examples
of successful development. The total number and
variety of considerations that affect the probability
of success is so large as to be beyond the scope of any
individual paper. There is one important element of
software development that appears to have been
somewhat overlooked, however, and is the subject of
this paper.
This paper presents the thesis that the probability
of software development success is much increased by:
(1) a proper separation of responsibility within the
project organization, combined with; (2) extensive
formal procedures; the combination of the two providing a system of checks and balances that gives
continuous, accurate visibility of project status.
A general project organization is presented here
that is felt to be widely applicable, and that achieves
the required set of checks and balances. The formal
procedures required to enforce the organizational
division are not described completely or in detail, but
examples are given.
It is felt that viable commercial products will only
rarely be successfully developed with project organizations that do not provide some equivalent to the checks
and balances approach described here. It can be
argued that superior products may be developed at
less cost and more quickly by small expert groups
carrying the project from inception to completion. The
technical contributions possible from such an approach
cannot be denied, but the need still exists to place
these contributions in an environment that assures
their control. It should be noted that control need not
MAJOR PROBLEMS IN SOFTWARE
DEVELOPMENT
This section describes the problem areas that are
felt to be historically most common. The problems
129
130
Spring Joint Computer Conference, 1972
described in this section are felt to be significantly
reduced by the organization and procedures later
described.
In the most general sense, the two major problem
classes are:
Those that make the customer unhappy; and
Those that make the developer unhappy.
Problems in the above two classes might also be
classified as follows:
Unsatisfactory product
Schedule delays
Excessive costs
The above problem classes clearly are interactive, as
schedule problems lead to cost problems, an unsatisfactory product leads to remedial action (cost, schedule), etc. Thus the division is to some degree artificial,
but is useful for descriptive purposes.
The above three classes of problems will now be
discussed in more detail.
Unsatisfactory Product
The major causes of user dissatisfaction with the
product are:
1. Too Many Bugs
2. Instability
3. Unsatisfactory Performance
make it work, or the initial design is simply unsatisfactory in some way. In such instances an approach
sometimes followed is to "program around the problem", leading to further problems in all areas of system
performance, including possibly the undoing of some
important initial design concept unknowingly.
A further cause of program complexity is due to the
excessively "sophisticated," "elegant," "clever," or
"efficient" programmer. Most, if not all, . systems
operating today have sections that either never will
work quite properly or, if they do, dare not be modified
to meet new requirements, due to their initial implementation by a programmer with one of the above
attributes.
Poor implementation is a very common source of
bugs. The cost of finding and repairing problems caused
by poor implementation is so large as to make it quite
clear that proper project staffing, detail design reviews,
and strictly enforced unit test requirements are of
extreme importance.
A situation leading to the existence of a continually
high bug rate sometimes occurs when a product undergoes an evolution process in which new features are
introduced simultaneously with ongoing maintenance.
In such instances, synchronization between new features
and bug fixes becomes a problem. An approach sometimes encountered under these conditions is to create a
"safe" local environment by minimizing dependencies
upon other parts of the system, even to the extent of
creating duplicate or similar local tables, functions, etc.
The problems in future maintenance and modifications
are obvious.
2. Instability
1. Too Many Bugs
The reasons for an excessively high number of bugs
are many, including: (1) over-complex initial design;
(2) implementation not consistent with initial design;
(3) inappropriate implementation; and (4) uncontrolled
evolution. These points are elaborated upon below.
The design may be so complex that the system in
fact cannot be debugged. This complexity can be
introduced in a number of. ways. The initial design
concept may, for example, unduly require complex
module interactions, extensive time-dependent characteristics, multiple and non-obvious uses of the same
information by many parts of the system, etc.
Complexity can be introduced during modifications
following initial design if the initial implementors, or
the next generation of designers and implementors,
either cannot understand the initial design, cannot
The term "stability" will be used here to characterize the degree to which a job, once entered into the
system, will terminate only due to a user error, and
further, the effect of the user error is minimal (e.g.,
execution terminated, but files created to that time
are not lost). If a user's program frequently must be
rerun due to problems not of his own making, or if
the severity of the problem is not consistent with the
severity and probability of the error, then the system
may be said to be "unstable."
Instability was not a problem in the days prior to
multi-programming, as only one job was generally lost,
and a rerun usually was successful. In multi-programming batch systems even extreme instability could be
tolerated (and was) for a while, as a rerun often worked.
In time, however, more capable I/O devices such as
removable disks became available, with the attendant
need for extensive support software. The major stability
Organization for Successful Project Management
problem then became one of file creation and retention.
This problem remains in many systems.
With the advent of real-time and time-sharing systems,
stability has become much more important. In such
systems there are, typically, from 20 to 100 users
simultaneously somewhere in the processing cycle (in
core with the CPU, in core, swapped, etc.). Losing the
execution state, and possibly the files, of this many
programs, or of critical programs, is extremely serious.
The most significant factors affecting a system's
stability are the complexity of design and implementation, and the degree of attention paid by designers
and implementors to automatic system recovery. Even
good automatic recovery techniques cannot overcome
problems inherent in an over-complex system.
3. Unsatisfactory Performance
The performance of a system may be unsatisfactory
to the users. The performance of most batch systems
is not so bad that users consider it intolerable, though
it is still a major concern. The basic algorithms for
obtaining satisfactory batch throughput are basically not complex, but as batch systems attempt to
service an increasingly large community of hardware
and users, the simplicity possible disappears. Thus, the
major operating batch systems available vary widely
in design, and in classes of service performed well.
Batch systems with performance problems generally
are troubled with excessive overhead, complexity due
to the variety of user-types intended to service, difficulties in core management, and inadequate support
for large data bases.
In the time-sharing area there have been notable
instances where the performance was not what was
required. A number of reasons exist for performance
problems in time-sharing systems, for example, the
basic assumptions were over-ambitious, not well thought
out, or inadequately scoped (with modeling, for example). A more frequently epcountered cause of unsatisfactory performance in time-sharing systems is the
attempted retrofitting of a batch system to support
time-sharing users.
Schedule delays
The most frequent cause of a missed schedule is, of
course, the initial creation of an unrealistic schedule.
Other reasons, generally related to the first at least
implicitly, include ill-defined or missing requirements,
changes in baseline assumptions, the customer interface relation, plus many of the causes of product and
cost problems as described elsewhere in this section.
There are frequent instances in which the product
131
was initially ill-defined and underwent a process of
definition through its development. The conditions
under which the initial estimates were given often
change, including such changes in the available resources (money, skill, computer time). Requirements
to support new hardware previously unenvisioned are
often introduced.
The type of customer interface can have a major
effect upon schedule. The customer interface is defined
here as that person or persons who define, interpret,
and control all requirements that come from the
customer. The customer's relevant technical and
management experience, maturity, willingness to respond to suggested changes, understanding of problems,
and readiness to assist in achieving satisfactory mechanics of living together, are quite important. In
particular, it is extremely important that the customer
not require that all possible "bells and whistles" be
included in his product. He should be reasonable in
terms of tradeoffs, where considerable design and
implementation simplicity can· be gained by providing
somewhat less function to the user. The customer
must be convinced that simplified or limited functional
capabilities will often improve the eventual performance
and stability, and will increase the ability to add
future enhancements to the system.
Excessive costs
A major software development problem for the
developer, in addition to user-related problems, IS
cost. Major causes of cost over-run include:
1.
2.
3.
4.
5.
6.
Schedule Delays
Low Initial Estimates
Staffing Too Rapidly
Staffing With Quantity, Rather Than Quality
Follow-on Costs
Type of Contract
1. Schedule Delays
Delayed schedules generally lead to higher cost,
unless the developer had the foresight to see the
schedule was unrealistic and staffed according to a
reasonable schedule.
2. Low Initial Estimates
Some excellent techniques for estimating project
schedules and costs have been presented in the litera-
132
Spring Joint Computer Conference, 1972
ture. 6 Persons making schedule and cost estimates
must previously have been closely involved with
projects of similar size and complexity. They must
have accurate cost and progress summaries of the
previous projects. It is useful to know the original
estimates for previous projects, and eventual results.
The value of PERT-type techniques in making
initial estimates is limited, due to the lack of detail
concerning the project available at that time. A PERT
network or the equivalent should be constructed, however, even if only on a very gross scale, as a means for
forcing upon the estimators a mildly rigorous framework in which to place their estimates. Of particular
importance in ~he PERT are, of course, those things
that frequently lead to schedule problems. Foremost
among these are a knowledge of: (1) dependencies
outside the project; (2) the period required for initial
staffing, defining the organization, and other activities
required to have the people know what they are supposed to be doing, why, and when; and (3) those major
activities within the project which may proceed in
parallel, and which must proceed serially.
Machine time estimates are almost always underestimated, on projects of all sizes, and usually by a
large factor (two to four). Even when machine time
estimates are made by reasonable and experienced
people, they are often made invalid by the eventual
uncontrolled and wasteful manner in which the computer is used. Even today we find use of "block" or
"hands-on" time on large, fast machines. Unless
projects develop techniques for optimal use of computer time, including the support software required
to remove the need (except in rare cases) for hands-on
time, problems of cost, geographically separate computer installations, and inability to maintain schedules
will generally arise.
Some activities in project development can proceed
quite nicely in parallel by defining the major interfaces
early. For example, a compiler can often be developed
in parallel with an operating system, as its interface
needs are small. Similarly, applications design and
coding may often overlap development of the support
system.
3. Staffing Too Rapidly
Staffing a project is an important and complex
issue. There are never as many good people available
as a manager would like. A manager is aware that a
certain general level of manpower will be required to
do a job, and then the staffing search begins, trying to
identify people who are available, have relevant ex-
perience and skills, etc. Initial estimates that a project
will need a certain number of programmers should not
lead to the addition of "head count" simply to meet
predictions. In general; projects staff too quickly with
people anxious to produce code, and not quickly enough
nor with enough skill with managers and supporting
staffs (e.g., integration and test activities, described
later). Programmers are often brought on board in
order to start doing something before they really know
what to do. A good generalization is to always have the
minimum number of programmers possible on a project.
4. Staffiing With Quantity, Rather Than Quality
No matter how insensitive, trivial, simple, or straightforward a piece of code is to write, it will cost more,
often much more, if a poor programmer is given the
job. Sometimes the cost is hidden, perhaps for years,
but once programs "work" in some sense there is a
great reluctance to replace them, which tends to extend the life of some rather poor examples of the programmer's art.
In such complex areas as systems or real time software, unless there is a very large amount of review
talent available, people should not be brought onto the
project unless they are extremely skilled. (It can be
argued that this statement should be enlarged to include all types of programming.)
Relevant experience and resumes of people cannot be
considered the most important criteria for hiring. Extensive experience cannot overcome the lack of an
organized approach, insight, maturity in tradeoffs,
and a willingness to make very sure that a program
really works correctly.
It should not be assumed that key people will be
available through hiring, or transfer from other parts
of the company.
5. Follow-on Costs
Unrealistic estimates of follow-on costs after the
first release of a system are often made. Follow-on
costs may· include maintenance, enhancements due to
oversights in the initial product (frequently stability
and performance problems fall into this cateogry),
user enhancements required to stay competitive, a
need to support new hardware, etc. The larger a software system is the more reluctance there is to replace
it. Thus the product life may be long, with a fairly
continuous, and costly, development cycle.
Organization for Successful Project l\fIanagement
133
6. Type of Contract
The basic types of contracts are cost-plus fee (percentage of cost, award, incentive, etc.) and fixed price.
Virtually any type of contract is satisfactory if the
contract administrators on both sides are both knowledgeable and reasonable. Cost-plus contracts are felt
to be superior to fixed price contracts for all cases
except the (relatively rare) instances in which the
product, dependencies, etc., actually can be specified
in great detail. For example, the author has observed
in some detail a cost-plus contract with highly skilled
technical and management interfaces, and a fixed price
contract with a vague contract and inexperienced
interfaces. The cost-plus contract could have been
costly, but was not, due to the expertise of the contract
managers. The fixed price contract in theory limited
the cost, but in fact, due to extensive requirements
above the scope of the contract, resulted in contract
renegotiation, higher cost, schedule problems, ill will,
and eventual replacement of contract managers on
both sides.
There are, of course, instances of cost or product
problems in cost-plus contracts, if, for example, expensive and not necessarily talented personnel are
"dumped" onto the contract for profit and/or convenience. A sometimes-encountered problem in fixed
price contracts is a "buy-in," followed by either minimum possible contract interpretation or change of
scope. Again, experience and reasonableness on both
sides is required in order to prevent the contract type
from perhaps heavily contributing to cost and other
problems.
OPTIMAL 'PROJECT ORGANIZATION
This section describes a general project organization that assists in providing a check-and-balance
relation in a project that will contribute to project
visibility, control, and other factors important to
meeting project goals. This organization, and the
corresponding procedures of which examples are given,
is felt to have wide applicability, but is not, of course,
an exact model of any particular project. An organization will inevitably be shaped by the job to be done,
people available, company policies, etc.
This section discusses the following topics:
General Project Organization
Project Managers
Development Activities
Integration Activities
PROJECT
MANAGER
I
~DEVELOPMENT
DEVELOPMENT
~TASK 1
DEVELOPMENT
TASK 2
••
•
-~
DEBUGGING
TOOLS
PERFORMANCE
MEASUREMENT
TOOLS
DEP=NDEt\CY
CONSULTING
AND PROBLEM
DIAGNOSIS
···
I
INTEGRATION
I--
PROJECT TEST
-
TECHNICAL
REVIEW
---
TEST TOOL
GENERATION
-
BOOKKEEPING ~
TEST PLAN
GENERATION
-
INITI,\L
TESTING
~
TEST CASE
WRITING
-
PROBLEM
RESOLUTION
ANDlOR
IDENTIFICATION
r--
TEST CASE
EXECUTION
~
SCAFFOLDING
~
DEVELOPMENT
··
···
Figure 1-Project organization
Test Activities
Procedures
Staff and General Support Activities
General project organization
Figure 1 shows a project organization that it is felt
is generally applicable for a wide range of development
projects. Many of the functions shown in this figure
are not, of course, required precisely as shown in particular projects, but the major functions implied, or
their equivalent, are felt to be required in some form
for projects on the order of five people or more.
The key element of the figure, and indeed of this
paper, is the division of responsibility into separate
functional groups, such as those termed here Development, Integration, and Project Test. This division is
felt to be an absolute necessity. This division must
occur early enough in the project life so that each
functional group can adequately prepare.
134
Spring Joint Computer Conference, 1972
The following sections describe the Development, Integration, and Project Test groups in more detail. The
general responsibilities of these three groups are:
Development:
Integration:
Project Test:
Design, write, debug and unit
test new code.
Integrate all code. Be the project
"bookkeeper.' ,
Determine the status of integrated
code.
It is critical that people who are developing the product not be simultaneously responsible for all the bookkeeping functions, integration of new code, and confirmation that the integrated code works. The project
organization must be such that all groups have strong
technical people, and receive full support from the
project manager. Without an appropriate division of
responsibilities, and a corresponding set of procedures,
both visibility of true project status and control over
development are very difficult to achieve. Among the
typical problems that result are: not knowing what
code is really in a particular version of the system; and
a requirement to accept a programmer's statement for
the status of a module ("90 percent done, only a few
minor things don't work").
Project managers
The three levels of project management discussed
here are:
1. Project Manager
2. The Project Manager's Manager
3. First Level of Management Within the Project
One comment relative to all levels of management
should be made before going into further details.
Managers are assigned a responsibility, and must be
allowed to make decisions within their assigned responsibility without undue requirements to justify
their decisions. If a reasonable set of checks and
balances exists (e.g., Review Boards), and if the
managers chosen have appropriate experience and
judgment, then their scope of decision making should
not be frequently tampered with. Frequently no decision is worse than nearly any timely and moderately
rational decision.
1. Project Manager
The most important single person on a project is
the project manager. Therefore, choice of this person
should be made with appropriate care. There are a
wide variety of attributes that it is desirable to have
in a project manager, and a set of attributes that if
they exist in a project manager almost assuredly doom
the project to failure.
The project manager must be technically strong
enough to understand the important technical decisions made by those under him, to ask the rig~t
questions about those decisions, and to change them
if needed. In particular, he must be able to cause the
project to move toward realizable goals, and be able
to say "no" to impractical ideas, and enforce it.
The project manager must have both technical and
managerial maturity. All too often managers are chosen
on the basis of strong technical skills plus a desire to
be "promoted." Opposite extremes would be the assignment of a weak technical person to a managers role
because nobody else would put up with the customer
interface or personnel problems, or because the person
just happened to be available.
Another characteristic that must be contained within
the project manager is a desire to become involved. He
must manage the project, not simply spend occasional
time in reviews, believe all that is told him, and dilute
his activities with marketing for new business or other
company activities. It is always easier for a manager.
to assume that since good people are working in a
certain area, and everyone is working hard, the end
result will work out all right, and that he need not take
the time to dig into that area in detail. On reflection,
it almost always turns out that one or more areas do
not develop satisfactorily, regardless of the skill of
those most closely involved. Frequent reviews of design, implementation, test status, dependency status,
schedule milestones, etc., by the project manager, are
required.
It is not felt to be possible for a project manager to
be in some sense a "pure" manager, that is, manage
PERT charts, organization charts, staffing, facilities,
and so forth, and allow others to make the larger
technical decisions uninspected. This would rule out
software project managers whose experience is only
in other types of work.
2. The Project Manager' s Manager
In addition to the project manager being of appropriate technical and supervisory capability, it is
also critical that his immediate supervisor have relevant
experience, a set of both common and complementary
skills, and not be so sure of the project manager that an
independent check of status and problems is never
Organization for Successful Project Management
made. Every project manager needs someone reviewing his major decisions, a person to whom he may
bring problems and receive real help, and someone to
just talk to at times in order to remain objective about
his project.
3. First Level of Management Within the Project
A superior project manager can, with appropriate
organization and procedures, control up to 20-30
people satisfactorily with a set of managers reporting
to him that are really "technical task leaders" -strong
technical people with some supervisory capability,
each supervising 3-5 people. Above the 20-30 level,
however, support of full-time supervisory people
within the project is required.
Development activities
Figure 1 shows a number of possible functions to be
included within development. Many additional or
different functions exist, of course, for any particular
project. This is felt to be a reasonable example set,
however. The particular activities to be described in
this section are:
1.
2.
3.
4.
Major Development Function
Debugging Tools
Performance Measurement Tools
Dependency Consulting and Problem Diagnosis
Before beginning a discussion of the above, it should
be mentioned that this paper does not attempt to
discuss the merits of such very important development
considerations as: software specification or implementation languages; types of debug tools; tradeoffs
between speed, space, portability, flexibility, cost and
schedule; the value of formal proofs; etc. The emphasis
here is on functions that must somewhere be performed,
not how they are best performed.
Two characteristics of the development process that
frequently occur will first be briefly mentioned: the
effect of design changes during implementation; and
the occasional need to replace significant design or
implementation efforts. A great deal of interpretation·
of the initial high level design takes place during detailed design and implementation. If not carefully
controlled (via documentation and review) it is possible
to develop a product substantially different from and/
or inferior to that initially intended.
Occasionally it is realized that a significant mistake
was made in design or implementation. The tempta-
135
tion always exists to "live with it," "fix it up later,"
or "program around it." Generally such approaches
are a mistake-significant problems must be removed
when discovered, or at least a plan for their removal
created and begun. Too often the problems, if put off,
remain in the system for a long period of time and
cause far more difficulty than if remedied early.
1. Major Development Function
The major development function is, of course, responsibility for the overall design, detail design, debug,
checkout, and internal documentation activities required for product implementation. Worth mentioning
is the undesirability of fragmenting the responsibility
for this effort in a manner that results in a manager
with overall knowledge of the entire development not
having full control over work for which he is responsible.
2. Debugging Tools
The creation of debugging tools is a distinct programming task, with substantial requirements to be
defined, lead time needed for development, etc. In
general there remains far too much dependence upon
octal or hexadecimal dumps as the major aid to resolving difficult problems. Including appropriate (e.g.,
brief, symbolic) tools in a system initially is generally
inexpensive; adding them later is quite difficult.
3. Performance Measurement Tools
Performance measurement tools must be included
in development planning. This requirement needs
planning, lead time, etc. The capture and processing
of performance information is something that should
go on very early in a system, but often does not. Obtaining early indication of performance problems is
often critical, however, as their repair can require
major surgery.
4. Dependency Consulting and Problem Diagnosis
Programming projects usually have significant dependencies on areas outside their direct control, for
example, the hardware employed, support software,
and communications facilities. Where such dependencies
exist, it is best to assume that non-trivial problems will
occur, and place in the project appropriate skills to
isolate the problems and assist the appropriate support
group in their removal. Since such problems often arise
136
Spring Joint Computer Conference, 1972
due to misunderstandings resulting from inadequate
documentation, or perhaps just a complex dependency,
the ready availability of consulting assistance within
the project will be valuable.
Integration activities
Put briefly, this group's activities are to provide a
major portion of the independent control and visibility
of development activities that is required. The Integration Group lies or~anizationally between the Development Group and the Project Test Group. This
group receives new code from Development; integrates
the various pieces of new code received from Development; performs the bookkeeping tasks on detailed
status of all changes that have come in; assures proper
approval levels ; and other similar tasks, prior to passing
on a new release for testing.
The control over development resulting from this
sort of activity is obvious-nothing goes into the
system unless properly identified and approved, and
extensive documentation exists should the changes
need to be altered (or, in extreme cases, removed). The
visibility provided above an approach which has
Development personnel alone report on system status
is a bit less obvious, but critical. Development personnel
tend to be optimistic about their code, tend to report a
feature as fully provided even though only part of it
is done, and to otherwise exhibit human traits. Integrations' job is to be more hard-headed-something
is done only if the code was turned in, with appropriate
documentation (e.g., updated internals), and a repeatable test sequence (without which the change
is not accepted). Thus a project manager can know
exactly what is completed.
It is becoming more and more common in the industry
for the integration function to include very strong
technical people, for such purposes as: (1) providing
the ability to inspect new code submitted to the system
for general technical correctness; and (2) identifying
integration problems well enough to fix some, and if
not to provide good information to Development
people. If all the the project technical strength lies
in other groups, the Integration Group must always
borrow· technical resources from these other groups,
which they give up grUdgingly. An intermediate approach is to assign people from Development to each
new release, thus providing additional technical muscle
for integration activities.
Another important function of the Integration Group
is to perform some level of initial testing on the product
in order to assure that the major new functions will
work together and were integrated properly. Typically
a small set of regression tests is run by Integration to
assure that no major regressions have occurred prior
to approving a new system for more extensive testing.
In addition to the above principal activities, a number of other activities may be convenient to include in
the Integration Group. An item that may come under
Integration is one that is termed here "scaffolding
development." In the development of a new project
it is always required that some subset of the system be
generated first as an anchor on which the fuller system
can be developed, that some other system be used as
a vehicle for creating assemblies, load elements, etc.
The term "scaffolding" is used to define the set of code
and procedures that is developed to substitute for
missing interfaces or missing SUbsystems in order that
a partial system can run, or that phasing from one
system to another goes smoothly.
Enforcement of such standards or requirements
as linkage and naming conventions and memory utilization may also be conveniently performed by Integration.
Automated tools may help such activities.
Test activities
This section describes a series of testing levels, and
their place in the project organization. A fundamental
corollary of this section is the now (hopefully) clearly
established requirement that successful projects must
include: (1) early creation of test plans, procedures,
and staff; and (2) one or more groups established for
testing a product that are organizationally distinct
from and equal to the Development Group.
A testing approach that has proved quite successful
is one in which there are a number of separate and
distinct test activities, with minimal overlap, each
fulfilling a needed function. A possible set of testing
levels, chosen for purpose of example, is the following
five level set:
1. Unit Testing by Development programmers.
These tests show that the new function(s)
operate in a private environment. Development
managers must review the unit test plans in
detail, as a poor job at this level will be very
costly later.
2. Integration Tests, including rerunning of some
of the above unit tests, testing the ability of the
system to operate without major regression such
that the next testing phase can concentrate on
testing new code.
Organization for Successful Project Management
3. Project Test. This is the major test activity and
is discussed in more detail below. This group
runs extensive tests on new systems to confirm
that new features work.
4. Regression Test. In addition to testing that new
features work, one must also ensure that things
that used to work still do. This may be done
either within the project (e.g., by Project Test),
or by an organizationally separate group. The
regression testing activity differs somewhat from
Project Test activities in that: (1) the volume of
testing is larger; (2) the features tested are
generally more stable than the new features;
and (3) the regression testing group has more
lead time, better documentation, etc., than the
group testing new features, thus need not be
quite as good "detectives" to determine what
the new features really are.
5. Field Test. Regardless of the amount of prior
test, non-trivial bugs always exist in the final
release. For this reason a field test should be
scheduled, in which the new system is mounted
in one, or a few sites, and watched for a while,
prior to full release.
The Project Test Group normally performs the
following functions:
1. Test Tool Generation
2. Test Plan Generation
3. Test Case Writing
4. Test Execution
1. Test Tool Generation
Test tool generation requires both "hooks" in the
system, and programs to process and analyze the
results. To minimize the requirements for support upon
the Development Group, it is advisable to develop
test tools that are carefully designed to capture all
information that is likely to be useful, but impose
minimum space and complexity requirements upon the
system. These tools should not be the last functions
integrated. With early data definition, the required data
processing programs may be developed in parallel with
the system. Typical of the test tools that are required
for development of modern systems are a means to
easily and repeatedly run large series of programs. For
example, a common practice is to simulate a large
number of users in a time-sharing environment, with
137
input coming from precatalogued files rather than
on-line users, but seen by the system in a very similar
way. These "prestored" jobs may contain test programs, a sample of real user programs, or both. Information captured from these test tools should record
such information as is later needed to determine such
things as response times, if or not the output compares
on a line-by-line basis to previous runs, and so forth.
2. Test Plans
Extensive study of documentation and listings plus
detailed planning is required to develop a set of test
plans that may be reasonably executed and analyzed.
Test plans must include enough detail so test cases are
not written with dependencies on functions not yet
integrated. Among the many types of tests that must
exist are those for testing: functional capabilities;
stability; performance; fallback (the ability for a system to be replaced by an earlier release if it fails); and
the ability to support various hardware variations,
including degraded mode operations in which only a
subset of the hardware is available.
3. Test Case Generation
This is a difficult effort to do well if the test programs
themselves are to: (1) not produce more bugs than
they find; (2) efficiently and completely implement the
test specifications; and (3) be self checking to a large
degree.
4. Test Execution
Test execution includes the actual running of the
tests, creation of files used for later analysis to determine
if the tests ran properly, documentation of results,
getting the information back to the Development Group
and consulting on procedures used, and so forth. With
automated test tools this effort can be reduced very
significantly, with only a few people required to test
features not easily tested automatically.
Procedures
The type of procedures required to assist in providing
project control and visibility may be very large. This
paper does not attempt to give a detailed set of procedures. The following list, provided as an example,
gives information which would be expected to be
138
Spring Joint Computer Conference, 1972
submitted by all Development programmers when
their code is ready for Integration.
System level upon which the changes are based
System level intended for inclusion of the changes
Change identification
Change description
Listing of the changes
Card deck (or the equivalent)
Changed internal documentation
Changed operational documentation
Changed external documen tation
Dependencies upon other changes
Modules changed
Copy of the unit test passed to confirm unit
testing, and instructions for reproducing the test
results in the integrated system
Approval signatures
For an example of support software to aid in implementing procedures of the above type, see the CLEAR
system description of Reference 7.
A further example of a procedure usually needed is
an automated planning aid of some sort. There are a
number of reasons why a mechanized aid (such as
PERT) is useful. These include:
1. A common basis for discussing project status is
defined. Even if it is not quite everything that
would be desired, everybody gets used to using
it, and the shortcomings are overcome.
2. The mechanical difficulty of experimenting with
changes in work required, people available,
slipping dependencies, etc., is much less, as one
need change merely a few data cards and rerun
a program to get an initial feel for problems,
tradeoffs, etc.
To meet the above objectives, the scheduling aid
must have a number of attributes, including: (1) the
output must be prepared by computer, not the local
art department, as waiting a week to see the latest
chart makes the whole thing useless; (2) the input
preparation must be relatively simple; and (3) the
process must be flexible enough and closely enough
related to the projects' detailed activities to be a widely
usable day-to-day planning tool (for example, listings
should be produced that sort activities by start date,
end date, person assigned, release version, etc.).
Staff and general support activities
There are a variety of activities that must exist
within either the project or a supporting organization
that do not always fall neatly into the Development,
Integration or Project Test Groups. Those discussed
here are:
1.
2.
3.
4.
5.
6.
Staffing Assistance
Customer Interface and Support
Review Board
Operations Support
Documentation
Status, Cost and Schedule Data Collection,
Reporting
1. Staffing Assistance
In the early days of a project, when many people
must be interviewed, resumes must be reviewed, and
so forth, the project manager should not have to (and
cannot) do all the recruiting for the project. It is also
felt, however, that this job cannot be delegated completely to a personnel department. A good personnel
department can be very valuable by performing such
activities as obtaining candidate names and performing
initial screening for quality and relevant experience.
Technical men on the project must do all detailed
screening, recruiting and staffing for the project, however. This is a difficult job to do well, as people range
from uncommunicative geniuses to imposing charlatans.
Nevertheless, detailed interviews combined with extensive checkups of references can assist greatly in
minimizing the dead wood brought aboard. Realistically, it must be faced that more people must be
hired than are needed, as some will not work out and
must be discarded in short order.
2. Customer Interface and Support
A major element of the customer interface must, of
course, be the project manager himself. This is so since
he alone is responsible for the project, and therefore
only he (or hjs manager, but hopefully not independently) can commit the project. It is often the case,
however, that there is a need for frequent discussions
between vadous people within the project and within
the marketing organization, or other organizations
working with the project, such that a continuous and
heavy transmission of information back and forth
across the project interface must exist. The project
manager is generally too busy to both perform this
Organization for Successful Project Management
function and manage the project, so it is wise to set up
a small group, perhaps one person, reporting to the
project manager, to provide a continually available
interface to the customer. This may include such
customer support functions as assisting in preparation
of rough external documentation and/ or proposals
for the customer, looking in advance at conversion
problems when the system becomes operational, etc.
A further important role of the customer interface
may be one of providing appropriate visibility concerning progress and problems. It is fairly easy for a
project manager and a customer to both be working
hard and think the other one knows what each is
doing, but to discover that in fact major differences of
opinion occur. A good interface can reduce these
problems.
3. Review Board
A review board should be established that includes
people who are generally not assigned full time to the
project, but remain cognizant of technical activities
going on in the project through their continuous participation on the board. This board includes senior
technical people from wherever is appropriate. The
purpose of this review board is to review major decisions either already made or that must be made before
going on. This helps assure that all relevant experience
available is brought to bear. Items reviewed should be
of both technical and administrative (e.g., cost, schedule) nature.
4. Operations Support
Computer operators need someone to call on for help
occasionally, efficient machine room procedures need
to be developed that are generally rather different in
project development from those in a typical production
shop, etc.
139
people who must run the computer center, documentation for user managers, training documentation, etc.
One of the major unsolved problems of the computer
industry is the creation of appropriate documentation,
at a reasonable cost. It always seems to get done
eventually, but is always painful to the programming
staff, and not infrequently to users.
6. Status, Cost and Schedule Data Collection, Reporting
Projects sometimes begin with good procedures in
place for creation of status, cost and schedule collectio n,
etc., but as time goes on less and less use is made of such
procedures. A frequent cause is the lack of staff to
regularly collect and report upon the data collected.
This can be a substantial job, but if done properly
provides management with early indications of potential trouble areas.
SUMMARY
The proper management of programming projects
requires means for visibility and control. To know
what is actually going on in a project, to not have
critical path activities slip, to head off such difficult-tosolve problems as memory over-use and slow performance, and with all this to meet a tight schedule and
budget, is a challenge met by few. The primary attributes that must be contained in a project to provide
good visibility and control are:
1. Division of responsibility in a manner that gives
good checks and balances (separate groups for
Development, Integration and Test).
2. A large set of procedures, rigidly enforced, that
supplement the above organization by forcing
an automatic flow of information.
3. Managers, supervisors, and task leaders at all
levels that have good technical judgment, and
will "dig" to find out the true status of all work.
5. Documentation
REFERENCES
Documentation is always a problem, both where to
place it organizationally as well as who should do it.
There is a very wide variety of types of documentation
to be done, usually far more than is obvious at budget
time. Among the major types are, of course, the internal
documentation for the system (usually done in Development, with the support from elsewhere). Another obvious type is the external documentation for the user.
There is also the question of documentation to support
1 C KING
Systems analysis and project management
McGraw-Hill Book Company New York 1968 p 255
2 ME CONWAY
Datamation Vol 14 No 4 April 1968 pp 28-32
3 R H KAY
The management and organization of large scale software
development projects
AFIPS Conference Proceedings Volume 34 1969 SJCC
pp 425-433
140
Spring Joint Computer Conference, 1972
4 R W BEMER
Manageable software engineering
Software Engineering Volume 1 Computer and Information
Sciences Academic Press 1970
5 R W BE MER
Checklist for planning software system production
NATO Conference Software Engineering Report on
Conference 1968 pp 165-180
6 J E ARON
Estimating resources for large programming systems
NATO Conference Software Engineering Report on
Conference 1969 pp 68-79
7 H M BROWN
Support software for large systems
NATO Conference Engineering Report on Conference 1969
pp 53-60
Commercial data processing machines in
government applications
byJ. D. ARON
IBM Federal Systems Divisi'.Jn
Gaithersburg, Maryland
BENEFITS OF USING COMMERCIAL
HARDWARE
INTRODUCTION
When a major military weapons system is designed,
it is often so far ahead of the then current commercial
technology that special approaches are needed to make
the system feasible. This has led to the development
of many special purpose computing systems as components of large government procurements. But special
purpose hardware is often too complex to be built on
normal schedules; furthermore, the software to go with
it must be deferred until the special machine is finished.
The sequential nature of the hardware/software development cycle means that any slip in the schedule of
either element directly affects the total system schedule.
One obvious way to avoid cost and schedule problems
due to spec:al purpose computing systems is to substitute commercially available computng systems for
them.
There is a lag of some 3-5 years between the specification of a major government application and the
detailed design of related non-government systems.
Dur'ng this period, the hardware and software designs
of the computing industry generally incorporate the
special characteristics of the government system for
their standard product line. By the time the government system goes into operation, contemporary commercial systems have caught up. Thus, the convergence
of government and commerc'al needs is leading to
standard computing systems which meet all but a few
of the needs of the special military and federal civilian
applications. In those cases where the commercial system
is totally responsive to the requirements of the special
system, it offers sufficient benefits to recommend it in
preference to special purpose hardware. In other cases
where the commercial offerings are only partly responsive, there are still significant advantages to the use of
commercial systems (modified as necessary) to be
evaluated by the system manager.
Salient benefits
The benefits of using commercial hardware depend
on which elements of the system design have the highest
priority in the mind of the user. For instance, in evaluating commercial data processing alternatives for the
SAFEGUARD system, the Army l:sted five system
characteristics in relative order of importance and
weighted them to emphasize the ranking. Performance,
including throughput and some aspects of reliability,
carried 40 percent of the weight. Product Deliverability
was next in importance, followed closely by Implementation Risk. Some 10 percent of the weight was
assigned to Growth Potential and Cost carried a
nominal 5 percent. Commercial alternatives will score
very high in the last four characteristics. Will they stand
up in Performance? Probably, yes. The computing
performance of general purpose mach'nes has been
growing by an order of magnitUde every five years.
There is no sign that the growth will stop.
The commercial computer approach is strongly
enhanced by the availability of compatible families.
This feature of the commercial market was introduced
in a limited way in 1962. Taking advantage of this, for
instance, the USAF Command Post Project 473L was
able to install an IBM 1401 computer very early in the
system design stage to test out concepts related to disk
storage and display consoles. Later, as the workload
on this facility grew, the 1401 was replaced by the
larger 1410 without substantially altering the system.
Through the emulation capabilities of the third generation S/360, some of the original 473L programs could
still be used after the 1410 reached the limit of its
utility. Most manufacturers now offer commercial families of compatible machines. The same degree of com141
142
Spring Joint Computer Conference, 1972
patibility is seldom offered in the special purpose computer market for simple economic reasons: neither the
buyer nor the vendor has a cost justification for developing any features other than those directly applicable to
the special application. Consequently, there is less
growth capability in special purpose machines procured
for military systems than there is in the standard commercial product line of a given manufacturer.
Referring again to 473L, the use of the 1401 as an
interim test bed illustrates a common aspect of the
system development process. In order to make progress
on the overall system it is important to overlap many
activities. Programming, as an example, will proceed
while the hardware is still being built. In 473L it was
necessary to create a simulator of the Librascope
L-3055 computer, specially procured for the project.
The simulator ran on a commercial 709 located in the
programming facility. By using the simulator, the
programmers were shielded from delivery delays in
the L-3055.
The rigid product test protocols observed by most
manufacturers further increase the confidence that
commercial machines will perform according to their
advertised parameters. The risk, as has occurred on
special procurements, that a computer will be delivered with some of its instruction set still undefined
and perhaps not included in the circuitry is negligible
with commerical machines.
If the performance and reliability of commerc'al
machines are sufficient to justify their use to the systems engineers who design the military and federal
civilian systems, then the software support available
with the machines should throw the decision well over
in favor of the commercial product. Sof~ware, which
includes development aids as well as the deliverable computer programs, has become the most difficult aspect of
large systems to plan and control. Project management
is generally unfamiliar with the nature of software and
lacks the experience to estimate and schedule the programming effort accurately; However, since a data
processing system is a package of hardware and :~dt
ware, in which the software is the only feature directly
accessible to the user, the system cannot be completed
until the software has satisfactorily passed its tests.
It is specifically in the area of software that commercial
machines have a marked advantage over special purpose implementations.
Vendor software, available with the first delivery of
machines, normally includes a basic operating system
which controls the hardware function and facilitates
the preparation and execution of user programs. In
addition, the vendor supplies a. variety of language
processors: basic assembly· language for manipulating
the hardware instruction set, higher level languages
such as FORTRAN, Algol, COBOL, JOVIAL, and
PL/1 for application programs, and simulation languages such GPSS and SIMSCRIPT for building
models. The higher level languages are easier to use
than the basic assembly language and speed up the
development effort. The languages have the added
benefit that they are easy to learn and can be transf erred from one machine to another with relative ease.
The advantages of higher level languages are so selfevident that some have been written to run on special
purpose processors. But the resources applied by the
general purpose machine manufacturer to come up
with a comprehensive efficient high language processor
are too extensive to be duplicated on each special
processor. The result is most often a l'mited subset of
the full language and an inefficient compiler.
This 1ast point, when extended to cover additional
areas of vendor support and product enhancement,
emphasizes one more significant benefit of commercial
machines : Commercial systems are usually less expensive
because they ach"'eve economies of scale inaccessible to
special products.
Characteristics of applications of interest
There are three general classes of government applications which can be identified according to the stringency
of their unique requirements:
Class I-Problems such as inventory management, management information systems, finance
and accounting, etc., which are performed daily
or less often in an office environment.
Class II-Problems such as assisting commanders in operational situations or controlling
weapons and space missions. An office environment
with special security, reliability, and availability
provisions is required in fixed installations. Installations in aircraft or ships may call for special
equipment.
Class III-Problems such as air navigation,
weapons guidance, or space veh:cle maneuver
control in an environment in which temperatures
and other physical parameters can vary widely
and where the computing element may have to be
shaped so as to fit into a small space. Reliability
must be very high and maintenance may be impractical once the mission has started.
Class I problems are normally handled by commercial
hardware. Class II problems are dominated by the
Commercial Data Processing Machines in Government Applications
environmental constraints and are normally handled
by special hardware*. Class II problems, which are
the primary subject of this paper, present the opportunity for tradeoffs between special and standard
hardware. The typical tradeoff to be made is whether
to place a specially designed machine in an uncontrolled
field environment or to create a ,spec'ally designed
controlled environment in which to place a commercial
machine. The commercial machine approach is most
appropriate for fixed installations at headquarters
locations and for transportable facilities in vehicular
vans and airlift pods. The decision can swing either way
for ship and submar~ne installations. The airborne
case will almost always call for special hardware to
meet space and weight constraints.
The SAFEG UARD advanced ballistic missile defense system falls in the second class. So do Air Traffic
Control and the ground support for the Apollo manned
space flight system. In each case there is a need for
large capacity storage, fast computation, versatile
input/ output devices, communication with other systems, high availability, and the flexibility to respond
to changing workload requirements.
Performance
No effective measure of computer performance
has been developed that applies to more than one
situation; therefore, it is common to describe performance requirements by the arbitrary value of the instruction execution time. The lack of other throughput
requirements is usually due to the inability of the
system designers to anticipate the effect on throughput
of interactions among the programs in the job stream.
At best, the designers can lay down specifications for
system throughput based on the real time requirements
of one critical activity. Most of the complex systems of
interest to the government involve many related
activities; e.g., the relations between radar data and
aircraft tracks and between aircraft tracks and flight
plans and between aircraft tracks and traffic control
procedures. The relationships cannot be unravelled so
that the system design requires all of the computing
to be done on a single computer configuration t where
all the related information is available at the same time.
While it may be useful to categorize machines based
on a single parameter, selection of a machine for a
particular application should be based on a more
* Some Class III problems require so many identical computers
that economies of scale can be realized.
t Which may contain multiple OPUs.
143
thorough analysis of its capability to handle the
specifics of the job. The selection of computer hardware
should be one of the last things done in the design
phase. Premature selection will force the designers to
distort the rest of the system to conform to the computer. Problem definition, workload sizing, allowable
computing overlaps, deferrable computations, absolute
real-time deadlines, I/O rates, and other job descriptors should be determined first. Then a balanced
computer configuration can be selected (using a gross
model for timing and storage evaluation) which will
do the job. If this policy is followed, the lead time for
computer delivery will be compressed.
There are very few performance requirements that
cannot be handled by off-the-shelf hardware. The per-
formance criteria in which commercial machines exceed
the capabilities of most special purpose machines include:
1. Range of speeds available for a family of central
processors;
2. Range of memory capacity for a given processor
or family of processors;
3. Number and diversity of input/output devices
available.
• card handling equipment
• printers
• typewriters and teletypewriter terminals
• displays and plotters
• communications adapters
• tapes
• disk units
• drum units
• on-line sensors and output controllers
• other computers
4. number of computer programs available
• to support the machine operations
• to support programmers
• to solve problems
• to support terminal users
• to support system analysts
A characteristic of a commercial product line is the
way in which the above facilities are coordinated so
that a large number of possible configurations of the
system can be used efficiently. In the typical special
processor whatever support is provided in the way of
balanced performance or software support is optimized
around the original problem statement and may be
somewhat clumsy when used for a variation of the
problem or for a different problem.
144
Spring Joint Computer Conference, 1972
The areas in which commercial and special machines
can be roughly the same include:
1. Ability to multiprogram (time-share more than
one program at a time);
2. Ability to multiprocess (run one problem on
more than one computer to share the load) ;
3. Ability to handle real-time inputs;
4. Ability to connect redundant system elements
through cross-channel switches;
,
5. Ability to interface with special processors of a
different type;
6. Ability to nterface with special input/output
devices.
The fact that commercial market requirements have
grown to include these features makes the standard
products highly competitive with special machines.
However. there are performance limitations in many
commercial machines which can be avoided in special
machines at the expense of balanced machine operation.
The areas in which special purpose processors can be
superior include:
1. Instantaneous speed of input/output (bits per
second per channel);
2. Maximum capacity of I/O channels (bits per
second for all channels taken together);
3. Interference between memory cycles and I/O
cycles;
4. Ability to do parallel processing (run many
copies of the same program at once);
5. Do self-diagnosis and error correction.
With few exceptions, the special purpose processors
used in military and federal civilian applications were
built by the same people who build the commercial
products. Therefore, there is no technical reason why
the same capabilities could not be offered by them in
their standard product line. Their decision not to make
such products available is an economic decision.
Software and compatibility
As mentioned earlier, the computer programs required to construct and operate a complex system are
beginning to dominate the project. Not only are the
costs, as a proportion of project cost, increasing but
the schedule impact of software development is being
felt in later operational dates. The larger the programming task is, the more severe the impact is. In order
to shorten the overall development schedule two steps
are recommended:
1. Use existing tested software where applicable.
2. Build and test programs in parallel with other
elements of the project.
These steps are facilitated by the use of commercial
machjnes because the vendor can supply a library of
tested support programs. Commercial test machines
compatible with the proposed operational computer
can also be obtained. The library of software for commercial machines extends beyond basic operating
systems, languages, and utilities. Information handling
systems which assist the user build and maintain files
as well as query them are offered in versions which stress
speed of retrieval and versions which provide great
file handling flexibility at slower speeds. Management
control support programs can be obtained which
process project activity network data. Mathematical
and statistical routines, output display formatters and
report generators, flowchart programs, and various
aids to the programmer are also found in vendor
libraries. *
The process of programming consists of designing the
logical set of steps to solve a problem and then coding
and testing the steps. Both logical design and coding
are subject to error; the errors, or "bugs" are detected
by running program segments with test data. As the
programmer finds and corrects the bugs he then repeats
the process of design, code and test until his unit of
programming is correct. Later his unit will be integrated
with the programs written by others and the group of
programs will be tested against the system specification.
Without exception, additional errors will be detected
at this point. However, it is not clear whether the new
error is due to a faulty program unit, a faulty test case,
a machine error, an operator's mistake, or a faulty
system spec. Therefore, the analysis of the error involves a great deal of trial and error and a lot of machine time. It is very important that this process be
carried out on a machine which acts exactly the way the
final operational system will act if all the errors are to
be found. Thus, the machine used by the programmers
for debugging their program units should ideally be
compatible with the machine in the operational system.
Programmers need large blocks of uninterrupted
computer time. Rather than sharing an engineering
prototype, programmers want their own machine that
will let them get started on productive work at the
earliest possible time.
* Modern libraries include programs from many sources; some are
available at no charge, others are sold, leased, or licensed.
Commercial Data Processing Machinoes in Government Applications
Carrying this concept one step further, many programming managers are examining methods for increasing programmer productivity bygjving the programmer better access to a computer and by giving
him better tools at the computer. The access problem
is addressed by installing a time-sharing system which
allows the programmer to do his work at a terminal,
cutting out the middlemen in the computer facility. *
The tools question is addressed by providing programs
to maintain the programmer's library and history files.
With these tools, the programmer can create test data
files, program files, and command files so that he can
invoke a set of commands to execute a set of programs
against specified test data. He can do this without
handling any of the input data more than once, saving
himself a lot of paperwork and a lot of running back
and forth to the machine room. When the machine
he is using is compatible with the final operational
machine, it is a simple matter to transfer the set of
completed work to the operational system to signify
that he is done. When the final machine is different,
there is an extensive requirement for translation, reprogramming, and retesting before the program can
be accepted for the final system. In other words, the
compatibility of the support machine with the final
machine shortens the time and lowers the cost of producing
a final version of the programming system.
The benefits of the compatibility concept carryover
to the operational system in some instances. Several
government systems have been specified in such a way
as to have all programming done at a central point. In
TACFIRE, an Army artillery fire control system, the
programming was to be done in the U.S. and shipped
to tactical installations at field locations around the
world. The programs, written in PL/1, would be
debugged and tested on a commercial machine in the
U.S. using a compiler modified so as to create output
programs in the language of the field machines. Under
these conditions, it must be assumed that no changes
of any type were to be made to the programs in the
field. Such a system is feasible but is more difficult to
manage than one in which the ability to make a change
in the field exists. Compatibility between the base
machine and the field machines would provide that
option in systems similar to T ACFIRE.
A considerable advantage of commercial machines
for the fast startup of a project and for the installation
of the initial capability lies in the ease of training the
project staff to use the equipment. The likelihood that
* For simple debugging, the time-sharing system may look like a
subset of the operational machine. The use of "virtual machines"
can eliminate this restriction if required.
145
trained personnel can be hired to use commercial
machines is high and getting hIgher as schools add data
processing courses to their curricula. The likelihood
that trained people exist for a special purpose machine
is nil. Furthermore, the nature of the training for a
commercial machine is identical to that offered by the
vendor or any number of independent computer training
schools. The training program for a special purpose
processor is almost always unique and may be unsuitable for teaching institutions. The corollary of the
training problem is that many people are willing to
work on a general purpose machine whereas they are
reluctant to accept employment to work on a unique
machine. Their reasons are tied to their future career
plans. Employment history shows that a computer
engineer or programmer has more opportunities for
advancement when he is in the main stream of the
industry that when he is associated with a special
purpose one-of-a-kind system.
Hardware and compatibility
There are several other factors affecting the specifications of military and federal civilian systems. Some
are spurious; for instance, it is not unknown for a buyer
to specify an advanced componentry because it is newnot because it is essential. This was common during
the transition from vacuum tubes to transistors. Although such a spec may have been necessary to achieve
a performance objective, in some situations it simply
increased the risk of on-time delivery. Other specs are
more significant because they reduce the system cost
and reduce the complexity of the system both functionally and operationally. An example is the specification of a standard interface for connecting input/
output devices to the computer. At the many Air
Force and NASA ranges, for instance, there was a proliferation of special sensors to track rockets and aircraft and to process communications from space vehicles
and from remote tracking stations. Acquired at different times for different purposes, the sensors had a
wide variety of interfaces. Consequently, when it became evident that unified range operations would improve the support provided to all range users, a whole
new set of "black boxes" had to be acquired to connect the sensors into the common network. In this respect, commercial machines are ahead of the government. Standard interfaces that allow off-the-shelf
equipment of one manufacturer to interface with that
of another manufacturer are the norm. Vendor specifications of their standard interface in terms of wiring
diagrams and voltage levels are readily available so
146
8pring Joint Computer Conference, 1972
that it is reasonably easy to procure peripheral devices
that meet the standard. This facilitates the use of other
vendors' devices and permits the attachment of special
purpose sensor and control devices to the central computer. The result is a capacity for horizontal growth.
Manufacturers provide for vertical growth by designing a compatible family which includes central
computers of various speeds. Thus, the IBM 8/360
line provides for compatible processors (each capable
of reading the same programs and handling the same
input/output records) that can handle anywhere from
5.33 bits per microsecond to 2370.37 bits per microsecond. While the bits per microsecond do not relate
directly to performance, they do give a feel for the very
wide range of capability found in a compatible family.
Additional vertical growth can be obtained by increasing
the amount of storage available on the central computer. This contributes to throughput by reducing the
amount of traffic between the central computer and the
auxiliary storage devices. Here, too, the range is
enormous running from a few thousand characters to
several million characters of storage in the same family.
An analysis of the combined computational and information handling capability of a line such as the 8/360
shows a ratio of overall performance of 36 X 106 between the very large 8/360-195 and the very small
8/360-20. More realistically, there is a range of two
orders of magnitude in the performance of the Model
195 versus the Model 65 which would be a typical
development support machine for the large processor.
The existence of compatible families of commercial
machines permits the installation of a small machine
for which complete software support will be available
in more or less the same form as the support for a larger
version of the machine so that the scaffolding developed
around the small machine is directly transferrable to
its successor. Thus, maximum use can be made of commercial components early in the schedule without compromising the flexibility of the system design.
Reliability and serviceability
Under the topic of reliability and serviceability are
included considerations of availability (is the machine
ready when requested?), reliability (does the machine
function correctly?), maintainability (how long does
it take to service and repair?), and modifiability (how
easy is it to add a feature to correct a recurrent problem?). In engineering terms, these characteristics are
often provided by redundant facilities. In some machines, the redundancy is built into each box by repeating circuits twice or three times. More commonly,
the system as a whole is redundant with more than
one processor connected through cross-channel switches
to multiple copies of the input/output devices. When
one element fails or deteriorates, it is removed from
the system for maintenance and the rest of the system
continues to operate. The level of redundancy is established so that the remaining equipment can handle
the entire application (fail-safe) or some subset of the
application (fail-soft). In addition, the software is
designed to permit frequent checkpoints which copy
the status of the machine so that, if a subsequent error
occurs, the program can back up to the checkpoint
and restart with correct data. The time required for
automatic restart is small compared to the repair time
of the machine and, in fact, the operator may not even
notice that an interruption occurred. The ability to do
these things was developed on special purpose machines
but is now generally available on all major commercial machines.
The reliability which is demanded of individual
units of equipment may exceed the design ljmits of
commercial hardware. This degree of reliability, however, may be somewhat unrealistic. Enemy action,
failure of sensors, or natural catastrophe might cause
a system failure quite independent of the condition of
the individual system elements. For instance, suppose
an air traffic control system were based on data from
satellite-borne sensors passed to the ground through a
communications ground station. In principle, one
ground station would suffice for the system. In practice,
one ground station is inadequate because it could be
put out of action by an earthquake, fire, aircraft accident, broken transmission line, etc. At least two
ground stations are needed to make the system reliable.
The additional ground stations could share the system
workload or could act as backup for the prime station.
In each station there could be a duplex or multiprocessor computer to increase its availability. Now the
system as a whole is more likely to work properly than
if there were only one station regardless of the reliability
of the individual units in the single ground station.
Thus, although commercial machines fail to meet the
initial hardware specs of many special applications, the
need for these restrictive reliability standards can be
called into question in those applications where system
reliability results from good system design.
Component technology in commercial hardware
equals or exceeds the performance called for in contemporary special hardware. The large volume of the commercial vendors had led to the development of mass
production techniques for componentry which have a
high yield at very low cost. The comparable process
technology for special components would require the
same initial development expense without the equivalent product base against which to amortize the cost. A
Commercial Data Processing Machines in Government Applications
related benefit of mass production is that the lifetime in
the field for a given family of components is quite high.
This makes it economically feasible for a manufacturer
to continue to produce spare parts for that component
family long after new production of the machine is
terminated.
The fact that commercial hardware does use production quantity components leads to a very high
degree of standardization with the system. The number
of different parts used is generally held down to facilitate
the logistics of resupplying the field maintenance staff.
A great deal of effort goes into making the system simple
to maintain: extensive diagnostic aids are provided,
pluggable replacement assemblies of optimum cost
(trading off repair versus throwaway) are designed,
multiple sourcing for parts is planned, training material
is designed to be explicit yet easy to learn and understand, machines are assembled for easy access to
components, etc. Commercial machines are built,
wherever possible, to use standard power sources and
to place a minimum burden on the user for special
office conditions or construction. The commercial
system development cycle includes the preparation
of training programs for maintenance people as well
as engineers and programmers. In most cases, a pool of
experienced maintenance people exists at the time of
delivery of the first field machine. Similarly, a large
and adequate stock of spare parts and replacement
units is placed on the shelf to meet the needs of the users.
The byproducts of mass production are not obtained
in special purpose computers. Here, reliability is obtained by more careful parts inspection, by designing
for larger margins of safety, and by continujng operation while minor repairs are in progress. The degree of
reliability achieved approaches that desired as close as
the buyer's budget permits. The net result is that, in
area~ of service and reliability, the commercial standard
is very high and, although not higher than what the
government buyer wants, it is often a good deal higher
than what he ends up buying.
Flexibility
The use of standards to improve the general purpose
product could restrict the flexibility of commercial
systems. Fortunately, this has not occurred. The
standards normally apply to components and interfaces
in such a way that system modification is quite easy.
This can be observed in applications where one aspect
of the problem must be processed at a much faster rate
than other aspects. As an example, a communications
satellite may store data received as it travels around
the globe and then spew it out all at once when it
147
passes over a receiving station near its home base. The
data must be accepted when the satellite is overhead
because there will never be another opportunity to
pick up the message. In this case, commercial machines
can still be applied as, indeed, they are. A special input
buffer is required to collect and hold the satellite output; the buffer is a very high speed recorder. Then, at
computer speed, the buffer transfers the data to the
computer. In some instances, such as at missile ranges
where the data stream is to be sampled before it is
analyzed, the buffer may do a limited amount of data
screening, editing, and summarizing before transferring
the stream to the computer. This combination of an
"intelligent channel" with a computer is a special case
of the commercial machines' ability to interface with
special I/O devices. When the input stream exceeds
the computer capacity for extended periods of time,
it is necessary to replace the computer with a higher
speed processor. In practice, this requirement occurs
with both commercial and special processors; however,
the replacement is often more practical with commercial machines from compatible families.
In those problems that call for a parallel processor,
several options are available. Very few problems are
so well structured that, at all times, they can be subdivided into exactly the same number of identical
computations. Thus, a machine like the Illiac which
provides 64 parallel processors may be fully utilized
only when a 64 part problem is being processed. Most
problems involve some serial processes in addition to
the parallel processes. For instance, in a system which
analyzes seismic data to detect earthquake events, the
process may start with some housekeeping to set up
the input record format and allocate some memory
locations to the results of the analysis. Then, by applying a transform algorithm to the input data the
results can be computed and stored in the allocated
space. The frequency with which the computer is asked
to compute the transform may be small in the light
of other jobs to be done in the facility. Therefore, instead of buying a parallel computer, the project manager will consider augmenting a standard commercial
machine with a low cost Fast Fourier Analyzer box
that attaches to an input channel of his computer.
The speed of the FFA is only used for FFA problems;
the rest of the time it is ignored.
LIMITATION OF COMMERCIAL HARDWARE
The advantages listed above are not without limits.
Several limiting features of commercial machines have
been mentioned but bear repeating. Others related to
commercial business practice are also relevant.
148
Spring Joint Computer Conference, 1972
Environment
A typical office environment implies a room with air
conditioning and good janitorial services, plenty of
enclosed storage space, space for maintenance people,
etc. Such facilities are often available for military
systems even when the room is inside a bombproof
shelter. When the computer is in a properly shielded
environment, a special effort to "harden" the computer against shock, vibration, fungus, vermin, dirt,
electromagnetic and nuclear radiation, etc., is redundant. On the other hand, some machines are meant
to be used on board ships, in jeeps, in aircraft, in remote locations without normal stateside services, etc.
In these cases, the hardware itself may be designed
to be protected against the hostile environment. The
hardening takes the form of specially built components
which, in general, cost more than those used in commercial products; therefore they are not found in offthe-shelf equipment except for the machines aimed at
the process control market (steel mills, paper mills,
refineries, etc).
It has been demonstrated many times that commercial hardware can be installed in military vehicles
so that it can be transported without damage and can
be operated in the vehicle given an appropriate enclosure. Transportability requirements are not uniform, however, and the degree of transportability
varies from machine to machine. The most powerful
machines tend to exceed the floor area of one van.
Certain general trends have improved the ability of
the industry to build transportable machines: smaller
boxes that are easier to place in a vehicle, more liberal
temperature ranges, etc. These features are evident in
the reduction of setup time for a commercial machine.
In the 1950s a week was allowed to assemble a large
computer and check out the problems that may have
occurred in the move via padded van from the factory.
In 1970, a day or two is all that is required with very
few problems introduced by the transport. When the
same machine is to be placed in a van-as has been
done in the Army CS-3 system-some additional precautions are required. Most of them are mechanical.
Stiffening of the cabinets and the movable panels in
the machines may be required to reduce the effects of
shock and vibration. The whole machine may be
mounted on shock absorbers to shield it from the environment. And a short checkout cycle may be added
to the set-up procedure after the van comes to a stop
and the machine is turned on. In general, the commercial machine is not operated while the transport is
moving (except on board ship).
The input/output devices for the commercial market
present a more severe problem in transportable systems. They are primarily mechanical devices with
sensitive alignment and close tolerances between high
speed moving parts. They do not stand up as well as
the electronic computer. It is normal for the project
manager to substitute militarized I/O devices for the
commercial products in transportable installations.
Specially designed disk and tapes have been built for
this purpose and, by virtue of the standard interface
concept, can be attached to a variety of computers. A
transportable system can consist of all off-the-sl:elf
hardware or a combination of standard processors and
special peripheral devices. Thus, it is not essential to
assume that all elements of a military system must be
hardened. If a commercial machine is the best one for
the application, it can often be installed in such a way
as to be protected from the environment.
When it comes to the third class of applications
where the environment is so hostile that special hardening is required, the commercial machines are no
longer feasible. Machines in Class III are usually very
small both physically and functionally. They are built
to fit into odd-shaped spaces. They weigh very little.
Their word sizes and instruction sets are smaller than
those offered in commercial machines. Their input and
output devices may bear no resemblance at all to the
cards, tapes, and disks found in larger information
handling systems. As an example, the computer in a
space vehicle may be used only to calculate orbital
rendezvous parameters or descent speeds and angles.
Its inputs may be from instruments in the cockpit of
the capsule; instruments used nowhere else except in
this particular space mission. Its size may be that of a
home tape recorder to permit it to fit in the astronaut's
console. Its memory may be only large enough for a
single computation; a new computation may require
reloading of the memory by radio from an earth station.
The computations it performs may be so well worked
out in advance that the magnitUdes of all the numbers
in the computations are known; therefore, there is no
need for floating point instructions in the repertoire
of the computer. The programs are probably written
and optimized in machine language so as to take as
little memory as possible; therefore, no high level
language compiler or massive operating system is
called for. All these features tend to make the general
purpose capabilities of commercial hardware and software unnecessary for the space computer. In fact, the
bulk represented by the standard features of commercial hardware is undesirable in the space computer.
On the other hand, it is essential that the space computer work when it is needed. This leads to a high
degree of redundancy in the design of the system in
Commercial Data Processing Machines in Government Applications
order to increase the reliability, availability, and failsafe characteristics of the system. Since, in the example
of the space capsule, there is no practical way to maintain or repair the computer, it is possible to design the
computer to be discarded on failure and replaced by a
spare. Obviously, the priorities for a system of this
type are quite different from those set for commercial
computers. These priorities make specialization an
asset in the third class of application where it is a penalty
in the other two classes.
On the other hand, some applications in Class II
call for the same environment as Class III even though
they require the functional capabilities of Class II
machines and programs. Examples are surface and
undersea naval applications, airborne applications or
airborne back-up for ground based systems, and long
duration manned space laboratory missions. Some of
the applicable specifications might be:
1. Dimensions - 26" X 48" X 66" for passage
through watertight hatches
2. Weight-45# per box for 2-man lift
3. Temperature and Humidity-operate in shelters
with interior temperature 60°-90°F, relative
humidity 15-95 percent, operate for limited
periods at -65° - 125°F, non-operating exposure to -80° - 160°F.
4. Other-withstand salt, fog, rain, sand and dust,
sunshine, fungus, high altitude, 5g vibration,
30g shock, vermin.
+
+
It is not cost effective to design normal commercial
hardware to withstand these extreme conditions. However, it is possible to build hardened machines to specs
that are compatible with commercial machines. This
will permit the benefits of commercial support in the
development process to be realized. It may also facilitate communication between hardened systems and
normal systems; i.e., a ground based command center
and its airborne alternate.
Commercial practice
The project manager who is convinced that commercial data processing is appropriate for his project
may find that there are some obstacles to his getting
what he needs. The practice in the industry is to withhold information on advanced developments until the
machines are fully tested and are ready for public announcement. Prior to this time, the existence of a
suitable machine may be unknown to the project
manager. His best move in these circumstances is to
149
make his needs known through an industry briefing.
Then, by agreeing to protect the proprietary rights
of the vendors, he can obtain the advanced information
for use in his decision process.
There is a tendency for government project managers
to schedule the system so that they get to install the
very first machine of a new product line. Although the
vendor does a very thorough job of factory test, the
first one or two machines off the production line are
still liable to have bugs in them. The project manager
would be better off to downgrade the glamour of the
first installation and place more weight on the stability
of the later machines in the production line.
A commercial machine is suitable for a government
system when it meets all the requirements of the
government system. However, the commercial machine
was designed for a broader market than the single
government application. It contains many features in
addition to those needed by the project. There are two
disadvantages and one advantage to this. The cost of
the unnecessary features is included in the price of the
machine. The cost is not restricted to the acquisition
price of the machine. The added features also take up
space and use up time in the operational system. This
disadvantage is offset by the fact that the commercial
machine is usually much less expensive than the special
purpose alternative. In some critically timed real-time
systems, the added features must be removed. This
problem ties in to the second disadvantage. The more
features a machine has, the more complex it is and the
more things that can go wrong with it. The effects of
complexity are controlled by good system development
procedures but their impact on operations and maintenance cannot be ignored. The advantage of the added
features found on commercial machines is that the
programmers can usually find ways to use the features
to improve the system software.
There are other features that are generally useful
in government systems which are seldom found in commercial machines. The average business data processing
application does not call for them. An example is the
ability to remove a unit of the computer for service
without interrupting the computer operation. The
ability to reconfigure around -a failed unit has been
provided with some commercial systems but they are
designed to stop while the unit is removed and then
restart with some manual intervention to describe
the new configuration. In systems with enough redundant elements to permit continuous operation there
is no reason to stop the computer to remove a unit;
however, special modifications may be needed to
prevent the computer from automatically stopping
under these conditions. The modifications essentially
150
Spring Joint Computer Conference, 1972
place a switch in the hardware that isolates the failed
unit electronically the same way a switch in the software permits the logical rearrangement of boxes.
When the project manager recognizes the need for
a modification to the commercial machine there is
generally no great problem in designing and installing
the change. However, the industry business practice
may increase the cost impact of that change. The
normal maintenance of commercial hardware and
software has been designed to give maximum service
at minimum cost. This is achieved by standardizing
the training and diagnostic aids given the se~vice
personnel. A corollary of this approach is that the
serviceman is not well equipped to understand user
modifications to the hardware or software; therefore,
his service commitment may be modified or even
voided by certain types of modifications. The protection against loss of service is simple; the project manager
and the service supplier should mutually agree to a
service agreement which spells out the extent of the
service commitment and alerts the manager in advance
of the exposure he has. The reverse of this situation
may have similar impact. The vendor of commercial
hardware normally makes engineering changes to the
machines over a period of years. The purpose of the
changes is to correct minor problems, facilitate service,
reduce failure rates, etc. The changes are transparent
to the user except in cases where the user has modified
the hardware. The project manager must be prepared
to trade off the benefits attributed to the engineering
change against the value of his modification.
CHARACTERISTICS OF THE DEVELOPMENT
PROCESS
The systems included in the second class above are
dominated by large real-time information handling
systems-SAGE, Air Traffic Control, SAFEGUARD,
TACFIRE, Naval Tactical Data System, Marine
Tactical Data System, Apollo, Orbiting Astronomical
Observatory, National Military Command System,
Intelligence Data Handling System, etc. The consequence of size is complexity. There are so many interactions among the elements of a large system that no
one man has the ability to comprehend and manage
the total entity. As a consequence, the system is organized into subsystems and smaller components to
limit the span of control of each manager to a scope
that he can handle. The step by step delineation of
system components changes the focus of attention from
the system itself to the parts of the system. As a result,
the structural interactions which define the system
may not get enough attention to ensure their integrity.
Project control
The concept of "change" is basic to system development. It is unrealistic for a system manager to assume
that the objectives established at the outset of a project
will be unaffected by changes in the environment or in
the detailed plans fo~' implementing a given function.
Rather than be crippled by an inflexible plan, the
manager establishes procedures which permit the
formal modification of his baseline specification by
changes which are agreed to by all affected parties.
Such a set of procedures protects the system against
arbitrary changes but permits necessary changes. In
order to be effective, the change control process must
be able to determine the interactions of each proposed
change with the rest of the system.
The government calls the control procedure "configuration management" and provides vendors with
guidelines for describing the work breakdown and
keeping track of the base specification. For a large
system, it takes about ten years to reach the operational phase of the cycle. Lots of things change during
that period which can upset earlier commitments.
Brigadier General W. R. Reed, U.S. Army, suggested
how serious the problem can be when, after eight years
of a study and design effort, it was realized that changes
had occurred in computer technology that had a profound impact on the environment being studied. In
fact, he estimated that computers improved by a factor
of ten every 3.8* years. Such an order of magnitude
improvement required a new definition of the environment in which the computers were to be used. Gen.
Reed was talking about the Army tactical fire control
system, TACFIRE, which in eight years had been
obsoleted twice before it ever reached the acquisition
stage until 1968 by which time its specs were again
being overtaken by new technology. The guideline
implied by this situation is that computer specs should
not be frozen early in the system definitjon stage since
they will probably have to be redone later.
Postponing the actual computer decision does not
impede the progress of the system. The data processing
subsystem can be described in terms of the functional
and performance characteristics desired. These characteristics can then be incorporated into a model of
the subsystem which can be exercised to evaluate the
design concept and predict the performance of the
actual hardware when it is selected according to the
* As compared to my estimate of 5 years. The rate of computer
improvements is hard to determine but remarks by Lowell D.
Amdahl, president of COMPATA, Inc., at the June 1970 meeting
of the IEEE computer group indicated that Gen. Reed's figures
have not changed substantially since 1962.
Commercial Data Processing Machines in Government Applications
approved design. The model is a computer program
which can be run on a standard commercial machine.
(This technique, used with great success in the Apollo
program, has added value when the computer used to
exercise the model is compatible with the computer
ultimately procured for the system. When this is the
case, parts of the model may be reusable in the ultimate
system.)
The model is a design aid and may be thrown away
after the total system goes into operation. Preferably
it is retained as the basis for continuing improvement of
the operational systems. Nevertheless, it is never more
than a part of the scaffolding required to support the
system builders. Other parts of the scaffolding for a
data processing subsystem are test programs and data
generators; input/output simulators; computer services
for running engineering problems and debugging programs; compilers, sorts, and other programs to prepare
system programs for execution; controlled libraries
to separate work in process from released work; project
control administration and analysis (as in PERT);
and many other activities both technical and managerial. The optimum environment-from the standpoint
of pro}ect control, training, cost, and testing-is one in
which the same computer family is used for all functions
of control, support, and ultimate operations. The advantage of sticking with one computer family throughout
the life of the project is that predictable results can be
achieved on schedule without the distractions posed
by a new, incompatible machine.
System development guidelines
Various guidelines are generally accepted as constructive when dealing with large systems. One such guideline attempts to strengthen the system structure without tying the hands of the component developers. It
calls for the design to be done from the top down. That
means that the structure of each level of the system is
designed before the details of the next lower level are
developed. Top down design is an effective device for
identifying and controlling the interfaces within the
system. In addition, this approach minimizes the constraints on the component designers because it provides
them with a set of functional and performance objectives for their area of responsibility without telling
them how to build their specific "black box". Since
each element of the system is simply a "black box" to
the level above it, a different black box with the same
external characteristics can be substituted for the
original element without making any other changes
to the system. This is one reason why it is feasible to
use a simulated environment during the development
151
of a system; simulated black boxes are used until the
real thing is available. Such design flexibility is essential during the design stages of the system specifications.
Phased implementation
Aware of the need for adapting to changes in the
system design, the system requirements, and the system environment, experienced system managers lay
out a phasing plan which will reach the final system
in useful steps. They start with an initial operating
capability (IOC) to get a minimal capability for meeting operational requirements and to provide an environment in which to test out the design concepts for
the operational system. Only by installing an IOC can
the designers evaluate their ideas against realistic
man-machine tests and modify the final system to
overcome the weaknesses observed in the lOCo The
existence of the IOC often leads to more pervasive
changes to the system design as well. Considering the
long lead time for most large systems, the original requirements statement is often out of date when the
IOC is installed. Top management does not realize this
until they try to use the lOCo Then they observe that
some of the things they asked for are not appropriate
to the problems they face today. In addition, for the
first time they have an opportunity to observe how the
data processing system can contribute to their decision
making functions. This leads them over a period of
time to restate the functions assigned to the computer
so as to take advantage of its speed and flexibility. Invariably, their new definitions of the computer workload place more work on the machine and less on the
user. Therefore, it is normal for the final operational
system to represent an upward growth from the lOCo
Recognizing that the IOC is a test vehicle, not the
ultimate system, it should be installed at the least
expense but in a form that is easily modified. The
best way to minimize the cost of the IOC is to acquire
a commercial computer. In this situation, the original
design and development costs have been borne by the
vendor and are distributed equitably among all the
users of that computer. A special purpose machine in
the IOC passes all the design and development \costs
as well as the manufacturing cost along to the single
buyer.
The decision to select off-the-shelf hardware for a
government system affects the balance of the system
plan. The timing of the decision to use commercial
data processing equipment should be made in the
system definition phase of the development cycle. It
should occur after the overall system design and all
152
Spring Joint Computer Conference, 1972
of the subsystem functions have been defined and
before the subsystem component specifications are
complete. Having decided to use commercial technology, the actual selection of a machine should be
deferred until the start of the acquisition phase to
take advantage of the latest available technology. As
stated earlier, the system specifications can be written
around function and performance objectives rather
that detailed characteristics of the data processor so
that the delayed procurement does not slow up the
design process. By selecting a machine that is part of
a compatible family of computers, the manager can
allow for future growth requirements. To achieve the
benefits stated earlier, the manager must verify that
the compatible family includes basic software packages,
that the maximum capacity machine in the family is
large enough to permit substantial vertical growth, and
that the family has a published standard interface.
SUMMARY AND CONCLUSION
Most of the performance and reliability specificat~ons
for military and federal civilian applications can be
handled by one or more machines available off-theshelf. With minor modifications to their functional
capability, addition of special I/O boxes, and installation in suitable enclosures, the commercial machines
can generally fit all the requirements of ground-based
application areas. In fact, because of the family characteristics of many commercial machines, they outperform the typical special purpose machine with
respect to growth capability and cost effectiveness.
The delivery schedules for commercial machines are
sUbstantially more reliable than those for specially
engineered equipment. Although the first machine
delivery off the production line in commercial practice
may vary from schedule by several months, subsequent
deliveries are sufficiently certain to permit vendors to
accept penalty clauses for late delivery as a normal
business practice. By comparison, special machines
have been as much as three years late with delays of
one year from the projected schedule occurring with
some frequency. The reason for the delays is seldom
poor workmanship on the part of the builder. Most
of the time it is due to the fact that changes to the
machine specs occur during the machine development
cycle which cause rework and rescheduling. The commercial machines have been fully specified before they
are announced and before delivery commitments are
accepted; therefore, the specs are not subject to change
in the same way. The price of commercial machines is
more stable than the price of the typical cost-plus
special machine; again, because of the different impact
of product changes. More important to the integrity of
the application, commercial machines have already
passed stringent product tests before they are announced for sale. The project manager can have very
high confidence that a machine that meets his requirements on paper will perform properly in fact. He cannot have the same level of confidence in a special purpose machine since he must commit himself to its
design specs without any assurance that the machine
so specified can be built and, if buildable, will perform
exactly as planned. His ability to predict these things
at procurement time simply falls far short of his ability
to predict-and measure-the same things on off-theshelf systems. At the same time, he is able to compare
his requirements to the offerings of several competitive
vendors in the commercial market in order to select
the least expensive system for his project.
Risk reduction is a key advantage in the eyes of the
project manager. In addition, the advantages in the
development process are significant. The fact that a
test cell can be established for the engineers and a
separate support machine can be set up for the software
team contributes to shortening the system schedule.
The testing itself becomes less risky. Because the computer and its vendor software have been extensively
tested before shipment, the application programmers
can simplify their test detective work by assuming
that the commercial data processing subsystem are
error-free; therefore, errors must lie in the application
programs or test cases. The assumption will not always
be valid but the order it imposes on the error analysis
procedure will speed up the process. In particular, the
assumption that the various programs in the system
have been fully debugged directs the attention of the
test team to the interactions among the components
where it belongs and away from the internal workings
of each program unit.
Since systems are built and used by people, a major
effort in any system development involves the training
of the development team and the operational and
maintenance teams. The earlier the training can start
the better as long as the material taught is truly representative of the final operational system. When using
commercial machines, the knowledge that the machine
and its software are well defined permits training in
this area to begin immediately after the procurement
decision. Effective training can be procured from a
variety of sources without the need for structuring a
permanent educational office in the project. Moreover, the computer time needed for the trainees can
be obtained on the vendor's machine (which, by
definition, will be compatible with the project machine)
Commercial Data Processing Machines in Government Applications
without interfering with the test activities on the
project machines.
The project manager concerned with meeting a set
of operational objectives at minimum cost on a firm
schedule must minimize the risk associated with each
element of his system. By specifying commercial data
processing subsystems he can satisfy his functional and
performance needs in the large class of command and
control applications as he has traditionally done in
153
administrative applications. He will accomplish this
with less cost, equal or higher performance in both
the development cycle and in the operational installations, simpler logistics, and with much less risk of
slippage or overrun. A general guideline to follow,
contrary to past practice, would be that commercial
data processing should be used in all cases except those
in lvhich there is a specific obstacle to prevent them from
doing the job.
Programming language efficiency
in real-time software systems
by J. O. HENRIKSEN
University of Michigan
Ann Arbor, Michigan
and
R. E. MERWIN
SAFEGUARD System Office of U. S. Army
Arlington, Virginia
implementation language." The systems implementation language in effect attempts to represent a range on
the continuum of programming languages. It permits
the programmer to readily access and exploit hardware
features, but allows him to perform the bulk of his coding by utilizing a less cumbersome higher level language.
There are several attempts to analyze programming
languages described in the literature. 1 ,2,3 In the sections
which follow, an investigation is described in which representative programs from a phased-array radar realtime software system are coded in selected programming
languages. Performance measures are described, results
tabulated, and conclusions are drawn on the basis of
these results. This investigation was carried out under
the sponsorship of the SAFEGUARD System Office
of the U.S. Army by Brown University,4 the System
Development Corporation,5 University of Michigan, 6
and the Westinghouse Corporation. 7
INTRODUCTION
Early in the development cycle of a real-time software
system, the designer must select one or more programming languages to be used in writing the system.
As shown in Figure 1, there is available today a continuum of programming languages ranging from
"high-level" languages like PL/I to "low-level"
traditional assembly languages.
At the present time, high-level languages are widely
used in conventional scientific and commerical software
production, while low-level languages are widely used
in the development of real-time systems. The wide
acceptance of high-level languages in conventional
applications may be attributed to favorable costperformance tradeoff. Given an application whose
data and program structures can in a reasonable
straightforward manner be represented in a high-level
language, use of the high-level language will result
in conservation of human resources at the expense of
machine resources. Real-time systems represent a class
of applications where machine performance becomes a
critical resource. In this case, factors other than fiscal
cost of the machine resource become dominant. As a
consequence, the program and data structure of a realtime system must be hardware motivated and any programming language used to implement such systems
must allow the programmer to fully exploit the characteristics of the hardware. Since the design of program
and data structure is hardware-motivated, artificial software restrictions, in the form of language limitations,
are unacceptable. Such considerations have given rise to
a new type of programming language, called "systems
MODUS OPERANDI
Three exis ting programs developed to con trol the
phased array radar used in the SAFEGUARD AntiBallistic lVIissile System test program on K wajalein
Atoll were selected as typical examples of real-time
software. A functional description including flow charts
and data sets was prepared for each of these programs
based upon the actual assembly language code for the
equivalent function produced for the SAFEGUARD
data processor. From the supplied functional descriptions, the study participants constructed programs in
various languages and ran standard sets of test data
155
156
Spring Joint Computer Conference, 1972
LOW-LEVEL
LANGUAGES
HIGH-LEVEL
LANGUAGES
FORTRAN
PL/l
PL/360
(Exte nded Assem bier
with expression
capability)
Assembly
Language
Figure I-Continuum of programming languages
for performance measurements. Five languages; PL/1,
FORTRAN-IV-H, JOVIAL, Brown University's Language for System Development (LSD), and IBM 360
basic assembly language were compared in performance
runs on IBM 360-67 hardware. FORTRAN-V and
SLEUTH assembly language were compared on the
UNIVAC-1108. Of the languages compared, PL/I,
FORTRAN-IV, and V are selected as representative
high-level languages, JOVIAL as a precursor of systems
implementation languages, LSD as systems implementation language currently being developed, and
IBM 360 basic assembly language as a baseline for
performance measurement.
ALGORITHM DESCRIPTIONS
GETTASK
The first· algorithm modelled, G ETTASK, is a task
dispatcher for a single task list multi-processor. In the
system studies, tasks are related in PERT-like networks
such as the one shown in Figure 2.
In such a network, the completion of Task #1 allows
the simultaneous execution (if 3 processors are available) of Tasks 2, 3, and 4. In general, a given task may
have any number of predecessor tasks which must be
completed prior to its running, and a task may have an
arbitrary number of successors. In the case where more
than one task is eligible to be run at the same time, a
priority scheme is used to assign a task to a processor.
The implementation of such a precedence network is
achieved by use of absolute enablement bits (AEBs)
and conditional enablement bits (CEBs). Associated
with each task is a CEB word, an AEB, and a successor
list. Each element in a successor list contains a pointer
to another task's CEB word and a mask to be logically
ORed with the CEB word. In the example above, the
successor list for Task #1 would contain pointers to
Tasks #2, #3, and #4. Each CEB in a CEB word corresponds to a unique precedence condition. For example,
the CEB word for Task #5 in the above network would
have one bit to be set upon completion of Task #2 and
another upon completion of Task #3. Each time the
logical OR is performed, a check is made to see if all
CEBs are set to 1, and if so, the AEB for the corresponding task is set to 1, indicating that the task is
ready for dispatching. The system is general enough
to allow enablement of tasks as a funct.ion of time or
system conditions by allowing certain dedicated bits
to be set only by the operating system.
EXLIGEN
The second algorithm modelled, EXLIGEN, is a
portion of a radar control program execution list
generator which converts requests for radar transmissions, according to time and type, into a fast access
execution list format for later processing. Scheduling of
transmissions is done on a cyclic basis: a request made
in cycle n is handled by the scheduler in cycle n + 1 and
actually transmitted in cycle n+2. A master "menu" of
allowable transmissions is available to several subsystems within the radar control program, and it is possible
that these subsystems can make conflicting transmission
requests. The list generation algorithm is carried out
in two passes: in pass 1, a scan is made of all requests
in order of increasing time, and requests are consolidated according to request type; and in pass 2, a list
is constructed and ordered by priority of request type
with certain requests of the same type consolidated into
single list entries.
UPDATE
The third algorithm modelled, UPDATE, is a portion
of a Kalman filter algorithm used to filter radar return
data. On the basis of signal-to-noise ratio in the radar
returns, weights are calculated to be applied to the
current radar observations, and using these weights, a
Figure 2-Task precedence lattice
Programming Language Efficiency
state vector for an object in track is updated. The
algorithm is completely described by recursively applied
equations, which are amenable to solution in any
FORTRAN-like language.
TABLE I-University of Michigan Comparative Performance
Data for FORTRAN IV-H and PL/1
Versus Assembly Language on
IBM 360 MOD 67-2
Assembly FORTRANLanguage
IV-H
SUMMARY OF RESULTS
The results of the individual comparative studies
submitted by the four participants are shown below. The
four performance cirteria chosen were, number of
source statements, number of object instructions,
number of storage words required to contain the
programs and data, and program running times.
Comparative number of source statements reflect
ease of expression in the two languages, i.e., a program
that requires more source statements in one language
than another is less naturally expressed in this language. Comparative numbers of object instructions
are a partial measure of translator efficiency but do not
reveal the impact of run-time routines called by the
translator. Comparative object code storage requirements of language translators reflecting storage efficiency represents usage of a critical machine resource in
most real-time applications. Specific comments on these
criteria are included in the discussion of each study
results.
157
PL/I
F-5
GETTASK
(Strict Data Structure)
Number of Source
Statements
Number of Object
(nstructions (words)
Storage size (Bytes)
CPU Run Time
(milliseconds)
79
50
48
75
251
327
314
2.84
444
6.74
183
0.70
GETTASK (Redesigned
Data Structure)
Number of Source
Statements
Number of Object
Instructions
Storage Size
CPU Run Time
67
39
48
65
170
292
83
0.49
244
1.78
413
3.14
259
122
133
228
477
1100
305
1.83
655
4.98
1205
19.20
228
126
130
200
405
783
276
1.42
557
2.86
EXLIGEN
(Strict Data Structure)
The University of Michigan
The IVlichigan study was carried out on an IBM
360jl\lOD67-2 computer with 1.51\1 bytes of storage
and compared FORTRAN, PLjI, and IBlVI 360 basic
assembly language. In addition to coding the three
algorithms with a "strict" interpretation of the original
data structure, Michigan investigators carried out a
redesign of the data structures used in GETTASK and
EXLIGEN. The revised implementations, using redesigned data structures, were functionally equivalent
to the original descriptions but exhibit enhanced
translator performance.
Results, as presented in Table I, show a marked
superiority of assembly language programs on the
IBM 360. On the average for all cases tested, FORTRAN programs ran 2.7 times as long, and PLjI
programs 7.4 times as long, as the corresponding
assembly language programs. Results similar to this
were noted in a benchmark study 8 which compared
assembly language and FORTRAN on several large
current systems. While the PLjI language offers a
great deal of generality in the range of problems and
data structures it can handle, it is at the expense of
performance. Because of the wide range of the language,
Number of Source
Statements
N umber of Object
Instructions
Storage Size
CPU Run Time
EXLIGEN (Redesigned
Data Structure)
Number of Source
Statements
Number of Object
Instructions
Storage Size
CPU Run Time
1074
7.03
UPDATE
(Strict Data Structure)
Number of Source
Statements
Number of Object
Instructions
Storage Size
CPU Run Time
88
27
28
89
134
351
91
0.74
194
1.39
447
2.32
158
Spring Joint Computer Conference, 1972
TABLE II-System Development Corporation Comparative Performance Data for JOVIAL vs Assembly Language on
IBM 360 MOD 67 and Comparative Performance of JOVIAL on UNIVAC 1108 and CDC 3800 and IBM 360 MOD 67
JOVIAL
Assembly Language
IBM 360
IBM 360
UNIVAC 1108
CDC 3800
79
75
183
0.70
97*
198
399
2.02
77**
119
159***
3.4
73**
158
154****
2.1
233
647
1146
4.47
232
449
566
2.0
454
566
2.72
GETTASK (Strict Data Structure)
Number of Source Statements
Number of Ob,:ect Instructions
Storage Size (32 bit words)
CPU Run Time (ms)
EXLIGEN (Strict Data Structure)
Number of Source Statements
N umber of Object Instructions
Storage Size
CPU Run Time
259
228
305
1.83
228
UPDATE (Strict Data Structure)
N umber of Source Statements
Number of Object Instructions
Storage Size
CPU Run Time
* Includes 17 direct statements
** Includes 5 direct statements
*** 36 bit words
**** 48 bit words
88
41
133
89
91
0.74
producing an optimizing compiler is difficult, and the
language has not had a long enough history to reach the
state of development of compilers for other languages.
One of the big disadvantages of FORTRAN and even
PL/I is that the languages do not have syntactic forms
which correspond directly to powerful hardware
capabilities, i.e., the hardware is too highly masked
by the use of these languages. For FORTRAN, the
narrow range of syntactic forms appears to be the
biggest weakness. On the whole, for the problems
studied, FORTRAN appeared to produce reasonably
efficient code for the statements allowed in the language,
but the range of available statements was clearly
restrictive to the programmer. The best performance
of FORTRAN and PL/I was on the algebraic UPDATE
program, which reflects that UPDATE was the most
naturally expressed (in these languages) of the three
problems.
The improvements in performance obtained by redesign of the data structures are interesting to note.
For all languages, data structure redesign yielded performance enhancement, but the improvements obtained
were substantially greater for FORTRAN and PL/I.
This simply illustrates the fact that performance III
171
1.79
41
96
40
0.78
41
102
40
1.52
high-level languages suffers as program and data
organizations become more and more removed from
basic structures in the languages. Since program and
data organization in real-time systems are often dictated
by hardware organization and data formats, applicability of high-level languages may be relatively low.
SDC
The SDC Study was performed principally on an
IBM 360/lVIOD67 and additionally on the UNIVAC
1108 and CDC 3800 using the JOVIAL language. The
goals of this study were to exhibit performance for
another language on IBM 360 equipment and to explore the ease of transferability of software between
dissimilar machines. The JOVIAL language exhibits a
great deal of flexibility in definitional capabilities for
data structures. It represents a substantial improvement over FORTRAN in this respect, but is not
quite as wide ranging as PL/I. The JOVIAL language
also allows a programmer to insert assembly language
instructions into a program in order to utilize the hardware features he may desire. JOVIAL does not have (in
Programming Language Efficiency
159
TABLE III-Brown University
Comparative Performance Data for LSD vs FORTRAN IV, PLII and Assembly Language on IBM 360 MOD 67-1
LSD
Assembly Language FORTRAN IV
PLjI
P-5
I
48
327
444
6.74
50
159
199
2.2
II
GETTASK (Strict Data Structure)
N umber of Source Statements
Number of Instructions
Storage Size (Bytes)
CPU Run Time (ms)
79
75
183
0.70
50
251
311
2.84
259
228
305
1.83
122
477
655
4.98
88
89
91
0.74
27
134
194
1.39
EXLIGEN (Strict Data Structure)
Number of Source Statements
N umber of Instructions
Storage Size
CPU Run Time
133
1100
1205
19.2
126
440
677
UPDATE
Number of Source Statements
N umber of Instructions
Storage Size
CPU Run Time
the IBlYI 360 version) optimization features which are
as extensive as those of FORTRAN-IV-H, but produces "reasonable" code, certainly much better than
that of PL/I. Performance of IBM 360 JOVIAL is
given in Table II. The numbers shown may be meaningfully compared with the University of Michigan numbers for the strict data structures. As one might expect,
JOVIAL performed better than FORTRAN-IV-H,
much better than PL/I, and worse than IBM 360
basic assembly language in the GETTASK and
EXLIGEN problems. In the UPDATE problem,
however, the optimizing features of FORTRAN-IV-H
enabled it to outperform JOVIAL.
The algorithms were executed on the UNIVAC
1108 and CDC 3800 by simply changing the data
definition statements to account for different word
sizes. Additionally, driver programs had to be altered
because of differences in system input-output and timer
routines. The significant fact is that with the exception
of "direct" assembly language statements in GETTASK, no executable statements in the programs required change. The framework for carrying out such a
transfer to a different machine is relatively easily used,
as illustrated by the fact that the CDC 3800 conversion
was done as a minimal effort by a programmer unfamiliar with the original IBM 360 JOVIAL version.
28
351
447
2.32
31
159
133
0.78
29
151
120
0.78
Brown University
The LSD language is being developed by Brown
University as a systems programming language for the
IB1VI 360. LSD is syntactically similar to PL/I, but
not nearly as broad in scope. I t is specifically tied to the
organization of the IBlYI 360 hardware, for example, the
16 general purpose registers of the IBM 360 can be
directly referenced and manipulated in LSD statements.
The design philosophy of LSD can be summarized by
saying that it attempts to make the hardware readily
accessible to the programmer while retaining the ease
of usage of a high-level language. In order to produce
optimal code, the programmer must be thoroughly
familiar with IBM 360hardware, as only the simplest
forms of optimization are performed by the compiler.
The Brown University investigators used University
of Michigan implementations of the three programs as a
starting point. PL/I statements were then transliterated into LSD statements by means of an automatic
transliteration program. Results for compilation of the
resultant LSD source code are shown in Table III under
the column labeled LSD-I. The data generated for
EXLIGEN by LSD could not be verified and should be
regarded as ten tatine. Next, the investigators carried
out an optimization of the LSD code at the source
160
Spring Joint Computer Conference, 1972
TABLE IV-Westinghouse
Comparative Performance Data for FORTRAN V and SLEUTH
(Assembly Language) on UNIVAC 1108
SLEUTH
FORTRAN V
GETTASK
Number of Source Statements
N umber of Object Instructions
Storage Size (in 36 bit words)
CPU Run Time (milliseconds)
212
50
192
256
173
205
1.2
IllS
1.2
IllS
746
828
2.6
IllS
EXLIGEN
N umber of Source Statements
N umber of Object Instructions
Storage Size
CPU Run Time
673
645
684
2.6
177
IllS
UPDATE
N umber of Source Statements
Number of Object Instructions
Storage Size
CPU Run Time
228
212
227
35
181
212
.53
IllS
.35
IllS
level for the UPDATE program, taking advantages of
facilities not provided by PL/I. The results are shown
in column labelled LSD-II. University of lVlichigan
FORTRAN-IV and PL/I results are included for
purpose of comparison. Timings shown for Brown
University results have been adjusted upward by 10
percent from the measured. values on an IBM 360/
MOD67I-1 in order to make them directly comparable
to the timings obtained on the University of Michigan
IBM 360/MOD67-2 (1.5M Bytes Storage).
Westinghouse
The Westinghouse study was performed on the
UNIVAC 1108 and compared with the SLEUTH
assembly language with FORTRAN V, UNIVAC's
highly-touted optimizing FORTRAN compiler. Two
programmers were employed, one coding only in
FORTRAN and the other only in SLEUTH. They
designed, together with the project supervisor, compatible data structures so that a single driver program
could drive either the FORTRAN V or SLEUTH
versions of a particular algorithm. The data structures
were amenable to problem solution on the UNIVAC
1108 and were not the same as data structures originally
developed for the SAFEGUARD data processor.
On the whole, the performance of FORTRAN V
as shown in Table IV was of surprisingly high quality.
The design of compatible data structures for SLEUTH
and FORTRAN V appears to have been slightly
slanted toward FORTRAN, i.e., to force the SLEUTH
programmer to use a data structure that can also be
used by FORTRAN (especially in the areas of manipulating data pointers) is somewhat of a handicap. For the
UPDATE algorithm, which was purely algebraic in
nature, relatively good performance was expected from
FORTRAN. The algorithm was a relatively small
piece of code and was simple enough to be easily handled
by a compiler, i.e., assembly code "tricks" could not be
employed to any significant advantage. In actual performance, the FORTRAN version ran significantly
better than the SLEUTH version. If the SLEUTH
version were to be recoded using the FORTRAN
version as a guide, it is probable that it could be made
to perform better than the FORTRAN version. The
significant fact is that in the time frame allotted to
this study, FORTRAN actually produced a better
program, reflecting that in certain cases a cleverly
written compiler can actually surpass human
performance.
CONCLUSIONS
The following conclusions relative to the performance
in terms of efficient object code production and CPU
running times for programming languages, i.e., highlevel or assembly, are drawn from the results summarized above.
(a) If CPU running time and storage utilization are
the primary criteria for evaluation, assembly
language coding is distinctly superior to highlevel languages available today.
(b) System's Implementation Languages, which
appear to offer the advantages of high-level
languages with respect to reducing software
development costs, also produce object code
with efficiency approaching that of assembly
languages. This performance improvement,
largely achieved by allowing programmers
to take advantage of system hardware features,
implies a machine dependence of such languages
and loss of transferabili ty of programs written
in these languages from one computer architecture to another.
(c) Careful design of program data structures can
greatly improve the performance of present-day
higher-level languages in production of efficient
object code.
Programming Language Efficiency
(d) The production costs associated with high-level
languages are lower, up to a threshold at which
specific desired manipulations cannot easily be
made in the language.
(e) Transferability is easily achieved in high-level
languages, provided that direct usage of machine
dependent characteristics is carefully controlled.
(f) Data structures designed for a particular
machine architecture must be modified if any
kind of efficiency is desired in transferral to
another machine architecture.
(g) The "ideal" high-level language must allow
flexibility in data definition capabilities as
JOVIAL does and FORTRAN IV does not, but
be realistic in scope, as PLjI is not.
ACKNOWLEDGMENTS
The programming language efficiency study was carried
out by four groups under the overall guidance of the
authors. The study directors were Prof. B. Arden,
University of l\1ichigan; Mr. P. Waszkiewicz, Westinghouse; }\tIr. R. Knight, SDC and Prof. A. Van Dam,
Brown University. The coding was done by Mr. J.
Hamilton, University of Michigan; Messrs. G. H.
Rouillard and R. L. Specht, Westinghouse; Mr. R.
161
Brunstrum, SDC and Messrs. R. D. Bergeron, J. D.
Gannon and J. V. Guttag, Brown University.
REFERENCES
1 F J CORBATO
PL/l as a tooljor system programming
Datamation May 1969
2 H HESS C MARTIN
A tactical command and control subset of P L /1
Datamation April 1970
3 R RUBEY
A comparative evaluation of PL/l
Datamation December 1968
4 A VANDAM R D BERGERON J D GANNON
J V GUTTAG
Programming language comparison study
Brown University Report
5 R L BRUNSTRUM
A study of JOVIAL programming language effectiveness for
SAFEGUARD programs
SDC TM 4553/000/000
6 BARDEN J A HAMILTON
Study of programming language effectiveness
University of Michigan Report #0322-1-F
7 P WASZKIEWICZ
BMD object code efficiency study
Final Report for Contract DAHC 60-70-C-048 dated 20
March 1970 Westinghouse Electric Corp
8 B N DICKMAN
BTL Private Communication
A review of
recursive filtering algorithms
by BERNARD FRIEDLAND
The Singer Company
Little Falls, New Jersey
of each other and of Uk and Vk for all k~n. The optimum
estimate xn of X n, given Yn, Yn-I, ... can be expressed by
means of the recursion equations
INTRODUCTION
The recursive filtering theory introduced scarcely a
decade ago by Kalman1,2 and Kalman and Bucy3 has
been widely hailed as a major development in data
processing, perhaps as important as the work of Weiner4
on linear filtering.
The introduction of Kalman's filtering theory could
not have come at a more propitious time. The theory
was expressed in the vector-matrix notation which had
only recently been introduced to control engineers, and
problems to which the theory was applicable were
known to many investigators. Perhaps the most important reason for the almost immediate reception of the
theory is that it is expressed essentially in the form of a
computer program-in other words, it is naturally
suited to implementation on a high-speed digital
computer. Digital-computer implementation of earlier
filtering and smoothing algorithms, on the other hand,
did not seem to be very promising.
The fundamental result of Kalman's first papers can
be stated fairly concisely: consider the discrete-time
dynamic process evolving according to the "transition
equation"
(1.3)
(1.4)
where
in which (') denotes matrix transposition,
Qn
is the covariance matrix of the excitation
noise Un, i.e.,
and
Rn is the covariance matrix of the observation
nOIse.
(1.1)
The recursive nature of the Kalman filtering algorithm
and its immediate translation into a computer program
is illustrated in the flow chart of Figure la.
The reader may have noticed that the sense in which
the estimate, computed by the algorithm defined by
(1.3)-(1.6), is optimum has not yet been defined. This
omission is intentional, because, quite remarkably, the
estimate is optimum in every reasonable sense: it is the
least-squares estimate, the minimum-variance estimate,
and a maximum-likelihood estimate. It is also the
conditional mean given the observation data, i.e.,
where
is the "state vector" of the process at the nth
instant of observation
Un
is a vector of random excitations
cI>n is the (known) "transition matrix"
r n is a known matrix
Xn
Suppose that noisy observations Yn of the state are made
in accordance with
(1.2)
and, further, that
Un
and
Vn
are gaussian, independent
The other quantities in (1.3)-(1.7) also have statistical
163
164
Spring Joint Computer Conference, 1972
significance, namely:
~n=E[Xn
I Yn-l, Yn-2,
INITIAL CONDITIONS
20 , ~O
,
_I
COMPUTE TRANSITION MATRIX cPn -1 ;
EXTRAPOLATE STATE TO NEXT OBSERVATION
In= f(i n_ 11
,
TIME·UPDATE COVARIANCE MATRIX
1\
'n=cPn-1 Pn-19~-1 +111-1 Qn-1rn'-1
,
I
COMPUTE SENSITIVITY MATRIX Hn;
COMPUTE EXPECTED OBSERVATION
Yn=h(ln1
,
,
... J, conditional mean of Xn,
prior to observation Yn
Pn= E[ (xn-xn) (Xn -Xn) 'J, conditional a posteriori
covariance matrix
Pn=E[(Xn-~n) (Xn-~n)'J, conditional
a priori
covariance matrix
It is noted that the covariance matrices Pnand Pn
and hence the gain matrices Kn are independent of the
observation data. Hence the latter can be computed
off-line and stored for on-line implementation of (1.3)
as indicated in the flow chart of Figure 1b. When Un
and Vn are correlated, Kalman's recursive filtering
algorithm is somewhat more complicated and uses the
covariance matrix Cn=E[unv n']' The more general
algorithm is given in References 1 and 2.
INITIAL CONDITIONS
20 , ~O
COMPUTE GAIN MATRIX
- '"
I
,.
I
]-1
Kn-PnHnlHn nHn+Rn
/
_I
-t
""
READ DB::RYATION /
1\
xn=cPn-1 xn-1
,
COMPUTE EXPECTED OBSERVATION
Yn=Hnxn
COMPUTE RESIDUAL
,
,
,
,
,
EXTRAPOLATE STATE TO NEXT OBSERVATION
fn=Yn-Yn
/
REAO OB::RYATION/
CORRECT STATE ESTIMATE
'X n-xn
-- +K nf n
~
COMPUTE RESIDUAL
fn=Yn-Yn
NO
RESIDUAL Iriln is needed in two places: to
update the state estimate via (1.4) and to update the
covariance matrix via (1.6). It is worth noting, however, that the transition matrix is not needed to update
the state estimate. Instead the differential equation
(2.16) can be integrated over the interval [tn, tn+lJ
with x(t n) =Xn to obtain x(t n +1 ) =Xn +l). This additional
computation may be justified when it is believed that
the evaluation of the transition matrix may be inaccurate, because inaccuracies in the transition matrix
in updating the covariance matrix (1.5) are far less
serious than errors in the transition matrix used to
evaluate the estimate of the state. The former type of
error will result in using a somewhat erroneous gain
matrix K n , but the latter will result in a direct error in
the estimate of the state.
When random excitation is present on the dynamics,
a variety of theoretical problems arise the treatment of
which entails sophisticated mathematical concepts.
Jazwinski's book 6 contains a very 'well written account
of the relevant mathematical techniques. The major
difficulty arises because the continuous time analog of
the random excitation Vn is white noise which has very
disagreeable mathematical properties. Consider the
effect of adding white noise to the process (2.16), i.e.,
(2.18)
x=A (t)x+B(tH
with ~ being white noise having a known spectral
density matrix. If ~ were nonrandom, the solution to
(2.18) would be
(2.19)
Since Ht) is white noise, hmvever, the integral in (2.19)
must be interpreted in a stochastic sense. In accordance
with standard theory, the integral
with observations taken at discrete-times
is a random variable, uncorrelated with Vk,
zero mean and covariance matrix:
The solution to (2.16) can be expressed by
x (t n+1 ) = cI> (tn+l, tn) x (t n)
where cI>(tn+l, tn) is the transition matrix, which is the
solution at time tn+l to the matrix differential equation
~=A(t)cI>
(2.17)
with cI>(tn) =1, the identity matrix. Obviously this
transition matrix is used in place of cI>n, and the earlier
discrete-time results are directly applicable.
k~n
having
(2.20)
where ~ (t) is the spectral density matrix of the white
noise ~(t), i.e., E[~(tH'(T)J=~(t)O(t-T). Hence,
except for the possible difficulty in evaluating (2.20),
the discrete-time theory is applicable to (2.19).
168
Spring Joint Computer Conference, 1972
When the observations are continuous, however, i.e.,
yet) =H(t)x(t) +7](t)
Hence, as
we obtain
x=A (t)a;+K(y-H(t)x)
(2.21)
with 7] (t) being white noise, the discrete-time algorithm
is not directly applicable. A heuristic deviation of the
continuous-time equations of Kalman filter is possible
by use of a limiting process as described by Kalman. 2
For small intervals of time, the solution to (2.18) can
be approximated by
Llt~O,
(2.24)
with
Also, the variance equations (1.6)-(1.7), which can
be written in the form
F n+l-1 = (if!nF nif!n' + I'nQnI' n)-l+ H n+t' Rn+lHn+l
become
where
F n+!-l = {Fn+[A (tn)Pn+PnA'(t n) +B(tn)~(tn)B'(tn)]Llt
+0 (Llt2) }-l+H' (tn)N-1 H (t n) Llt
is a random variable of zero mean and variance
~ (tn) Lltn, owing to the integration of white
noise for an interval Lltn.
Vn
Owing to the white noise on the observations it is
not possible to sample the output y (t) at discrete times;
instead, it is necessary to smooth the output during the
intervals. Simple averaging is easiest to treat. For this
type of smoothing
1
Yn= Llt
ft n yet) dt=y(tn) +wn=H(tn)x(tn) +Wn
tn-l
(2.23)
where
1
w n= Llt
ftn 7](t) dt
tn-l
The integral in Wn is a random variable of zero mean and
variance N Llt where N is the spectral density matrix of
the white noise 7]. Accordingly
Wn
is a random variable of zero mean and variance
(1/ Llt) 2N Llt = N / Llt
Using (2.22) and (2.23) as the characterization of an
approximate discrete-time system, and applying the
discrete-time filtering algorithm, gives
a;(tn+1) = [1 +A (t n) Llt] {x(t n)
+PnH' (t n) Rn
-1
[Yn - H (t n) X (t n) ] }
Substituting Rn = N / Llt into this equation and rearranging terms gives
a; (t n+!) - a; (t n )
Llt
= [A (tn)a;(t n) + F nH' (t n)N-1 (Yn - H (tn)a;(t n) ]+O(Llt)
Upon rearranging terms and omitting terms of 0 (Llt2)
we obtain
n =A (t )P +P A'(t )
Fn+1-F
Llt
n
n
n
n
Finally, passing to the limit as
Llt~O,
we get
F=A (t)F+FA' (t) +B(t) ~(t)B' (t)
-FH'(t)N-1H(t)F
(2.25)
Thus the optimum state estimate evolves in accordance with the differential equation of the original
process, but forced by the term K(y-Ha;). The covariance matrix P evolves in accordance with the
matrix Riccati equation (2.25).
Rigorous treatment of the continuous-time process
entails rather sophisticated concepts of stochastic
processes. The original treatment by Kalman and
Bucy3 is entirely rigorous, but is confined to linear
systems. More general formulations which, in principle,
are capable of generalization to nonlinear processes,
have been developed by Stratonovich,7 Kushner,8.9
Bucy,I° and Kailath and Frost,1l·12 and by others.
EXTENSION OF THE THEORY
Like most theories, the theory of recursive filtering
is applicable exactly in almost no practical situation:
few processes are linear, almost no random noise is
gaussian (although what it is if not gaussian is another
problem), and frequently the actual process model is
not known. All these problems have received attention
in the decade since the appearance of the Kalman-Bucy
papers, and are still receiving attention at the present
time. A comprehensive survey of the various extensions
which have been published is an overwhelming assign-
Review of Recursive Filtering Algorithms
ment-a comprehensive bibliography could easily
contain a thousand items. There are, however, several
trends in the investigations being pursued which can be
outlined in broad perspective.
the previous section is applicable, and the deviations
from the nominal trajectory are given by
(3.7)
en = en+Kn(Yn-Hnen)
Nonlinear discrete-time processes
(3.8)
or in terms of the total state
A general discrete-time process could be represented
by the difference equation
(3.1)
(3.2)
Yn=h(xn, vn)
Xn+1 = f(xn)
+ ~nen
=f(xn) -~n(Xn-Xn) +~n(Xn-Xn)
~n = [af(Xn,
aXn
a general observation may be expressed by
where, in most Un and Vn are random variables about
which very little is known. The usual way of handling a
nonlinear problem is to linearize it along a nominal
solution. In the present case, suppose a nominal
sequence Xo, Xl, ... ,xn were known, and, moreover, it
is known a priori that the random quantities Un and Vn
are "small enough" to insure that the differences
(3.3)
are small. Then (3.1) and (3.2) become
Xn+l =f(xn) +~n(Xn-Xn)
169
0)]
Xn=~n
Note that except for the difference between ~n and
(3.9) can be written
(3.4)
4>n
(3.10)
Moreover, in many situations the estimated solutions
xn is more accurate than any a priori nominal solution
xn~Xn; in fact, there may be no reasonable way of
determining Xn other than by making it identical to
the xn, i.e., by defining the nominal solution as the
running estimate. In this case (3.9) and (3.10) are
identical. The same reasoning gives
Xn=Xn+Kn[Yn-h(Xn) ]
+ IinUn
(3.9)
(3.11)
The recursive algorithm (3.10) and (3.11) with the
gain matrix computed from (1.5) and (1.6) with
but
xn+l=f(xn)
is the so-called "extended" Kalman filter, as it is now
termed. These equations were used as early as 1962 by
Smith.I3 The following features of the extended Kalman
filter are worth emphasizing. See Figure 2.
Yn=h(xn) = nominal observation
where
• No nominal trajectory is required
• Covariance matrices Pn, Fn, and gain matrix Kn
must be computed on-line
• Statistical optimality is only approximate.
or
en+l = ~nen+ IinUn+O(en2)
Yn -Yn =EInen+Znvn+O (e n2)
(3.5)
(3.6)
Since (3.5) and (3.6), after omitting the terms of
O(e n 2 ) constitute a linear system, the linear theory of
Although no nominal trajectory is required, it is
necessary to compute the covariance matrix on-line
and this computation occupies the bulk of the computation requirements. It is not insignificant that strict
optimality cannot be assured for the extended Kalman
filter; as a matter of fact, it often happens that the
estimate given by (3.10) and (3.11) actually diverges
from the true trajectory as the number of observations
processed increases. This "divergence problem," to be
discussed subsequently, could result because the terms
of O(e n 2 ), so casually omitted in developing the filtering
equations, in fact, may not be negligible. Their presence
170
Spring Joint Computer Conference, 1972
INITIAL CONDITIONS
~O' ~O
•
•
COMPUTE TRANSITION MATRIX cP n-1·,
EXTRAPOLATE STATE TO NEXT OBSERVATION
,
,
,
,
,
xn = fl~n-11
TIME-UPDATE COVARIANCE MATRIX
1\
'P n=cPn-l
Pn- 1cP n-1 +rn-1 Qn-1rn'-1
COMPUTE SENSITIVITY MATRIX Hn;
COMPUTE EXPECTED OBSERVATION
Yn=h(ln 1
COMPUTE GAIN MATRIX
- '"
I
ITnH'n+Rn)-1
Kn-PnHnlHn
/
READ OB::RYATION /
COMPUTE RESIDUAL
,
rn=Yn-Yn
CORRECT STATE ESTIMATE
'Xn=!n +Kn rn
I
Figure 2
can introduce a statistical bias into the results; the
effect, paradoxically, is most serious when the random
noise represented by f' nUn and ZnVn in (3.5) and (3.6),
respectively, is small relative to the nonlinear terms.
When the random terms are large they tend to swamp
the nonlinear terms; i.e., those of O(e n2 ); when they are
small the nonlinear terms may be predominate. Since
the nonlinear terms add to the random terms, one is
tempted to increase the covariance matrices of the
latter in a heuristic attempt to account for nonlinearity.
This approach is often quite successful, but could be
dangerous because the nonlinear terms are not random,
but are related to the linear terms in a systematic way .
The limitations of the linearized Kalman filtering
equation (3.7) and (3.8) or the extended Kalman
filter (3.10) and (3.11) have led to a number of investigations, some still continuing, of more accurate
extensions of the basic theory or of alternate approaches.
These investigations appear to have been motivated by
two considerations: the desire to achieve performance
closer to the optimum, and the need to avoid problems
which arise in applying the linearized or extended
algorithm.
The desire to avoid the "divergence" attributable to
omission of nonlinear terms is a practical motivation
which may be handled in various ways, not necessarily
related to achieving "better" (i.e., closer to optimum)
performance. In the presence of nonlinearities and/or
nongaussian random variables, the very definition of the
optimum estimate is a problem: in the linear, gaussian
case the conditional mean is also the minimum variance
estimate and the maximum likelihood (Bayes) estimate.
In the linear, but nongaussian case, the minimum
variance estimate (which is what is obtained by
applying the Kalman-filtering algorithm) is not always
the conditional mean, and neither may be the maximum
likelihood estimate. In the nonlinear case, moreover,
none of the estimates can be expressed by an exact
recursion algorithm; errors are introduced by use of
truncated approximations the effects of which are very
difficult to assess. As a practical matter performance of
nonlinear filters can be assessed only by Monte-Carlo
stimulation: a "fix" which works well in one application
may be useless or even worse than the basic extended
algorithm in another.
Improved estimation algorithms can generally be
classified in two categories: higher order, explicit
algorithms and iterative algorithms. In the former, the
updated estimate Xn+l is obtained from xn by an explicit
computation which entails no iteration and no check
of accuracy; in the iterative techniques, the updated
estimate Xn+l is an implicit function of xn which is
solved for iteratively.
Iterative techniques
Iterative techniques for treatment of nonlinear
problems may be visualized as generalizations of the
Review of Recursive Filtering Algorithms
ancient Newton-Raphson technique for solving nonlinear equations. Suppose, for example, that we have a
single observation y from which it is possible to determine the state x through the solution of the system of
equations represented by
y=h(x)
(3.12)
If this is true, the Jacobian matrix
H(x) =
[:~]
is nonsingular in the vicinity of the solution to (3.12).
The standard N ewton-Raphson iteration algorithm for
solving (3.12) is
x=x+[H(x) J-I[y-h(x) ]
(3.13)
where
x
x
is a prior estimate of the solution
is a revised estimate
When x differs significantly from x, x is replaced by x
and the iteration is continued until II x- x II is sufficiently small in accordance with some criterion established by the user.
Comparison of (3.13) with the observation update
equation (3.11) of extended Kalman filtering reveals a
very striking similarity. In Kalman filtering the gain
matrix
multiplies the residual y-h(x) while in the NewtonRaphson algorithm the residual is multiplied by Hn- I •
If the observation noise is absent, and H n -1 exists,
however, the Kalman filter gain becomes
Kn = P nHn' (H n') -1 P n-1 H n-1 = H n-1
In other words the Kalman filter gain is the same as the
N ewton-Raphson weighting matrix when the latter
exists and the noise is negligible. The Kalman gain
matrix may thus be regarded as a generalized version of
the N ewton-Raphson gain which reduces to the latter
in the case when noise is absent and H n-1 exists. When
Hn- I does not exist, i.e., when the number of observations is insufficient to permit determination of the
state, but noise is absent, then the Kalman gain matrix
Kn=PnHn'(HnPnHn')-I is a "generalized inverse" of
Hn in the sense that HnKn=I, regardless of the value
of Pn •
171
Although the Kalman filter uses a more general gain
matrix, it does not perform the iterations of the X ewtonRaphson technique. In the linear case, of cours(', the
iterations are not necessary. In the nonlin('ar case,
however, one would expect that the initial ('stimate x
of the state could be improved upon by iteration unless
the uncertainty in the observation has an effect equal
to the effect of the nonlinearity. Thus, in an application
entailing highly accurate, but nonlinear, sensors, one
could expect significant benefit from use of the iterations; conversely, when the sensor noise is large relative
to the nonlinearity, little improvement due to the
iteration is to be expected.
Assuming that iterations are to be employed, what
is a suitable convergence criterion? If (3.12) is solved
exactly-to the precision available to the computerthen all past history of the process is ignored. If no
iterations are used, then nonlinear effects are disregarded. A reasonable convergence criterion would be
to iterate until the contribution of the error to the
residual vector y- h (x) is just about as large as the
nonlinear effect. The (approximate) covariance matrix
of the residual is H nP nH n' + Rn. Since, in the absense
of nonlinear effects, most of the residuals can be expected to be less than their corresponding theoretical
standard deviation, i.e.,
it would be reasonable to continue iteration until (3.14)
is satisfied. The addition of the Newton-Raphson
iteration cycle to account for nonlinear observations
entails a negligible complication of the basic algorithm,
as the flow-chart of Figure 3 shows. The operating
time, of course, will be increased in proportion to the
average number of iterations necessary to pass the
convergence test. Whether this additional running
time is justified depends on the improvement achieved.
Moreover, in an application in which the computer is
dedicated to the Kalman filtering algorithm, there may
be time available for the iteration so that the additional
cost could be inconsequential.
The ideas inherent in the N ewton-Raphson iteration
technique may be extended to the case in which the
state cannot be determined from a single observation,
but requires a series of observations and knowledge of
the process dynamics. The general equations may be
derived, using considerations of least-squares by combining the analysis of the second section and of this
section. The inherent statistical parameters can be
brought into the problem formulation explicitly. Typical
developments are to be found in COX,14 and Friedland
and Bernstein. Is
172
Spring Joint Computer Conference, 1972
INITIAL CONDITIONS
~O' ~O
-t-COMPUTE TRANSITION MATRIXCPn_l;
EXTRAPOLATE STATE TO NEXT OBSERVATION
,
,
,
,
xn = = [af/ ax] analytically.
Owing to the definition of f as the solution of a system
of ordinary differential equations, however, it is
possible to compute the transition matrix by numerical
integration of the matrix differential equation
.
cJ? =
[aa]
ax
cJ?
(3.20)
with the initial condition (tn - 1 ) =1, where [aa/ax] is
the Jacobian matrix of a(x) evaluated along the
solution to (3.18). Thus x(t n) and cJ?n are evaluated
concurrently by numerical integration of a system of
n (n+ 1) differential equations. The process differential
equations must be integrated to an accuracy consistent
with the observation errors; in other words, the numerical errors in obtaining Xn=X(t n) from X(tn-l) must be
of a lower order than the correction Kn[Yn-h(xn)].
The computation of the transition matrix, however,
requires accuracy only consistent with the accuracy to
which the statistical parameters are known. In practice
this usually means that the numerical integration
algorithm used for (3.20) can be less sophisticated than
that used to integrate (3.18). For example, while a
fourth-order Runge-Kutta algorithm might be needed
to integrate (3.18), it could well happen that a simple,
174
Spring Joint Computer Conference, 1972
Likewise the observations can be expressed as
first-order Euler algorithm
Yn=h(x n, b, vn)
q;n=I+ [::] (tn-tn_.)
would provide sufficient accuracy for the state transition matrix.
Nonlinear dynamics with random excitation create
problems on the frontiers of investigation in the mathematical theory of stochastic processes. The very meaning of differential equations with white noise excitation
is open to serious question: almost nothing is known
about how to interpret a general differential equation of
the form x=a(x,~) with ~ being white noise; the
meaning of the more restrictive equation
in which the white noise ~ is additive, is open to two interpretations, depending upon whether one uses the
mathematically-favored "Ito calculus" or the "Stratonovich calculus" unless the matrix B does not depend on
x. A lucid discussion of the two interpretations is given
by Jazwinski. 6 Since white noise is a mathematical abstraction which cannot exist in nature, the different interpretations are of more interest to mathematicians
than to engineers and physicists. Moreover, unless a
very precise analysis of the physical behavior of the dynamic process is made, it is usually impossible to establish the precise nature of the random excitation. For this
reason it would seem reasonable to account for all the
random effects in a typical process by a model of the
form
X n+l
These equations are general enough to include as
special cases observation bias and constant (unknown)
forcing terms. Each observation bias is represented by
a parameter bi which appears only in the observation
equation. Each constant forcing term appears only
in the dynamic equations unless it contributes to a
direct measurement.
There is a standard trick for handling parameter
estimation, namely to treat b as a part of an enlarged
state vector of k+m components.
Zn=
x=a(x)+B(xH
=f(x n) + r nUn
where r n and Un are selected empirically to account for
the cumulative random errors caused by all random
excitation during the intervals between the observations.
Parameter estimation
In various applications there may be a number of
parameters to be estimated in addition to the dynamic
state variables. Suppose the parameters are designated
as bi (i= 1, ... , m) and arranged in a vector
b=[]
Then the discrete-time dynamics can be represented as
(3.21)
(3.22)
[~:]
Since b is a constant it evolves In accordance with
the equation
bn+1 =b n
The initial condition bo for the estimate is taken as the
expected value before any observations, usually zero.
The standard extended linear algorithm (or any other
nonlinear extension) is applied to estimate Zn; the
resulting estimate contains the estimate xn in the
presence of (initially) unknown parameters are well as
an estimate bn of the unknown parameters. The method
works effectively and, in fact, often is the key to the
success of the Kalman filtering algorithm in practical
applications which abound in uncertain parameters. In
the sense that the filter by estimating the uncertain
parameters adapts to their presence, the technique may
be and, in fact, has been termed "adaptive."
One of the problems with this method of parameter
estimation is that the dimension of the big vector Zn
can be quite large and, as a result the calculations, may
require the manipulation of large matrices. In addition
to requiring considerable storage, the usual numerical
difficulties associated with large-matrix calculations
may be present. In an attempt to avoid such numerical
difficulties, Friedland17 developed a computation technique, which is mathematically equivalent to dealing
with the large vector Zn and the associated covariance
matrices, but in which the estimation of the parameter
vector bn is decoupled from the estimation of the state
vector. In particular, the algorithm consists of computing the estimate xn of the state as if the parameter
vector b were equal to its expected value prior to any
observations, say zero, and the corresponding residual
vectors fn=Yn-h(xn). These residuals are used as the
input to a "parameter estimator" which produces the
optimum estimate bn of the parameter b. The estimate
bn is then multiplied by a matrix V n to yield the cor-
Review of Recursive Filtering Algorithms
rected estimate:
(3.23)
In applying this method, there are usually parameters
which cannot be estimated, i.e., bn changes negligibly
from its value prior to any observations. It is clear from
(3.23) that such parameters need not be included in the
state vector Zn or in the parameter vector bn . It is
cautioned, however, that the covariance matrix, say, Pn
which accompanies the computation of Xn does not
realistically represent the accuracy of the estimated
state. When uncertain parameters are present, the
actual covariance matrix of the state is given by
(3.24)
where Vn is the matrix in (3.23) and Mn is the covariance matrix of the parameter vector, i.e.,
(3.25)
When the uncertainty is large it is quite possible that
V nMnV n' is of the same order of magnitude as Pn or
perhaps even larger.
THE "DIVERGENCE" PROBLEM
Almost as soon as Kalman's recursive filtering
algorithm was announced there were a number of
investigators ready to apply it to their specific problem.
It was quickly discovered that a practical difficulty of
the method is that the estimate of the state may tend
to diverge from the true state and, in fact, may tend to
be ridiculous. Kalman showed that the filtering algorithm is stable, i.e., erroneous covariance matrices
for the dynamic noise and the observation noise will
not cause the estimate to diverge from the true state.
Consequently, the divergence could not be attributed
to an inherent instability of the algorithm. Other
explanations for the divergence problem had to be
found. It became evident that the divergence problem
cannot be attributed to a single source. Sometimes it
may be due to difficulty in propagating the estimate of
the state, in accordance with (3.10) and (3.11); sometimes in propagating the covariance matrix In accordance with (1.6) and (1.7); sometimes both.
Modeling errors
Errors in propagating the estimate of the state may
result because of numerical errors in integrating the
dynamic equations x = f(x), or because the dynamic
equations do not really represent the true behavior of
the process. The state of the art in numerical integration
175
having been very advanced by the time the recursive
filtering algorithm was introduced, the effect of numerical errors could reasonably be discarded. The
possibility that the differential equations being integrated, however, do not accurately represent the
true physical behavior of the process, however, is not
so easily dismissed. The true behavior of the process
may not be sufficiently well understood to be modeled
accurately, or else an accurate dynamic model may be
impractically complicated. The consequence of these
"modeling errors" could very well be the divergence of
the estimated state from the true state. Possible cures
for the modeling errors which have been applied with
success in various applications include:
• Representation of the modeling errors by "pseudonoise"
• Bounding of the covariance matrix
• Use of finite-or fading-memory filtering
• Selective improvement of modeling.
The performance of the Kalman filter is achieved
through the correlation of the state of the process at a
given time to the state at earlier times. This correlation
is established through the dynamics of the process. It
follows that if the dynamic model is incorrect, the
correlations assumed to be developed may be unreliable,
and their use could be dangerous. Any noise present in
the process excitation retards the development of this
correlation, and it is thus reasonable to represent
uncertainty in the model as having the same effect as
would be produced by noise. The covariance matrix of
this "pseudo-noise" is selected so that the standard
deviation in the latter is about equal to the level ot
uncertainty in the dynamic model.
A technique related to the use of pseudo-noise is a
priori covariance matrix bounding. The rationale for
this technique is that, on physical grounds, we would
regard it as impossible to achieve better than a specified
accuracy in estimating some of the state variables. If
the covariance matrix indicates that higher ac<;uracy is
being achieved, the matrix is increased to the a priori
lower limit. Thus, instead of adding the covariance
matrix r nQnr n' corresponding to a known dynamic
noise level at each step, this matrix is adjusted so that
P n+l = ipnPnipn' + r nQnr n' does not decrease below a specified lower limit. Similarly, the observation-updated covariance matrix Pn=Pn-PnHn'(HnPnHn'+Rn)-lHnPn
can be kept from falling below a specified limit.
Another point of view on modeling uncertainties is
represented by the idea that the validity of the dynamic
model may be of limited duration. For example, there
may be certain long-term trends which the model does
176
Spring Joint Computer Conference, 1972
i.e., the conditional mean given the most recent N
observations: each time a new observation is made, the
oldest observation is deleted. One method of obtaining
a finite-memory estimate is to use a non-recursive
algorithm. For example, assuming no dynamic noise,
and following the development in the second section,
the least-squares estimate of Xn given Yn, . . . Yn-N+b
for a linear process, is given by
of the data be assumed as the age of the data is increased. This can be accomplished by assuming that the
noise covariance matrix increases from its "nominal"
value in proportion to the number of samples elapsed.
The computational advantage of the assumption of
gradual diminution of data importance is that the data
processing can usually be represented by a recursive
algorithm. For example, Tarn and Zaborszky,I8 have
shown that if the effective covariance matrix is taken as
slRn (s > 1) where l is the number of elapsed samples the
implementation is achieved by simply multiplying the
term n8n
(4.7)
and entails an additional matrix inversion. In most
cases, however, the additive noise as represented by
r nQnr n' would be expected to be quite small, and the inverse of the bracketed matrix in (4.7) can be approximated by bn- bn'l' n'r nQnr n''I' nb n. Thus (4.7) would be
approximated by
(4.8)
The computation of the additional term in (4.8) not
present in (4.7) entails two additional matrix multiplications, which may not prove significantly better to
evaluation of (4.7).
I t is worth pointing out that the matrices to be
inverted in all aspects of Kalman filtering are symmetric and (theoretically) positive-definite. Use of
inversion algorithms that are specific for such matrices
might be desirable. In particular, the Gauss-Seidel
iterative method for inverting bn-1+'I'n'r nQnr n''I'n,
with bn used to start the iteration, would very likely
converge in one or two iterations.
AnQther method for dealing with the ill-conditioned
matrices that arise in the recursive least-squares
algorithm, has been termed the "square-root method."
The method is based on representing each covariance
matrix as the product of a lower triangular matrix and
its transpose, i.e.,
(4.9)
where S is a matrix in which Sij=O for j>i. When P
and S are scalars S = vip, hence the name of the
method. (In a strict sense a lower triangular matrix S
satisfying (4.9) is not the square root of P. A true
matrix square root, say W, satisfies W2=P, and when
P is symmetric, W is also symmetric and thus cannot
be lower triangular.)
A survey of the background and current status of the
square-root method is contained in a recent paper by
Kaminski, Bryson and Schmidt. 19 In the absence of
process noise, the square root algorithm may be expressed by the formulas
Kn = SnFnGn'-lGn-l
( 4.10)
Fn=Sn'Hn'
( 4.11)
GnGn' = Rn+Fn'Fn
(4.12)
where
and
i.e., Gn
IS
the (unique) lower triangular factor of
(4.13)
where
VnVn'=Rn
Only triangular matrices are inverted in (4.10) and
(4.13) which is a considerable advantage. The major
computational chore is in the factorization of the
matrix Rn+FnFn'. This factorization problem is somewhat analogous to the spectral factorization problem
which arises in Wiener filtering (see Friedland20 for a
discussion of this connection as well as for independent
development of the Cholesky-Banachiewicz algorithm19
for accomplishing the factorization).
When process noise is present, a more complicated
algorithm is needed, but the basic ideas are the same.
The large consumer of computer capacity is the
triangularization operation impJicit in (4.12) . The
efficiency of the square-root method thus depends on
the algorithm used to find Gn • The authors of Reference
19 have made an extensive study of suitable algorithms
and conclude that Householder's algorithm is adaptable
to this problem. A count of operations made in Reference 19 shows that the square-root algorithm may
typically require only as much as 30 percent of additional computer time over that required by the
conventional (Kalman-Bucy) algorithm and even less
time than use of the information-matrix algorithm.
The numerical advantage of the square-root method is
claimed to be equivalent to doubling the precision of
calculations: " ... a single precision square-root filter
would provide the accuracy equivalent of a double
precision conventional filter in ill-conditioned problems."19
CONCLUDING REMARKS
No survey of the first decade of Kalman filtering would
be complete without a discussion of applications which
were investigated almost as soon as the theory appeared. (Since the Swerling paper, 5 which predates
Kalman's paper by a year, deals with an application,
it would be reasonable to assert that applications were
investigated even before Kalman's theory appeared.)
Coming at the time of the rapid expansion of the
country's aerospace program, it is understandable that
the majority of appliyations were in the aerospace field.
G. Smith's very timely paper13 aroused considerable
Review of Recursive Filtering Algorithms
interest when it was presented and perhaps was to a
very large measure responsible for the rapid assimilation
of the method by aerospace engineers. The application
of the method to orbit and trajectory determination
described in the book21 of a notable expert, R. Battin,
helped to establish the importance of the theory. Since
the earliest papers, which demonstrated feasibility of
the method largely through simulations, the number of
applications which have been studied is overwhelming.
Hundreds of papers demonstrating potential performance have been presented at technical meetings
and have been published in the journals of technical
societies. Moreover, the published studies represent
only a small fraction of those actually performed. Many
others are documented in company internal technical
reports or in final reports of limited circulation (many
also classified) prepared under government contract.
The recursive filtering algorithm is so simple that
almost anyone can develop a simulation program.
Many organizations evidently have done so.
Application of the Kalman filtering technique to
processing of real-world data has naturally been more
limited than application studies conducted through
simulation. Nevertheless, the number and importance
of real-world applications of this technique is most
impressive. Those who have listened to the broadcasts
of Apollo flight conversations must have heard reference
to "state-vector updates" -clearly the language of
Kalman filtering. And also the substance. A review of
the extensive use of Kalman filtering in the Apollo
program by Battin and Levine is contained in a compendium22 of theory and applications papers that were
presented at a 1970 AGARD meeting. Another important application of Kalman filtering has been to
aided-inertial navigation. The Kalman filter, in this
application, is used to optimally mix data from an
inertial platform which has very low inherent shortterm errors, but which can build up substantial secular
drifts, and non-inertial (e.g., radio ranging, LORAN,
doppler) navigation aids which have opposite characteristics, namely that they are relatively drift-free but
typically quite noisy. The Kalman filtering algorithm
is implemented using an airborne digital computer on
the C5-A military transport. A description of the system
is given in Reference 22. Inertial navigation applications have advanced to the point that implementation
of the Kalman filtering algorithm is now a significant
design consideration, in particular, with regard to the
design of airborne digital computers to be used in
such systems.
Kalman filtering applications appears to be significantly less widespread outside of the aerospace field.
Perhaps one reason for this is that dynamic models
179
which playa large role in Kalman filtering are not well
established for processes if interest, especially in very
large-scale systems (e.g., urban dynamics, ecological
systems, etc.). The existence of an analytically-defined
dynamic model would appear to be a minimum prerequisite for application of the recursive filtering
algorithm, unless methods can be found for using the
algorithms in the absence of such models. In the field
of industrial processes, Kalman filtering applications
have been reported in conjunction with direct digital
control. An early, and by now rather celebrated,
application in the Swedish paper-making industry was
presented by Astrom.23 Other applications in the paper
industry, the cement industry, the metallurgical
industry, the electric pm\Ter industry, have been
reported or proposed.
The recursive filtering technique developed by
Kalman and Bucy would appear to be mature and
vigorous despite its youth. The easy theoretical problems
seem to have been solved, / and the reasons 'why the
difficult problems are difficult have been discovered;
approximate methods have been developed to facilitate
engineering applications and to develop insights;
applications in diverse fields have been studied and
often implemented; the basic results are teachable and
are included in many curricula in systems engineering.
Like many engineering analysis techniques of the past,
some of the glamor of Kalman filtering is likely to wear
off. What remains, hmvever, will continue to be useful
for many years to come.
REFERENCES
1 R E KALMAN
A new approach to linear filtering and prediction problems
Trans ASME J Basic Eng Series D Vol 82 pp 34-45 March
1960
2 R E KALMAN
New methods in Wiener filtering theory
In Proc 1st Symp Engineering Applications of Random
Function Theory and Probability J L Bogdanoff and
F Kozin Eds N ew York Wiley 1963 pp 270-388
3 R E KALMAN R BUCY
New results in linear filtering and prediction theory
Trans ASME J Basic Eng Series D Vol 83 pp 95-108 March
1961
4 N WIENER
The extrapolation, interpolation, and smoothing of stationary
time series with engineering applicat£ons
New York Wiley 1949
5 P SWERLING
First order error propagation in a stagewise smoothing
procedure for satellite observations
J Astronaut Sci Vol 6 pp 46-52 Autumn 1959
6 A H JAZWINSKI
Stochastic processes and filtering theory
New York Academic Press 1970
180
Spring Joint Computer Conference, 1972
7 R L STRATONOVICH
Conditional Markov processes
Theory of Probability and Applications Vol 5 pp 156-178
1960
8 H J KUSHNER
On the dynamical equations of conditional probability density
functions with applications to optimum stochastic control
theory
J Math Anal Appl Vol 8 p 332 1964
9 H J KUSHNER
On the differential equations satisfied by conditional probability
densities of Markov processes
SIAM J on Control Vol 2 pp 106-119 1964
10 R S BUCY
Nonlinear filtering theory
IEEE Trans on Automat Contr Vol 10 p 198 April 1965
11 T KAILATH
An innovations approach to least-squares estimation-Part I:
Linear filtering in additive white noise
IEEE Trans Automat Contr Vol AC-13 pp 646-655
December 1968
12 T KAILATH P FROST
An innovations approach to least-squares estimation-Part II:
Linear smoothing in additive white noise
IEEE Trans Automat Contr Vol AC-13 pp 655-660
December 1968
13 G SMITH
M ultiuariable linear filter theory applied to space vehicle
guidance
Presented at SIAM Symposium on Multivariable System
Theory Cambridge Mass November 1962
14 H COX
On the estimation of state variables and parameters for noisy
dynamic systems
15 B FRIEDLAND I BERNSTEIN
Estimation of the state of a nonlinear process in the presence
of nongaussian noise and disturbances
J Franklin Institute Vol 281 pp 455-480 July 1966
16 R S BUCY K D SENNE
Digital synthesis of nonlinear filters
Automatica Vol 7 No 3 pp 287-298 1971
17 B FRIEDLAND
Treatment of bias in recursive filtering
IEEE Trans Automat Contr Vol AC-14 pp 359-367 August
1969
18 T J TARN J ZABORSZKY
A practical, nondiverging filter
AIAA J Vol 8 pp 1127-1133 June 1970
19 P G KAMINSKI A E BRYSON JR S F SCHMIDT
Discrete-square root filtering: A survey of current techniques
IEEE Trans on Automat Contr Vol AC-10 No 6 pp 727-735
December 1971
20 B FRIEDLAND
Least squares filtering and prediction of nonstationary
sampled data
Inform Contr Vol 1 pp 297-313 1958
21 R H BATTIN
Astronautical guidance
New York: McGraw-Hill 1964
22 C T LEONDES ed
Theory and applications of Kalman filtering
AGARDograph No 139 NATO Advisory Group for
Aerospace Research and Development February 1970
23 K J ASTR(jM
Computer control of a paper machine-An application of
linear stochastic control theory
IBM J Res Develop Vol 11 pp 389-405 1967
On computational methods for dynamic and
static optimization*
by D. H. JACOBSON
Harvard University
Cambridge, Massachusetts
INTRODUCTION
certain of the second-variational algorithms remain as
attractive methods.
Our work in trajectory optimization (or, more
generally, computation of optimal controls) has been
concerned with the development of a class of algorithms
and a methodology of computation based on Dynamic
Programming. The approach which is called Differential
Dynamic Programming (DDP) arose as a consequence
of an early stimulating paper6 and is quite extensively
described in Reference 7. While no theorems of convergence are given in Reference 7, conditions and proofs
for continued descent are provided, and the algorithms
have successfully solved a number of substantial
numerical problems. Thus, there is still room for
theoretical extensions in the form of convergence proofs
and rate of convergence studies, though these will be
nontrivial. Mayne's8 recent approach to DDP may
prove to be useful in these theoretical problems.
In parameter optimization which, basically, involves
choosing the values of n variables to minimize a scalar
function, the most famous and widely used methods are
given in References 9 and 10. These methods are based
on quadratic modelling of the function to be minimized
and hence are quasi-Newton in type. Interestingly
Fletcher and Powell's algorithm appeared in 1963,
and has been very popular, but it was not until 1971
that a proof of convergence was offered by Powell.ll
Our interest in the function minimization problem
led us to propose a new class of algorithms which is
based upon the concept of an homogeneous function. 12
Our algorithm12 is but one possible example of the use
of the homogeneous model and it is likely that others
will be forthcoming. The algorithm is roughly at the
stage that Fletcher and Powell's was circa 1964 in that
computational experience suggests that it is attractive,
while convergence and rate of convergence studies are
yet to come.
A recent book which is appealing in its novelty of
approach to the theoretical questions of convergence
In the 1960s the joint impact of fast digital computers
and the space age stimulated the ingenuity of a number
of researchers in optimization and prompted them to
invent new and/or better (faster, more elegant) methods
for solving, numerically, optimization problems of
different types. Two areas that received much attention
were trajectory optimization and parameter optimization. That is, the computational problems of determining optimal trajectories (generally, functions of
time) and optimal parameter values by minimizing
(maximizing) appropriate performance criteria.
Many of the (very successful) algorithms developed
were heuristic in that they were good ideas translated
skillfully, albeit non-rigorously in the mathematical
sense, into algorithms and computer programs. More
recently, more effort has been assigned to the theoretical
problems of convergence and rate of convergence of
algorithms. But, and this is an important point, new
powerful algorithms rarely arise out of purely abstract
treatments while on the other hand good heuristic
methods seldom manifest themselves unless their
inventors have at least some deep, albeit informal,
understanding of theories of convergence which would
enable them to propose an algorithm which is "unlikely
not to converge." Thus, good heuristics and theory of
algorithms should complement one another in the
invention and development of numerical methods.
Certain trajectory optimization algorithms that
manifested themselves, as powerful numerical methods
for solving real aerospace problems are described in
References 1 and 5. The reader should acquaint himself
with these because, though some of the methods are
dated, insight into the development of computational
methods in optimization can be gained and, moreover,
* This research is supported by the Joint Services Electronics
Program on Contract N00014-67-A-0298-0006.
181
182
Spring Joint Computer Conference, 1972
and rate of convergence is Polak's. 13 Here, general
theorems on convergence are presented and applied
to known and new algorithms. Though this general
theorem approach is appealing and useful it is not a
panacea; indeed, some effort appears to be needed to
twist the algorithm described in Reference 12 into the
framework and verification of a number of required
conditions seems to be nontrivial. 14
With this background and philosophy noted, we
continue with subsequent sections of this paper which
describe briefly the notions of DDP for control optimization, and homogeneous modelling for function
optimization. These are two approaches which seem to
be attractive and which, as outlined above, offer
potential for future research.
OPTIMAL CONTROL COMPUTATION
Problem formulation
We are concerned with the problem of finding a
control function u ( .) which minimizes
V(Xo, u(·), to) =
t!
I
L(x, u, t) dt+F[x(tj)J
(1)
to
subject to the dynamic system constraints
x=f(x, u, t); x(to) =Xo
(2)
and the terminal and control constraints
-.f;(x(t j » =0
(3)
g(u(t»~O
(4)
Here, L:R nXR mXRL-7R\ F:Rn~R1, f:RnXRmXR1~
Rn, -.f;:Rn~R8, g:Rm~Rq, and all these functions are
assumed to be three times continuously differentiable
in each argument. The initial and final times to, tj are
assumed to be given.
In general, one is unable to find the absolute minimum of V (some sort of global search technique would
be required) unless V is a convex functional of u(·)
which would exclude the possibility of there existing
a number of local minima having different V values.
Typically what one can find is a stationary point of V
or, at best, a local minimum of V.
It is known that a necessary condition (Pontryagin's
Principle) for V(xo,u('),t o) to have a relative minimum with respect to u(·) at u(·) =Uo(.) is that there
exist multipliers poER+\ vERB, A(') absolutely continuous, not all zero, such that
where
H(x, u, A, t) = poL (x, u, t) +ATf(x,
U,
t)
(6)
and
UO(t) = arg min H (x, u, A, t)
(7)
U(t)EU
where
u= {u(t) :g(u(t»
~O}
(8)
Usually one assumes that the problem is normal (i.e.,
that the conditions can be satisfied with po:;eO) so that
po can be set equal to unity.
Thus, at the very least, one is interested in determining a control function which satisfies the above
necessary condition.
Certain algorithms [2J, [3J are based directly on
second-order expansions of the above optimality
conditions, but we prefer to use the notion of DDP
which is intuitively more appealing and gives rise to
algorithms which are significantly different from those
arising from expansions of conditions (5) - (7) . Of
course, with hindsight, it is possible to derive these
algorithms by expanding (5)-(7) but it is the Dynamic
Programming formulation which gave rise to these in
the first place (see Reference 15 for some discussion
of this).
For the purpose of this presentation we shall assume
g ( • ) = 0 (i.e., no control constraints) and at the outset
we shall assume -.f;(.) =0 (no terminal constraints)
though we shall allow -.f;( ·):;e0 later in the paper (see
Reference 7 for DDP algorithms that handle control
constraints) .
We define the optimal value function VO(x, t) by
..1
VO(x, t) =
min
jt! L(x, u, t) dt+F(x(tj»
(9)
U(T) ,t0]. There is a host of other methods
based on quadratic models (Quasi-Newton methods)
and each has its advantages and disadvantages when
compared with References 9 and 10; see, for example
184
Spring Joint Computer Conference, 1972
Reference 17. The important point is that researchers
in this field have exploited and continue to exploit,
admittedly cleverly, the quadratic model. Thus, the
homogeneous model, described below, seems to be a
departure from conventional approaches (though a
certain method that arises from the homogeneous
model is closely related to Newton's method).
Homogeneous function as a model for minimization
algorithms
The continuously differentiable function C (x) is
said to be homogeneous of degree "I if
(22)
C(x) ="1-1 (x-x*)T(ac/ax) (x) +w
Clearly a quadratic function is homogeneous of degree
2. An example of a non-quadratic homogeneous function is
C(x)
= [Y2(X-X*)TQ(X-X*)Jp, p>l, Q>O
(23)
Since Cxx(x*) =0 convergence of conjugate gradient
methods is particularly poor for this type of function
[12].
Multiplying (22) by 'Y yields
Note that this is a Newton step modified by the scale
factor ("1-1). Thus Newton's method, which minimizes
a quadratic in one step, minimizes a homogeneous
function if a step length of ("1-1) is used. This appears
to be unknown in the function minimization literature
though analogous behavior, in the problem of locating a
repeated root of an equation, was recognized in 1870 by
Schroder. Unfortunately, methods which generate
estimates of the second derivative matrix (inverse)
from past data, for example Fletcher and Powell, do
not preserve this valuable property; this is another
motivation for estimating x*, "I, w directly from (24),
as is done in Reference 12.
CONCLUSION
In this paper our intent is to place in perspective certain
approaches to the development of optimization techniques, and to suggest certain research directions.
Two areas of recent activity, namely dynamic and
static optimization via DDP and homogeneous modelling, are introduced. DDP and homogeneous modelling
are two novel approaches to optimization which could
be exploited further.
~
'YC(x)
= (x-x*)T(ac/ax) (x) +w,
'Yw=w
(24)
N ow, the attractiveness of this model is apparent;
namely, the unknowns x*, "I, w appear linearly and can
be solved for, given n+2linearly independent vectors
[C(Xi), (ac/ax) (Xi), -IJ,
i=I, ... n+2
(25)
Our new algorithm, for general functions, described in
Reference 12 is one possible procedure for iteratively
updating the estimates of x*, "I, w as new data points
become available. Numerical experience indicates that
the algorithm is at worst competitive with Fletcher
and Powell's and, in a number of representative
examples, is almost twice as fast in terms of number of
evaluations of the pair [C (x), (aC / ax) (x)].
Though the class of homogeneous functions is larger
than, and includes, quadratic functions, a suitable
modification of Newton's method will find the minimum,
x*, in one step. Differentiating (24) with respect
to x yields
[(a 2c/ax2) (x)J(x-x*)
= ("1-1) (ac/ax) (x)
(26)
whence, if the required inverse exists and is positive
definite,
x*=x- ("1-1) [(a 2c/ax2) (x) J-1 (ac/ax) (x)
(27)
REFERENCES
1 H J KELLEY
Methods of gradients
In Optimation Techniques G Leitmann ed Academic Press
New York 1962
2 H J KELLEY R E KOPP H G MOYER
A trajectory optimization technique based upon the theory of
the second variation
In Progress in Astronautics and Aeronautics Vol 14 New
York Academic Press 1964 pp 559-582
3 S R McREYNOLDS A E BRYSON JR
A successive sweep method for solving optimal programming
problems
Proc 1965 Joint Automatic Control Conference No 6 P 551
4 H J KELLEY B R UZZELL S S McKAY
Rocket trajectory optimization by a second-order numerical
technique
AIAA NASA-MSC Astrodynamics Conference Houston
Texas December 12-14 1967
5 C W MERRIAM III
Optimization theory and the design of feedback controls
McGraw-Hill New York 1964
6 D Q MAYNE
A second-order gradient method of optimizing non-linear
discrete time systems
Int J Control 3 1966 pp 85-95
7 D H JACOBSON D Q MAYNE
Differential dynamic programming
American Elsevier New York 1970
Computational Methods for Dynamic and Static Optimization
8 D Q MAYNE
Differential dynamic programming-A unified approach to
the optimization of dynamic systems
To appear in Advances in Control Systems C T Leondes ed
1972
9 R FLETCHER C M REEVES
Function minimization by conjugate gradients
Computer Journal 7 July 1964 pp 149-154
10 R FLETCHER M J D POWELL
A rapidly convergent descent method for minimization
Computer Journal 6 1963 pp 163-168
11 M J D POWELL
On the convergence of a variable metric algorithm
J Inst Math Applic 7 1971 P 21
12 D H JACOBSON W OKS MAN
An algorithm that minimizes homogeneous functions of n
variables in (n + 2) iterations and rapidly minimizes general
functions
J Math Anal Appl 1971 To appear
185
13 E POLAK
Computational methods in optimization-A unified
approach
Academic Press New York 1971
14 E POLAK D H JACOBSON
Informal Talks Spring 1971
15 W F DENHAM
Review of Reference 7
IEEE Trans Automatic Control Volume 16 August 1971
pp 389-390
16 D H JACOBSON M M LELE J L SPEYER
New necessary conditions of optimality for control problems
with state variable inequality constraints
J Math Anal Appl35 1971 pp 255-284
17 B A MURTAGH R W H SARGENT
Computational experience with quadratically convergent
minimization methods
Computer J Volume 13 May 1970 pp 185-194
Piecewise linear approximations of fewest line segments
by D. G. WILSON
Virginia Commonwealth University
Richmond, Virginia
INTRODUCTION
at discrete abscissa values within a variable tolerance.
Our algorithms can also be used to approximate continuous functions. However, in this case a partition of
the interval of interest must be chosen first, the values
of the function at these points computed, and an initial
continuous piecewise linear approximation obtained by
linear interpolation. It is evident that our algorithms
cannot give a "good" fit if this initial approximation is
not "good." It is also evident how to make this initial
approximation "good." But it is not at all obvious how
to make it how "good." We have not solved this
problem in general. Perhaps a combination of Phillip's
algorithm and ours could be used to solve the problem
for continuous functions whose domains are separable
into intervals over which the second derivative is of
one sign.
In the second section we give a precise statement of
the problem we have solved. Section three contains the
basic algorithm and the modification. Section four
contains the proofs which validate the algorithm.
Section five contains some sample results. Section six
acknowledges the assistance of others. A listing of a
FORTRAN program which implements our algorithms
is appended.
Schwerdtfeger4.5 has considered the problem of interpolation and curve fitting over a given partition by a
sum of continuous sectionally linear functions. He
showed how to construct an orthogonal system of these
functions over a given partition and how to use this
system to obtain an approximation of a given function
which is best in the least square sense.
Stone,6 Bellman,! and Gluss 2 have analyzed various
aspects of the problem of obtaining a piecewise linear
approximation, not necessarily continuous, with a given
number of line segments which is best in the least
square sense.
IVlore recently, Phillips3 has given an algorithm for
obtaining a continuous piecewise linear approximation
to a function whose second derivative is of one sign.
This algorithm gives an approximation which is of
fewest segments among those with a given deviation.
The output from this algorithm is a partition of the
given interval and the parameters of a straight line
over each subinterval of the partition.
We consider the problem of approximating a continuous sectionally linear function by another piecewise
linear function, which mayor may not be continuous,
satisfying:
STATEMENT OF THE PROBLEM
(a) the approximation is within a given deviation,
which need not be constant, of the given function
and
(b) the approximation is extremal in the sense that
there is no other piecewise linear approximation
which is within the same or lesser deviation and
which has fewer line segments.
Let P denote a partition of the finite interval [a, b].
Let f (x) be a continuous function defined on [a, bJ
which is linear on each subinterval [Xi-I, xiJi = 1, ... , n.
Let 0(x) be the continuous sectionally linear extension
to [a, bJ, obtained by linear interpolation, or 0 (x) = OJ
when x=xjEP, where 0i>O, j=O, ... , n, are the
permissible deviations at the points of P.
Then the problem is, given Uo = a, determine m, pi, qi,
and Ui, i= 1, ... , m such that F(x) given by:
We give an algorithm which solves the problem as
stated and a modification which gives a continuous
piecewise linear, approximation which is within a given
deviation of the given function and which is extremal
among such approximations in the sense given above.
We thus solve the problem of fitting data known only
187
188
Spring Joint Computer Conference, 1972
when xE [Ui-I, Ui) for i = 1, ... ,m and
F(um) =Pmx+qm,
satisfies If(x)-F(x)l:::;o(x) for xE[a,bJ and m,
the number of linear segments of F, is a minimum.
Xk(x, A, B)
THE ALGORITHM
rmax[x, {Xi I xiEP, Xi ~k (Zi-I, Xh, Ai-I),
then go to Termination step 1.
4. If Zi = Zi-I, then go to Termination step 2.
5. Compute: Ai=Pk(Z*, Zi-I Zh Yi),
Bi=Qk(Z*, Zi-I, Zh Yi)'
6. Increment j by
+ 1 and go to Iteration step 1.
Proof:
The functions are rational and hence continuous on
(x, b]. Let Xi and Xi+! be successive points of P n [x, b].
That Sk and Sk are linear in (Y-X)-I for yE (Xi, Xi+!]
follows from substituting
LJ.I(Y) =LJ.I(Xi) + [LJ.I(Xi+l) -LJ.I(Xi) ](Y-Xi) / (Xi+I-Xi)
Termination:
1. If X(k)=+1, then set Pk=Sk(ZhYi)' If
X(k) = -1, then set Pk= Sk(Zh Yi)' Set qk= f(zi) +
"A(k)O(Zi) -PkZi' Set X(k+l) =X(k). Go to
Termination step 3.
2. If X(k) = -1, then set Pk=Sk(Zi, Yi)' If
"A(k) = 1, then set Pk = Sk (Zh Yi)' Set qk = f(zi) +
"A(k)o(z) -PkZi' Set X(k+1) = -X(k).
3. Set: Uk=Yh
+
for p,=t into the definition of Sk equation (2.1) and
for p,=b into the definition of Sk equation 2.2. Writing
(Y-Xi) = (y-x) + (X-Xi) and dividing out (y-x)
gives an expression linear in (Y-X)-I.
Corollary 1:
For a fixed XE [a, b], if Xi and Xi+! are successive
points of Pn[x,b],then Sk(X,y) and Sk(X,Y) are
monotone functions of Y for Y E (Xi, Xi+l].
Corollary 2:
Ao= Sk(ZO, Xh),
Bo= Sk (zo, Xh).
If the approximation is to be continuous, then
set z* = Zh otherwise set z* = Yi' If the approximation is to be continuous and k> 1, then
recompute Uk-I, the abscissa value at the intersection of the current and previous segments.
Set: j = 1, increment k by
1 and go to
Iteration step 1.
4. Set: Pk = {~k (Zi-I, b, Ai-I) +Uk (Zi-I, b, B i- I) }/2,
+
For fixed xE [a, b], Sk(X, y) and Sk(X, y) take their
minimum and maximum values respectively at points
y' and y" which belong to pn (x, b].
Lemma 2:
For a fixed XE [a, b], A and B, if Xi and Xi+! are
successive points of pn (x, b] with ~k(X, Xi, A) ~
Uk(X, Xi, B) and ~k(X, Xi+!, A) ~k (x, Xi, A)
or
Sk (x, Xi+l) <
Uk(X, Xi, B) and not both.
qk=f(Zi-l) +"A(k) o(Zi-I) -Pkzi-I,
Proof:
uk=b.
We show first that under the hypothesis not both
inequalities may hold. Since Sk(X, Xi+!) ~Sk(X, Xi+!) ,
both inequalities would imply Uk (X, Xi, B) > ~k(X, Xi, A)
which contradicts the hypothesis.
We now show that under the hypothesis not both
inequalities may fail. From the definition of ~k and Uk,
and lemma 1: If Sk (x, Xi+!) ~ ~k (X, Xi, A) and
Uk(X, Xi, B) ~~k(X, Xi, A),
then
Uk(X, Xi+l, B) ~
~k(X, Xi, A); similarly if Sk(X, Xi+!) ~Uk(X, Xi, B) and
~k(X, Xi, A) ~Uk(X, Xi, B),
then
~k(X, Xi+l A) ~
Uk (X Xi, B). Thus, if the hypothesis held but both
inequalities failed we would have: ~k (x, Xi, A) ~
Uk(X, Xi+l, B) > ~k(X, Xi+l, A) ~Uk(X, Xi, B). But this
implies Sk (x, Xi+l) > Sk (x, Xi+!) which is impossible.
If the approximation is to be continuous and
k> 1, then recompute Uk-I, the abscissa value at
the intersection of the current and previous
segments. End.
VALIDATION
In this section we show that Yk(x, A, B) can be
computed, that the algorithm just given does generate
a piecewise linear approximation which is extremal in
. the sense already defined and finally that the modification to be implemented for a continuous approximation
190
Spring Joint Computer Conference, 1972
Proof:
Lemma 3:
For a fixed xE [a, b], A and B, let Xi and Xi+! be
successive points of P(](x,b] with ~k(X,Xi,A)~
Uk (X, Xi, B) and Uk (X, Xi+l, B) > ~k (x, Xi+l, A) . If
Sk(X, Xi+l) > ~k(X, Xi, A), then Yk(x, A, B) is the z
value for which
Lb(Z) = (z-x)
~k(X,
Xi, A) +f(x) +A(k)o(x);
while if Sk(X, Xi+!) ~k (x, Xi, A), then Sk (x, z) is
an increasing function of z for Z E (Xi, Xi+l] and we are
interested in the Z for which Sk(X, z) = ~k(X, Xi, A),
while if Sk (x, Xi+!) < Uk (X, Xi, B), then Sk (x, z) is a
decreasing function of z for zE (Xi, Xi+!] and we are
interested in the z for which Sk(X, z) =Uk(X, Xi, B).
This lemma shows constructively that Yk(x, A, B)
can be computed. This is the only function we have
defined about which there was potential doubt.
It is evident that our algorithm generates a piecewise
linear approximation which is within 0 of f. We now
show that this approximation is extremal.
For convenience we identify the last Zj associated
with the kth segment as ek, the abscissa value of the
eyepoint of this segment. This value is available at the
termination step of each segment. Note that
Since each segment, except possibly the right most,
terminates on either L t or Lb we have shown that each
approximating segment, again except possibly the
right most, has at least two points on the boundary of
our two dimensional tunnel. The extremal property of
our approximation follows from each approximating
segment, except possibly the right most, having at
least three points on the boundary which alternate
between the boundary lines.
We will prove this assertion in the next two lemmas.
The first of these merely establishes a useful geometric
fact.
Lemma 4:
Let asx, <,
S, or =. If A(k) = +1 and Sk(X, y)Rsk(x, z), then
Sk(X, y)Rsk(y, z). If A(k) = -1 and Sk(X, y)RSk(x, z),
thensk(x, y)RSk(y, z).
~,
If A(k) = +1, then the hypotheses imply:
[Lt(y) -Lt(x) ](z-x)R[Lb(z) -Lt(x)] (y-x).
In this relation we substitute (z-y+y-x) for (z-x)
on the left and [Lb(Z) -Lt(y) +Lt(y) -Lt(x)] for
[Lb(z) -Lt(x)] on the right. The result is:
[Lt(y) -Lt(x) ](z-y)R[Lb(z) -Lt(y) ](y-x).
The conclusion, Sk(X, y)Rsk(y, z), follows from dividing
this relation by (z-y)(y-x) >0.
The argument is similar in the case A(k) = - 1.
Lemma 5:
If the kth approximating segment is not the right
most and terminates on Lp., where,." = b or t, then there
exist x'E [Uk-I, Uk) and x"E (x', Uk) such that Lp.(x') =
X'Pk+A(k)o(x') and Lv(x") =X"Pk+A(k)o(x") where
if ,." = b, then v = t and vice versa.
Proof:
The idea of the proof is simple although the notation
is complicated. The outline of the proof is as follows.
If the kth segment is not the right most, then the slope
of this segment is both the maximum of the minimum
permissible slopes for approximating segments through,
(ek' Lp.(ek» which intersect the vertical segment over
Uk-I, and the minimum of the maximum permissible
slopes for approximating segments through this eyepoint which intersect this vertical segment. Furthermore each of these slopes is determined by a point on
the boundary. One of these points is the terminal point
of the segment, the other is the point whose existence
this lemma asserts.
There are four possible cases determined by:
Lt(Uk) =UkPk+qk with A(k) = ±1, and Lb(Uk) =UkPk+qk
with A(k) = ± 1. We shall consider the two cases with
A(k) = + 1. The other two are similar to these.
We consider first A(k) = +1 and Lt(Uk) =UkPk+qk.
Then Lt(ek) =ekPk+qk, x'=ek and we need to find
x" E (x', Uk). If ek = Uk-I, then the slope of the line
through (Uk-I, Lt(Uk-I» and (Uk+l, Lt(Uk+!» is the
minimum permissible slope of an approximating
segment over [Uk-I, Uk]. By lemma 3 and corollary 2 of
lemma 1 this minimum slope is the slope of a line from
(Uk-I, Lt(Uk-I»
through (Xi, Lb(Xi»
for some
Xi E P(] (Uk-I, Uk]. Furthermore, this Xi is not Uk since
Lt(Uk) =UkPk+qk. In this case x" is this Xi.
If ek¢.uk-I, then to determine Uk, Pk and qk more than
one pass through the iteration phase of our algorithm
was required. Let ek* and Yk* be respectively Zj-2 and
Yi-I, where ek = Zi from the determination of Uk, Pk and
Piecewise Linear Approximations of Fewest Line Segments
qk and let Xk * = min {x I x E P, x ~ Yk * }. Then
Pk= ~k(ek, Uk, A) =uk(ek, Uk, B),
where
and
If there were no x" E (ek' Uk) such that Lb (x") =
X"Pk+qk, then Pk would equal Band sk(ek, Xi) would be
less than B for each Xi E pn (ek' Uk]. But this is impossible. For the algorithm which gives the value of Yi
insures that Sk(ek*, ek) :::;sk(ek*,xk*); and lemma 4 then
implies Sk (ek*' ek) :::;Sk (ek' Xk*). Finally, since A= + 1, we
have B=Sk(ek*, ek). Hence sk(ek, Xk*) ~B, and the
existence of an x" is established.
We suppose now that A(k) = +1 and Lb(Uk) =
UkPk+qk. Then Lt(ek) =ekPk+qk and we will show that
there exists x' E [Uk-I, ek) such that Lb(x') = X'Pk+qk.
This follows from Sk(ek, Uk) =Pk(Uk-I, ek*, ek, Yk*). For
Sk (ek' Uk) = Uk (ek' Uk, B) = ~k (ek' Uk, A), and if this is
not A, namely Pk(Uk-I, ek*, ek, Yk*), then there exists
some xiEPn(ek, Uk) such that Sk(ek, Xi) 1 the kth segment extended to the
191
left intersects the (k - 1) th segment between the x"
and Uk of lemma 5. That this approximation is extremal
follows from the observation made in the proof of
corollary 2 of lemma 5.
SAMPLE RESULTS
The appended FORTRAN program, with a suitable
driver, was run a number of times. An input parameter
determined if the approximation was to be continuous
and whether or not the deviation was to vary. If the
deviation was not to vary it was taken as the first
input tolerance.
One set of test data was the following:
INPUT DATA, NUMBER OF POINTS=20
x
Y
TOLERANCE
1.0000
2.0000
3.0000
4.0000
5.0000
6.0000
7.0000
8.0000
9.0000
10.0000
11.0000
12.0000
13.0000
14.0000
15.0000
16.0000
17.0000
18.0000
19.0000
20.0000
0.7175
0.6250
0.6250
0.6250
0.6563
0.7500
0.6563
0.6406
0.7500
0.5000
0.7500
0.6250
0.6250
0.6250
0.6563
0.7500
0.6563
0.6406
0.7500
1.0000
0.1250
0.0625
0.0625
0.1250
0.1250
0.2500
0.1250
0.0313
0.0312
0.0156
0.1250
0.0625
0.0625
0.1250
0.1250
0.2500
0.1250
0.0313
0.0312
0.0156
The results, when the deviation was taken as constant,
namely 0.125, were:
2 LINE SEGMENTS WERE REQUIRED TO
FIT THESE DATA EQUATION OF
APPROXIMATION IS Y=PX+Q
FOR U.LT.X.LT.V
P
Q
U
v
Y(U)
Y(V)
0.0
0.6250 1.0000 19.0000 0.6250 0.6250
0.3750 -6.5000 19.0000 20.0000 0.6250 1.0000
whether or not the approximation was required to be
continuous. When the deviation was permitted to vary,
192
Spring Joint Computer Conference, 1972
the results were:
The results were:
6 LINE SEGMENTS WERE REQUIRED TO
FIT THESE DATA EQUATION OF
APPROXIMATION IS Y=PX+Q
FOR U.LT.X.LT.V
P
Q
v
U
0.0113 0.5812 1.0000 8.6372
-0.0627 1.2828 8.6372 9.3075
-0.1893 2.4086 9.3075 10.0947
0.0832 -0.2904 10.0947 11.9235
0.0172 0.3621 11.9235 18.6778
0.2393 - 3. 7867 18.6778 20.0000
Y(U)
Y(V)
0.5925
0.7415
0.6467
0.5497
0.5673
0.6835
0.6791
0.6995
0.4977
0.7018
0.6835
1.0000
when the approximation was not required to be continuous, and:
6 LINE SEGMENTS WERE REQUIRED TO
FIT THESE DATA EQUATION OF
APPROXIMATION IS Y=PX+Q
FOR U.LT.X.LT.V
P
Q
v
u
0.0113 0.5812 1.0000 8.0000
0.0469 0.2965 8.0000 9.0000
-0.2032 2.5474 9.0000 10.0000
0.1094 -0.5781 10.0000 11.0000
0.0067 0.5513 11.0000 18.6084
0.2329 -3.6572 18.6084 20.0000
Y(U)
Y(V)
0.5925
0.6719
0.7188
0.5156
0.6250
0.6759
0.6719
0.7188
0.5156
0.6250
0.6759
1.0000
when the approximation was required to be continuous.
These results show that it may not require any
additional segments to have the approximation be
continuous for a given set of tolerances.
Another set of test data was:
5 LINE SEG:\IENTS WERE REQUIRED TO
FIT THESE DATA EQUATIOX OF
APPROXLUATION IS Y =PX+Q
FOR U.LT.X.LT.V
P
Q
U
v
-0.7500 4.8000 0.0
2.5333
0.2727 2.2091 2.5333 4.0000
0.8333 -0.0333 4.0000 7.4800
-0.2632 8.1684 7.4800 9.0360
- 1 . 6500 20. 7000 9.0360 12.0000
Y(U)
Y(V)
4.8000
2.9000
3.3000
6.2000
5.7905
2.9000
3.3000
6.2000
5.7905
0.9000
when the approximation was required to be continuous
and the deviation was taken as 0.2; and:
5 LINE SEGl\1ENTS WERE REQUIRED TO
FIT THESE DATA EQUATION OF
APPROXIlVIATION IS Y=PX+Q
FOR U.LT.X.LT.V
P
Q
U
v
-0.7000 4.8000 0.0
2.4530
0.0130 3.0510 2.4530 4.0000
0.7990 -0.0930 4.0000 7.9099
-0.3000 8.6000 7.9099 9.1905
-1.7237 21.6847 9.1905 12.0000
Y(U)
Y(V)
4.8000
3.0829
3.1030
6.2270
5.8428
3.0829
3.1030
6.2270
5.8429
1.0000
when the approximation was required to be continuous
and the deviation was permitted to vary.
The program will accept any non-negative tolerance
including zero. If all tolerances are zero the program
gives the parameters for linear interpolation.
INPUT DATA, NUMBER OF POINTS = 13
X
Y
TOLERANCE
0.0
1.0000
2.0000
3.0000
4.0000
5.0000
6.0000
7.0000
8.0000
9.0000
10.0000
11.0000
12.0000
5.0000
4.0000
3.1000
3.1000
3.1000
4.0000
5.0000
6.0000
6.0000
6.0000
4.0000
2.5000
1.0000
0.2000
0.1000
0.3000
0.0100
0.0030
0.2000
0.3000
0.5000
0.2000
0.1000
0.7500
1.0000
0.2000
ACKNOWLEDGMENTS
This problem was originally given to me by lVlr. Fred
Stahl of the John D. Kettelle Corporation. I am indebted to Dr. W. A. Thedford of Virginia Commonwealth University for a suggestion which led to the
modification for a continuous approximation.
Mr. W. T. Lipscomb III, a student at V.C.U.,
programmed a preliminary version of the algorithm and
in numerous discussions contributed some of the
descriptive terminology. His name appears as a coauthor of the appended listing.
Sincere appreciation goes to my wife Gwendolyn
who typed this manuscript.
Piecewise Linear Approximations of Fewest Line Segments
193
1 R BELLMAN
3 G M PHILLIPS
Algorithms for piecewise straight line approximations
The Computer J 11 2 August 1968 pp 211-212
4 H SCHWERDTFEGER
Interpolation and curve fitting by sectionally linear functions
On the approximation of curves by line segments using
dynamic programming
Comm ACM 4 6 June 1961 p 284
2 B GLUSS
Further remarks on line segment curve-fitting using
dynamic programming
Comm ACM 5 8 August 1962 pp 441-443
Canad Math Bull 3 1 January 1960 pp 41-57
5-Further remarks on sectionally linear functions
Canad Math Bull 4 1 January 1961 pp 53-55
6 H STONE
Approximation of curves by line segments
Math of Comp 15 73 January 1961 pp 40-47
REFERENCES
194
Spring Joint Computer Conference, 1972
APPENDIX
FORTRAN IV G LEVEL
C
C
C
C
MAIN
19
PIECWISE LINEAR APPROXIMATION OF FEWEST
LINE SEGMENTS WITHIN A GIVEN TOLERANCE.
BY D G WILSON AND W T LIPSCOMB III
VIRGINIA COMMONWEALTH UNIVERSITY.
C
SUBROUTINE STL(X,Y,E,N,U,P,Q,K,ITCH)
DIMENSION X(9),Y(9),E(9),U(9),P(9),Q(9)
X AND Y ARE INPUT DATA ARRAYS OF N ELEMENTS
Y = P(I)*X + Q(I) IS THE EQUATION OF THE
ITH SEGMENT OF THE PIECEWISE LINEAR APPROXIMATION. THE ITH SEGMENT EXTENDS FROM
X = UeI) to X = U(I+l1. K IS THE NUMBER
OF SEGMENTS.
IF THE INDICATOR ITCH IS
EITHER 1 OR 3, THE APPROXIMATION MUST BE
CONTINUOUS.
IF ITCH IS 2 OR 3, E IS A
TABLE OF N PERMISSIBLE DEVIATIONS..
IF ITCH
IS LESS THAN OR EQUAL TO 1, THEN E(l) IS
THE SINGLE PERMISSIBLE DEVIATION.
0001
0002
r'
C
C
C
C
C
C
C
C
C
C
C
C
C
* * * * * * * *
INITIALIZATION
* * * * *
* *
* *
* *
* *
*
c
C
FROM SCRATCH
C
.J = 1
000:3
C
C
C
C
0004
0005
C
C
0001;.
0007
000::::
0009
0010
0011
0012
001:3
0014
0015
r'
r'
C:
IS THE INDEX INTO THE U ARRAY.
ILLEGITIMATE DATA CAUSES ERROR RETURN WITH
K, THE NUMBER OF LINEAR SEGMENTS, EQUAL O.
THE MINIMUM NUMBER OF DATA POINTS IS TWO.
IF (N.LE.l) GO TO 777
IF (E(l).LT.O.O) GO TO 777
DEVIATIONS MUST BE NONNEGATIVE
CHECK FOR DATA OUT OF ORDER.
DO 29 L =. 2, N
IF (X(L-l).GE.X(L» GO TO 777
IF (ITCH.LE.l) GO TO 29
IF (E(L).LT.O.O) GO TO 777
29 CONTINUE
EP:3LN = E( 1 )
YINIT = Y(l) - EPSLN
:::;dN = 1.0
KEEP = 1
U(l) = X(l)
U(M) IS THE LEFTMOST ABCISSA VALUE FOR THE
MTH SEGMENT AND THE RIGHTMOST ABCISSA VALUE
FOR THE (M-l)TH SEGMENT.
J
I
0011:..
= 1
I IS THE INDEX INTO THE X AND Y ARRAYS.
YEYE = Y(l) + EPSLN
XEYE, YEYE ARE THE COORDINATES OF THE
CURRENT EYEPOINT.
C
0017
C
C
,-.
'-'
FOR EACH LINE SEGMENT
C
c
3!:i
0018
0019
0020
c
CONT I NUE
IF (U(J).GE.X(N» GO TO 777
TEST FOR END OF DATA
XEYE = U(.J)
Piecewise Linear Approximations of Fewest Line Segments
FORTRAN IV G LEVEL
C
rC:
0021
C
C
C
C
0022
c
002::::
0024
0025
C
r-
C
C
(l021::..
0027
C
r-
C
C
C
0029
c
c
c
STL
19
U(J-l), YINIT ARE THE COORDINATES OF
THE POINT OPPOSITE THE ORIGONAL EYEPOINT
OF THE CURRENT SEGMENT.
INIT :: 1
I NIT U:: THE I NDE X OF THE F I'R::::T 1 NPUT
X VALUE IN THE CURRENT SUBDIVISION.
THIS MAY NOT BE THE INITIAL X-VALUE
OF THE CURRENT SEGMENT.
IF (XEYE .GE. XCI») I:: 1+1
TEST FOR SEGMENT ENDING AT AN INPUT X VALUE
IF (ITCH.NE.l.AND.ITCH.LT.3) KEEP:: IN IT
IF (ITCH.GE.2) EPSLN :: SGN*E(I)
DX:: X(I) - XEYE
DX :: DISTANCE FROM CURRENT EYEPOINT TO XCOORDINATE OF POINT CURRENTLY BEING CONSIDERED. TO BE USED IN COMPUTING MAX AND MIN
SLOPES SMAX AND SMIN RESPECTIVELY
SMAX :: (Y(I) + EPSLN - YEYE)/DX
SMIN:: (YCI) - EPSLN - YEYE)/DX
IPIV :: I
IPIV IS THE INDEX OF THE RIGHTMOST DATA
POINT FOR WHICH THE CANDIDATE FOR SMAX IS
LESS THAN OR EQUAL TO THE CURRENT SMAX.
THIS LOCATES THE CANDIDATE FOR NEW EYEPOINT
IF PIVOTING IS NECE~SARY.
IGRAZE :: I
IGRAIE IS THE INDEX OF THE RIGHTMOST DATA
POINT FOR WHICH THE CANDIDATE FOR SMIN IS
GREATER THAN OR EQUAL TO THE CURRENT SMIN
.J :: .J + 1
00::::0
C
C
r-
C
C
INCREMENT INDEX INTO OUTPUT ARRAYS
END OF INITIALIZATION
*
* * * * * * * * *
* *
*
* *
*
* * *
* * *
DETERMINE MAX AND MIN SLOPES FOR SEGMENT
C
0031
0032
55 CONTINUE
c
IF (I .EI). N) GO TO 705
TEST FOR END OF DATA WITHIN CURRENT SEGMENT
I :: 1+1
00:::::::
C
00:34
0035
C
0031:..
00:37
C
003::::
00::::9
C
C
C
C
r-
0040
C
C
C
INCREMENT INDEX INTO DATA ARRAYS
57 CONTINUE
DX:: XCI) - XEYE
DX AS BEFORE
IF (ITCH.GE.Z) EPSLN :: SGN*E(I)
TEMP1 :: (Y(I) + EPSLN - YEYE)/DX
TEMP1 IS A CANDIDATE FOR SMAX
TEST :: TEMP1 - SMAX
IF (SGN.LE.O.O) TEST:: -TEST
SGN WILL BE POS IF PREVIOUS SEGMENT
ENDS AT TOP OF TUNNEL, NEG IF PREVIOUS
SEGMENT ENDS AT BOTTOM OF TUNNEL
IF SGN IS NEG CONSIDER TUNNEL TO BE UPSIDE
DOWN FOR TESTS WITH TEMPl AND TEMP2.
IF (TEST) 75, 91, 9~:;
IF CANDIDATE FOR SMAX IS GE OLD SMAX,
THEN KEEP OLD SMAX. OTHERWISE CANDIDATE
BECOMES THE NEW SMAX. EPSLN IS NEG IF
195
196
Spring Joint Computer Conference, 1972
FORTRAN IV G LEVEL
C
19
STL
INITIAL EYEPOINT IS AT BOTTOM OF TUNNEL.
75 CONTINUE
0041
C
r
r
0042
004:3
0044
004~;
004t.
0047
0048
0049
r
C
0050
0051
0052
005::::
0054
0055
C
C
r
C
C
005l:;..
0057
005::::
0059
OOt.O
CANDIDATE FOR SMAX IS LESS THAN OLD SMAX.
TEST IF CANDIDATE IS ALSO LESS THAN OLD
SMIN.
IF SO END SEGMENT AT TOP OF TUNNEL.
TEST = TEMPl - SMIN
IF (SGN.LE.O.O) TEST = -TEST
IF (TE!::;T .LT. 0.0) GO TO lZ1
!::;MAX = TENPl
91 CONTINUE
IPIV = I
95 CONTINUE
TEMP2 = (Y(I) - EPSLN - YEYE)/DX
COMPUTE CANDIDATE FOR NEW SMIN AND CONPARE
WITH OLD MINIMUM SLOPE.
TEST = SMIN - TEMPZ
IF (SGN.LE.O.O) TEST = -TEST
IF <. TE~::;T) 9}, 99, 55
97 CONTINUE
TEST = TEMPZ - SNAX
IF (SGN.lE.O.O) TEST = -TEST
COMPARE NEW CANDIDATE FOR MIN SLOPE
WITH OLD NAX SLOPE.
IF NEW MIN IS
GREATER THAN OLD MAX CHECK IF PIVOT
IS POSSIBLE. OTHERWISE SET MIN SLOPE
TO NEW VALUE AND CONSIDER NEXT DATUM.
IF (TEST.GT.O.O) GO TO 101
st'll N = TEMP2
9'~ CONT I NUE
IGRAZE = I
GO TCI 55
C
C
C
*CHECK
* * *IF *PIVOT
* * * * * * * * * * * * * * * * *
POSSIBLE
C
0061
0062
C
C
C
C
006:::
0064
0065
OOt.,~.
00/:;..7
0068
OOt.9
0070
.-.
1_.
C
C
C
007 1
0072
0073
0074
0075
101 CONTINUE
IF (XEYE.EG!.X(IPIV}) GO TO 125
X(IPIV) IS THE X-COORD OF THE LAST DATUM
FOR WHICH THE CANDIDATE FOR SMAX WAS LESS
THAN OR EQUAL TO THE OLD SMAX.
IF XEYE IS
EQUAL TO X(IPIV) NO PIVOT IS POSSIBLE.
IF (ITCH.GE.2) EPSLN = SGN*E(IPIV)
XEYE = X(IPIV)
Y( IPIV) + EP~=;LN
YEYE
Sl"lIN =
Sl"lAX = (YINIT - YEYE)/(U(J-1) - XEYE)
IF (KEEP.GE.IPIV) GO TO 105
IT = IPIV - 1
TEMP2 = YEYE + EPSLN
COMPUTE THE NIN OF THE SLOPES FROM ALL
PRECEEDING DATA POINTS OF CURRENT SEGMENT
TO (X(IPIV),Y(IPIV) + 2*EPSLN). THIS WILL
BE A FIRST APPROXIMATION TO THE NEW SMAX.
DO 103 L = KEEP, IT
IF (ITCH.GE.2) TEMPZ
= YEYE + SGN*E(L)
TEMP1 = (Y<'L) - TEMPZ)/(X(L) - XEYE)
TEST = TEMP1 - S~~X
IF (SGN.LE.O.O) TEST = -TEST
Piecewise Linear Approximations of Fewest Line Segments
FORTRAN IV G LEVEL
0076
0077
0078
0079
0080
19
STL
IF (TEST.LT.O.O) SMAX :: TEMPl
103 CONTINUE
105 CONTINUE
IF (IPIV.GE.I-1) GO TO 57
IT = I - 2
C
C
COMPUTE THE MIN OF THE SLOPES FROM ALL
SUCCEEDING DATA POINTS OF THE CURRENT
C
SEGMENT TO (X(IPIV),Y(IPIV»
IF THIS IS
C
LESS THAN THE PREVIOUSLY COMPUTED VALUE,
C
THEN IT BECOMES THE NEW SMAX.
TEMP2 = YEYE - EPSLN
DO 111 L = IPIV,IT
DX = X(L+l) - XEYE
IF (ITCH.GE.2) TEMP2 = YEYE - SGN*E(L+l)
TEMPl ::: (Y(L+l) - TEMP2)/DX
TEST ::: TEMP1 - SMAX
IF (SGN.LE.O.O) TEST = -TEST
IF (TEST) 107, 109, 111
107 CONTINUE
:::;MAX ::: TENP1
109 CONTINUE
IPIV ::: L + 1
111 CONTINUE
GO TO 57
C
0081
00:32
008:3
0084
0085
0081:.,
00::::7
0089
0090
0091
0092
009:3
0094
c
* * * * * * * * * * * * * * * * * ~ * * * *
END CURRENT SEGMENT
121 CONTINUE
TEMP2 ::: SNIN
KEEP ::: IGRAZE
c
EQ OF THIS SEGMENT IS
c
Y :: SMIN * (X - XEYE) + YEYE
NEW EYEPOINT WILL BE AT THE INTERSECTION
C
ro
OF THIS LINE WITH THE LINE BETWEEN
( X( 1-1 ) , Y( 1-1 ) +EP:::;;LN) AND (X <. I ) ,y <. I) +EP::;:LN )
C
IF (ITCH.LE.l) GO TO 135
GO TO 129
C
r
0095
0097
0098
0099
C
0100
0101
0102
0103
0104
C
ro
C
C
C
0105
C
C
0106
0107
0108
o 10':t
0110
0111
125 CONTINUE
SGN ::: -::;GN
EP:::;LN ::: -EPSLN
TENP2 ::: SMAX
KEEP:: IPIV
EQUATION OF THIS SEGNENT IS
Y :: SMAX * (X - XEYE) + YEYE
NEW EYEPOINT WILL BE AT THE INTERSECTION
OF THIS LINE WITH THE LINE BETWEEN
(X( 1--1) ,y( 1-1 )-EPSLN) AND (X( I) ,Y( I )-·EPSLN)
IF (ITCH.LE.l) GO TO 135
IF ITCH.LE.l, THEN EPSLN IS A CONSTANT
NAMELY E(l).
129 CONTINUE
TEMPl ::: EPSLN - SGN*E(I-l)
GO TO 1:37
13~i CONT I NUE
TEMPl ::: 0.0
137 CONTINUE
197
198
Spring Joint Computer Conference, 1972
FORTf~~AN
IV
13
LE',jEL
01 1'-'.::..
1 '1
TEMP1 ::: (Y(I) - Y(I-l) + TEMP1)/
(X(I) - X(I-I»)
U(J) ::: (Y(I) + EPSLN - YEYE - TEMPl *
XCI) + TEMP2*XEYE)/(TEMP2 - TEMP1)
1
P( ,J-1) ::: TE\':1P2
PCM) IS THE SLOPE OF THE MTH SEGMENT
Q(J-l) ::: YEYE - TEMP2 * XEYE
Q(M) IS THE INTERCEPT OF THE MTH SEGMENT
YEYE::: TEMP2*U(J) + Q(J-l)
(XEYE,YEYE) WILL BE THE COORDINATES OF THE
NEW EYEPOINT.
XEYE WILL BE SET TO U(J).
IF SEGMENT ENDS AT BOTTOM OF TUNNEL, THEN
START NEXT SEGMENT WITH EYE POINT AT BOTTOM
OF TUNNEL.
IF SEGMENT ENDS AT TOP, START
NEXT WITH EYEPOINT AT TOP OF TUNNEL.
TEMP 1 ::: EP!:::LN
IF (ITCH.LE.l) GO TO 141
TEMP1 ::: EPSLN + (SGN*E(I-1) - EPSLN)*
1
(XCI) - U(.J»/(X(I) -, XCI-l»
1.41 CONTINUE
YINIT ::: YEYE - TEMP1 - TEMP1
IF APPRO X MUST BE CONTINUOUS, THEN U(J-l)
MAY HAVE TO BE RECOMPUTEDo
IN THIS CASE
ITCH WILL BE 1 OR :3.
IF (ITCH.NE.l.AND.ITCH.LT.3) GO TO 35
145 CONTINUE
IF (INIT.EQ.l) GO TO 35
IF INIT IS 1 THE CURRENT SEGMENT IS THE
INITIAL SEGt1ENT.
IF (XEYE.EQ.U(J-1» GO TO 35
IF XEYE IS STILL U(J-1), THEN NO PIVOT WAS
MADE AND U(J-1) NEED NOT BE RECOMPUTED.
U(J-1) :::(Q(J-2) - Q(J-1»/
(P(J-1) - P(J-2»
1
GO TO :::5
* * * * * * * * * * * * * * * * * * * * * *
END OF DATA ENCOUNTERED
1
01 1 ,-',
.~
01 14
C
01 15
C
01 1/;.
c·-'
C
r'-'
C
C
r'
01 17
01 1'-'1='
01 19
0120
0121
C
C
C
0122
012:3
0124
C
0125
c
c
0126
0127
C
C
C'
0128
0129
01::::0
01:31
01:32
01:3:3
01::::4
01:35
01 :36
705 CONTINUE
U(.J) ::: X(N)
P(J-l) ::: O.5*(SMAX + SMIN)
Q(J-l) ::: YEYE - XEYE * P(J-l)
IF (ITCH.EQ.l.0R.ITCH.GE.3) GO TO 145
777 CONTINUE
K:::.J-l
RETURN
END
Experimental results on a new computer method for
generating optimal policy variables in (s, S) inventory
control problem
by P. E. VALISALO, B. D. SIVAZLIAN and J. F. MAILLOT
University of Florida
Gainesville, Florida
computer and on the analog computer. The feasibility
of using analog computers was demonstrated in a set of
experiments published in 1970 by Sivazlian and
Valisalo. 5 By using dimensional analysis and using
numerical inversion techniques for Laplace transforms,
Sivazlian4 generated a set of graphs for the case of
gamma distribution demand with integer order, to
obtain the optimal values of Sand Q for all possible
values of input variables. The computational feasibility
of the problem was also discussed.
Although both analog and digital computer techniques proved successful, certain computational
deficiencies were encountered in both methods. In
using analog computers, experimental errors were
generated when increasing the number of integrators.
Further the derivation of results for complex demand
distrib~tions was limited by the capability of the
analog computer system. In using digital computation,
the discretization of the problem and the numerical
method utilized could generate solution instability.
These two deficiencies were ultimately resolved by
combining the conceptual basis of analog computation
with the capacity and speed of digital computers by
using the Continuous Simulation and Modeling Programming (C.S.M.P.) on the IBM 360/65 digital
computer. The C.S.M.P. is a simulation language which
works on block diagrams as an analog computer does
but which utilizes a digital program. The present paper
presents preliminary results obtained using this computation technique and discusses some inherent merits
of this method.
INTRODUCTION
The problem of developing a computable solution to
the optimal periodic review stationary (S, S) inventory
control problem has not received the same level of
attention as the theoretical works first initiated in 1951
by the well-known paper of Arrow, Harris, Marschak. 1
Even for some of the simplest situations, perhaps
closest to practice, involving a fixed set-up cost, and a
linear holding and shortage cost, the solution to the
mathematical problem of determining the optimal
values of Sand S to minimize the total expected cost
per period, requires the formal solution of an integral
equation of the Volterra type and an optimization
problem of a fairly complex objective function involving the decision variables Sand S.
Explicit theoretical solutions for sand S can be
obtained as computable formulas for some very simple
demand distributions as for example the negative
exponential distribution. Approximations to the optimal
solutions were proposed by Roberts 2 in 1962. In 1965,
Veinott and Wagner6 developed an algorithmic procedure applicable to instances when the demand
distribution is described by a discrete random variable;
the study fails to discuss the computational efficiency
of the algorithm and its usability in practice particularly
in relation to the large number of input variables (at
least five) which are necessary to compute a single pair
of optimal values of (S, S). In practice, this facet of the
computational problem cannot be ignored since inventory control involves usually several thousand of
commodities, e~ch commodity necessitating frequent
updating of the set of input variables due to changes in
economic or other conditions. In 1968, Sivazlian3
derived a set of equations to compute the optimal
values of Sand Q= S - S and developed conceptual
approaches to solve these equations on the digital
THEORETICAL CONSIDERATIONS
A brief discussion of the theoretical results as obtained by Sivazlian3 is necessary.
199
200
Spring Joint Computer Conference, 1972
TABLE I
Xl2 = REALPL(O. ,P, XII)
XI3=REALPL(0. ,P,XI2)
XI4=REALPL(0. ,P,X13)
XI5=REALPL(0. ,P,XI4)
XI6=REALPL(0. ,P,XI5)
XI7=REALPL(0. ,P,XI6)
****CONTINOUS SYSTEM MODELING PROGRAM****
***PROBLEM INPUT STATEMENTS***
INITIAL
P=IO.jX
A=XjIC.
PARAM S=(O. ,2. ,4. ,6. ,8., 12.),X=19.
DYNAMIC
XLO=O.
XLI =REALPL(A,P,XLO)
XL2 = REALPL(O. ,P, XLI)
XL3 = REALPL(O. , P, XL2)
XL4 = REALPL(O. , P, XL3)
XL5 = REALPL(O. , P, XL4)
XL6 = REALPL(O. ,P, XL5)
XL7 =REALPL(O., P, XL6)
XL8=REALPL(0. ,P,XL7)
XL9 = REALPL(O. , P, XL8)
XLlO = REALPL(O. ,P, XL9)
XLll =REALPL(O. ,P,XLlO)
XLI2=REALPL(0. ,P,XLll)
XLI3=REALPL(0. ,P,XLI2)
XLl4 = REALPL(O. ,P, XLI3)
XLI5=REALPL(0. ,P,XLI4)
XLI6 = REALPL(O. ,P, XLI5)
XLI7=REALPL(0. ,P,XLI6)
XLl8 = REALPL(O. ,P, XLI7)
XLI9=REALPL(0. ,P,XLI8)
XLD = 11. *XLI9
SM=XI9-XL
XL=INTGRL( -10. ,XLD)
PROCED C=BLOC(TIME,S)
XI8=REALPL(0. ,P,XI7)
XI9 = REALPL(O. ,P, XI8)
BM=INTGRL(O. ,SMI)
FINISH SM = O.
Consider the periodic review inventory control
problem of a single commodity system where the
demand per period for the commodity is described
by a continuous random variable ~ (0 < ~ < 00) with
probability density function ¢(O identically and
independently distributed from period to period. Assume
that the following cost components affect the operation
of the system: a fixed order cost K, a holding cost and
a shortage cost. Complete backlogging is allowed and
delivery of orders is immediate. Let L (x) be the expected holding and shortage cost over one period when
the stock level at the beginning of the period following
a decision is x. An (S, S) policy is in effect, that is,
whenever the stock level at the beginning of a period
lies between Sand S, no order is placed, and whenever
the stock level falls below S, it is brought up to S. It
can be shown3 ,4 that for S 2:: 0 the values of Sand
Q = S - S which minimize the total expected cost per
period for the stationary inventory system are solutions
to the system of equations
(1)
m(S, Q) =0
and
IF(TIME-S)I,2,2
C=O.
GOT03
2 C=1.
3 CONTINUE
ENDPRO
fQ m(S, x) dx=K
1
SMI=C*SM
Xl = REALPL(O. ,P, SMI)
X2=REALPL(0. ,P,XI)
X3 = REALPL(O. ,P ,X2)
X4=REALPL(0. ,P,X3)
X5=REALPL(0. ,P,X4)
X6=REALPL(0. ,P,X5)
X7=REALPL(0. ,P,X6)
X8 = REALPL(O. ,P ,X7)
X9 = REALPL(O. ,P, X8)
XIO=REALPL(O. ,P,X9)
XU = REALPL(O. ,P, XIO)
(2)
o
where m (S, x) satisfies the Volterra integral equation
2 (6+x)
m(.6 ,x)
+
-1
~(s)
Figure I-Feedback system simulating the equation
m(S, x) = - l(S
+ x) + 1:1) m(S, x
- u) cp (u) du
Experimental Results on a New Computer Method
Figure 2-Flow chart for the digital simulation when h
p = 10, n = 4 and a = .40
201
1,
100
Q
m(S, x) =-L'(S+x)+
IX m(S, x-~)cp(~) d~
(3)
Figure 4-C.S.M.P. results for m(S, x) when n = 1, a = .1 and
increments of .01
o
Let
p is the unit shortage cost. Differentiating (4) with
respect to x, we obtain the following expression for l(x) :
l(x) =L'(x)
l(s, S) =£{l(S+x)}
l(x) = (h+p)
([>(s) =£{cp(x)}
We shall restrict our attention to the case when
Then, from taking the Laplace transforms on both sides
of (3) and solving for fii(S, s) we obtain
Thus, the integral equation (3) can be solved using the
feedback system of Figure 1.
The optimal values Sand Q can be determined by
observing that the output function m (S, x) must
satisfy equations (1) and (2). The interesting practical
case which was investigated was the following:
Assume. proportional holding and shortage costs,
measured at end of period, then
IX (x-u)cp(u) du+p f""
o
cp ( .) is a gamma density function of integer order n,
i.e.,
cp(~)
) _ -l(s, s)
m S, s - 1- ([> ( s )
L(x) =h
(5)
o
fii(s, S) =£{m(S, x)}
_(
IX cp(u) du-p
(u-x)cp(u) du
x
(4)
In inventory terminology, h is the unit holding cost and
(a~) n-l
= (n-1)!
ae-a~a>O,
n=1, 2, ...
(6)
Note then that in the s domain
([>(s) =an/(s+a)n
n=1, 2,...
(7)
THE CONTINUOUS SYSTEM MODELING
PROGRAM AND EXPERIMENTAL RESULTS
For illustrative purpose the numerical values of h = 1,
p = 10 and a = .1 On were used. The selection of this
particular value of a yields an expected demand of 10
units per period irrespective of the order of the gamma
distribution. In Reference 5 a parallel connection was
used to generate the gamma distribution. In contradistinction, a series connection is used in this paper
involving a cascade of n filters of a/ (s+a). Thus, the
103
Q
Figure 3-Analog equivalent of Figure 2
Figure 5-C.S.M.P. results for m(S, x) when n = 4, a = 4 and
increments of .01
202
Spring Joint Computer Conference, 1972
TABLE II-n = 1. Comparison Data for Alternative Methods Used in Solving for Q and K
Q
S
Analog
0
K
Digital
1.0 (inc.)
Digital
0.1 (inc.)
Digital
0.01 (inc.)
100.0
100
100
Analog
Digital
1.0 (inc.)
Digital
0.1 (inc.)
500
499.9
499.4
Digital
0.01 (inc.)
2
78.9
81
79
80
315.7
332.6
319.2
320.1
4
62.9
64
63
63
200.6
211.0
202.3
203.1
6
49.7
51
50
50
124.9
132.0
126.3
126.8
8
38.9
40
39
39
76.4
81.0
77.4
77.7
12
22.8
23
23
23
26.2
28.0
26.6
26.8
$ 2.45
$ 3.05
$ 8.52
Computing Cost
S, then c = -1 thus initiating the feedback loop. At the
same time, the last integrator marked 1/s is turned on
on operate mode. The logic part has been left out in
Figure 3 for the sake of simplicity and because it has
well been defined in Reference 5. The C.S.M.P. program
for n= 1 to n= 19 (Table I) ,vas so designed as to print
out the Q and K values when the function m (S, x)
reaches zero.
entire problem was to be redesigned in such a way that
the number of feedback loops as used in the original
analog circuitry5 was eliminated; instead, a serial first
order loop approach was implemented. Figure 2
illustrates the flow chart of the digital simulation when
n=4, while Figure 3 is the analog equivalent of Figure
2. Referring to Figure 2, when time is less than S, c = 0
and the feedback loop is idle. When time is greater than
TABLE III-n=4. Comparison Data for Alternative Methods Used in Solving for Q and K
K
Q
S
Analog
Digital
1.0 (inc.)
Digital
0.1 (inc.)
Digital
0.01 (inc.)
Analog
Digital
1.0 (inc.)
0
102.9
103
103
103
528.5
537.4
537.4
537
2
81.8
83
81
81
338.4
354.5
338.3
339.5
4
60.0
62
60
60
189.4
201.5
190.2
191.3
6
41.6
43
41
41
94.1
100.8
94
94.6
8
26.5
27
26
26
41.1
44.2
40.8
41.1
12
7.1
7
6
6
5.6
5.8
5.2
5.3
Computing Cost
$ 2.59
Digital
0.1 (inc.)
$ 3.66
Digital
0.01 (inc.)
$ 12.37
Experimental Results on a New Computer Method
DISCUSSION
A significant marked improvement results for the
output function m (S, x) ; this is illustrated in Figures
4, 5 and 6 for values of n= 1, 4 and 19 respectively.
The fact that the function m (S, x) can be generated
for a gamma distribution of an order as high as n= 19
is significant, particularly in the context of previous
work.
Tables II and III report respectively some of the
numerical results for n = 1 and n = 4 obtained from
analog computation and digital computation using
C.S.M.P. Increments of 1.00, .10 and .01 were used for
comparison purposes.
I t may be noticed that the order of magnitude of n
depends on the size of the analog installation, 5 whereas
the digital does not seem to have any limitations on the
103
Q
Figure 6-C.S.M.P. results for m(S, x) when n = 19, a = 1.9 and
increments of .01
203
value of n at all. It is evident that the advantage of the
analog system is not present in the discretized problem
particularly when an immediate visual or graphical
picture is desired for m (S, x) .
REFERENCES
1 K J ARROW T HARRIS Y MARSHAK
Optimal inventory policy
Econometri,ca 19 1951 pp 250-272
2 D M ROBERTS
A pproximations to optimal policies in a dynamic inventory
model
Studies in Applied Probability and Management ScienceK J Arrow S Karlin H E Scarf eds Stanford University
Press 1962 pp 207-229
3 B D SIVAZLIAN
Optimality and computation of the stationary (s, S) inventory
control problem
Technical Report No 7 Project THEMIS Department of
Industrial and Systems Engineering The University of
Florida Gainesville Florida May 1968
4
Dimensional and computational analysis in stationary
(s, S) inventory problems with gamma distributed demand
Management Science Vol 17 1971 pp 307-311
5
P E VALISALO
The utilization of a hybrid computer system in solving for
optimal policy variables in inventory problems
Proceedings of the Sixth AICA Congress Munich Germany
August 31-September 4 1970
6 A F, VEINOTT JR H M WAGNER
Computing optimal (s, S) inventory policies
Management Science Volume 111965 pp 525-552
Bounds on multiprocessing anomalies
and related packing algorithms
by R. L. GRAHAM
Bell Telephone Laboratories, Inc.
Murray Hill, New Jersey
essential to have on hand the worst examples one can
think of before conjecturing and (hopefully) proving
bounds on worst-case behavior, numerous such examples will be given throughout the text.
Before concluding this section} it seems appropriate
to make a few remarks concerning the general area of
these topics. Recent years have seen the emergence of
a vital and important new discipline, often called
"analysis of algorithms." As its broad objective, it
seeks to obtain a deeper understanding of the nature of
algorithms. These investigations range, for example,
from the detailed analysis of the behavior of a specific
sorting routine, on one hand, to the recent negative
solutiont to Hilbert's Tenth Problem by j\'iatijasevic 37
and Julia Robinson,43 on the other. It is \vithin this
general framework that the present. discussion should
be viewed.
INTRODUCTION
It has been known for some time that certain rather
general models of multiprocessing systems frequently
exhibit behavior which could be termed "anomalous,"
e.g., an increase in the number of processors of th2
system can cause an increase in the time used to complete a job. 42 ,36,2o In order to fully realize the potential
benefits afforded by parallel processing, it becomes important to understand the underlying causes of this
behavior and the extent to which the resulting system
performance may be degraded.
In this paper we survey a number of theoretical results obtained during the past few years in connection
with this topic. We also discuss many of the algorithms
designed either to optimize or at least to improve the
performance of the multiprocessor system under
consideration.
The performance of a system or an algorithm can be
measured in several rather different ways.5 Two of the
most common involve examining the expected behavior
and the worst-case behavior of the object under consideration. Although knowledge of expected behavior
is generally more useful in typical day-to-day applications, theoretical results in this direction require assumptions concerning the underlying probability distributions of the parameters involved and historically
have been extremely resistant to attack.
On the other hand, there are many situations for
which worst-case behavior is the appropriate measure
(in addition to the fact that worst-case behavior does
bound expected behavior). This type of analYEis is currently a very active area of research, and theoretical
insight into the worst-case behavior of a number of
algorithms from various disciplines is now beginning to
emerge (e.g., see References 7, 14, 15, 19,20,21,26, 27,
29, 32, 33, 44, 47, and especially Reference 41.) It is
this latter measure of performance which will be used
on the models and algorithms of this paper. Since it if:!
A GENERAL MULTIPROCESSING SYSTEM
Let us suppose we have n (abstract) identical processors Pi, i = 1, ... , n, and we are given a set of tasks
::I = {Tli ... , T r} which is to be processed by the Pi.
Weare also given a partial order t t < on ::I and a function ,u:::I~(0, 00). Once a processor Pi begins to execute
a task Tj, it works without interruption until the completion of that task, t t t requiring altogether ,u (T j ) units
of time. It is also required that the partial order be
respected in the following sense: If T i < T j then T j cannot be started until Ti has been completed. Finally,
we are given a sequence L = (T io . . . , T i r ) , caJled the
t Which roughly speaking shows that there is no universal
algorithm for deciding whether a diophantine equation has
solutions or not.
tt See Reference 31 for terminology.
ttt This is known as nonpreemptive scheduling as opposed to
preemptive scheduling in which the execution of a task may be
in terrupted. 5
205
206
Spring Joint Computer Conference, 1972
~O
T1/3 0
T9/ 9
T1
T3
T9
3
2
9
T5/4
T2/2
Ts/4
T3/ 2
0':
T7/4
Ta/4
T4/ 2
T2
T5
¢1
2
4
4
T4
T6
Ts
¢2
2
4
4
4
Figure 3-The timing diagram D' when L' is used
Figure 1-A simple graph G
(priority) list (or schedule) consisting of some permutation of all the tasks 3. The Pi execute the T j as follows:
Initially, at time 0, all the processors (instantaneously)
scan the list L from the beginning, searching for tasks
Ti which are "ready" to be executed, i.e., which have no
predecessors under <. The first ready task T j in L
which Pi finds immediately begins to be executed by
Pi; Pi continues to execute T j for the p,(Tj) units of
time required to complete T j • In general, at any time
a processor Pi completes a task, it immediately scans
L for the first available ready task to execute. If there
are currently no such tasks, then Pi becomes idle. We
shall also say in this case that Pi is executing an empty
task which we denote by 'P (or 'Pi). Pi remains idle until
some other P k completes a task, at which time Pi
(and, of course, P k ) immediately scans L for ready
tasks which may now exist because of the completion
of T j • If two (or more) processors both attempt to
start executing a task, it will be our convention to
assign the task to the processor with the smaller index.
The least time at which all tasks of T have been completed will be denoted by w.
We consider an example which illustrates the working of the preceding multiprocessing system and various
anomalies associated with it. We indicate the partial
order < on T and the function p, by a directed graph t
0:
T,
T9
3
9
T2
T5
T7
2
4
4
T3
T6
Ts
2
4
4
Figure 2-The timing diagram D for G
t For terminology in graph theory, see Reference 23.
G ( <, p,). In G ( <, p,) the vertices correspond to the T i
and a directed edge from Ti to T j denotes T i < T j. The
vertex T j of G( <, p,) will usually be labeled with the
symbols Tj/p,(Tj). The activity of each Pi is conveniently represented by a timing diagram D (also
known as a Gantt chart. 2 D consists of n horizontal
half-lines (labeled by the Pi) in which each line is a
time axis starting from time and is subdivided into
segments labeled according to the corresponding
activity of the Pi. In Figure 1 we show a simple graph
°
G.
In Figure 2, we give the corresponding timing diagram
D assuming that the list L= (TI' T 2 , ••• , T 9 ) is used
with·three processors. The finishing time is w = 12.
Note that on D we have labeled the intervals above by
the task and below by the length of time needed to
execute the task.
It is evident from the definition of w that it is a
function of L, p" < and n. Let us vary each of these
four parameters in the example and see the resulting
effect this variation has on w.
(i) Replace L by L' = (Tl; T 2, T 4 , T 5, T 6 , T a, T 9,
T 7 , T s), leaving p" < and n unchanged (Figure
3). For the new list L', w'=w'(L', p" <, n) =14.
(ii) Change < to <' by removing T4 < T5 and
T 4 0) by varying anyone of the three parameters L, J.I..
and <. Note that (2) implies that using the worst
possible list instead of the best possible list still only
results in an increase in w of at most a factor of 2-1/n.
When n = 1, (1) implies w'l w~ 1 which agrees with
the obvious fact that the aforementioned changes in
L, J.I.., < and n can never cause increase in the running
time when compared to that for single processor. On
the other hand, when n> 1 then even a large increase
T
02
T
1
I
'°
,
'f':
T 1004
1<1>
1000
€
w=1000+2£
Figure 12-2 processors are used to execute the tasks of G
fSince a partial order on J is a subset of J X J, <' C < has the
obvious meaning.
tt Recent examples of M. T. Kaufman (personal communication)
show that in many cases the bounds of (1) and (2) can be achieved
even when J.!(T) = 1 for all T.
PI
P2
D':
P3
T,
T4
T lOO4
C
1
1000
T2
T5
<1>
C
1
1000
T3
Ts
c
1
11000 <1> T 1OO3
€
1
<1>
1000
w'=1001+€
<1>
1000
Figure 13-1000 processors are used to execute the tasks of G
SOME SPECIAL BOUNDS
We next consider results arising from attempts at
finding lists which keep the ratio of wiWo close to one.
Since for any given problem, there are just finitely
many possible lists then one might be tempted to say:
"Examine them all and select the optimum." Not much
insight is needed, however, to realize that due to the
explosive growth of functions such as n!, this is not a
realistic solution. What one is looking for instead is an
algorithm which will guarantee that wi Wo is reasonably
close to one provided we are willing to expend an appropriate amount of energy applying the algorithm. Unfortunately, no general results of this type presently
exist. There is a special case, however, in which steps in
this direction have been taken. This is the case in which
< is empty, i.e., there are no precedence constraints
between the tasks. We shall restrict ourselves to this
case for the remainder of this section.
Suppose, for some (arbitrary) k, the k tasks with the
largest values of J.I.. have been selected t and somehow
t i.e., holding a processor idle when it could be busy and interrupting the execution of a task before completion.
t Recent results of Blum, Floyd, Pratt, Rivest and Tarjan41 allow
this to be done in no more than 6r binary comparisons where r
denotes the number of tasks.
Bounds on lVlultiprocessing Anomalies
arranged in a list Lk which is optimal with respect to
this set of k tasks (i.e., for no other list can this set of
k tasks finish earlier). Form the list L(k) by adjoining
the remaining tasks arbitrarily but so that they follow
all the tasks of L k • Let w (k) denote the finishing time
using this list with a system of n processors. If Wo denotes
the global optimum, i.e., the minimum possible finishing time over all possible lists then the following result
holds.
w(k) <1+ I-I/n
Wo 1+ [k/n]
°1
°2n-2
°2
°2n-3
Do:
wo"'3n
P
«n-2
n-2
Pn- 1
Pn
°n+1
an
°n-1
a2n
°2n-1
°2n+l
n
for 1:=:;i:=:;k+1,
order for w(k) to be assured of being within 10 percent
of the minimum value Wo, for example, it suffices to
optimally schedule the largest 9n tasks.
Another heuristic technique" for approximating the
optimal finishing time Wo is to use the "decreasing"
listt L*= (Til' T i2 , ... ) where Jl(TiJ '2.Jl(T i2 ) '2. ....
The corresponding finishing time w* satisfies the following inequality.
I
for k+2:=:;i:=:;k+l+n(n-I).
Theorem. 20
(3)
For k=O(mod n) this bound is best possible.
For the case of k=O(mod n) the following example
establishes the optimality of the bound from below.
For 1:=:;i:=:;k+1+n(n-1), define Jl(T i ) by
Jl(T i ) =
{
For this set of tasks and the list L (k) = (Tl' ... , T k ,
T k +2, ... , T k+1+n(n-l) , T k+1 ) we have w(k) =k+2n-1.
Pi
P2
0*: P3
Pn
P2
Figure I5-The timing diagram Do using an optimal list
Theorem. 20
Pn - 1
Pi
209
°1
°2n
°2
a 2n - 1
°3
°2n+1
°2n-2
°n-1
On+2
On
°n+l
w*= 4n-1
Figure I4-The timing diagram D* using the decreasing list L*
This bound is best possible.
For n= 2, (6) yields a bound of 7/6 which is exactly
the ratio obtained from the canonical example vdth
five tasks having execution times of 3, 3, 2, 2 and 2.
More generally, the follmving example shows that (6)
is exact. ;) consists of r = 2n+ 1 independent tasks Tk
with Jl(Tk) =ak=2n-[(k+I)/2] for l:=:;k:=:;2n and
Jl(T2n+1 ) =a2n+l=n (where [x] denotes the greatest
integer not exceeding x). Thus
= (2n-l, 2n-l, 2n-2, 2n-2, . .. ,n+l, n+l, n, n, n)
In Figure 14, ;) is executed using the decreasing list
L* = (Tl' T 2, ... , T 2n+1 ).
In Figure 15,;) is executed using an optimal list.
Since wo=k+n, and k=O(mod n) then
w(k)=I+ l-l/n
Wo
l+[k/n]
as asserted.
For k=O, (3) reduces to (2) while for k=n we have
w(n)/wo:=:;3/2-1/2n.
(6)
w* / wo:=:; 4/3 -1/3n.
(4)
The required optimal assignment of the largest n tasks
to the n processors is immediate-just assign each of
these tasks to a different processor. For k = 2n, .(3)
reduces to
(5)
w(2n)/wo:=:;4/3-1/3n,
a bound which will soon be encountered again.
An important property of (3) is that the right-hand
side tends to I as k gets larger compared to n. Thus, in
T1
T1
6
6
cp
T2
T3
T2
T4
3
3
3
2
T4
T5
T3
2
2
3
Wo =6
w(6) =7
Figure I6-Example illustrating difference between L* and L(2n)
t Such a list can be formed in essentially no more than r log r Ilog 2
binary comparisons. 33
210
Spring Joint Computer Conference, 1972
It is interesting to observe that although the righthand sides of (5) and (6) are the same, arranging the
tasks by decreasing execution time does not necessarily
guarantee that the largest 2n tasks will be executed
optimally by L*. An example showing this (due to
J. H. Spencer (personal communication» is given in
Figure 16. The execution times of the tasks are
(6,3,3, 2, 2, 2) and three processors are used.
The following result shows that if none of the execution times is large compared to the sum of all the execution times then w* cannot be too far from woo
Theorem. IS
If
problems seems remote indeed. There are several special
cases, however, for which such algorithms exist.
For the case when Jl. (T) = 1 for all tasks T and < is a
forest, t Hu28 has shown that the following algorithm
generates an optimal list Lo.
(i) Define the level A(T) of any terminal t t task T
to be 1.
(ii) If T' is an immediate successor of T, define
A(T) to be A(T') +1.
(iii) Form the list Lo= (Til' T i2 , ... , Ti r ) in order of
decreasing A values, i.e., A(Til ) C:.A(Ti2) C:. ••• C:.
A(Tir ) •
Theorem. 2s
< is empty and
Lo is an optimal list when Jl. (T) = 1 for all T and
max Jl. (T) / ~ Jl. (T) ~ (3
< is a tree.
T
then
(7)
Another approach is to start with a timing diagram
resulting from some arbitrary list and then make pairwise interchanges between tasks executed by pairs of
processors which decrease the finishing time, until this
can no longer be done. If w' denotes the final finishing
time resulting from this operation then it can be shown18
that
w'/wo~2-2/(n+1)
(8)
and, furthermore, this bound cannot be improved.
SOME ALGORITHMS FOR OPTIMAL LISTS
There seems little doubt that even for the case when
is empty, Jl.(T) is an integer, and n=2, any algorithm which determines an optimal list for any set of
tasks must be essentially enumerative t in its computational efficiency. This problem can be rephrased as
follows:
<
Given a sequence S= (81, ... ,8 r ) of positive integers
find a choice of ei = ± 1 such that
The only other case for which an efficient algorithm
is currently known is when Jl. (T) = 1 for all T, n = 2 and
< is arbitrary. In fact, two quite distinct algorithms
have been given. One of these, due to Fujii, Kasami
and Ninomiya ll ,12 is based on a matching algorithm for
bipartite graphs of Edmonds 8 and appears to be of
order O(r3). The other, due to Coffman and Graham,3
uses the following labeling technique:
Assuming there are r tasks, each task T will be assigned a unique label a(T)e{1, 2, ... ,r}.
(i) Choose an arbitrary terminal task To and define
aCTo) = 1.
(ii) Assume the values 1, 2, ... , k-1 have been
assigned for some k~r. For each unlabeled task
T having all its immediate successors already
labeled, form the decreasing sequence M (T) =
(ml' m2, ... , m5) of the labels of T's immediate
successors. These M (T) are lexicographicallyt
ordered. Choose a minimal M (T') in this order
and define a (T') = k.
(iii) Form the list L*= (Til' T i2 , ... , TiT) according to decreasing a values, i.e., a(Ti l ) >
a(Ti2) > ... >a(Tir ).
Theorem. 3
L* is an optimal list when Jl. (T) = 1 for all T and
n=2.
is minimized.
Thus any hope for efficient algorithms which produce
optimal schedules for more general multiprocessing
t More precisely, the number of steps it may require cannot be
bounded by a fixed polynomial in the number of bits of information needed to specify the input data.
t This means that every task T has at most one immediate
successor T', i.e., T < T' and for no Til is T < Til < T'. Actually, by adding a dummy task To preceded by all other tasks, <
can be made into a tree, without loss of generality.
tt i.e., a task with no successor.
t i.e., dictionary order, so that (5, 4, 3) precedes (6, 2) and
(5, 4, 3, 2).
Bounds on lVlultiprocessing Anomalies
This algorithm has been shown to be of order 0 (r 2 )
and so, in a sense, is best possible since the partial
order < can also have this order of number of elements.
The increase in complexity of this algorithm over
Hu's algorithm seems to be due to the greatly increased
structure an arbitrary partial order may have when
compared to that of a tree. Even relatively simple
partial orders can defeat many other algorithms which
might be thought to be optimal for this case. The example in Figure 17 illustrates this.
An optimal list for this example is L*= (T10 , T 9 , • • • ,
T 1 ) where we assume p,(Ti) = 1 for all i. Any algorithm
which allows TlO not to be executed first is not optimal, as,
for example, executing tasks on the basis of the longest
chain to a terminal task (i.e., according to levels), or
executing tasks on the basis of the largest number of
successors.
For n>2 and p,(T) = 1 for all T, the algorithm no
longer produces optimal lists as the example in Figure 18
shows.
It would be interesting to know the worst-case behavior
of the lists produced by this algorithm for general n.
The current state of affairs here seems to be similar
to that of the job-shop scheduling problem5 ,30 for which
optimal schedules can be efficiently generated when
n = 2, while for n> 2 no satisfactory algorithms are
known.
211
Tg
Ta
Figure 18-A counterexample to optimality when n
=3
L which (approximately) minimizes the finishing time
w. We now invert this question as follows: For a fixed
A DUAL PROBLEM
Up to this point, we have generally regarded the
number of processors as fixed and asked for the list
Tg
deadline w*, we ask for a list L which when used \yill
(approximately) minimize the number of processors
needed to execute all tasks by the time w*. Of course,
the two questions are essentially equivalent, and so no
efficient algorithms are known for the general case. t
Nevertheless, a number of recent results are now available for several special cases and these will be the subject of this section.
We first make a few remarks concerning the general
case. It is not hard to see that if A* denotes the length
of the longest chain t t in the partially-ordered set of
tasks 3, then we must have W*~A*. Otherwise, no number of processors could execute all tasks of 3 in w* time
units. On the other hand, if sufficiently many processors
are available then all tasks of 3 can be executed in
time A*. In fact, if m* denotes the maximal number of
mutually incomparable t tasks of 3, then it is never
necessary to have more than m* processors in the system since clearly no more than m* can be in operation
at anyone time.
t Both of these questions are raised in Reference 10.
tt i.e., a sequence T i1 < T i2 < ... < Tim with Lk IJ. (T iJ
Ta
Figure 17-A useful graph for counterexamples
maximal.
t T i and T i are incomparable if neither T i
hold.
<
T i nor T i
<
Ti
212
Spring Joint Computer Conference, 1972
For the case in which J.I. (T) = 1 for all tasks T, lower
bounds for both problems are provided by results of
HU. 28 In this case, if A(T) denotes the level of a task
T as defined in the preceding section, let m denote the
maximum level of any task in 3 and for 0 ~ k ~ m, let
A(k) denote the number of tasks having level strictly
greater than k.
this problem, but the amount of computation necessary
soon becomes excessive as the size of the problem grows.
Several heuristic algorithms have been suggested9 ,15,4o
for approximating No. One of these, which we call the
"first-fit" algorithm, is defined as follows: For a given
list L= (ai2' ai2' ... , air), the aik are successively assigned in order of increasing k, each to the box B j of
lowest index into which it can validly be placed. The
number of boxes thus required will be denoted by
NFF(L) , or just N FF , when the dependence on L is
suppressed.
If L is chosen so that ail ~ ai2 ~ ••• ~ air then the
first-fit algorithm using this list is called the "first-fit
decreasing" algorithm and the corresponding NFF(L)
is denoted by N FFD.
Instead of first-fit, one might instead assign the next
ak in a list L to the box in which the resulting unused
capacity is minimal. This is called the "best-fit"
algorithm and N BF will denote the number of boxes
required in this case. The corresponding definitions of
"best-fit decreasing" and N BFD are analogous to first-fit
decreasing and N FFD and are omitted.
One of the first questions which arises concerning
these algorithms is the extent by which they can ever
deviate from No. Only for N FF is the behavior accurately
known.
Theorem. 28
Theorem. 47 ,15
16
10(X5)
50
6(X7)
42
34
34
51
51
(X 3)
(X 7)
51
(X5)
Figure 19-An example with N FF IN 0
(X10)
= 17/10
If n processors can execute 3 with finishing time w
then
(9)
w~ max (k+A(k)/n).
oSk'::;m
For other early results dealing with these and related
problems, the reader may consult References 1, 5, 13,
24, 38, 42, 45, and 46.
For the remainder of this section, we restrict ourselves
to the special case in which there are no precedence
constraints on the tasks. In this case the second problem
becomes a special case of the one-dimensional cutting
stock problem15 ,17 as well as a special case of the assembly-line balancing problem. 5
We can also think of the problem in the following
terms. Weare given a set of objects i,O with Oi having
weight ai=}.t(T i ), l~i~r. We have at our disposal an
unlimited supply of boxes Bj, each with a maximum
capacity of w* units of weight. It is required to assign
all the objects to the minimum number No of boxes
subject to the constraint that the total weight assigned
to any box can be no more than w*. In this form, this
question takes the form of a typical loading or packing
problem. 9 Integer linear programming algorithms have
been given9 ,16,17,25 for obtaining optimal solutions for
For any e>O, if No is sufficiently large then
NFF/No < 17/10+e.
(10)
The 17/10 in (10) is best possible. An example for
which NFF/No= 17/10 is given in Figure 19 (where
2.0
~ 1.5
0::
.-_...----
1. 0 "---1...&..1-'-1--1. ---'-1-------'-1 1 1
"'7654 3 2
---1.
a
Figure 20-The function R(a)
Bounds on l\1ultiprocessing Anomalies
w* = 101). The multiplicity of types of boxes and objects are given in parentheses.
For any e>O examples can be given with NFF/No~
17/10-e and No arbitrarily large. It appears, however,
that for No sufficiently large, N FF/ No is strictly less
than 17/10.
In order to achieve a ratio NFF/No close to 17/10 it is
necessary15 to have some of the Oli exceed w* /2. Conversely, if all Oli are small compared to w* then NFF/No
must be relatively close to one. This is stated precisely
in the following result.
.1
5
2
"5
~+2£
5
(X5n)
NFFD=11n:
1-8
£
5£
2
!-£
2
(X5)
(X5n)
(Xn)
5"
(X5n)
The right-hand side of (11) cannot be replaced by any
smaller function of a.
We denote the right-hand side of (11) by R(Ol) and
illustrate it in Figure 20.
It is conjectured15 that the worst-case behavior of
NBF/No is the same as that of NFF/No but this has not
yet been established. It is known that R(Ol) is also a
lower bound for NBF/No when max Oli~OlW*.
As one might suspect, N FFD/ No cannot differ from
1 by as much as N FF/ No can. This is shown in the
following result.
(X5n)
5"
~+2£
5
Suppose max Oli/W*~Ol. Then for any e>O, if No is
sufficiently large then
(11)
2
5"
~-2£
Theorem. 15
213
Figure 22-An example with NFFD/NBFD
= 11/10 and No large
Theorem. 15
For any E>O, if No is sufficiently large then
N FFD/ No < 5/4+e.
(12)
The example in Figure 21 shows that
NFFD/No~ 11/9
(13)
is possible for No arbitrarily large. It is conjectured
that the 5/4 in (12) can be replaced by 11/9; this has
been established 15 for some restricted classes of Oli.
The preceding remarks also apply, mutatis mutandis,
to the ratio N BFD/ No. This is implied by the following
somewhat surprising result.
1_ 2 £
4
~-28
Theorem. 15
1+ 28
4
1+
2£
4
(X6n)
(X 3n)
88
1.- 28
4
t- 2
£
1
4- 2 £
*-2E
(X6n)
(X2n)
(X 3n)
Figure 21-An example with NFFD/No = 11/9 and No large
If max Oli/W* ~ 1/5 then N FFD = N BFD.
The quantity 1/5 above cannot be replaced by any
smaller number as the example in Figure 22 shows.
This example raises the whole question concerning
the extent by which the numbers N FF, N BF, N FFD and
N BFD may differ among themselves (assuming that No
is large). The example in Figure 22 shows that
NFFD/NBFD~II/10 is possible for arbitrarily large No.
On the other hand, the example of Figure 23 shows that
N BFD/NFFD~ 13/12 is possible for arbitrarily large No.
These two examples represent the worst behavior of
N FFD/ N BFD and N BFD/ N FFD currently known.
Another algorithm which has been proposed 40 proceeds by first selecting from all the Oli a subset which
packs B1 as well as possible, then selecting from the
214
Spring Joint Computer Conference, 1972
1000 using the first-fit decreasing algorithm then we
find N FFD = 3 which is optimal. However, if all the
weights are decreased by one, so that now the weights
(759, 394, 394, 378, 378, 240, 199, 104, 104, 39) are
packed into boxes of capacity 1000 using the first-fit
decreasing algorithm, we have N FFD = 4 which is clearly
not optimal. In fact, the following example shows that
N FF can increase when some of the (Xi are deleted. In
Figure 24 the list L= (7, 9, 7, 1, 6, 2, 4, 3) is used with
the first-fit algorithm to pack boxes of capacity 13,
resulting in N FF (L) = 3.
If the number 1 is deleted from L, to form the list
L' = (7, 9, 7, 6, 2, 4, 3), then we see in Figure 25 that
NFF(L') =4.
t-€
i-2£
-k-E
t+€
.i +£
3
1+€
3
(X6n)
(X6n)
i-
~+e:
2£
(X6)
3
(X6n)
(X6n)
DYNAMIC TASK SELECTION
(Xn)
Figure 23-An example with NBFD/NFFD = 13/12 and No large
remaining (Xi a subset which packs B2 as well as possible,
etc. Although more computation would usually be required for this algorithm than for the first-fit decrea~ing
algorithm it might be hoped that the number N of
boxes required is reasonably close to No. This does not
have to be the case, however, since examples exist for
any e>O for which No is arbitrarily large and
As an alternative to having a fixed list L prior to
execution time which determines the order in which
2
6
2
2
4
N'=4:
7
9
7
QO
N/N o> 2: 1/(2n -1)-e.
(14)
n=l
Figure 25-A non optimal packing using the deleted list L'
The quantity
00
2: 1/ (2n-1) = 1.606695 ...
n=l
in (14) is conjectured 15 to be best possible.
Some of the difficulty in proving many of the preceding results and conjectures seems to stem from the
fact that a decrease in the values of the (Xi may result
in an increase in the number of boxes required. For
example, if the weights (760, 395, 395, 379, 379, 241,
200, 105, 105, 40) are packed into boxes of capacity
3
4
,
2
6
N =3:
7
9
Figure 24-An optimal packing using L
7
tasks should be attempted, one might employ an algorithm which determines the scheduling of the tasks in a
dynamic way, making decisions dependent on the
intermediate results of the execution. Unfortunately,
no efficient algorithms of this type are known which
can prevent the worst possible worst-case behavior.
Perhaps the most natural candidate is the "criticalpath" algorithm, 5 which always selects as the next task
to be executed, that available task which belongs to the
longest t chain of currently unexecuted tasks. This type
of analysis forms the basis for many of the project
planning techniques which have been developed such
as PERT, CPM, etc. 39 Its worst-case behavior can be
bad as possible as the example in Figure 26 shows
(where O0I\X2>01\ (X2 divides Xl)]
then 1 else undefined.
Thus, je is properly less defined than jPlI e.g., je(1, 0)
is undefined whilejPl(l, 0) = 1.*
There are two ways to view this problem: either (a)
theoreticians are wasting their time by developing
methods for proving properties of programs which "do
not exist" in practice. They should concentrate their
efforts in developing direct methods for proving
properties of programs as they are actually executed;
or (b) existing computer systems should be modified,
since they are computing recursive programs in a way
which prevents their user from benefiting from the
results of the theory of computation. Language designers and implementors should look for efficient
computation rules which always lead to the least
fixpoint. "Call by name," for example, is such a computation rule, but unfortunately it often leads to very
inefficient computations. An efficient computation rule
* It can actually be shown, in general, that for every recursive
program P and any computation rule C, if f c and f p are not
identical, then f c must be less defined than f p (Cadiou [3]).
We now describe the computational induction method
for proving properties of recursive programs. The idea is
essentially to prove properties of the least fixpoint f P
of a given recursive program P by induction on the
level of recursion.
Let us consider, for example, the recursive program
F(x)~
P 2:
if x=o then 1 else x F(x-l),
o
over the natural numbers. The least fixpoint function
f P2 (x) of this recursive program is the factorial function x! .
Let us denote now by Ji(x) the partial function
indicating the "information" we have after the ith
level of recursion. That is,
jO(x) is undefined (for all x) ;
P(x) is ifx=O then 1 else x o fO(x-l), i.e.,
if x = 0 then 1 else undefined;
f2(x) is ifx=O then 1 else x oP(x-l), i.e.,
ij x = 0 then 1 else x (if x-I = 0 then 1 else undefined) , or
0
in short,
if x = 0 V x = 1 then 1 else undefined;
etc.
Computation of Recursive Programs
In general, for every i,
i~ 1,
Ji (x) is if x = 0 then 1 else X· Ji-l (x - 1) ,
which is
if x < i then x! else undefined.
This sequence of functions has a limit which is exactly
the least fixpoint of the recursive program; that is,
limJi(x) =x!
The important point is that this is actually the case
for any recursive program P. That is, if P is a recursive
program of the form
F (x) ¢=:r[F] (x),
For our purpose there is no need to specify the domain
of the programs or the meaning of p, hand k. We
would like to prove, using the two forms of induction,
that
fps(x, y) =gp,(x, y) for all x and y.
Proof by simple induction
If we restrict ourselves to simple induction, it is
much more convenient to prove a stronger result than
the desired one. This often simplifies proofs by induction by allowing a stronger induction assumption, even
though we have to prove a stronger result. So, we
actually show that
cp(fps, gp,): \fxVy{[fp 3(X, y) =gp,(x, y)]
and Ji (x) is defined by
1\ [gp,(x, h(y)) =h(gp,(x, y))]}
fO(x) is undefined (for all x),
holds. We proceed in two steps:
and
Ji(x) is r[Ji-l] (x) for
i~1,*
(a) cp( jO, gO), i.e., VxVy{ [fO(x, y) =gO(x, y)]
then
1\ [gO (x, h(y)) =h (gO (x, y))]}.
lim Ji(x) =fp(x).
\fx\fy{ [undefined
i
This suggests an induction rule for proving properties of
fp. To show that some property cp holds for fp, i.e.,
cp ( f p), we show that cp (Ji) holds for all i ~ 0, and
therefore we may conclude that cp(limJi), i.e., cp( fp),
holds.
i
There are two ways to state this rule. Both are
essentially equally powerful. These are actually the
rules for simple and complete induction on the level
of recursion.
(a) simple induction
if cp(fO) holds and \fi[cp(Ji)==}cp(fi+l)] holds,
then cp (fp) holds.
(b) complete induction
if 'Ii {[ ( Vj s.t. j < i) cp (fi) ]==}cp (fi)} holds, **
then cp ( fp) holds.
The simple induction rule is essentially the "JL-rule"
suggested by deBakker and Scott, 6 while the complete
induction rule is the "truncation induction rule" of
Morris. 7
Example: Consider the two recursive programs7
P3:
F (x, y)¢=: if p (x) then y else h(F(k(x), y)),
1\ [undefined
=undefined]
=undefined] }.
(b) \fi[cp(Ji, gi)==}cp(fi+l, gi+l)]'
We assume
\fx\fy{ [Ji(x, y) =gi(X, y)]
1\ [gi(X, h(y)) =h(gi(x, y))]},
and prove
Vx\fy{[fi+l(X, y) =gi+l(X, y)]
1\ [gi+l (x, h(y)) =h(gi+l (x, y))]}.
fi+l (x, y)
= if p (x) then y else h ( Ji (k (x), y) )
= if p(x) then y else h(gi(k(x), y))
= if p(x) then y else gi(k(x), h(y))
=gi+l(X, y).
gi+l(X, h(y))= ifp(x) thenh(y) elsegi(k(x), h2 (y))
= ifp(x) thenh(y) elseh(gi(k(x), hey)))
=h(if p(x) then y else gi(k(x), h (y)))
=h(gi+l(x, y)).
and
P4 :
221
G(x, y)¢=: if p(x) then y else G(k(x), h(y)).
* Where J[fi-l] is the result of replacing fi=l for all occurrences
of F in J[F]
** Note that this indicates implicitly the need to prove q;(fO) separately, since for i = 0 there is no j s. t. j < i.
Proof by complete induction
Using complete induction we can prove the desired
result directly; that is, we prove that
CP(fp3' gp,): VXVy[fp3(X, y) =gp,(x, y)]
222
Spring Joint Computer Conference, 1972
holds. This is done by showing first that cp ( f O, gO) and
cp ( p, gl) hold, and then that cp ( ji, gi) holds for all
i2=:2. (We treat the cases for i =0 and i = 1 separately,
since to prove cp ( ji, gi) we use the induction hypothesis
for both i-I and i-2.)
induction on the following simple flowchart program:
(a) cp( f O, gO), i.e., VxVy[JO(x, y) ==gO(x, y)].
VxVy[undefined == undefined].
(b) cp( fI, gl), i.e., VxVy[JI(x, y) ==gl(X, y)].
P (x, y) == if p (x)
== if p (x)
== if p(x)
then y else h ( fO (k (x) , y) )
then y else undefined
then y else gO(k(x), h(y))
==gl(X, y).
(c) (Vi2=: 2) [cp (ji-2, gi-2) /\ cp( ji-I, gi-l)=}cp (ji, gi)]
We assume
VxVy[ji-2(X, y) ==gi-2(X, y)]
and
VxVy[ji-l(X, y) ==gi-l(X, y)],
and deduce
VxVy[ji(x, y) ==gi(X, y)].
ji(x, y) == if p(x) then y else h( ji-l (k(x), y))
== ifp(x)
== if p (x)
thenyelseh(gi-l(k(x), y))
then y else h (if p (k (x)) then y
else gi-2(k 2(x) , h(y)))
==
ifp(x) thenyelse (ifp(k(x)) thenh(y)
else h (gi-2(k 2(x) , h(y))))
== if p (x)
then y else (if p (k (x)) then h (y )
else h( ji-2(k2(x) , h(y))))
==
==
ifp(x) then y elseJi-l(k(x), hey))
if p (x) then y else gi-l (k(x), h(y))
==gi(X, y).
THE INDUCTIVE ASSERTIONS METHOD
The most widely used method for proving properties
of "flowchart programs" is presently the inductive
assertions method, suggested by FloydS and Naur.9 It
can be shown that for any proof by inductive assertions,
there is a naturally corresponding computational
induction proof. We shall illustrate the inductive
assertion method and its relation to computational
We wish first to use the inductive assertions method
to show that the above flowchart program over the
natural numbers computes the factorial function, i.e.,
z=x!, whenever it terminates. To do this, we associate
a predicate Q (x, Yl, Y2), called an "inductive assertion,"
with the point labelled a in the program, and show that
Q must be true for the values of the variables x, Yl, Y2
whenever execution of the program reaches point a.
Thus, we must show (a) that the assertion holds when
point a is first reached after starting execution, (i.e.,
that Q(x, 0, 1) holds) and (b) that it remains true
when one goes around the loop from a to a (i.e., that
Yl~X/\Q(X, Yl, Y2) implies Q(x, Yl+l, (Yl+1)·Y2)).
To prove the desired result we finally show (c) that
z=x! follows from the assertion Q(x, Yl, Y2) when the
program terminates (i.e., that Yl=X/\Q(X, Yl, Y2)
implies Y2=X!).
We take Q(x, Yl, Y2) to be Y2=yd. Then:
(a) Q(x, 0, 1) is 1 =01.
(b) We assume Yl~X and Q(x, Yl, Y2), i.e., Y2=yd. Then
Q(x, Yl+l, (Yl+l) 'Y2) is (Yl+l) 'Y2= (Yl+l)!,
i.e., (Yl+l) ·yd= (Yl+l)!.
(c) We assume Yl=X and Q(x, Yl, Y2), i.e., Y2=Yl!, then
Y2 = Yl! = x! as desired.
To show the relation between this method and
computational induction, we must first translate the
flowchart program into a recursive program. Following
the technique of McCarthy,lO we find that the above
Computation of Recursive Programs
flowchart program isfp5(x, 0,1), i.e., the least fixpoint
of the recursive program Po (with Yl = and Y2 = 1)
where
°
Po: F (x, Yl, Y2) {= if Yl = x then Y2
else F(x, Yl+1, (Yl+1) ·Y2).
We shall prove by (simple) computational induction
that f p5(X, 0,1) ex!, i.e., the value of fp5(X, 0,1) is x!
whenever fp5(X, 0, 1) is defined, which is precisely what
the above proof by inductive assertions showed.
We take cp (F) to be the following predicate:
("Ix, Yl, Y2) {Q(x, Yl, Y2)::::}[F(x, Yl, Y2) ex!]},
where Q (x, Yl, Y2) is Y2 = yd, the induction assertion
used before. Obviously cp ( fO) holds. To show that
cp (Ji) implies cp ( fHI) for i 2:: 0, we consider two cases:
either Yl = x, in which case the proof follows directly
from (c) above, or Yl~X, which follows directly from
(b) .
By computational induction we therefore have cp ( f p) ,
i.e., Q(x, Yl, Y2)::::}[fp(x, Yl, Y2) ex!] for all x, Yl, Y2.
But since Q(x, 0, 1) is known from (a) to hold, we
conclude that fp (x, 0, 1) ex!, as desired.
REFERENCES
1 Z MANNA S NESS J VUILLEMIN
Inductive methods for proving properties of programs
In Proceedings of ACM Conference on Proving Assertions
about Programs ACM New York January 1972
223
2 S C KLEENE
Introduction to meta-mathematics
Van Nostrand Princeton New Jersey 1952
3 J M CAD IOU
Recursive definitions of partial functions and their
computations
PhD Thesis Computer Science Dept Stanford University
To appear
4 J VUILLEMIN
Proof techniques for recursive programs
PhD Thesis Computer Science Dept Stanford University
To appear
5 R MILNER
Implementation and applications of Scott's logic for
computable functions
In Proceedings of ACM Conference on Proving Assertions
about Programs ACM New York January 1972
6 J W DEBAKKER D SCOTT
A theory of programs
Unpublished memo August 1969
7 J H MORRIS
'
Another recursion induction principle
CACM Vol 14 No 5 pp 351-354 May 1971
8 R W FLOYD
Assigning meanings to programs
In Proceedings of a Symposium in Applied Mathematics
Vol 19 Mathematical Aspects of Computer Science pp 19-32
Ed J T Schwartz
9 P NAUR
Proof of algorithms by general snapshots
BIT Vol 6 pp 310-316 1966
10 J McCARTHY
Towards a mathematical science of computation
In Information Processing:
Proceedings of IFIP 62
pp 21-28 Ed C M Popplewell Amsterdam North Holland
1963
Mathematical concepts in programming language semantics
by DANA SCOTT
Princeton University
Princeton, New Jersey
leaving only what is familiar remaining. If you can do
it the first way, you can do it the second way, obviously; the converse is not obvious though. A contextual translation scheme may be very sensitive to
the context: a transformation appropriate for one
occurrence of an expression may not work elsewhere.
The negative integers can be used as a good example
here. The rules of algebra are such that all minus signs
can be eliminated from an equation by multiplying out
the formal polynomials and then using transposition.
(Different rules are used for different contexts, note.)
If it is the question of an algebraic law with variables,
we use this trick: Suppose we wish to assert that the
equation f(x) =g(x) holds for all x at both positive
and negative values. Of course f(x) =g(x) holds for all
non-negative x. But so does f( -x) =g( -x). In other
words one equation has been equivalently translated
into two, in which the variable can be restricted to the
more familiar range. Now Descartes may have been
willing to do algebra this way, but we would no longer
consider it reasonable. We have developed our theory of
numbers so as to include both positive and negative
quantities, and we have gone on to imaginary and
complex numbers with great gains in understanding.
In the new algebra, expressions are directly meaningful
and no translations are required. Nevertheless we prove
that the new algebra is consistent by constructing a
model out of familiar stuff. Complex numbers were
fairly easy to handle; quaternions were harder. You all
know examples and know that mathematicians are
busy every day finding other weird structures. Whether
the results deserve other than a mother's love is another
question.
What does this discussion have to do with programming languages? Very much I feel. Programming
languages have introduced a new dimension into the
problem of semantics. In the first place there has been
an explosion in the size and complexity of the expressions that must be considered. In view of the com-
INTRODUCTION
In mathematics after some centuries of development
the semantical situation is very clean. This may not be
surprising, as the subject attracts people who enjoy
clarity, generality, and neatness. On the one hand we
have our concepts of mathematical objects (numbers,
relations, functions, sets), and on the other we have
various formal means of expression. The mathematical
expressions are generated for the most part in a very
regular manner, and every effort is made to supply all
expressions with denotations. (This is not always so
easy to do. The theory of distributions, for example,
provided a non-obvious construction of denotations for
expressions of an operational calculus. The derivative
operator was well serviced, but one still cannot multiply
two distributions.)
The point of such activity is that the formal rules of
the calculus of expressions allow solutions of problems
to be found and give us ways of checking correctness of
proposed solutions. It is by no means the case that
mathematical inspiration is thus reduced to automatic
algebra, but the possibility of formal manipulation is a
great help. Not only can we record useful lemmas, but
a precise language is essential for teaching and communication.
I t is of course possible to pick formalisms out of thin
air and to ask people to accept their usefulness on
mystical grounds. (The operational calculus was
developed a little that way.) There is no denying that
clever guesswork can be very successful, but ultimately
it is fair to ask the mystic just what he is talking about.
A way to counter that question is to show how the
concepts being symbolized in the new language are
explained in terms of familiar notions. To do this we
can try either to correlate directly denotations definable
in familiar terms with the expressions of the new
language or to show how to translate the new expressions out of every context in which they might occur
225
226
Spring Joint Computer Conference, 1972
plications, every effort is made to allow the writer of
the program to keep tiresome details implicit: some
controls can be written in, but generally it is the compiler that will take care of the boring parts. Now many,
many compilers have been written-even students can
do it these days. A compiler can be viewed as a translator
from the source language (unfamiliar) into machine
language (familiar). Why cannot we say, then, that
the semantical problems of programming language are
solved? The answer is, I beHeve, that every compiler
(if it is meant for a real machine) is a compromise.
There must be as many compilers as there are machines,
each reflecting limitations and peculiarities of the given
machine. Should not the ideal of language definition be
machine independent?
Certainly the introduction of abstract machines does
not settle this difficulty of a multiplicity of translation
schemes. After all even for an abstract machine the
compiler writer must choose specific ways of keeping
track of the order or depth of nesting of computation
initiations. There may be different ways of doing this,
all of which lead to the same results. The variety of
approaches even on an abstract machine may make it
quite impossible to define in any· meaningful way just
what is a single computation step. Therefore, the idea
of the state of the computation is not apparently at all
well determined by the source language alone. When a
specific compiler is fixed, however, we may very well
want to investigate how it handles computation steps.
But the question remains: do they have anything to do
with the semantical definition of the original language?
I think not.
Before pursuing the question of the proper level at
which semantics enters, we should take note of a
second dimension-expanding consequence of programming language study. Mathematical concepts generally
have a rather static quality. True, mathematicians study
flows on manifolds and many-body problems, but it
seems to me that often the interest centers on global
qualities or asymptotic behavior. What is peculiar in
programming language-especially from a linguistic
point of view-is that exactly the same symbols may
possess a quite different import in different segments
of a program. This is most apparent in the way variables
(identifiers) are used. I need give no examples here;
all of you understand why variables are not employed
in the assignment statement in a "mathematical" way.
The dynamic character of command execution requires
a quite different treatment of variables, and this
dynamic urge permeates the whole semantic analysis.
The principal virtue of the programming language is
that the compounding of the various operations need
only be indicated in a rather schematic way, since the
calculation is meant to be automatic in any case. But
the calculation is not meant as a game or a joke. It is
something that needs precision, so we must be able to
"follow" what happens in some rather definite sense.
What we are discussing is how definite this has to be in
order to have a good semantical definition of a language.
Some years ago, Christopher Strachey began a
project of trying to expose the semantics of a programming language as a series of mutually recursive func. tional equations.! The particular complex of equations
would be "syntax directed" in the sense that each
clause of the recursive syntactical specification of the
language would have a corresponding equation. The
equations taken together would define the meaning of a
program, because made to correspond to a program
text would be a recursively defined function. This
function was intended as a state-transformation function: the function that takes an initial state to the final
state that results from executing the program. In many
instances the notion of "state" used here could be taken
to be "state of the memory" or some abstraction from
that idea to make the definition machine independent.
The formaHsm Strachey used to state his equations
was a modified version of the A-calculus. There was an
inherent difficulty in this approach: The A-calculus at
the time was just another symbolic calculus. 2 The
criteria for equivalence of expressions were rather weak,
and it was not clear in which directions they should be
expanded. The advantage of the A-calculus was that it
was "clean," especially in its handling of Ivariables,
which was done along the usual "mathematical"
lines. 3 ,4 Thus it was felt that some progress had been
made in explaining the unfamiliar in terms of the
familiar. Still, the project was not quite complete.
One objection to the A-calculus the present author
had was that it possessed no mathematical semantics.
It was another kind of operational calculus. True, the
calculus had been proved consistent, but the consistency
proof did not seem to give clear hints as to how to
extend usefully the principles of equivalence of expressions. 5 This uncertainty was particularly unsettling in
view of the many inconsistent extensions that had been
proposed. The main difficulty rested on the thoroughly
type1ree style of functional application and abstraction
used in the A-calculus, where, for example, a function
could be applied to itself as an argument. 6 And it was
just this type-free character of the system that Strachey
wanted to exploit.
During the fall of 1969 the author resided in Oxford
in order to learn more about Strachey's ideas on programming languages. After long, and sometimes rather
heated, discussions on the role of mathematics in
semantics, it slowly began to dawn on the author that
Mathematical Concepts in Programming Language Semantics
there might be an "objective" interpretation of the
A-calculus. As explained elsewhere/· s it was possible
finally to combine ideas and techniques from many
sources into a coherent theory of models for the
A-calculus. The key step was to find the right idea of
an abstract domain (which turned out to be a kind of
topological space) so that an appropriate notion of a
function space would be a domain of the same kind.
From that point it was only a matter of time until the
question of whether a domain might exist that could be
isomorphic ally identified with its own function space
would arise. Fortunately the author was able to see how
to effect the required mathematical construction, and a
new approach to functional calculi was opened up.
This sounds most abstract and impractical, but the
spaces constructed are actually no worse then the real
numbers. The "irrational" elements can be explained
as limits of infinite sequences in ways that are quite
reminiscent of classical analysis. 9 And what is more
important proofs about the properties of the elements
can he given inductively by "successive approximation"
in a simple and natural way. Furthermore it is possible
to discuss the effectiveness and computability of various
elements and processes so as to tie in the abstractions
with actual computation.
In this paper it will not be possible to discuss the
mathematical details, though a few words will be
inserted here and there to resolve puzzles about whether
the method is reasonable.lO Instead it will be shown how
the theory of these abstract domains can be applied to
typical semantical problems, thus supplying the
mathematical foundation needed for Strachey's equational approach. It is not claimed that the project for a
mathematical semantics is at all completely finished,
but the ideas have been found to be so flexible that we
have gained full confidence that we can do serious
model building incorporating features whenever the
need for them is realized. ll
LOCATIONS AND STORES
There are many levels of storage from core to disk to
tape to card hopper to the mind of the user sitting at a
console. Some of these are more addressible than others
(and more reliable). Some require special handling,
especially as regards allocation of space in preparation
for future acts of storage. In the present discussion we
shall not treat these subtleties, even though they are
very important for good compiler operation. We shall
simplify the presentation for the sake of illustration by
making these assumptions:
• There are but two facets to storage: internal and
external.
227
• The internal storage is addressed by elements of a
homogeneous collection of locations.
• The contents stored at each location always may be
read out (nondestructively), and at any time new
contents may be read in updating (destroying)
the old contents.
• The current state of the store allows a distinction
between the area of active locations (with conte'!ts)
and passive or free locations (without contents).
• At any time a new location may be selected from
those free and placed in the active area.
• At any time a location may be lost or retired to
the free list.
• One part of the external store allows reading in of
fresh information (input).
• The other part of the external store allows writing
of computed information (output).
• External reading and writing are independent
operations: what is written cannot be read back
unless it has been separately stored internally.
The statements of these rather natural assumptions
have been given first in fairly precise yet intuitive
language. The point of the present paper is to show how
to "mathematize" such assumptions in terms of a model
that can be incorporated into a full semantical definition. (No formal language has been discussed at this
point, however.) To carry out the mathematical
modelling, we postulate first the existence of several
domains that will be interrelated by the model:
The basic domains
L = locations
v = stored values
S = states of the store
T = truth values
Possibly it would have been better to say "storable
values" since not every element of V is actually stored.
Just what these quantities are supposed to be will be
left open until the next section. One has a variety of
choices depending on the kind of language that is to
be interpreted.
These domains alone do not specify the model because
they have not yet been supplied with any structure.
This can be effected by listing the operations and
transformations tha~ may be applied to the domains in
228
Spring Joint Computer Conference, 1972
various combinations:
The store operators
Contents: L-{S~V]
Update: LXV~[S~SJ
Area: L~[S~TJ
New:
S~L
Lose: L~[S~SJ
Read:
S~VXS
Write: V~[S~SJ
Given any two domains Do and D 1, we write [Do~DlJ
for the space of all (admissible) functions from Do into
D 1• (At this stage we do not need to worry just which
functions are admissible.) We write f: Do~Dl to
indicate that f is just such a function. What we have
listed above are the functions that correspond to our
intuitive ideas about the structure of the store. In order
to explain how this works, the following variables will
be used (with or without sub- and superscripts) restricted to the indicated domains:
a:L,
(3:V,
O':S, r:T
Suppose, then, a is a particular location and 0' is the
current state of the store. The function value Contents(a) (0') is to be the V-value stored by 0' at a.
Conversely, let {3 be a given V-value. The pair (a, (3) in
LXV provides the desired information for updating the
store. Therefore, when we write
Update(a, (3) (0') =0"
we want 0", the transformed store, to be just like 0'
except in having (3 stored now in location a. Similarly
Area (a) (0') is true or false according as a is in the active
area of 0'. The function Lose(O') transforms 0' into the
store 0''' which is just like 0' except that a has been freed.
Exactly what Read and Write do depends on the
activities of the mad scientist at the console. Supposing,
however, that he does not ruin the equipment, whenever
Read (0') is activated something will happen. This
transformation can be recorded as a pair ({3', 0"), where
(3' is a storable value, and 0" has the same internal
state as 0' did, but the external condition is made all
eager and ready for the next input. In a similar way, the
function Write({3') may be regarded as only affecting
the external portion of the store.
The functional notation of mathematics has the gloss
of precision. But so far the gloss is the only aspect
introduced, since note that the above explanations of
what the functions are supposed to do are just as
informal as the original assumptions given in ordinary
language. What must be avoided in this kind of work is
the Fairthorne Hovercraft effect described12 as an "approach in which we use extremely sophisticated techniques and mathematical devices to skim at very high
speed and great expense over the subject of concern
without ever touching it."
Now in mathematical model building the way to
touch ground is to find out how to formulate with
precision the postulates that correspond to the intuitive
assumptions. Notational precision is not enough-if
there is no way of proving useful theorems. So far our
postulates have been rather weak: nothing more than
simply noting the functional characters (or logical
types) of certain operators. The next step is to say
exactly how these operators are connected.
What I wish to claim is that each of the intuitive
assumptions previously informal1y indicated can be
expressed rigorously by an equation. For example,
after updating the store at a location, the contents of
the location wiH be found to be what is expected and
the location will be found to be active. This statement
makes two equations as follows: r
Contents (a) (Update(a, (3) (0'» =(3
Area(a) (Update(a, (3) (0'» = true
These equations are meant to hold for all a, (3, 0'. What
about locations a' different from a? If a' ~ a, we expect
that:
Contents (a') (Update(a, (3) (0')) = Contents (a') (0')
Similarly in the case of Area. If we introduce the
equality relation on L:
Eq:
LXL~T
and conditional expressions, these four equations can be
reduced to two in the obvious way.
In writing these equations, one puzzle is what to
write in the cases where the functions are possibly
undefined. A solution is to introduce a special value to
correspond to this case. The symbol for this value
adopted here is -L. We write f(x) =.L to indicate that
the function x is undefined at x. (Other symbols in use
are n, w, *, and UU.) This convention is useful in the
main equation relating Contents to Area:
Contents(a) (0') =if Area(a) (0')
then Contents ( a) (0')
else .L
Mathematical Concepts in Programming Language Semantics
There is not enough room here to formulate all the
necessary equations; thus, my claim must remain just
that. 13 But it does not seem to me that the claim is too
implausible. Note, however, that these postulates on the
character of the store would not completely specify
everything. The exact nature of V is left· open at this
stage of the model building. Concerning L, all we would
know is that there are infinitely many locations, because
new ones can be produced indefinitely. Actually that is
probably enough to know about L until one gets into
problems of allocation. The input/output phase has
also been left a little vague, but that is not necessarily
bad either. If we can prove any theorems at all, it is
better to prove them from fewer assumptions. Some
assumptions are needed, nevertheless; and it requires
experimentation to find just the right balance. Part of
the thesis of this paper is that the mathematical style
advocated allows for this experimentation to take place
in a convenient way.
229
following variables are used in restricted senses:
~:Id,
v:Num,
w:Op,
'Y:Cmd,
E:Exp
The syntax for Id, N um, and Op will not be given since
it is standard. The remaining two categories are defined
as follows:
Commands
'Y : : = EO: =El , write E, !E , E~'YO, 'Yl ,
dummy , 'Yo; 'Yl , while Edo 'Y ,
let ~:;:; Ein 'Y ,let ~ = Ein 'Y ,letrec ~ be e in 'Y ,
('Y)
Expressions
e: : = ~, ..L , read , 'Y result is e , eO~el, e2 ,
A LANGUAGE
There were no surprises in the discussion of storage in
the previous section, and there are no surprises planned
for this section either. All we shall do here is to indulge
in some very modest language design. Any real innovation is saved for the section on semantics. And this is
how it should be, otherwise we would not be giving
solutions to natural problems. It is quite possible,
though, that after the semantical approach has been
appreciated language design practice will be altered.
Strachey has argued for this,14 but the effects remain to
be seen. In any case we hope to develop a semantical
style within which the consequences of different design
choices can be studied.
To start with our language will be divided into the
usual syntactical categories:
The syntactical domains
Id = identifiers
N um = numerals
Op = (binary numerical) operations
Cmd = commands
Exp = expressions
A feature of our method is that we treat these domains
on a par with the basic and semantical domains. They
are different, since they are constructed for syntactical
purposes; but they are domains nevertheless. The
e: T , true , false , eo = el ,
e: N I v , eOwel ,
e:C, :'Y'
e: P , A~. E 'eoe! I
e:R'
1 e'
ie'
(e)
Some comments are necessary: (i) There is an
unpleasant conflict in this syntax between the use of
words versus the use of symbols. The trouble is that
there are not enough symbols-especially on keyboards-otherwise all constructs could be symbolized.
But then one has to remember what the symbols are
for, so it is better to use words-:-especially English
words. But it takes so long to write out all those words.
The situation is hopeless. (ii) There is an unpleasant
ambiguity in this syntax. The same string could be
parsed in several different ways. Necessarily, then, the
meaning of a command or an expression will have to
depend on the parse. But we· will pretend in writing
equations that everything can be determined from the
string alone. If that worries you, please write in the
parentheses (you are allowed to by the last clause of
the definition). But no one can stand to write in all
those parentheses. The situation is hopeless. But for the
semantical theory it does not really matter.15
The style of language definition was chosen to give a
few hints as to the meanings. But I hope there are some
constructs that seem quite mysterious on a first reading.
230
Spring Joint Computer Conference, 1972
Some explanation is in order. Take commands first.
The first clause gives us assignment statements. Everyone knows what they mean-except what does it mean
to have a compound expression on the left? Well, never
mind. The next command is obviously intended to
invoke output. That was easy. For the next clause it
would have been better to write do E. In this language
commands can be set up and (their closures) stored
away for later execution. This command means that E
should be evaluated out; and if the value is a command
closure, then it should be done. If not, what then?
Never mind. Next we have the conditional command
(Boolean-valued expressions are possible). To execute
dummy, do nothing-except waste time. The semicolon
provides the means for sequencing, or composition, of
commands. Next we have the while statement. Its
effect is well-known. Finally there are three kinds of
initialization of parameters in blocks. But which is
which?
An odd fact about many programming languages is
that identifiers are used for many different purposes
even though they form just one syntactical category.
The context is expected to give the clue as to use. It is
not such a bad idea. When one starts to write a program,
the number of identifiers to be used is probably not
known. To have to divide them up into various subcategories would complicate the language a great deal,
and restrict the ways they could be chosen, by tiresome
rules. They have only a local significance in any case, so
some rough, informal conventions of programming
style are sufficient to assure readability of programs.
The three types of initialization in this language
illustrate three quite different uses of identifiers. In the
first, we begin by evaluating E. It will turn out to be
either an L-value or a V-value. Whatever it is, we
associate the same value with ~ and go on to execute 'Y
under this assignment (keeping assignments to other
identifiers the same as before, of course). In the second,
we evaluate E. If the value is a V-value, we are happy.
If the value is an L-value, we find the contents of the
current state of the store in that location-a V-value.
In either case we now have a V-value. Next we find a
new L-value outside the active area of the store and
attach it to ~.Finally we update this location with the
computed V-value. Thus prepared, we can now execute
'Y. (The only reason for being so complicated is that in
'Y we would like to be able to use ~ on the left of assignment statements.) The first two cases are not so very
different, but the third presents a fresh aspect.
At the time of making a recursive definition, we want
to associate the "import" of E with ~, but we do not
want to evaluate E. Also E may contain ~ (a free occurrence of the identifier) , and we want ~ to mean the same
as we just said. Having made this tie-up without
actually evaluating anything, we begin to execute 'Y.
Every time we find a (free) ~, in effect, we want to
replace it be E and continue the evaluation. That is to
say, E will be evaluated only when it is called for by an
occurrence of ~. Since E contains ~, this may happen
repeatedly. This sequence of events is quite unlike the
non-recursive initializations where the ~'s in E are not at
the same as the r s in 'Y.
Turning now to expressions, the explanations can be
rather short. The read expression invokes input and has
a V-value. The result is combination allows for the
command 'Y to be executed before E is evaluated. Next
we see the conditional expression. The E: X expressions
are all Boolean-valued and are tests on the nature of the
value of E. In lines two and three of the definition we
have obvious Boolean-valued or numerical-valued expressions. In line four we have to do with (closures of)
commands, and :'Y forms just such a closure making a
command into an expression. Line five has to do with
procedures. First we find "A-abstraction (functional
abstraction) which forms a (closure of) a procedure
from an expression with respect to a formal parameter.
N ext we have application of a procedure to an argument. Line six, finally, has to do with references. We
can make a reference (to the value of E), or we can
look up a reference. References bring in the problem of
sharing, but we will not treat it in this paper. Nor shall
we discuss arrays. Note too that labels and jumps have
not been included.
The explanations just given have not been very full;
but the programming concepts mentioned are familiar,
and most of us would now have a fairly good idea of
what a program written in this language would do.
Such intuitive understanding is not rigorous semantics,
however, and as everyone knows sticky points can arise.
Just as we could turn the intuitive assumptions about
the store into precise equations, so must we formalize
our semantical understanding, as will be outlined in the
next section.
THE SEMANTICS
The plan of the semantical definition is that every
command and every expression shall denote something.
It is the construction of the domains in which the values
lie that requires the mathematics. We have spoken
already about the basic domains L, V, S, and T. Of
these Land T can be given independently in advance,
but V and S can only be formed in conjunction with the
over-all semantical project. To do this we have to look
at the kinds of expressions there are to be found in the
Mathematical Concepts in Programming Language Semantics
231
language and to provide appropriate domains. The
uses of the identifiers also have to be taken into account.
This analysis suggests these domains in addition to the
four already isolated:
To understand how these functional types are
arrived at, consider a command 'Y. Given an environment p and a state of the store u, we can write the
equation
e ('Y) (p) (u) = u'
The semantical domains
to indicate that u' will be the state achieved after
execution of 'Y. Similarly for expressions the equation
N = numerical values
E = expression values
W = dynamic values
D = denoted values
C = command values
P = procedure values
R = reference values
The denoted values accumulate all the possible values
that might be attached to an identifier. A scheme of
such attachments is called an environment. Mathematically it is just a function from identifiers to denoted
values. All our evaluations will have to take place
within (or relative to) such an environment. The
following variable is restricted to environments:
p: Id~D
Environments can change, but the meanings of the
numerals and the numerical operations are fixed. The
way to fix them is to define in the standard way these
two functions:
Numval:
See) (p) (u)
indicates that 1] is the value found for e, while u' is the
state achieved after the act of evaluation.
An immediate question is why the p and u are
separated as arguments. The answer is that they enter
into the evaluations in different ways. For one thing,
they change at quite different rates with p staying fixed
much longer than u. For another, we will be tempted to
copy p, but we will generally never feel free to ask for a
copy of the whole store-there just is no room for that.
Possibly in simulating a small machine on a large
machine we could conceive of programming the copying
of the store, but this is not yet a standard concept. In a
way p enters at a more conscious level, while u flows
along as the unconscious. Much of the action on u is
meant to be automatic, though there is communication
between the levels. Besides these reasons, it is often the
case that we want to discuss e ('Y) (p) without reference
to a particular u; thus it is convenient to be able to drop
it off as the last (deepest) argument.
For stylistic reasons and as an aid to the eye, we shall
use emphatic brackets with the semantical functions:
S[e](p) (u)
Num~N
Opval: Op~[NXN~NJ
Explicit definitions need not be given here.
Ultimately a command means a store transformation.
In mathematics expressions have "static" expression
values, but in programming it turns out that commands
can be invoked in evaluating a command. Thus an
expression has an effect as well as a value. We also have
to remember that expressions are sometimes used for
their L-values and sometimes for their V-values. All of
this can be summarized in several semantical functions
which have these logical types:
These are helpful because the expressions tend to get
along and to pile up their own parentheses. Before we
can discuss the semantical equations, however, we must
return to the definitions of the various domains.
The domains L, T and N are given. The rest are
constructed. The constructions can be summarized as
follows:
The domain equations
V=T+N+C+P+R
E=V+L
The semantical functions
e:
Cmd~[[Id~DJ~[S~SJJ
= (1], u')
W=S~EXS
D=E+W
S: Exp~[[Id~DJ~[S~EXSJJ
C=S~S
£: Exp~[[Id~DJ~[S~LXSJJ
P=E~W
"0: Exp~[[Id~DJ~[S~VXSJJ
R=L
232
Spring Joint Computer Conference, 1972
We shall not need variables over all of these domains.
The following restricted variables are used:
?]:E,
o:W,
(1:C
One domain is missing from the list: namely, S. The
construction of S is a bit complicated and needs more
discussion of L than we have time for here. Roughly
S=AX[L~VJXI/O,
where the A-coordinate represents the area; the middle
coordinate, the contents-function; and the last, the
input/output features. But this is a little too rough,
though we must leave it at that. ls
. What is essential to note here is the highly recursive
character of these domain equations; in particular, V
involves Sand S involves V. The involvement comes
about through the use of function domains such as
[S~SJ and [L~V]. Since V-values are storable values,
something seems wrong here. We said earlier that we
would not store (i.e., copy) stores, yet we are asking to
store a store junction (1: S~S. There is actually no
conflict here. Functions involve their arguments in a
potential, not actual, manner. In implementing such a
language, functions would be stored as finite descriptions
(i.e., texts of definitions) not as infinitary abstract
objects. From the point of view of mathematical conception, however, we want to imagine in theory that it
is the functions that are stored. If we did not want to do
this, we should explicitly program the syntax of function definition and the necessary interpretive operations.
In any case, storing a function is done without storing
the store.
Granting the reasonableness of the connections
between V and S, it is still fair to ask whether such
domains exist. This is where the real mathematics
enters. The idea mentioned in the Introduction of
constructing A-calculus models can be employed to
construct these more involved domains. It requires a
combination of lattice theory and topology to achieve
the proper kind of function theory.17 On set-theoretical
grounds it is clear that when we write [S~S ] we cannot
mean to take arbitrary functions, otherwise the cardinality of S (and of V) would become unbounded. The
point is that the functions defined by programs are of a
very special sort. Looked at in the right way they are
continuous functions, and there are many fewer continuous functions than there are arbitrary functions.
And this turned out to be the secret: by restricting the
function spaces to the continuous functions, the required domains can indeed be constructed. Expensive
as this device is, the Hovercraft effect is avoided by
showing that such a theory of domains fits in very well
with the theory of computable functions (recursive
functions) and that a]] the functions required by the
se~antics of the language are indeed computable. In
particular the theory provides a basis for justifying the
existence of functions defined by involved recursions
(like the semantical functions) and for proving properties of such functions. 18 ,19
It should be stressed that the semantical domains
make no explicit reference to the syntax of the language.
True, we gave the language first, and then cooked up
the domains to match. It could have easily been the
other way round. Take V for example. There were five
main sections to the definition of an expression corresponding to five sorts of values an expression could
have. (Strictly speaking this is not true. The expressions eOel and i e could have arbitrary values. It might
have been more logical to put these clauses on the first
line of the definition.) Therefore in the construction of
V, we had to provide for five sorts of elements, T, N, C,
P, and R. The summation operation (+) on domains
has to be defined as a disjoint union (and a little care is
needed with the topology of the reSUlting space). If we
had wanted, we could have included other sorts of
summands. They would not have been reflected in the
language, however. It is an interesting question
whether the language reflects enough of the structure of
the domain V, but one that we cannot pause to consider
here. The point is that language design and domain
construction are parallel activities, each can (and
should) affect the other.
Finally it remains to illustrate some of the equations
needed to define the semantical functions:
Some semantical equations
e[eo: =el](p) = Update*Pair (£ [eo](p) ) (00 [el](p) )
e[writee](p) = Write *8 [e](p)
eho; 'Yl](p) = ehl](p)oeho](p)
e[!e](p) =Do*8[e](p)
e[let ~=e in 'Y](p) = (A?]- eh](p[17/~J)) *He](p)
e [letrec ~ be e in 'Y] (p)
= eh](p[Fixpoint(Ao-8[e] (p[o/~J)) /~J)
For the e-function there should be 11 equations in
all; and for the 8-function, 21 equations. Then the
semantical definition would be complete. Note how the
equations are mutually recursive functional equations:
the e- and 8-functions occur on both sides of the
Mathematical Concepts in Programming Language Semantics
equations in functional contexts. Note too that there is
much unexplained notation.
In order to be able to combine functions, we need at
least two kinds of composition; because some functions
are of type [S~SJ, and some are of type [S~XXS].
We can see how this works in one example. Let:
f=£[EO](p):
S~LXS
g=eu[El](p):
S~VXS
We want:
Pair(f) (g): S~[LXVJXS.
Suppose 0- is a given state. Thenf( u) = (a, u'). Carrying
over 0-' to the next step, g (u') = ({3, u"). So we can
define:
Pair ( f) (g) (u)
233
CONCLUSION
The presentation in this paper has been but a sketch.
For a complete semantics even of this small language,
many more details would be required. But it is hoped
that enough of the project has been exposed to convince
the reader that it is possible to carry out such a plan.
And it is not even too painful to. do so: not so many
mathematical constructs are required, and the equations need not be so very complicated. Of course,
judgment of the worth of doing so should be withheld
until the semantical equations for a really serious
language are fully written out.
REFERENCES
= ((a, (3), u").
(The reason for doing it this way is to get the effect of
two separate evaluations, because there were two
expressions EO and El needing evaluation. ) Then by
definition:
(Update*Pair( f) (g)) (u)
= Update (a, (3) (u")
*
This shows how is a form of functional composition. In
the third equation we wrote 0, since this was just the
ordinary composition of two [S~S ] functions.
The notation p[7]/~J means that the original environment p has been altered to assign the value 7] to the
argument~. (Remember that the arguments of environments are the formal identifiers as syntactic objects.)
The import of the fifth equation then is to evaluate E
first, pass on the value to the environment, and then
execute the command starting in the state achieved
after evaluation of E. Note that E is evaluated in the
original environment.
The Fixpoint function in the last equation is applied
to a function F: W ~W. All our domains are constructed
so that functions defined by expressions always have
fixed points-ifthey have the same domain of definition
and range of values, of course. The domains are lattices
as well as topological spaces, so we can speak of the
least solution to the equation:
oo=F(oo).
This 00 = Fixpoint (F) . Fixed points of functional
equations solve recursions. So in the letrec command, we
first set up the solution 00, and then execute the command in the environment p[oo/~]. This explains our
mathematical concept of recursion. 20 Note that there are
no stacks, no pointers, no bookkeeping. None of those
devices of implementation are relevant to the concept.
That is why this is a mathematical semantics.
1 C STRACHEY
Towards a formal semantics
In T B Steel (ed) Formal Language Description Languages
(North-Holland 1966) pp 198-220. Cf. also Ref 15 for
another description of the present program
2 H B CURRY ET AL
Combinatory logic
Vol 1 (North-Holland 1958) Vol 2 (North-Holland 1972
in press) This is a basic reference with a very large
bibliography
3 P J LANDON
The mechanical evaluation of expressions
Comp J 6 pp 308-320 1964
4 A EVANS JR
P AL-a language for teaching programming linguists
In Proc ACM 23rd Nat Conf Brandon Systems Princeton
N J The PAL language carries out many of the ideas
introduced by Landon
5 Cf. Ref 2 p 78
6 The first proof of inconsistency was given by Kleene and
Rosser for a system of Church. The proof was later much
simplified. Cf. Ref 2 pp 258 ff
7 D SCOTT
Outline of a mathematical theory of computation
Proc Fourth Annual Princeton Conf on Info Sci and Sys
Princeton 1970 pp 169-176
8 D SCOTT
Continuous lattices
Proc Dalhousie Conf Springer Lecture Notes in Math 1972
in press
9 D SCOTT
The lattice of flow diagrams
In E Engeler (ed) Semantics of Algorithmic Languages
Springer Lecture Notes in Math Vol 188 1971 pp 311-366.
This paper provides many examples of the limit concept.
Cf. also Ref 10
10 D SCOTT
Lattice theory, data types and semantics
NYU Symp on Formal Semantics Prentice-Hall 1972 in
press. This is a general introduction more detailed in some
respects than Ref 7
234
Spring Joint Computer Conference, 1972
11 C STRACHEY
Varieties of programming language
Proc ACM Conf Venice 1972 to appear. This paper
contains more examples
12 R A F AIRTHORNE
Remarks in P Atherton (ed) Classification Research
Munksgaard Copenhagen 1965 p 210
13 C STRACHEY
A n abstract model of storage
In preparation. This report will give complete details
14 Cf. Ref 11
15 D SCOTT C STRACHEY
Toward a mathematical semantics for computer languages
Proc of Symp on Computers and Automata Microwave
Research Institute Symp Ser Vol 21 Polytechnic Institute
of Brooklyn 1972 in press. A nearly identical language and
16
17
18
19
20
its semantics is outlined in this paper together with some
more of the mathematical background
Cf. Ref 13
Cf. Refs 7 and 8
R MILNER
Implementation and applications of Scott's logic for
computable functions
SIGPLAN Notices Vol 7 No 1 January 1972 pp 1-6.
(=SIGACT News No 14)
J W DE BAKKER
Recursive procedures
Math Centre Tracts 24 Mathematisch Centrum Amsterdam
1971. Other useful references are contained in these two
papers
Cf. Refs 9, 15 and 19 for further discussion of recursion
Applications of language theory to compiler design
by J. D. ULLMAN
Princeton University
Princeton, New Jersey
Go defines arithmetic expressions over operators + and
*, with no structured variables, and with a representing
any identifier.
The way in which a CFG serves to define strings of
terminal symbols is as follows.
Definition: Let G= (N, ~,P, S) be a CFG. We define
the relation =::}
on (NU ~) *, by: if a and (j are any strings
G
in (NU~) *, and A~')' is a production, then aA{j=::}a,),{j.
G
If a is in ~*, then aA{j =::} a,),{j and if {j is in ~*, then
Glm
aA{j =::} a')'{j; lm and rm stand for leftmost and rightmost,
Grm
respectively. The transitive closure of any relation R,
denoted R+, is defined by:
INTRODUCTION
There are certain aspects of language theory that have
had, or can have, significant impact on the design and
implementation of compilers. These areas are, principally, the subjects of context free grammars and syntax directed translations. It is perhaps to be expected
that the deep and interesting theorems of language
theory do not usually find application. Rather, it is the
definitions of formal constructs and their elementary
properties that find use.
In this paper, we will discuss some of the ways in
which the language theorist can help the compiler designer. First, we will discuss classes of context free
grammars that have fast parsing algorithms and discuss
briefly what these algorithms are. Then we shall discuss
schemes for specifying the translations which must be
performed by the compiler.
(1) if aRb, then aR+b;
(2) if aR+b, and bR+c, then aR+c;
(3) aR+b only if it so follows from (1) and (2).
The reflexive-transitive closure of relation R, denoted
R*, is defined by aR*b if and only if a = b or aR*b.
* for example, to express the noThus, we can use a=::}{j,
CONTEXT FREE GRAMMARS
Let us proceed to the principal formalism of use to
compiler writers, the context free grammar.
Definition: A context free grammar (CFG) is a fourtuple (N, ~, P, S), where N and ~ are finite, disjoint
sets of nonterminals and terminals, respectively; S in N,
is the start symbol, and P is a finite list of productions
of the form A~a, where A is in N and a in (NU~) *.t
Example: A good example grammar, which will be
subsequently referred to as Go, is ({E, T, F},
{a, (,), +, *}, P, E), where P consists of the following
productions.
G
tion that a can become {j by some (possibly null) sequence of replacements of left sides of productions by
their right sides.
We will, whenever no ambiguity results, drop the
subscript G from the nine relations =::}, =::} ,=::} ,and their
G .Glm Grm
transitive, and reflexive-transitive closures.
We say L (G), the language defined by G, is {w I w is
* l. L (G) is said to be a context-free lanin ~* and S=::}w
guage (CFL).
Convention: Unless we state otherwise, the following
convention regarding symbols of a context free grammar holds.
(1) E~E+T
(2) E~T
(3) T~T*F
(4) T~F
(5)
(6)
F~(E)
( 1) A, B, C, ... are nonterminals.
(2) ... , X, Y, Z are either terminals or nonterminals.
(3) a, b, c, ... are terminals.
(4) u, ... , z are terminal strings.
F~a
t If X is any alphabet, then X* denotes the set of finite length
strings of symbols in X, including e, the string of length O.
235
236
Spring Joint Computer Conference, 1972
(5) a, /3, ,,(, ... are strings of terminals and/or
nonterminals.
( 6) S is the start symbol; except in Go, where E is
the start symbol.
(7) e denotes the empty string.
We may, using this convention, specify a CFG merely
by listing its productions. Moreover, we use the shorthand A -7al I ••• I an to stand for the productions
A-7aI, A-7a2, ... ,A-7an.
Definition: Let G= (N, ~, P, S) be a CFG. If
'~an, then we say there is a derivation of an
from al. If ai~ai+I' 1:::; i < n, we call this a leftmost derial~a2~"
vation, and if
ai~ai+l,
rm
1:::; i
< n, it is a rightmost deriva-
tion. Most often, we are interested in the case where
al
= S. If S~a, then a is a sentential form. If S~a, it is
a left sentential form, and if
*
S~a,
rm
lm
it is a right sentential
form.
Example: Let us consider Go, and the string a*a+a
in L (Go). It has the following derivations, among
others.
(1)
E~E+T~T+T~T+F
(2)
~T*F+ F~T*a+ F~F*a+ F
~F*a+a~a*a+a
E~E+T~T+T~T*F+T
The construction of a tree defined above is called
top down. We can also construct the same tree bottom
up, as follows.
(1) Begin with an isolated node corresponding to
each symbol of an. As this algorithm proceeds,
we will have a collection of trees corresponding
to each step of the derivation. At the end, there
will be one tree for the first sentential form al
(i.e., S).
(2) Suppose we have a collection of trees for ai,
1 < i:::; n, where to each symbol of ai there corresponds a root of one of the trees. If ai is constructed from ai-I by replacing A by /3, create a
new node, labeled A, whose direct descendants
are the roots of the trees for the symbols of /3.
The order of symbols in /3 reflects the order of
the descendants. If, however, /3 = e, create one
descendant for the node labeled A, and label the
descendant e.
Example: The unique parse tree for a*a+a in Go is
shown below. Note that the leaves of the tree read
a*a+a, from the left.
E
~F*F+T~a*F+T~a*a+T
~a*a+F~a*a+a
(3) E~E+T~E+F~E+a~T+a
~T*F+a~T*a+a~F*a+a~a*a+a
Derivation (1) is neither rightmost nor leftmost. (2)
is leftmost and (3) is rightmost. F*a+F is a sentential
form of Go, but happens not to be a left or right sentential form. a*a+a is both a left and right sentential
form, and is in L(Go).
Given a derivation of w from S we can construct a
parse tree for w as follows. Let S = al~a2 .. .~an = w.
(1) Begin with a single node labeled S. This node is
a trivial tree, and is said to be the tree for al.
In general the tree for ai will have a leaf corresponding to each symbol of ai. Initially, the lone
symbol S of al corresponds to the lone node.
(2) Suppose we have constructed the tree for ai,
i < n. Let ai+1 be constructed by replacing some
instance of A in ai by /3. To this instance of A
there corresponds a leaf. Make descendants of
that leaf for each symbol of /3, ordered from the
left. If /3 is the empty string, then we create a
single descendant, labeled e.
E
T
T
1
j
T
F
/~
I
F
/I~
+
*
1
F
I
a
a
I
a
It is easy to show that the top down and bottom up
methods of tree construction yield the same tree when
applied to one derivation.
An important property of a CFG is that it be unambiguous, that is, no word in its language has more than
one parse tree. Because of the way syntax directed
translation algorithms work on parse trees, an ambiguous programming language is very likely to provide
surprising machine code when (at least some of) it~
programs are compiled. It is easy to show that the con-
Applications of Language Theory to Compiler Design
dition of unambiguity is tantamount to saying that
each word in the language has a unique leftmost derivation and a unique rightmost derivation.
Example: The lists for Go, with input a*a are shown
below.
II
10
E~·E+T,O F~a·,O
EARLEY'S ALGORITHM
There is one outstanding method of recognizing the
words of an aribtrary CFL and building parse trees,
although many others have been proposed. This is the
method of Earley.l Descriptions of other general
methods can be found in References 2 and 3. Earley's
method works as follows.
~, P, S) and let al ... an be the
word we wish to recognize or parse. We construct lists 10, II, ... , In, of items; an item is of
the form [A~a·{3, iJ, where A~a{3 is a production and i an integer.
(2) Construct 10 as follows.
(i) Add [S~·a, OJ to 10, for each S~a in P.
(ii) If [A~·Ba, OJ is on 10, add [B~·{3, OJ to
10, if it is not already there, for each B~{3
inP.
(3) Suppose we have constructed Ii-I. Construct
I i as follows.
(i) For all [A~a·ai{3, jJ on Ii-I, add
[A~aai·{3,jJ to Ii. Recall that ai is the
ith input position.
(ii) If [A~a· ,jJ is on list Ii, add [B~{3A .'Y, kJ
to Ii, if [B~{3·A'Y, kJ is on I j •
(iii) If [A~a·B{3,jJ is on Ii, add [B~·'Y, iJ to
Ii for all B~'Y in P.
(1) Let G= (N,
We can show that item [A~a·(3)jJ is placed on
I i if and only if there is a leftmost derivation
As a special case of the above, al ... an is in L (G) if
and only if [S~a·, OJ is on In for some a. Thus, it is
easy to see how Earley's algorithm can be used to
recognize the words of a language. Moreover, once the
lists have been constructed, it is possible to build the
parse tree of the word. We shall not explore this further
here, but the intuitive idea behind the tree construction algorithm is to let the item [S~a·, OJ on In
represent the root, then look for those complete (dot at
the right end) items which lead to its being placed on
In. Make these items correspond to the descendants of
the root, and proceed top down, finding "causes" for
each item corresponding to a node.
237
E~·T,O
T~F·,O
T~·T*F, 0
E~T·,O
T~·F,
T~T·*F,O
F~·
0
12
T~T*·F,
0
F~· (E), 2
F~·a, 2
13
F~a·,
2
T~T*F·,
E~T·,
0
0
T~T·*F,
0
(E), 0
F~·a,O
List 13 is constructed as follows. [F~a., 2J is added
by rule (3i), because [F~ ·a, 2J is on 12 • [T~T*F·, OJ
is added to 13 by rule (3ii) , because [T~T*· F, OJ is
on 12 and [F~a·, 2J is on 13 • [E~T., OJ and
[T~T·*F, OJ are added 'because [E~·T, OJ and
[T~· T*F, OJ are on 10, and [T~T*F·, OJ is on Ia.
Since [E~T·, OJ is on Is, a*a is in L (Go).
Earley's algorithm can be implemented in O(n2)
steps of a random access computer if the underlying
grammar is unambiguous, and in O(n3 ) steps for an
arbitrary grammar. Moreover, on many grammars of
practical interest, Earley's algorithm operates in 0 (n)
steps. It is the fastest known general parsing algorithm.
LL GRAMMARS
We will now begin the study of several subclasses of
the context free grammars. None of the three classes
we consider is capable of generating all the context
free languages. However, confronted with a context
free language that is associated with a real programming language, it is highly likely that grammars in the
classes to be discussed do exist.
Our first subclass of grammars, called LL(k), for
left to right scan, producing a leftmost derivation, with
k symbollookahead, was first examined in Reference 4.
The LL (l) case was developed independently in Reference 5. Development of the theory can be found in
References 6 and 7. The general idea can be summarized
as follows.
Let G= (N,~, P, S) be a CFG, and let w be in ~*. We
may attempt to find a leftmost derivation for w by
starting with S and trying to proceed to successive left
sentential forms. Suppose we have obtained
where ai=xA{3, and x is a prefix of w. If there are
several productions with A on the left, we must select
the proper one. It is desirable that we be able to do so
using only information which we have accumulated so
far during the parse (which we represent by saying
that we "know what (3 is") and the k symbols of w be-
238
Spring Joint Computer Conference, 1972
yond prefix x, for some small k. If we can always make
this decision correctly, we say G is LL (k ) .
If a grammar is LL(k), we can parse it deterministically in a simple fashion. One pushdown list, which
holds the portion of a left sentential form to the right
of the prefix of terminals (A,8 in the case of ai, above)
is used. (There is also some other information on the
list, but we shall not discuss this here. A discussion
can be found in in Reference 3.) The input w is scanned
left to right, and if ai has been reached, the input
pointer will have scanned over prefix x, and is ready
to read the first k symbols of w. The arrangement is
shown below.
Stated less formally, suppose we are parsing w, and
have so far reached left sentential form xAa. We have,
as indicated in the informal parsing procedure which
introduced the section, not scanned w more than k
symbols beyond x. Thus, either xy or xz could be w, as
far as we know. Suppose A~,8 and a~'Y are two productions. Then the LL(k) definition assures us that
independent of w, but depending on x, a and the first
symbols of w beyond x (which are y:k, or equivalently,
z: k), we may uniquely select the proper production
with which to replace A.
Example: Consider the grammar
Ib
B~bSS I a
S~aBB
w
x
t
top
input pointer
I
pushdown list
~~
A!3
If production A ~'Y is chosen to expand A, the pushdown list is made to hold "1,8. Then, any terminals on
top of the pushdown list are compared with the input
immediately to the right of the input pointer, and the
next left sentential form will be properly represented.
The process of expanding the topmost nonterminal on
the pushdown list then repeats. Note that while expanding nonterminals, we could construct a parse tree
top down if we wished.
It should be noted that the pushdown list may carry
information other than grammar symbols, in order to
summarize at the top of the list, the important information about what is in the list (,8 in our example).
However, this information is not essential, if the grammar is modified properly. We now give the formal
definition of an LL(k) grammar.
Definition: If a is a string, let I a I denote the length
of a. Let a: k denote the first k symbols of a, or all of
a if I a I
u:
0
500 BIT PACKETS PLUS OVERHEAD
r
~
:::r
::0
0
I\)
c
C)
:::r
\J
c
0
0
~
UI
~
r
1000 BIT PACKETS PLUS OVERHEAD
I\)
0
curve A with the points obtained by simulation, the
curve should actually be recomputed for the slightly
skewed distribution that resulted. It is notable that the
delay estimates from the simulation (which used a
dynamic routing strategy) and the computation (which
used a static routing strategy and the time delay formula) are in close agreement. In particular, they both
accurately determined the vertical rise of the delay
curve in the range just above 400 kilobits/second, the
formula by predicting infinite delay and the simulation
by rejecting the further input of traffic.
In practice and from the analytic and simulation
studies of the ARPANET, the average queueing delay
is observed to remain small (almost that of an unloaded
net) and well within the design constraint of 0.2 seconds
until the traffic within the network approaches the
capacity of a cutset. The delay then increases rapidly.
Thus, as long as traffic is low enough and the routing
adaptive enough to avoid the premature saturation of
cutsets by guiding traffic along paths with excess capacity,
queueing delays are not significant.
0
III
=i
en
.....
en
m
0
Channel capacity optilllization
~
0
0
1000 BIT PACKETS WITHOUT OVERHEAD
500 BIT PACKETS WITHOUT OVERHEAD
~
UI
0
.I:>
o
o
.I:>
g------~------~------~------~----~
Figure 3-Delay
VB.
throughput
total throughput slightly greater than 400 kilobitsl
second is reached. The delay then increases rapidly.
Curves C and D respectively represent the same
situations when the overhead of 136 bits per packet and
per RFNM and 152 bits per acknowledgment are
included. Notice that the total throughput per IMP
is reduced to 250 kilobits/second in case C and to
approximately 200 kilobits/second in case D.
In the same figure, we have illustrated with x's the
results of a simulation performed with a realistic
routing and metering strategy. The simulation omitted
all network overhead and assumed fixed lengths of
1000 bits for all packets.
It is difficult to develop a practical routing and flow
control procedure that will allow each IMP to input
identical amounts of traffic. To compare the delay
One of the most difficult design problems is the
optimal selection of capacities from a finite set of
options. Although there are many heuristic approaches
to this problem, analytic results are relatively scarce.
(For the specialized case of centralized networks, an
algorithm yielding optimal results is available. 11 ) While
it is possible to find an economical assignment of
discrete capacities for, say, a 200 IMP network, very
little is known about the relation between such capacity
assignments, message delay, and cost .
To obtain theoretical properties of optimal capacity
assignments, one may ignore the constraint that
capacities are obtainable only in discrete sizes. In
Reference 21 such a problem was posed where the
network topology and average traffic flow were assumed
to be known and fixed and an optimal match of capacities to traffic flow was found. Also, the traffic was
assumed to be Markovian (Poisson arrivals and
exponential packet lengths) and the independence
assumption and decomposition method were applied.
For each channel, the capacity Ci was found which
minimized the average message delay T, at a fixed
total system cost D. Since AilJ.i.. is the average bit rate on
the ith channel, the solution to any optimal assignment
problem must provide more than this minimal capacity
to each channel. This is clear since both Equations (6)
and (7) indicate that T i will become arbitrarily large
with less than (or equal to) this amount of capacity.
It is not critical exactly how the excess capacity is
Computer Communication Network Design
assigned, as long as C i > AilJ.l.. Other important parameters and insights have been identified in studying the
continuous capacity optimization problem. For example, the number of excess dollars, De, remaining
after the minimum capacity AilJ.l. is assigned to each
channel is of great importance. As De~O, the average
delay must grow arbitrarily large. In this range, the
critical parameters become p and n where p = 'YI J.l.C is
the ratio of the rate 'YI J.l. at which bits enter the network
to the rate C at which the net can handle bits and
n = AI 'Y, where A= I)i is the total rate at which packets
flow within the net. The quantity p represents a dimensionless form of network "load" whereas n is easily
shown to represent the average path length for a
packet.
As the load p approaches lin, the delay T grows very
quickly, and this point p= lin represents the maximum
load which the network can support. If capacities are
assigned optimally, all channels saturate simultaneously
at this point. In this formulation n is a design parameter
which depends upon the topology and the routing
procedure, while p is a parameter which depends upon
the input rate and the total capacity of the network.
In studying the ARPANET23 a closer representation
of the actual tariffs for high speed telephone data
channels used in that network was provided by setting
D = Li diC i where 0 ~ a ~ 1. * This approach requires
the solution of a non-linear equation by numerical
techniques. On solving the equation, it can be shown
that the packet delay T varies insignificantly with a
for .3 ~ a ~ 1. This indicates that the closed form
solution discussed earlier with a = 1 is a reasonable
approximation to the more difficult non-linear problem.
These continuous capacity studies have application to
general network studies (e.g. , satellite communications )33
and are under continued investigation. 25 ,26,46
In practice, the selection of channel capacities must
be made from a small finite set. Although some theoretical work has been done in this case by approximating the discrete cost-capacity functions by
continuous ones, much remains to be done. I3 ,25 Because
of the discrete capacities and the time varying nature
of network traffic, it is not generally possible to match
channel capacities to the anticipated flows within the
channels. If this were possible, all channels would
saturate at the same externally applied load. Instead,
capacities are assigned on the basis of reasonable
estimates of average or peak traffic flows. It is the
responsibility of the routing procedure to permit the
traffic to adapt to the available capacity,l4 Often two
* Of course the tariffs reflect the discrete nature of available
channels. The use of the exponent a provides a continuous fit
to the discrete cost function. For the ARPANET, a~.8.
267
IMP sites will engage in heavy communication and
thus saturate one or more critical network cutsets. In
such cases, the routing will not be able to send additional flow across these cuts. The network will therefore
experience "premature" saturation in one or a small set
of channels leading to the threshold behavior described
earlier.
DISCUSSION
A major conclusion from our experience in network
design is that message switched networks of the ARPA
type are no longer difficult to specify. They may be
implemented straightforwardly from the specifications;
they can be less expensive than other currently available
technical approaches; they perform remarkably well as
a communication system for interconnecting timesharing and batch processing computers and can be
adapted to directly handle teletypes, displays and many
other kinds of terminal devices and data processing
equipment. I6 ,3o
The principal tools available for the design of networks are analysis, simulation, heuristic procedures,
and experimentation. Analysis, simulation and heuristics
have been the mainstays of the work on modeling and
topological optimization while simulation, heuristic
procedures and experimental techniques have been the
major tools for the actual network implementation.
Experience has shown that all of these methods are
useful while none are all powerful. The most valuable
approach has been the simultaneous use of several of
these tools.
Each approach has room for considerable improvement. The analysis efforts have not yet yielded results
in many important areas such as routing. However, for
prediction of delay, this approach leads to a simple
threshold model which is both accurate and understandable. Heuristic procedures all suffer from the
problem that it is presently unclear how to select
appropriate heuristics. It has been the innovative use
of computers and analysis that has made the approach
work well. For designing networks with no more than a
few hundred IMPs, present heuristics appear adequate
but a good deal of additional work is required for networks of greater size. Simulation is a well developed tool
that is both expensive to apply and limited in the overall
understanding that it yields. For these reasons, simulation appears to be most useful only in validating models,
and in assisting in detailed design decisions such as the
number of buffers that an IMP should contain. As the
size of networks continues to grow, it appears that
simulation will become virtually useless as a total design
tool. The ultimate standard by which all models and
268
Spring Joint Computer Conference, 1972
conclusions can be tested is experimentation. Experimentation with the actual network is conceptually
relatively straightforward and very useful. Although,
experiments are often logistically difficult to perform,
they can provide an easy means for testing models,
heuristics and design parameters.
The outstanding design problems currently facing
the network designer are to specify and determine the
properties of the routing, flow control and topological
structure for large networks. This specification must
make full use of a wide variety of circuit options.
Preliminary studies indicate that initially, the most
fruitful approaches will be based on the partitioning of
the network into regions, or equivalently, constructing
a large network by connecting a number of regional
networks. To send a message, a Host would specify
both the destination region and the destination IMP
in that region. No detailed implementation of a large
network has yet been specified but early studies of their
properties indicate that factors such as cost, throughput,
delay and reliability are similar to those of the present
ARPANET, if the ARPA technology is used. 9
Techniques applicable to the design of large networks
are presently under intensive study. These techniques
appear to split into the same four categories as small
network design but approaches may differ significantly.
For example, large nets are likely to demand the placement of high bandwidth circuits at certain key locations
in the topology to concentrate flow. These circuits will
require the development of a high speed IMP to connect
them into the net. It is likely that this high speed IMP
will have the structure of a high speed multiplexor, and
may require several cooperating processors to obtain
the needed computer power for the job. Flow control
strategies for large networks seem to extrapolate nicely
from small network strategies if each region in the large
network is viewed as a node in a smaller network.
However, this area will require additional study as will
the problem of specifying effective adaptive routing
mechanisms. Recent efforts indicate that efficient
practical schemes for small networks will soon be
available. These schemes seem to be applicable for
adaptive routing and flow control in networks constructed from regional subnetworks. The development
of practical algorithms to handle routing and flow
control is still an art rather than a science. Simulation is
useful. for studying the properties of a given heuristic,
but intuition still plays a dominant role in the system
design.
Several open questions in network design presently
are: (1) what structure should a high bandwidth IMP
have; (2) how can full use be made of a variety of high
bandwidth circuits; (3) how should large networks be
partitioned for both effective design and operation;
and (4) what operational procedures should large
networks follow? Much work has already been done in
these areas but much more remains to be done. We
expect substantial progress to be achieved in the next
few years, and accordingly, the increased understanding
of the properties of message switched networks of
all sizes.
ACKNOWLEDGMENT
The ARPA Network is in large part the conception of
Dr. L. G. Roberts of the Advanced Research Projects
Agency to whom we owe a debt of gratitude for his
support and encouragement. We also acknowledge the
helpful contributions of S. Crocker and B. Dolan of
ARPA. At BBN, NAC, and UCLA many individuals,
too numerous to list, participated in the network effort
and we gratefully acknowledge their contributions.
REFERENCES
1 P BARAN S BOEHM P SMITH
On distributed communications
Series of 11 reports by Rand Corporation Santa Monica
California 1964
2 "Specifications for the interconnection of a Host and
an IMP
BBN Report No 1822 1971 revision
3 S CARR S CROCKER V CERF
Host-Host communication protocol in the ARPA network
SJCC 1970 pp 589-597
4 S CROCKER et al
Function oriented protocols for the ARPA network
SJCC 1972 in this issue
5 D W DAVIES
The control of congestion in packet switching networks
Proc of the Second ACM IEEE Symposium on problems
in the Optimization of Data Communications Systems
Palo Alto California Oct 1971 pp 46-49
6 D FARBER K LARSON
The architecture of a distributed computer system-An
informal description
University of California Irvine Information and
Computer Science Technical Report #11 1970
7 W D FARMER E E NEWHALL
A n experimental distribution switching system to handle
bursty computer traffic
Proc of the ACM Symposium on Problems in the
Optimization of Data Communication Systems 1969
pp 1-34
8 H FRANK W CHOU
Routing in computer networks
Networks John Wiley 1971 Vol 1 No 2 pp 99-112
9 H FRANK W CHOU
Cost and throughput in computer-communication networks
To appear in the Infotech Report on the State of the
Art of Computer Networks 1972
10 H FRANK I T FRISCH
Communication transmission and transportation networks
Addison Wesley 1972
Computer Communication Network Design
11 H FRANK I T FRISCH W CHOU
R VAN SLYKE
Optimal design of centralized computer networks
Networks John Wiley Vol 1 No 1 pp 43-571971
12 H FRANK I T FRISCH W CHOU
Topological considerations in the design of the
ARPA computer network
SJCC May 1970 pp 581-587
13 L FRATTA M GERLA L KLEINROCK
The flow deviation method; An approach to
store-and-forward network design
To be published
14 G FULTZ L KLEINROCK
Adaptive routing techniques for store-and-forward
computer-communication networks
Proc of the International Conference on
communications 1971 pp 39-1 to 39-8
15 F HEART R KAHN S ORNSTEIN
W CROWTHER D WALDEN
The interface message processor for the ARPA
computer network
SJCC 1970 pp 551-567
16 R E KAHN
Terminal access to the ARPA computer network
Proc of Third Courant Institute Symposium Nov 1970
To be published by Prentice Hall Englewood Cliffs, NJ
17 R E KAHN W R CROWTHER
Flow control in a resource sharing computer network
Proc of the Second ACM IEEE Symposium on
Problems in the Optimization of Data Communications
Systems Palo Alto California October 1971 pp 108-116
18 R E KAHN W R CROWTHER
A study of the ARPA network design and performance
BBN Report No 2161 August 1971
19 J F C KINGMAN
Some inequalities for the queue GI/G/l
Biometrica 1962 pp 315-324
20 L KLEINROCK
Queueing systems; Theory and application
To be published by John Wiley 1972
21 L KLEINROCK
Communication nets: Stochastic message flow and delay
McGraw-Hill 1964
22 L KLEINROCK
Models for computer networks
Proc of the International Conference on Communications
1969 pp 21-9 to 21-16
23 L KLEINROCK
Analysis and simulation methods in computer
network design
SJCC 1970 pp 569-579
24 T MARILL L G ROBERTS
Toward a cooperative network of time-shared computers
FJCC 1966
25 B MEISTER H MULLER H RUDIN JR
Optimization of a new model for message-switching
networks
Proc of the International Conference on Communications
1971 pp 39-16 to 39-21
26 B MEISTER H MULLER H RUDIN
New optimization criteria for message-switching
networks
IEEE Transactions on Communication Technology
Com-19 June 1971 pp 256-260
269
27 N. A. C. Third Semiannual Technical Report for the
Project Analysis and Optimization of Store-and-Forward
Computer Networks
Defense Documentation Center Alexandria Va
June 1971
28 N. A. C. Fourth Semiannual Technical Report for the
Project Analysis and Optimication of Store-and-Forward
Computer Networks
Defense Documentation Center Alexandria Va Dec 1971
29 The Host/Host protocol for the ARPA network
Network Working Group N I C No 7147 1971 (Available
from the Network Information Center Stanford
Research Institute Menlo Park California)
30 ORNSTEIN et al
The terminal IMP for the ARPA network
SJCC 1972 In this issue
31 J PIERCE
A network for block switching of data
IEEE Convention Record N ew York N Y March 1971
32 E PORT F CLOS
Comparisons of switched data networks on the basis of
waiting times
IBM Research Report RZ 405 IBM Research
Laboratories Zurich Switzerland Jan 1971 (Copies
available from IBM Watson Research Center
POBox 218 Yorktown Heights New York 10598)
33 H G RAYMOND
A queueing theory approach to communication
satellite network design
Proc of the International Conference on Communication
pp 42-26 to 42-311971
34 L G ROBERTS
Multiple computer networks and inter-computer
communications
ACM Symposium on Operating Systems
Gatlinburg Tenn 1967
35 L G ROBERTS
A forward look
SIGNAL Vol XXV No 12 pp 77-81 August 1971
36 L G ROBERTS
. Resource sharing networks
IEEE International Conference March 1969
37 L G ROBERTS
Access control and file directories in computer networks
IEEE International Convention March 1968
38 L G ROBERTS B WESSLER
Computer network development to achieve resource sharing
SJCC 1970 pp 543-549
39 L G ROBERTS B WESSLER
The ARPA computer network
In Computer Communication Networks edited by
Abramson and Kuo Prentice Hall 1972
40 R A SCANTLEBURY P T WILKINSON
The design of a switching system to allow remote
access to computer services by other computers
Second ACM/IEEE Symposium on Problems in the
Optimization of Data Communications Systems
Palo Alto California October 1971
41 R A SCANTLEBURY
A model for the local area of a data communication
network-Objectives and hardware organization
ACM Symposium on Problems in the Optimization
of Data Communication Systems Pine Mountain Ga
1969 pp 179-201
270
Computer Communication
Ne~work
Design
42 R H THOMAS D A HENDERSON
M cRoss-A multi-computer programming system
SJCC 1972 In this issue
43 R VAN SLYKE H FRANK
Reliability of computer-communication networks
Proc of the Fifth Conference on Applications of
Simulation New York December 1971
44 R VAN SLYKE H FRANK
Network reliability analysis-I
Networks VolIN0 3 1972
45 E WOLMAN
A fixed optimum cell size for records of various length
JACM 1965 pp 53-70
46 L KLEINROCK
Scheduling, queueing and delays in time-sharing
systems and computer networks
To appear in Computer-Communication Networks
edited by Abramson and Kuo Prentice Hall 1972
47 A H WEIS
Distributed network activity at IBM
IBM Research Report RC3392 June 1971
48 M BEERE N SULLIVAN
Tymnet-A serendipitous evolution
Second ACM IEEE Symposium on Problems in the
Optimization of Data Communications Systems Palo
Alto California 1971 pp 16-20
49 W TEITELMAN R E KAHN
A network simulation and display program
Third Princeton Conference on Information Sciences
and Systems 1969 p 29
50 P BURKE
The output of a queueing system
Operations Research 1956 pp 699-704
51 J R Jackson
Networks of waiting lines
Operations Research Vol 5 1957 PI? 518-521
52 D B McKAY D P KARP
Network/440-IBM Research Computer Sciences
Department Computer Network
IBM Research Report RC3431 JUly 1971
Function-oriented protocols for the ARPA Computer Network
by STEPHEN D. CROCKER
JOHN F. HEAFNER
ROBERT M. METCALFE
Advanced Research Projects Agency
Arlington, Virginia
The RAND Corporation
Santa Mon ca, California
Massachusetts Institute of Technology
Cambridge, Massachusetts
and
JONATHAN B. POSTEL
University of California
Los Angeles, California
INTRODUCTION
message exchange between ARPANET Interface
Message Processors (IMPs). 2 ,5 A high level protocol is
one with primitives closely related to a substantive use.
At the lowest levels the contents of messages are unspecified. At higher levels, more and more is stated
about the meaning of message contents and timing. The
layers of protocol are shown in Figure 3.
A second way of structuring sets of protocols and
their design is bound up in the word factoring. At any
level of protocol are sets of format and timing rules
associated with particular groupings of agreements. In
the IMPs we find certain protocols pertaining to error
handling, while others to flow control, and still others
to message routing. At the ARPANET's user-level
communications interface there are, among others,
separable protocols associated with establishing connections and logical data blocking. These protocols do
not nest, but join as modules at the same level.
Before moving on to consider the higher level function-oriented protocols, let us first make a few statements about underlying protocols. There are three
lower level software protocols which nest in support of
the user-level communications interface for the ARPANET. The lowest of these is the IMP-IMP protocol
which provides for reliable communication among
IMPs. This protocol handles transmission-error detection and correction, flow control to avoid message
congestion, and routing. At the next higher level is the
IMP-HOST protocol which provides for the passage
of messages between HOSTs and IMPs in such a way
as to create virtual communication paths between
HOSTs. With IMP-HOST protocol, a HOST has
operating rules which permit it to send messages to
specified HOSTs on the ARPANET and to be informed
of the dispensation of those messages. In particular, the
IMP-HOST protocol constrains HOSTs in their transmissions so that they can make good use of available
Much has been said about the mechanics of the ARPA
Computer Network (ARPANET) and especially about
the organization of its communications subnet. 1 ,2 ,3 ,4 ,5
Until recently the main effort has gone into the implementation of an ARPANET user-level communications
interface. Operating just above the communications
subnet in ARPANET HOST Computers, this ARPANET interface is intended to serve as a foundation for
the organization of function-oriented communications. 6 ,7 See Figures 1 and 2 for our view of a computer
system and the scheme for user-level process-to-process
communications. It is now appropriate to review the
development of protocols which have been constructed
to promote particular substantive uses of the
ARPANET, namely function-oriented protocols.
We should begin this brief examination by stating
what we mean by the word "protocol" and how protocols fit in the plan for useful work on the ARPANET.
When we have two processes facing each other across
some communication link, the protocol is the set of
their agreements on the format and relative timing of
messages to be exchanged. When we speak of a protocol, there is usually an important goal to be fulfilled.
Although any set of agreements between cooperating
(i.e., communicating) processes is a protocol, the protocols of interest are those which are constructed for
general application by a large population of processes
in solving a large class of problems.
In the understanding and generation of protocols
there are two kinds of distinctions made. Protocols in
the ARPANET are layered and we speak of high or
low level protocols. High level protocols are those most
closely matched to functions and low level protocols
deal with communications mechanics. The lowest level
software protocols in the ARPANET involve reliable
271
272
Spring Joint Computer Conference, 1972
M
p
File System
Terminal Control
Termina 1
Operating
System
Boundary
Termina 1
Figure 1-0ur view of a computer system
communications capacity without denying such availability to other HOSTs.
The HOST-HOST protocol, finally, is the set of
rules whereby HOSTs construct and maintain communication between processes (user jobs) running on
remote computers. One process requiring communications with another on some remote computer system
makes requests on its local supervisor to act on its
behalf in establishing and maintaining those communications under HOST-HOST protocol.
In constructing these low levels of protocol it was the
intention to provide user processes with a general set
of useful communication primitives to isolate them
from many of the details of operating systems and
communications. At this user-level interface functionoriented protocols join as an open-ended collection of
modules to make use of ARPANET capabilities.
The communications environment facing the designers of function-oriented protocols in the ARPANET
is essentially that of a system of one-way byte-oriented
connections. Technically speaking, a "connection" is a
pair: a "send socket" at one end and a "receive socket"
at the other. Primitives provided at the user-level
interface include:
1.
2.
3.
4.
5.
Initiate connection (local socket, foreign socket),
Wait for connection (local socket),
Send, Receive (local socket, data),
Close (local socket),
Send interrupt signal (local socket).
Processes in this virtual process network can create
connections and transmit bytes. Connections are subject to HOST-HOST flow control and the vagaries of
timing in a widely distributed computing environment,
but care has been taken to give user processes control
over their communications so as to make full use of
network parallelism and redundancy. The kind of
agreements which must be made in the creation of
Function-Oriented Protocols for ARPA Computer Network
273
Figure 2-Two communicating processes
function-oriented protocols relate to rules for establishing connections, to the timing rules which govern
transmission sequences, and to the content of the bytestreams themselves.
USE OF REMOTE INTERACTIVE SYSTEMS
The application which currently dominates ARPANET activity is the remote use of interactive systems.
A Telecommunications Network (TELNET) protocol
is followed by processes cooperating to support this
application. 8 A user at a terminal, connected to his
local HOST, controls a process in a remote HOST as if
he were a local user of the remote HOST. His local
HOST copies characters between his terminal and
TELNET connections over the ARPANET. We refer
to the HOST where the user sits as the using HOST,
and to the remote HOST as the serving HOST. See
Figure 4.
At the using HOST, the user must be able to perform the following functions through his TELNET
user process ("user-TELNET") :
1. Initiate a pair of connections to a serving HOST,
2.
3.
4.
5.
Send characters to the serving HOST,
Receive characters from the serving HOST,
Send a HOST-HOST interrupt signal,
Terminate conn.ections.
The user-TELNET needs to be able to distinguish between (1) commands to be acted on locally and (2)
input intended for the serving HOST. An escape character is reserved to mark local commands. Conventions
for the ARPANET Terminal IMP (TIP) userTELNET are typical. 9
In most using HOSTs, the above functions are provided by a user-TELNET which is a user-level program.
A minimal user-TELNET need only implement the
above functions, but several additional support func-
274
Spring Joint Computer Conference, 1972
_ _ _ _ _ _ -USER LEVEL- -
-
-
-
-
-
Actua 1 Communica tion
Virtua 1 Communication (=Protocol)
Figure
3~The
layers of protocol
tions are often provided (e.g., saving a transcript of a
session in a local file, sending a file in place of usertyped input, reporting whether various HOSTs are or
have been up).
In the serving HOST it is desirable that a process
controlled over the ARPANET behave as it· would if
controlled locally. The cleanest way to achieve this
goal is to generalize the terminal control portion (TCP)
of the operating system to accept ARPANET terminal
interaction. It is unpleasant to modify any portion of
a working computer system and modification could be
avoided if it were possible to use a non-supervisor
process (e.g., "server-TELNET" or "LOGGER") to
perform the job creation, login, terminal input-output,
interrupt, and logout functions in exactly the same way
USING HOST
I
M
P
Terminal Control
Termina 1
I
M
p
Termina 1 Control
SERVING HOST
Figure 4-Data flow for remote interactive use
Function-Oriented Protocols for ARPA Computer Network
M
Figure 5-Data flow scheme for server
as a direct console user. Prior to the development of the
ARPANET, no operating system provided these functions to nOD-supervisor processes in anywhere near the
required completeness. Some systems have since been
modified to support this generalized job control scheme.
See Figures 5 and 6.
Efforts to standardize communications in the TEL-
275
NET protocol focused on four issues: character set,
echoing, establishing connections, and attention
handling.
The chosen character set is 7-bit ASCII in 8-bit
fields with the high-order bit off. Codes with the highorder bit on are reserved for TELNET control functions. Two such TELNET control function codes are
the "long-space" which stands for the 200 millisecond
space generated by the teletype BREAK button, and
the synchronizatiQn character (SYNCH) discussed below in conjunction with the purpose of the TELNET
interrupt signal.
Much controversy existed regarding echoing. The
basic problem is that some systems expect to echo,
while some terminals always echo locally. A set of conventions and signals was developed to control which
side of a TELNET connection should echo. In practice,
those systems which echo have been modified to include
provision for locally echoing terminals. This is a nontrivial change affecting many parts of a serving HOST.
For example, normally echoing server HOSTs do not
echo passwords so as to help maintain their security.
Terminals which echo locally defeat this strategy, how-
N C P
M
p
Terminal Control
LOGGER must be a background service program capable of initiating jobs
Figure 6-Alternate data flow scheme for a server
276
Spring Joint Computer Conference, 1972
M
Figure 7-Data flow and processing of the character
input stream
ever, and some other protection scheme is necessary.
Covering the password with noise characters is the
usual solution.
The HOST-HOST protocol provides a large number
of sockets for each HOST, but carefully refrains from
speeifying which ones are to be used for what. To establish communication between a user-TELNET and a
server-TELNET some convention is required. The
Initial Connection Protocol (ICP)lO is used:
1. Connection is initiated from a user-TELNET's
receive socket to a serving HOST's socket 1
(a send socket).
2. When the initial connection is established, the
serving HOST sends a- generated socket number
and closes the connection. This socket number
identifies an adjacent socket pair at the serving
HOST through which the user-TELNET can
communicate with a server-TELNET.
3. TELNET connections are then initiated between the now specified pairs of sockets. Two
connections are used to provide bi-directional
communication.
Note that socket 1 at the serving HOST is in use only
long enough to send another socket number with which
to make the actual service connections.
One of the functions performed by·a terminal control
program within an operating system is the scanning of
an input stream for attention characters intended to
stop an errant process and to return control to the
executive. Terminal control programs which buffer input sometimes run out of space. When this happens to
a local terminal's input stream, a "bell" or a question
mark is echoed and the overflow character discarded,
after checking to see if it is the attention character. See
Figure 7. This strategy works well in practice,but it
depends rather strongly on the intelligence of the human
user, the invariant time delay in the input transmission
system, and a lack of buffering between type-in and attention checking. None of these conditions exists for
interactive traffic over the net: The serving HOST cannot control the speed (except to slow it down) or the
buffering within the using HOST, nor can it even know
whether a human user is supplying the input. It is thus
necessary that the terminal control program or serverTELNET not, in general, discard characters from a network input stream; instead it must suspend its acceptance of characters via the HOST-HOST flow control
mechanism. Since a HOST may only send messages
when there is room at the destination, the responsibility
for dealing with too much input is thus transferred back
to the using HOST. This scheme assures that no characters accepted by the using HOST are inadvertently lost.
However, if the process in the serving HOST stops accepting input, the pipeline of buffers between the userTELNET and remote process will fill up so that attention characters cannot get through to the serving
executive. In the TELNET protocol, the solution to
this problem calls for the user-TELNET to send, on
request, a HOST-HOST interrupt signal forcing the
server-TELNET to switch input modes to process network input for attention characters. The serverTELNET is required to scan for attention characters
in its network input, even if some input must be discarded while doing so. The effect of the interrupt signal
to a server-TELNET from its user is to cause the buffers between them to be emptied for the priority processing of attention characters.
To flip an attention scanning server-TELNET back
into its normal mode, a special TELNET synchronization character (SYNCH) is defined. When the· serverTELNET encounters this character, it returns to the
strategy of accepting terminal input only as buffer
space permits. There is a possible race condition if the
SYNCH character arrives before the HOST-HOST
interrupt signal, but the race is handled by keeping
a count of SYNCHs without matching signals. Note
that attention characters are HOST specific and may
be any of 129 characters-128 ASCII plus "long
space"-while SYNCH is a TELNET control character
recognized by all server-TELNETs. It would not do
to use the HOST-HOST signal alone in place of the
signal-SYNCH combination in attention processing,
because the position of the SYNCH character in the
TELNET input stream is required to determine where
attention processing ends and where normal mode input
processing begins.
Function-Oriented Protocols for ARPA Computer Network
277
FILE TRANSFER
When viewing the ARPANET as a distributed
computer operating system, one initial question is that
of how to construct a distributed file system. Although
it is constructive to entertain speculation on how the
ultimate, automated distributed file system might look,
one important first step is to provide for the simplest
kinds of explicit file transfer to support early substantive use.
During and immediately after the construction of the
ARPANET user-level process interface, several ad hoc
file transfer mechanisms developed to provide support
for initial use. These mechanisms took two forms: (1)
use of the TELNET data paths for text file transfer and
(2) use of raw byte-stream communication between
compatible systems.
By adding two simple features to the user-TELNET,
text file transfer became an immediate reality. By
adding a "SCRIPT" feature to user-TELNETS
whereby all text typed on the user's console can be
directed to a file on the user's local file system, a user
need only request of a remote HOST that a particular
text file be typed on his console to get that file transferred to his local file system. By adding a "SENDFILE" feature to a user-TELNET whereby the contents of a text file can be substituted for console type-in,
a user need only start a remote system's editor as if to
enter new text and then send his local file as type-in
to get it transferred to the remote file system. Though
crude, both of these mechanisms have been used with
much success in getting real work done.
Between two identical systems it has been a simple
matter to produce programs at two ends of a connection
to copy raw bits from one file system to another. This
mechanism has also served well in the absence of a more
general and powerful file transfer system.
Ways in which these early ad hoc file transfer mechanisms are deficient are that (1) they require explicit
and often elaborate user intervention and (2) they depend a great deal on the compatibility of the file systems involved. There is an on-going effort to construct
a File Transfer Protocol (FTP)1l,12 worthy of wide
implementation which will make it possible to exchange
structured sequential files among widely differing file
systems with a minimum (if any) explicit user intervention. In short, the file transfer protocol being developed provides for the connection of a file transfer'
user process ("user-FTP") and file transfer server
process ("server-FTP") according to the Initial Connection Protocol discussed above. See Figure 8. A user
will be able to request that specific file manipulation
operations be performed on his behalf. The File Transfer Protocol will support file operations including (1)
M
Background File Service Program or Server-FTP
Figure 8-Data flow for file transfer
list remote directory, (2) send local file, (3) retrieve remote file, (4) rename remote file, and (5) delete remote
file.
It is the intention of the protocol designers to regularize the protocol so that file transfer commands can
be exchanged by consoles file transfer jobs engaged in
such exotic activities as automatic back-up and dynamic file migration. The transfers envisioned will be
accompanied with a Data Transfer Protocol (DTP)ll
rich enough to preserve sequential file structure and in
a general enough way to permit data to flow between
different file systems.
USING THE ARPANET FOR REMOTE
JOB ENTRY
A very important use of the ARPANET is to give a
wide community of users access to specialized facilities.
One type of facility of interest is that of a very powerful
number-cruncher. Users in the distributed ARPANET
community need to have access to powerful machines
for compute-intensive applications and the mode of
operation most suited to these uses has been batch
Remote Job Entry (RJE). Typically, a user will generate
a "deck" for submission to a batch system. See Figure 9.
He expects to wait for a period on the order of tens of
minutes or hours for that "deck" to be processed, and
then to receive the usually voluminous output thereby
generated. See Figure 10.
As in the case of file transfer, there are a few useful
ad hoc ARPANET RJE protocols. A standard RJE
protocol is being developed to provide for job submission to a number of facilities in the ARPANET.
This protocol is being constructed using the TELNET
and File Transfer protocols. A scenario which sketches
how the protocol provides the RJE in the simplest,
most explicit way is as follows:
Via an ARPANET RJE process, a user connects his
278
Spring Joint Computer Conference, 1972
I
M
P
File
I
M
P
Terminal
Control
Queue of
Submitted Jobs
Prepared "deck"
Figure 9-Submission of RJE input
terminal to an RJE server process at the HOST to
which he intends to submit his job "deck." Through
a short dialogue, he establishes the source of his input
I
M
P
and initiates its transfer using the File Transfer Protocol. At some later time, the user reconnects to the appropriate RJE server and makes an inquiry on the
I
M
P
Fi Ie Sys tern
Figure lO-Retrieval of RJE output
Function-Oriented Protocols for ARPA Computer Network
status of his job. When notified that his input has been
processed, he then issues commands to the serving
HOST to transfer his output back.
We can of course imagine more automatic ways of
achieving these same functions. A user might need only
type a job submission command to his local system.
Automatically and invisibly, then, the local system
would connect and converse with the specified RJE
server causing the desired output to later appear in the
users file area or perhaps on a local line printer. The
intention is to design the RJE protocol so that the explicit use can start immediately and the more automatic
RJE systems can be built as desired.
OTHER PROTOCOLS AND CONCLUSIONS
One of the more difficult problems in utilizing a network of diverse computers and operating systems is that
of dealing with incompatible data streams. Computers
and their language processors have many ways of
representing data. To make use of different computers
it is necessary to (1) produce a mediation scheme for
each incompatibility or (2) produce a standard representation. There are many strong arguments for a
standard representation, but it has been hypothesized
that if there were a simple way of expressing a limited
set of transformations on data streams, that a large
number of incompatibilities could be resolved and a
great deal of computer-computer cooperation expedited.
The bulk of protocol work is being done with the
invention of standard representations. The TELNET
protocol, as discussed, is founded on the notion of a
standard terminal called the Network Virtual Terminal
(NVT). The File Transfer Protocol is working toward
a standard sequential file (a Network Virtual File?).
So it is also with less advanced protocol work in graphics
and data management.
There is one experiment which is taking the transformational approach to dealing with incompatibilities.
The Data Reconfiguration Service (DRS) is to be
generally available for mediating between incompatible
stream configurations as directed by user-supplied
transformations. 13
ACKNOWLEDGMENTS
Function-oriented protocols have been the principal
concern of the ARPANET Network Working Group
(NWG). A list of people who have contributed to the
development of the protocols discussed would include,
Robert Braden, Howard Brodie, Abhay Bhushan,
279
Steve Carr, Vint Cerf, Will Crowther, Eric Harslem,
Peggy Karp, Charles Kline, Douglas McKay, Alex
McKenzie, John Melvin, Ed Meyer, Jim Michener,
Tom O'Sullivan, Mike Padlipsky, Arie Shoshani, Bob
Sundberg, Al Vezza, Dave Walden, Jim White, and
Steve Wolfe. We would like to acknowledge the contribution of these researchers and others in the ARPA
N etwork Working Group, without assigning any responsibility for the content of this paper.
REFERENCES
1 L G ROBERTS B D WESSLER
Computer network development to achieve resource sharing
AFIPS Conference Proceedings May 1970
2 F E HEART et al
The ~'nterface message processor for the ARPA
computer network
AFIPS Conference Proceedings May 1970
3 L KLEINROCK
Analytic and simulation methods in computer
network design
AFIPS Conference Proceedings May 1970
4 H FRANK I T FRISCH W CHOU
Topological considerations in the design of the ARPA
Computer network
AFIPS Conference Proceedings May 1970
5 Specifications for the interconnection of a Host and an IMP
Bolt Beranek and Newman Inc Report No 1822
February 1971
6 C S CARR S D CROCKER V G CERF
HOST-HOST communication protocol in the
ARPA Network
AFIPS Conference Proceedings May 1970
7 HOST/HOST protocol for the ARPA Network
ARPA Network Information Center #7147
8 T O'SULLIVAN et al
TELNET protocol
ARPA N etwork Working Group Request For
Comments (RFC) #158 ARPA Network Information
Center (NIC) #6768 May 1971
9 S M ORNSTEIN et al
The Terminal IMP for the ARPA Computer Network
AFIPS Conference Proceedings May 1972
10 J B POSTEL
Official initial connection protocol
ARPA Network Working Group Document #2 NIC
#7101 June 1971
11 A K BHUSHAN et al
The data transfer protocol
RFC #264 NIC #7812 November 1971
12 A K BHUSHAN et al
The file transfer protocol
RFC #265 NIC #7813 November 1971
13 R ANDERSON et al
The data reconfiguration service-An experiment
in adaptable process/process communication
The ACM/IEEE Second Symposium On Problems In
The Optimization Of Data Communications Systems
October 1971
McROSS-A multi-computer programming system*
by ROBERT H. THOMAS and D. AUSTIN HENDERSON
Bolt, Beranek and Newman, Inc.
Cambridge, Massachusetts
INTRODUCTION
This paper describes an experimental "distributed"
programming system which makes it possible to create
multi-computer programs and to run them on computers connected by the ARPA computer network
(ARPANET).1 The programming system, which is
called McROSS (for Multi-Computer Route Oriented
Simulation System), is an extension of a singlecomputer simulation system for modelling air traffic
situations 2 developed by Bolt, Beranek and Newman,
Inc. (BBN) as a tool for air traffic control research.
The McROSS system provides two basic capabilities.
One is the ability to program air traffic simulations
composed of a number of "parts" which run in geographically separated computers, the distributed parts
forming the nodes of a "simulator network." The
second is the ability of such a simulator network to
permit programs running at arbitrary sites in the
ARPANET to "attach" to particular nodes in it for the
purpose of remotely· monitoring or controlling the
node's operation.
The McROSS distributed programming system is
unique in several ways:
(~)
lator network might be run at BBX and on the
next some might be run at BB~, others at
RAND and still others at the University of
Utah. This mode of using the ARPANET is
significantly different from the normal one in
which programs are bound to particular network sites at program composition time. (The
only constraint on the binding of nodes to
ARPANET sites is the requirement that each
node run on a PDP-IO under the TENEX
operating system. 5)
The responsibilities of a node in a simulator network can be conveniently partitioned into subtasks which can be performed more or less
independently of one another. The McROSS
implementation mirrors this partitioning. Functions performed at the nodes are realized by
groups of loosely connected, concurrently evolving processes.
The distributed simulation system represents an
initial step in an on-going research program which is
investigating techniques to make it easy to create, run
and debug computations involving the coordinated behavior of many computers. The McROSS system is
intended to serve both as an experimental vehicle for
studying problems related to distributed computation
and as a tool for air traffic control research. Its two
goals are well matched. A satisfactory solution to the
nation's air traffic problems is likely to include a network of airborne and ground based computers working
together on a single distributed computation: the
scheduling and control of aircraft maneuvers. Thus, the
air traffic control problem is a rich source of interesting
problems in partitioned computation which can be used
to measure the usefulness of the distributed computational techniques developed.
This paper is a report on one phase of a continuing
research program. The intent is to describe interesting
aspects of an experimental distributed programming
(a ) Use of McROSS generates inter-computer traffic
in which a group of programs are engaged in
substantive conversation. There is relatively
little previous experience with such intercomputer, program-to-program conversations.
(b) The component nodes of a simulator network
are not bound to particular ARPANET sites
until simulation "run time." Thus on different
runs the same distributed program can be distributed in different ways over the ARPANET.
For example, in one run all the nodes of a simu-
* This work was supported by the Advanced Projects Research
Agency of the Department of Defense under Contract No.
DAHC-71-C-0088.
281
282
Spring Joint Computer Conference, 1972
system and to share our experience with others considering the construction of such systems. The paper
does no more than hint at how the McROSS system
can be used in air traffic control research.
The next section provides background useful for
subsequent discussion of the distributed programming
system. After than, the McROSS system is described,
first in terms of the facilities it provides for creating
distributed simulations, and then in terms of interesting
aspects of its implementation. The paper closes with a
discussion of some of the issues brought into focus by
the experience of implementing and using a distributed
programming system.
COMPONENTS OF THE McROSS SYSTEM
The main components of the distributed programming system are:
1. The ARPA computer network;
2. The TEN EX operating system for the PDP-IO;
and
3. A simulation programn¥ng system known as
ROSS (for Route Oriented Simulation System).
These components became operational within 6-10
months of one another, at which time it became feasible
to implement the distributed programming system
being described.
The ARPANET
The ARPA computer networkI,3,4 is a set of autonomous computer systems (hosts) which are interconnected to permit resource sharing between any pair of
them. The goal of the ARPANET is for each host to
make its resources accessible from other hosts in the net
thereby permitting persons or programs residing at one
network site to use data and programs that reside and
run at any other. Each host interfaces with the network
through an Interface Message Processor (IMP) ,3 a
small dedicated general-purpose computer. The IMPs,
which reside at the various ARPANET sites, are connected by 50 kilobit common carrier lines and are
programmed to implement a store and forward communication network. In passing from host A to host B
a message passes from host A to IMP A, through the
IMP communication network from IMP A to IMP B
(in general passing through a number of intermediate
IMPS) and finally from IMP B to host B.
At each host there is a Network Control Program
(NCP) whose function is to provide an interface be-
tween the network and processes within the host. The
use the IMP store and forward network to provide processes with a connection switching network.
Thus, they enable processes in different hosts to establish connections with one another and to exchange
information without directly concerning themselves
with details of network implementation such as the
way in which hosts are connected to and communicate
with IMPs.
Information can flow in only one direction on an
ARPANET connection. Thus, before two processes are
able to engage in a dialogue they must establish two
such connections between them. A connection is completely specified by its two ends which are called
sockets. A network socket is itself uniquely specified by
a host identifier and a socket identifier. The purpose of
the socket identifier is to specify a process or group of
processes within a host and a socket relative to that
process or process group. Thus, it is useful to think of a
socket as having a three component "socket name" of
the form H. P . N. H is the "host" component which
identifies an ARPANET host, P is the "process" component which identifies a process group within Hand N
is the "process-local" component which identifies a
socket relative to P. In the sequel
}~·CPs
HI,PI.NI~H2,P2.N2
is used to denote a connection between sockets
HI. Pl. N I and H 2. P 2. N 2 where ~ indicates the direction of information flow over the connection.
For a connection to be established between two
processes each must request that it be established. There
are two common ways in which connections are established. In the first, the processes play symmetric
roles. Each specifies, as part of a "request for connection" (RFC), the socket name at its end of the connection, the socket name at the remote end of the
connection and the direction of information flow. If the
two RFCs "match" the connection is established. This
connection procedure requires a priori agreement upon
the sockets to be used for the connection. The second
common connection procedure is used in situations in
which one process wishes to provide some sort of service
to other processes. The "serving" process establishes
a ltstening socket within its host which is receptive to
RFCs from any other process in the network and then
"listens" for connection attempts. The serving process
uses facilities provided by its NCP to detect the occurrence of a connection attempt and to determine its
source. When such an attempt is made the serving
process can choose to accept or reject it. This connection procedure requires that only one socket name,
that of the serving process's listening socket, be known
McROSS
a priori. In the remainder of this paper
[H.P.N~JL
and
[H.P.N~ JL
are used to denote connections established in a listening
state.
The TENEX operating system
TENEX5 is a time sharing system for the DEC
PDP-I0 processor augmented with paging hardware
developed at BBN. For purposes of this paper it is
useful to describe TENEX in terms of the virtual
processor it implements for each logged-in user (i.e.,
user time sharing job) .
The instruction repetoire of the TENEX virtual
processor includes the PDP-I0 instruction set with the
exception of the direct I/O instructions. In addition, it
includes instructions which provide access to virtual
processor capabilities implemented by the combination
of the TENEX software and hardware.
The TENEX virtual processor permits a user job to
create a tree-structured hierarchy of processes. Such
processes have independent memory spaces and computational power. At different stages in its lifetime a
single user job ma)\ include different numbers of processes in various states of activity. Several mechanisms
for interprocess communication are provided by the
TEN EX virtual machine. Processes can interact by
sharing memory, by interrupts and by direct process
control (e.g., one process stops, modifies and restarts
another which is "inferior" to it in the hierarchy) .
A memory space is provided by the virtual processor
which is independent of the system configuration of
core memory. Each process has a memory space of
256K words which is divided into 512 pages each of
512 words. A process can specify read, write and execute
protection for pages in its memory space as it sees fit.
The virtual machine includes a file system which
provides a mechanism for storing information on .and
retrieving it from external devices attached to TENEX.
Processes refer to files using symbolic names, part of
which identifies the particular device on which the
file resides. The instruction set of the virtual machine
includes operations for data transfer to and from files
which a process can execute without explicitly arranging for buffering.
The NCP resident in TEN EX makes the ARPANET
appear to TENEX processes as an I/O device. The
name of a "file" corresponding to a network connection
includes the names of both the local socket and the
283
remote socket which define the connection. A process
requests TENEX to estabJish a connection by attempting to open an appropriately named "network" file.
The open attempt succeeds and the connection is established if and when another process issues a matching
RFC. TEN EX processes transmit and receive information over network connections by executing the normal
file data transfer instructions.
ROSS
ROSS is a programming system for modelling air
traffic situations. 2 It includes facilities for creating and
running simulation experiments involving air traffic in
an experimenter-defined airspace. The system is currently being used in a number of air traffic control research projects.
To create a simulation experiment the experimenter
uses ROSS language forms to write a "program" which
defines the geography of an airspace, the wind profile
for the airspace, aircraft flight characteristics and a set
of "route procedures." A route procedure consists of a
sequence of one or more "instructions" for monitoring
or controlling the progress of an aircraft through the
simulated airspace. Execution of a route procedure is
the ROSS counterpart of pilot and/or controller actions.
The "flight" of a simulated aircraft through the airspace is accomplished by the execution of a series of
route procedures. ROSS includes "primitive" route
procedures to "create" aircraft, "inject" them into and
remove them from the simulated airspace as well as
ones which cause aircraft to accelerate, turn, climb and
descend.
By compiling his program the experimenter creates
a simulator for traffic in the airspace he has defined.
To perform a simulation experiment the experimenter
runs his program. The simulated airspace remains
empty until the program is supplied with input which
inject aircraft into the airspace and control their flight
through it. Each input line the simulator receives is
passed to an internal parsing mechanism which issues
a call to an appropriate experimenter-defined or primitive route procedure. The program can accept input
from an on-line terminal, a predefined "scenario" file,
or both. Input lines from the scenario file are identical
to ones from the on-line keyboard with the exception
that scenario file input lines include a time field which
specifies the (simulated) time at which the program is
to accept them. A user can manually "vector" aircraft
through the airspace by supplying input at the on-line
keyboard.
A ROSS simulator can drive displays of the airspace
284
Spring Joint Computer Conference, 1972
and, in addition, can generate output which can be
written into files, typed on the on-line keyboard or
sent back into the simulator input parser.
THE
McROSS PROGRAMMING SYSTEM
The McROSS system provides the ability to define
simulation experiments involving a number of airspaces
or "simulation centers" which can be interconnected
to form a simulator network. Adjacent centers in the
simulator network are connected to one another by way
of the ARPANET. The components of a simulator network may run as user jobs distributed among different
TENEXs or as different user jobs on the same TENEX.
(As of January 1972 the ARPANET included five
TENEX hosts.)
Computational responsibility for performing a multicomputer McROSS simulation is truly distributed.
For example, as an aircraft flies from one airspace into
an adjacent one the responsibility for simulating its
dynamics shifts from one computer to another.
Goals
The McROSS system was implemented to achieve
the following goals:
1. Autonomy of parts:
Individual components of a McROSS network
should be able to operate independently of one
another (to the extent that each is independent
of the others for traffic). Furthermore, no center
should be able to cause another to malfunction.
Autonomy of parts enables a multi-computer
simulation to run when only some of its components are operational. Failure of a component
center in a multi-center simulation results in
degradation of the total simulation rather than
forced termination of it. A beneficial side effect
of autonomy is that individual centers can be
partially debugged without running the entire
simulator network.
2. Deferral of process/processor binding:
The binding of centers in a McROSS network to
host computers in the ARPANET should be deferred until run time. This goal can be stated in
more general terms. The program for a distributed computation defines a logical configuration made up of abstract relations between the
computation's parts. A given execution of the
program is accomplished by a particular physical
configuration of computers. The two configurations, logical and physical, are by necessity re-
lated. However, the programmer should have
the option of specifying them separately. By
deferring process/processor binding the configurations can be separately specified. As a
result the programmer is free while composing
his program to concentrate on the logical structure he wants his program to define without
concerning himself with details of the physical
structure on which it is to be run.
3. Capability for dynamic reconfiguration:
In the course of a simulation it should be possible for adjacent centers to dynamically break
and reestablish connections with one another.
Furthermore, it should be possible for process/
processor binding to be changed during a simulation. That is, it should be possible to change the
physical location of a center from one
ARPANET host to another. The ability to dynamically reconfigure makes it possible to remove an improperly operating center from the
simuLator network and replace it with another at
the same ARPANET host or at a different one.
4. Decentralization of control:
McROSS is to be used as a tool for investigating
distributed computation. Among the subjects to
be studied are methods for controlling such computations. I n particular, various techniques for
distributing control responsibilities among the
parts of a computation are to be experimentally
investigated. It is important, therefore, that
operation of the McROSS system not require a
central control mechanism for coordinating
simulator networks. Stated somewhat differently, the only components required for a
McROSS simulation should be simulation centers defined by McROSS programs. The realization of this goal, which makes experimentation
with distributed control possible, should not
preclude experimentation with centralized
control.
5. Remote monitoring capability:
A McROSS simulator network should provide
ports through which its components are accessible to any ARPANET host. An appropriately
programmed process running at any ARPANET
hostfthould be able to "attach" to a component
of a simulator network to monitor and control its
operation. A remote monitoring process should
be able to:
a. obtain sufficient information to display traffic
in the airspace it is monitoring.
b. serve as the on-line keyboard for the center
it is monitoring;
McROSS
c. "detach" from one center and "attach" to
another in the course of a simulation run.
M eRO S S as seen by the user
A McROSS simulator network is defined by a program composed of a "network geometry" sub-program
and sub-programs corresponding to each of the centers
in the network.
The network geometry sub-program defines the logical geometry for a simulator network. Conceptually, a
network is composed of nodes and arcs. Nodes in a
McROSS network are simulation centers and arcs are
duplex connections between centers. Figure 1 shows a
four node simulator network which could be used to
simulate air traffic between Boston and N ew York. The
following geometry sub-program defines that network:
netbegin
neteen BOSTRM, BOSCEN, NYCEN,
NYTRM
neteon BOSTRM, BOSCEN
neteon BOSCEN, NYCEN
neteon NYCEN, NYTRM
netend
The neteen statement declares that the network con-
BOSTRM
NYTRM
Figure I-A simulator network which could be used to simulate
air traffic between Boston and N ew York
285
tains four nodes (Boston terminal control, Boston en
route control, N ew York en route control and X ew
York terminal control). The netcon statements declare
the three arcs; netbegin and netend serve to bracket the
geometry declarations.
In general, the sub-program for each center has four
parts:
•
•
•
•
a route procedure module
a local geography module
a wind profile module
an aircraft characteristics module.
In addition to defining procedures followed by aircraft as they fly through a center's airspace, the route
procedure module includes routines specifying how the
center interacts with its neighbors. Information exchange between adj acent centers. is accomplished by
sending messages across the connection between them.
A center handles messages from neighboring centers by
submitting them to its input parsing mechanism. Such
messages are treated identically to input from its on-line
console and scenario file.
The ability of adjacent centers to interact depends
upon the state of the connection between them as each
sees it from its end of the connection. A center may
consider a connection to be in one of three states:
1. uninitialized:
the "physical location" of the neighbor IS
unknown;
2. closed:
the "physical location" of the neighbor is known
but the connection is not capable of carrying
messages (either because it has not yet been
established or because it has been broken);
3. open:
the connection may be used for information exchange with the neighbor.
In the current implementation of McROSS the
"physical location" of a neighbor includes both the
ARPANET host the center is running on (e.g., BBN)
and the identification of the user it is running under
(e.g., Jones).
McROSS provides the operations init, eonn,dseonn
and abort for changing the state· of a connection. The
effect these operations have on the end of a connection
is illustrated by the state transition diagram of Figure 2.
Consider the geometry for the Boston-New York
simulation. Execution of
eonnBOSTRM
286
Spring Joint Computer Conference, 1972
tional aids, obstructions and airports. In addition it
includes a declarative statement which names the simulation center. For example, the geography module for
the BOSTRM center would include the declaration
atccen BOSTRM.
This declaration has the effect of binding the identifier
THISIS to the name BOSTRM. Thus in the BOSTRM
center THISIS is bound to BOSTRM while in the
NYTRM center it is bound to NYTRM. Route procedures which access the simulator center name can ,be
written in terms of THISIS to enable their use at any
center in a simulator network.
A properly authorized process at any ARPANET
host can attach to a center in a McROSS simulator
network and request output from it and direct input
to it thereby monitoring and controlling its operation.
McROSS center programs are prepared to offer two
kinds of service to remote monitors:
dsconn
Figure 2-Transition diagram for the state of the end of a
connection showing the effect of the operations init, conn,
dsconn and abort
within the BOSCEN initiates an attempt to open a
connection with BOSTRM. The connection attempt
succeeds if a matching conn is executed by the
BOSTRM center. The effect of executing
dsconn NYCEN
within the BOSCEN center simulator is to break the
connection between the NYCEN and BOSCEN centers
by forcing both ends of it into the closed state; abort
works in an analogous manner. Execution of the init
operation results in a center-user dialogue in which the
human user is asked by the center program to specify
the physical location of the neighbor.
Two language primitives are provided for sending
messages from one center to another. One takes a single
operand, a message, which it sends to every neighbor
whose connection is in the open state. The other takes
two operands, a message and the name of a neighboring
center. If the connection to the center is open, the message is sent to the center; otherwise the operation has
no effect. Because they are submitted to the input
parsing mechanism care must be taken that messages
sent to a neighbor are formatted correctly.
McROSS includes operations which can be used by
a center to obtain information about the simulator
network and its immediate neighbors. For example,
tllere is a primitive which produces a list of all nodes in
the network (i.e., all centers declared by the netcen
declaration); another one produces a list of all neighboring centers for which connections are in the open
state. In addition, a center can examine the state of the
connection to each of its neighbors individually.
The local geography module defines the airspace of a
center by specifying names and locations (x-y coordinates) of important geographic features such as naviga-
I
1. broadcast service:
Centers continuously broadcast certain information to morntors attached to them. Presently
centers broadcast flight parameters of each aircraft in their air space (speed, heading, altitude,
x-position, y-position, acceleration, aircraft id)
and the (simulated) time. A remote monitor
can use broadcast information to drive a display
of traffic in a center's airspace or it can record
it for later analysis.
2. demand service:
Each center is prepared to respond to certain
specific requests from monitors. In the current
implementation a monitor can request that a
center:
a. transmit its map of the airspace (which can
be used as background for displaying the
center's air traffic) ;
b. stop the continuous broadcast;
c. resume the continuous broadcast;
d. treat the monitor as its on-line keyboard by
directing keyboard output to the monitor
and accepting input from it;
e. cease treating the monitor as its on-line
keyboard;
f. break its connection with the monitor.
The monitoring facility has proven useful both for
debugging and for demonstration purposes. One difficulty a user faces in debugging a multi-center simulation is determining what is happening at centers suspected to be malfunctioning. A monitor, constructed
appropriately, can serve as a "graphical probe" and be
McROSS
used to watch the operation of first one suspect center
and then another. For example, we have used such a
monitor to follow the trajectory of an aircraft as it
passes through several centers.
By enabling processes at arbitrary ARPANET sites
to observe and control McROSS simulations, the
monitoring facility provides a mechanism for· using
hardware and software features which are unique to
various network installations. By using monitors which
play an active role in his simulations a McROSS user
can experiment with different ways of partitioning
computational and control responsibilities in air traffic
situations. He could, for example, experiment with a
monitor built to provide a weather advisory service for
simulator centers. Such a monitor would presumably
have access to an on-line weather data base. (A weather
data base to be accessible through the ARPANET is
currently being designed. 10) To perform its service for a
center the monitor would attach to the center, requesting that" the center broadcast aircraft flight parameters
to it and accept input lines from it. It would then
"watch" the airspace of the center and send instructions
to it, as necessary, to vector aircraft around severe
weather.
Unless he chooses to do so, the simulation programmer need not concern himself with remote monitoring
beyond specifying at simulation run time which centers
in his network are to be receptive to remote monitors.
Monitors themselves are not part of the McROSS
system. McROSS merely provides a mechanism for remote monitoring. No effort has been made to provide
linguistic features within the McROSS system to make
it easy to write programs to do monitoring.
THE McROSS IMPLEMENTATION
Some interesting aspects of the McROSS implementation are discussed in'this section. The section
focuses on strategy rather than detail. The result is a
simplified but nonetheless accurate sketch of the
implementation.
The ROSS implementation
Implementation of McROSS was accomplished by
extending the existing ROSS simulation system. A
ROSS simulation consists of initialization, simulation
and termination phases. The simulation phase is implemented as a loop. Each pass through the loop represents a "tick" of the clock which maintains simulation
time. On each tick the simulator:
1. parses and interprets input directed to it from
287
SOCKETS
(I
- I".
HA 'PA 'SAS 1
'I
oP. oR.A
CENTER
CENTER
A
B
"A
OPA
1-
0 ...
I"·op.os ..
Figure 3-Schematic of center-center connection between adjacent centers A andB. SAB, RAB, SBA and RBA are assigned at
program translation time; H A , HB, P A and P B are determined
at run time
2.
3.
4.
5.
6.
its scenario file and on-line console since the
last tick;
interprets the route procedure each aircraft is
currently following;
advances each aircraft along its trajectory taking into account the aircraft's speed, acceleration
and heading and the wind profile of the airspace;
directs output generated since the last tick to
the appropriate devices;
performs actions necessary to maintain the local
display of its airspace:
increments the simulated time.
A ROSS simulation can be run either in a "real time"
mode in which simulated time is locked to real time,
or in a "hyper fast" mode in which the simulation proceeds as iast as it can.
Process/processor binding and center-center connections
Connections between pairs of simulator network
centers are duplex. Each center-center connection is
implemented by two ARPANET connections. More
specifically, an open connection between centers A and
B is realized by the two ARPANET connections (see
Figure 3):
HA. P A. SAB~HB' P B. RBA
H A. P A. RAB~ H B. P B. SBA
To establish such a center-center connection two pairs
of matching RFCs must be issued by centers A and B.
To issue the correct RFCs A must know H B, P B, RBA
and SBA; similarly, B must know H A, P A, RAB and SAB.
288
Spring Joint Computer Conference, 1972
The host (H) and process (P) components of the
socket names for a center-center connection cannot be
determined until run-time because process/processor
binding is deferred until then. However, the processlocal components (R and S) of the socket names can be
pre-assigned and, in fact, the effect of the declarations
in the network geometry sub-program for a particular
McROSS network is to do exactly that.
The process local components for the four socket
names corresponding to a center-center connection are
always the same whereas the host and· process components may change from run to run or even within the
same run if either neighbor is involved in a dynamic
reconfiguration.
When a center's end of a center-center connection is
in the uninitialized state the host and process components of the socket names corresponding to the remote
end are unknown to it. To move its end of a connection
from the uninitialized state. the center engages in a
dialogue with the user requesting from him the physical
location of the neighbor. After successfully completing
the dialogue the center has sufficient information to
issue the two RFCs required of it to establish the
connection.
Each center willing to service monitors maintains as
an "attach" socket a send socket in a listening state
(see Figure 4.a). The attach socket for C could be
denoted
[Hc.Pc.A~JL
The process local component (A) of the name for attach sockets is the same for all centers and is "welladvertised." Therefore, if M knows the physicallocation of C it can issue an RFC for C's attach socket.
The effect of such an RFC is to establish the connection
(Figure 4.b)
Hc.Pc.A~HM,PM.RM
Upon detecting an RFC for its attach socket, C notes
HM and PM and transmits SCM and R over the connection. Next both C and M break the connection and
listening
(0)
CENTER
C
Center-monitor connections
The connection between a center C and an attached
remote monitor M is realized by two ARPANET connections. One of them
---+
Hc'Pc'A :
(b)
CENTER
C
(c )
CENTER
C
Hc. Pc. SCM~HM. PM. R MC
I HM'PM'R M
MONITOR
M
is a "broadcast" connection used for continuously
broadcasting information to M. The other
[Hc.Pc.R~ JL
is a "request" connection maintained by C in a listening
state for M to use to make requests of C. Each monitor
attached to C has its own broadcast connection but
may share a request connection with other monitors.
To make a request of C, M connects to the request
socket, transmits its request over it and then closes the
request connection, freeing it for use by other monitors.
The action taken by C of course depends upon the request. If the request were for the display map, C would
transmit the map data over the broadcast connection
toM.
Before the RFCs required to establish a centermonitor connection between C and M can be issued
C must know H M, PM and RMc and M must know
H c , Pc, SCM and R. To obtain the required information,
M and C engage in a connection protocol which is
similar to the "initial connection protocol" developed
by the ARPANET network working group. 6
---+
Hc'PC'SCM :
HC'PC'R
Hc ·Pc·A
(d)
CENTER
C
Hc''C'SCM
MONITOR
IHM,PM'RMC
.-.-
~
M
listening
listening
---+
MONITOR
,HM'PM'RMC
M
40-
Hc'Pc'R
listening
Figure 4-Schematic of connection protocol exchange between
center C and monitor M
McROSS
289
issue the RFCs necessary to establish the broadcast
connection (Figure 4.c)
Hc. Pc. SCM~HM' PM:. R MC
where RMc=f(RM), a pre-agreed upon function of R M.
C, if it has not done so previously for another monitor,
sets up the listening connection
[Hc.Pc.R~ JL
and finally, reestablishes its attach connection so that
other monitors can attach to it (Figure 4.d). Currently
the process-local components for ARPANET socket
names are numbers and f is taken to be
f(x) =x+2.
If RM rather than f(R M) were used for R MC a race
condition would result when M and C attempt to establish the broadcast connection. The race involves the
order in which the connection with socket H M. PM. RM
would be closed and reopened by C and M. In particular, the current TENEX NCP is such that an attempt
by· C to open the network file corresponding to its end
of the (broadcast) connection
Hc. Pc. SCM~HM . PM. RM
before M closes the network file corresponding to its
end of the connection
Hc.Pc.A~HM.PM.RM
would fail. Use of f(R M) for RMC avoids the race. A
similar race condition, discovered in an early version
of the ARPANET initial connection protocoJ,7 is
avoided in the current protocol by the same technique. s
Process structure at M cROSS centers
A McROSS center is realized by a collection of cooperating, asynchronously evolving, sequential processes. The collection corresponds to a partitioning of
the center's responsibilities into more or less independent sub-tasks. It includes:
1. a process (SIM) to perform the ROSS functions;
2. a process (CONN) for each center-center connection to establish and maintain the connection;
and
3. a monitor server process (MONSER) to service
remote monitors.
The CONN process at center A corresponding to the
center-center connection to center B is responsible for
establishing ARPANET send and receive connections
with B. After it establishes the center-center connection
Figure 5-The process hierarchy which implements a McROSS
simulation center with n neighbors
with B the CONN process maintains the connection.
When messages from B arrive it passes them on to the
SIM process for parsing.
The job of the MONSER process at a center is
twofold: to engage in an initial connection protocol exchange with monitors attempting to attach to the
center and to respond to requests made by attached
monitors.
The processes at a center exist in a hierarchy (see
Figure 5). The hierarchical structure is less the result
of anyone process being more important than any
other than it is a consequence of the TENEX constraint that process groups be hierarchically arranged.
During initialization the SIM process creates the
MONSER and CONN processes. Thereafter, the processes evolve more or less independently.
The process structure at each center helps achieve
autonomy of parts. The CONN processes and the
MONSER process serve to protect the SIM process by
insulating it from direct interaction with other centers
and remote monitors.
Protocols
The current implementation of the TEN EX NCP
is such that if a center were to unilaterally break a connection with a neighbor (by closing the two corresponding ARPANET connections) it could leave processes
in the neighboring center in an irrecoverable state. For
example, a process in the neighbor sending information
across the connection at the time it is broken would
"feel" the close as if it had executed an illegal instruction. To prevent such situations McROSS centers en-
290
Spring Joint Computer Conference, 1972
gage in a protocol exchange prior to breaking
connections.
The center-center protocol is relatively simple. To
perform an abort or dsconn operation a center sends its
neighbor a "request for abort" or "request for disconnect" message and waits until it receives ani acknowledgment before actually breaking the connection.
Existence of the center-center protocol has two major
implications. The first is that a center-center connection
has more states than the three noted earlier. The additional states are transient ones which the connection
passes through as the center and its neighbor advance
through protocol exchanges initiated when one attempts
to change the state of the connection. The transient
states are invisible to the McROSS user. Immediately
after a dsconn (or abort) is initiated the SIM process
treats subsequent operations involving the connection
as if the connection were already in the closed (or
uninitialized) state. The second implication is that
center-center connections carry "control" messages
used in center-center protocol exchange in addition to
"ordinary" messages intended for the receiver's parsing
mechanism. The CONN process for each connection
must be prepared to recognize and respond appropriately to both kinds of messages.
McROSS centers expect remote monitors to observe
a center-monitor protocol. In addition to the connection and request procedures described earlier, the
center-monitor protocol includes a disconnection procedure much like the· one used in the center-center
protocol.
I nterprocess communication
To perform their tasks the processes at a simulation
center must interact occasionally. For example, the
arrival of a message from a neighbor requires interaction between the SIM and CONN processes. The
CONN process receives the message and passes it onto
the SIM process for parsing and interpretation.
One way the processes interact is through shared
memory. For example, the SIM and CONN processes
have read and write access to a shared "connection
table." There is an entry in the table for each centercenter connection which includes the state of the connection, a semaphore9 and other information relevent
to the connection. Use of the table is coordinated by
strict adherence to a convention which requires every
"critical" access (every write access and certain read
accesses) to an entry to be bracketed by P (lock) and
V (unlock) operations on the entry's semaphore.
The situation arising at a center when a neighbor
attempts to break connection ",ith the center is a
typical one which requires interprocess communication.
The CONN process corresponding to the center-center
connection receives a "request for disconnect" message
from the neighbor. Center-center protocol requires the
CONN process acknowledge the request so that the
neighbor can break the connection. The purpose of the
protocol exchange is to warn the center that the connection is about to be broken and that it should no
longer attempt to use it. Therefore before it acknowledges the neighbor's request it is important that the
CONN process communicate this information to the
other processes at its center. The CONN process does
this by the following sequence of actions:
P(CONNECTION SEMAPHORE);
set connection-state to "not open";
V(CONNECT10N SEMAPHORE);
acknowledge neighbor's request
As long as processes at the center perform the following
sequence of actions to send over center-center connections there is no danger of sending after the connection
has been closed:
P(CONNECTION SEMAPHORE);
if connection-state = open
then send
else abort the send;
V(CONNECT10N SEMAPHORE)
Stated somewhat differently, sending over a centercenter connection should be regarded as an operation
which involves a "critical" read access of the corresponding connection table entry.
In addition to memory sharing, direct process control
is used as a mechanism for interprocess communication
in the McROSS system. Because of its superior position
in the process hierarchy the SIM process can exert
direct control over the other processes. A few situations
occur in which it does so. For example, when a centercenter connection has been closed or aborted (via
dsconn or abort) the SIM process forces the corresponding CONN process to halt. If and when an attempt is
initiated to reestablish the connection (via conn)
SIM restarts it.
SOME OPEN QUESTIONS
This section briefly discusses questions representative of ones which have arisen in the course of using
the McROSS system. The questions have been resolved
to the extent that useful simulations can be performed
using McROSS. However, none has been resolved in a
McROSS
totally satisfactory manner. The intent of this section
is to leave the reader with an appreciation for the issues
raised by these questions; a thorough discussion of
them is well beyond the scope of this paper.
291
unknown names in certain limited contexts are being
investigated. However, the general problem of handling
such references is an open question.
Program residence
Synchronization
Simulated time is important in the operation of the
McROSS system. In particular, whenever an interaction between adjacent centers occurs it is important
that the clocks kept by the centers show approximately
the same time. Time synchronization is a specific example of the general problem of control in ~istributed
computation. It is compounded by the fact that centers
can start up and shut down independently of one
another. A centralized approach to synchronization
has been used with success in McROSS simulations.
In it, one center acts as a synchronizer for an entire
simulator network. When a center starts up it connects
to the synchronizer and receives a synchronization
message from it. Thereafter, to stay in synch with
other centers in the network, the center makes use of
the real time clock in the computer it runs on. A distributed approach to synchronization which does not
require a synchronizing center is under consideration.
Locally unknown names /
N ames that are well defined within a simulator network as a whole are not necessarily defined at every
node in the network. How should references to such
names occurring within centers in which they are not
defined be handled? For a specific example in which
such a reference is reasonable, reconsider the (four node
network for simulating Boston-New York traffic. A
user controlling the simulator for Boston Terminal who
is manually vectoring an aircraft leaving Logan airport
might reasonably issue the clearance
fly (V205, PAWLING)
which specifies that the aircraft is to follow Victor Airway #205 to Pawling. Assume that V205 is defined
within the geography modules for BOSTRM, BOSCEN
and NYCEN and the PAWLING is defined within
NYCEN but not within BOSTRM or BOSCEN. The
BOSTRM center can't fly the aircraft to Pawling because Pawling is not defined within its airspace. Ideally
it should fly the aircraft along V205 to the boundary
of the BOSCEN airspace and then hand it off to the
BOSCEN simulator. Certainly it should be able to do
better than report an error and abort the route procedure. Techniques for handling references to locally
Where should the program (route procedures) required to fly an aircraft through several simulator
centers reside? Should the program be associated with
the aircraft and passed with it from center to center or
should parts of the program be distributed among the
relevant centers? The approach\ currently used in
McROSS simulations is to distribute the program and
pass only the aircraft and its flight parameters from
center to center.
Interruption and resumption of route procedures
Aircraft frequently interrupt their flight plans temporarily in order to avoid severe weather or heavy
traffic. The simulation analogy to a flight plan is the
route procedure. How should a center handle interruption and subsequent resumption of route procedures?
Interrupting the execution of a route procedure in
order to follow another one is not difficult. The difficulty arises in determining how to appropriately resume
the interrupted procedure. In general, the point of interruption is inappropriate as a resumption point. A
considerable amount of (simulated) time can elapse
between interruption and resumption during which the
flight parameters (position, speed, altitude and heading) of the aircraft can change significantly. Therefore,
the usual programming technique of saving the "state"
when an interrupt occurs and restoring it after the
interrupt has been handled is inadequate. The interruption/resumption problem is made more complex by
the possibility that between interruption and resumption the aircraft may fly out of the airspace of one
center and into the airspace of another. The current
McROSS implementation is not prepared to handle
interruption and subsequent resumption of route
procedures.
Error handling techniques for distributed systems
The question of how to handle error situations in a
distributed computational system is a challenging one.
In McROSS considerable attention has been given to
making nodes in a simulator network autonomous. The
strategy for handling errors is to try to achieve a
"local" error recovery whereby a node attempts to preserve its autonomy. As a result, while the actions it
292
Spring Joint Computer Conference, 1972
takes are locally optimal in the sense that its continued
operation is insured, they may be sub-optimal in the
more global context of the entire simulation network.
Errors occurring in inter-node messages are simply
handled in the current McROSS implementation. Recall from an earlier section that inter-node messages
are submitted to the parsing mechanism of the destination node. When a node receives a message which is
syntactically incorrect or semantically meaningless
(to it) from a neighbor, it reports the error on its
on-line keyboard, sends a message to the neighbor causing the error to be reported on the neighbor's on-line
keyboard, and ignores the message. This procedure is
locally satisfactory in the sense that it guarantees that
messages which are not well-formed cannot cause the
node to malfunction. However, if the incorrect message
from the neighbor is one critical to the outcome of the
simulation, this procedure is not globally acceptable.
Ideally, upon detecting an error in a message, the node
should engage in a dialogue with its neighbor in an
attempt to resolve the error. The difficulty in implementing this strategy is that it is frequently unclear
what should be done to resolve an error. Often the
cause has been masked by the time the error is detected.
While the simple techniques used in McROSS for
error handling have proven adequate, it is clear that
more effective techniques can be developed.
CONCLUDING REMARKS
The results of the work reported in this paper are applicable in two areas.
One area is research in air traffic control. Researchers
can use the McROSS system to conduct simulation
studies preliminary to the design of an automated
mUlti-component air traffic control system. For example, McROSS could be used to evaluate various
ways of partitioning responsibility among components
of such a system. Or, it could be used to compare different strategies for automated scheduling and control of
aircraft. Because it exhibits autonomy of parts and the
ability to dynamically reconfigure, it could be used to
experimentally study the behavior of failure handling
techniques for a multi-center system under various air
traffic loads.
The other area is the design and implementation of
distributed computation systems. The results in this
area are incomplete and tentative consisting prjmarily
of insights and attitudes developed from the experience
of building and using a distributed computation system.
These are summarized by reviewing the goals for the
McROSS system in terms of problems they posed and
techniques useful in realizing them.
Of the five goals, autonomy of parts and deferral of
process/processor binding were the most significant in
terms of effort required to achieve them and· influence
on the appearance of the system to users. Given their
realization, the other three goals (the ability to dynamically reconfigure a simulator network, decentralization of control and ports for monitoring) were relatively easy to achieve.
The strategy of implementing parts of the distributed
computation by process groups rather than solitary
processes contributed significantly to achieving autonomy of parts. The multi-process implementation
made it possible to dedicate certain processes at a node
to maintaining an interface with other nodes and to
dedicate other processes to performing functions crucial
to the node's existence. In addition to insulating vital
internal node functions from the actions of other nodes,
the functional modularity resulting from multi-process
nodes had the effect of reducing the complexity of the
implementation: each individual process being considerably less complex than an entire node. The multiprocess capability which the TENEX operating system
supports for each user- job was invaluable in carrying
out the multi-process strategy. It is unfortunate that
few operating systems allow users to create and maintain process structures.
Equally useful in realizing autonomy was the establishment of and strict adherence to protocols for partpart interactions. A center can expect monitors and
adjacent centers which are functioning properly to observe protocol and can therefore interpret a breach of
protocol as a warning that the offender may be malfunctioning. A consequence of the multi-process implementation of nodes is that interprocess communication
occurs within McROSS at two levels: inter-node and
intra-node. Use of a protocol for intra-node interactions
helps insure that internal node data bases always accurately reflect the condition of the node's interface
with other nodes. A useful implementation rule was to
reject any technique whose success depended upon the
order in which events in different centers or in different
processes within the same center occur.
The major problem in implementing deferred process/
processor binding was providing a way for parts of the
computation to determine the location of logically adj acent parts at run time. The solution used in the
current McROSS implementation, which requires run
time interaction with the user, is not totally satisfactory. A more satisfactory alternative might be for each
part to engage in a network-wide search for logically
adjacent parts.
We expect to see a trend toward distributed multicomputer systems in the future. By its existence
McROSS demonstrates that the construction of such
systems is currently feasible.
McROSS
ACKNOWLEDGMENT
The McROSS system grew from an idea proposed by
Dr. W. R. Sutherland of BBN; we gratefully acknowledge his guidance and enthusiasm.
The realization of the current McROSS implementation is the result of building upon the work of others,
most significantly the designers and implementers of
the ARPA computer network and of the TEN EX
operating system.
REFERENCES
1 L G ROBERTS B D WESSLER
Computer network development to achieve resource sharing
Proceedings of AFIPS SJCC 1970
2 W R SUTHERLAND T H MYER E L THOMAS
D A HENDERSON
A route oriented simulation system for air traffic control
studies
Proceedings of the Fifth Conference on Applications of
Simulation December 8-10 1971
3 F E HEART R E KAHN S M ORNSTEIN
W R CROWTHER D C WALDEN
The interface message processor for the ARPA network
Proceeding of AFIPS SJCC 1970
293
4 S CARR S CROCKER V CERF
HOST-HOST protocol in the ARPA computer network
Proceedings of AFIPS SJCC 1970
5 D G BOBROW J D BURCHFIEL D L MURPHY
R S TOMLINSON
TENEX, A paged time sharing system for the PDP-10
Paper presented at the Third ACM Symposium on
Operating System Principles October 18-20 1971
published in Communications of the ACM March 1972
6 ARPA network current network protocols
August 1971 Available from the Network Information
Center as NIC fI, 7104 at Stanford Research Institute
Menlo Park California 94025
7 W NAYLOR J WONG C KLINE J POSTEL
Regarding proffered official ICP
Unpublished memo available from Network
Information Center NIC #6728, 1971
8 A SHOSHANI
A solution to the race condition in the I CP
Unpublished memo available from the Network Information
Center NIC fI, 6772 1971
9 E W DIJKSTRA
Cooperating sequential processes
Appears in Programming Languages edited by F Genuys
Academic Press New York 1968. Also published as Report
EWD123 Dept of Mathematics Technological University
Eindhoven The Netherlands 1965
10 D STERN
Weather data
Unpublished memo available from Network Information
Center NIC fI, 7692 1971
Extensions of packet communication technology
to a hand held personal terminal
by LAWRENCE G. ROBERTS
Advanced Research Projects Agency
Arlington, Virginia
N ow, within the last decade or less, the advances in
digital computers and electronics have, in many cases,
reversed the economic balance between circuit and
packet communication technology. Perhaps the best
proof of this is the economy of the ARPA N etworkl - 6
for country-wide computer to computer communication, but many other examples are beginning to appear
such as the University of Hawaii's ALOHA System7
utilizing packet radio transmission for console communications and the experiments with digital loops for
local distribution. However, most of the experiments
with packet communications have been undertaken by
computer scientists, and it is not even generally recognized yet in the communications field that a revolution
is taking place. Even where the knowledge of one of
these experiments has penetrated the communications
field, it is generally written off as a possibly useful new
twist in communications utilization, and not recognized
as a very different technology requiring a whole new
body of theory. Throughout the development of the
ARPA Network, communication engineers compared it
with conventional circuit switched systems but, perhaps unconsciously, used rules of thumb, statistics and
experience applicable only to circuit switched systems
as a basis for comparison. A century of experience and
tradition is not easy to ignore and in fact should not be
ignored, only it should be properly classified and segregated as resulting from a different technology.
Packet corp.munication technology is only beginning
to be explored but already it is clear that the design of
all forms of communications channels and systems
should be rethought. As an example of the kind of
difference packet communications can make in a perhaps unexpected area, the design of a personal terminal
will be explored in some detail. Although such a terminal has never been built, it is most likely completely
feasible to build and would provide many unique
advantages.
INTRODUCTION
Electronic communications technology has developed
historically almost completely within what might be
called the circuit switching domain. Not until the last
decade has the other basic mode of communication,
packet switching, become competitive. Thus, as a technology, packet communication has only begun to be
explored. Circuit switching can be defined in the broad
sense as the technique of establishing a complete path
between two parties for as long as they wish to communicate, whereas packet switching is where the communic~tion is broken up into small messages or packets,
attaching to each packet of information its source and
destination and sending each of these packets off independently and asynchronously to find its way to the
destination. In circuit switching all conflicts and allocations of resources must be made before the circuit can
be established thereby permitting the traffic to flow
with no conflicts. In packet switching there is no dedication of resources and conflict resolution occurs during
the actual flow perhaps resulting in somewhat uneven
delays being encountered by the traffic. Clearly, without
the speed and capability of modern computers, circuit
switching represented a cheaper and more effective
way to handle communications. For radio frequency
assignment and telephone exchanges the resource allocation decisions could be made infrequently enough
that manual techniques were originally sufficient. Also,
since voice was the main information being communicated, the traffic statistics were sufficiently compatible
with this approach to make it quite economic for the
period. Packet switching of a kind, the telegram per. throughout this period but due to the high' cost
slsted
of switching and the limited demand for fast message
traffic never attracted much attention.
For almost a century circuit switching dominated
the communications field and thus dominated the development of communications theory and technology.
295
296
Spring Joint Computer Conference, 1972
HAND HELD PERSONAL TERMINAL
Let us start with the goal of providing each individual
with a pocket-sized, highly reliable and secure communications device which would permit him to send
and receive messages to other individuals or to coputers. Leaving the consideration of design alternatives
muntil the end, a device fulfilling these objectives is as
follows:
Output
Text or graphics displayed on a 2.8"X I" plasma
panel with 80 dots per inch resolution. The screen,
divided into 7 X 10 dot rectangles, using 5 X 7 characters
would hold 8 lilies of 32 characters each for a total of
256 characters. Text this size is almost the same size as
typewriter print, except that the lines are closer together. The plasma panel has internal storage and is
digitally addressed to write or erase a point.
Input
Five capacity or stress sensitive buttons used by the
five fingers of one hand simultaneously to indicate one
of 31 characters. This five finger keyboard technique
was developed by Doug Englebart at SRP to permit
users to type with only 'one hand while working on a
display console. Recently the keyboard has become
fairly widely used at SRI due to its great convenience.
Training time for a new user is evidently less than a
day and speeds of 30 words per minute can be achieved. 9
Although somewhat slower than a good typist (72
speed) the speed is clearly sufficient for a terminal
device even at 10 words/minute.
Transmission
Each input character will be transmitted to a central
controller station using the random access radio transmission techniques developed at the University of
HawaiU The 5 bit character is embodied in a 64 bit
packet containing:
30 bits-Terminal Identification Number
8 bits-Character plus alternation bit, or Count
2 bits-Type of packet (CHAR, ACK, CNT,
ERR, ST ERR)
24 bits-Cyclic Sum Check
64 bits
All terminals transmit their packets independently and
asynchronously on a single frequency and the receiver
at the central controller merely listens for a complete
packet which has a correct sum check. If two terminals'
transmissions overlap the sum check will be wrong, and
the terminals will retransmit when they find they don't
receive an acknowledgment. Retransmission time-out
intervals are randomized between the terminals to
avoid recurrence of the problem. Upon receipt of a good
packet, the central station transmits a display-acknowledgment packet back to the terminal on a second
frequency. This 144 bit packet contains a 70 bit display
raster field and an 8 bit position on the screen. The display raster is a 7 X 10 dot array for the character sent
in and the position includes 3 bits for vertical by 5 bits
for horizontal. Current position information for each
active user is kept by the central station by user ID in
a hash table. Thus, the individual terminal needs no
character generation logic, position advancement logic,
or any other local verification of the input since the
response from the central station both acknowledges the
character and displays it in an input text line at the top
of the display. If a character display-acknowledgment
is somehow lost in transmission the terminal will continue to time-out and retransmit the character. The
central station must somehow differentiate this from
a new character. This is achieved by an alternation
bitlO,ll in the terminal's packet which is complemented
for each new character. On a repeat the bit is the same
as previously and the central station just retransmits
the same character and posi tion again. When a prearranged terminating character is sent the central
station examines the message and takes an appropriate
action. Considerable flexibility exists here, all(~ operational modes could be established. However, the first
message of a sequence should contain a destination as
the first item. This might be the ID of another terminal
in the same area, it might be the address of a service
computer or it might be the ID of another terminal
halfway around the world. In the latter two cases, a
more global network such as the ARPA Network comes
into play. It would be perfectly feasible for a message
to another terminal to be sent to a central or area-coded
directory computer to locate the particular control
station the other terminal was near. Note that the location of neither man was given to the other, only the
message and the ID of the sender. (Based on ARPA
Network cost estimates and international satellite tariff
trends, such a message exchange should cost less than
0.1 cents, independent of distance.)
Reception
At any time when a message destined for a terminal
arrives at the central control station, a transmission to
Extensions of Packet Communication Technology
the terminal may begin, character by character, each
in its own 144 bit packet as follows:
30 bits-Terminal Identification Number
70 bits-7X 10 dot pattern, character display
8 bits-position of character
1 bit -alternation bit
1 bit -broadcast mode
3 bits-Message Type
(Response, initial,
normal)
8 bits-Characters Left in message
24 bits-Cyclic Sum Check
144 bits
The terminal must always be checking all transmission
to detect those with its ID and a correct sum check.
When one occurs which is not a "response" to an input
character, a message is being sent. The first character
of a message is marked type "initial," and has the
count of the remaining characters. Each character is
displayed where the central station placed it. Following
the "initial" character "normal" characters are checked
to make sure the count only decreases by one each time.
After the character with count zero, an acknowledgment type packet is sent by the terminal. If this is lost
(as it may be due to conflicts) the central control will
retransmit the final character over again without complementing the alternation bit until it is acknowledged
(or it determines the station is dead). If a count is
skipped the terminal sends a CNT ERR message with
the count of the character expected. The transmitter
then starts over at that count. If a "normal" type character is received before an "initial" type a ST ERR
message is sent and the message is restarted. A broadcase bit is included which overrides the ID check for
general messages.
Security
Since all transmissions are digital, encryption is possible and would be important no matter what the application, military or civilian. Most private uses such as
personal name files, income-expense records, family
conversations, etc., would be far more sensitive than
current computer console use.
Bandwidth
Personal terminals for occasional use for message exchange, maintaining personal files, querying computer
data bases for reference data, etc., would not lead to
very heavy use, probably no more than two queryresponses per hour. The query we might estimate at 64
characters in length and the response at 256. (Clearly
297
256 character response could also consist of an 80 X
224 point graphic display since each character is sent as
a full 7 X 10 raster.) The average bandwidth consumed
by each terminal is therefore 2.3 bits/second transmitted and 25.6 bits/second received. The random access technique used for transmission requires the channel bandwidth to be six times the average bandwidth
actually utilized in order to resolve all conflicts properly. Thus, the terminal transmission bandwidth consumption is 14 bits/second, still less than the receiver
bandwidth needed. Thus, the central control station's
transmitter bandwidth is the limiting factor assuming
equal bandwidths on both transmitter and receiver. If
a 50KHz bandwidth is used for each and modulated
at 50K bits/sec, then a total of 2000 terminals can be
accommodated. Of course this number depends on the
activity factor. At one interaction every two minutes a
data rate equal to average time shared console use is
obtained and even at this activity 130 terminals can be
supported, more than most time-sharing systems can
support. With 50 KB channels, the time required to
write 256 characters is about one second. Lower bandwidths require increased time, thus, 10KB (5 sec WrIte
time) would be the lowest bandwidth reasonable. Even
at this bandwidth, with the estimated 2 interactions
per hour, 400 terminals could be supported.
COMPARISON
Comparing the effect of the packet technology with
the same terminal operating with preassigned Frequency or Time Division Multiplexed channels (ignoring the losses due to TDM sync bits or FDM guard
bands) the circuit oriented terminal would require a
40 bit/sec transmit channel and a 4KB receive channel
if a 5 sec write time is to be achieved. For 400 terminals
with a 5 sec write time, the circuit method would require a total of 16 Megabits/sec bandwidth whereas the
packet method only requires 20 Kilobits/sec bandwidth. Thus, the circuit technology requires a factor of
800 more bandwidth than the packet technique. Of
course, the circuit mode terminals could interact more
often within the same bandwidth right up to continual
rewrite of the display every five sec, but you would
have to massively reshape the user statistics to suit the
technology.
Another possibility, to design the terminal so that it
performed more effectively in a circuit oriented mode,
would be to put character generation logic and position
logic in the terminal. This would considerably increase
the cost of the terminal, which originally had very little
logic except shift registers. The result of adding this
logic, however, is to reduce the bandwidth by a factor
298
Spring Joint Computer Conference, 1972
of 10 to 1.6MB or still 80 times the packet technique.
The same logic would help. reduce the packet size but,
in order to maintain the graphic output capability and
gross simplicity, it does not seem to pay.
CONCLUSION
As can be seen from the example, packet technology is
far superior to circuit technology, even on the simplest
radio transmission level, so long as the ratio of peak
bandwidth to average bandwidth is large. Most likely,
the only feasible way to design a useful and economically attractive personal terminal is through some type
of packet communication technology. Otherwise one is
restricted to uselessly small numbers of terminals on
one channel. This result may also apply to many other
important developments, only to be discovered as the
technology of packet communication IS further
developed.
REFERENCES
1 L G ROBERTS
B D WESSLER
Computer network development to achieve resource sharing
SJCC 1970
2 F E HEART R E KAHN S M ORNSTEIN
W R CROWTHER D C WALDEN
The interface message processor for the ARP A network
SJCC 1970
3 L KLEINROCK
Analytic and simulation methods in computer network design
SJCC 1970
4 H FRANK I T FRISCH W CHOU
Topological considerations in the design of the ARPA
computer network
SJCC 1970
5 S CARR S CROCKER V CERF
HOST-HOST communication protocol in the ARPA network
SJCC 1970
6 L G ROBERTS
A forward look
Signal Vol XXV No 12 pp 77-81 August 1971
7 N ABRAMSON
THE ALOHA System-Another alternative for computer
communications
AFIPS Conference Proceedings Vol 37 pp 281-285
November 1970
8 D C ENGELBART W K ENGLISH
A research center for augmenting human intellect
AFIPS Conference Proceedings Vol 33 p 397 1968
9 D C ENGELBART
Stanford Research Institute Menlo Park Calif (Personal
communication)
10 W C LYNCH
Reliable full-duplex file transmission over half-duplex
telephone lines
Communications of the ACM Vol 11 No 6 pp 407-410
June 1968
11 K A BARTLETT R A SCANTLEBURY
P T WILKINSON
A note on reliable full-duplex transmission over half-duplex
links
Communications of the ACM Vol 12 No 5 pp 260-261
May 1969
An overview of programming languages
for specialized application areas
by J. E. SAMMET
IBM Corporation
Cambridge, Massachusetts
INTRODUCTION
that one of the major reasons for the proliferation of
programming languages is that designing and implementing languages are fun, and there is a very large
NIH (Not Invented Here) factor that makes even
minor deficiencies in an existing language a justifiable
cause for the development of a new one. This represents the less productive aspect of the proliferation.
However, the important cases (meaning the languages
widely used) fulfill a bona fide need for a language
that can be used by people who don't really understand
programming. The specialized languages help these
people work in their own professional jargon. The motivation for the development usually comes when individuals find that for each existing language there are
facilities that they want, and which they think the
language should legitimately contain, but which are not
basically available in the language. It is important to
emphasize the "not basically available" aspect, as well
as recognizing that there is a value judgment involved
on this issue. There are certainly cases where FORTRAN has been used to write payroll programs but it
is unlikely that anybody would seriously contend that
such usage was appropriate; alternatively, people
should not condemn FORTRAN for being ill-suited
for writing data processing applications since that was
not its intent. Similarly, COBOL has been used to
generate differential equation programs, but that is
certainly a perversion of its major intent. Thus, in considering whether an existing language should be used
for a particular problem, its avowed intent must be
kept well in mind. This applies not only to the syntax
and semantics of the language itself, but also to the
type of the machine or environment for which it was
designed. A language suitable for use in a batch system
is not necessarily well-suited for use in an interactive
mode, even though a compiler or an interpreter for the
language can indeed be put into a time sharing system.
Similarly, a language which provides very good inter-
There are more than 165 different programming languages in use in the United States today, where only
higher level languages are considered as programming
languages. If assembly languages were considered in
this total it would obviously be much higher. The total
number would be still greater if programming languages
in use outside the United States were included. (They
are excluded here only because of the difficulty of obtaining accurate and sufficiently detailed information.)
As individuals, and as an industry, we should ask ourselves, "What is the reason for this enormous proliferation?", particularly since many of these languages
claim to be "general purpose." Some languages do
serve a wide variety of users and applications, whereas
others are restricted in intended· usage. The languages
which have few users are usually in that category because (a) they are basically for a narrow application
area which has relatively few users* or (b) information
about the language has not been widely disseminated,
or (c) the language and/or its implementation is ineffective and/or has inadequate support, or (d) the
language is implemented only on a computer not widely
used. The purpose of this paper is to provide some of
the background and perspective on the existence,
classifications, and general characteristics of those languages which are oriented toward a specialized application area.
The earliest of the major "specialized languages"
seems to be APT, developed at MIT by 1955, for
numerical machine tool control. A small programshown in Figure I-illustrates in an intuitive way the
type of language with/which this paper is concerned. It
is perhaps unfortunate-but is certainly quiM true-
* Some languages which have a narrow area of intended usage
may actually have a large number of users, e.g., COGO.
299
300
Spring Joint Computer Conference, 1972
2
3
4
5
678
Part to be cut
Part Program
Explanation
CUTTER/I
TOLER/.005
FEDRAT/80
HEAD/l
MODEll
SPINDL/2400
COOLNT/FLOO D
PTI = POINT/4, 5
Use a one inch diameter cutter.
FROM/(SETPT =
POINT/I,I)
Start the tool from the point called SETPT,
which is defined as the point with coordinates (1, 1).
INDIRP/(TIP
POINT/I, 3)
Aim the tool in the direction of the point
called TIP, which is defined as the point
with coordinates (1,3).
BASE::: LINE/TIP, AT
ANG L, 0
Defined the line called BASE as the line
through the point TIP which makes an angle
of 0 degrees with the horizontal.
GOTO/BASE
TL RGT, GORGT/BASE
Go to the line BASE.
GOFWD/(ELL I PSI
CENTER, PTI, 3, 2, 0)
Go forward along the ellipse with center at PT1,
semi-major axis = 3, semi-minor axis = 2, and
major axis making an angle of 0 degrees with
the horizontal.
GOLFT/(LINE/2, 4, 1, 3,),
PA ST, BA SE
GOTO/SETPT
COOLNT/OFF
SPINDL/OFF
EN D
Go left along the line joining the points
(2,4) and (1,3) past the line BASE.
FINI
Tolerance of cut is .005 inch.
Use feed rate of 80 inches per minute.
Use head number 1.
Operate tool in mode number 1.
Turn on spindle. Set at 2400 rpm.
Turn on coolant. Use flood setting.
Define a reference point, PT1, as the point
with coordinates (4, 5).
With the tool on the right, go right along
the line BASE.
Go to the point SETPT in a straight line.
Turn off coolant flow.
Turn off spindle.
fhis is the end of the machine control unit
operation,
and the finish of the part program.
Source: Hori, S. Automatically Programmed Tools, Armour Research Foundation of Illinois Institute of Technology,
AZ-240, Nov. 1962.
Figure 1-APT (machine tool control)
Languages for Specialized Application Areas
active facilities does not necessarily provide the broad
flexibility and control normally found (or needed) in
batch programs of great complexity.
In order to more explicitly establish the level of
language that is being discussed, the defining characteristics of a higher level language are considered to be
the following: (1) machine code knowledge is unnecessary, i.e., the user does not have to know the machine
instructions available on any computer; (2) there must
be good potential for converting a program written in a
higher level language onto another machine; that is
equivalent to saying that the language must be basically
machine-independent (but since we know that no
languages to date are completely machine-independent,
what is being stipulated is a good potential for conversion to another computer); (3) there must be an
instruction explosion, i.e., for most of the statements
that the user writes in the higher level language, the
computer (through a compilation or interpretive process) should generate many more machine instructions;
(4) the notation of the higher level language should be
more problem-oriented than that of an assembly language, i.e., it should be more "natural" for the class of
problems being solved.
MEANING OF, AND STATISTICS ON,
APPLICATION-ORIENTED LANGUAGES
Terminology
Many people refer to special-application-oriented
languages as "special purpose" languages. This is misleading since the term "special purpose" really applies
to a single or a limited set of objectives. For example,
one might design a language that was intended to be
very easy to use (e.g., BASIC). On the other hand,
a major objective of the language might be easy and
rapid compilation (e.g., MAD). Alternatively, the objective might be a language in which it was easy to
generate efficient object code. Finally, as a particular
type of "special purpose," a language might be designed
to be useful for a specific application area.
Another term which is frequently used for the class
of languages discussed in this paper is "problemoriented." This is bad terminology, because all programming languages are problem-oriented. The main
distinctions pertain to the width or narrowness of the
problem area involved.
In the most fundamental sense, all programming
languages are "application-oriented." Every programming language which has been developed has been
aimed at a particular class of applications, which may
be narrow or broad. In the latter case,· the so-called
301
general purpose languages such as PL/I and ALGOL
68 attempt to be suitable for every application area and
they clearly don't succeed. This is not surprising when
one considers the enormous variety of uses to which
computers are put today, including calculation of space
trajectories, medical diagnosis, inventory control, numerical machine· tool control, graphic displays, and
movie animation. With the sole exception of medical
diagnosis, all of these applications have fairly general
(e~g., FORTRAN, COBOL) or very specialized (e.g.,
APT) languages used for their solutions. Hence, it is
inaccurate to refer to· some programming languages as
"application-oriented" while others are not. All programming languages are application-oriented, and the
only question that can meaningfully be asked is
"what type of application?". The answer can be narrow
or broad, and also can be classified by either technique
or application area, or both. For example, matrix
manipulation is both a technique and a class of applications, depending on your viewpoint. (This is of
course analogous to the concept that one person's program is somebody else's subroutine.)
In contrast with the technique and/or application of
mathematics, one might consider the application area
of technical computation with engineering as a major
subcategory; underneath the latter can be logical design and civil engineering (which in turn has subdivisions of structural engineering and coordinate geometry). In parallel with engineering we might have
astronomy. The area of computations in medicine could
be considered a subset of technical computations, or
might be considered a major category. It is really up
to the individual as to how fine a line he wants to draw.
Table I represents one possible schematic, and the
reader can easily develop similar tables to reflect his
own approach to problem areas. It is important to note
TABLE I-A Schematic for Types of Application Areas
Mathematics
Numeric
Matrices
Partial Differential Equations
Non-numeric
Matrices
Partial Differential Equations
Polynomials
Technical
Engineering
Logical Design
Civil Engineering
Structural Engineering
Coordinate Geometry
Astronomy
Medical
302
Spring Joint Computer Conference, 1972
that the distance of the observer from an application
area affects his view of it. Thus, civil engineering is one
application area from the viewpoint of a computer
scientist, but has many levels and subdivisions for a
person involved in building bridges.
Another method of classifying the application areas
is through the realization that some types of applications involve a particular specialized discipline or
specific technology, whereas others are specialized but
can be used across many areas. Illustrations of the
former include civil engineering, movie animation,
social science, etc., whereas the latter include simulation, graphics, etc. A more complete list is given in
Table II.
This paper specifically deals with, and includes in the
category of "languages for specialized application areas,"
TABLE II-Categories and Statistics on Languages for
Special Application Areas
Number of Languages
Pre 1966
1966-1971
1-2 3-5
over 5
1-2 3-5
over 5
Specialized Application
Disciplines
automated equipment
X
checkout
civil engineering
X
computer assisted
instruction
logical design (including
simulation of digital
computers)
machine tool control
movie animation
real time/process
control
social science/
X
humanities
systems programming
Specific application areas and statistical trends
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Narrow Applications
A cross M ultiDiscipll:nes
computer aided design X
graphic and on-line
display
query (excluding data
base management
systems)
simulation-continuous
(including block
diagrams and
analogue computers)
simulation-discrete
all programming languages except those specifically intended for mathematical computations (both numeric
and non-numeric, i.e., formula manipulation), business
data processing, string and list processing, or any combinations of these. (The use of a language outside its
intended application area does not cause it to be considered specialized, nor change the definition of its
primary intended use.) This list of excluded categories
is certainly debatable on the grounds of what it does
and doeS' not contain. The applications cited seem so
fundamental to the use of computers that none should
be considered as being specialized. Of the categories of
specialization (discussed later) only simulation seems
to have a reasonable potential for consideration as
fundamental, and at this point in time such a conclusion does not seem justified to the author. Note also
that systems programming is considered one of the
specialized application areas; this view refutes the concept which has been expressed by some people that a
language can only be considered good if it can be used
to write its own compiler.
The terms "special-application-languages" and
"application-oriented languages" will be used in this
paper as synonyms for the phrase "languages for
specialized application areas."
X
X
X
X
X
X
X
X
X
In Table II is a list of special application areas which
have had programming languages developed for them.
Some statistics are also given; the latter are presented
in categories rather than specific numbers in order to
show trends. It is virtually impossible to obtain a completely accurate count because of the existence of dialects, multigeneration languages (e.g., SIMSCRIPT I,
1.5, II, 11.5, and II Plus), and the differences between
dates of definition, implementation, and actual usage.
The distinction between pre-1966 and more recent
years largely reflects existence on second generation
computers. However, not all languages on second generation computers were implemented on third generation machines. The most complete lists of languages
available-although they are by no means perfect or
complete-are in References 15, 16, 17, 18. Discussions
of almost all those languages developed by 1967 are in
Reference 14, Chapter IX.
General statistical trends
As indicated just above, it is virtually impossible to
obtain accurate statistics. This is due not only to the
language generation problem but also to the fallibility
Languages for Specialized Application Areas
of any single human attempting to track this field. Until
we get some scientific methodology for defining language generations, dialects, etc., and until a reliable reporting system is developed, the most we can hope for
is some statistical trends. (See Reference 19, for a first
attempt at dealing with the dialect problem.)
The trends that can be observed are all based on
References 15, 16, 17, 18. While the figures cited have
inaccuracies and in particular are based on date of inclusion of a language in the roster rather than its actual
development, it seems fair to state that all the errors
are probably consistent and hence relatively unbiased.
The first year in which any serious attempt was
made to list "all" the special-application-oriented languages was 1968. In each of the four years 1968-1971
the number of special application languages was approximately 50 percent of the total number of languages
listed. The latter were 82, 125, 139, and 164 in the four
cited years. In 1969, 1970 and 1971 the total number of
new languages added from the previous year was between 35 and 40 each year. In 1970 and 1971· the percentage of new special-application-languages was between 40 and 60 percent of all the new ones. * In both
1970 and 1971 the number of special-applicationlanguages dropped from the roster (meaning clear nonuse of the language) was about 50 percent of the total
number of languages dropped. (The latter numbers
are small, ranging between 5 and 10 percent of the
total. )
These numbers are presented because of the trends
they indicate, and certainly should not be used as definitive representations of the actual situation. For that
reason these figures were deliberately not presented in a
table or graph because that would imply more accuracy
than is justified.
NEEDS TO BE MET IN DEVELOPING
THE LANGUAGES
There are several needs which must be met by a new
language or a modification of an existing one. The
major needs are functional capability, a style suitable
fer the application area, and efficiency.
Functional capability
The inclusion of specific functional capability is
single most important need to be met by
probabl~ the
* A similar figure for 1969 would be very misleading because the
1968 Roster did not contain any of the languages developed for
CAl and their inclusion in 1969 perverts the statistics.
303
the application-oriented languages. Most of the deficiencies in a particular language .actually reflect the
omission of functional capabilities which a certain class
of users need. For example, the FORTRAN user often
wishes to do character manipulation, the COBOL user
might wish to do floating point calculations, and the
PL/I user might wish to do simulation. In considering
functional capability, the three major issues are (a)
the specific features which must be included (i.e., commands and data types), (b) the distinction between
subroutines and a specific language facility, and (c) the
facilities provided by the system. Each of these is now
discussed in more detail.
Specific features
The specific features representing the functional
capability of any language are the operations (i.e.,
commands) to be performed, and the data types. The
kinds of operations to be provided depend completely
on the application area, and of course must be consistent with the data types. As a very simple example,
the existence of floating point numbers is extremely
important in any language to be used for scientific
computation, whereas they have little or no importance
for business data processing. Therefore, the existence
of a floating point or complex number data type is a
functional requirement of many scientific problems, and
naturally there must be executable statements which
can operate on these data types. A less elementary
example occurs in the civil engineering field where the
ability to calculate the point of intersection of the
tangents to two circles may be deemed important
enough to incorporate directly into the language.
Furthermore, a "point" with coordinates might be defined as a data type with operations provided to calculate areas. In the case of an application involving
simulation, some indication of time and time-dependencies in both the data types and commands is absolutely crucial. In the case of language developed for
animated movies, the user must be able to address and
manipulate pointers or markers on a screen. In the
general area of graphics, a "graphical" data type is
normally needed.
a
Subroutine versus language facility
Since all major languages have a subroutine capability of one kind or another, the question can legitimately be asked as to why the needs cannot simply be
met through adding subroutines rather than either
developing a new language or adding syntax and se-
304
Spring Joint Computer Conference, 1972
mantics to the existing language. It must be emphasized
very strongly that there is a fundamental difference between functional capability (which can be represented
either directly in the languages or via subroutines) and
specific language facilities.
The easiest way to show this· is by means of an example within the field of mathematics. (Since this was
ruled out earlier as not being specialized, its use here is
primarily to illustrate the concept of subroutines versus
specific language facilities.) Suppose a person wished
to do MATRIX addition in a language like FORTRAN.
One could add a subroutine to perform those calculations and then invoke this facility by writing
CALL MATADD (A, B, C)
This is fundamentally different in several ways from
writing something of the following kind:
DECLARE A, B, C MATRICES
C=A+B
In the first instance, the user (meaning both the writer
and reader of the program) has lost a certain mnemonic
advantage and furthermore has the difficulty of remembering the· types, sequence, and restrictions on the
parameters that he is using. In this particular example,
the main difficulty is to remember whether the stated
call would provide A as the sum of Band C, or C as the
sum of A and B; this is something which must be remembered or looked up in a manual. In the second example, what is happening is far clearer. In addition to
the lack of "problem-oriented notation" inherent in using the CALL or equivalent statement, there are implementation difficulties and inefficiencies relative to linkages. In many cases, there is a great deal of extra code
generated to invoke a subroutine, although the latter
may in fact be quite small and would be more efficient
placed in line. Unless the compiler is very sophisticated,
it is likely to generate the linkage coding rather than
placing the subroutine in line.
While subroutines dO,serve a very useful purpose in
making additional functional capability available to the
user, they should not be viewed as substitutes for additions to a language.
SysteIn provided facilities
Another aspect of functional capability is the built-in
facility of the language and its associated compiler to
do things which might need to be programmed in
another language. For example, in the languages for
computer assisted instruction, it is assumed that they
will be used in an interactive mode and hence the lan-
guage translators automatically provide for input and
output from a terminal without the programmer having
to specify much (if anything) about input/output.
Furthermore, certain types of control flow are assumed
by the system and handled automatically. In the case
of graphic languages, the language (and its processor)
automatically provide the necessary instructions to the
graphics equipment.
Style suitable for application area
In the development of languages for special application areas, the style plays a major role, primarily because the users are normally not professional programmers. Style in a programming language has many
facets, ranging from personal views on the importance
(or non-importance) of blanks and punctuation, to the
use (or non-use) of a GOTO command, to the selection
of a particular word for getting input data (e.g., READ
vs. GET). The major identifiable elements of style are
vocabulary, personal preferences, and requirements
affecting style.
Vocabulary
The second * most important need in an applicationoriented language is the vocabulary or professional
jargon that is involved. The whole raison d' etre of
many languages for specialized application areas is to
allow the user to write his specialized jargon in a natural
manner. Whereas he can certainly develop subroutines
to accomplish what he wants, the ability to use his own
terminology in a style natural to him is of paramount
importance. It is normal that a person outside a particular area will find the nomenclature confusing or not
understandable. All figures in this paper reflect this
issue, i.e., the programs as written are generally not
understandable to any reader outside the specific application area.
Personal preferences
It is unfortunate-but quite true-that in the development of one of these special-application-Ianguages,
the personal preferences of the developer have a significant effect, although they should of course be subordinated to the functional requirements and the vocabulary. For example, people who wish to have short
data names and short statements in a language because
* The first is the functional capability.
Languages for Specialized Application Areas
they like that style may be forced into a different mode
because the professional jargon of the field constantly
uses long words. (In some systems, e.g., COGO, both
short and long forms of key words are allowed to provide short cuts for experienced users.) The choice of a
fairly rigid format versus a free form, or the selection
of specific key words (e.g., READ versus GET) can
sometimes make the difference between successful
usage of the language versus constant unhappiness by
the users. In some instances, people have strong views
on punctuation and will change an existing language
to eliminate (or include) punctuation in lieu of some
other syntactic restriction. (It has been said facetiously
that by choosing the correct subset of PL/I one merely
has FORTRAN with semicolons.)
Background and past experience with specific equipment often have a strong personal influence. People
who have used punched cards extensively tend to favor
rigid formats with card columns used as syntactic delimiters. Those who have used on-line terminals generally tend to favor free form. Even in this latter case,
there. is considerable difference of opinion on the value
of limiting each statement to the length of a single line.
The use of very simplistic styles, as illustrated in
Figure 2, primarily consisting of a single key word at
the beginning of a line, followed by some parameters,
certainly forces one to reconsider the border line between programming languages and powerful macros.
Certainly such a style is generally not "problemoriented" which was described as one of the characteristics of a higher level language. However, such languages (e.g., COGO-see Figure 2) can be justified as
higher level languages because of the distance of these
operations from normal machine code. Thus, there is a
large amount of information built into the compiler or
the interpreter to perform specific functions which are
directly related to an application (rather than merely
enhancing normal machine code) .
It should be emphasized that there is little or no
way of determining which of two styles is better; in
virtually every case it is a matter of individual taste,
preference, previous usage, and jargon common to the
application area.
Requirements affecting style
It should not be thought that all matters of style are
arbitrary; some are influenced or forced by specific requirements of equipment-particularly the character
set. In other cases, the intended use may affect the
style of the language and environment will have a very
specific effect. If the language is to be used in an inter-
305
Po in t 7
(7, 7)
\
\
\
? \
.
\
12" \
Point 1
\
(l000., 2000.)
\
STORE
1
1000.
LOCATE/AZIMUTH 7 1 256.17
LOCATE/AZIMUTH 95 1 350.00
AREA
1 7
95
PAUSE
Point 95
(7, 7)
2000.
45 15 28
102 35 12
Explanation:
Small COGO program for figure shown. In the figure above, given
the coordinates of point 1, the length and azimuth (clockwise
angle from north) of lines 1-7 and 1-95, the COGO program shown
computes the coordinates of points 7 and 95 and the area of the
triangle. In the program, the second line reads: Locate point 7 by
going from point 1 a distance of 256.17 at an azimuth of 45 degrees
15 minutes 28 seconds.
Source: Fenves, S. J. "Problem-Oriented Languages for ManMachine Communication in Engineering," p. 48.
Reprinted by permission from Proceedings of the IBM
Scientific Computing Symposium on M an-Machine
Communications, Data Processing Division, 320-1941,
© 1966 by International Business Machines
Corporation.
Figure 2-COGO (civil engineering)
active mode, it is pointless to be highly concerned
about card columns. On the other hand, if the primary
use of the language involves relatively simple statements and a large number of numeric parameters or
data, then it may be most effective to orient the style
of the language toward card columns.
In some instances, the style can be justified on fairly
concrete grounds. For example, in situations where
time is critical (e.g., command and control) there may
be much more need for brief fixed formats with little
flexibility. In other areas where documentation plays
an important role, the desire may be for lengthy free
form syntax which clearly conveys the meaning of the
306
Spring Joint Computer Conference, 1972
program to a large number of persons long after the
program is written.
Efficiency
It is obvious that one of the reasons for developing
these application-oriented languages is efficiency. This
involves the efficiency which comes both from ease of
writing the programs and from suitable processors.
One major way in which an attempt is made to increase efficiency is to delete unwanted parts of a maj or
language while (perhaps) adding on the functional
capability (in the form of new language elements).
While the person or group which has a large language
available to them is under no obligation to use all of its
facilities, it is perfectly clear that they are paying for
the implementation of these unwanted features. The
common and obvious practical solution to this problem
is merely to have a compiler which implements a subset of a language, and this is frequently done. However,
to the extent that the individual or group wants to
clearly define a certain subset of syntax and semantics
and give it a name, he has in effect defined a new language. It is not true that all languages can have subsets
properly defined, if a program written in the subset is
also to run on a compiler for the full language.
The ways in which suitable processors can be obtained are discussed in the next section.
DESIGN PARAMETERS OF SPECIAL
APPLICATION LANGUAGES
The design parameters of the languages for special
application areas essentially reflect the needs which
were discussed in the previous section. Thus, the functional capability, a style suitable for the application
area, and efficiency are clearly design parameters. However, there are two additional issues which were not
discussed in the previous section but which are very
significant in the development of these languages,
namely the methods actually used to design and implement the languages. It is well-known that those issues
are important in the design of any language, but they
are perhaps more significant in the languages within
the scope of this paper because the intended users are
not professional programmers and hence are less likely
to be tolerant of unnecessary idiosyncrasies. In more
general languages, some of the idiosyncrasies are (unfortunately) forced into existence by the methodology
used for language design and/ or implementation.
Finally, it is possible to summarize the potential language requirements.
Methods of defining language
There are three basic methods for defining a language.
The first is the most obvious-namely, a straightforward definition. In this instance, the individual or group
merely sits down and writes out a definition of the
language. Depending upon their sophistication and the
complexity of the language, they may use something
like Backus Normal Form, or alternatively may simply
use ordinary English and examples. A special case of
this method involves making specific changes to an
existing language, which may involve addition, deletion, changes, or all of these.
The second method of defining a language is through
an extensible language system. This is an area which
has become increasingly important over the past few
years, although there is not much evidence of practical
systems or significant usage as yet (see Reference 1).
In this situation, the developer of the language for a
special application area is limited in two ways. First, he
is limited by the inherent style and capability of the
base language, and second, he is constrained by the
mechanism given to him to produce the extensions. If
the extension facilities do not allow new data types to
be added, then he is limited to the syntax and functional operations of new commands. For example, any
macro system (e.g., PL/I) tends to allow new commands and/or new syntax to be developed but does
not provide for new data types. Alternatively, other
extensible systems, e.g., IMps allow for both new
commands and new data types, but do not allow for
major changes in language style or format.
The third method of defining the language is via some
system. In this case, which seems to' be the most important and the most promising, the user or application programmer stat_es his wishes to a person who can
be defined as a "language designer" who then interacts
with a system which produces relatively easily a language definition which meets the needs of the original
user or programmer. While many people have talked
about this for years, relatively little has actually been
accomplished-see a later section. In the long run, it is
clear to me that we must allow the user ample facilities
/ to easily define and implement his own language subject to whatever constraints and quirks he may have.
The key word here is "easily" and that is the major
difficulty in achieving the general goal.
Methods of implementation
Just as there are several different ways of defining a
language, so there are different broad techniques for
Languages for Specialized Application Areas
implementing them, and to some extent (but not entirely) they match the methods of defining the language. The first and most obvious method of implementation is a specific compiler or interpreter. This
would tend to be used most often in a case where a
language had been designed from scratch. Second,
paralleling exactly the use of extensible languages is the
extensible language compiler or equivalent facility.
This method might conceivably be used with a language
designed in another way, but it is highly unlikely to be
applicable. A third possibility is a very powerful macro
assembler which then allows the user quite a bit of
flexibility in terms of jargon, lists of parameters, etc.,
but gives him virtually no flexibility in style and overall
format. Finally, roughly corresponding to the userdefined language via a system, is a system which generates a compiler or interpreter. This method of imp le-
307
mentation can be used even with the first case where
the individual has designed and defined the language
from scratch. The compiler generators that have been
the vogue for many years come close to satisfying this
requirement in theory, although none seem to do it in
practice. (See a later section.)
Potential language requirements
A brief summary of requirements (or considerations)
for potential desired language features is shown in
Table III. Obviously, anyone language will only use
some of these. However, it is possible to find at least
one specialized language which requires or uses each of
these approaches or features.
SOME SPECIFIC APPLICATION AREAS
WITH EXAMPLES
TABLE III-Considerations in Language Design
Syntax
1. Form
Free
Fixed tabular, as in report writers or decision tables
Rigid with required parameters, i.e., essentially macro style
2. Punctuation
Critical with many symbols or not very significant
Blank character is critical delimiter or not significant
Single or multicharacter
3. Identifiers and Key Words
Single or few characters vs. lengthy
Abbreviations optional vs. not allowed
Specialized vocabulary
4. Full power of a language like PL/I (for systems programming)
5. Declarations-see under Data
Almost all special application areas tend to look
small and homogeneous when viewed from outside, but
large and filled with differing problems and issues when
qu Who discovered America?
aa Ericson
ab Leif Ericson
ty Your answer would be accepted by some.
ca Columbus
ty Yes
wa Ponce de Leon
ty No. He looked for the "Fountain of Youth."
Try again.
un bl
Data
1. Types
Specialized to application, e.g., length
Many vs. few
Implicit vs. specifically declared
Determined by position in statement
2. Declarations
Grouped by attribute vs. grouped by data item
Implicit from other syntactic rules
Default conditions
Semantics
1. Specialized computational routines
2. Non-standard use of common characters (e.g., plus sign)
Program/Control Structure
1. Generally quite simple with no block structure nor compound
statements
2. Very powerful (for systems programming)
Explanation:
Example uses the aa and ab operation codes. If the student
enters a response of "Ericson," or "Leif Ericson," the message
"Your answer would be accepted by some," is typed to the
student. After the aa or ab match, the system continues to scan
statements until it finds the un statement. It then types the
contents of buffer 1. If the student responds with an answer
which does not match an aa, ab, ca, or wa statement, only the un
argument (the contents of buffer 1) is typed to the student. The
contents of buffer 1 might be, "Please try again." Using a buffer
in this way saves the author from repeatedly entering the same
text for many un statements in the course.
Source: Reprinted by permission from p. 17, Coursewriter III for
System/360, Version 2, Application Description Manual,
Data Processing Division, H20-0587, © 1969 by
International Business Machines Corporation.
Figure 3-COURSEWRITER III
(computer assisted instruction)
308
Spring Joint Computer Conference, 1972
viewed by those familiar with the field. A very good
illustration of this can be seen merely by glancing at the
papers. on numerical control programming languages. lO
Even though one language-namely APT-predominates, there are still enough technical issues surrounding its utility and implementation to cause the existence
of numerous other languages. In particular, 32 others
are listed.H
In the field of computer-assisted instruction, there
are over 30* languages utilizing different syntactic and
conceptual approaches. Just glancing at Figures 3 and
4, for Coursewriter and FOIL, respectively, shows
the wide variety of style, ranging from two-letter
mnemonics to a PL/I-like language. A comparison of
CAl languages can be found in Reference 23.
The situation in graphics is similar, but with another
dimension of concept involved. In the computerassisted instruction application area it can reasonably
be argued that the application is unique and that there
is little relevance to existing languages of somewhat
wider purpose, e.g., FORTRAN, COBOL. (However,
even in the CAl situation, the case can be made for
the desirability of control statements, conditionals, and
numeric calculations expressable by formulas as in
FORTRAN.) In the field of graphic languages there is
certainly a special facility that can be used by many
TY WOULD YOU LIKE TO CONTINUE THE
EXERCISE?
ACCEPT
IF 'NO', GO TO FINISH
IF 'YES, OK'
NUM=NUM+1
GO TO NEXT
GO BACK PLEASE ANSWER YES OR NO
Explanation:
The TY causes the indicated typeout to be made. If the student
responds with a NO there is a branch to a statement labeled
FINISH. If either YES or OK are typed in the variable NUM
has 1 added to it and control is transferred to the statement
labeled NEXT. Any answer not including YES, NO, or OK
causes the typeout from the system of PLEASE ANSWER YES
OR NO and a return of control to the ACCEPT statement.
Source: Hesselbart, J. C. "FOIL- A File-Oriented Interpretive
Language," Proceedings of the 23rd National Conference
of the Association for Computing Machinery, 1968, p. 94.
© 1968 Association for Computing Machinery, Inc.
Reprinted by permission.
Figure 4-FOIL (computer assisted instruction)
* Not all of these are listed in Reference 18.
applications (including, for example, computer-assisted
instruction). The technical approaches and issues in
graphics are as diverse as in other applications. In this
case more of an argument can be made for providing
the facilities as extensions to existing languages, e.g.,
GRAF,5 which is an extension of FORTRAN. However, most developers went to the other extreme with
entire new languages, for example General Purpose
Graphic Language. 9 (See Figures 5 and 6, respectively.)
Some languages take a middle ground by retaining
some of the style of more popular languages, such as
ALGOL or FORTRAN, but by no means accept compatibility with them as a constraint. (See for example
Euler-G12.) In each case the developer of the language
was reflecting his view of how graphic information
should be stored internally, and the most effective way
in which it could be displayed and manipulated on a
screen. In this application area, the physical environment plays a major role in the development of the
language; thus the existence of lightpens, keyboards,
push-buttons, etc., must be supported-if they are to be
used by the graphic language.
SYSTEMS FOR DEVELOPING LANGUAGES
FOR SPECIAL APPLICATION AREAS
It is unfortunate, but appears to be a fact, that
there are no currently available systems which have
actually been used in a practical way for the development of a significant number of languages (and their
processors) for special application areas. It is not even
DISPLAY A, B, PDQ, POLE (11), K72A (7, 2, 4)
PDQ=A+POINT (0, XY2)+B
K72A(2, 1,3) = PLACE (0,1) +PRINT 13,
(YY (I), 1= 1, 8) + PLACE (100, 200)
Explanation:
The names in the DISPLAY statement are display variables.
PDQ is assigned the value which is obtained by first generating
the graphic orders of A followed by the orders generated by the
built-in function POINT, followed by the orders generated by
B. Similarly, the value of K72A(2, 1, 3) is obtained by taking each
of the graphic orders indicated in turn. The built-in display
function POINT generates orders for plotting the point with
indicated coordinates; the built-in function PLACE changes the
beam position without plotting, and PRINT plots the indicated
string of characters.
Source: Based on examples in "GRAF: Graphic Additions to
FORTRAN," A. Hurwitz and J. P. Citron, Proceedings
of the Spring Joint Computer Conference, 1967.
Figure 5-GRAF (addition to FORTRAN to do graphics)
Languages for Specialized Application Areas
309
(A, B+D)
BEGIN WINDOW (A, B, C, D)
RECT (A, B, C, D)
AA=A+C/2
BB=B+D/2
LINE AA, B; AA, B+D
LINE A, BB; A+C, BB
END
(A, BB) ~
(A, B)
(M, B)
(A+C, B)
Explanation:
A subroutine WINDOW is defined where A and B are the coordinates of one corner of a rectangle and
C and D represent the horizontal and vertical dimensions. The subroutine to draw a rectangle is called
and executed. The drawings of these windows are to have horizontal and vertical lines midway in the
window so AA and BB compute the coordinates of the midpoints. The LINE commands cause the
"midway" lines to be drawn.
Source: Kulsrud, H. E. "A General Purpose Graphic Language," Communications of the ACM, Vol. 11,
No.4, April 1968, p. 253. © 1968 Association for Computing Machinery, Inc. Reprinted by
permission.
Figure 6-General purpose graphic language
clear that any of the systems now in prototype stage
will ever be satisfactory for that purpose. Virtually all
of the systems known to the author have one or more
of the following characteristics: (1) they require a
compiler expert for their use; (2) they have been used
to produce some minor variations on "normal" languages such as FORTRAN, ALGOL, etc.; (3) they are
not really intended to be used to develop the types of
languages discussed in this paper; (4) they give lip
service-although little else-to the concept of allowing
the average user to be able to define his own language
and easily get a processor for it.
In theory, any compiler-compiler, meta-compiler or
similarly designated system could be used for this purpose. However, there is a different emphasis in most of
those developed to date. They have been designed primarily to provide an easy means of implementing known
and widely used languages (e.g., FORTRAN, COBOL,
ALGOL, PL/I) rather than as a tool for the development of new languages with uncommon requirements,
and their processors. Thus the major considerations
have pertained to efficiency of the resulting compiler,
with an easy way to make minor changes in the syntax.
A discussion of the past and potential use of such systems or translator writing systems in general is beyond
the scope of this paper. A good survey is given in
Reference 3.
Although no systems seem to have been widely, or
even significantly, used for developing the types of
languages within this paper, several have had limited
use and/or have such intent for the future. A brief
description of these will now be given.
(a) ICES
The Integrated Civil Engineering System (ICES)
provides an overall system within which many language
processors suitable for civil engineering can reside and
use common facilities. I3 There is also the capability of
allowing the user to define new languuges, or add facilities to one of the existing languages. This is done by
means of the Command Definition Language (CDL).
Although CDL has not been used very much in practice,
at least one language, namely STRUDL,22 was developed using it. (A brief but relatively accessible
summary of ICES, including CDL, is in Reference
14.)
(b) REL
The Rapidly Extensible Language (REL) System
was (and is) intended for use by researchers in the
fields of complex social and environmental processes. 20
310
Spring Joint Computer Conference, 1972
It has a powerful English grammar, thus permitting
individuals to communicate with the computer in a
fairly "natural" language. In 1970 an experimental
system was in operation on the IBM System 360/50
and was used to develop an animated film language and
also by some social scientists.
(c) PLAN
The Problem Language ANalyzer (PLAN) has many
facets to it, but the only one of interest in this context
is its facmty to allow the user to define simple new
languages in an easy manner.6 A version providing
graphics support allows the user to develop his language
at an IBM 2250 and also provides him with many
built-in graphics facilities. 7
(d) UAL
The User Adaptive Language (UAL) is another attempt to provide a user with the ability to dynamically
create and modify a language in an interactive mode. 4
This system provides the user with fairly sophisticated
programming concepts (e.g., lists), but does not require
him to use them.
(e) SDF
The Syntax Definition Facility (SDF) allows the
user to define his language by means of illustrative
sentences. 2 The sYEtem indicates whether the input is
ambiguous or contradictory to earlier information. By
late 1971, it had been used primarily to implement the
syntax of fairly standard language subunits, e.g.,
arithmetic and Boolean expressions.
(f) Extensible Languages
All extensible languages should-in theory-be usable
for creating specialized languages. By late 1971, none
seem to have been used in this way. See Reference 1.
BRIEF COMMENTS ON THE FUTURE
It seems unfortunate but true that the proliferation
of higher level languages is likely to continue at about
the same rate. The reason for this is that some of the
causes and motivations behind the development of
these languages rest in quirks of human nature rather
than technological progress or lack thereof. Thus, as
long as people find it fun to develop languages, as long
as they want something which is specifically tailored
exactly to their needs, and as long as they are going to
find picayune faults with the existing languages, there
is very little that technical progress can do to reduce
the number of languages. On the other hand, there are
some areas in which improved technology will have an
enormous effect. For example, the existence of good
extensible language systems, or good systems which can
easily generate a language and its translator based on
appropriate input from a language designer, will have
a considerable effect. We might even envision specialized language generators, i.e., a system designed to
allow the easy creation and implementation of languages in a single application area, e.g., CAl, graphics.
ICES13 is a simple attempt in this direction for civil
engineering.
In the opinion of this author, the ease and efficiency
of using a language particularly suited to a specific
application area is a desirable result which outweighs
the disadvantages of the proliferation. A thorough discussion on the pressures and resources involved in the
future development of these specialized languages is
given in Reference 20.
SUMMARY
This paper has defined and discussed the class of languages which are designed for use in specialized application areas. These languages include about half of all
higher level languages used in the United States at the
time of this writing. A discussion of terminology showed
why some of the commonly used terms for this class of
languages are technically inappropriate.
The major needs to be met in developing these languages were shown to be functional capability, deletion
of parts of an existing language, and a suitable style.
Two specific application areas, namely CAl and
graphics, were used to illustrate the existence of significantly different language styles within the same application area. Although there are a number of systems
which purport to allow the user to easily define and
implement his own language, and they are mentioned,
none have actually been significantly used. A few brief
comments on the future indicate that the proliferation
serves a useful purpose and will continue.
REFERENCES
1 ACM SIGPLAN
Proceedings of ACM SIGPLAN Conference on Extensible
Languages
SIGPLAN Notices Vol 6 No 12 December 1971
2 R S EANES
An interactive syntax definition facility
MIT Electronic Systems Laboratory Report ESL-R-397
September 1969
3 J FELDMAN D GRIES
Translator writing systems
Communications of the ACM Vol 11 No 2 February 1968
Languages for Specialized Application Areas
4 A HORMANN A LEAL D CRANDELL
User adaptive language (UAL): A step toward man-machine
synergism
System Development Corporation Technical Memorandum
TM 4539 June 1971
5 A HURWITZ J P CITRON J B YEATON
GRAF: Graphic additions to FORTRAN
Proceedings of the Fall Joint Computer Conference Vol 30
1967
6 Problem language analyzer (PLAN) program description
manual
IBM Corporation Form GH20-0594
7 PLAN graphics support for the IBM 2250 (application
description manual)
IBM Corporation Form H20-0535
8 E T IRONS
Experience with an extensible language
Communications of the ACM Vol 13 No 1 January 1970
9 H E KULSRUD
A general purpose graphic language
Communications of the ACM VolU No 4 April 1968
10 W H P LESLIE Ed
Numerical control programming languages
North-Holland Publishing Company 1970
11 W E MANGOLD
Status of NC language standardization in I.S.O. (International
Standards Organization)
Numerical Control Programming Languages W H P Leslie
Ed North-Holland Publishing Company 1970
12 W M NEWMAN
Display procedures
Communications of the ACM Vol 14 No 10 October 1971
13 D ROOS Ed
ICES system: General description
MIT Dept of Civil Engineering R67-49 September 1967
311
14 J E SAMMET
Programming languages: History and fundamentals
Prentice-Hall Inc 1969
15 J E SAMMET
Roster of programming languages, 1968
Computers and Automation Vol 17 No 6 June 1968
16 J E SAMMET
Roster of programming languages, 1969
Computers and Automation Vol18 No 7 June 1969
17 J E SAMMET
Roster of programming languages, 1970
Computers and Automation Vol 19 No 6B November 1970
18 J E SAMMET
Roster of programming languages, 1971
Computers and Automation Vol 20 No 6B June 1971
19 J E SAMMET
Problems in, and a pragmatic approach to, programming
language measurement
Proceedings of the Fall Joint Computer Conference Vol 39
1971
20 F B THOMPSON et al
REL: A rapidly extensible language system
Proceedings of the 24th ACM National Conference 1969
21 F B THOMPSON B H DOSTERT
The future of specialized languages
Proceedings of the Spring Joint Computer Conference
Vol 40 1972
22 R A WALTER
A system for the generation of problem-oriented languages
Proceedings of 5th National Conference Computer Society
of Canada May-June 1966
23 K L ZINN
A comparative study of languages for programming interactive
use of computers in instruction
University of Michigan Center for Research on Learning
and Teaching February 1969
The future of specialized languages
by F. B. THOMPSON and B. H. DOSTERT
California Institute of Technology
Pasadena, California
INTRODUCTION
areas. The past and current situation has been reviewed
by Jean Sammet in An Overview of Programming
Languages for Specialized Application Areas. 19 Our final
task, therefore, is to identify the major trends these
developments are likely to take in the future.
The prediction of the future, like the review of the
past, has as its sole usefulness, the organization and
purposeful direction of the present. Thus, in situations
where there is rapid change, as there certainly is in the
field of computing, prediction-though more difficultis all the more necessary. Suppose that you, as a computer specialist, are considering whether to design and
implement a language for your own special application
area or to consolidate your programming within the
framework of a single, general language. You will certainly want your decision to be responsive to, though
perhaps not dictated by, your perception of the directions computers and computing will be taking.
Our own perception concerning programming language development rests on two considerations. The
first consideration is to understand the nature of the
pressures that will bring about change. New languages
for specialized application areas don't just happen;
they arise because of a felt need, a dissatisfaction with
trying to write programs for a specialized domain using
programming languages not specifically tailored to
that domain. Our first task, then, is to understand the
essential nature of this need.
The second consideration on which our perception of
future developments rests is to assess the technological
and economic restraints and resources for change. Big
computers, batch processing, and further professionalization of programmers will stimulate certain trends in
programming language design; mini-computers, interactive processing, and widespread knowledge of programming will stimulate different trends. Thus, our
second task will be an assessment of the major developments i~ hardware and software, and of the economic
environrv-ent within which the pressures for change will
be resolved.
These considerations should then put us into a position where we can bring into some focus what to expect
in language development for specialized application
SOURCES OF PRESSURE FOR LANGUAGE
DEVELOPMENT
In talking about languages for computing, we should
first like to consider certain aspects of the nature of
language. To do this it will be useful to develop an
analogy between a language, on the one hand, and the
design engineer's laboratory, on the other. Imagine
yourself to be an electrical engineer designing a new
computer central processing unit. As your design progresses, you and your team actually construct a model
or "breadboard" out of flip-flops, amplifiers, "and"
gates and other components. You wire these together
often using clips rather than solder, because as you try
out your design, you may wish to modify it as your
breadboard model reveals unexpected relationships
and possibilities for improvement. This model has a
second important function: it expresses in a most
articulate way the sum total of ideas contributed by
the various members of the design team and is thus a
vehicle for communication between them.
The design engineer's laboratory provides a great
variety of basic components and the means of hooking
them together into meaningful arrays. As the design
proceeds, selection is made of certain components and
they are built into combinations that express the functions that the designer wishes to execute. The same is
true of a language. A language is based upon a great
variety of basic concepts and its syntax is the means of
hooking them together into meaningful arrays. As a
programmer proceeds, he selects certain components,
building them into combinations that express the functions that he wishes to execute. This then is the analogy
313
314
Spring Joint Computer Conference, 1972
between design laboratory and programming language
we now wish to exploit.
Suppose you were called upon, as a computer specialist, to develop the configuration of a new computer for
your installation. You would have to choose the main
CPU, the size of high speed memory, what peripherals
you would want, etc. Suppose you were told that the
components you had at your disposal were diodes, resistors, capacitors and the like and that you had to
build your computer installation from this point up.
You would surely go about your job far differently
than if you had been provided as building blocks the
major pieces of computer equipment available from
computer manufacturers. Consider these two situations
carefully. If you had diodes and resistors you would
have to be a different kind of engineer than if you had
disk drives and printers to work with; your design
would take considerably longer, and your expectation,
design considerations and final output would be distinctly different. Our activities, the direction of our
thinking, our efficiency, and our results are all greatly
influenced by the basic components with which we
must work and the means at our disposal for building
them into more meaningful structures.
These same observations apply with equal force to
the languages we use in dealing with our various problem areas. Language is the principal tool of our conceptual processes. And different styles of thought reflect
and are reflected in the languages we use. Notice the
correlation between artificial intelligence and LISP;
engineering mathematics and FORTRAN or PLjI;
operating systems programming and assembly language.
This notion that language conditions the modes of
thought is not new. Benjamin Whorf, the MIT chemistturned-linguist, expresses the matter in the following/
words:
"We dissect nature along lines laid down by our
native languages. The categories and types that
we isolate from the world of phenomena we do not
find there because they stare every observer in
the face; on the contrary, the world is presented
in a kaleidoscopic flux of impressions which has
to be organized by our minds-and this means
largely by the linguistic systems in our minds." 1
Whorf was referring, of course, to natural languages.
But surely there is every reason to suspect that the
programming languages we use will also have an effect
on the kinds of problems and the character of the programs to which we apply the computer.
To illustrate this interdependence, consider the relation between languages and the kinds of management
information systems that are currently in vogue. The
original development of concepts for dealing with busi-
ness data came at a time when punch cards and magnetic tape were the only large size repository for machine readable data. Thus the whole nomenclature of
sequential files, fields, records, file update, report generation, etc., became an integral part of the language of
data processing and the conceptual environment for
the development of COBOL. Now we find that the
inertia resulting from these common language concepts
inhibits the acceptance of new systems based upon
random access to data and time shared environments.
A whole generation of programmers, information systems designers, and middle management people have
come to think of systems for formatted file management
and report generation as coextensive with management
information systems, even though such systems are a
travesty on what management wants and needs.
If Whorf's hypothesis is true, it can be turned around
and applied in reverse. We, ourselves, build the artificial languages for programming computers. As language builders, we will have significant effects on those
who use them. Thus, when we apply this Whorfian
notion to artificial languages we ourselves can build, a
new perspective opens up. The computer is a uniquely
powerful instrument for conceptual design and structuring. The "special application" languages we provide
are the major interface between the "designer" and this
powerful design laboratory. The conceptual elements
and syntactic tools made available to him cannot but
influence the effectiveness, even the direction, his work
will take.
Who is this "designer" in the case of the computer?
He is the industrial manager who is seeking to direct
the intricate interactions of product lines, production
capabilities, markets and finance. He is the anthropologist searching for those causal laws of human behavior that lurk within his voluminous data on family
relationships, vocational histories and patterns of
ownership. He is the test engineer whose task is to
chart the strengths and weaknesses of an aircraft wing
from the thousands of data points of a destructive test
procedure. He is the government agency head whose
response to public need is dependent on his sensitivity
to changing conditions as reflected in census statistics
and spot surveys. Can we indeed say that all of these
are well served by FORTRAN or PLjI? Is it not obvious that the basic conceptual elements of each of these
diverse areas of computer application are themselves
equally diverse, each with their own logical interrelationships and implicit assumptions? This logic and
these assumptions can be built once and for all into the
software support of a special application language.
They can exist at that tacit level which is natural for
the given application area and free the creative mind of
the manager, researcher or engineer to build his pro-
Future of Specialized Languages
grams on a conceptual platform appropriate and natural
for his concerns.
We would like to illustrate this point by a reference
to experience in the area of theorem proving on the
computer. The resolution strategies of Robinson2 and
their refinement by a number of researchers has progressed to the point where interesting applications can
be made to highly restricted areas such as the control
of robots that move blocks. 3 ,15 However, application of
theorem proving to problems of everyday business appears to be a long way away. One of the reasons for
this is the necessity, if theorem proving is to give
realistic results, to describe in specific axioms the very
large number of tacit assumptions that are implicitly
understood in these areas. Using explicit statements of
these assumptions turns out to be very much more
expensive in processing time than building them implicitly into heuristics and procedures. Think of the
task of stating all of the tacit assumptions that underly
just the personnel files of a modern business. But these
same assumptions, known implicitly to the applications programmer, are built into the procedures for
processing that data. To be sure, these procedures are
specific to the application area. Indeed it is just such
idiosyncratic procedures that become embodied as the
interpretive routines of a language which is "natural"
to such a specialized area. An example is the inclusion
of efficient differential equation solving algorithms in
applied mathematics systems such as NAPSS,4 algorithms that are automatically invoked in response to
natural syntax for the expression of such an equation.
From there on, they are no longer conscious considerations in further program writing, or processed internally
as axioms. They are now implicit, pressed down below
the level of the explicit considerations of the researcher
or manager who is using his own natural language.
There are two advantages here. One is the advantage
that accrues to the user inthe efficiency of his language
in dealing with matters th~t are directly of his concern.
The second is the advantage in the underlying processing algorithms that make use of the underlying implicit
assumptions of the domain. These enormous economic
advantages that the computer can thereby put at the fingertips of the specialist in his area are the true source of the
pressure for special application languages.
THE PRESENT RESOURCE ENVIRONMENT
When the computer was the scarce resource and
programming was the domain of a small community of
professionals-and indeed these conditions still residually apply-the powerful multipurpose language was
the natural tool for man/computer communication.
315
But this situation has been changing. We will examine
four significant developments in this regard.
Training of computer scientists
In the first place, our universities are turning out a
swelling stream of graduates in each of the various
professions who, over and above their professional
specialty, are also knowledgeable in computing. Our
major schools, and even many smaller institutions, include as an integral part of their professional curriculum
creditable courses in programming and computer systems. So far, most of these are limited to a few widely
used algebraic languages such as FORTRAN. However, more and more, specialized languages are being
taught: COBOL in business schools, LISP in psychology, SIMSCRIPT5 in industrial management,
various applied mathematics languages, such as
NAPSS,4 in areas of engineering, data analysis languages, such as SPSS,6 in the social sciences.
More important than the large number of students
taking these computing courses is that much smaller
minority in the various disciplines who take the more
advanced courses in the computer science curriculum.
They go into their professional areas fully competent
to bring to their disciplines the full power of the computer, and they are highly motivated to do just that.
It is these cross disciplinary people who will spawn the
new languages for their specialized application areas.
They will know the conceptual elements and implicit
logic essential to their substantive discipline and they
will also know how to embody these within efficient
programs and with linguistic sophistication reflecting
their training in computer science.
Let's review a case history in this regard. Dr. Harry
Markowitz received his doctor's degree in economics,
concentrating in areas which required a high degree of
knowledge of mathematics and computing. At the
RAND Corporation his work involved the development
of some economic models and their implementation on
the computer. He then became one of the leading
scientists in the RAND logistics project where he was
instrumental in the development and application of
simulation techniques. Subsequently Markowitz worked
within the executive office of the General Electric
Company, applying digital simulation to manufacturing and corporate problems. As he developed his simulation programs, his style and program organization
became clearer and more modularized. Also, the scope
of application of his work grew. Upon returning to the
RAND Corporation, it was natural for him to distill
from all of the various simulation programs he had
written and supervised, a general technique that was
316
Spring Joint Computer Conference, 1972
widely applicable. The result was one of the first and
still one of the best discrete simulation languages,
SIlV[SCRIPT. 5,20
The number of such able, interdisciplinary people
need not be large to make a significant impact, and
both the number and quality are growing.
Advances in hardware
The second development we would like to cite is in
the hardware area. The price of computers and peripheral equipment continues to come down. There will, of
course, always be the super-jobs which can utilize unlimited amounts of computer time. However, as computer costs drop, not only is the market widened, but
the experienced user can afford to shift more of his
task onto the computer and thus demand that the
computer do more for him. One form of this extra
service is to move the man/machine interface closer to
the man. One of the principal ways this can be accomplished is through the development of languages that
are more natural for the various application areas.
However, more significant than the general downward trend of cost per cycle time is the advent of the
mini-computer. Many project teams in industry, in the
university and other research institutions, in all walks
of life are now finding they can afford their own computer. Up to now the main market for mini-computers
has been in areas of process control or in connection
with special input devices and sensing equipment.
Those applications of computers which are not tied
directly to special sensors or control devices but which
require complex application programs have ~ended ~o
gravitate to central computing centers wIth thelr
large programming staffs and facilities for batch processing the many debugging runs that characterize
application software development. But the cost advantage of one's own mini-computer which avoids the
growing overhead costs of the big computer centers will
tend to reverse this. A preliminary look indicates that
very high level conversational languages can be implemented as dedicated mini-computer systems.
The development of effective programming languages
for specialized application areas can be instrumental
in the opening up of sizable markets for the mini-computers. As these versatile devices are brought to bear
on the sophisticated problems of competent professionals, with their small group of captive programmers,
.
we can again and again expect to see the evolutlOn
from special application programs, to module libraries,
to monitors, to special application languages. Once
such languages are developed, they stimulate similar
installations elsewhere. The heavy attendance at spe-
cialized area sessions at computer conferences attest to
the interest in learning about just such developments.
Because of the low cost and considerable capability of
the mini-computer, one can expect a general shift toward single user installations with a corresponding
increase in independence and innovation. The result
cannot help but have a considerable effect on the development of languages for specialized application
areas.
Developments in systems programming
The third general area of development is that of systems programming of which extensible programming
language research is a part. Here the rapid growth of
interest and importance of extensible programming
languages is a key development that will have a profound effect on the proliferation of specialized application languages. 21 To see this, one needs to be aware of
the nature of the problems that those working in the
area of extensible languages are attacking. The deep
problems of this domain have to do with the building
of optimizing compilers. It is no great trick for the experienced systems programmer to build a programming
language that provides for complex structures declarations, at least when he can implement these without
consideration of run time efficie~cy or storage management. The real problems are how to achieve optimization of both storage and computing efficiency.
Important inroads into this difficult and central area
are being made. We cite, for example, the work of
Cheatham and his group at Harvard. 7
As work progresses on extensible programming languages, one of its primary applications will surely be to
the definition of higher and higher level languages,
languages that include more and more implicit structurallogic, indeed languages that fit closely the specialized needs of significant application areas. The ability
to produce such languages efficiently and at the same
time to retain reasonable levels of optimization in the
actual encoding provides a powerful tool for specialized
language building. These specialized application languages need not be limited to domains outside comput~r
science. The language Planner, developed by the Artlficial Intelligence Group at MIT,8 is an excellent example of such a language to be used by computer
scientists themselves. In this case it is built on LISP
which is surely an example of an extensible language.
.
Science of linguistics
The fourth area of development is linguistics itself.
Weare indeed learning more and more about the struc-
Future of Specialized Languages
tures of languages and the underlying reasons why
language is such a powerful tool for conceptual structuring and communication. In particular, we are rapidly
gaining sufficient knowledge of the mechanisms of
natural language so that useful segments of natural
language can be understood and responded to by the
computer. Our own work on the REL system is a good
example of where this is being successfully accomplished. 9 ,10 In our system, we combine results from recent work in theoretical linguistics, namely modern
deep case grammar as developed by Fillmore,l1 with an
efficient application of the notions of syntax-directed
compiling. We believe we are only a very few years
away from an English driven system for conversational
data analysis with levels of efficiency that will markedly
improve upon present formal language batch systems.
Another system, that of Terry Winograd at MIT has
demonstrated the ability to control intelligently the
complex behavior of a robot in response to directions
given in a comprehensive subset of natural English.
The importance of these types of systems does not
lie in some magical quality of "English." There is a
rather general understanding by computational linguists working on actual systems that "natural" languages are full of idiosyncratic notions and expressions
that derive from the particular domain of discourse for
which they are adapted. What is important about this
natural language research is not the vocabulary, which
is surely not a universal of the native fluent speaker.
Rather the important insights from this research concern syntactic mechanisms and their interaction with
semantics. We have referred to the need in a language
not only for the right conceptual elements but for a
sufficiently powerful syntax that will allow the efficient
expression of interrelationships, as indeed is found in
natural language.
Natural language has a variety of powerful mechanisms for combining conceptual elements. Ambiguity
is an excellent example. Usually, when ambiguity in a
language is mentioned, one thinks of ambiguous sentences. However, consider how ambiguity is involved in
phrases, i.e., segments of sentences. In the phrase:
"the computer just moved into the laboratory"
the words "computer," "moved," and "laboratory" are
essentially all ambiguous when standing alone in that
they do not designate a unique piece of equipment,
action or location. The phrase "moved into the laboratory" also could be used in many contexts where it
would have quite different meanings. However, the
above phrase, when taken as a whole and in context is
not ambiguous at all. This ability to use general nouns
and verbs in such a way as to balance off their ambiguous referents to achieve in a parsimonious way a totally
317
unambiguous description is a powerful and Ubiquitous
tool of natural language, and one that is not difficult at
all to include in computer languages where the context
is delimited to a specialized application area. Thus,
work on natural language will indeed go far in providing
both understanding and specific techniques for building
specialized application languages with sufficient expressiveness to truly serve as effective design laboratories for conceptual structuring.
Our growing knowledge of computational linguistics
goes beyond knowledge of natural language to all areas
of language communication. In particular in the domain
of graphic languages and man/machine communications using graphic consoles, specialized man/machine
communication languages have been and surely will
increasingly be developed.
The rapid growth in linguistic knowledge will stimulate advances beyond the immediate effect of more
effective computer languages and language systems.
When a domain of human knowledge expands as linguistic knowledge is expanding today, it has far reaching consequences. The simulation of more effective
systems built upon these new linguistic insights, insights
that span from English syntax to psycholinguistics and
the mechanisms of language acquisition, cannot help
but be great. And greater understanding has always
led to higher degrees of specialization, specialization
that spells efficiency.
TRENDS IN PROGRAMMING LANGUAGES
The pressures and developments discussed in the
previous two sections give evidence that programming
languages for specialized application areas will continue
to proliferate. Moreover, they imply several more
specific trends. We shall identify and examine several
of these.
As knowledge of linguistics grows and the application of computers to specialized areas continues, we
realize that our old algebraic languages-FORTRAN,
ALGOL, PL/I-are really quite special purpose after
all. Certainly there is a need for good algebraic languages in physical science and engineering. However,
other language developments, for example LISP, have
already demonstrated the need for programming languages with quite different characteristics.
The attempt to include in PL/I a wide range of data
structure declaration capabilities has led to an interesting and perhaps significant development. PL/I has
not replaced FORTRAN for writing special application programs. It does appear that it is being used by
some systems programmers and by programmers who
318
Spring Joint Computer Conference, 1972
are writing languages for special application areas. The
problem with using PL/I for these systems programming purposes is that the resulting code is not sufficiently optimized. But it is exactly in this area of
optimizing compilers that progress of the greatest importance is being sought in extensible language research.
The confluence of these developments will lead to a
movement toward powerful system programming
languages of the extensible type. They will be based
upon our increasing understanding of the nature and
importance of data structure.
The advent of these systems programming languages
will mean that we will have greatly increased ability to
create languages that are carefully tailored to the conceptual and structural needs of specialized areas. The
mini-computer, the computer utility and the general
lowering of computing costs are creating a ready market
for such language developments.
Thus we foresee that systems programmers will be
turning away from their traditional preoccupation
with the architecture of, and compilers for, classical
algebraic programming languages. System programming
will turn more of its attention to the efficient implementation of a much wider class of language mechanisms and the building of these mechanisms into a far
more diverse family of application languages. These
developments will obviously be greatly influenced by
the spreading acceptance of conversational, interactive
computing.
A second major trend will be toward natural language
systems. We emphasize that by natural language we do
not mean the general English of some mythical native
fluent speaker. By natural we mean computer languages
which reflect the conceptual elements and the syntax
of the application areas in which they are employed.
These languages will be specialized languages, idiosyncratic, reflecting the physical as well as the conceptual environment in which they are to be employed.
For example, they will be influenced by the kinds of
terminals or displays to be used, whether they refer to
very large files of data, whether the application area
naturally employs advanced mathematics, the interactive reaction times required, etc.
There are two technical characteristics, however,
which many of these languages for specialized application areas will share. First they will tend more and
more in the years ahead to be problem definition languages rather than procedural languages. The distinctions between problem definition languages and procedural·languages is extensively discussed in the computer science literature without definitive conclusions. 12
Thus it will do no harm if we add to that discussion a
distinction that we feel to be an important one. A
procedural language talks essentially about the com-
puter; statements in such a language are instructions
to the computer about what it is to do. A problem
definition language talks essentially about the domain
of application; statements in such a language either
describe, ask for descriptions or direct the computer
concerning the subject matter of the application. It
appears to us that higher level languages and languages
for more highly specialized languages tend to be closer
to problem definition than to procedural languages. We
feel that there will be an increasing trend toward
problem definition languages.
The second technical characteristic that we foresee
is a trend toward natural language syntax. English
as a programming language has been discussed for
a good number of years and often fervently wished
for but thought of as something for the distant future. 13 , 24, 22 Through these same years solid progress
has been made-in theoretical understanding of
linguistic structure, in computational linguistic practice, and toward operational English language systems. 9,10,15,16,17 Pragmatic work on machine translation
has been showing practical results,18 contrary to some
expressed opinions. As a result, the next few years will
see operational systems for specialized areas where the
structure of the language is closely related to our native
English. Once this capability has been conclusively
demonstrated, prejudice against it will be forgotten
and we will make use of the powerful syntactic mechanisms of na,turallanguage in many application areas.
SUMMARY
Return for a final look at the Whorfian hypothesis,
that language shapes the thought and culture of those
who use it. As we develop powerful systems programming languages for application language development,
as we incorporate the power and expressibility of natural
language syntax into our application languages, as the
economic costs of hardware and language software
come down, and particularly as our rapidly expanding
knowledge of linguistics continues to grow, a new
dimension in artificial language development will come
into being. We will recognize that language design is a
powerful means of direction and control. The tasks of
professionals can and will be directed by the languages
they must use in communicating with their computers.
REFERENCES
1 B L WHORF
Language, thought and reality
MIT Press 1964 p 213
Future of Specialized Languages
2 J S ROBINSON
The present state of mechanical theorem proving
Proc of Fourth Systems Symposium 1968
3 C GREEN B RAPHAEL
The use of theorem proving techniques in question answering
systems
Proc 23rd Nat Conf of A C M 1968
4 L SYMES R ROMAN
N APSS: Syntactic and semantic description for the
numerical analysis programming language
Comp Sci Dept Purdue Univ 1969
5 H MARKOWITZ B HAUSNER H KARR
SIMSCRIPT: A simulation programming language
The RAND Corp Santa Monica 1963
6 N NIE D BENT C H HULL
SPSS: Statistical package for the social sciences
McGraw-Hill 1970
7 B WEGBREIT
The ECL programming system
Div of Eng and App Phy Harvard 1971
8 C HEWITT
PLANNER: A language for proving theorems in robots
Proc of Internat Joint Conf on Arti Intell 1969
9 F THOMPSON P LOCKEMAN B DOSTERT
R DEVERILL
REL: A rapidly extensible language system
Proc 24th Nat Conf of A C M 1969
10 B H DOSTERT F B THOMPSON
The syntax of REL English
REL Project Calif Inst of Technology 1971
11 C J FILLMORE
The case for case
Universals in Linguistic Theory ed E Bach and R Harms
Holt Rinehart and Winston 1968
r
319
12 J E SAMMET
Programming languages: History and fundamentals
Prentice-Hall 1969 p 20-22 p 726
13 J E SAMMET
The use of English as a programming language
Comm of A C M 9 pp 228-230 1966
14 F B THOMPSON
English for the Computer
Proc FJCC pp 349-356 1966
15 T WINOGRAD
Procedures as a representation for data in a computer
program for understanding natural language
Project MAC MIT 1971
16 C KELLOGG J BURGER T DILLER D FOGT
The converse natural language data management system
Proc of Sym on Info Stor and Retrieval Univ of Maryland
1971
17 W A WOODS
Transition network grammars for natural language analysis
Comm of A C M 13 pp 591-606 1970
18 S PERSCHKE
Machine translation, the second phase of development
Endeavour 27 pp 97-100 1968
19 J SAMMET
An overview of programming languages for speciali.zed
application areas
To be published in Proc SJCC 1971
20 SIMSCRIPT 11.5 handbook
California Analysis Centers Santa Monica 1971
21 Proc of A C M Sigplan Conference on Extensible
Languages Sigplan Notices 6 #12 December 1971
22 M D HALPERN
Foundations of the case for natural-language programming
Proc FJCC 29 19()()
AMBUSH-A case history in language design
by STEPHEN W ARSHALL
Applied Data Research, Inc.
Wakefield, Massachusetts
common characteristics in the development of languages for new problem areas.
Whenever any body of informal discourse about a
subject is analyzed in order to create a formal language
for saying the same things, the primary effort is concentrated on verifying that the formal language under
creation is complete-that one can express every
meaning-with little concern for ease of use or its close
relative, grammatical simplicity. The first requirement
is met by letting the language arise from, and comparing
it to, a large body of utterances in the informal discourse. The loom of this body of utterances generally
causes the second criterion-essentially that of linguistic "goodness"-to be quickly reinterpreted to
mean superficial similarity to the informal language.
Forms in the slowly developing formal language are
adjudged good insofar as they "look like" the corresponding forms in the informal one. This perfectly
natural criterion generally leads to first-cut designs
which, although very valuable (for they effect the
desired formalization), usually exhibit certain characteristic properties:
INTRODUCTION
AMBUSH is a language in which the user can describe
a materials-processing/transportation network in an
allegedly readable form. The AMBUSH Compiler
transforms this description into a set of linear equations
and inequalities and edits this set into an input file for
a linear programming package.
Although the language is powerful enough to handle
both materials-processing and transportation, its design
is heavily biased toward processing, with transportation
expected to appear only occasionally, around the
"edges" of the network. Thus, a typical subject for
AMBUSH description might be a very complex oil
refinery with a few arcs representing transport of crude
oils into and final products out of the refinery.
AMBUSH was designed by Applied Data Research
for the Shell Oil Company, to facilitate the preparation
of very large linear programming problems. This
project followed a long history of experimental language
design by Shell and its contractors, which had yielded
a very valuable crop: Shell was able to summarize,
fairly confidently and economically, the set of meanings
to be expressed. The present language is the result of
collusion (and sometimes collision) between Shell's
body of experience and ADR's background in language
and compiler design.
AMBUSH, as actually designed and implemented,
represents a conscious compromise between two styles
of language design: the "template" style, with a large
set of different statement types, corresponding roughly
one-to-one to the kinds of utterances the user is accustomed to; and the recursive style, in which the
designer hunts for a minimal number of logical primitives sufficient to express all meanings and devises the
shortest (in number of types) and most highly recursive
grammar possible for combining the primitives. This
stylistic tension and, indeed, the historical sequence
from pure template languages toward more recursive
ones exhibited in the AMBUSH project are, we believe,
a. A syntax which is "broad" rather than "deep."
By this we mean that they tend to have a large
variety of different, special syntactic formseach aping a familiar English one-rather than a
small number of forms and a small set of rules
for recursively combining them.
b. A proliferation of reserved identifiers, each of
which once again apes a commonly used word
in the informallangul:ltge, even when several of
these identifiers may be logically identical in
function.
c. Extremely rigid format requirements, which
mechanically copy the forms in which informal
information is currently expressed.
These properties tend to characterize languages
which, however easy to read, are very difficult to learn
to write in, since each type of utterance has its own
321
322
Spring Joint Computer Conference, 1972
special construction rules and its own reserved identifiers; difficult to compile, since the grammars are so
broad; and difficult to extend, since the grammars are
so non-uniform and format-controlled.
It has been our general experience that a first-cut
language design should be viewed as a formal characterization of the class of required utterances, rather
than as an end product. What is required next, of course,
is a redesign embodying deliberate infusion of the
recursive style. The ever-present danger is the obvious
one of going too far: users are willing to change their
habits only so much, and a language which demands a
complete reorganization of their styles of thought and
expression sets an unacceptably high price, for perfectly
understandable reasons.
In this paper we do eventually present a skeletal
grammar of the AMBUSH language, as it was actually
implemented. Our primary purpose, however, is not to
describe a language. Rather we intend to treat the
AMBUSH project as a case history of the language
design process, which may give substance to our general
remarks about the shift from template to recursive
style.
We begin by summarizing how an engineer thinks
about his model of an oil refinery: the appearance of
his graph, the kinds of assertions he makes about flow
in the graph, the packages of information he thinks of
as single elements of model description. We then
describe, in general terms, the structure of languages in
the template style for expressing the engineer's meanings. Next we reexamine the engineer's utterances from
the point of view of a designer in the recursive style,
concerned with logical minimality and searching for
opportunities to shorten the grammar by the use of
recursion. In this last section, the general outline of the
final grammar of AMBUSH takes shape. Then we
present that grammar, so that the reader can verify our
claim that AMBUSH is indeed a compromise: a language· basically in the recursive style, but with elements
of the template style still remaining, to render it more
familiar-looking, and thus more palatable, to the user.
HOW THE ENGINEER DESCRIBES HIS
MODEL
The directed graph
An engineer conceives of his model as a directed
graph (with no self-loops), with labels on the nodes and
arcs. [The bracketed examples in this paragraph refer
to the figure in Appendix I.] The nodes of the graph
are labeled with the names of the processing units of a
plant or refinery, or the staging points of a transporta-
tion network ['EGG.PLANT,' 'BLEND.UNEX,'
'DEPOT']. The arcs of the graph represent the paths
of flow of the various materials in the model. Each arc
is a path for exactly one material and is labeled with the
name of that material ['Exotic Liquid,' 'Unexciting
Prod.']; if several materials flow from one node to
another, there will be several "parallel" arcs (arcs with
a common head node and a common tail node) between
the nodes [Universal Solvent and Residue both flow
from ICE.PLANT to BLEND.UNEX]. Node names
are unique (no two nodes bear the same name), while
arc names are not (several arcs may bear the same
name: the same material may flow in numerous arcs of
the graph [Residue flows from ICE. PLANT to
BLEND.UNEX, to TRUCK, and to DEPOT1, and
from DEPOT1 to DEPOT2]). Parallel arcs must have
different labels: that is, there can be but one arc carrying a given material from a given node to a given other
node.
Thus, an arc of the graph is completely specified by
an ordered triple of names: (node name, arc name,
node name).
The variables of the model correspond to the arcs of
the graph or, more precisely, to the flow along the arcs.
That is, the engineer states his restrictions on the model
and his costs in terms of flows on arcs, and seeks an
optimal solution stated in terms of flows on arcs.
The arcs of the graph will become the columns of a
conventional LP matrix; the restrictions on the model
will become rows of the matrix; and the various costs
incurred in the model will become the objective function(s) of the matrix.
Restrictions on flow in the graph
Material balance
In general, at every node of the graph which possesses
both inputs and outputs, the engineer wishes to relate
the various flows entering to the flows leaving the node.
These relations are conventionally expressed, in the LP
matrix, as a set of "material balance equations" (rows).
Each equation expresses the total amount of a single
material flowing out of a node as a linear expression in
the flows of the materials entering the node. The
coefficients of such an expression are called "yield
factors," and the engineer thinks in terms of these
yield factors. It is important to note that a single
material balance equation, while a natural element
(a single row) of the. LP matrix, does not necessarily
correspond to a natural single utterance for the engineer.
He may, for example, refer to a handbook of standard
processing units which contains an array (inputs vs.
AMBUSH
outputs) of yield factors, each of whose columns
corresponds to a single equation; or an array of outputs
vs. inputs, with rows corresponding to equations; here
the entire array corresponds to a single utterance for
the engineer. On the other hand, the engineer may
assemble his description of material balance at a node
from several sources, each of which supplies a few yield
factors-each factor associated with an input/output
pair-in no particular order. In sum, the engineer's
natural utterance is an arbitrary subset of the yield
factors at a single node, or a complete array of these
yield factors organized in either of two ways.
Quantity restrictions
The engineer may set a limit (maximum, minimum,
or fixed amount) on the total flow through a set of arcs.
Each such restriction becomes a row of the LP matrix.
It is noteworthy that the set of arcs in a single restriction is not at all arbitrarily chosen, but is always either
a subset of the arcs entering a single node or a subset
of those leaving a single node. This limitation imposes
no logical restriction on the engineer, for he can always
introduce further arcs and nodes so as to create a set of
input arcs to a single node (or even a single arc) whose
flow will be precisely equal to the sum of the flows in an
arbitrary set of arcs. The point here is not that a certain
kind of arc set is logically sufficient, but rather that it is
the only kind that the engineer in fact uses as a domain
for quantity restrictions.
"Quality" restrictions
The engineer may set a limit on the value of some
physical property for the mixture of the flows on several
arcs. For example, three arcs might carry three different
materials each with a certain specific gravity. The
engineer wishes to restrict the relative flows on the three
arcs so that the specific gravity of the total flow satisfies
some limit (maximum, minimum, or fixed value). If
we denote the flows in the different arcs by !i and the
respective specific gravities by gi, the engineer is setting
a limit on the value of Li!igi/ Li!i. Once again) as
with the quantity restrictions, the set of arcs is always
either a subset of the arcs entering, or a subset of the
arcs leaving, a single node.
Ratio restrictions
The engineer may set a limit on the ratio of the total
flow in one set of arcs to the total flow in another set of
arcs. Again, it is a feature of user behavior that the
323
union of the two sets of arcs referenced in a single ratio
restriction is always a subset of the arcs entering or a
subset of the arcs leaving a single node.
Cost and income
The engineer may wish to state that flow along certain
arcs incurs cost or generates income. Eventually, all
his remarks of this kind will become the objective
function of the LP problem, a linear expression in flows
on arcs which is to be minimized. The engineer's typical
utterance does not correspond to an entire objective
function, but rather to the supply of a single coefficient
value for the objective function; such a coefficient value
may apply to one arc or to a set of arcs: thus, the
engineer may say, in effect, "flow on any of this set of
arcs costs $3.50 per unit flow." It is no serious distortion
of user behavior to say that the set of arcs to which a
single cost/income coefficient applies is always either a
subset of the arcs entering, or a subset of the arcs
leaving, a single node.
TEMPLATE-STYLE LANGUAGES
Even from the rather brief picture given above of the
engineer's view of his model, it should be clear that he
has a fairly large number of different-or what he
believes are different-kinds of things to say. He must
be able to describe a graph, supply a set of yield factors,
supply an array of yield factors in input/output form,
supply the array in output/input form, state quantity
restrictions on the output side of a node, or the input
side, assign cost to an arc, assign income to an arc, and
so forth.
It is important to note that, although the difference
between some two elements of this list may seem quite
trivial to the reader (input/ output form versus
output/input form of an array of yield factors, for
example), the difference may look enormous to the
engineer, who obtains the two kinds of information
from different sources, uses them in different modeling
contexts, and discusses them in a different vocabulary.
In our effort to summarize the engineer's utterances
concisely, we have made use of logical similarities
between utterances which might, to him, look quite
different. Thus, in our description of quantity restrictions, we took advantage of the fact that to set a
quantity maximum is not unlike setting a quantity
minimum. In some real problem, however, all the
maxima may come from physical limitations (pipeline
capacities, say), while all the minima may reflect
business obligations (requirements to buy at least so
much from various suppliers). The engineer in this
324
Spring Joint Computer Conference, 1972
situation is not working with maxima and minima
(which even sound similar) but with capacities and
obligations, which he may customarily treat with quite
dissimilar vocabularies.
A common characteristic of the early language designs
for the description of these models was a strong tendency to preserve, more or less uncritically, the many
logically empty distinctions between "different kinds"
of information. Thus, such a language would typically
consist of a large number of dissimilar-looking templates,
composed of reserved words; each template would
correspond to one of the different kinds of information,
and the reserved words would guarantee a familiarlooking quasi-sentence appropriate to that kind. The
holes in the templates were to be filled with nothing
more complex than lists of numbers or lists of names.
It would be grossly unfair to early workers in the
area to suggest that the number of templates in any
real language design was anywhere near as large as
completely uncritical acceptance of the engineer's
discriminations would have implied. Considerable, and
quite fruitful, effort was devoted to the reduction of this
number to even more manageable limits. Nonetheless,
it is fair to say that even the latest of the pre-AMBUSH
languages retained all the stigmata of the template
approach:
a. An extremely broad and shallow grammar: a
very large number of syntactic types at the
"statement" level, with almost no phrases in
common (above the level of name list or number
list) .
b. A very large number of reserved words.
c. Inconsistencies of lexical style: the use of
punctuation marks as separators when the
templates were to look sentence-like, the use of
spaces or position-on-card to delimit symbols if
the templates were to look like arrays.
d. Prefix characters to signal statement type: since
the templates possessed little or no common
phrase structure, the .analyzer was likely to
consist of many essentially independent recognizers entered through a common switch and
thus a prefix character was required to control
the switch.
ANOTHER LOOK AT THE ENGINEER'S
UTTERANCES, BY DESIGNERS IN THE
RECURSIVE STYLE
Reduction in variety of user's statement forms
Let us set aside for the moment the problem of
specifying the structure of the graph itself, and confine
our attention to those of the engineer's utterances
which include numerical information-these are the
statements of restrictions or remarks about cost and
income. The most striking fact about these numerical
assertions is that each concerns an extremely small
portion of the whole graph. Thus, a remark about
material balance always talks about a subset of the
arcs entering or leaving a single node; and the other
numerical assertions only refer either to a subset of the
arcs entering, or a subset of the arcs leaving, a single
node.
This immediately suggested the possibility of turning
the language "inside out" in the following sense:
instead of having one statement type per "kind of
information," each containing its subgraph specification
after its own fashion, we could have a far smaller
number of statement types, one per kind of subgraph,
each containing the kind-of-information specification
in a more uniform fashion. This inversion had several
attractions:
a. It dropped to a lower syntactic level the vast
array of special forms, with their reserved words
and need for special recognizers; above this
level, phrase structure could be quite simple and
uniform.
b. It simplified the job of persuading the user of the
logical emptiness of many of his discriminations;
if the template for pipeline capacities looks completely different from that for purchase obligations, with reserved words scattered nonanalogously throughout the two forms, it is hard
to convince him that they are logically similar;
if, however, he sees the differences entirely
embodied-reserved words and all-in two short
phrases which fit in exactly the same larger
structure, he becomes far more willing to drop
the reserved words for his 10 different kinds of
quantity restriction and simply say "maximum"
or "minimum."
c. It became trivial (indeed, almost inevitable) in
grammar design, and very palatable to the
engineer, to take advantage of the symmetry
between the inputs of a node and its outputs.
The syntactic type for discussing the one could
look identical to that for discussing the other, to
within a reserved word or two.
d. It suggested some interesting possibilities of
nested information. The engineer frequently had
several things to say about the same subgraph,
or about two subgraphs, one of which was a
proper subgraph of the other. We could perhaps
arrange our grammar to permit him to nest his
sub graph specifications, and to associate with
each nesting level a set of (say) restrictions.
AMBUSH
The redundancy of graph specification
A notable feature of the numerical assertions described above (the restrictions and income/ cost
utterances) is that, whether they be written in engineer's jargon, some template language, or in some new,
recursive language, they inevitably contain information
about the structure of the graph. This is perhaps
obvious, for-as we have earlier indicated-every
numerical assertion must contain a specification of the
sub graph to which the assertion applies.
Thus, to say that the maximum amount of M flowing
out of A is less than five surely suggests that the graph
contains a node named A with at least one arc labeled
M leaving it. Every numerical assertion contains some
such topological information, and the set of such
information collected from all assertions appeared to
yield a fairly good picture of the overall shape of the
graph. Initially, this redundancy was expected to
provide a check: the topological implications of each
assertion might be verified against a previously given
graph description.
Then a further observation was made. A very large
number of the nodes in a graph did not represent either
processing units or staging points, but were essentially
formal: they represented "pools" of intermediate
products. Within a model, the engineer deals with two
kinds of materials: the "pooled" ones, like intermediate
products in a refinery, such that any consuming node
can obtain them from any producing node; and the
non-"pooled" ones, like raw materials and final
products, which flow from each producing node to
certain consuming nodes, and no others. For each
pooled material, the engineer establishes a single pool
represented by a node, with arcs to the node for each
producer and arcs from the node for each consumer.
Moreover, since our user population modeled very
large refineries with only a small amount of transportation at the edges of the graph, it turned out that
virtually all materials in a typical model were of pooled
type. This implied that, if we required the user to
declare explicitly his non-pooled materials (which
should be but a small burden, for they were not numerous), the Compiler could draw far stronger topological inferences from his numerical assertions than we
had originally thought. Thus, from the example given
earlier in this section, one can deduce not only that at
least one arc carries M out of A, but-if M is pooledthat the arc must go to the pool for M and must be
unique (since parallel arcs must have different labels).
This analysis led to the conclusion that the set of
topological implications contained in all the engineer's
numerical utterances amounted to a virtually complete
description of the graph, and thus separate statement
325
types designed for graph specification were quite unnecessary. True, there might be an occasional piece of
graph left ill-defined after the numerical statements
were written, but our statements for making numerical
assertions were going to incorporate the specification of
little sub graphs to which a set of numerical remarks
would apply. If we simply permitted these types to
contain an empty set of numerical remarks, we would
have a mechanism for describing little subgraphs,
thereby filling in the holes in the graph definition.
(The fact that this degenerate form would be inappropriate for describing a whole graph was entirely
irrelevant. )
THE GRAMMAR OF AMBUSH
The grammar of AMBUSH derives directly from the
observations of the preceding section. There is no
statement type intended exclusively for graph description; there are three statement types for making
numerical assertions, differentiated semantically by
the kinds of arc set (subgraph) they discuss:
a. The YIELDS statement, for discussing the
inputs and outputs of a node; this is used exclusively for the supply of yield factors.
b. The SENDS statement, for discussing subsets of
the arcs leaving a node; this is used for all
numerical assertions except the supply of yield
factors.
c. The TAKES statement, for discussing subsets
of the arcs entering a node.
(N ote: In this section, we have permitted ourselves the
liberty, in stating our rules of grammar, of using,
without definition, the types (identifier) and (numex),
which latter type corresponds to "numeric expression.")
The YIELDS statement
GraInInar
(row):: = (identifier), (numex) I (row),
(numex)
(row list): : = (row) I (row list), (row)
(name list): : = (identifier) I (name list),
(identifier)
(yields statement): : = (identifier) RUNNIN G
(name list) YIELDS
(row list) I (identifier)
YIELDS (name list)
RUNNIN G (row list)
326
Spring Joint Computer Conference, 1972
ExaInples
Sl, S2, S3
.1, .4, .5,
.6, .1, .1
S4, S5,
b. URUNNING
YIELDS
Sl, .1, .6,
S2, .4, .1,
S3, .5, .1
c. U RUNNING Sl YIELDS S2, .4, S3, .5
a. UYIELDS
RUNNING
S4,
S5,
Discussion
It should be clear from the first two examples (which
are identical in meaning) that the grammar has been
designed to facilitate supply of a large array of yield
factors in either input/output or output/input form.
The more "linear" style, exhibited in Example c, for
the supply of a few yield factors, is identical grammatically to the array style.
It should be noted that the grammar demands that
the set of yield factors supplied in a single statement
always correspond to some array (the cross product of
a set of inputs and a set of outputs), however small.
This requirement is made less troublesome than might
appear, for the Compiler systematically fails to distinguish between a yield factor of zero and no yield
factor at all. Thus, the engineer can, for example, write
one statement to cover all but one of the yield factors
at a node (representing the missing one by zero) and a
second statement to supply the omission.
The SENDS statement
GraInInar
b. SENDS Statement
(stream/node factor): : = (identifier) I
( (stream/node
expression) )
(stream/ node term): : = (stream/node
factor) 1
(stream/ node
term),
(modifier)
(stream/node expression): : = (stream/node
term) I
(stream/ node
expression),
(stream/node
term)
(sends clause): : = SENDS
(stream/node
expression) TO
(stream/ node
expression) I
SENDS
(stream/ node
expression)
(sends statement): : = (identifier)
(sends clause)
ExaInples
a. Modifier
1.
2.
3.
4.
5.
MAX 50
SPEC.GRAVQFIX .75
MAX .5 (M!, M 2)
COST3 -3.50
INCOME33.50
b. SENDS Statement
a. Modifier
(limit):: = MAX 1 MIN 1 FIX (qlimit):: =QMAX 1 QMIN 1 QFIX
(cost):: = COST 1 COSTO 1 COST11
... 1 COST91
INCOME 1 INCOMEO I
INCOME11·· .1
INCOME9
(quantity phrase): : = (limit) (numex)
(quality phrase): : = (identifier) (qlimit)
(numex)
(ratio phrase): : = (limit) (numex)
(stream/node factor)
(cost phrase):: = (cost) (numex)
(modifier):: = (quantity phrase) 1
(cost phrase) 1
(quality phrase)
(ratio phrase)
1
1. U SENDS A, MAX 50
The maximum quantity of A output by
U is 50 .
2. U SENDS (A, MAX 50, MIN 40, B, MAX
50), COST 3.50
The maximum quantity of A output by
U is 50.
The minimum quantity of A output by
U is 40.
The maximum quantity of B output by
U is 50.
A cost of 3.50 is incurred per unit of either
A or B flowing out of U.
3. U SENDS (A, MAX 50, MIN 40, B, MAX
50), COST 3.50 TO X, MAX 10, Y, MIN 10
All the meanings included in Example
2, plus:
AMBUSH
The total flow of A or B from U to X has a
maximum of 10.
The total flow of A or B from U to Y has a
minimum of 10.
4. U SENDS A, B TO X
This example includes no numerical assertion, and is thus "degenerate." It
informs the Compiler that there is one
arc carrying A, and another carrying B,
from node U to node X.
5. U SENDS A, MAX .5 (B, C, MIN 10)
The minimum quantity of C output by
U is 10.
The quantity of A output by U is ne more
than .5 times the total quantity of B
and C output by U.
Discussion
The four varieties of modifier correspond to the four
kinds of numerical assertion (other than supply of
yield factors) covered in earlier sections: quantity,
quality, and ratio restrictions and income/cost assertions. The large number of reserved words in the
definition of (cost) derives from the desire of the user
to define several objective functions and from his
preference not to treat an income as a negative cost
(modifier Examples 4 and 5 are identical in meaning).
Each modifier must apply to a certain subgraph (set
of arcs) of the graph and the only difficulty in understanding the SENDS statement is that of learning the
rules which determine to which sub graph a given
modifier applies.
First it should be noted that every SENDS statement
begins with an identifier; this names a node of the
graph, which we will-in this section-call the "subject
node" of the statement. The word SENDS indicates
that we are discussing arcs leaving the subject node.
Next follows a stream/node expression in which appear
identifiers which are the names of physical materials.
Within tliis expression, such a name M is to be read as
shorthand for "the set of all arcs carrying M out of the
subject node," and thus defines a subgraph.
The syntactic type (stream/node factor) corresponds
to the notion of subgraph. If a given stream/node
factor is a single identifier, we have already indicated
what subgraph is meant. If the factor is a parenthesized
expression, the sub graph meant is the union of the
subgraphs defined by all material names found in the
expression. Thus the stream/node factor (Ml' M 2) is to
be read as "the set of all arcs carrying either Ml or M2
out of the subject node."
The reader will observe that the type (stream/node
term) is defined as a single (stream/node factor)
327
followed by an arbitrarily long list of modifiers (with
appropriate separation by commas). The meaning here
is that each modifier in the list is to be independently
applied to the subgraph defined by the factor.
In sum, then, the recursive nature of the (stream/node
term) definition permits application of a set of modifiers
to a single subgraph; the recursion in (stream/node
factor) definition (i.e., the ability to parenthesize a
(stream/node expression) to make a new factor)
permits nested sub graph definition; and, finally, the
recursive structure of a (stream/node expression)
permits assertions about overlapping or disjoint subgraphs to be included in the same statement (so long as
each subgraph is a subset of the arcs having the subject
node) .
The engineer may continue his statement, after the
stream/node expression, with the reserved word TO
followed by a second stream/node expression. In this
latter expression, the identifiers are the names of nodes;
each identifier N acts as shorthand for "the set of all
arcs carrying any of the materials named in the first
stream/node expression from the subject node to the
node N," and thus defines a subgraph. The rules for
applying modifiers to factors, treating parenthesization
as subgraph union, etc., are exactly as before.
The TAKES statement
Grallllllar
(takes clause):: = TAKES (stream/node expression)
FROM (stream/node expression) I
TAKES (stream/node expression)
Exalllples and Discussion
The TAKES statement is completely analogous to
the SENDS statement, both grammatically and
semantically. With appropriate substitution of TAKES
and FROM for SENDS and TO, the examples of the
previous section will be correct. With similar substitutions in the discussion section, that section will
work also.
Final notes on the grammar
The basic skeleton of AMBUSH consists of the three
statement types described above and a few declarations:
notably, one to list non-pooled materials and another
for the supply of physical property values for materials
which participate in quality restrictions.
The language has a full macro capability, including
the insertion, at macro-expansion time, of actual
parameters for formal parameters in the macro defini-
328
Spring Joint Computer Conference, 1972
tion. Macros are, of course, used for abbreviation and
to reduce copying errors. But they also serve as a way
to parametrize a model: an identifier may be used in
place of any numeric quantity, and its value may be
changed from run to run. Other methods of parametrization, without recompilation, are also available.
For the sake of completeness, it should be added that:
a. The Compiler treats the AMBUSH program as
a string, and consumes 72-column card images
stringwise without format requirements.
b. AMBUSH (like many languages without a
statement terminator) has a statement initiator
(the # character) .
c. An AMBUSH program is bracketed by the
reserved strings BEG IN and END.
d. An AMBUSH identifier is built of alphanumerics and the period character; the initial
character must be alphabetic and the character
limit is twelve.
e. An AMBUSH number is a string of up to 14
digits among which at most one decimal point
may appear.
f. All arithmetic is performed in floating point.
g. Numeric expressions are built in the customary
way out of numbers, the four arithmetic operators, parentheses, and the special functions
EXP and LOG. Unary minus is permitted. The
evaluation rule is left-to-right and gives equal
precedence to * and / and equal precedence to
and-.
h. A comment may be inserted between any two
tokens of the language (roughly, in any place a
space would be allowable). The comment is
delimited by < and >; the # sign is prohibited
within comments so that, when the programmer
neglects to close his comment, it will be closed
automatically by the initiator of the next
statement.
+
AMBUSH AS A COMPROMISE IN STYLES
It should be clear to the reader that the grammar of
AMBUSH follows fairly directly from the observations
made in Section 4, and in general exemplifies the
recursive style:
a. The grammar clearly reflects the search for a
logically minimal description of the user's
utterances.
b. The syntax is "narrow" (a small number of
types at the statement) level and "deep" (highly
recursive, at least within the SENDS and
TAKES statements).
c. There are relatively few reserved words.
d. Lexical strategy is uniform; the input is treated
as a string.
On the other hand, there still remain certain elements
of template style; for example:
a. The two forms of YIELDS statement (input vs.
output and output vs. input) are a logical
redundancy.
b. The reserved words QMJN, QMAX, and
QFIX could be replaced by MJN, ~![AX and
FIX. The
< RAW MATERIAL SLATE >
120
ARKAN,IE.R.M. COST 7.00. MAX
SENDS
LOUIS,IE.R.M, COST 7.50, MAX 300, MIN 180.
SENDS
100
AI..ASK.EX.R.M. COST 20.00. MAX
SENDS
LABRA,lX.R.M, COST 25.00. MAX
ISO
SENPS
MNOPOOL.:
MADDITIVE:
.. ARKANSAS
"I..OUISIANA
.ALASKA
"LABRADOR
"PURCHASE
"'CEPL.ANT
• COST .80
< >
< PROCESSING UNITS >
,MAX 250. COST ,20
< >
ARKAN.IE.R.M. LOUIS.IE.R.M
RUNNING
SENDS
"ICEPL.ANT
YIELDS
FUEL..GAS
•
UNI.SOLVENT,
RES'DUE
"EGGPLANT
.COST
.50
< >
ALASK.EX.R.M, LABRA.EX.R.M
"EGGPLANT
RUNNING
YIELDS
EXOTlc.L.JQ •
REJECT
IEGGPLANT
< >
fUEL..GAS
TAKES
< >
PRODUCT 8L.ENOS
BCINDEX. SPEC.GR
18LENDEXOT
1 1 .5
10.0
.7
TAKES
.70
.30
.60
.'+0
(
"PROP:
STREAM
EXOTIC.LIQ •
UNl.SOLVENT.
SLUE.ovE
• 12
.7'+
.1"+
.10
.70
.20
< >
•
•
• fIX .11
CALASK.EX.R.M •
LABRA.t:X.R.M)
>
1 .2 •
0.9 •
< >
)
CEXOTIC.LIQ • UNI,SOLVENT • BLUE,DYE
SPtC.GR QMAX
1• 1
BCINDEX "MIN
12
< >
UNEXCIT.PROD
•
ISLENDUNEX
MAKES
BLENDING
UN,I.SOI..VENT.
REJECT
RESIDUE
.25
,'+5
.30
< >
( ACCUMULATE EXCESSES>
IPOOLlRES1DUE)
SENDS
RESiDUE
TO
TRuCKS,
• COST ,50)
< >
"SOLVENT.XES TAKES UNI,SOlVENT
"BURNING
TAKES
fUEL.GAS
< >
< DISTRIBUTE fINISHED PRODUCTS>
TAKES
EXOTIC.PROD
fROM
"DEPOTl
UNEXCIT.PROD fROM
xES.SOL.VENT
fROM
EXCESS,RESID fROM
(RESID,[XCESS.
,MAX 30
8L.ENDEXOT
BLENDVNEX
SOL.VENT,XES
RESIp,~XCESS
.
331
100
200
300
"00
SOO
600
700
800
900
1000
1100
1200
1300
1 .. 00
lSOO
1600
1700
1800
1900
2000
2100
2200
2300
2'+00
2S00
2600
2700
2800
2900
3000
3100
3200
3300
3'+00
3S00
3600
3700
3800
3900
'+000
.. 100
.. 200
.. 300
.... 00
.. 500
.. 600
.. 700
"+800
.. 900
5000
5100
S200
SlOO
5"+00
5500
5600
5700
5800
5900
6000
6100
332
Spring Joint Computer Conference, 1972
TAKES
"OEPOTI
"SALES,2
.PSEUOONOO£
"OEPOTI
SENOS
TAKES
EXOTIC,PROD ,
UNEXCIT.PROO,
XES.SOLVENT •
EXcESS.RESIO,
FDUR,PROOUCT
,xpTIC,PROP ,
UNEXCIT,pROD,
XES.SOLVENT ,
EXCESS,RESID,
< >
< SET PIPELINE CAPACITY
UNEX.PL.CAP
SENDi
(UN[X,PL.CAP
TAKES
SOLVE,PL,CA'
MESIC,PL,CAP
TAKES
INCOME
INCOME
INCOME
INCOME
fROM
TO
INCOME
INCOME
INCOME
INCOME
FROM
~o.o
15.0
30.0
3.0
35.0
10.0
25,0
Card numbers:
400,500: These illustrate the form of simple declarations-a declarative reserved word, followed by a
colon, followed by a list of identifiers used as
names of materials. Note that FOUR. PRODUCT
is a list of four material-names by virtue of the
MACRO definition on cards 200-300.
400: NOPOOL tells the compiler not to automatically
set up a POOL node for the material(s) named in
the declaration. This implies that arcs carrying
these materials must have both end points specified
(see cards 5800-6100 for the FOUR. PRODUCT
materials). Compare this to cards 2000, 3100, and
5500 which together describe the handling of
FUEL.GAS: ICEPLANT "yields" it (to its
pool), and EGGPLANT and BURNING "take"
it (from the pool).
500: The material BLUE.DYE is declared to be an
DEPOTI
OEPOT2
,MAX 120,
,F'X 80,
,F'IX 20,
,
,
3.0
LIMITATIONS>
,SOLVE,PL.CAP
,FIX CSOO/~SO
,FIX (SOO/~OO
,F1X (S00/300
~XOTIC.PROD ),MAX
SOO
CUNEX,PL.CAP ,FIX (22S/200
SOLVE.PL.CAP ,fIX (22S/17S
REsIO"L,CAP ,FIX (225/125
EXoTIC,PROD ),MAX 225
Notes to the listing
,MAX 126.
,MAX 120.
,MAX 60.
DEPOT2
,RESlO,PL.CAP
• 1) UN£XC1T,PROO,
• 1) XES.SOLVENT ,
• 1) EXCESS,RES10.
•
•
•
1) UNExelT.PROO,
1) XES.SOLVENT ,
1) EXCESS.RESID,
6200
6100
' .. 00
6S00
6600
6700
6800
6900
7000
7100
7200
7300
7"00
7S00
7600
7100
7800
7900
8000
8100
8200
8')00
8 .. 00
additive. This informs the compiler that the
quantity of blue dye coming into a node (card
4100) has no effect on material-balance calculations, but only on quality determinations.
1600,2400: This is a shorthand statement for applying
modifiers to the total capacity or throughput of a
node. Formally, such a statement is interpreted by
the compiler as a degenerate form of the TAKES
statement, with the modifiers applying to the set
of all input arcs to the node.
3500-3900: This declaration gives, for each relevant
material, the coefficient to be used in "quality"
calculations, described in an earlier section.
4400-4800: This is one of the "totally redundant
template statements" retained in the language
because of its familiarity; the MAKES ...
BLENDIN G statement is a variant of the YIELDS
statement, used to describe a node which produces
a single material, by giving the "recipe" for its
product in terms of its inputs.
The data-text system-An application language for the
social sciences
by D. J. ARMOR
Harvard University
Cambridge, Massachusetts
tion. Why did the symbolic machine languages fail to
suffice for all application software, being supplanted
almost exclusively by FORTRAN for problems involving numerical computations? In retrospect the answers
are obvious. First, programming in a machine language
requires a good deal of detailed knowledge of the internal structure of the machine; second, the atomistic
nature of the instruction set means a great deal of programming effort even for simple mathematical expressions-not to speak of the coding required for
routine input-output procedures. For the engineer or
scientist with a particular type of mathematical expression to evaluate, the investment of time and energy in
learning and programming in machine language was
costly. FORTRAN and other languages like it solved
this problem for many· quantitative applications in the
physical sciences. FORTRAN was relatively machine
independent (at least by the end of the 1950's) and
could be learned very quickly by those with some background in mathematics. Most mathematical formulas
could be expressed in a fairly natural way, and most of
the troublesome clerical problems of I/O were handled
with a minimum of complexity (at least in comparison
with machine language solutions). In other words, the
FORTRAN-type languages were "natural" languages
for those programmers working in numerical mathematical applications. The same can be said of many
other languages, such as COBOL in the business realm
and SNOBOL in the field of text processing.
For many other fields, however, FORTRAN is not a
"natural" language. In the social and behavioral
sciences, where mathematical proficiency is not predominant, a great many statistical analyses are commonly used even though their mathematical bases are
not fully comprehended by the user. Two examples are
the techniques of regression analysis and factor analysis. The first requires inversion of a matrix of correlation
coefficients, and the second requires extraction of
eigenvalues and eigenvectors. Although a competent
INTRODUCTION
The enormous growth of special applications software
has been the subject of much speculation and debate.
While many of the developments are natural expansions into new application areas, many computer specialists argue that applications programming is a prime
example of the tendency to reinvent the wheel. No
area receives this accusation more than that of statistical packages or languages, particularly those developed
for applications in the social and behavioral sciences.
A recent study by Hugh F. Cline shows that in 130
universities which grant higher degrees in these fields,
there are over 170 such packages or languages in use.!
This is more than one per university! Noone could
possibly maintain that all of these systems are unique;
the duplication of effort has been rampant.
Now that I have said that, I want to take the other
side. While I cannot defend outright duplication, I
want to present some of the reasons why many of these
developments were necessary and why they represent
a significant stage in the evolution of computer software. In illustrating my argument, I will draw upon
examples from the Data-Text system, a data processing
and statistical analysis language developed at Harvard. 2
Although other systems could be used to make the
same points, Data-Text may represent the most comprehensive attempt in this field to date. Besides, since
I helped to develop it, I know it better than others!
EARLY DEVELOPMENTS
One insight into the rationale behind Data-Text and
other similar attempts can be gained by considering the
origin of languages like FORTRAN. Why was FORTRAN developed and why did it become so popular?
All modern computers have had symbolic machine or
assembler languages since at least the IBM 704 genera-
333
334
Spring Joint Computer Conference, 1972
social scientist can understand the results of these
analyses, very few actually understand the mathematical techniques which are required to derive the
results. (In defense of the social scientist, I should
hasten to add that a great number of physical scientists
I have known are likewise in the dark.) Even in the
case of less complex statistical methods, many researchers are not able to provide precise computational
formulas without careful review of a statistics textbook.
The result of this is that the social scientist finds it
difficult to program in a language which requires that
he provide the mathematical or statistical formulas for
all of his ordinary analyses. Thus languages like
FORTRAN, ALGOL, BASIC, PL/I, and COBOL are
not natural languages for the social scientist. I think
this argument can be extended to other fields as well
where standard algorithms exist for data analysis problems. In these cases, if a language is to earn the label
"natural," it should embody terms or macros which
call in these entire algorithms, just as FORTRAN calls
in a routine in response to a function name such as
SQRT or LOG. In other words, FORTRAN and similar
languages are natural languages for the programmer
who wants to implement a statistical or mathematical
algorithm, but they are not natural languages for those
who simply want to apply those algorithms to analyze
a particular set of data.
I do not want to give the impression that the only
limitation of FORTRAN-type languages has to do with
statistical algorithms. There are a variety of other data
processing problems which are commonplace in the
social sciences which can be extremely tedious to program in FORTRAN. One example is the problem of
missing observations. These occur whenever a variable
cannot be measured for a given subject or some other
unit of analysis. There are a variety of standardized
procedures which a social scientist follows to deal with
this problem but no general language that I know of has
implemented them. Another problem has to do with a
variety of farily common transformations which social
scientists apply to their variables but which do not
exist in the FORTRAN-type languages. Perhaps the
most common of these is what we call "recoding" of an
original measurement. This involves transforming the
original values of a variable into some arbitrary set of
new values, as when we want to collapse a continuoustype variable into one with a small number of values or
categories. Although these kinds of transformations
can be coded in a FORTRAN-type language, they can
frequently lead a fairly lengthy and repetitive program.
As we shall illustrate, a recoding operation in DataText stands in the same relationship to the necessary
FORTRAN steps as an algebraic formula in FORTRAN stands in relation to the necessary steps in a
machine language. The same can be said for a number
of other transformational capabilities commonly available in the more popular social science languages.
Finally, there are a number of other data processing
and routine clerical problems which are not easy to
handle without special languages. Included are full
labeling of variables and their values (or categories),
input of multiple-punch data, selecting or sampling
sub-sets of the input data, and controls to classify the
input data into an arbitrary number of sub-groups.
The earliest attempts to solve some of these problems
for the social scientists led to the development of
"canned" programs. By "canned" program I mean one
written-usually in FORTRAN-to perform a particular statistical analysis, but written so that it can be
used over and over again by different researchers with
different data. A user prepares "control" or "parameter" cards which specify the necessary information
about his data (e.g., number of variables) and any
options which are available; the control cards are used
by the program to read in the data properly and to
produce the desired results. Canned programs are still
used widely by social scientists today, and for some
applications canned programs continue to be the most
efficient computational solution.
As canned programs became a popular method of
computer analysis, collections or "packages" were put
together at various locations (usually university research centers) and distributed to researchers at other
locations. The oldest, most well-known and widely used
of these collections is the BMD series, started by Dixon
and his associates at UCLA.3 The BMD collection for
the IBM System/360 contains over 40 programs for
almost every type of standard statistical analysis found
in applied statistics textbooks. Another collection for
the IBM System/360 is the OSIRIS package. 4 Developed at the University of Michigan, OSIRIS represents a significant advance in that the canned programs
are "integrated" into one large system which recognizes
a "standardized" data file. A file of data can be described and then any number of different statistical
routines can be requested which use that file.
The canned program approach still leaves many
problems unsolved for the social scientist. While canned
programs have largely solved the problem of knowing
complicated statistical algorithms, little relief is gained
for the many other data processing problems which I
have mentioned (special transformations, missing observations, labeling, and the like). Moreover, two new
problems have surfaced. Both of these problems result
from the fact that most canned program developers are
not professional programmers, and therefore they are
usually more interested in the statistical algorithm than
in program elegance.
The Data-Text System
The first problem is that all kinds of arbitrary restrictions are placed upon various parameters in the
problem-the number of variables allowed, the number
of subjects, the number of values or categories of variables, the number of analyses, etc. I wonder how many
hundreds of researchers have had a 110-variable factor
analysis problem with a program which would accept
only 100 variables; or a cross-tabulation requiring 60
cells with a program limited to 50? This would be like
a FORTRAN programmer being limited to a total of
5 DO-loops or to arbitrary subscript limits of 50. Of
course, any language has some limitations, but all good
compilers do dynamic core allocation so that limits are
encountered only when available memory is exhausted.
Most canned program limits are due to programmer
short-cuts such as fixed dimension statements.
Second, little effort is given to making the control
cards "readable" to the analyst in the sense that
FORTRAN is readable to a programmer. Most control
cards consist of arbitrary numeric codes in fixed-format
positions. It is practically impossible to remember the
set-up procedures from one run to another without
a program write-up literally in front of you. For the
data analysts, having to "read" these control cards is
somewhat analogous to a FORTRAN programmer
having to read a hexadecimal dump in order to interpret
the steps in his program.
THE DATA-TEXT SYSTEM
The Data-Text system was designed to solve some
of these problems and limitations of the package approach. Data-Text is designed to be a "natural" language for the social scientist, just as FORTRAN is a
natural language for those familiar with mathematical
expressions. In this sense, I think Data-Text represents
a further stage in the evolution of "problem-oriented"
computer languages. With Data-Text, the social scientist can request complex data analyses as easily as the
engineer can write complex formulas in FORTRAN.
The first version of the Data-Text system was designed
by Couch and others for the IBM 7090/94 series, and
it became operational in 1963-64. 5 This version became
widely used at more than 20 universities and research
centers during the middle 1960s. A substantially revised version of Data-Text has been designed and programmed for third generation computers and a version
for the IBM System/360 series became operational in
the spring of 1971.*
* The original Data-Text system was supported by grants from
the National Science Foundation (# GS287 & GS1424). The
revised Data-Text system was made possible by a grant from the
National Institutes for Mental Health (#MH15884) and by
donated computer time from the Harvard Computing Center.
335
It should be mentioned that in the latter part of the
1960s other computer systems with similar design
goals appeared. One example is the Statistical Package
for the Social Sciences (SPSS), created by Nie and his
associates at Stanford University and the University of
Chicago. 6 Other social scientists have begun experimenting with interactive (or "time-sharing") data
analysis systems, such as Meyers' IMPRESS system at
Dartmouth College,7 Miller's DATANAL system at
Stanford,s the ADM INS system at MIT,9 Shure's
TRACE system at SCD and UCLA,1O the Brooking's
Institution BEAST,!! and Kuh's TROLL system. 12
The unique aspects of the Data-Text system in relation to other computer systems is its ability to handle
very complicated data processing problems and extremely intricate statistical analyses with a minimum
of technical knowledge about the computer and a
minimum of familiarity with statistical formulas and
algorithms. The requirements for a user are: (1) that
he have a concrete research problem which demands a
standard statistical analysis of data; (2) that the data
are recorded in some systematic format on IBM
punched cards (or certain other media, such as magnetic tape or disc); (3) that he understands the type of
statistical analysis required for his problem; and (4)
that he knows the names· of the appropriate statistical
analysis procedures. Given such a situation, Data-Text
can be used for defining or transforming input variables,
for giving them appropriate descriptive labels, and for
requesting a great variety of different statistical analyses. The variable definitions and statistical analysis requests are made in a flexible, easy-to-learn "natural"
language which makes heavy use of terms familiar to
most social science researchers. Data processing features
include automatic missing observation procedures, input and manipulation of multipunched data, subgrouping controls, and many others.
A sample of the Data-Text language is probably the
easiest way to introduce this idea and to show how
Data-Te){t differs from FORTRAN-type languages.
Assume that a researcher has collected data from a
group of several hundred college students (the actual
number is not important). The data might include
measurements of age, sex, race, father's education,
family income, college class, an ability test score, expected work after college, several yes-no questions regarding current political-social issues, and a series of
questions about school activities. We will assume that
the non-numeric measures (for example, sex) have been
given codes of some kind (for example, 0 for male, 1 for
female) and that the data has been punched onto IBM
cards with two cards for each person. The Data-Text
instructions shown in Figure 1 define the set of original
variables, derive some new variables as transformations
336
Spring Joint Computer Conference, 1972
Col. 1
Col. 80
*DECK COLLEGE STUDENT STUDY
*READ CARDS
*CARD(1-2)FORMAT / UNIT =COL(1-4},CARD =COL(5)
*AGE =
COL( 5- 6/1)
= AGE OF STUDENT
*SEX =
COL( 7/1)
= STUDENT'S SEX(O = MALE/1 = FEMALE)
*RACE=
ACOL( 8/1)
= RACIAL BACKGROUND(B=BLACK/W=WHITE/O=OTHER)
*INCOME=
COL(10-14/1)
= FAMILY INCOME
*CLASS =
COL(15/1)
= COLLEGE CLASS(l =FRESH/2 =SOPH/3 =JUNIOR/4 = SENIOR)
*ABILITY =
COL(27-28/1)
=SCHOLASTIC APTITUDE TEST
*ITEM(1-4) =
COL(31-34(4)/1) = WILLING TO BE DRAFTED (1 = YES/2 =NO)/
*
APPROVE OF SDS POLICIESO/
*
LIKE NIXONO/
*
LIKE AGNEWO
*ACTIVITY(1-50) = COL(6-55(50)/2) = SCHOOL ACTIVITIES(0=NO/1 = YES)
*VAR (1)=
COL( 9/1)
= FATHER'S EDUCATION(1=SOME HS/2=HS/3=SOME COLLI
*
4=BA/5=BEYOND BA)
*VAR (2) =
COL(21/1)
= FUTURE PLANS (0 = GRAD SCHOOL/1 = PROF SCHOOL/
*
2 =BUSINESS/3 =TEACHING/4 = OTHER/
*
5=DON'T KNOW)
MEAN ITEM(1,3-4) = PRO-ESTABLISHMENT SCALE
*VAR(3) =
*INDEX=
SUM ACTIVITY(1-50) = ACTIVITIES INDEX
*VAR(4) =
1 IF VAR(1) =4,5 AND INCOME GREATER THAN 20000 = SOCIAL CLASS INDEX
*
(1 =UPPER/2 =MIDDLE/3 = LOWER)
*OR =
3 IF VAR(l) = 1,2 AND INCOME LESS THAN 10000
*OR=
2
RECODE(A) VAR(2) = FUTURE PLANS lI(l =SCHOOL/2 = WORK)
*VAR(5) =
*CODE(A) =
(0,1 =1/2-4=2/5 = BLANK)
*VAR(6) =
(ABILITY / AGE) *100 = AGE-GRADED ABILITY
*CHANGE(1-10) = POSTEST(l-lO) - PRETEST(1-10)
*WRITE DATATEXT DISC 4
*COMPUTE STATISTICS(AGE, INCOME, ITEM, VAR(6», SKEW
*COMPUTE T-TESTS(ABILITY, VAR(3», GROUP BY SEX
*COMPUTE FREQUENCIES
*COMPUTE CORRELATIONS(ACTIVITY), TEST
*COMPUTE CROSSTABS(VAR(2), ITEM BY SEX, RACE, CLASS), CHI SQUARE
*COMPUTE REGRESSION(ABILITY ON AGE, SEX, VAR(l), INCOME), GROUP BY CLASS
*COMPUTE ANOVA(SEX BY RACE BY VAR(4», ABILITY
*START
*
*
*
*
*
*
*
Figure I-A sample data-text program
of the original set, and request several types of statistical analyses. (In many cases these instructions are
punched onto IBM cards, one instruction per card. In
other instances, they might be lines typed at a remote
typewriter console.)
The instructions fall into several types. The instruction
*DECK COLLEGE STUDENT STUDY
is a header instruction which signifies the start of a set
of Data-Text instructions and which provides a title
that will appear on every page of computer print-out.
The next two instructions relate to I/O operations:
*READ CARDS
*CARD(1-2)FORMAT/UNIT=COL(1-4),
CARD=COL(5)
The READ identifies the mode of data input (punched
cards), while the FORMAT provides information
about the number of cards per student and some
special identification fields. The term CARD (1-2)
indicates 2 cards per subject; the term UNIT refers to
a field in each card for identifying the unit of analysis
(such as a subject number); the term CARD refers to
a field for identifying the different data cards for each
UNIT. Thus, this example indicates two cards per
UNIT, a subject number in columns 1 to 4 of each
card, and a card number in column 5. Although there
is some syntactic similarity to FORTRAN in these two
instructions, their effect is quite different. First, no
looping controls are required around the READ instruction; all data cards will be processed automatically
according to the other operations specified in the program.* Second, the FOR1VIAT instruction in this ex* A special *SELECT ... IF instruction is available for selecting
sub-sets of the data file; see Figure 2.
The Data-Text System
ample only provides information about the number of
cards per subject and the identification fields; variable
fields are defined in separate instructions. Moreover, if
the UNIT and CARD fields are specified as in the
example, the cards for each subject are automatically
checked for consistent subject numbers and card sequence (taking the first subject as the prototype).
These checking operations are extremely important for
some of the large-scale survey research studies.
The next set of instructions define the variables to be
used in the statistical analysis requests. For example,
the instruction
*SEX= COL(7/1)
= STUDENT'S SEX(O=MALE/l=FEMALE)
defines a variable named SEX which appears in column
7 of card 1 for each subject. It also gives a user-supplied
descriptive label and, within the parentheses, it describes the values actually punched in column 7 and
relates them to user-supplied category labels (e.g., 0 =
MALE means that O's were punched to represent
males). The ability to specify labels and values enables
an analyst to construct a true "machine readable" codebook for his data set. Moreover, the use of the variable
and category labels is not confined to the instruction
listing; they are also used in all computer print-out of
statistical results which use the variables and/or their
categories.
Alphabetic-coded variables can be indicated by preceding the COL-specification with the letter "A":
*RACE=ACOL(8/1)
=RACIAL BACKGROUND
(B=BLACK/W=WHITE/O=OTHER)
This definition indicates a variable which was coded in
column 8 with the letter values B, W, and O.
Entire arrays of variables can also be defined without
the use of explicit looping controls, as in the example
*ACTIVITY (1-50) = COL (6-55 (50) /2)
=SCHOOL ACTIVITIES
(O=NO/l= YES)
In this case the variable and value descriptions will
apply to all 50 variables in the array. The example
*ITEM ( 1-4) shows how several variables can be defined with the same value descriptions but different
variable labels.
The example in Figure 1 illustrates several of the
special transformation capabilities of Data-Text. While
the logical and arithmetic transformations used to
create VAR( 4) and VAR(6) resemble those available
in most" languages, the special functions MEAN, SUM
and RECODE used in defining VAR(3), INDEX, and
VAR (5) are unique. The MEAN and SUM are "sum-
337
mary" functions which operate across the variables for
a given subject, so that an average score (for the
MEAN) and a count (for the SUM) are derived for
each subject in the sample. Again, no looping controls
are necessary for these operations.
The RECODE function embodies a great deal of
power. It works in conjunction with a code statement
(*CODE(A) in the example) which specifies the recoding equations. Each equation consists of a series of
original values together with the new value they are to
be assigned in the transformed variable. Thus, only two
instructions are required to transform one set of values
into any combination of new values. Although this
kind of operation is programmable in FORTRAN, it
requires a great many assignment, IF and GO TO
statements.
One of the equations in the *CODE statement is
5 = BLANK. The term BLANK is a special constant
in Data-Text which denotes a missing observation.
This means that a subject with a score of 5 in VAR(2)
will be treated as missing in VAR (5). BLANK value8
are automatically assigned to variables for subjects
with blank columns in the input data fields. That is, if
columns 5 and 6 in card 1 are blank for a given subject,
then a BLANK value is automatically assigned to the
AGE variable for that case. Regardless of where
BLANK values come from, they are handled automatically in all transfomation and statistical routines. A
series of default rules exist which are appropriate to the
type of transformation or the type of statistical procedure. For example, BLANK's are ignored by the
MEAN function in the VAR(3) instruction, so that
the average is taken only of non-BLANK values. In the
VAR(6) instruction, however, which uses a regular
arithmetic expression, the opposite is true: if either of
the arguments ABILITY or AGE is BLANK for a subject, then the result is BLANK. In most of the statistical routines indicated by the COMPUTE instructions,
the default is to ignore BLANK values; but options
exist which will do other things (like excluding a subj ect
from the analysis if any variable has a BLANK value) .
This automatic processing of missing observations has
proved to be an extremely valuable feature in social
science applications.
Before turning to the statistical controls, another instruction should be noted. The instruction
*CHANGE(I-10) =POSTEST(I-10)
-PRETEST(l-lO)
illustrates what we call a "list" expression. The subtraction operator is applied element-wise to the two
argument lists, so that each variable in the CHANGE
array is the difference between the POSTEST and
PRETEST variable in the corresponding list position.
338
Spring Joint Computer Conference, 1972
*DECK COLLEGE STUDENT STUDY-SECOND RUN
*READ DATATEXT DISC 4
*LEVEL =ORDER ABILITY = ABILITY LEVEL(0-9 =LOW /10-24 = MIDDLE/OVER 24 =HIGH)
*SELECT UNIT IF SEX = 0
*COMPUTE CROSSTABS(LEVEL BY RACE, CLASS), CHI SQUARE
*START
Figure 2-Using a data-text file
Lists of variables can be combined into any arbitrary
arithmetic expression, and the expression is evaluated
for each element in the list. This provides a very powerful transformational ability without the necessity of
looping controls.
The COMPUTE instructions are commands for
statistical analyses on the variables defined in the preceding instructions. The statistical procedure is requested by name, such as T-TEST or CROSSTAB or
CORRELATION. Generally speaking, the only parameters required are the lists of variables to be included in the analysis and any special options which are
desired. The instruction
*COMPUTE STATISTICS(AGE, INCOME,
ITEM, VAR(6)), SKEW
will compute means, standard deviations, and the
number of nonmissing observations for each variable in
the list across the whole sample of students; the option
SKEW will also cause a measure of skewness to be
computed. The instruction
*COMPUTE CORRELATIONS(ACTIVITY),
TEST
will cause a 50 by 50 matrix of product-moment correlations to be computed for the array ACTIVITY(1-50),
and the TEST option will result in a statistical test of
significance for each correlation.
While there is some resemblance here between the
COMPUTE instruction and a subroutine call in many
languages, the analogy cannot be pushed too far. First,
the "arguments" include reference only to the variable
names and not to the many other quantities and arrays
which are used by the routine, such as variable labels,
value description, number of categories, and so forth.
Second, and more important, some of the statistical
requests have special key words embedded in the variable list which must be encoded by a special compiler
tailored to each statistical procedure.
For example, in the instruction
*COMPUTE REGRESSION (ABILITY ON AGE,
SEX, VAR(l), INCOME),
GROUP BY CLASS
the key word ON indicates the independent variables
(AGE, SEX, VAR(l), INCOME) on which the dependent variable (ABILITY) is. to be regressed. The
G ROUP option indicates the analysis is to be carried
out on the four college class subgroups defined by the
CLASS variable. In the COMPUTE ANOVA Instruction, *
*COMPUTE ANOVA(SEX BY RACE BY
VAR( 4)), ABILITY
the key word BY indicates a 3-way factorial analysis
of variance design with ABILITY as the dependent or
criterion measure. In other words, the COJ\1PUTE
instructions are also expressed in a natural language
which contain operators and a syntax meaningful to
each particular analysis.
All of the statistical routines are almost literally
without limitations. Correlation matrices are not
limited to available core; a cross-tabulation can be
n-ways, with no limit to n; a variable used for classification purposes in a cross-tabulation, an anova, or in
the GROUP BY option can have any number of categories; and if all the analyses requested will not fit in
available core, the data is automatically saved in internal form so that repeated passes can be made over
the data to satisfy all the requests. These features reduce the frustrations often encountered with other
statistical packages which have established arbitrary
parameter limitations.
It is rarely the case that an analyst will obtain all of
his statistical results in a single run. Sometimes the
same data set will be analyzed several dozen times.
Data-Text offers a method for saving all of the defined
variables, labels, and data in a standardized binary
file. Since no compilation, transformation, and data
conversion needs to be done, the time required to
process this file is substantially less than the time it
takes to process the original raw data. * In our sample
program, the instruction
*WRITE DATATEXT DISC 4
creates a standardi~ed file for this set of data.
Input of a DATATEXT file does not preclude the
use of the full transformational language. New vari* The term ANOV A is a fairly standard abbreviation for "analysis
of variance."
* The savings range from 50 percent to 90 percent of CPU time,
depending upon the size of the data file (the larger the file, the
greater the savings).
The Data-Text System
339
NI"H DRUG STUDY OAT A
NIMH DRUG STUDV DATA
LISTING OF CONTROL
CA~DS
*OECK
NIMH DRUG STUDY DATA
"REAO CARDS
"CARD fORMAT/ UNIT= COL< 1-4). CARD= COL< 5-6)
T>lU-WAY STATISTIC5 fO~ RATING!I)
*"
"* SYMPTOMS (1-14) ARE PRE-TREAT~ENT ~ATlNGS OF SCHIZOPHRENIC SYMPTOMS.
"" THEIR RANGES ARE FROM 1-8 TO 1-4S. WHERE A HIGH SCORE INDICATES A MORE
. . SEVERE RATING.
t-1ALt
DRUG
4
5
6
7
8
9
10
11
IZ
13
14
15
16
11
"SYMPTOM (!)
"SYMPTOM (2)
"SYMPTOM (3)
"SYMPTOM (4)
"SYMPTOM (S)
"SYMPTOM (6)
"SYMPTOM (7)
"SYMPTOM (8)
"SYMPTOM (9)
"SYMPTOM (10)
"SYMPTOM (11)
"SYMPTOM (lZ)
"SYMPTOM (13)
"SYMPTOM (14)
=
=
=
=
=
COLl7-8)
=
COLl9-10) =
COLlll-IZ)=
COL< 13-14) =
COLl IS-16) =
COLl 17-18) =
COL< 19-Z0) =
COL (ZI-Z2) =
COL (23-24) =
COLl2S-26) =
COL<27-28) =
COLl 29-30) =
COl( 31-32) =
COL (33-34) =
1
lJRUG TREATMENT
HOSTILITY
DISORIENTATION
GUILT
AUDITORY t'ALLUCINATION
AGITATION
SLOWED SPEECH
DELUSIONS OF GRANDEUR
INDIFFERENCE
INCOHERENT SPEECH
PRESSURE OF SPEECH
PERSECUTION
HEIlEPHRENIC
NON-AUDITORY HALLUC IN.
MEMORY DEFECT
PLACEt:lO
MEAN
CHLORPRO.
',EAN
20
21
22
23
24
2S
26
27
28
""
"ILLNESS(!)=
"ILLNESS(2)=
n."29
5iJ
34.000
FLUPHEN.
THIORID.
THAT A 7 MEANS MOST IMPROVED
(I-7=RANGE)
"RATlNG(2) =
8-COL(56) = IMPROVEMENT--NURSES
(I-7=RANGE)
"DRUG = COLlS7)= DRUG TREATMENT (I=PLACEBO/2=CHLORPRO./3=FLUPHEN./4=THIORID.)
"SEX
= COL91
33.uOO
RO"
MAR('INALS
I
I
I
I
I
I
4.-'0b
-0.763
I
5.903 I
00143 I
0.901; I
31.000 I
5.702
0.032
I
>1£AN
SI)
5.Btl9
-0.077
0.979
310.000
,·'E.A,'J
EFFECT
S,l
"
5.931<
-').04"
0.'114
32.000
0.-.06 I
33.(01) I
MEA'"
EFFECT
':>.610
-0.0S-.
S.72'l I
0.0"9 I
EFFECT
COLlSO)= DOCTORS ILLNESS RATING (I-7=RANGE)
COLlS4)= NURSES
ILLNESS RATING (I-7=RANGE)
""
"" THE IMPROVEMENT RATINGS ARE TRANSFORMED SO
""
"RATlNG(Jl=
8-COL(52)= IMPROVEMENT--DOCTORS
'>. '>0['
-ro.143
EFfECT
"" THE FOLLOWING TWO VARIABLES ARE PRE-TREATMENT RATINGS OF OVER-ALL
"" ILLNESS.
THE V ARE SCORED SO THAT A 7 MEANS MOST SICK
18
19
Sol i:>
0.2/)/1
1.107
26.000
EFFECT
Su
H.MALE
2
b.lbl I
u.077 I
0.8;>0 I
31.uOO I
I
6.152 I
b.02':>
0.356
6.0,+5
fJ .375
O.041l I
-----------------------------------------------------1----------J
COLUMN MARGINALS
':>.669
MA~GINALS A~E U"'wEIGHTED AVE~AGE" OF CELL MEANS.
Figure 3-Sample output from a data-text run
Figure 3c
abIes can be derived from existing variables just as in
a regular run. Figure 2 shows a run using the DATATEXT file created in the first example. A new variable,
LEVEL, is derived by collapsing the existing variable
ABILIT Y using the special collapsing function
ORDER. Some new cross-tabulations are requested,
and the SELECT instruction will restrict processing to
the sub-group of males. It is clear from this example
that using a DATATEXT file results in a much shorter
and simpler program.
As I have noted, the use of labeling specifications
illustrated in Figures 1 and 2 is not confined to a program listing. All of the Data-Text statistical routines
use the labels to produce readable output. Since the
sample programs were hypothetical, we cannot show
output for them. However, Figure 3 illustrates partial
output from an actual run using real data. The DataText program which defines the variables and requests
the analyses is shown on the first page of output. * The
remaining pages show the output resulting from the
STATISTICS and ANOVA instructions.
NIMH DRUG STUDY DATA
BASIC STATISTICS
VARIABLE DESCRIPTION
NAME
HOSTILITY
DISORIENTATION
GUILT
AUDITORY HALLUCINATION
AGITATION
SLOWED SPEECH
DELUSIONS OF GRANDEUR
INDIFFERENCE
INCOHERENT SPEECH
PRESSURE OF SPEECH
PERSECUTION
HEBEPHRENIC
NON-AUDITORY HALLUCIN.
MEMORY DEFECT
DOCTORS ILLNESS RATING
NURSES
ILLNESS RATING
IMPROVEMENT --DOCTORS
IMPROVEMENT--NURSES
DRUG TREATMENT
SYMPTOM (1)
SYMPTOM(2)
SYMPTOM(3)
SYMPTOM (4)
SYMPTOM(S)
SYMPTOM(6)
SYMPTOM(7)
SYMPTOM(8)
SYMPTOM (9)
SYMPTOMtential remains. The trade-offs are between speeds of logic and
speeds of memory.
346
Spring Joint Computer Conference, 1972
Interaction Among
Availability:
Costs,
Task
Management
and
The Era of Multi-processors
1. Costs-At any technological point in time, there
is an optimum processor size. The old rule that
"bigger and faster" means "greater performance
per dollar" does not hold over all combinations
of conditions. In fact, at the high-power end of
the spectrum today, cost approaches a linear
relation with computing power.
2. Task Management and Software-Some features
of programming systems can be simplified, if the
speeds of processors and data storage devices can
be brought closer together. If no more CPU resource is wasted by allowing the CPU to idle
during a file read than would be consumed in
overhead by task-switching, then it is preferable
to let the processor idle-because of the potential
reduction of time spent writing and debugging
both operating systems and application programs. One way to approach this condition is to
parallel-process with "slow" CPU's rather than
single-process with a "fast" one. For example,
a I-million instructions per second (MIPS)
processor executing 10,000 instructions per file
access would be wasting only 10 percent of its
time if it waited for a one millisecond average
access time device, while a 5 MIPS processor
idling during reading the same device would
waste 50 percent of its time. In the past, we have
multiprogrammed the "fast" CPU's to avoid
waste because CPU costs were non-linear with
speed. We have conserved CPU power by programming effort, but it may be time to reverse
those factors, and multi-process instead.
3. Availability-Availability can be brought to any
given level (excluding perfect!) by increasing
the level of multi-processing.
Also, there will be workloads beyond the capacity of
any processor that we will ever build; at this point,
multiprocessing becomes a requirement, not an option.
Of course, the processors might be packaged together
under one cover; on the other hand, it might be prudent
to separate them geographically to prevent nonhardware-caused reliability problems.
Software/firmware/hardware trade-offs-We hardly
need to be reminded that micro-programming techniques will be important, and they are already widely
accepted. LSI projections further enhance these techniques, particularly in writable control stores which
offer greater flexibility. Many functions in teleprocess-
ing systems today are handled by software, e.g., line
control, bit handling, etc., but performance often warrants hardware solutions. Higher-level control programs
and language programs in hardware or software become
more realistic. 13 This will be the direction as the industry matures.
Extension of computer usage
There are a number of not necessarily independent
ways in which LSI will extend the use of CPU's and
memory:
• Broadening the user base in conventional areas.
• Extending small machine with large machine
functions.
• Providing new and additional functions.
• Providing universality, standardization, flexibility.
• Meeting new performance criteria.
• Opening new application areas.
There is evidence of each of these today. Broadening
the user base in conventional areas simply implies
selling more systems to more users for established applications, usually at the small end of the line. More
interesting is the addition of typicaJly larger-machine
functions to smaller machines,4,5,8,10 e.g., more sophisticated instructions, memory protection, instruction
retry. Such features could add an order of magnitude
in logic and memory to today's small systems.
Adding function to existing systems is conceptually
an extension of the aforementioned. For example, function will be directed at improving data acquisition and
use, at extending the ability of a system to self-diagnose
and reconfigure, at providing communications functions and security, or at converting current software
functions. Clearly, this is an open-ended category and
suggests the basis for many times present hardware
levels.
Meeting new performance criteria, we believe, means
placing higher priority on response time, availability,
ease of installation and use-rather than on throughput.
These objectives will require new approaches, and more
logic and memory can profitably be put to use in their
pursuit.
New application areas will be developed. However,
there are many applications which are presently on the
shelf because of either time or economic reasons. It is
already apparent that environmental monitoring and
control is an important area for development. Attempts
at "duplicating" human function, e.g., constructing
capable robots, will undoubtedly consume much circuitry. These today are analog functions and require
LSI
two to three orders of magnitude more components
when done digitally. Still, it is becoming more and more
economical to digitize, and examples are well-known in
the data transmission area. Other known areas such as
pattern and speech recognition will consume extensive
hardware when we exploit them to their fullest.
In the next section we will use a specific system,
namely, a highly interactive data processing system, to
illustrate the impact of LSI technology.
A HIGHLY INTERACTIVE TELEPROCESSING
(TP) SYSTEM
One motivation for looking at this system is that we
believe that ultimately there will be very large systems
serving tens of thousands of users. The users will be
indifferent and largely oblivious to the fact that they
are using a computer system. They probably won't
even call their terminals "terminals"; names such as
"fact-finder," "stockinfo," and "smart mart" are more
likely. In particular, these people will probably not be
programmers, mathematicians, engineers, scientists, or
accountants. Their applications will be logically
trivial-at least from a systems person's point of view.
What we today might expect to be a command language
will be the jargon of their particular environment, and
they will be largely innocent about how the data they
reference was acquired or is organized.
The interesting features of the system are that (1)
there will be a very high traffic rate, (2) the traffic will
have to do mainly with references to or updates of a
Terminal
Controllers
Line
Handlers
File
Central
Processors
File
Terminals
I
Communications Network
I
Central Server
Figure 2-Schematic of interactive system
347
data base, and (3) response to an inquiry will have to
be within no more than 1-2 seconds to satisfy the users
psychologically. The terminals might be displays, keyboards, badge readers, etc.-with or without "intelligence." A high degree of reliability will be required,
and we will not want to manually reprogram each such
system for each environment. Airline reservations systems are a current example of such systems, but other
systems of even larger size are destined for such areas
as the financial, securities, and retail industries.
We postulate here an example of a hypothetical,
highly interactive system for further discussion-in
terms of potential LSI impact. The system is to have
10,000 terminals, and performance requirements are
as follows:
Peak Message Rate
Simple Inquiry
Simple Update
Complex Inquiry and
Update
Data Base
Response Time (Simple
Inquiry and Update)
Availability
200 msgs/sec.
30 percent
50 percent
20 percent
10 billion bytes
1-2 sec.
1 failure/day with
2 min. recovery.
(In a real case, there should be additional qualifications on availability and recoverability.)
Some provision must be made for batch processing.
Also, we have to look at data integrity, security, ease
of installation, provision for growth and change, provision for on-line evaluation, etc.-each an area where
hardware additions could contribute improvements.
Figure 2 illustrates the principal functions as we will
describe them. Relating to current-day techniques, the
peak load assigned to the central server can be projected to be the following:
Messages/sec.
File Accesses/sec.
I/O Instructions/sec.
TP Access, Instructions/sec.
Instructions/sec. Total
200
1000
2.5X106
1.5X106
5X106
For the purposes of this illustration, we assume that
the configuration, in contemporary terms, uses four
processors of the type described in Table II, plus two
stand-by/batch processors (one might use fewer, but
larger, processors). Using other component prices from
reference sourcesll and our previous assumptions about
changes in costs, we compute the cost comparison
change shown in Table IV.
348
Spring Joint Computer Conference, 1972
TABLE IV-A HypotheticallO,OOO-Terminal Configuration
Cost Units*
Circa 1970
Terminals (10,000)
Lines and Modems
Multiplexors
CPU Processor(s)
59
6
Cost Units*
Late '70's
20
60%
4
12
2
6
1
7
Channels, etc.
Main Memory
3
4
Bulk Memory
7)
1
.3
Files
Other
10
3
100 Units
* Units:
5
2
,,-,33 Units
15
6
100%
Equivalent to percentage of Circa 1970 costs.
Perhaps the most conspicuous feature of Table IV
is the dominance of terminal costs. Secondly, perhaps,
is the relative disappearance of the main and bulk
memory costs. Next is the relatively small proportion
of costs dedicated to transmission.
While the configuration assumed does not exist, it is
at least realistic in the 1970 time frame, with some
performance compromises. It is somewhat similar to an
airlines reservation configuration in terms of the geographic assumptions made. The degree of terminal
clustering achievable, relative to line requirements,
makes it possible today to keep the percentage of transmission costs modest. However, it is assumed that line
costs will not go down in cost as fast as the other components, and thus could constitute a higher percentage
of costs-an opportunity for LSI to provide further
concentration.
Even at the relatively low function level of 1200
logic gates per terminal, there is on the order of ten
times as much cumulative logic at the terminals as at
the central facility-and even more than 10 times as
much memory if we use semiconductor storage at a display terminal for refresh memory. Clearly, it would be
easy to increase these ratios significantly-if additional
hardware at terminals could be utilized productively.
Just as important is the fact that with terminals
dominating costs, and with logic and memory costs
decreasing anyway, it will be less painful to add more
function to the central facilities in support of systems
which are more responsive and easier to install, use, and
maintain. Of particular note here, again referring to
Table IV, is the fact that the cost of a 20-fold increase
in the size of main (and bulk) storage in the late 70's
would still be possible within the indicated 1970 prices.
Figure 3 shows the response time breakdown that we
would expect today, given a two-to-six second response
time range and assuming relatively simple inquiry and
update applications and moderate loading conditions.
(The more conventional implementations would probably not achieve the one-to-two second response times
we have postulated.)
The polling delay is half of the average polling cycle,
initiated from the concentrator. The delays on the
transmission lines are due to line speeds, message
lengths, and queued waiting for the lines. Actual time
delays in transmission are relatively negligible. Concentrator delays are principally queueing delays, with
actual processing times in the 10 to 100 ms range.
Central processing times are also mainly waiting times,
particularly waits for file access, but also for channels
and for processor service. Again, tens or hundreds of
milliseconds are the range of actual processing times
needed, subject, of course, to the processors' speed and
the job to be processed.
I t should be clear that these times are satisfactory
for many applications; however, our contention is that
a substantial segment of the potential user community
will want response times in the one or two second range,
or perhaps faster, at least for simple inquiry-update
messages.
Design for the late 70's
Most systems used for interactive requirements today have been built upon batch systems. There have
been attempts to achieve good throughput with acceptable response times. On this base, we are now
adding more sophisticated user-oriented functions, in
the area of data management, for example. In the
future we must do more. The question is: "How far can
we continue to build up the processing requirements on
File
Controller
Communications
....,1
. .-
-
-
-
Data
Management
Percent Response Time-------+t.
Figure 3-Factors in response time
1
LSI
the present base, and maintain, much less reduce,
response times?" 11 We believe there are significant
changes possible based upon the advances in LSI
technology.
Present systems attempt to conserve processor resources. As we have said before, multiprogramming
lets us use the processor while it would have been
otherwise waiting on file accesses. Many-terminal systems, airlines for example, require us to maintain many
messages active in the CPU concurrently, up to 50 in
some systems. Caring for these messages is complex,
and it is this type of complexity that causes much of
the problems of installability, maintainability, etc. 12 In
the future, processors, including memory, do not need
to be conserved to the same degree.
LSI opens new possibilities which we could not consider in the past, particularly if we can appropriately
partition the data bases (as we can in some environments today) . We can bring the CPU speeds and random access speeds into better balance, we can afford to
let the CPU idle during file reads and reduce the software and system complexity. The path to arriving at
the balance appears to embrace (1) keeping the CPU
suitably slow, (2) making direct access storage suitably
fast, and (3) paralleling CPU's and direct access devices
sufficiently to absorb traffic. In an environment where
cost is nearly linear with CPU power, we can make the
choice of reducing complexity at no cost, and into the
bargain get increased reliability and perhaps improved
Checkpoint
Line
Handlers
CPU
Batch/Standby
CPU
Batch/Standby
CPU
Satell ite
Message
Processor
Switchable to any CPU position
Figure 4-A central server configuration for a highly
interactive system
349
security. Conceptually such a system might look like
Figure 4.
Communications processing
The many functions relating to the handling of
input and output messages may give rise to separate
communication processors. The precise role of these
processors in the total teleprocessing picture, and particularly the interface to other central processing functions, has not been universally defined. In fact, the
communication processor function should be redefined
in the context of the total teleprocessing requirement,
including response times, to assure that there is no
unnecessary data handling, and that the communication processor does, in fact, efficiently complement the
central processors. Here LSI will permit us to build the
necessary buffers and other interface hardware to
afford a clean interface between the communications
functions and other processing requirements, thus reducing device dependence and improving interprocessor
communication.
Line attachment is another area where LSI will help.
This area includes the physical attachment, modem
functions, switching, i.e., functionally getting the information on and off lines and into and out of registers.
Interface standards (EIA) usually have to be met, a
variety of line speeds accommodated, and, often, provisions must be made for using the dial telephone
network.
At the line end of the communications processor, we
have a choice between hardware and software. The
10,000 terminals, for example, will require many connections-and in the past this would have been very
expensive. This would have been particularly true if we
had implemented sophisticated equalization equipment
as well as the other modem functions digitally. On the
other hand, done strictly with software, these functions
would require extensive processing and processing
times. Fast response time requirements and LSI costs
make hardware the clear choice.
LSI has also made another communication processor
design choice easier. Here, a writable control store
(WCS) approach gives the flexibility needed to exist
with the many variations found in practice, i.e., terminal and line types, line disciplines, formats, etc. When
communications processors must be ·fast, bipolar techniques can be used for the WCS-and perhaps for their
main memories as well.
The communications network
Communicating between the central site(s) and the
terminal in the many-terminal system can be a rela-
350
Spring Joint Computer Conference, 1972
tively expensive proposition but in most cases it need
not be. In the example of Table IV, it will be about
12 percent of the cost. This is a function of the distribution of terminals-and since in most applications
terminals tend to be clustered, there is the opportunity
for the terminals to share fewer transmission lines.
This enables us either to use lower speed communications lines more effectively or to afford to use a broader
transmission channel, where the potential costs per bit
transmitted are significantly lower.
Concentration of line sharing can take place in
several places, including the central site, intermediate
remote points, and multiple-terminal sites. Concentrators, since they amortize their costs over more than
one terminal, provide us with the opportunity to make
them far more sophisticated, and LSI will help us to
add the optimum amount of function. Functions
directed toward increased availability might take the
form of off-site processing capability, alternate path
routing, forward error correction and backup storage.
For our interactive teleprocessing example, the response
time requirement forces us to limit queues, particularly
on slow lines. LSI can help here by enabling us to extend
line capacity (through multilevel modem equalization,
error correction, etc.), or to speed up communications
processing. Again, we can under-utilize facilities more
economically to combat queue build-up.
Figure 3 shows a plausible breakdown of delays for
a 1970 configuration. (There are faster airline systems
but they are configured somewhat differently and are
otherwise specialized.) If we have a one-second response time objective, some reduction in nearly all of
the time components must be realized, but the use of
additional hardware for faster polling and message
processing makes the overall one-second response time
very reasonable.
tion, diagnostic ability, even self-repair, could be considered. Pre-processing, such as syntax checking and a
limited degree of local problem solving, is a natural
extension-continuing upward to significant standalone power.
To arrive at some idea of the level of logic complexity
addressed here, we list in Table V the rough number of
logic circuits (gates) and storage units (cells) associated with the various listed functions. (The reader
should realize that the numbers are highly variable,
subject to the particular application and the performance required. In addition, the functional hardware
requirements are not necessarily additive since there
mayor may not be sharing of hardware, and in the
more complex functions the option to perform them by
mixes of software and hardware is generally warranted. )
Hardware counts are rounded to the nearest 100.
Two of the more dynamic ranges in, Table V are
those of "Forward Error Correction" and the "Modem"
functions, which could include very sophisticated forward error correction techniques and automatic equalization. It is not difficult to envision the use of substantially more logic and memory in the terminal. For
example, if we add 10,000 circuits and 100,000 bits of
memory at the projected costs (and also increment
some of the other costs), the terminal will still be
cheaper than its 1970 forerunner.
LSI will afford us the opportunity to define and
economically design many functional interfaces. These
interfaces will enable us to design terminal controllers,
terminal I/O devices, and stand-alone terminals with
extensive functional modularity-and to do this without jeopardizing the low-cost single-terminal requirement. Likely interfaces include the line-modem interface, the modem-data link control (DLC) interface,
the DLC-terminal function-and eventually, the terminal I/O device interfaces. By choosing the appropriate
Terminal functions
TABLE V-Hardware Requirements of Typical Functions
With the assumption that LSI will enable us to expand terminal function significantly, what will it mean
for the future terminal? Clearly, the minimal function
of the terminal is its I/O: keyboard, printer, display,
etc.; the I/O control; the basic communication functions including code conversion, serial/parallel conversion, and parity checking. We can expand these
functions by adding character, line, and message
buffering; various modem functions; line control; security provisions. Further expansion could include local
user prompting, message format editing, header generation, and a variety of more sophisticated error control
and automatic retransmission features. Continuing
further, the high availability features of error correc-
Function
Basic I/O Control
Display Character Generation
(ROS)
Display Refresh (CRT)
Basic Communications Functions
Extended Line Control Functions
Forward Error Correction
"Modem" Function
Line and Message Buffering
Editing Functions
Calculator Functions
"Typical" Small Computer
Gates
Cells
100-200
<50
<50
1000-8000
<50
100-200
500-1000
400-20,000
200-10,000
<50
200-400
100-500
2000-4000
1000-25,000
<50
<50
4000-6000
100-10,000
200 & up
500-3000
500-3000
16,000-64,000
plus files
LSI
sub-function hardware modules, the controller is
tailored to suit the appropriate line, the number and
mix of terminal I/O devices, and other general functional requirements. Even within the smallest hardware module a degree of generality must exist which
supports the standard interfaces. However, as our cost
example illustrates, we can afford a significant increase
in logic or memory count before we have a substantial
increase in overall terminal cost.
SUMMARY
We have looked into the future of projected LSI logic
and memory costs. The implications to the industry are
dramatic. Without additional applications, the cost of
the hardware base is a fraction of the cost of today's
base. There will be an increased search for new applications and a change of emphasis on performance factors.
LSI will support an era of greater accommodation of
the user's desires, as opposed to forcing user conformity
to machine-and data processing will be extended to a
much larger user base.
Some important design and architecture trends are
motivated by the need to meet other than batch processing and throughput requirements-for example, response time, availability, installability, usability. LSI
will aid in establishing needed interfaces for both user
and manufacturer, support the evolution of multiple
processors, accelerate the use of firmware, and add
many new functions to systems, some converted from
software. It will not significantly restrict design freedom
if the part number generation costs are as low as
projected.
While LSI alone has not solved all problems, it has .
shifted the emphasis, changed the scale, enabled us to
do some things better. "Large" will become larger,
costs will be lower-and exploiting our new environment will be the major challenge.
351
REFERENCES
1 Large-scale integration perspectives
IEEE Computer Group-Computer Elements Technical
Committee, Computer Group News 2 #6 pp 24-32 1968
2 Computer memories in the seventies
Computer Elements Workshop Computer 14 #1 pp 58-59
1971
3 R NOYCE
Bob Noyce of Intel speaks out on the integrated circuit
industry
EDN IEEE 16 #18 pp 28-32 1971
4 M G SMITH
W A NOTZ
Large-scale integration from the user's point of view
AFIPS Fall Joint Computer Conference 31 pp 87-94 1966
5 M G SMITH W A NOTZ E SCHISCHA
Economic questions of systems implementation with large-scale
integration
IEEE Transactions on Computers C-18 #8 pp 690-6941969
6 M G SMITH
The terminal in the terminal-oriented system
Australian Computer Journal 2 #4 pp 160-165 1970
7 J E BRYDEN
Visual displays for computers
Computer Design 10 #10 pp 55-77 1971
8 R RICE
LSI and computer system architecture
Computer Design 9 #12 pp 57-63 1970
9 D L HOUSE R A HENZEL
Semiconductor memories and minicomputers
Computer 4 #2 pp 23-29 1971
10 W A NOTZ E SCHISCHA J L SMITH
M G SMITH
LSI-The effect on systems design
Electronics 40 #4 pp 130-141 1967
11 Auerbach computer technology reports
Auerbach Information Inc 1970
12 J MARTIN
Design of real-time computer systems
Prentice-Hall Publishing Company 1967
13 R RICE Vir R SMITH
SYMBOL-A major departure from classic
dominated von Neumann computer systems
software
AFIPS Spring Joint Computer Conference 38 pp 575-587
1971
The rationale for logic from semiconductor memory
by W. H. DAVIDOW
Signetics Memory Systems
Sunnyvale, California
INTRODUCTION
mented today are far more complex than the computers
which are deriving benefits from microprogrammed implementation. Some experts today are forecasting that
most complex logic systems of the future will use microprogrammed techniques for the same reasons that motivated computer designers to select this alternative.
In a general sense, any sequential logic device can be
viewed as transferring information from one set of
storage elements to another through a logic network.
In the case of a computer, the execution of an instruction involves a sequence of information transfers from
one register in the processor to another, some of which
take place directly and some through an adder or other
logical network. A machine or computer instruction is
made up of a number of these transfers which Wilkes
likened to a program and hence, he termed the individual steps microinstructions and the sequence of steps
a microprogram.
The mechanism Wilkes suggested for implementing
the system is shown in Figure 1. The microprogram was
held in a read-only diode memory or control store which
is shown as consisting of two matrices A and B. The
outputs of matrix A were used to control the transfers
between the various registers. The outputs from matrix
B were passed through a delay and were then used as
inputs to a decoding tree. These inputs to the decoding
tree directed the timing pulses to the next selected data
line in the control store. Information from the sign
flip-flop of the accumulator was used to select alternate
paths through matrix B and hence to change the next
selected data line in the memory. This is represented by
one of the lines from matrix A which branches before it
enters matrix B. The signals coming from matrix A
control arithmetic gates, register paths, etc. Wilkes
viewed these as incremental logical operations and
called them micro-operations. A collection of these
operations performed at one time was a microinstruction.
Wilkes' example segmented the microprogrammed
control into two parts-one for operating the gates
Memory is the LSI component which we know best
how to fabricate. Compared to other LSI (Large Scale
Integrated) circuits, it is almost "standard", and because of the regular interconnection patterns which
exist between memory cells, it can achieve very high
component densities and is relatively inexpensive to
make.
A product such as a 4096-bit Bipolar ROS (Read Only
Store) has some rather remarkable characteristics.
When used properly, it can:
1. Become the logical equivalent of about 500 gates.
2. Be packaged efficiently in small 16 and 24 pin
packages.
3. Dissipate about 1 lVIW per equivalent gating
function.
4. Be customized for about $1.50 per gating function.
These benefits can only be obtained by using new logic
design techniques which have not been extensively used
in the past. One of these techniques is microprogramming. A great deal has been written about this technique
but it has not really found wices}read application.
In this paper we will provide a brief introduction to
microprogramming and then show how this technique,
used in conjunction with semiconductor memory, can
greatly reduce the cost of the control portion of a digital
system.
INTRODUCTION TO MICROPROGRAMMING
The idea of microprogramming is normally attributed
to Wilkes. 1 His stated objective was to provide "a systematic alternative to the usual somewhat ad hoc procedure used for designing the control system of a digital
computer."2 Actually, many logic devices being imple-
353
354
Spring Joint Computer Conference, 1972
TABLE I-Microinstructions for simple machine
DECODING TREE
TIMING
PULSES
MATRIX A
MATRIX B
~----;!
---V
1
i
I
I
I
I 1 I
I l L 1-1-1II 1
1
D ELAyl
,-----;1
I
MEANING
i
i
MARM
MB RM
PCO
Gate MAR onto M bus
Gate MB R onto M bus
Gate PC onto 0 bus
lAD
Gate IA (instruction address) onto 0 bus
I
ACO
Gate AC onto 0 bus
W
Write MBR into memory
PLUS
OTS
MTS
ON E
SMAR
5MBR
SPC
SIR
SAC
Add
Gate
Gate
Gate
Gate
Gate
Gate
JMP
Jump to address in address field of microinstruction
JIFO
Jump to address in address field of microinstruction if AC = 0
JOPC
Jump to address of. OP code field
U
TO GATES IN
ARITHMETICAL
UNIT, ETC.
~
CODE
FROM SIGN FlIp·FLOP
OF ACCUMULATOR
Read memory into MBR
M bus
0 bus
M bus
0 bus
S bus
S bus
S bus
to 0 bus in adder and place on S bus
through adder to S bus
through adder to S bus
through adder to S bus and add one
into MAR
into MBR
into PC
Gate S bus into I R
Gate S bus into AC
Figure I-Wilkes' model of microprogrammed device
which control the data paths, and the other for selecting
the next step in the control sequence. Today all microprogrammed devices are organized in a similar fashion.
The essence of designing a good microprogrammed system is the selection of the proper strategies for data
paths and logic function control, as well as the implementation of the control sequence section.
Figure 2 shows a simplified computing element. In
reality it could be a word-organized single-address
stored program computer. In this over-simplified version, assume the control portion of the machine gen-
erates the signals shown in Table I. These signals are
called micro-operations. By combining these, instructions
can be generated. Assume further that the control
portion of the machine contains a ROS (Read Only
Store) and that words are read from the ROB under
the control of an address register. Words are read from
the ROB in sequence unless one of the Jump instructions
(JMP, JIFO or JOPC) is executed.
Figure 3 shows an example of a ROB instruction word
with the appropriate fields labeled. The symbolic
representations of the micro-operations are shown under
the fields in which they appear in the microinstruction
word. There are of course many different microinstruction formats. For example, the Interdata Mod IV or
Micro 810 computers use 16 bit formats, whereas systems such as the IBM 360/85 use 128 bit formats.
Figure 4 shows a microprogram in which the contents
of memory are added to the accumulator in the following
manner:
Line 1 The contents of the program counter are
transferred to the memory address register.
Line 2 The instruction is read from memory into
the memory buffer register.
Line 3 The instruction is transferred from the
memory buffer register to the instruction
register.
MEMORY
CONTROL
AC . ACCUMULATOR
JUMP
INSTRUCTION
ADDER
CONTROL
M'SUS
CONTROL
D BUS
CONTROL
SBUS
CONTROL
PCD
SMAR
lAD
5MBR
ACD
SPC
SIR
R
JMP
PLUS
MARM
W
JIFO
MTS
MBRM
JOPC
ONE
DTS
JUMP
i:
ADDRESS :!
FIELD
'
SAC
Figure 2-Simple microprogrammed machine
Figure 3-Representation of a microinstruction word
Rationale for Logic from Semiconductor Memory
Line 4 The control of the microprocessor is determined by the operation code of the instruction.
Line 5 The contents of the address portion of the
instruction register are transferred to the
memory address register.
Line 6 The desired data is read into the memory
buffer register.
Line 7 The memory buffer register is added to the
accumulator and the result stored in the accumulator.
Line 8 One is added to the program counter so it is
ready to fetch the next instruction and the
result is stored in the program counter.
Line 9 Control of the microprocessor is transferred
to start the next sequence.
Figure 5-Two-address source for microprocessor address register
This example does not really discuss how the ROS is
controlled. It merely points out that a control memory
can emit signals capable of controlling the data paths in
a system. The real essence of microprogramming is
focused on controlling the address sequencing of the
control memory itself.
CONTROL AND SEQUENCING OF THE
CONTROL STORE
In every microprogrammed device there must be some
logic which controls the ROS and does the basic system
timing. The complexity of this logic depends to a high
degree on the microprogrammed implementation. In a
microprogrammed device with short ROS words where
very few bits in the microprogrammed instruction word
are devoted to determining the next instruction, the
control logic will become fairly sophisticated. In these
systems a ROS program counter will generally exist and
the control logic will ensure that the next ROS control
word is selected by augmenting the program counter
by one just as the program. counter is augmented in a
MEMORY
CONTROL
JUMP
INSTRUCTION
ADDER
MBUS
CONTROL CONTROL
DTS
DBUS
CONTROL
S BUS
CONTROL
PCD
SMAR
JUMP
ADDRESS
FIELD
!
R
MTS
MBRM
SIf!
f
I
JOPC
DTS
EXECUTE
PLUS
RETURN
lAD
'\
SMAR
R
ONE
JMP
MBRM
ACD
SAC
PCD
SPC
START
Figure 4-Microprogram to add contents of memory to
accumulator
355
typical computer system. In microprogrammed devices
with longer words, the control will be conceptually
simpler. For example, if each instruction contained the
address of the next instruction, there would be no need
for a program counter, only a ROS address register.
Wilkes' basic implementation shown in Figure 1 generated the address to read out the next microinstruction
directly from the output of the B matrix. Therefore, if
there were 1024 words of ROS, the output from this
matrix would be a 10-bitcode used to designate one of
these words. While this technique is adequate, it fails to
couple the microprocessing device in a tight fashion to
its external environment and leads to an inordinately
long response to an input stimulus. To see this, consider
the problem of interpreting a 5-bit code and branching
to one of thirty-two points determined by the code. This
is the type of operation which occurs in interpreting the
operation code of a computer. In the Wilkes' model,
each bit must be tested separately and a branch must
be taken at each step. This involves 5 separate tests,
one for each bit and 31 branch-type instructions in a
decision tree, plus an additional 32 branch instructions
to get to the starting point of the various routines.
Wilkes' group suggested introducing multiple address
sources. This greatly simplifies and speeds the solution
to the above problem. To see this, consider the ROS
address register shown in Figure 5 where the bits Ri
are output from the address selection section of the
ROS. Consider the bits Sj as bits from another register
(for example, the instruction register in a computer).
In order to interpret a 5-bit code, one need only let the
bits Rll to R5 select the starting address of a table in
memory which contains 32 starting addresses of ROS
sequences. The bits S4 to So could select anyone of 32
entries in this table which could direct the microprocessing element to the proper location. Instruction decoding
could, therefore, be accomplished with one microinstruction.
The importance of this technique goes far beyond the
concept of instruction decoding. Any set of conditions
could be introduced as an input in the low-order bit
356
Spring Joint Computer Conference, 1972
SET ROM
DATA REGISTER
--In,'--_ _.....J
n
L.._ _ _....I ' -_ _ _.... 1..._ __
I
EXECUTE MICROINSTRUCTION
CONDITIONAL
BRANCH DECISION
'I
I
I
n
n
I
SET ROM
ACCESS REGISTE R ~ ,_ _+-----' 1...-_4------1 L---~_.....II ' - - I
I
ACCESS ROM --;..,_---'
Figure 6-Typical ROS timing
positions and therefore, this represents one technique
for developing a fast response based on the status of the
external environment. For the example above, anyone
of 32 alternative courses of action could be taken in
response to an input. This action could be initiated in
one microinstruction cycle. With today's semiconductor
memories, microprocessors with 100 nanoseconds cycle
times are easily constructed, so that a response to an external stimulus can begin very quickly.
Figure 6 shows the timing in a typical microprogrammed system. The first set of timing pulses strobes the
output from the ROS into the output buffer register.
As soon as the output buffer has· settled, the execution of the microinstruction can begin. This is indicated
in the second line of the timing diagram. The execution
time will be long enough to permit the most basic microinstruction execution to take place. However, some of
the longer operations might take two or more microinstruction times to execute. For example, suppose the
time to gate data from source registers to the adder
and to perform an "add" is 300 nanoseconds. If the
basic microinstruction cycle is 150 nanoseconds, then
an add operation would require two microinstruction
times. This could be accomplished by executing the
same microinstruction twice with the exception that
data would not be stored in the destination register
until the second instruction is executed. Another way to
handle long instruction execution times is to let the
microinstruction have a bit or bits which will be used to
extend the microinstruction execution time. Still
another obvious way for simpler systems is to merely
let the longest instruction dominate the timing. For
example, if 300 nanoseconds is the longest register-toregister cycle time, then the basic cycle could be
selected as 300 nanoseconds. In most cases, however, a
system will have certain microinstructions which require several basic machine cycles. For example, a fast
microprogrammed device may be hooked to a slow core
memory which has an access time of 800 nanoseconds
compared with a basic microinstruction execution time
of 200 nanoseconds. It is desirable to have some inter-
locks which enable this type of delay to be conveniently
accommodated.
The fourth line in Figure 6 shows the time at which
the ROS address register is loaded. This timing pulse
will set the ROS address register. If a conditional
branch is going to be executed, the logical decision must
be made during the time shown in line 3 for the branch
to be executed within the given cycle. Obviously, this is
not always possible. For example, if a branch is to be
made on overflow, it is likely that the information will
not be developed by the adder until it is too late to
enable a branch decision to be made for that instruction.
Consequently, one instruction and one instruction
execution time is lost because the branch decision must
be made on the next instruction.
The fifth line of the timing diagram shows the time
devoted to the access of the ROS. One reason for the
importance of fast access in the ROS can now be understood. The shorter the access time, the more time is
available for making decisions. Since a high percentage
of microinstructions contain conditional branches, many
instructions and instruction times can be saved by making the access time as small a percentage of the basic
control cycle as is possible.
ADVANTAGES OF MICROPROGRAMMING
There are many reasons why it is desirable from a systems point of view to employ microprogramming. Some
of these are:
1. Reduction of random logic, resulting in more
structured organization.
2. Emulation of a number of devices (not just
another processor) can be carried out by a single,
general-purpose device.
3. Diagnostics and service aids may be implemented
easily in the control portion of the system.
4. Field changes can be made easily by changing
the contents of control stores.
5. Special-purpose adaptations can be made of a
device by changing a few program cards.
6. The logical complexity of a device can be increased at lower cost than in a conventional system.
7. Final system definition can be postponed to a
later time in the design cycle.
8. Documentation and service training costs can be
reduced.
The prime motivation for interest in microprogramming today appears to be one of economy. To under-
Rationale for Logic from Semiconductor Memory
stand why, an analysis must be made of the cost of
putting an IC (Integrated Circuit) into a system.
The direct cost of putting an IC into a system is over
$1.00. Figure 7 shows a breakdown of these costs which
one experienced manufacturer of digital systems considers reasonable. When all of the direct costs in fabricating a system are taken into account, such as indicator
lamps, maintenance panels, system cabling, etc. ,and
the total system manufacturing cost is divided by the
number of IC's, one frequently arrives at a figure of
$2.00 per IC. The $1.05 cost of Figure 7 will be used during the rest of this discussion because there seems to be
general agreement that getting rid of one IC will usually
save a manufacturer that much money.
It is interesting to note that under the assumption of
Figure 7, even if IC's were free, the total manufacturing
cost could be reduced by only 30 percent. Assuming
.30
-IC
- Incoming
Inspection
.05
. 25
-P C Card
-Component Insertion and Fabrication
.03
_Board Check Out
.05
-Connector
.05
-Capacitor
.03
-Wiring
.09
- Power Supply
0
$1.00 I Watt
- Cabinetry ICard Guidesl Fans/etc.
.10
.10
$ 1.05
Figure 7-System cost for a 16 pin DIP on 88 pin 60 IC board
designers continue to use conventional IC's and packaging approaches in design of their systems, there will be
small, if not significant, decreases in the manufacturing
cost of digital systems.
If one assumes that the average IC contains 3 gating
functions, then the direct cost per gate installed in a
system will be on the order of 35¢.
For the most elementary type of devices, random
control logic will always be the most economical way to
design a system. If, for example, a device can be controlled by a single pre-set counter, it is impractical to
become involved in the intricacies of microprogrammed
control. This is because a microprogrammed device has
a base cost associated with the address sequencing and
memory selection circuitry which is incurred no matter
how simple the device is. This is shown in Figure 8.
Properly designed semiconductor control storage has
most of the memory selection circuitry integrated into
357
COMPLEXITY Figure 8-Cost comparison of conventional and
microprogrammed control
the memory element arid this greatly reduces the base
cost.
Figure 8 shows the cost of microprogrammed control
increasing slowly with the number of sequencing cycles.
This is because each additional sequence cycle will, in
general, require one additional word of control store .
If, for example, the control memory of a device uses 32
bit words and the control store costs only 0.25¢/bit, as
such devices will in the future, then the cost of an additional control cycle is only 8¢ .
The cost of conventional control in Figure 8 is shown
increasing at a fairly fast rate. One can see that if an
additional control cycle required only one additional
gating function or some type of storage element to distinguish it from all the other control states, then at
least one gate or 35¢ in direct cost must be added to the
system cost. For this simple example, the cost of conventional control increases at over four times the rate
per sequencing cycle of microprogrammed control.
I
1¢/BIT
O.5¢/BIT
O.25¢/BIT
40.00
20.00
10.00
.50
.50
.50
-PC Card
.25
.25
.25
- Component Insertion and Fabricat ion
.03
.03
.03
- Board Check Out
.15
.15
.15
-Connector
.05
.05
.05
-Wiring
.12
.12
.12
-Power Supply $ 1.00 I Watt
.50
.50
.50
.10
$41.70
.10
$21.70
.10
$11.70
- IC (4096 BIT ROM)
- Inca'ming
Inspection
-Cabinetry I Cord Guidesl Fans I etc.
Figure 9-Cost of ROM in microprogrammed system
358
Spring Joint Computer Conference, 1972
There are a few hard facts to back up any estimates
of the efficiency of microprogrammed devices, but most
designers seem to agree that somewhere between 8 and
16 bits of ROM can be used to replace a gating function. If 16 is considered to be a pessimistic number and
8 an optimistic one, then a 4096-bit ROM is capable of
replacing between 256 and 512 gating functions. This
ratio provides a great incentive to the designer to employ
microprogramming.
Figure 9 shows the direct cost of putting a 4096-bit
ROM in a microprogrammed system, assuming costs
per bit of 1¢, 0.5¢ and 0.25¢. If R bits of ROl\1 replace
a single gating function, then the dollars saved by employing a single 4096-bit ROM at 0.25¢/bit are:
SAVINGS
0.35 X
=
(4~6)
BITS PER GATE FUNCTION
8
OPTIMISTIC
12
REALISTIC
16
PESSIMISTIC
NO. OF DIPS
SAVED
170
114
85
PC CARDS SAVED
60 DIPS/BOARD
3
2
1.5
12.8
8.5
6.4
VOLUME SAVED
IN IN 3
150 IN3
100lN3
751N3
DOLLARS SAVED
PER 4096 BIT ROM
$168
$119
$83
POWER SAVED
IN WATTS
- $11.70
where $11.70 represents the cost of the ROM shown in
Figure 9. These savings are plotted in Figure 10 for
various costs of ROlVl.
While 12 bits is probably a realistic number per gating
function replaced, it is interesting to note that the breakeven points for 1¢, 0.5¢ and 0.25¢ per bit ROMS are
36, 66, and 122 bits. With a 4096-bit bipolar ROM
there can be a tremendous margin of error in the assumptions, and still have microprogramming be the
most economical approach to system design.
Other savings result as well. These are tabulated in
Figure ll-Savings by using O.25~/bit ROM in
microprogrammed control of digital system
Figure 11. For example, if one assumes 12 bits of ROM
will replace a gate function, then the use of 4096-bit
ROl\fs in the control portion of a digital system will
save about 114 packages, 8.5 watts of power and 100
cubic inches of volume in addition to $119 per 4096-bit
ROlVl employed.
CONCLUSION
The true promise of LSI has not been realized in most
digital systems simply because it has been unappealing
to use custom designed parts in all but the highest volume applications. lVlicroprogramming techniques used
in conjunction with semiconductor memory can provide
many of the benefits of LSI for a broad class of systems. The designer, to take advantage of this new component, will, however, have to change many of his design techniques and philosophies.
REFERENCES
O~
______
~
__
10
~
__L -______________
15
20
25
~~
30
Figure lO-Number of ROM bits to replace a gate function
35
1 M V WILKES
The best way to design an automatic calculating machine
Manchester U Computer Inaugural Conference 1951
p 16+ff
2 M V WILKES
The growth of interest in microprogramming
Computing Surveys Vol 1 No 3 Sept 1969 p 139+ff
SYMBOL hardware debugging facilities
by M. A. CALHOUN
Kansas State University
M~nhattan, Kansas
INTRODUCTION
system and are easily removed for incorporation of
logic changes using discrete wire "patches" to the
original printed circuitry. Figure 2 illustrates schematically how the boards are mounted between a pair
of parallel two-sided printed circuit "motherboards".
Communication between boards is provided by two
groups of 200 parallel printed circuit bus lines on the
motherboards, the "connect" bus and the "bypass"
bus. These buses provide all required system interconnections except for cables to peripheral devices
and to the console. Physically, each large board can
contact up to 200 bus lines and have the remaining
200 lines bypass it. A signal on the bypass bus may
cross over a signal on the connect bus between board
positions to allow a board to contact the corresponding
position on the adjacent board or, alternatively, to a
board several slots distant. In addition, either or both
buses may have continuity breaks to isolate groups of
boards.
There were eleven such isolated groups of boards in
the original system, where each such Autonomous
Functional Unit (AFU) acts as a specialized processor
(see Figure 3). The Main Bus, a Ill-wire subset of the
400 wires on the motherboards, runs the full length of
the system and connects to each AFU. The lines in
this time-shared, global communication path are
distributed as follows:
The SYMBOL system is a full-scale working demonstration of an ALGOL-like, high-level, general-purpose,
procedural language and a multi-processing, multiprogramming operating system implemented directly
in hardware. 1 ,2,3,4 The results have proven the versatility of the design, construction, and testing techniques that were developed to enable a small number of
people to implement such a major system in a reasonable
time and at a relatively low cost.
Although the last items in the project to be developed,
the methods used to test and debug SYMBOL were
not the least important; delivery of the finished system
would have been much delayed if more conventional
methods of manual excitation and probing had been
used. To facilitate fuller understanding of these testing
techniques, a brief description of the architecture and
physical characteristics of SYMBOL will be given
first, followed by a more detailed description of the
test facilities.
SYMBOL HARDWARE AND ARCHITECTURE
Logic in SYMBOL is implemented with Complementary Transistor Micro-Logic (CTpL), a positive
AND/OR logic family with wired-OR capability at
every output except that of the flip-flop. 5 ,6 The importance of the wired-OR capability must be emphasized: there are a significant number of two-way
wired-OR ties with sources throughout the six-foot
long main frame; if discrete OR gates had been required, the size of the finished system would have been
considerably larger and its simple bus-oriented organization would not have been possible.
The dual-inline CTpL integrated circuits are assembled on about 110 large two-sided printed circuit
boards with plated-through holes (see Figure 1). These
boards contain all of the logic components in the
64
24
10
6
5
1
1
bidirectional data lines
bidirectional address lines
bidirectional priority lines
operation code lines
terminal number lines
system clock
system reset
In order to fully appreciate the operation of the
debugging facilities and the interactions between these
facilities and SYMBOL, it is necessary first to under359
360
Spring Joint Computer Conference, 1972
are:
AFU to Memory Controller requests
Memory Controller to AFU returns
AFU to AFU transfers
Control exchange cycles
All Main Bus transfers are priority sequenced, where
the priority bus coordinates the usage of the other buses.
When an AFU desires to use the Main Bus, it raises
it priority line and simultaneously checks to see if
there are any higher priority requests pending; if there
are none, it uses the bus on the following cycle. AFU
to AFU cycles, used only between sections of the
Central Processor, are also controlled by the priority
bus: the Central Processor assumes the Main Bus is
available for a private "sneak" cycle if no priority
lines are raised. Control exchange cycles are used to
communicate control information between the System
Supervisor and the other AFU's. During a control cycle,
the Main Bus lines have preassigned uses, with certain
lines used to start and stop each AFU, others to indicate
the completion of an AFU task, etc.; during a given
Figure 1-TypicaI12" X 17" two-sided printed circuit board with
logic additions and changes made with discrete wires
stand the various modes of communication which exist
between the eleven AFU's. The foundation for this
understanding is the knowledge that everything of
importance that happens within an AFU eventually
has some effect on the Main Bus. When the Instruction Sequencer finishes processing one instruction and
needs another, a request to the Memory Controller
is sent via the lVlain Bus. If the Arithmetic Processor
runs out of data, a call for more goes to the Memory
Controller. In both cases, information returned from
the Memory Controller is sent over the Main Bus. If
an input device completes its operation, the Channel
Controller notifies the Interface Processor via the
Main Bus. When the Translator is done with compilation of a program, the System Supervisor is notified
via the Main Bus. Even if a processor fails catastrophically and refuses to function at all, the absence
of lVlain Bus transfers originating from that AFU over
a short period of time (20 clock cycles, perhaps) can be
detected. Thus it can be said that whatever controls
or watches the Main Bus thereby controls or watches
SYMBOL. This cQncept of the Main Bus and the
kinds of information that are transmitted through it
are key features in the design of the total system and
in the functioning of the debugging facilities.
Four distinct types of bus usage are possible. They
Figure 2-Physical organization of SYMBOL illustrating
placement of large logic boards between parallel printed circuit
motherboards
SYMBOL Hardware Debugging Facilities
cycle, any combination of the paths can be used simultaneously.
361
lustrates the major requirements for testing in a research and development environment, with other
aspects of testing discussed to a lesser extent.
SYMBOL DEBUGGING
Component testing
The testing operations required in the development
of a large system can be divided naturally into several
fairly specific stages. The test functions vary as the
system progresses from the research and development
stage, to the prototype stage, to the production stage,
and finally to the customer support stage. The emphasis on testing during these stages shifts from one in
which strong support is given to engineering design
checkout, to one which gives strong support to badpart identification. System development within each
stage requires component, board, AFU, and system
testing functions; these functions are not always
clearly distinct, but they can be considered separately
for convenience. The discussion which follows il-
}Hi9h Speed
MO
am
System
Supervisor
Bus Channel
Controller
Memory Bus
Memory
.......- Controller
Translator
Main
Memory
~
~
Channels
Telephone
Rate
Channels
L-}
I---
r-----:
Disc
Controller
c--
Disc
Files
Reference
Processor
-----Memory
Arithmetic -----4 .......- Reclaimer
Processor
~~
.................
Central
~
Processor
.......- Interface
..................
Processor
Format
Processor
----Instruction f-----4
Sequencer
Figure 3-Block diagram of the SYMBOL system showing the
original eleven autonomous functional units all connecting to
the main bus
Component testing is normally an incoming inspection operation. The integrated circuit devices used in
SYMBOL were checked both statically and dynamically
upon receipt for two main reasons: (1) The devices
often had a long lead time for procurement, and an
incoming inspection allowed immediate replacement
orders to be made for bad devices. (2) The environment
in which the devices were used (printed circuit boards)
is one which has a high time (and therefore cost)
penalty for replacing a device that should not have
been installed in the first place.
The tests included a static check of the logic the
device was supposed to implement, the on/off delay
times from threshold to threshold, a check on the
ringing tendencies, operation of the device when
driven by a minimum clock pulse (where applicable),
and the operation of the device under minimum and
maximum power supply limits. These tests were made
on a breadboarded device tester which, while adequate,
was not very efficient, especially from a human factors
viewpoint. In particular, the tester was capable of
making only one class of measurements at a time; if
a device required two classes of measurements, it had
to be retested in a second pass. This resulted in a low
throughput rate since about half of the time required
to test a device was spent in manually transferring it
from the source bin to the tester and from the tester
to the "accept" or "reject" bin. Fortunately, better
component testers are now available with good human
factors design and automatic device transporters for
quick and efficient incoming inspection.
Except for perhaps 100 devices received in the last
few weeks of the project, all 18,000 integrated circuits
in SYMBOL were given a thorough incoming inspection. It is safe to say that these last 100 devices caused
more trouble during debugging than the first 18,000.
This was sufficient proof of the absolute necessity for
complete incoming component testing for future projects.
Board testing
Two maj or kinds of errors should be detected and
corrected through board testing before a board is
placed into a system. As in most system development,
construction errors of various kinds will be discovered.
362
Spring Joint Computer Conference, 1972
These errors will include fabrication errors such as
drawing mistakes, missing or misplaced holes in the
printed circuit, solder bridges, and misplaced components, to name just a few. In addition, there will
also be system design errors ("oversights"?) which
must be found and corrected. The scope of this problem
was extremely large for SYMBOL boards because of
their great number (110), their size (maximum of 220
integrated circuits), and their limited number of signal
contact points (250). Considerable development is still
necessary before automatic computer test generation is
economically feasible for this size of board: current
programs might require two hours to generate complete
tests for about one-fifth of the logic on a board, and the
difficulty of the task increases considerably with increasing size. Such costs could not be justified for
this prototype system. If the problem were altered
from an exhaustive test of all of the logic on a board
to a test of all the used states of the logic, it might very
well prove economically feasible. In particular, in a
production environment, the cost of such test generation could be amortized over many systems since the
same test sequence would be used over and over again.
However, even though the isolation and correction of
fabrication errors before system checkout began would
have allowed more efficient debugging, it was felt that
the amount of effort required for a thorough precheck
could not be justified for this one-of-a-kind system.
Thus, after a relatively cursory examination of each
board for obvious errors (such as solder bridges) by
experienced technical help, the board was returned to
the designer for simple logic verification in a manual
test station before proceeding to AFU or system test.
This board test station has been described elsewhere. 4
Subsystem and system test
Subsystem testing was the process of debugging a
complete Autonomous Functional Unit as a unit. Each
AFU performs, by itself, some function in the complete
system, and, in a sense, is a stand-alone unit. Except
for the Memory Re claimer , a two-board AFU which
was extensively (but not completely, as it turned out)
simulated using the FAIRSIM* system, most AFU's
were too large to allow simulation as a unit; therefore,
subsystem test was the first time at which all of the
boards in an AFU were run together. By this time most
of the fabrication errors had been detected through
board testing, although there were always a few left
to find.
* Fairchild
Design.
Digital Simulation program for Computer Aided
Subsystem testing could take many forms and could
be performed in many different ways. An extension
of the board test station was conceived where all boards
of an AFU could be inserted into one module and a
manual test performed. This sort of testing might
have been useful in some limited areas such as verifying
the basic cycling of control logic or the basic register
transfers within an AFU, but, in general, a complete
AFU test in this sort of test station would be very
difficult, inefficient, and time consuming. Recognizing,
then, that a thorough job of AFU testing was not
desirable or even practical, subsystem and system
testing were combined into the same operation and
were essentially carried on simultaneously.
System testing was quite a prolonged process and
involved a wide spectrum of activities from the initial
startup of each of the AFU's on through to the final
operation of the full system. The debugging of SY1VIBOL encountered many unique problems analogous
to trying to test both a central processing unit and an
operating system simultaneously on a more conventional computer. Unfortunately, self-diagnostics were
impractical until late in the project because the construction schedule was such that Input/Output equipment was one of the last items to become operational.
Some way of automatically exercising and/or monitoring various AFU's and portions of the system and of
recording the results of these tests was absolutely necessary; in response to these needs, the first System Tester
was developed.
SYSTEM TESTER
The System Tester consisted of three major elements:
a programmable minicomputer, a logic interface and
bus multiplexer between the minicomputer and SYMBOL, and a comprehensive set of computer programs
which could control (and be controlled by) events
Small
Control ~16 Data Lines
Computer
a Control t
System
Tester
Interface
II-
System Mode
a
Clock Control
---
~
rCard
I Printer
Reader
Symbol
Main :
Buses:
Figure 4-Block diagram illustrating connection of the
programmable control computer to SYMBOL through
the system tester interface
SYMBOL Hardware Debugging Facilities
occurring on the Main Bus. The configuration is schematicallyrepresented in Figure 4.
The minicomputer was an IBM 1130 with an 8192
word, 16 bits per word, memory (3.6 microsecond cycle
time), a removable disc, a console keyboard and typewriter, a card reader/punch, a Data Products 80column high-speed line printer, and a Storage Access
Channel. The standard software supplied with the
system (Disk Monitor Version II, Level 3) was used
throughout the project.
The hardware interface consisted of four large logic
boards between a pair of short motherboards mounted
in a small separate enclosure (along with the necessary
power supplies, cooling fans, etc.), placed adjacent to
one end of the SYMBOL main frame. Short cables
were used to connect the Main Bus to the interface,
and a somewhat longer and thinner cable connected
the interface to the control computer. The interface
to the line printer was located on a fifth board in this
same module.
The System Tester interface logic was divided into
four basic sections. The first was a fairly small one
which consisted of a number of TT~L inverters which
were the logic level buffers between the control computer and the CT~L logic in the rest of the system. Second was a set of control interface registers and Input/
Output logic which communicated with the control
computer. The third section was another set of data
registers which could be loaded and unloaded by commands from the control computer and which were used
to transfer data to and from the Main Bus. The last
section was the control logic which obeyed the priority
rules of the Main Bus and included system reset and
clock controls.
In addition to the 111 Main Bus lines, four extra
lines were allocated to a System Test Mode which was
distributed throughout the system and decoded by
certain AFU's to provide additional control of several
of the more complex operations. Different test modes,
for example, could completely turn off a particular
AFU or could force serial instead of parallel operation of all the AFU's. The discrepancy between the
speed of the control computer's 16-bit data channel
and the considerably larger Main Bus was resolved by
allowing the interface to turn off the SYMBOL clock
momentarily each time data was transferred to or from
the interface buffer registers. Although control of the
clock in this manner significantly lowered the execution
speed of SYMBOL, all logic sequences were still executed in the same order with respect to each other,
except for real-time peripheral devices, no matter what
the actual clock speed.
The third major element of the System Tester was a
363
language called DEBUG (what else!) and a set of programs which interpretively executed this language to
control the interface as directed by input from the user;
details of the language are given below. The actual
interface and interrupt-servicing subroutines were
written in assembly language while the majority of the
remaining programs were written in FORTRAN. However, as new features were added to the system during
the development period, the limited memory of the
control computer was exhausted several times; each
time, another routine was converted from FORTRAN
to assembly language in order to free additional space.
Notwithstanding this severe memory limitation, only
rarely was a language feature removed, and then only
after assurances from all users that the feature really
was not being used.
In addition to the specific language features described below, many specialized programs were written
(normally in FORTRAN) to provide formatted memory
dumps, save-restore capability between the removable
disc and SYMBOL memory, and other convenient
features.
DEBUG LANGUAGE
The following sections describe the DEBUG language
and the operation of the System Tester in some detail
and especially attempt to convey some of the flavor
of the system. The past tense is used because the
System Tester was replaced by a special-purpose AFU,
the Maintenance Unit (to be described later) and thus
no longer exists.
The interpretive DEBUG processor accepted commands from punched cards. Each command consisted
of an instruction element followed by a list of zero or
more data elements. The format was relatively free
form, with all blanks (spaces) ignored except in a
string data element. Each element was separated from
the preceding one by a comma or an equal sign. The
last element was terminated by a period. Comments or
other information following the period were ignored
(a comment card was one whose first non-blank character was a period). Blank cards could be included in the
deck for readability.
Extensive error checking was performed by the
DEBUG processor, although very little error recovery
was attempted because of the paucity of memory. When
a mistake was discovered, the main response was an
indication on the output listing of its nature. The
system's action after an error was not predicted. In
addition to a listing of the input commands and error
messages, other messages of an informative nature and
364
Spring Joint Computer Conference, 1972
TABLE I-List and Description of Programmed Register and
Interface Hardware Register Mnemonics Recognized
by the DEBUG Processor
Programmed Register Mnemonics
COMB-Address last formed by a COMBINE command
COUNT-Number of Main Bus transfers monitored in tracing
SPLTG-Group-link word address from a SPLIT command
SPLTP-Page address from a SPLIT command
SPLTW-Word address from a SPLIT command
ZERO-Infinite source of zeros
Interface Hardware Register Mnemonics
MP-Monitored SYMBOL priority bus lines
OP-Memory operation code last transmitted or error
code last received
PL-Page-list currently specified (the mnemonic PAGE
LIST could also be used)
PRIOR-Priority of the System Tester (any of the AFU's
could be simulated)
RADR-Address last returned from SYMBOL
RCVX-Patchable register last received from SYMBOL
RDATA-Data last returned from SYMBOL
TN-Terminal number currently in use (TERMINAL
NUMBER could also be used)
XADR-Address last transmitted to SYMBOL
XDATA-Data last transmitted to SYMBOL
XMTX-Patchable register last transmitted
the results of any action taken could be obtained on
the line printer.
Data elements
A data element could have one of the following forms:
1. A hexadecimal constant formed by the character
"/" followed by zero or more hexadecimal digits.
Only the last 16 were retained. A typical example
is /0079 004F CO 02D63B, where blanks have
been included for readability. If fewer than 16
digits were entered, the result was right-justified. For left-justification ("contraction" is a
good mnemonic) the last digit could be followed
by an apostrophe and a character to designate
the "fill" digit. Examples are /FF'O, where the
leftmost byte is all ones and the rest are zeros,
and /'A, a word of alternating ones and zeros.
2. A positive decimal number formed by zero or
more decimal digits. Two examples are 0 (zero)
and 18 446 744 073 709 551 615, the largest
possible 64-bit number.
3. An alphanumeric string formed by a stringstart indicator (an apostrophe) followed by
zero to eight characters. To allow for character
codes not represented on a keypunch, triplets
composed of an escape character (the @) followed by a two-hex-digit coding of the desired
character could be included in the alphanumeric
string.
4. A data element could also be a register mnemonic
formed by a single letter "A" through "Z" or a
word chosen from a list of programmed registers
or interface hardware registers which had
specific predefined uses. The single-letter programmed registers were for temporary storage
of data, addresses, etc., as the user desired. They
could be initialized, cleared, etc., only by DEBUG commands or by being explicitly named
in a Memory Control or System Supervisor
command. A list and description of the multiletter register mnemonics is given in Table I.
Programmed registers A through Z and ZERO
and hardware registers XDATA and RDATA
were eight-byte (64 bit) registers. To refer to
fewer than eight bytes,. the mnemonics could be
followed by a subscript from·O through 7 enclosed in parentheses. Subscripts 3, 4, 6, and 7
implicitly referenced a single-byte datum. Subscripts 0 and 2 referred to a two-byte page
address, and subscripts 1 and 5 referenced three,..
byte word addresses. No subscript implied
context-dependent use of some or all of the full
64-bit register.
5. And finally, a data element could be empty or
null if it were formed by two consecutive terminators or two terminators separated only by
blanks.
The System Tester was a combination hardware/
software system. To execute each command, the
DEBUG processor transferred the contents of the
indicated programmed registers to the appropriate
hardware registers in the interface and initiated the
proper operation. Although a data element could be
left unspecified, the corresponding hardware interface
register still participated in the operation; its contents
were simply the value remaining from the previous
operation. These registers could be initialized, set,
cleared, etc., by DEBUG commands or by implicit
side effects of various Memory Controller or System
Supervisor operations.
Instruction elements
An instruction element was a mnemonic chosen from
a predefined list; only the first five characters of mnemonics containing more than five characters were used
SYMBOL Hardware Debugging Facilities
365
TABLE II-List of All DEBUG Main Bus Transfer Commands with Data Elements Explicitly Identified by the
Corresponding Default H~rdware Interface Register Mnemonic
Command
AG, XADR, RADR.
AGOO, RADR.
AGOl, RADR.
AG 10, XADR, RADR.
DE, XADR.
DS, XADR.
DL, XADR.
FD, XADR, RADR, RDATA.
FF, XADR, RADR, RDATA.
FL, XADR, RADR, RDATA.
FR, XADR, RADR, RDATA.
IG, XADR, RADR.
RG, XADR, RDATA.
RGO, RDATA.
SA, XADR, RADR, XDATA.
SD, XADR, RADR, XDATA.
ST, XADR, RADR, XDATA.
SO, XADR, RADR, XDATA.
SS, XDATA, XADR, OP, RDATA.
Function
Side Effects
Assign group
RDATA=O
XADR=RDATA=O=PL
XADR=RDATA=O
RDATA=O=PL
RADR=RDATA=O
RADR=RDATA=O
RADR=RDATA=0
Delete end of group
Delete string
Delete page list
Fetch direct
Fetch and follow
Follow and fetch
Reverse follow and fetch
Insert Group
Reclaim group
RDATA=O
RADR=O
XADR=RADR=O
RDATA=O
RDATA=O
RDATA=O
RDATA=O
Store and assign
Store direct
Store and insert
Store only
Control exchange cycle
for recognition. Most commands were order dependent,
and data elements had to be listed in the exact order
shown (or not listed at all). Data elements to the right
of the last one of interest to the user did not need to
be indicated. An example of each Main Bus command,
with data elements explicitly identified by the default
hardware interface register mnemonic, is given in
Table II.
In addition to the simple Main Bus commands, there
were 38 other commands available to the user to
provide for explicit control of the System Tester environment; control of the hardware interface registers;
maintenance of the files stored on the control computer's
disc; loading, reading, writing, and testing of SYMBOL's memory; monitoring of SYMBOL; and decision making within DEBUG. These commands are
summarized in Table III, where reserved mnemonics
are shown in capital letters, and parameters and explanatory notes are given in lower case letters.
MAINTENANCE UNIT
To provide an independent maintenance and debugging capability, the System Tester was replaced by
another AFU, the Maintenance Unit. Figure 5 schematically illustrates the final system configuration as
delivered to Iowa State University. Input/Output
equipment, controlled by a logic switch, is shared between the Maintenance Unit and a high-speed batch
~
Line
Printer
Card
Reader
~ ___~o~i~_~~it~~ ___
<.
?
I
Batch
Terminal
System
Twisted Mode 8
Pair
Clock
Control
..-
Maintenance
Unit
----
I--
Console
Control
[Consolel
\
To I~
r--
Symbol
Main:
Buses'
I
I
Other
Terminals
Figure 5-Schematic representation of the final system including
the maintenance unit and a high-speed terminal sharing common
input/output peripherals
366
Spring Joint Computer Conference, 1972
TABLE III-DEBUG Macros and Commands for Controlling the System Tester
Control of the general test environment
CLEAR TO ZERO, unordered list of registers.
COMBINE, page number, group number, word number, COMB. Address generator
EJECT.
Skipped output listing to a new page
END.
Signaled end of a testing session
EQUATE, old mnemonic=new mnemonic.
Corrected simple keypunch errors
HELLO, user's identification.
Identified beginning of a test session
LIST ALL.
Permitted printing of everything
LIST ERRORS ONLY.
Only error messages were printed
MOVE, destination = source.
Register-to-register transfers
PAUSE, number of milliseconds.
A timed delay.
PRINT, unordered list of registers.
REGISTER STATUS.
Printed contents of interface registers
REPEAT LAST MEMORY COMMAND, number of times. With XADR=RADR each time
SET, register = value.
Register initialization
SPLIT, source, SPLTP, SPLTG, SPLTW.
Address decomposer
STOP.
Press "START" on console to continue
WATCH, unordered list of hardware interface register mnemonics.
Control of the hardware interface
LOAD BUS AND STEP CLOCK, XDATA, XADR, OP. Single-step bus control
START CLOCK.
Let SYMBOL free-run
STEP CLOCK AND PRINT CONTENTS OF MAIN BUS, number of times.
STOP CLOCK.
Force SYMBOL to halt
SYSOFF.
Ccntraction of "system off"
SYSON.
Contraction of "system on"
Maintenance of files stored on control computer's disc
DELETE, FILE no
FILE STATUS.
RESTORE, FILE n.
SAVE, FILE n.
Deleted a previously saved file
Gave status of all files on disc
Loaded SYMBOL memory and DEBUG status
Stored SYMBOL memory and DEBUG status
Loading, reading, writing, and testing of SYMBOL memory
FIND, beginning address, ending address, data, mask. Searched for data
INITIALIZE, first address, last address, datum. Loaded memory with datum
LIST, beginning address, ending address. Dumped memory on line printer
LOAD, beginning address, ending address, ordered list of data elements.
TEST CORE, XDATA, number of times. High-speed repetive memory test
ZERO CORE.
Cleared SYMBOL memory to all zeros
Monitoring of SYMBOL
PREPARE TO TRACE, unordered list of AFU names. Set up for trace mode.
TRACE, XDATA, XADR, OP, unordered list of conditions for exiting.
Decision making within DEBUG
GO TO, label.
Skipped cards until label was found
IF, data, mask, condition, skip flag, number of cards. Decision maker
LABEL, user-chosen label.
Provided target for a GO TO command
terminal. The Maintenance Unit console, with START,
STOP, INHIBIT LIST, and RESET switches, is
integrated into the SYMBOL console. A simple punched
card input, easily produced at a keypunch or through
another processor called SUPERBUG (written in
FORTRAN for an IBM System /360) is used to direct
the hardwired Maintenance Unit. To preserve the
results of all prior testing, all DEBUG card decks were
converted to equivalent SUPERBUG decks through
a modified version of DEBUG which used the System
Tester and SYMBOL in the translation process. The
essential features of this control language are given
SYMBOL Hardware Debugging Facilities
below in hopes that they will provoke additional
ideas.
The Maintenance Unit is a card-driven character
processor where each card contains one or more commands. The command format is space independent, but
parameters are order dependent. The first non-blank
character on a card is the command code. Parameters
(if any) are separated fron each other by a dash (minus
sign). Two consecutive dashes (with zero or more intervening spaces) indicate an (optional) missing parameter, in which case the register contents remaining from
the previous command are used. The first semicolon
on a card terminates processing of further characters
from the card (i.e., human-readable comments, sequence numbers, etc., may follow a semicolon) and
the command is executed with parameters received
before the semicolon (a semicolon is automatically
generated at the end of a card if none were previously
found). Because of minimized decoding logic, the only
valid characters before a semicolon are the hex digits
o through F, the dash, and the (ignored) space.
Maintenance unit hardware
Table IV describes the hardware registers contained
in the Maintenance Unit. In the table and in the following descriptions, each upper case character in a
register mnemonic represents a single card column.
During operation, XXXXXX and Q are cleared to
zeros before each new command is read. RRRRRR,
RC, and DDDDDDDDDDDDDDDD are preserved
from one instruction to another unless changed by a
memory command. M is preserved until a new value is
loaded or until a system reset is performed, after which
M=O. XMP, CCCCCC, 0, P, and TN are preserved
from command to command unless specifically changed.
TABLE IV-Description of Registers in the Maintenance Unit
CCCCCC-Address compared during trace
(24 bits)
DDDDDDDDDDDDDDDD-Transmitted or received data
(64 bits)
M-System test mode (4 bits)
f)-Operation code (4 bits)
P-Page list (2 bits)
Q-Disc quadrant code (4 bits)
RC-Memory Controller return code
(6 bits)
RMP-Priority seen during trace
(12 bits)
RRRRRR-Returned address (24 bits)
TN-Terminal number (5 bits)
XMP-Priority watched for trace
(12 bits)
XXXXXX-Transmitted address (24 bits)
367
Note that P, TN, 0, Q, XMP, and CCCCCC are
treated as a single ordered parameter when loaded
from a card. P and TN may be changed without affecting 0 by following TN with a dash or semicolon
(or by leaving the remainder of the card blank). Other
than these registers, the Maintenance Unit contains
no memory; card commands are processed "on the
fly" without benefit of additional storage.
SUPERBUGcommands
The thirteen valid operation codes are summarized
in Table V, where typical cards and variations are
shown. Explanatory notes are again written in lower
case letters. Unused command codes 0, 1, 2, 6, and are simply ignored.
DEBUGGING TECHNIQUES
Although the command and control languages for
the System Tester and the Maintenance Unit differed
somewhat (with the Maintenance Unit having a considerably smaller repertoire), debugging using the two
systems was essentially the same. Both systems allowed the full range of Main Bus transfers to be initiated. This meant, for example, that the Memory
Controller (the central hub for most information
transfers) could be thoroughly and exhaustively checked
without having any other AFU functioning. Control
exchange cycles enabled the starting and stopping of
any AFU or groups of AFU's. The environmental
commands and the macros, such as ZERO CORE,
provided a good human interface with the system and
permitted easy setup of initial conditions in preparation for a test. And last, and definitely most important,
was the ability of both testers to monitor or "trace"
the operation of SYMBOL as it operated under its
own steam.
In the System Tester, monitoring was accomplished
by a PREPARE TO TRACE card (which set the
interface into a trace mode) followed by a TRACE
command with parameters to start the proper AFU(s)
and to establish stopping conditions. A single card
combining both setup and startup commands was
used with the Maintenance Unit. In either case, once
the monitoring process was begun, all (or any subset)
of the events occurring on the Main Bus (plus several
"patchable" lines used to assist in observing internal
AFU operations) could be printed on the high-speed
line printer. At the option of the user, printing could
be suppressed and the results of the trace could be
stored "round robin" in a small temporary buffer (on
disc with the System Tester or in SYMBOL core with
the Maintenance Unit) for later playback only if something crashed. The buffer in the System Tester held
368
Spring Joint Computer Conference, 1972
TABLE V-Examples of SUPERBUG Commands which Control the Maintenance Unit
THIS IS A COMMENT CARD AND DOES NOT AFFECT THE MAINTENANCE UNIT IN ANY WAY
3; Pause. Press "START" on console to continue processing.
4; Enable printing of results on the line printer
5; Inhibit printing for greater test throughput
7; Skip the line printer to the top of a new page
8 OOXXXX-DDDDDDDDDDDDDDDD-DDDDDDDDDDDDDDDD-etc., Load core with data
8 OOXXXX-DDDDDDDDDDDDDDDD-------------------------------------------etc., . Load successive core locations with datum
8 -FFFFFFFFFFFFFFFF-1-4-30--AAAAAAAAAAOO; Load beginning at address zero
900XXXX; Dump non-zero contents of memory on line printer
Dump non-zel,'o memory beginning at address zero
9;
A OOXXXX-DDDDDDDDDDDDDDDD-DDDDDDDDDDDDDDDD-etc., Compare core with data
A -FFFFFFFFFFFFFFFF-1-4-30--AAAAAAAAAAOO; Compare beginning at zero
B; Test core with all ones and all zeros, in that order
C XXXXXX-DDDDDDDDDDDDDDDD-P TN 0; Memory cycle without check of results
C XXXXXX-DDDDDDDDDDDDDDDD-P TN 0-RRRRRR-DDDDDDDDDDDDDDDD-RC TN; With check
D; System reset. Equivalent to pressing "RESET" on the console
E XXXXXX-DDDDDDDDDDDDDDDD-P TN; System Supervisor transmit without trace
E XXXXXX-DDDDDDDDDDDDDDDD-P TN 0 Q; Disc-synchronized System Supervisor transmit
E XXXXXX-DDDDDDDDDDDDDDDD-P TN 0 0 XMP CCCCCC; Trace after System Supervisor transmit
F M; Set new system test mode
the last 1600 operations whereas the Maintenance
Unit's buffer held but the last 64; usually the most
recent 10 to 20 were sufficient to analyze whatever
problem caused the crash. As might be expected, this
"instant reverse playback" feature gained heavy use
since testing without the real-time printing of results
speeded things up manyfold; only the last cycles which
caused failure needed to be printed.
SYMBOL. Steve Lundstrom designed the original
System Tester and contributed to the development of
the DEBUG language. Tom Cook assisted with the
implementation of the Maintenance Unit. Eric Palmer
wrote the SUPE~BUG processor. The guiding hands
of Rex Rice and William R. Smith were present throughout the entire project. And, of course, the hard work
and enthusiasm of the other members of the department made the project succeed.
SUMMARY
The full-scale running SYMBOL system has demonstrated that:
1. A very high-level, general-purpose, procedural
language and a multi-processing, multi-programmingoperating system can be implemented
directly in hardware.
2. Design and construction techniques using only
large two-layer printed circuit boards for all
system interconnections, together with a functionally factored system result in an economical,
serviceable, reliable, and "debuggable" system.
3. Effective testing techniques that connect an
operating processor to an unproven system which
has a bus-organized architecture can be developed to enhance and greatly simplify the debugging process
ACKNOWLEDGMENTS
The author wishes to acknowledge the help of the past
and present members of the Digital Systems Research
Department at Fairchild Camera and Instrument
Corporation who contributed to the testing phase of
REFERENCES
1 R RICE W R SMITH
SYMBOL: A major departure from classic
software-dominated von Neumann computing systems
AFIPS Conf Proc 38 pp 575-587 1971
2 W R SMITH R RICE G D CHESLEY
T A LALIOTIS S F LUNDSTROM
M A CALHOUN L D GEROULD T G COOK
SYMBOL: A large experimental system exploring major
hardware replacement of software
AFIPS Conf Proc 38 pp 601-616 1971
3 G D CHESLEY W R SMITH
The hardware-implemented high-level machine language for
SYMBOL
AFIPS Conf Proc 38 pp 563-573 1971
4 B E COWART R RICE S F LUNDSTROM
The physical attributes and testing aspects of the SYMBOL
system
AFIPS Conf Proc 38 pp 589-600 1971
5 R B SEEDS W R SMITH R D NEVALA
Integrated complementary transistor nanosecond logic
IEEE Proc 52: 12 pp 1584-1590 1964
6 R RICE
Functional design and interconnections: Key to inexpensive
systems
Electronics 39:3 pp 109-116 1966
The Rice Research Computer-A tagged architecture*
by E. A. FEUSTEL
Rice University
Houston, Texas
out when a tagged data word or instruction was
encountered.
Today the EAI8400 employs two tag bits for similar
purposes. The Telefunken TR4 and TR4405 employ
two tag bits to denote the numeric type of data at an
addressed location. The Burroughs B67006 ,7 ,8 and
B7700 which were developed concurrently and independently of the R-2 employ three tag bits to
identify types of numeric operands and special information used by the operating system.
What is new about Iliffe's concept is that it represents
a rejection of the classical von Neumann machine in
favor of something which may be better. In the von
Neumann machine program and data are equivalent in
the sense that the data which the program operates on
may be the program itself. The loop which modifies its
own addresses or changes its own instructions is an
example of this. While this practice may be permissible
in a minicomputer with a single user, it constitutes
gross negligence in the case of a multi-user machine
where sharing of code and/or data is to be encouraged.
Instead, Iliffe presents a different conjecture. All
information which the algorithm needs to know about
the data ought to be contained indivisibly in the data
itself. For example, an algorithm to perform a for-loop
on arrays ought to be the same whether the array is of
length ten or length 100. Rather than record this
information in a variable and use a loop with an index,
Iliffe proposes to record the length of the array with the
pointer to the array itself, as in Figure 1.
Rather than have several different algorithms for
add integer, add floating, add double precision, and
add complex, he proposes to make the data self-representing. An integer can only be used as an integer, a
floating quantity as a floating quantity, etc. This idea
is the fundamental difference between the class of
machines represented by the BL1YI, the R-2, and the
Burroughs B6700 on the one hand, and by those of more
conventional architecture on the other.
Once the fundamental decision has been made to
INTRODUCTION
In this paper we report on a new computer with several
novel features. These features are applications of the
concept of tagged architecture, and although some
of them are not unique to the Rice Research Computer
(R-2) , they focus our attention on this radical design
form, its advantages and disadvantages. Since the
work is still in progress, we limit this report to a discussion of the architecture and a few of its ramifications.
History of tagged architecture
The R-2 computer is an adaptation of a design of the
Basic Language Machine (BLM)l of Iliffe. In his book
and paper2 he presents an argument for the utilization of
a fraction of each memory 'word as tag bits. These tag
bits are to be interpreted by the hardware as information about the data found in the referenced location, or
its status with respect to the program or operating
, system.
The basic concept of tag bits is not new. Almost all
computers employ a parity bit which the hardware
uses to detect memory failure. In addition, many
computers utilize a lock byte which limits access to an
area of storage to the operating system or to those who
have a key byte that opens the locked area.
Early machines also employed bits which were of
special significance to the hardware. The Burroughs
B5500 employed a flag bit to inform the hardware that
the word at the location addressed possessed a nonnumeric value which must be interpreted by the
operating system. 3 The Rice Computer (R-1),4 circa
1959, employed two bits for every word which could be
set by the operating system or the programmer. These
bits were used in an extensive debugging system wherein
tracing, monitoring, or other procedures were carried
* This work is supported in part by the Atomic Energy Commission under grants AT-(40-1)-2572 and AT-(40-1)-4061.
369
370
Spring Joint Computer Conference, 1972
AlB
ADDRESS FORMAT
7
for the high security of the system programs. For every
fetch from memory the address calculator is given
four quantities, a base address B of 20 bits, an initial
index I of 14 bits, a length L of 14 bits, and the element
selector D of 14 bits. In 150 to 200 nanoseconds the
calculator performs the following algorithm:
ARRAY
Temp:=D-I;
POINTER
if Temp <0 then Low_error_l;
ifTemp~L then High_error_l;
Actual_address: = B+ Temp;
50
L
L -_ _ _ _ _---1
~
ARRAY
Figure 1-A typical array pointer and its array
adopt this goal in hardware, and the commitment to the
use of memory bits for tags has been made, a great
many benefits result. One of the most important is that
the hardware, once informed of what each piece of
data is, can perform run-time checks for consistency
of data and algorithms, e g., bounds checking and type
conversion.
General structure of the R-2
We now turn to the general structure of the R-2 as
shown in Figure 2, which represents only a minor
modification from the original design which began in
January 1969. The system consists of three major
asynchronous subsystems: a memory system of 24K
64-bit words of core memory, a Digital Equipment
Corporation PDP-II 1-0 controller, and the CPU
complex. While the details of the first and second subsystem are of interest, we will not be concerned with
them in this paper.
The CPU complex consists of a set of 64 16-bit
scratch-pad memory circuits organized as 64-bit
registers (designated X0 through XI5), whose cycle
time is approximately 40 nanoseconds, an arithmetic
unit and a CPU. The latter two units are built from
RCA ECL integrated circuits with typical delays
of from 3 to 5 nanoseconds. This results in a typical
add time for two 54-bit floating quantities on the order
of 50-200 nanoseconds, and a multiply consisting of
additions and shifts typically requiring 3 microseconds.
The address calculator in the CPU is one of the most
important features of the system. It functions as an
automatic base-bounds calculator and is responsible
I is a number between - (213 -1) and (213 -1) in one's
complement form. D has a maximum value of 214 - 1
and this is the largest segment which one can practically
use. This should be sufficient for all but the largest
one-dimensional arrays of data. The base address B is
of sufficient size for any program (or memory) that we
can currently foresee, on the order of 1 million words.
Data formats
Before we can discuss the operation of the CPU we
must understand the various data formats which the
R-2 can deal with. These formats are given in Figure 3.
Each word currently consists of 62 bits of information.
A two bit field in every word contains a parity bit Z
and a write lock bit L. The remaining 60 bits may be
divided into four classes of. words: numeric words,
control words, address words (or partition words), and
instruction words. The first three classes contain six
bits used for tags as Iliffe suggested. Four bits are used
to distinguish types and two may be set by the programmer to generate interrupts. The type codes are listed in
Table 1.
I~---------------------T----------
1
1
1
1
SCRATCH PAD
III
ARITHMETIC
UNIT
I
1-0 DEVICE & DISK
I
1- __________________ I
Figure 2-Subsystems of the R-2 Computer
The Rice Research Computer
The format of the various numeric types is of little
interest. They are the same as those found in the
original Rice Computer.4 See Table I.
We should take greater note of the formats for address
words. In addition to containing a base field (B), an
initial index field (I) and a length field (L), each address
word also contains an indirect reference field which indicates the type of the object in the block described by
the address word. Two more bits are used. One indicates whether the block which is described is in core
memory or in secondary storage (P). The other indicates
whether the block may be relocated. (Q).
Control words are an innovation. They are the only
method of intersegment communication. They contain
a 21-bit halfword pointer to an instruction (R-2 instruc, tions are packed two per word). A mode field of 11
bits indicates the operating state of the computer at the
time a jump to a subroutine is made. A two-bit condition code at the time the jump is made is stored in
field C. Since the routine may be disk resident, a P field
is provided to signal the routine's presence or absence
in core memory. A chain field is provided in each control
word. This field may be used to link together control
words which are on the stack or are in a common
linkage segment. Rather than scan storage linearly to
371
TABLE I-Data Tag Assignment
TAG Number
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111
Meaning
MIXED OR UNTAGGED
(unassigned)
(unassigned)
(unassigned)
REAL, SINGLE PRECISION
54 BIT BINARY STRING OR INTEGER
DOUBLE PRECISION (real, fl. pt.)
COMPLEX (two single precision fl. pt. words)
UNDEFINED FOR NORMAL OPERATIONS
PARTITION WORD
RELATIVE CONTROL WORD
ABSOLUTE CONTROL WORD
RELATIVE ADDRESS, UNCHAINED
ABSOLUTE ADDRESS, UNCHAINED
RELATIVE ADDRESS, CHAINED
ABSOLUTE ADDRESS, CHAINED
find the previous control word, one merely follows the
chain of links. Finally, a four-bit mark field may be used
to indicate the level of the subroutine or the level of the
subtask in the operating system. These marks are
especially useful when employed with the control
stack for exiting blocks and reestablishing an appropriate environment.
8 BIT
CONTROL
54 BIT
ARITHMETIC AND DATA FIELD
Processor facilities
,.
FIELD
COEFFICIENT
NUI1E RI C tlORDS
2
11
21
Ici
MODE
LOCATION
CONTROL
~IORDS
1_
CHAIN
20
ADORE SS tlORDS
or
PARTITION HORDS
2 2
_
I:I:I/(I 1 I
OP
y
iN
iN
FIRST INSTRUCTION
SECOND INSTRUCTION
INSTRUCTION
S---$oftlo/are-defi ned tags
D---Dircct tags
IR---Indirect tags
M---Mark
z---Parity
L---Write lockout
A---Literal value of iN
~IORDS
N---Displacemcnt of ·Location
Q---Rcstricted access to array
present in core
X---l s t operand reg. se 1ector
V---Variant on operation
Y---2nd operand reg. selector
OP- --Opera tf on code
C---Condi tf on code
P-~-Array
Figure 3-Diagram of R-2 word formats
Two major resources are available for use by the
instruction unit. The first is the hardware stack and
stacking mechanism. The second is the register set
(previously described). The stack is maintained in
memory and utilizes an address word held in register
X0 as a stack pointer and bound. In order to utilize the
address calculator in a consistent manner, the top of the
stack is the location addressed by the base field of the
address word and the bottom of the (accessible) stack
is determined using the length field. Special words called
partition words are stored by the operating system to
denote the absolute beginning and end of the stack
region or to point to a continuation of the stack in
another segment (see Figure 4). Any word of the accessible stack within 214 -1 of the top may be accessed by
an instruction. Partition words cannot be overwritten
by normal stacking and unstacking operations.
Two hardware registers U and R constitute Xl, the
double length accumulator for arithmetic and logical
operations. If Xl is loaded with an item of double
precision or complex data, the second word is held in
the R register. Special instructions are available to
address the R register independently of U.
372
Spring Joint Computer Conference, 1972
-,..----1
BEGIN STACK
BOTTOM OF STACK
N
PF- PARTITION FORWARD
PB - PARTITION BACKWARD
END OF STACK
four bits labeled X/V in Figure 3 are interpreted differently in two classes of instructions. The first features a
. four bit result register field X. The second uses this
field as a variant code for the operation, and for this
class (which includes arithmetic and logic) the first
operand is implicitly Xl, which also contains the
result.
Instructions are customarily written in the form
S A X OP Y ± N or S A OP Y ± N where the function
is to perform X OP Yeff~X, The first operand X is
either stated explicitly or is implicit in the instruction.
Yeff depends on the contents of Y, the number Nand
the immediate bit A.
Rather than describe the operation of the addressing
algorithm for Yeff exhaustively by flow diagrams, we
will describe instruction sequences for short algorithms.
This will show the effect of Iliffe's conjecture, as well
as illustrating the machine design.
ALLOCATED FOR STACK
Figure 4-The stack pointer and stack layout
Registers X2 through X15 are implemented with the
scratchpad memory integrated circuits mentioned
previously, and a reserved, fixed core memory location is
associated with each register to hold the second word of
double word data when it appears. By recognizing
the data tags "complex" and "double precision," the
hardware automatically performs the appropriate
double word transfers and storage so that no special
programming is required. Thus, to the programmer Xl
through X15 appear to be a set of general purpose
double word registers. Since X0 is always used as the
stack pointer, the hardware rejects (by interrupt) any
attempt to store a word into X0 unless it is tagged as
an address word.
All of the other registers except X15 may be used for
temporary storage of numbers, addresses, or control
words. X15 must contain an address word which describes where the interrupt vector is located. All
interrupts transfer relative to this address. In the event
of a catastrophe when there might not be an address
word in X1.5, interrupts transfer to locations relative
to absolute address O.
Instruction formats
Every instruction contains a one bit software tag
denoted by S and six bit function code field labeled OP
in Figure 3. Each instruction also features an immediate
bit labeled A, a numeric offset labeled N which may be
plus or minus, and a register field Y. The remaining
EXAMPLE PROGRAlVIS
Example i-Accessing vector elements
All elements must be accessed through an address
word. Address words can be constructed by the operating system in a manner to be described in a following
example. Suppose we have an address word in X2
which points to a vector in the manner of Figure 1, and
suppose we wish to add the element with index ten
of the array to a numeric quantity in Xl. We could use
the following instruction:
ADD X2.10 / / Select the element of X2 indexed by
10 and add to Xl. Suppose the initial index of X2,
I(X2) is -4, the length 15, and the base address 1000.
The sequence of computations would proceed as follows.
The computer would check X2 and determine that it
contained an address. It would issue B = 1000, I = - 4,
L = 15, and D = 10 to the address calculator. The
calculator would compute D-I (10- (-4» or 14
which is greater than -1 and less than L. Since the
element is within the vector, an address of 1014 would
be generated and the element would be brought to the
arithmetic unit. If the element is an integer it would be
immediately added to the integer in Xl and the
condition code would be set to reflect whether the
result was less than, greater than, or equal to zero. If
the element is real (fixed or floating point fraction), the
computer would convert Xl to floating point form and
perform the addition. If the element is anything but a
numeric type, an exception occurs and an interrupt to a
fixed location relative to the address in X15 takes place.
If the instruction also invokes the auto-store option,
The Rice Research Computer
denoted ADD~X2.10, the result would be stored back
into 1014.
373
that the initial indices are O. Then we could use:
X2 DOT = 3
Example 2-Accessing array elements
On the R-2 we usually represent arrays in a tree
structure. The first index is used to determine an
element in a vector composed of address words. The
second index is used with this address element to select
an element from a second vector which is an address
word and so on until the last index which is used to
select the desired element. This kind of an array is
illustrated in Figure 5. Because of the fact that each
address word carries with it the length of the vector
it addresses, such arrays may be uniform or nonuniform
as desired. They may also be so large that only one
vector of data will fit in core memory at any time.
Two different methods of addressing such arrays
can be used. These methods are considerably more
efficient than that used on the Burroughs 6700 because
of the scratchpad registers X2-X14 which are available.
One method involves element selection as in the first
example. It is generally used when we wish to select
only Xi,j,k th element of an array rather than to deal
with every element. The following sequence of instructions indicates how this may be accomplished.
Suppose X2 contains the address word pointing to
the vector and we desire to select Z3 ,1 ,5 and assume
FORMATS
ADDRESS
N
REAL
INTEGER
INTEGER
I
I R I REAL
~ A
A
2
1
0
1
4{A
A
2
2
3
2
~
-+-
-+~
R
R
7_1
5..3
N -10
R -12_'2
N
5
R
4..3
N
-7
Figure 5-A nonuniform three dimensional array
/ / Replaces the contents of X2
with the third element of
first level tree.
X2 DOT
1 / / Replaces of the contents of
X2 with the first element of
second level.
X2 MOD = 5 / / Generates the
address of
Z3,1,5 in X2.
ADD ~ X2 / / Adds (Xl) to Z3,1,5 and autostores back into the array.
This set uses the immediate address form of the
instruction.
An alternative form might employ a vector of subscripts. Suppose that X3 contains the address word of a
vector of subscripts to be applied to Z, i.e. (3, 1, 5). The
following sequence indicates how this may be done.
X2 DOT X3.1 / / Obtains the third element of
first level.
X2 DOT X3.2 / / Obtains the first element of
second level.
X2 MOD X3.3 / / Generates a pointer to Za,I,5.
ADD ~X2 / / Adds (Xl) to Z3,1,5' and autostores.
This sequence of computations is as follows. The first
element of X3 (since I(X3) =0) is selected and brought
to the CPU. It has the value 3. If X3 had
contained a number originally, 1 would have been
added to that number and the resultant would have
been used. This value is then used to obtain the third
element of Z's first level subtree (denoted Z3, *, *).
This is left in X2. The next operation obtains an address
word which is the first element of Z's second level tree
of the third branch (Z3 ,1, *). The next operation indexes
this address to make its location field point to the
desired element. This element is presumably a number
(integer, real, complex, or double precision). It is added
to the .contents of the U register (Xl), and the result
placed in Xl and in Z3,1,5, thus smoothly implementing
the ALGOL 68 statement: Z[3, 1,5] + := V; where V was
the contents of Xl. If the value of (X3.1), (X3.2), or
(X3.2) had not been a number then an exception
would have occurred.
Example 3-Array processing
In some cases vector processing is desired. For this
purpose a different kind of access is desired. In this
374
Spring Joint Computer Conference, 1972
mode one systematically examines all the elements of an
array or vector in turn, and performs some operation
on them. For example, to sum a vector pointed to by an
address word in register X2, one might use the following
sequence of instructions. Assume (I(X2)) equals o.
X3 LOAD
4
/ / To sum five elements of
vector X2
Xl LOAD
0 / / Initialize Xl to Zero
AGAIN
ADD X2.0 / / Add first elemen t of
vector
/ / Adjust X2 to point to
X2 MOD = I
the next element
X3 JGE AGAIN / / Continue to CONT if
X3 is zero or negative
CONT
/ / Decrement and jump to
AGAIN otherwise.
This sequence loads X3 with the number 4 and Xl
with the number o. The next instruction causes the
number pointed to by the B field of X2 to be added to
the number in Xl. If the length field is set to - 1, an
exception will occur. The next instruction uses the
literal 1 to decrement the L field of the address in X2
and simultaneously increase the B field by 1. If L is
less than zero an exception will occur. The next instruction examines X3. If it is a number less than or equal
to 0, the next sequential instruction is taken. Otherwise
the number is decremented by one and control passes
to AGAIN. Using this sequence the first five elements
of the vector pointed to by X2 are summed. If there
are fewer than six elements in this vector, an exception
occurs. If there are exactly five elements in the vector
when the program gets to CONT, L(X2) equals zero.
An attempt to do X2 MOD = I again will cause an
error exception. Otherwise the new L(X2) is five less
than before and the new B(X2) is five more than
previously.
A shorter sequence may be used if it is desired to
sum all the elements of the vector. Here the programmer
need not even know how long the vector is.
AGAIN
Xl LOAD = 0 / / Set Xl to zero
ADD X2.0 / / Add elements to Xl
X2 JNL AGAIN / / See the discussion below
The last instruction checks to see if L(X2) is greater
than o. If it is it performs X2 MOD = 1 and transfers
control to AGAIN. If it is not, control passess to the
next instruction.
As a final example of the power of this approach,
assume that we have three arrays A, BT, and C and
that we desire to compute
n
Ci,k=
L: Ai,jBk,/.
j=O
This can be calculated simply in the following routine
assuming X2 is an address word pointing to A, X4 is an
address word pointng to BT, and X6 is an address word
pointing to C.
INIT
BEGIN
X9 COpy X4
X7 LOAD X6
FIRST
X3 LOAD X2
/ / Copies (X4) to X9
/ / Get ith subtree of
C
/ / Get ith subtree of
A
X5 LOAD X4
/ / Get kth subtree of
BT
ZERO X7.0 / / Put zero in Ci,k
SECOND Xl LOAD X3.0 / / Get Ai,j
lVIUL X5.0 / / ::.Vlultiply by Bk ,l
ADD~ X7.0
/ / Add and autostore
to Ci,k
X5 IVIOD =1
/ / Next consider
B k ,j+1T
X3 JNL SECOND / / Next consider
A i ,Hl
CONT
/ / if no more j continue here
X4 lVIOD = 1
/ / Next consider
B k +1 ,l
X7 JNL FIRST
/ / Consider Ci ,k+l if
any left
X6 IVIOD = 1
/ / Consider Ci+l,k
X4 COpy X9
/ / S tart over with
Bo,o
X2 JNL BEGIN
/ / Consider A i+l ,j if
any left.
This routine destroys pointers located in X2, X4, and
X6. The steps
MUL X5.0
X5 MOD=l
may be combined into l\1UL! X5 which uses a variant
option for the arithmetic operation code to modify the
address word in X5 after the element has been fetched.
Example 5-Use of the stack
The stack may be used for intermediate storage in
the following manner. It is first necessary to get the
operand in a scratchpad register. Suppose we wish to
The Rice Research Computer
stack X5. Then we write X5 STORE X0. The contents
of X5 is pushed onto the stack. On the other hand, X5
STORE X0.7 stores the contents of X5 in the seventh
location of the stack without altering other elements.
If there are less than seven elements on the accessible
stack an exception occurs. The top element of the stack
may be changed without pushing by the use of X5
STOREX0.1.
Elements are removed from the stack in an analogous
manner. For example, ADD X0 adds the top element
of the stack to the accumulator and pops the top
element. ADD X0.1 adds the top element of the stack
but does not pop it; ADD X0.7 adds the seventh element of the stack without affecting the stack.
This stack arrangement affords many conveniences
in arithmetic operations. An example of this is the
instruction save and fetch. Take as an example X2
SVF X3.12. This instruction gets the twelfth element
of the array pointed to by X3, after saving the old
value of X2 on the stack, and places the new value in
X2. In compiling, the instruction Xl SVF Xi.N will
occur frequently. Intermediate results can be saved
on the stack for later use. Alternatively, when the value
is to be used many times they can be stored in a register
using COPY.
The stack is also useful in control actions. The
instruction JUMP AND SET MARK, e.g., 4 JSM
LABEL, causes a control word to be made up pointing
to the next sequential instruction. This control word
contains the current mode, the current condition code,
and the mark specified by the JS1\rI instruction, in this
case 4. The chain field is loaded with the current value
of L(X0). The resulting control word is pushed on the
stack. X0 is then updated to reflect a new stack regime.
L(X0) is set to 0 and B is set to the location that is one
less than that occupied by the control word. This stack
) regime is completely disconnected from the prior one;
there is no way save through the registers or memory
constants to reach any of the members of the previous
stack regime (see Figure 6). One can return to the previous environment by the use of the return instruction:
RET 4. The previous control word is found by examining the address B(X0) + L(X0) + 1. This address contains the last control word or a partition word pointing
to another section of the stack regime or a partition
word marking the absolute beginning of the stack. If a
control word occupies this position, B(X0) is set to point
to this address. The chain field of the control word is
copied into L(X0), the mode field to the mode register,
the condition code to the condition code register, and the
21 bit address to the program counter. If the mark field
is less than the literal used with the return instruction,
the computer resumes processing. Otherwise the process
375
500 BEGINNING OF STACK
REGIME 1
REGIME 2
310
REGIME 3
TOPOF SiACK
100 END OF STACK
Figure 6-The use of the stack in programming systems
described above is repeated until a partition word
marking the absolute beginning of stack is encountered.
If the beginning of stack is encountered, an error
exception will result. This form of return has the
advantage that it is efficient and can be used to return
several levels in a block structured language.
Relative addressing
In an earlier section we stated that all addressing
was done via an address word. In fact this is not quite
true. Addresses may be relative to the program counter
or to the location in which the address word or control
word is stored. One may then jump minus five halfword
instructions. This feature was available on the R-1 in
1959 and made possible the development of very
efficient relocatable code. It is frequently found on
machines today. One can also access fullword data in
the same manner so that constants can be stored with
the code.
In the same way relative codewords and addresswords
can be used to address other quantities. The address of
the location in which the address or control word is
stored must be determinable by the computer. An
offset relative to this address is used to point to the
jump location or to the data. This feature makes
poss~ble relocation of large blocks of data in a very
efficient manner and minimizes the number of address
words which contain absolute addresses. This is
important because it drastically reduces overhead in the
reorganization of storage. Only a few locations need to
be modified to relocate all programs and their data.
Chained Addressing
A second kind of addressing is also provided. Chained
addressing provides for efficient parameter passing
376
Spring Joint Computer Conference, 1972
mechanisms, particularly of the call by reference
variety. The addressing algorithm is modified to include
indirection. When a chained address or control word is
encountered the machine causes an indirect reference
through the address or control word to the next quantity. A counter is employed to assure that chaining
beyond 32 levels is not allowed. Special instructions are
employed to defeat chaining for loading and storing.
These instructions allow complete control of the
addressing mechanism.
Miscellaneous instructions
The R-2 is designed to be used with compilers rather
than assemblers. It has many useful miscellaneous instructions including reverse divide, variants of preand post-complemented addition and logical operations,
and integer and floating multiplication and division.
Various instructions allow extraction and replacement
of the predefined data and instruction fields. A large
number of shift, bit count, and test instructions
complement the arithmetic and logical set of instructions, thus facilitating the development of operating
systems and compilers.
Ramifications of tagged architecture in the R-2
The use of tagged architecture has many ramifications. In a future paper we will discuss them more fully.
Here we will comment on a few of interest to those who
write or use compilers and operating systems or who
must debug programs.
Compilers can be made simple and more efficient.
Since tags indicate what each numeric quantity is and
since the hardware will correctly perform the appropriate operation on all legal combinations of data, the
compiler need not deal with semantic operations
referring to basic types of identifiers. This is now
handled conveniently at run-time. The problem of
temporary storage is largely solved by the stack whose
implementation is greatly facilitated by the address
calculator and the tagged address type. The tagged
registers allow simple manipulation and mechanization
of vector and array operations and allow dynamic
variables much more freedom than do previous machines. They also permit the optimum calculation of
expressions of type address and type numeric. Finally,
tagged addresses and numbers greatly simplify the
problems of run-time systems for use with particular
compilers; note that even undefined quantities have a
distinct representation.
Operating system design is facilitated by tagging.
The difference between a label and an address can be
determined at run-time. This means that one cannot
jump through an address word or a number but only
to approved points in a subroutine via a control word.
Attempting to do otherwise produces an interrupt.
Secondly, addresses can only be manipulated by
means of a special set of instructions. The more powerful
instructions may be denied to the user and he may be
given the use of lVIOD, TAG, and LIJ\L TAG is an
instruction with an immediate operand. The compiler
monitors all TAG instructions assuring that no unauthorized user can construct illegal address or control
words. Any user may employ MOD or LIlVL They
modify an address to point to a subset of the elements
in an addressed space. Since an unprivileged user may
never generate an address outside the initial space to
which he has been given access, protection of user
programs is enhanced if not insured. This protection
mechanism appears to be exactly what is required for
recursively defined operating systems.
The design and use of debugging systems is greatly
simplified. A program can be written to dump core
memory using the type of each datum. This means that
complex, double precision, floating, integer, and undefined types can be used to interpret the data contained in the cells. This can be used in the analysis of
dumps. Addresses and labels are also distinct in this
scheme; the fact that they are not in other systems
has been a recurring problem for those who must debug.
Dynamic debugging is also easily implemented. By
the use of symbolic locations, relative locations, or
absolute locations, data or instructions may be tagged
with software tags. Whenever such tagged data is
encountered, an interrupt occurs. The programmer may
supply his own programs to analyze or monitor the data
values which are encountered. The software tag in
each of the instructions may also be set to cause interrupts related to tracing any or all control actions.
Again the user may write a program to analyze the
results. Finally since the tag bits may be set either at
compile time by the compiler, or arbitrarily at runtime by the user through the operating system, code
which is verified as being correct need not be recompiled,
thus simplifying and expediting the process of
debugging.
SUMMARY
This paper has reported the state of the Rice Research
Computer in its development. It has emphasized the
features of the R-2 which arise from accepting the
principle of tagged architecture. For a particular
implementation, we have shown by example the power
of tagged architecture in application to compilers,
operating systems, and debugging systems.
The Rice Research Computer
ACKNOWLEDG1VIENTS
I would like to acknowledge the work of the designers
of R-2 including John Iliffe, I.C.L. (London, England),
Walter Orvedahl (Colorado State University), Dr.
Sigsby Rusk (Rice University), Douglass DeLong
(Graduate Student, Rice University), Dr. Ernest
Sibert (Syracuse University), and Dr. Robert C.
l\1:innick (Rice University). Also, lowe thanks to Dr.
J. Robert Jump and the graduate and undergraduate
students at the Rice University Laboratory for Computer Science and Engineering who have made and are
making the machine a reality.
REFERENCES
1 J K ILIFFE
Basic machine principles
American Elsevier New York 1968
377
2 J K ILIFFE
Elements of BLM
Computer Journal 12 August 1969 pp 251-258
3 A narrative description of the Burroughs B5500 disk file
master control program
Burroughs Corporation Detroit Michigan Revised October
1966
4 Basic machine operation
Rice University Computer Project Houston Texas January
1962
5 TR440 eigenschaften des RD441
AEG Telefunken Manual DBS 1800470 Konstanz
Germany March 1970 (German)
6 Burroughs B6500 information processing systems reference
manual
Burroughs Corporation Detroit Michigan 1969
7 J G CLEARY
Process handling on the Burroughs B6500
Proceedings of the Fourth Australian Computer Conference
Griffin Press Adelaide South Australia 1969 pp 231-239
8 E I ORGANICK J G CLEARY
A data structure model of the B6700 computer system
SIGPLAN Symposium on Data Structures and Program
Languages ACM New York New York 1971 pp 83-145
A generative CAl tutor for computer
science concepts*
by ELLIOT B. KOFFMAN
University of Connecticut
Storrs, Connecticut
petence is often acquired through a process of "learning
by doing." Consequently, it is essential that the CAl
system be capable of presenting a wide variety of
problems and solutions to the student. Reprogramming
each problem and its solution in a manner suitable for
presentation by CAl would be extremely inefficient.
It is precisely for these reasons that generative CAl
systems have recently become of great interest. Generative systems are capable of generating a series of
questions (and 'answers to these questions) as a function
of the student interaction. These systems can be
divided into two classes. Those which are oriented toward the "soft-sciences" and textual material and
those which are more concerned with numerical manipulations and quantitative material.
CarbonelP and Wexler2 have designed generative
CAl systems which have been used to teach concepts
in geography. These systems are organized around an
information structure or network. Carbonell uses the
semantic network developed by Quillian. 3
Once the information network has been specified,
these systems are capable of generating a sequence of
questions for a student. As each question is generated,
the answer is retrieved for comparison with the student's response. If the student is incorrect, Wexler's
system is capable of providing individualized remedial
comments. This would consist of either a correct and
relevant statement using the student's incorrect answer
or a systematic presentation of the steps performed by
the system in deriving the correct solution. Both these
systems allow the student to interrupt and pursue
topics which interest him at greater depth.
The potential for incorporating generative CAl in
the "hard sciences" is extensive. Algorithms for solution of classes of problems could be in~orporated into
CAl systems. In some cases, solution techniques might
be sufficiently complex that heuristic programs would
be necessary. Examples of the latter case would be
teaching symbolic integration or proving theorems. In
INTRODUCTION
Limited progress has been made in software for computer-assisted instruction. Frame-oriented CAl systems
have dominated the field. These systems function as
mechanized programmed texts and utilize the computational power of the computer to a minimal extent. In
addition, they are difficult to modify and tend to provide a fairly fixed instructional sequence.
The conventional frame-oriented CAl system is organized as a series of frames. A frame may present a
piece of information and/or ask a question. The questions are normally objective and often are of the multiple-choice type. The frames are usually linked in a
sequential fashion and a student will cycle through
them one at a time. Frames may be presented on a
teletype, a graphical display, a slide projector, via an
audio track, or any combination of the above.
There are severe problems inherent in systems of
this type. All questions must be specified by the courseauthor as well as a set of anticipated student responses
to each question. If branching is to occur, explicit
instructions must be given indicating the performance
criteria for a branch and the new continuation point
in the program.
Since everything must be specified in advance, extensive time must be spent in preparing course material
for presentation. Furthermore, once programmed this
material has very little flexibility. Modifying the set of
questions to be asked of the student or the material
to be presented is a major undertaking and much reprogramming must be done.
This type of system is not very useful in teaching
quantitative courses. Subject areas such as engineering
or the physical sciences are concerned with teaching
techniques of problem solving. Problem solving com-
* This research is sponsored by the Connecticut Research Commission under Grant RSA-71-7.
379
380
Spring Joint Computer Conference, 1972
any event, CAl systems organized around a set of
algorithms would have the capability to generate and
solve a wide range of problems.
An extensive project in the subject area of analytical
geometry has been described by Utta1. 4 His system is
capable of generating twelve problem types which are
representative of the problems found in an analytical
geometry course. These problems usually involve an
expression or graphical representation of a particular
conic section. The expression is obtained from the general quadratic equation: AX2+BY2+CX+DY +E=O.
The required expression is obtained by setting certain coefficients to 0 and selecting the others at random.
The complexity of the equation generated depends on
the constraints imposed on the coefficients. For example, to generate circles centered at the origin, A = B
and C=D=O.
Associated with each of the twelve problem types is
an answer routine. The routine which determines if a
randomly generated point (x,y) falls on the locus
represented by a randomly generated equation simply
plugs this point into the equation. The expression
generator itself is used as the answer routine when the
student is asked to supply the equation for a conic
section with given standard characteristics.
The following sections will describe a generative
tutor that has been used in an introductory computer
science course. It has been used to teach concepts of
digital circuit design as well as to introduce students to
machine language programming. Because of the large
number of concepts covered, an intelligent "concept
selector" has been designed which attempts to tailor
the current instruction each student receives to fit his
past performance record.
GENERATIVE CAl IN DIGITAL SYSTEMS
The system is designed to be extremely flexible in
that it can completely control the progress of a student
through the course, selecting concepts for study on an
individual basis and generating problems. Alternatively,
the stud~nt can assume the initiative and determine
his own areas of study and/or supply his own problems.
In addition, the system also operates in a "problemsolver" mode. In this mode, the student specifies the
concept area and his problem, and the system will
crank out the solution without further interaction. It is
anticipated that students in later courses and the digital
laboratory will utilize this mode for solving complex
minimization problems and determining the relative
merits of different state assignments.
Figure 1 is a block diagram of the systEm functions.
Subsequent sections of this paper will describe how
I
-- -
-------.-------,
,------~---
.__----l.---.
- --- -,
I
I
I
,
I
,
I
UPDATING DATA
SYSTEM CONTROL
STUDENT CONTROL IN PROBLEM SOLVER MODE
Figure I-System block diagram
these functions are accomplished. As has been mentioned, the student can assume the initiative and bypass
the Concept Selector and/or Problem Generator (indicated by dashed lines from Student box). The bottom
part of Figure 1 shows the student exercising full control in the problem-solver mode.
When the system is in control of the interaction, it
attempts to individualize the depth and pace of instruction presented to each student. A model of each
student is kept which summarizes his past performance
in each of the course concepts. Table I shows the contents of a student record.
In addition, the system is supplied with a concept
tree which indicates the degree of complexity (plateau)
of a concept and its relationship with other concepts
in the course. A sample tree for the concepts currently
covered is shown in Figure 2. This, of course, represents
the author's interpretation of the relationship between
course concepts. There are alternate interpretations
which are just as valid.
The system uses each student's record to determine
how quickly he should progress through the tree of
concepts, the particular path which should be followed,
the degree of difficulty of the problem to be generated,
and the depth of monitoring and explanation of the
problem solution.
Figure 3 is a flow-chart of the overall operation of
the system.
PROBLEM-SOLVER/MONITOR
The course is organized as a set of solution algorithms.
Normally there is a single algorithm for each major
concept of the course. The algorithms solve the problems much as a student would, breaking each problem
Generative CAl Computer for Computer Science Concepts
TABLE I-Student Record
Student Name E B Koffman Master Ave. 1.8 Current Plateau 5
Concept #1
Level
Last level change
Weigh ted Av. level
change
Date of last call
Sequential order of
last call
No. of times called
in 0-1 range
No. of times called
in 1-2 range
No. of times called
in 2-3 range
No. of problems
generated
Concept #2 ... Concept #30
2.2
.1
.5
1.5
.5
3/15
25
3/17
31
4/20
48
2
2
3
2
1
0
0
0
0
2
3
3
.6
0.5
-.2
-.1
381
If the student is questioned, then his answer is compared with the system's solution. If the student is correct, his level is increased; if he is incorrect, he will
receive a remedial comment explaining the correct
solution procedure and his level for that concept will be
decreased. The higher a student's level, the fewer
questions he will be asked. When the student reaches
a level of 3 in a concept, the system will solve subsequent problems dealing with this concept for him.
down into a series of sub-tasks. After each sub-task
is accomplished, a decision is made whether or not to
question the student on this part of the problem solution. This decision is based on the student's current
level of achievement (a number between 0 and 3) in
the concept.
Figure 3-System flow chart
LEGEND:
~.-[§J
~J
Note:
CONCEPT A IS A PREREQUISITE OF CONCEPT B.
CONCEPT A IS A PREREQUISITE OF CONCEPT B;
CONCEPT A MAY BE USED AS A SUB-CONCEPT BY B.
The relation "is a prerequisite of" is transitive
(A is a prerequisite of B, B is a prerequisite of C, Implies A Is a
prerequisite of C)
Figure 2-Concept tree
Table II presents examples of different degrees of
interaction with a student in an octal addition problem.
The first character of all student inputs is underscored.
A single algorithm solves binary, octal, and hexadecimal adcij.tion problems. The decimal sum of each
pair of digits and old carry is first calculated. The corresponding new carry and sum digits in the problem
base is then determined.
A student with level less than 1· is quizzed on all details of this algorithm; while, the initial decimal calculation is skipped for students with level between 1 and
2. The student with level between 2 and 3 is asked
only for his final result; whereas, the final result is
generated for a student with level equal to 3. The
382
Spring Joint Computer Conference, 1972
TABLE II-Different Degrees of Interaction
Problem: Form the sum of 75.3,2.7 in the base 8.
LEVEL RANGE 0-1
Modify 2.7 for addition to 75.3
Q2.7
Correct. The rightmost digit is digit #1.
What is the decimal sum of digit #1
of 75.3 and digit #1 of 02.7?
8
No. Their decimal sum is 3+7 or 10.
What is digit #1 of the sum in the base 8?
1
-
No. The decimal number 10 is equivalent to 12 in the base 8.
Digit #1 is 2.
'
What is the carry to digit #2?
1
-
generated if one of the excitations match and the correct answer for the non-matching excitation is "D"
(a don't care). System response B is presented for all
other types of errors. The additional information presented to students with level < 1 is obtained by calling
the Flip-Flop analysis algorithm in the problem-solver
mode. This algorithm determines the next state which
would result from the current state if the student's
values of the Flip-Flop excitations were applied.
The magnitudes of the increment and decrement for
correct and incorrect answers respectively are also individualized to fit the student's past performance.
They are calculated for the particular concept which
has been selected as follows:
Correct. What is the decimal sum of digit #2 of 75.3 and digit #2
of 02.7 and the carry from digit #1?
LEVEL RANGE 1-2
The rightmost digit is digit #1.
What is digit #1 of the sum in the base 8?
2
-
Correct. What is the carry to digit #2?
Q
No. 3+7 = 12 in the base 8.
The carry to digit #2 is 1.
What is digit #2 of the sum in the base 8?
LEVEL RANGE 2-3
What is the complete sum of 75.3, 02.7 in the base 8?
Z7.2
No. The sum of 75.3, 02.7 is 100.2 in the base 8.
LEVEL RANGE'?3
The sum of 75.3, 02.7 is 100.2 in the base 8.
amount of interaction a student receives will vary as
the problem solution progresses and his level changes
from one range to the next.
In this manner, the amount of monitoring is dynamically adapted to fit a student's current level of
achievement. Often a solution algorithm will utilize an
algorithm dealing with another course concept as a
subroutine. When this happens, the student's level in
the sub-concept will control the depth of instruction.
If he has mastered the sub-concept (level ~3), this
portion of the solution will be provided for him.
When a student response is incorrect, he receives an
individualized remedial comment which explains the
system's derived answer. For example, in a problem
utilizing the Flip-Flop Design algorithm, the student
would be given the current state and desired next
state and asked to supply the required values of the
Flip-Flop excitations. Table III presents some of the
alternative forms of feedback which might be presented depending on a student's level and his answer.
The correct solution in this case is derived through
a table lookup. System response A is automatically
Increment = K2· K1
Decrement = K2/K1
where
KP= 1+ WN+AL and
.5~KP~2,
K2= 1-.5R
AL = last change in level
W N = weighted average level change for N uses
of a concept
W _ (N -1) . W N-l + 2· AL
N-
N+1
R = (Number of uses of concept at present
level range) / N
(1)
If the student's level in a concept has been consistently increasing, W Nand AL will be positive and K12
will tend to be large. K12 represents the ratio of Increment to Decrement. Consequently, a student who has
been performing well in a concept will be rewarded
more for a correct answer than he is penalized for an
incorrect one. Thus, he is receiving the benefit of the
doubt for an occasional incorrect answer and progresses more rapidly to the problem-solver mode for
that concept. The opposite is true for a student who
has been performing poorly. This will enable him to
drop quickly to a lower level at which he will receive
further monitoring and instruction if he continues to
answer incorrectly.
R represents the stability of the current level for the
concept in question. K2 assumes values between .5 and
1.0, the higher values representing a greater degree of
instability. Consequently, when the current level is in
a relatively unused or unstable level range, the Increment and Decrement will both tend to be larger than
when the current level appears to be a stable one. This
makes it easier for a student to move out of a new
level range; whereas, he must answer more questions
correctly (or incorrectly) if he is to move out of a level
Generative CAl Computer for Computer Science Concepts
383
TABLE III
QUESTION
The current state of JK Flip-Flop 1 is
The next state should be 1.
What are the values of J1, K1?
o.
STUDENT ANSWER: J1 = 1, K1 = 1
SYSTEM RESPONSE A: Your answer is correct, however, a better answer would be J1 = 1, K1 =D.
(D symbolizes a "don't care" condition)
I
The remedial feedback generated for a wrong answer to the above question follows:
STUDENT ANSWER: J1=D, K1=1
SYSTEM RESPONSE B: Wrong. To bring a JK Flip-Flop from the 0 to 1 state, set J=l and K=D.
ADDITIONAL RESPONSE FOR LEVELO.
K = 2 if the concept resides at a lower plateau and
AL 1, AM and (~L + W N) will be opposite in sign.
If the system selects the concept from the student's
current plateau, K will be 1. If the student's level increases and W N is also positive, his master average will
decrease. If the student has selected the concept from
a higher plateau and ~L > 0, the magnitude of the decrease is doubled as this indicates the student is ready
to progress more quickly. If the concept is above his
current plateau and he does poorly (~L < 0), he is not
penalized by an increase in his master average (K = 0).
However, if the concept is a remedial one (below his
current plateau) and (AL+ W N) is negative, the increase in his master average is twice what it would be
for the same performance in a concept from his current
plateau.
The effect of the term (1.1- R) is to cause those
changes, which occur when in a relatively new level
range, to have a greater influence on the master average. This is reasonable since a student who performs
384
Spring Joint Computer Conference, 1972
TABLE IV-Sample Problems Generated
1. Convert the decimal number 65.75 to the base 8.
2. Calculate 75.3 -24.56 in the base 8 using 8's complement
subtraction.
3. Derive the truth table for ((PV( -, Q)) j( -, (RAQ)))
4. Design a combinational circuit such that:
Input word A is 2 bits long. Input word B is 2 bits long.
The output X=A+B. The output Y=l if A 1. The probability
of 3 variables is .5 for 0::::; level::::; 2 and increases to 1 for
level> 2. The probability of 4 variables is .5 for 1::::;
level::::; 2 and 0 elsewhere.
The incomplete logical expression is scanned from
left to right for non-terminals. When the non-terminal
symbol A is found (Pa+P b) represents the probability
of increasing the length of the expression where:
PaCt) =Pb(t) =.75 c/(n(t)+1.5c-1.5)
(3)
where n (t) is the current length and c is the number of
variables in the expression (c~2)
Since (Pa+P b) is inversely proportional to the current
length, the logical expressions do not become unwieldy.
If the random number generated indicates that the
TABLE V
Probability: Rewrite rule
1:
Pa:
P b:
P C1 :
P C2 :
Pcs:
~~A
A~(A*A)
A~( -,A)
A~P
A~Q
A~R
Pc,: A~S
P d : *~V (or)
P d: *~A (and)
Pe: *~ i (NAND)
Pe: *~ t (NOR)
Pe: *~$ (exclusive or)
Constraints O:::;P a , Pb, P Ci , Pd, P e :::;l
Pa+Pb+ LiPc i=l
2Pd +3P e=1
Generative CAl Computer for Computer Science Concepts
385
TABLE VI-Example of Student Interaction With System Executive
IS THIS THE FIRST TIME YOU HAVE USED CAl?
no
TYPE IN YOUR NAME
ebkoffman
AFTER REVIEWING YOUR RECORD, I HAVE SELECTED CONCEPT #9.
BINARY MULTIPLICATION
IS THIS OK?
yes
FORM THE PRODUCT OF THE BINARY NUMBERS 101.01, 1.001
IGNORING BINARY POINTS, WHAT IS THE PARTIAL PRODUCT DUE TO BIT 1 OF THE MULTIPLIER 1001?
10101
CORRECT
WHAT IS THE PARTIAL SUM SO FAR?
TYPE F TO GO FASTER
(Instead of answering the previous question, the student has hit the console attention button.
S TO GO SLOWER
The system attempts to determine his wishes.)
Q TO QUIT
f
WHAT IS THE PRODUCT OF 101.01, 1.001?
(The student's level has been increased by 1)
101.11101
CORRECT
YOUR LEVEL IN BINARY MULTIPLICATION INCREASED BY 1.2 to 2.3
I HAVE SELECTED CONCEPT #12
KARNAUGH MAPS
OK?
no
WOULD YOU LIKE TO PICK YOUR OWN CONCEPT?
yes
DO YOU KNOW THE CONCEPT NUMBER?
no
HERE ARE THE CONCEPTS CURRENTLY COVERED
(This printout would be omitted if the student had answered yes.)
1. REGISTER 'ANDING'
15. STATE TABLE TO SEQUENTIAL DESIGN
WHICH CONCEPT NUMBER WOULD YOU LIKE?
15
FINE. THIS IS ABOVE YOUR CURRENT PLATEAU, BUT LET'S TRY IT.
DO YOU WANT ME TO GENERATE A PROBLEM?
no
HOW MANY STATES IN YOUR STATE TABLE?
(Student specifies problem parameters and works through solution)
5
HOW MANY INPUT BITS?
WOULD YOU LIKE TO CONTINUE PICKING CONCEPTS?
no
I HAVE SELECTED CONCEPT #12
KARNAUGH MAPS
OK?
yes
MINIMIZE A FUNCTION WHICH HAS 2,5,6,7 AS MINTERMS USING THE KARNAUGH MAP METHOD
HERE IS THE KARNAUGH MAP
(A student with level <1 in this concept would be tested on his ability to construct the map)
expression should not be extended, one of the variables
P, Q, R, S replaces A.
If the non-terminal symbol is *, one of the five
binary operators is selected. P e increases with level,
while, P d decreases. Hence, the more difficult operators
are more likely in expressions generated for the students
at higher levels of achievement.
Modifications of this technique are used to generate
problems for combinational design and sequential design concepts. For the earlier number system manipulations, it is necessary to select a base for the number
system and concatenate a set of valid digits from that
base. As might be expected, the hexadecimal base appears more frequently at higher levels and the numbers
to be manipulated are somewhat larger than those
generated for lower levels.
386
Spring Joint Computer Conference, 1972
IMPLEMENTATION
The system has been implemented on the IBM
360/65 at the University of Connecticut. It is programmed in the Conversational Programming System
(CPS) .5 CPS is a dialect of PL/I and includes some
string processing features which have been extremely
useful in programming this system.
There are forty IBM 2741 terminals connected to the
main computer. CPS operates in low-speed core and
each user is allowed a maximum of 12 pages of core
(48 K bytes). Currently, space is reserved for fifty
student records on disk. There is room for thirty concepts on the tree. There is an instructor mode which
permits easy modification of the concept tree. Student '
records can also be printed out while in the instructor
mode.
Students can log onto the system any time from
9 A.M. to 11 P.M. The average student session is about
an hour in length. The student's record is automatically
updated every 15 minutes so that the results of a complete session will not be lost in the event of a system
failure.
The course coverage includes familiarizing the students with the binary, octal, and hexadecimal number
systems. The students also learn how to use truth
tables to represent logical functions. They learn techniques of combinational design and how to minimize
the logic elements needed for a design problem. They
are introduced to Flip-Flops and the design of sequential circuits. They also learn about machine-language
programming by analyzing short program segments
and indicating the changes incurred in various registers
as these segments a:r;e executed.
Reaction from the students using the system has been
very favorable to date. It has been used as a supplement to the regular lectures and homework assignments covering the material up through plateau four
of the concept tree (Figure 2). The problem generation
capability was not fully implemented which required
students to insert their own problem parameters as
they were requested by the problem solution algorithms.
The major complaint of the students was the slowness
of the system. This has been alleviated considerably
now that problems are generated for all system
concepts.
The system responds to a student input typically in
5 seconds or less. In a couple of the more complex solution algorithms (tabular minimization for example),
a student working in the problem-solver mode may have
to wait up to three minutes for a problem solution.
Students at lower levels very rarely have to wait more
than thirty seconds as the solution algorithms areexecuted in a piecemeal fashion. This, of course, could
be improved substantially if compiled code (CPS
is an interpretive system) and high-speed core were
available.
During the current semester, a student group is
using the CAl system in lieu of regular homework assignments. The complete tree of concepts is available.
Table VI is an example of the dialogue that occurs between the system executive and the student. The
system's messages are capitalized. All student inputs
are preceded by a "-." Table VII presents examples
of the interaction that takes place during a problem
solution.
CONCLUSIONS AND FUTURE WORK
A generative system for teaching digital computer
concepts has been described. This system includes an
intelligent concept selection routine which attempts to
individualize the path taken by each student through
the tree of course concepts. In addition, the instruction
and monitoring provided by each solution algorithm
is dynamically adapted to suit a student's current level
of knowledge. The system can also operate as a problemsolver and will provide portions of the solution process
which have already been mastered by a student.
Expansion of the CAl system is continuing. The
majority of the portion which teaches logical design
has been completed. Students have also been exposed
to an on-line simulator of the Digital Equipment
Corporation PDP-8 which teaches machine-language
programming.
Future efforts in this area will lead to a generative
system which produces programming problems. As the
problem is generated, a sequence of sub-tasks similar to
a flow chart will also be produced. This will be used as
the basis for teaching machine language programming
and testing students' solutions. As before, portions of
the program will be generated for the student and he
will be required to supply the rest. The amount re,;.
quired from him will decrease as his level increases.
It is also anticipated that there will be further improvement of the concept selection algorithm. It is
likely that performance can be improved by incorporating additional parameters into the algorithm as well as
by adjusting the weights of the parameters currently
used.
The techniques discussed in this paper could readily
be applied to other courses which teach techniques of
solving problems. In fact, several courses could be administered simultaneously by the ~oncept selection
routine. A concept tree would have to be specified for
each course together with the algorithms necessary for
generating and solving problems.
Generative CAl Computer for Computer Science Concepts
The initial burden on the course designer is, perhaps,
greater than in a frame-oriented system· as he must
program general solution. algorithms rather than a
representative set of questions and anticipated replies.
It is possible that a "canned" solution program (such
as ECAP for circuit analysis) could be convprtpd into
a teaching program by first segmenting it into course
concepts. Each concept would be modified by inserting
TABLE VII
Example I-Sequent.ial Circuit Analysis
DERIVE THE TRANSITION TABLE FOR A SEQUENTIAL NETWORK WITH 2 FLIP FLOPS SUCH THAT:
J1 = (Y2 \ X)
KI = (YI \ Y2)
D2 = (-, X)
AND THE OUTPUT Z=X & (-, Y2)
THE TRUTH TABLE IS SET UP AS FOLLOWS:
\
\ ROW
\ 0
TYPE
\ CURRENT
\ INP STATE (t)
\
X Y1 Y2
\
0 0 0
IN JI
\ CONTROLS \
NEXT
\
At (t)
\ STATE
\ JI KI D2 \ YI
\
\ CURRENT \
U+I) \ OUTPUT
Y2\
\
Z(t)
\
o
TYPE IN K1
1
NO. YI =0,
TYPE IN D2
Y2 =0
SO(Y1 \ Y2) =0
1
TYPE IN THE NEXT STATE OF FLIP FLOP 1.
1
NO. IF J1 =0 AND KI =0, THE FF STATE REMAINS THE SAME.
TYPE IN THE NEXT STATE OF FLIP FLOP 2.
1
TYPE IN Z(t).
o
\ ROW \ X Y1 Y2\ JI KI D2\ YI Y2\ Z(t) \
\ 0 \ 0 0 0\ 0 0 1\ 0 1\ 0 \
\
1
\ 0
0
1\
1
1
1\
\
387
0 \
(NOTE: BECAUSE LEVEL IS NOW >1, ADDITIONAL INFORMATION HAS BEEN PROVIDED FOR ROW 1)
TYPE IN THE NEXT STATE OF FLIP FLOP 1.
o
NO. IF J1 = 1 AND KI = 1, THE FF CHANGES STATE.
TYPE IN THE NEXT STATE OF FLIP FLOP 2.
1
(NOTE: THIS LINE OF QUESTIONING CONTINUES UNTIL THE STUDENT'S LEVEL IN JK OR D FLIP FLOP
ANALYSIS BECOMES :2::3 OR ROW 7 IS COMPLET.ED.)
ROW \ X YI Y2 \ JI KI D2 \ YI Y2 \ Z(t) \
7 \ 1 1 1\ 1 1 0 \ 0 0 \\ 0 \
NOW WE MUST FORM THE TRANSITION TABLE. THE HEADING FOLLOWS:
\ CURRENT \ CURRENT \
\ STATE \ INPUT \
\ (Y1, Y2) \ X=O X=I\
WHAT IS THE NEXT STATE/CURRENT OUTPUT IF THE CURRENT STATE IS (0,0) AND X=O?
(USE FORMAT (YI(t+I), Y2(t+1))/Z(t))
(0, 0)/1
WRONG. Y2(t+I) =1
Z(t) =0
IF CURRENT STATE =(0, 0) AND X=l?
(1, 0)/0
WRONG. Y2(t+ 1) = 1
\ (Y1, Y2) \ X=O
X=l \
\ (0, 0) \ (0, 1)/0 (1, 1)/0 \
(NOTE: THIS LINE OF QUESTIONING WILL CONTINUE UNTIL THE PROBLEM IS COMPLETED
OR THE STUDENT'S LEVEL BECOMES 2::3.)
388
Spring Joint Computer Conference, 1972
TABLE VII-Continued
Example I-Sequential Circuit Analysis
Example 2-Sequential Circuit Design
DERIVE THE STATE TABLE FOR A SEQUENTIAL CIRCUIT WITH A SINGLE INPUT LINE X.
THE OUTPUT WILL BE 1 WHENEVER THE LAST 4 VALUES OF X HAVE BEEN 1000
HOW MANY STATES ARE NEEDED?
5
WRONG. SINCE THERE ARE 4 BITS IN THE INPUT STRING, 4 STATES ARE NEEDED.
Q 0 IS THE STARTING STATE. QI CORRESPONDS TO THE FIRST I BITS BEING CORRECT.
Q 0 CORRESPONDS TO THE LAST INPUT 0 OR I?
1
WRONG. BEING IN THE STARTING STATE MEANS THE DESIRED SEQUENCE HAS NOT BEGUN,
SO THE LAST INPUT WAS 0
THE STATE IS Q 1 IF THE LAST INPUT WAS _ ?
1
THE STATE IS Q 2 IF THE LAST 2 INPUTS WERE _ ?
11
WRONG
Q 2 CORRESPONDS TO THE PARTIAL SEQUENCE 10
THE STATE IS Q 3 IF THE LAST 3 INPUTS WERE _ ?
100
IN STATE Q 0: IF X=O WHAT IS THE NEXT STATE/OUTPUT?
Q1/0
NO. THE LAST INPUT IS NOT PART OF A DESIRED PARTIAL SEQUENCE.
THE SEQUENTIAL CIRCUIT RETURNS TO THE INITIAL STATE Q 0
IF X=l?
Q1/0
IN STATE Q1: IF X =O?
Q2/0
IF X=l?
QO/O
NO. THE LAST INPUT IS 1
THE NEXT STATE SHOULD BE Q1
IN STATE Q 2: IF X=O?
Q2/0
NO. THE LAST 3 INPUTS ARE 100
THE NEXT STATE SHOULD BE Q 3
IF X=l?
Q1/0
IN STATE Q 3: IF X =O?
QO/O
NO. THE LAST 4 INPUTS ARE THE DESIRED SEQUENCE 1000
THE OUTPUT SHOULD BE 1
IF X=l?
Q1/0
THE FINAL STATE TABLE FOLLOWS:
I CURRENT
STATE
QO
Q1
Q2
Q3
I
I
I
I
I
I
NEXT STATE I
/OUTPUT I
INPUT
X=O
QO/O
Q2/0
Q3/0
QO/1
X=l
Q1/0
Q1/0
Q1/0
Ql/0
requests for student answers after the completion of
each step in the solution process as well as remedial
statements explaining the correct procedure to be followed for each step in the solution. In addition, a pro-
gram statement would have to be included which would
allow this question to be skipped by students above a
specified level of proficiency.
It is felt that the extra effort required to program
Generative CAl Computer for Computer Science Concepts
an algorithm based CAl system is worthwhile as the
end product is a very versatile and flexible teaching
tool.
389
W2= 1 if Qj>O
w2=3 if Qj=O (Indicates concept k j has not been
selected for this student.)
Factor 2 favors the recall of concepts which have not
been used recently.
APPENDIX-CONCEPT SELECTION
(A3)
C ij is the jth concept at Plateau i
Lij is the level of Cij where O:=:; L ij :=:; 3
ni is the number of concepts at Plateau i
Li is the average level of concepts at Plateau i, where
where R j is the stability of concept kj as defined
previously.
W3=
-1
Factor 3 inhibits the use of a concept whose level is in
a relatively stable range.
If 1 is the current plateau, calculate L, where
L=I-1 Li=/ Li and L is the average of all concepts
at and below plateau I.
If L?M, where M is the Master average, then increase 1 by 1; otherwise, 1 does not change.
N ow select the set of candidate concepts K =
{k1, k2, ... , knI } as follows:
Let Sj= {Lxy I (x:=:; I) A (y:=:;nx) A (C Xy is a prerequisite of Cli )} for l:=:;j:=:;nl
Calculate Sj, the mean of Sj
If Sj?M, then k j= Cli , otherwise, k j = Cab where Cab is
the prerequisite concept whose level, Lab, is the smallest
element in Sj.
Given the set of candidate concepts, K, the candidacy
value, Vj, of each concept must be calculated. The
concept, kj, which has the highest candidacy value for
this student is selected. /
V j = L WiFij
i=1
WI
(AI)
= 1 if l1L1j
by JOE K. CLEM A, R. L. DIDDAY and M. WESSLER
Colorado State University
Fort Collins, Colorado
INTRODUCTION
choose efficiently from an infinity of possible deductions
in order to arrive at an answer. At present the limiting
factor in their usefulness is the difficulty in selecting an
appropriate sequence of deductions in a reasonable
length of time.
A question-answering system does not store as such
all information which is available to the user. Instead, it
maintains a compressed data base of compactly coded
facts. 3 ,4,5 The facts may reside in data structures3 ,4,6
such as lists or binary trees. There are many methods
for deducing answers which have not been explicitly
stored in memory. These include:
Computer Aided Instruction (C. A. I.) promIses to
make practical the goal of enabling each student to
receive highly individualized instruction at some
point in his educational career. C. A. I. has evolved over
the last fifteen years from programmed instruction
which itself has had a relatively short history as an
educational procedure.
Programmed instruction has not changed dramatically since the time of Pressey,! who in 1926 used
it as a means of reinforcement in the educational
process. Thirty years later Skinner2 saw the need for
incorporating stimulus materials into a framework of
instructional aids in order to provide education without
a live teacher. However, the ultimate goal of a universal
teaching machine which provides instruction to individuals in arbitrary fields has not yet been achieved.
We consider a universal teaching machine to be one
which may be converted to teach any subject by simply
changing the program data base and which can adapt
the instruction to the needs of each individual student.
It is desirable that the transformation from the natural
language of the subject to the machine language of the
data base be somehow simple.
1. A set of prewritten programs, one for each class
of question. These programs are a permanent
part of the system and do not change from their
initial state.
2. A translator which creates a subprogram each
time a question is input to the system. This
subprogram exists only as long as it is needed to
answer the question.
3. A formal theorem prover using some subset
of current known facts as axioms.
The problem with prewritten subprograms is when
questions arise that require interaction among existing
classes. Either the interaction must be anticipated or
new subprograms must be written. In No. 3 the inference mechanism must be general enough to answer
questions of a variety of types.
An important characteristic of all question-answering
systems is the set of languages programmed into them.
At the most sophisticated level are the dialogue languages3 which include:
TEACHING MACHINES AS QUESTIONANSWERERS
For us the problems faced by a general teaching
machine are similar to those faced by question-answering systems. A question-answering system is one which
accepts information and uses it to answer questions.
Question-answering systems are attempts to construct
and manipulate data bases which are represented as
associations among symbols which have meaning when
humans see them. Newer systems are based on theorem
provers, 3 and when given some input question must
1. A language for introducing facts into the system;
2. A query language to be employed by the user;
3. An answer language to be employed by the
system.
391
392
Spring Joint Computer Conference, 1972
In the process of answering questions the system
may require additional information from the user.
Thus it is necessary that a query language be employed
by the user and an answer language be employed by
the system. 7
Question-answering systems also consist of one or
more internal languages. These are machine languages
which are used as intermediate steps in translation 8
or for calculation and manipulation of data.
The problem of representing data may be derived
into three parts:7 ,10
1. Determining the semantic content of the data;
2. Choosing a language to represent the semantic
content;
3. Choosing an internal representation of the
language chosen above.
For example, the sentence "GASP is F~RTRAN
based." may be expressed by the binary relation "is"
as applied to the subject "GASP" and the predicate
"F~RTRAN based." In choosing a language to express
semantic content we might use the notation of symbolic
logic, and in choosing an internal representation we
might express a series of binary operations as a binary
tree structure. 9 ,11
OUR APPROACH
A teaching program can be structured so that the
burden of finding a path through the data, i.e., from
question to answer, is placed on the student. To put it
another way, we can generate proofs at random. Of
course we will not know what theorem we have proven
(what question we have answered) until we are through,
but this seems to be the way that human teachers
operate anyway.
Currently we plan to represent a topic as an ordered
set of information units called concepts. A concept
consists of an ordered triple (a production), a string of
symbols called the question format, a list of concept
labels called the error list, and an integer weight which
serves as a measure of how well the student knows the
concept.
In operation the system will be able to access a subset
of concepts, namely those it has introduced so far.
Associated with each student is a vector, the elements
of which serve as the weights of each concept in the topic
when he is using the system. When the student is asked
a question, the system selects a concept with a probability skewed by his weight vector. 13 ,14,15,16 This
involves Monte Carlo methods and techniques for
generating pseudorandom numbers. A certain number
of deductions are then made, again chosen according
to the weighted distribution. As each deduction is
performed, the question format of each successive
concept is taken into account so as to generate a
reasonably well-stated question. At some point in the
random deduction process a deduction is not made
according to the production associated with the
current concept. Instead, an alternate concept is
chosen from the error list, and its production is carried
out next. This allows the use of "what is wrong
with ... ?" type questions which we will demonstrate
later.
When a student's error vector fits certain criteria,
a new concept will then be introduced and used (with
high probability) in the question generation process. It
is our basic assumption that if a student can answer
arbitrary questions which result from associations
among a basic collection of concepts, he has learned the
topic. It is in this respect that we call our programs
teaching programs.
.
Where do concepts come from? Unlike the designers
of question-answering systems, we make no effort to
find an elegant or concise representation. We believe
that concepts should be the embodiment of a global
model of the topic encoded in "symbology" which is as
close to the natural language as possible. We further
envision that such a program could be developed in the
following way.
Experts in a field such as mathematics, programming,
etc., will be engaged to extract from their topic a set of
concepts which describe it. By "describe" w,e mean
that the concepts they provide can potentially lead to
the derivation of all facts that they are trying to teach
in their subject area. We can think of the topic as a
vector space and the concepts as a set of basic vectors
which describe it. We imagine that the process of
extraction will be done on-line, i.e., at any point the
designer can interrogate the concepts he has previously
defined in order to see what, in fact, can be derived
from them. Thus he can refine concepts which lead to
false deductions.
It has been implicitly assumed that we can embody
everything necessary about a topic within a reasonable
number of concepts. Also, the usefulness of this technique depends on its efficient implementation so that a
large number of students can interact with the program
simultaneously and economically. The former requirement dictates that the productions associated with each
concept be potentially powerful. The latter requirement
dictates that they be easily manipulated. A similar
problem is faced by those who write the software for
computer languages. ALGOL is represented as a
UNITEAM
"context-free" (Chomsky Type 2) set of productions, as
opposed to Chomsky Type 1 which is "context sensitive," which are easy to manipulate but which do not
completely specify the language. Context sensitive
aspects of the language such as the requirement that
array sizes be explicitly declared have been shelved
away in symbol manipulation routines, etc.
This solution is one we cannot take. Our goal is to
expose all aspects of the subject within the framework of
these concepts. We apparently will be forced to use a
context sensitive scheme in every interesting case.
In Phase 2 we are currently using techniques similar
to those used in compilers for languages expressed as
context free grammars (Chomsky Type 2). Since there
are also global (context sensitive) features, we make a
slight addition. A typical production is
/line/ IS UNIQUE (jstatement number/Oj
statement/CR
which would appear
form17 as
/line/
COMPLETED WORK
In order to test our approach, we have chosen to
design a program, UNITEAM, which teaches the
simple programming language BASIC. We have further
simplified our immediate goal, choosing to divide the
teaching into three phases. We hope that those phases
can eventually be included in one general framework
which will be applied to a broad range of topics. Phase
1 we term "motivational" in that we are trying to
relate the new words "computer", "memory", "word",
"I/O", etc., both to things with which the student is
already familiar and to each other.
In Phase 2 the syntax of the language and its semantics with respect to the concepts of Phase 1 are introduced. In Phase 3 the semantics in terms of the world
and more global techniques of programming are
emphasized. The following reports our work in Phase 2,
mentioning our approach to the other two phases only
in passing.
Sample productions belonging to concepts which will
be stressed in Phase 1 are things like:
COMPUTER HAS-AS-PART MEMORY
COMPUTER HAS-AS-PART CONTROLLER
COMPUTER HAS-FUNCTION PERFORM
OPERATION
etc.
Sample questions might be something like:
There is much work to be done on this phase which
is the most general phase. For example, we must understand what effect allowing various verbs (second
element of the production) has on the system. In
Phase 2 we deal almost exclusively with productions
which have the same verb.
:: =
III
/statement
traditional Backus-Naur
number/statement/OR,
and says that a /line/ consists of a/statement number/,
a /statement/, and a carriage return. It is a global
feature not expressed in the second form above that no
two lines may have the same statement number. In our
system the expression "UNIQUE( )" will reference
a subprogram which insures that any statement number
that is generated through this production is unique.
There will be an additional concept with the production
UNIQUE() HAS-FUNCTION EAOH LINE
HAS A UNIQUE /statement number/
which summarizes the operation of the hidden subprogram for the student.
A second difference is that, unlike compilers, we
will proceed from left to right which requires the
rewriting of a few productions from their more commonly seen forms.
With this brief introduction le~ us sketch the operation of the system as it would proceed in generating a
question. For this example we will generate a statement
as it would appear in BASIC18 except for one error. We
will not write all the productions which are necessary,
but suppose that concept 23 has been chosen. Concept
23 looks like this:
C23~./assignment/
IS LET / variable /
arithmetic expression /
.QUESTION FORlVIAT = ....
.ERROR LIST = 1\ (null)
.WEIGHT = ....
=
WHAT PART OF COMPUTER HASFUNCTION PERFORM OPERATION?
etc.
393
/
We will have three push-down stacks :19 ,20 One
stores the concepts in order of application, one stores
that part of the final string we have completed, and one
stores the parts we are still working on. We call these the
C stack, T stack, and W stack respectively.
394
Spring Joint Computer Conference, 1972
So far the stacks look like this:
T Stack
C Stack
W Stack
LET
C ERROR
24
/arithmetic
primary/
C
28
/relation/
/arithmetic
expression/
C
25
/arithmetic
primary/
..
C
37
W Stack
C Stack
The stacks would end up looking like this:
LET
/variable/
T Stack
B4
=
LET
C
35
Next we choose a concept which has a production
that tells us something about the top-most (nonterminal) element of the W stack. Suppose we choose
C
23
C36--+./variable/ IS / identifier/
Imagine that finally we had:
.etc.
C Stack
Then the stacks would look like:
C Stack
W Stack
T Stack
C
35
/identifier/
LET
C
23
=
/arithmetic
expression/
W Stack
T Stack
C
35
7
C
31
<
C
41
A2
C
35
=
C
31
B4
C ERROR
24
LET
C
28
At some point in the processing the student will encounter a concept which has a relatively high weight,
meaning that the student has had trouble with it before. Instead of copying the right side of that concept's
production onto the W stack, the program copies the
right side of a production belonging to one of the concepts in the current concept's error list. This fact is
noted on the C stack.
Suppose that later in the processing the top of the
W stack contained/arithmetic primary/, and instead
of an appropriate match we choose from the appropriate error list
C24--+/logical expression/ IS / arithmetic primary/
/relation/ /arithmetic primary/.
C
25
C
37
C
35
C
Z3
The system prints
WHAT IS WRONG WITH THIS /assignment/?
LET B40 = A20 < 7.
UNITEAM
Note that /assignment/ is the left side of the production of the bottom concept in the C Stack (C23). *
If the student's answer looks something like
/logical expresion/ SHOULD HAVE BEEN /
arithmetic expression/,
i.e., if it names expressions which pinpoint where the
error was made, the program accepts it. If the student's
answer includes expressions found higher in the C Stack
than the ERROR flag, for example, /relation/
SHOULDN'T BE THERE, the program responds:
YES, BUT CAN YOU BE MORE SPECIFIC?
Otherwise the program limits the productions which
caused the error and any others in the C Stack that the
student might want to see.
We have not yet settled on the best way to locate an
error nor on the best way to update the weights of those
concepts used in generating a question.
Phase 3 is dedicated to teaching the student how to
write small, meaningful programs. It will begin with
concepts which describe how the various BASIC
statements alter the variables referenced within them.
The next batch of concepts will introduce bits of
programs such as "short routine", "sum an array", etc.
Finally, the highest concepts will be oriented toward
a canonical representation of a few simple programs.
Thus, if all goes well, at the end of his relationship
with the system the student will be asked questions
about what specific, complete programs do.
CONCLUSION
We have outlined our initial approach to the problem of
creating a universal teaching program. The fundamental ideas are similar to the theorem proving approach, i.e., the technique used by question-answering
systems, but runs "backwards," generating questions
which test the student's ability to manipulate the basic
concepts of the topic he is to learn. We have given an
example which, while extremely simplified from the
general case, demonstrates a sophisticated capability
when compared to present day teaching programs.
It remains to be seen if the techniques we devise can be
generalized sufficiently to accept concepts derived
from diverse topics.
The parameters used to evaluate such a system are
* The concept numbers correspond to a list we have used but
which is not included in this paper.
395
access time, CP (Central Processor) time, IP (Input/
Output) time for Control Data Corporation 6000
machines, mass storage, and core requirements. We
believe that all four can be cut drastically by utilizing
the random access capability of the Control Data
Corporation 6400 on which our program is being implemented. That is to say that the system will be maintained on disc. Since the selection of concepts is inherently random, this approach seems intuitively
correct. The elimination of chaining, i.e., searching for
data sequentially, will minimize access time and CP
.
.
'
tIme wIll be reduced by holding data manipulation to an
absolute minimum. Since the system will reside on mass
storage units, core capability will be greatly enhanced.
The principal advantage of UNITEA1VI over other
systems (PLANIT, PLATO, ETC.) is that UNITEAM
is the most adaptive program yet devised. Certainly the
ultimate C. A. 1. will include verbal communication
and pictures, as does PLATO. PLANIT can recognize
responses in a number of ways which UNITEAM
at its present stage of development cannot.
PLANIT can derive data from several sources in
order to provide a basis for making instructional
decisions. This examination of various sources of data
and records is incorporated into UNITEAlvI to formulate the weights (UTILES) of the value of various
topics to be presented to the student.
1. Student performance on a question;
2. Cumulative student performance;
3. Student entry characteristics;
4. Student preference.
. Student performance includes accuracy of response,
tIme of response, etc. Student entry characteristics
include the ability and educational background. It is
felt that UNITEAlVI should make use of the prior
knowledge of an individual, including such things as
grades, IQ, interests, teacher ratings, etc.
Feedback is a major factor in determining which
material and at what depth that material should be
presented next, thus enabling the program to adapt
to the needs of the individual. All previous feedback
including the most recent information in one sense is
reevaluated at each step since UNITEAM is based on
stochastic methods. Although UNITEAM bears some
lVIarkov chain similarities, it is more complex, and thus
final evaluation will rest with performance of students
rather than mathematical analysis. Thus, total examination of feedback determines to a large degree
which direction one next proceeds.
396
Spring Joint Computer Conference, 1972
At the present time feedback consists of:
1. Student records;
2. Evaluation of performance;
3. Number of prompts, hints, cues needed;
4. Elaboration on a student's response as a means
of reinforcing a concept.
Unlike other C. A. 1., UNITEAM employs Monte
Carlo methods in addition to a weighting scheme
associated with topics, concepts, etc. This system provides a completely non-linear capability and innumerable paths of deductions as UNITEAlVI develops
necessary logic at each stage or step in the questionanswering process. UNITEAM is capable of providing
an almost unlimited number of pathways through the
instruction because its responses are dependent upon
each individual student who is making his own decisions, and it is very unlikely that any two students
would choose the same path through UNITEAM.
APPLICATION OF UNITEAM
The system design of UNITEAM enVISIOns the
following to be provided by the instructor:
1. Text or subject material (data) to be punched on
cards;
2. List of key words which students are to know;
3. Table of weights (utiles) for various topics and
concepts;
4. Table of yes-no and true-false questions.
Instructors are not required to know anything about
programming or how UNITEAM works. They must
know how to present material, and if they wish,
UNITEAlV:I will handle the weights of all topics and
concepts equally by default. The table of key words
provides ready access to the determination of important concepts.
At the current stage of UNITEAM's development,
response time is not a problem. This, of course, is
because at its present stage of development, the
question-answering is one of essentially true-false or
yes-no. Development is centering on multiple choice
responses, and definitions at this time, and the response
time problem is appreciated as the question-answering
becomes of a more complex nature. Disc storage rapidly
becomes a problem, as we envision the capability. of
UNITEAM to essentially control access to all knowledge about a particular course being taught that an
instructor might like to include. For the controlling
system (UNITEA1VI) disc storage is not a problem,
but the course material (data) rapidly can become
unwieldy. With the development of such hardware as
Precision Instrument Company's trillion-bit laser mass
memory, one might hope that this problem will soon be
eliminated or at least greatly reduced.
REFERENCES
1 S L PRESSEY
A simple apparatus which gives tests and scores-and teaches
In School and Soc Vol 23 1926 pp 773-776
2 B F SKINNER
Teaching machine
In Science Vol 128 1958 pp 969-977
3 C C GREEN
The application of theorem proving to question-answering
systems
Information Service 1970
4 J R SLAGLE
Experiments with a deductive, question-answering program
In Comm ACM Volume 8 1965 pp 792-798
5 J D BECKER
An information processing model of 1'ntermediate level
cognition
In Stanford Artificial Intelligence Project Memo AI-119
6 D E KNUTH
The art of computer programming-Volume I-Fundamental
algorithms
Chapter 2 Addison-Wesley Publishing Company Reading
Massachusetts 1968
7 C C GREEN
The application of theorem proving to question-answering
systems
Information Service 1970
8 F R A HOPGOOD
Compiling techniques
American Elsevier Publishing Company Inc New York
1969 pp 29-34
9 D E KNUTH
The art of computer programming-Volume I-Fundamental
algorithms
Chapter 2 Addison-Wesley Publishing Company Reading
Massachusetts 1968
10 J R SLAGLE
Experiments with a deductive, question-answering program
In Comm ACM Volume 8 1965 pp 792-798
11 D MAURER
Introduction to programming
Stanford University Press 1967
12 F R A HOPGOOD
Compiling techniques
American Elsevier Publishing Company Inc New York
1969 pp 29-34
13 T H NAYLOR J L BALINTFY D S BURDICK
K CHU
Computer simulation techniques
John Wiley and Sons Inc New York 1966 Chapters 3 and 4
14 J M HAMMERSLEY D C HANDS COMB
Monte Carlo methods
John Wiley and Sons Inc New York 1964
UNITEAM
15 PLANIT author's manual
Systems Development Corporation Sections I and II 1971
16 A D CALVIN
Programmed instruction
Indiana University Press Bloomington Indiana 1969
17 P NAUR et al
Revised report on the algorithmic language ALGOL 60
In CACM Volume 6 page 11963
18 J G KEMENY T E KURTZ
Basic programming
John Wiley and Sons Inc New York 1960
397
19 F R A HOPGOOD
Compiling techniques
American Elsevier Publishing Company Inc New York 1969
pp 4-10 52-54
20 D E KNUTH
The art oj computer programming-Volume I-Fundamental
algorithms
Addison-Wesley Publishing Company Reading
Massachusetts 1968 pp 234-238
21 PLANIT author's manual
Systems Development Corporation 1971 Sections I and II
Mainline CAl, necessary but not oppressive*
by C. VICTOR BUNDERSON
University of Texas
Austin, Texas
Two years ago the term "mainline instruction"
was introduced as a referent to a carefully designed,
total instructional system to replace complete courses
with a far less labor-intensive mixture -----+1 diagnostic
advice
o
'"
Figure 2-Generalized flow within a lesson
both of these instructional sequences various control
options and paradigms derived from recent research
and theory in instructional psychology are used. The
"Review Tips" section discusses the prerequisites
(concept of zero, domain, range, function, etc.), provides
brief review material, and references earlier lessons. The
"So what?" file contains information on why a junior
college student should bother to learn these objectives.
The mini-lesson is a quick survey of the entire lesson.
Definitions are provided for the important concepts
in the lesson, including second degree polynomial and
the three forms of the function. The mastery test is
diagnostic. If the student fails parts of it he is given
advice which is designed to help him go back to the
lesson menu, or to review, before taking the test another
time.
Figure 2 is a nondeterministic flowchart in which
the overall pattern for most lessons is revealed. Students
may try several strategies before taking the mastery
test, and after failing it the first time. The advisor program may be called by the student for a discussion of
various strategies used by fast, slow, and average
students, or the advisor program may interject commentary under certain conditions.
404
Spring Joint Computer Conference, 1972
A student is not required to attempt a mastery test
more than twice in close succesion, but may elect to
come back to the lesson at a later time. Under this
condition the lesson is automatically rescheduled. The
student may request "status" from the advisor program
at any time to see what lessons he has completed.
Once the mastery test has been passed, if there is
additional instruction at the A and B level, then the
student contract is checked, and if he has elected a B
or A, additional instruction is given, along with the
A-B test. If he has not elected a B or A, a calculation is
made to predict what he would probably get on the A-B
test. If he is an underachiever who could get a B or A, he
is provided with friendly advice and scored for approach
if he takes it. He then has a chance to select among the
"fun options" which might include such items as "More
on that Topic" (which gives him A and B items not
seen), a computational plotting program, a game
film or a short film (videotapes can be shown on the
TICCIT terminal). TIDBITS are historical vignettes,
anecdotes, etc., related to the lesson topic, and are
scored as approach. The student pays for fun options,
using points earned through earlier achievement. The
advisor may "advertise" certain options when the
student arrives at the fun options menu. If he arrives
at the fun options menu without having passed the
mastery test, his choices are restricted and his bank
account of points is low.
THE ADVISOR PROGRAM
The advisor is simply a set of routines which are either
called by the student by depressing an interrupt key
and typing a code word, or which are called by the
course program at certain points. Four of the functions
have been discussed above: strategy advice, status
report, A-B advice, and "advertising." Other functions
deal with setting and changing the grade contract, with
scheduling reviews, and with keeping track of the
"bank account" income and expenses.
duce the light and clever touches which have been used
so well in the TV programs developed by Children's
Television Workshop. Professional writers and TV
scriptors are a part of the courseware teams. The
intimate mixture of short videotapes and CAl sequences
is a powerful new mechanism of expression for creative
authoring talent, and we hope to learn to use it to the
fullest to provide instruction that is palatable and fun
as well as effective and efficient.
ON FREEDOM AND PRIVACY
The philosophy of learner choice and the respect for
the individual implicit in our courseware design assure
individual freedom. An individual is free even to remain
antagonistic toward mathematics, or to resist attempts
to accept responsibility, for our interactions are all
persuasive rather than coercive.
On the issue of privacy, we plan to keep scores on
mastery, speed and accuracy, learning strategies,
voluntary approach, and the responsible use of control
options. Thesescores are necessary both for the advisor
program and for the human advisors to help each
student achieve his objectives, and to improve the
system for later students. The data are analogous to a
combination of a grade transcript and a set of aptitude
scores now found in students' files in registrars' offices
at any college, but these data are more precise and detailed. They could presumably be misused in the same
manner as could the registrars' files if security were lost.
IQ scores have been misused and restrictions set up
against their distribution. Presumably, appropriate
restrictions must also be established to protect the
misuse of our courseware scores. Indeed, it is possible
to permit the individual to contract for the courseware
to attempt to influence strategies, attitude, and responsibility as well as mastery. Such an agreement
between the student and the system would be a positive
and constructive substitute for the "privacy warning"
now given to Dartmouth students whenever a record
is kept of certain of their transactions at a terminal.
MOTIVATIONAL TECHNIQUES
SUMMARY
The reader will have observed a number of motivational techniques in the previous discussion. The whole
concept of learner control, with emphasis on responsibilityand skill in the use of strategies, has the potential
of being very motivating to many students. The "So
what?" file, the "fun options," and the point system
used· to earn fun options are designed to enhance
motivation as well as to develop approach. In addition
to these techniques, humor, cartoons, graphics, color,
and audio are used throughout in an attempt to intro-
Because of increasing cost problems in higher education,
and the need to find more cost-effective approaches
to traditional instruction, mainline instructional systems were proposed as a desirable alternative. The
first reason discussed was economic. Mainline instructional systems, as defined in this paper, replace important subsystems within an educational institution with a
less labor-intensive, potentially more cost-effective
technology. Any proposal which uses technology as an
Mainline CAl, Necessary but Not Oppressive
adjunct to a classroom teacher, representing an add-on
cost, is unlikely to represent a viable alternative in the
years ahead unless somehow incorporated within a
more radical restructuring of education.
That systematically designed mainline courseware
can lead to the qualitative restructuring of curricula,
and, in particular, can enhance independent, selfmotivated learning and other important values was
discussed. An example was taken from the TICCIT
courseware development project in freshman mathematics to illustrate this discussion.
REFERENCES
1 V C ABBOUD C V BUNDERSON
A computer-assisted instruction program in the Arabic
writing system
Technical Report No 4 Computer-Assisted Instruction
Laboratory The University of Texas at Austin 1971
2 C V BUNDERSON
Justifying CAl in mainline instruction
In G P Weeg (Chairman) Conference on computers in the
undergraduate curricula. Proceedings The University of
Iowa Conference June 1970 Iowa City Iowa Center for
Conferences and Institutes September 1970
3 C V BUNDERSON
The computer as a means toward controversial educational ends
In T E Kurtz (Chairman) Conference on computers in the
undergraduate curricula. Proceedings Dartmouth Conference June 1971 Hanover New Hampshire University Press
of New England 1971
405
4 P F DRUCKER
The age of discontinuity
N ew York Harper & Row 1969
5 W A JUDD C V BUNDERSON W BESSENT
An investigation of the effects of learner control in
computer-assisted instruction prerequisite mathematics
(MATHS)
Technical Report No 5 Computer-Assisted Instruction
Laboratory The University of Texas at Austin 1970
6 T E KURTZ (Chairman)
Conference on computers in the undergraduate curricula
Proceedings Dartmouth Conference June 1971 Hanover
New Hampshire University Press of New England 1971
7 A W LUEHRMANN
Dartmouth project coexist: the computer qua computer
In T E Kurtz (Chairman) Conference on computers in the
undergraduate curricula Proceedings Dartmouth Conference
June 1971 Hanover New Hampshire University Press of
New England 1971
8 J R PIERCE (Panel chairman)
Computers in higher education: Report of the President's
Science Advisory Committee
Washington DC US Government Printing Office 1967
9 A SMITH C GREGORY
MATHS user's manual
Computer-Assisted Instruction Laboratory The University
of Texas at Austin 1970
10 S G TICKTON
The outlook for higher education in the big cities
Academy for Educational Development Inc 437 Madison
Avenue New York New York 1969
11 G P WEEG (Chairman)
Conference on computers in the undergraduate curricula
Proceedings Iowa Conference University of Iowa Iowa City
1970
Should the computer teach the student, or vice versa?
by ARTHUR W. LUEHRMANN
Dartmouth College
Hanover, New Hampshire
I
This sermon begins with a parable.
Once upon a time in the ancient past there was a
nation in which writing and reading had not yet been
invented. Society was as advanced as possible, considering that it had no mechanism for recording the
letter of the law or of writing agreements, contracts,
or debts. Nor was there a way of recording the heritage
of information and knowledge that had to be passed
on from generation to generation.
As a result, a great fraction of the total effort of the
society was spent in oral transmission of information.
Master teachers, who themselves had been taught by
older master teachers, lectured before children and
young people of the society. Training a master teacher
was a long and expensive process, and so the society
could not afford many. For reasons of economy the
curriculum was quite rigid and lectures were on a fixed
schedule. Teaching, obviously, was a labor-intensive
industry based on skilled, expensive talent. Education,
per force, was a luxury that could be afforded by the
elite classes only.
Then, one day, writing and reading were invented.
Not surprisingly, the first application of this new
technology was to business and government. Money
was printed; laws were encoded; treaties were signed.
In response to these needs, a reading and writing industry grew up. Within a few years it was able to offer
a broad range of reading and writing services to its
customers. The customers found this to be a convenient arrangement, since hiring readers and writers
from service vendors eliminated the need for each
customer to invest in an expensive R&D effort of
its own. The customers remained illiterate.
At first the situation was somewhat chaotic. Each
vendor of reading and writing service tended to develop its own favorite language and its own technique
for encoding information, leading to incompatibilities
that impeded the spread of the new technology. After
a winnowing-out period, however, the number of
competing systems settled down to a few and major
difficulties were handled by translators-though inevitably something seemed to be lost in the process.
Always looking for new markets, the vendors of
reading and writing service began to examine the area
of education. In view of its elitist role in the society it
had been dismissed at first as too limited a market. A
few, more imaginative people, however, argued that
the application of reading and writing technology
could turn education into a mass market. They proposed the following plan of attack. Reading and
writing specialists and master teachers would work as
a team. The master teachers would deliver their best,
most carefully prepared lectures to the reading and
writing experts, who would write them carefully
verbatim into books. The books would then be copied
many times, and each copy would be made available to
a new type of educational functionary-the reader.
His only job would be to assemble groups of students
and to read aloud to them the recorded lectures of the
master teachers. In view of the fact that training such
a reader would be far less expensive than the education of a master teacher, the on-going cost of such a
program would be far less than that of the conventional lecture method. The new method came to be
called Writing Assisted Instruction, frequently abbreviated to W AI.
Needless to say, WAI had its opponents. Established
master teachers expressed doubt whether a less skilled
reader would be able to communicate subtleties of
inflection, and they were certain that a mere reader
could not process student responses with skill or intelligence. W AI proponents counter-charged that the
master teachers were merely expressing their vested
interest in the present educational establishment, and,
indeed, that they ought to be fearful because the
superiority of WAI would ultimately drive out the
conventional practitioners. Even within the education
establishment some younger ili.embers became W AI
supporters on the grounds that the new method was
a boon to education research. Until then, teaching had
407
408
Spring Joint Computer Conference, 1972
been something of a black art, shrouded in the privacy
of the classroom. To compare one teacher with another
was impossible. But in the future, they said, the
written record of the lectures of master teachers would
make the teaching experience explicit and subject to
analysis, comparison and improvement. It was high
time, the young Turks exclaimed, that the teaching
profession act with accountability to the public it
served.
Unfortunately, such controversy remained for many
years on a hypothetical plane. The number of actual
WAI efforts was verysmall and their results were not
striking. There was also a credibility problem. Many
of the most outspoken advocates of WAI, especially
in the legislature and in business and on local school
boards, were themselves almost totally illiterate in the
new reading and writing skills. How could they evaluate
a new technology if they had not mastered it themselves?
Finally, government, business and some members
of the education establishment decided to mount two
or three large-scale demonstrations of W AI in order
to show publicly the advantages of the new educational
technology. For a period of several years curriculum
experts collected information on a few key courses of
lectures by assorted master teachers. The reading and
writing experts wrote down the best series and read
them aloud to the curriculum experts, who would
criticize them and make improvements. The reading
and writing experts would then incorporate the improvements in the next draft. Then came the field
test. Readers began to read the drafts aloud to actual
classes of students, and this led to further revision
by the curriculum experts and rewriting by the reading
and writing experts. At the end of a few more years a
summative evaluation of the projects was undertaken
by an independent, reputable educational testing organization, whose mission was to compare the cost and
effectiveness of WAI with conventional education.
The parable is nearing its conclusion now. Actually
it has two alternate endings, one happy and one sad.
The sad ending, which follows now, is brief.
The educational testing organization reported that
the projects were a complete vindication of Writing
Assisted Instruction. It found that students taught
by W AI performed even better on standardized tests
than students taught by the average master teacher,
that the students liked WAI better, and that the total
cost of WAI was about a fourth that of conventional
instruction. These pilot projects were imitated on a
grand scale and education was revolutionized. Special
institutes turned out vast numbers of readers and
within ten years they were reading courses of lectures
aloud to masses of people who could never have been
educated before the new instructional technology
arrived. The nation grew and prospered and thanked
the day that the reading and writing industry was
founded.
That is the sad ending. The happy ending is somewhat longer and more complicated. Here it is:
The educational testing organization found that
WAI was neither measurably worse than conventional
instruction, nor better. It found that costs were somewhat higher than anticipated, mainly because the
market demand for people wit~ reading and writing
skills had driven their wages up near those of master
teachers.
But this lukewarm finding was anticlimactic when it
came, for the impact of reading and writing on education had taken a new turn during the intervening years.
Here is how it happened.
At first a few master teachers had themselves found
it necessary in pursuing their own research to spend the
enormous effort required to master the skills of reading
and writing. As they became more and more competent
readers and writers, they began to see clearly the power
of the written word within their own disciplines.
Naturally enough the humanists were the first to apply
this new intellectual tool to their fields of interest.
Literature specialists collected stories, wrote them
down, exchanged them with each other and began to
develop literary criticism to a new height. Language
specialists compiled lists of grammatical rules, which
became writing manuals. Scientists were slower in
becoming literate, with mathematicians leading the
way, since they grasped the possibility of writing mathematical concepts in abstract notation. Nevertheless,
for many years scientists continued to remain in verbal
darkness.
While reading and writing had its primary impact
on scholarly research, at the same time many master
teachers across the land began to wonder whether it
might not be beneficial to introduce elementary uses
of reading and writing to students in their courses. A
few language teachers began to show students how to
write phrases and sentences, and the more venturesome teachers even asked students to write sentences
of their own. Such experience, they claimed, greatly
enhanced a student's understanding of syntax and
rules of grammar. Even in subject areas far removed
from language, to which reading and writing have a
natural affinity, teachers began to report pedagogical
gains due to having students carry out elementary
reading and writing tasks as an adjunct to conventional
instruction.
One obstacle to student use of reading and writing
was the awkwardness of the main systems of notation,
which had been developed mainly for research and
Should the Computer Teach the Student, or Vice Versa?
business applications. The most popular such system
was particularly difficult to format, since its characters
all had to be positioned accurately in a fixed number of
columns. Occasionally there were rumors that a group
of teachers in a remote province near the northern
frontier had developed a simpler writing system and
all their students were using it daily. Such rumors were
hard to verify; only a few people ever voyaged that
far north, and, in any case, experts in the reading and
writing industry seemed confident that anything that
made the current system simpler would also take away
its power and elegance. So most teachers adhered to it.
Within a few years teachers began to hold national
meetings to tell one another how their students used
reading and writing within their courses. Advocates
of this type of use, which came to be called adjunctive,
insisted that it be distinguished clearly from WAr.
Writing Assisted Instruction, they charged, was nothing
more than an improvement in the technology of delivering instruction. Adjunctive use of reading and
writing by the student, on the other hand, represented
a change in the intellectual content of instruction. They
argued from the following philosophical premise:
Reading and writing constitute a new and
fundamental intellectual resource. To use that
resource as a mere delivery system for instruction,
but not to give a student instruction in how he
might use the resource himself, was the chief
failure of the WAI effort, they said. What a loss
of opportunity, they exclaimed, if the skill of
reading and writing were to be harnessed for the
purpose of turning out masses of students who
were unable to read and write 1
WAI advocates responded that it was well and good
that a few elitist schools teach their students the difficult skill of reading and writing; it was. enough that
WAI teach lesser skills to masses that might otherwise
remain uneducated and unemployable.
How much longer, asked the WAI opponents in
rebuttal, will an illiterate person be considered educated? How long will he be employable and for what
jobs if elitist schools are turning out competent readers
and writers by the hundreds?
The more visionary advocates of mass literacy told
of foreseeing the day when students would spend more
hours of the day reading and writing than listening to
lectures. Small research libraries had indeed sprung up
at some schools, but they were expensive operations
limited to a few specialists who had to raise funds to
pay for their use. Such people were particularly incredulous at the suggestion that every school ought to
adopt as an educational goal the establishment of a
409
significant library open freely to all students. School
administrators were at first appalled at the idea that
the library should not be on a pay-as-you-go basis but
should be budgeted as part of the general institutional
overhead costs.
But as time went on and even school administrators
became competent and imaginative users of the skill
of reading and writing, all schools gradually accepted
as a mission the bringing of literacy to all students.
Accreditation agencies examined the quality of libraries
before approving schools. Books began to appear all
over and finally even in people's homes. WAI did not
die out altogether, but continued as a cost-effective
alternative to the lecture. But as books reduced dependence on lectures, students made less use of both
WAI and lectures and spent more time on their own
reading and writing projects. The nation grew and
prospered and wrote poems in praise of the day that
reading and writing were discovered and made available
to all people.
End of parable.
It is a perilous strategy, bordering on bad taste, to
tell a joke and then for several pages explain why it
was supposed to be funny. However, this allegorical
tale has been told here not merely for entertainment
but mainly for the moral lesson it carries. To compare
reading and writing with computing might be dismissed as an amusing frivolity; but that would be
wrong. Our fundamental philosophical premise here is
that, like reading and writing,
"[computing] constitutes a new and fundamental intellectual resource. To use that resource
as a mere delivery system for instruction, but not
to give a student instruction in how he might use
the resource himself, has been the chief failure of
the [C]AI effort. What a loss of opportunity if
the skill of [computing] were to be harnessed for
the purpose of turning out masses of students who
were unable to [use computing] I"
As this example shows, it is a trivial editing task
to go through the entire reading and writing fable and
turn it into a story about computing and its uses in
education. In fairness, the author admits that the
story really is about computing and that reverse editing
was done in the original telling so that it would seem
to be about reading and writing. Yet, as a story about
reading and writing it has considerable plausibility,
doesn't it? The Writing Assisted Instruction program
outlined in the story is not a totally absurd idea for
putting reading and writing to use in education. One
cannot argue against claims that committing lectures
410
Spring Joint Computer Conference, 1972
to writing would make education available to more
people, would invite critical comparisons and a consequent improvement in subsequent revisions of
written materials, and would be an asset to the study
of the learning process itself. What does appear absurd,
however, is the failure of these mythical WAI proponents to recognize that the best educational use of
reading and writing is the teaching of reading and
writing itself to everyone. Mass literacy is an educational mission about which few of us have doubts today.
Yet that consensus among us seems to vanish when
one substitutes "computing" for "reading and writing"
and "CAl" for "WAI". Mass computing literacy is
not an agreed-upon educational goal. Today very few
courses at any educational level show students how to
use computing as an intellectual tool with applications
to the subject matter being taught. Oh, there are a few
isolated, subject-matter-free courses in computer programming; but their market is largely restricted to
vocational-education students, at one end of the
spectrum, and future computer professionals at the
other. It is true that most schools consider it prestigious
to have a large and powerful computer facility; but
the fact of the matter is that such computers are
usually the captives of research and administrative
interests and operate on a pay-as-you-go basis. Ironically, it is in the most prestigious universities that
students are least likely to be permitted to use those
prestigious computers. It is a rare secondary school,
college, or university that budgets and operates its
computer facility in the same way that it budgets and
operates its library. (There is a persistent rumor of an
exceptional example in some remote province near the
northern frontier, but so few people ever travel that
way that the report is hard to verify.) In the main,
literacy in computing simply is not an educational
goal at many schools. Most educators seem to find
bizarre the suggestion that accreditation agencies
examine schools for the quality of their educational
computing facilities, just as they now do with libraries.
The distressing truth today is that educators, local
school boards and federal policy-makers are far more
receptive to the plans of CAl proponents for using the
technology of computing as a cost-effective delivery
system for instruction in math or remedial English
than they are to making computing itself a part of
education. This statement should not be taken as a
blast against CAl. On the contrary, CAl advocates
are to be commended for their desire to reduce the
cost of instruction, to tailor it to the different learning
styles of students, to develop systems that encourage
closer examination of what is being taught and systems
for improving instruction, and to hold teachers and
schools accountable to their clientele. With enough
developmental work on CAl, it is likely that students
will perceive the computer as a very superior teacher.
Above all, CAl promises to make education a less
labor-intensive industry and so to enable masses of
people to become better educated. This is certainly a
goal worth working for.
But there is a higher goal. If the computer is so
powerful a resource that it can be programmed to
simulate the instructional process, shouldn't we be
teaching our students mastery of this powerful intellectual tool? Is it enough that a student be the subject
of computer administered instruction-the end-user
of a new technology? Or should his education also
include learning to use the computer (1) to get information in the social sciences from a large data-base
inquiry system, or (2) to simulate an ecological system,
or (3) to solve problems by using algorithms, or (4) to
acquire laboratory data and analyze it, or (5) to
represent textual information for editing and analysis,
or (6) to represent musical information for analysis, or
(7) to create and process graphical information? These
uses of computers in education cause students to become masters of computing, not merely its subjects.
It will be countered that such an educational mission
is well and good for a few elitist schools, where students
are willing to learn the difficult skill of computing; but
it is enough that CAl teach lesser skills to masses of
students that might otherwise remain uneducated and
unemployable.
In response we ask, how much longer will a computer
illiterate be considered educated? How long will he be
employable and for what jobs if elitist schools are
turning out competent computer users by the thousands?
The true story about computing and education is
at its midpoint. Like the reading and writing parable,
it has a sad ending and a happy ending. Which one
actually occurs will be determined by you-teachers,
school administrators, computer professionals, and
government policy-makers.
Performance evaluation-A structured approach*
by STEPHEN R. KIMBLETON
University of Michigan
Ann Arbor, Michigan
INTRODUCTION
center managers by virtue of their training and natural
inclinations. Consequently, a communication barrier is
created between the O.R. analyst and those engaged in
making decisions regarding the selection, evaluation
and enhancement of computer systems.
This communication gap has two primary sources, the
first being the difference in viewpoint. Most managers of
computing centers have a reasonably thorough knowledge of the problems inherent in writing programs
for currently existing large-scale computer systems. In
particular, they are well aware that a meticulous concern for detail is necessary for the successful production
of programs within acceptable time limits. Consequently, the forest of computing is viewed as a collection
of individually interesting trees. This viewpoint produces a natural propensity toward simulation models
of computer systems whose basic level of detail is in the
sub-millisecond range.
A careful analysis of well-regarded models for other
large-scale systems! demonstrates that the major
prerequisite for successful modeling of complex systems
is the identification of a reasonably small number of
key variables. A corollary of this identification process
is the omission of as many other variables as possible.
Once the identification of the key variables driving the
system has been performed, the basic methodologies of
operations research, e.g., mathematical programming,
queueing analysis, scheduling theory, etc., can be
invoked. Clearly, the resulting model will appear
incomplete to the casual observer knowledgable in the
process being modeled. However, the acid test of the
model is neither its complexity nor its apparent completeness; rather, it is the capability of the model for
providing information of use by a decision-maker.
The resolution of the difference in viewpoints between
the computing center manager and the O.R. analyst
can only be achieved through construction by the
latter of models which provide information of use to the
former. This requires that the model relate the input
variables to the performance of the system as a whole.
Computer systems are expensive in terms of development, acquisition and maintenance. The efficient and
effective system appears to be the exception rather than
the rule. Concern for system improvement is voiced by
almost every computer-related management or technical support group. The types and amounts of data
which can be gathered through hardware and software
monitors appear to be ever increasing. A bewildering
array of papers and proceedings are published every
year and the problems of analyzing computer systems
are described with loving detail.
In spite of the effort implicit in the activities described above, the author has rarely visited an installation at which the systems analysts were reasonably
familiar with literature available in the technical
journals on modeling computer systems. The most
common approach to system improvement appears to
be one of incremental enhancement coupled with a
'cut and try' approach. The absence of a basic underlying approach for a problem of such significance is
difficult to believe.
MODELING SYSTEMS
In order to study large-scale complex systems
efficiently, one normally proceeds via the development
of suitable models. Effective tools fpr modeling have
been developed by generations of operations research
analysts. Unfortunately, mere knowledge of modeling
tools does not guarantee the production of a good model
of a system. Something akip. to an O.R. viewpoint is also
required. This viewpoint is normally opposed to that
which seems reasonable to programmers and computing
* This research was partially supported by the Office of Naval
Research, Information Systems Program under Contract
NOOO-14-67-0181-A-0036 (NR 049-311).
411
412
Spring Joint Computer Conference, 1972
Unfortunately, most of the models existing in the
literature are for components of a computer system.
In particular, a large number of models exist for:
(i) CPU scheduling algorithms,2 ,3 ,4 (ii) memory management models 5,7,6 (iii) I/O models 8 ,9,1o and (iv) miscellaneous models of use in studying storage contention ll
the effects of buffering,12 etc. A few attempts at building
models which provide information on throughput
have been made. In particular, the papers by Gaver13
and Hanssmann, Kistler and Schultz14 are noteworthy.
Before attempting to develop a model, it is natural to
seek guidelines for the properties which it should
possess if it is intended to be of use to a computing
center manager. The tradeoff between the effort
involved in building the model and the information
obtained from it must be carefully considered. Consequently, an absolute formulation of guidelines cannot
be made. However, extensive studies have been made of
the categories of information required by a decisionmaker in order to apply the formal techniques of
decision analysis. In particular one must have :15
(1) a list of variables to be considered is making a
decision, viz., the input variables and the output
variables,
(2) a model showing the interaction between the
input variables and the output variables,
(3) a list of constraints which the chosen solution
must satisfy,
(4) a means for evaluating various alternative
combinations of input and output variables.
As an example, the performance of a computer
system is often measured in terms of :16 (a) throughput,
(b) turnaround time and (c) availability. Throughput
is normally measured in jobs processed per week or
month, availability is measured in terms of idle time
per shift, and turnaround time is measured in terms of
elapsed time from submission of a job until its output
is available, Thus, it might be determined that a given
system should possess the capability for processing
4000 jobs/month, with an average turnaround time
of one hour and an availability of one hour/shift. In
considering systems which meet this requirement, it is
also desirable that some attention be given to the
stability of various solutions. That is, given two systems
which meet the requirements, one would normally
choose the less expensive of the two. However, if a
large increase in potential performance can be obtained
at only a modest increase in cost, the more expensive
system could be chosen.
Clearly, a model which effectively incorporates all of
these factors constitutes a difficult objective. However,
as a first cut at building a model of interest to a computing center manager, one might seek to relate the
attributes of the programs which are to be run on the
system (measured in some suitable manner) to the
performance of the system as a whole (measured in
terms of the three primary variables). In the following
such an approach is described for a somewhat restricted
class of programs.
THE SYSTEM PROCESS MODEL
A model for describing the performance of a computer
system (hardware plus operating system) must possess
the following two capabilities: (i) the activity of a
process must be· characterized in terms of some basic
collection of descriptors, and (ii) the interaction
of the collection of processes in the system must be
characterized.
In modeling the activity of a process in a computer
system, we observe with Denning17 that at any given
instant in time a job or process is in one of three states:
(i) active, i.e., currently being serviced by the CPU,
(ii) blocked, i.e., halted pending completion of some
event and incapable of being serviced by the
CPU,
(iii) ready, i.e., awaiting the CPU.
The lifetime of a job consists of an alternating sequence of active, blocked and ready intervals, which
may have length zero. The utility of this observation
does not appear to have been previously noted. Perhaps,
this is because of observed variations in the lengths of
these intervals, the relative times at which they occur
and their number. That is, the activity of a process is
not deterministically reproducible when its evolution
is viewed as an alternating sequence of such intervals.
Fortunately, the activity of the process is statistically
reproducible.
The interactions of the collection of concurrently
executing processes are assumed to behave in the
following manner:
(i) all jobs are statistically identical,
(ii) all processes cycle through the active, blocked
and ready states in the same order, i.e., processes
do not pass each other, and an exit from the
active state results in an entrance into the
blocked state,
(iii) the amount of time spent in any given state is
exponentially distributed.
Although these assumptions are a simplification of the
Performance Evaluation
manner in which a computer system operates, some
available evidence19 seems to indicate that estimates
for the performance of a real system which can be
obtained through the use of this model are reasonable.
In the following, we shall refer to this model of the
activity of a computer system as the System Process
Model (SPM).
The preceding assumptions are made in order to
obtain an analytically t.ractable model. Results similar
to those described later in the paper can be obtained for
non-statistically identical processes. However, statement of the results becomes significantly more complex.
The assumption that processes do not pass each other
is clearly not satisfied by the operation of a real system.
However, the effects of passing appear to be local in
nature and, consequently, this assumption does not
appear to be unduly restrictive. The exponential
assumptions for the time spent in the active, blocked
and ready states are only tenuously satisfied by some
available data. 19 Thus, this assumption does not appear
to be unduly restrictive on the range of applicability of
this approach.
For the SPM, mathematical expressions for the
CPU utilization, the average number of active intervals,
the average length of a ready interval and the average
system residence time of a process can be derived. In
obtaining these results, the average length of an active
interval, the average length of a blocked interval and
the total amount of CPU time are assumed to be known.
The results obtained can then be used as estimators
for the corresponding quantities of a real system. In
order to clearly distinguish between quantities which
are obtained for the SPM and those which are assumed
to be obtained through the use of monitors from a real
system, we adopt the following notation:
(a) O(K) denotes the SPM estimate for U(K), the
CPU utilization given K concurrently executing
jobs in the system,
(b)
N denotes the SPM predictor for N, the average
number of active intervals,
(c) R(K) denotes the SPlVI estimate for R, the
average ready interval,
(d) 8(K) denotes the SPM estimate for S, the
average system residence time of a job, i.e., the
elapsed time from initiation of the first active
interval until termination of the last active
interval.
The following theorem has been obtained elsewhere.Is ,19
413
1.0
------0.5
0.0
-l"----r----r--------,.....lS:-------Figure I-CPO utilization estimate
Theorem:
Let A~ denote the total amount of CPU time required by a given process. Let A and B denote the
average length of the active and blocked intervals of the
process. For the System Process lVlodel with K concurrently execution processes:
(i) N=A~/l,
(ii) O(K) ~ 1- pK-l
(iii) R(K) = (K -E[J(K») A O(K),
(iv) 8(K)=N(A+B+R(K».
where p = B/ (A + B) and 1 (K) denotes the number of
active intervals which can be initiated during a blocked
interval.
The behavior of O(K) is described in Figure 1. We
note that the effect of increasing the number of concurrently executing processes in the system is to
increase R(K) in a nearly linear manner, provided
the CPU utilization is near one. We further observe
that since A~ represents the total amount of CPU time
required by a job, variations in A~ with different
injections of the same job will reflect the effects of
system overhead and should be nearly negligible.
Throughput is a subject of much interest at most
computer installations. Unfortunately, since it is
normally computed in terms of jobs per day, week or
month, it is difficult to .examine the impact of a single
job on the throughput at an installation. However,
throughput is simply the rate at which jobs are processed. An expression for this quantity can be obtained
through the use of our model. Indeed, by using wellknown arguments from renewal theory,20 it follows that
the rate at which one job is completed is 1/S. Since
414
Spring Joint Computer Conference, 1972
there are K distinct jobs in the system, the rate at
which these jobs are completed is K/ S. Thus, under the
assumptions of our model, the throughput is K/ S. It
should be observedthat this expression is consistent
with the definition of throughput. Over a time interval
of length S, precisely K/ S XS = K jobs will have been
completed.
It is appropriate to inquire as to the stability of
decisions achieved through reasoning in the preceding
manner. Fortunately, the available evidence seems to
indicate that process behavior is statistically reproducible, provided the system is large enough so that
no single job dominates it. Indeed, measurerrrents made
on the University of Michigan's MTS Computer System
(a twin-processor 360/67 with three 2301 paging
drums, three eight-drive 2314 disks, two data cells,
100 terminals, plus assorted other peripheral devices)
through the use of the embedded software monitor21
have shown that the probability distributions obtained
for the lengths of the active, blocked and ready intervals
vary ina very predictable manner as a function of the
CPU load. (The MTS System is a processor bound
system; hence it is reasonable that the CPU load
should be the controlling influence on the variation
in the distributions of the lengths of these intervals.)
Similar arguments would appear to hold for other
systems in which there exists a well-defined limiting
resource other than the CPU.19 If there is no limiting
resource, the system is lightly loaded and the estimates
described here may not be valid since processes can
'chase' each other.
EXTENSIONS AND APPLICATIONS
The preceding results are of use in studying the effects
of different job mixes for a computer system in which the
hardware and operating system are assumed fixed. If
one wishes to study the effects of varying either the
number, type or arrangement of I/O devices, it is useful
to have a means of estimating B. In addition, if one
wishes to study the effect of changes in the CPU and/or
operating system, it would also be desirable to have a
method for estimating A. Some considerations relevant
to obtaining such estimators will now be described.
Estimation of A
Both the 'power' of the CPU and the impact of the
operating system are reflected in A. Consequently, of
the four basic approaches to gathering information
about a computer system, i.e., (a) benchmarks, (b)
hardware and software monitors, (c) simulation models
and (d) analytic models, the use of· analytic models
would seem least likely to succeed. This stems from the
difficulty of treating dependent relationships with
analytic models. Attempting to predict A as a function
of the hardware and operating system characteristics
through the use of a simulation model could probably
be done. However, a rather fine level of detail might
have to be incorporated in order to achieve a reasonable
estimator. Since one is normally interested in making a
large number of comparisons, this might render the
cost of a simulation approach prohibitive. It should be
noted, however, that it would be of independent interest
to study the minimal amount of detail which must be
incorporated in a simulation model in order to yield
consistent estimators for A. Such a study might provide
some information on the level of detail which should
be incorporated in a simulation model of a computer
system-a subject on which little appears to be known.
Perhaps the most suitable approach to this problem
would be through the use of hardware or software
monitors applied to suitably chosen benchmarks.
Unfortunately, the difficulties encountered in identifying the process responsible for a particular event being
measured with a hardware monitor appears to make
their use somewhat difficult. A software monitor capable
of tracing the activities of an individual process such
as the event driven software monitor embedded in the
lVITS System21 would appear to be ideal. However,
most of the commercially available software monitors
operate on a sampling basis which necessitates a certain
amount of guesstimating in determining A, although
these monitors are useful for determining fractional
CPU utilization.
Estimation of B
Estimating B appears to be rather simpler than
estimating A. Data described elsewhere19 indicate
that variations in the length of B are rather small (at
least for a system in which the CPU is the limiting
resource) over a fairly large CPU load range. A simulation22 of a single channel eight drive IBlVI 2314 indicates
that the distribution of arriving requests by module is
the most significant single factor in achieving a satisfactory channel utilization. In particular, given a
suitable distribution of requests by module, the delay
time ofa request appears to be rather insensitive to
the particular disk scheduling policy being used, e.g.,
FCFS (first come first served), SCAN,lO or SSTF.23
This result would seem to indicate that in estimating
B as a function of the collection of I/O devices in the
system, the level of detail which must be incorporated
Performance Evaluation
is not excessive. In particular, in addition to knowledge
of the hardware characteristics of the devices, the most
important variables appear to be: (a) arrival rate by
device, (b) distribution of arrival requests by cylinder
for disks, (c) device-channel arrangement and (d)
degree of buffering. Given this information one may
write:
In this expression Pi is the fraction of blocked intervals
which occur for a device of type i, Bi denotes the
average length of a blocked interval for such a device
and the sum is computed over all I/O devices in the
system. Estimation of Bi is straightforward for dedicated peripherals if the distribution of arrivals to the
device and the amount of information to be transmitted
in each request is known. For drums and disks, comments made earlier would seem to indicate that rather
simple simulation models can be employed. Alternatively, somewhat less accurate estimates could be
obtained through the use of analytic models described
in the literature.
Block times less than those indicated through the use
of these models are indicative of either a good arrangement of data sets on devices or an effective use of
buffers. Indeed, the appropriate depth of buffering
might be 'examined by observing the extent to which
modifications in this depth affect the observed blocked
interval. An observed value of the average blocked
interval greater than that indicated by the device
models may indicate poor data set organization for a
given job, contention between jobs for data sets stored
on the same device, channel contention, etc. Although
this approach does not pinpoint the exact source of
delay, it can be used as an indicator for the presence
of potential problems. Further, comparison of the
values observed with those predicted by the models
provide insight into the size of the anticipated reward
which might be achieved through further investigation.
SUMMARY
We have obtained a model which yields estimates for
turnaround time, CPU availability and throughput
rate for a collection of statistically identical processes
characterized in terms of the total amount of CPU time
required and the average lengths of the active and
blocked intervals. Consequently, the effects of varying
the number of users in the system upon the three
primary measures of system performance can be
investigated. In turn, this allows one to apply the
techniques of formal decision analysis to the selection,
415
evaluation and comparison of computer systems. Such
an application requires an expression of the means to be
used in judging various alternatives and the decision to
be made.
REFERENCES
1 E S QUADE
Analysis for military decisions
Technical Report R-387-PR The RAND Corporation
Santa Monica California November 1964 AD 453 887
2 J M McKINNEY
A survey of analytical time-sharing models
Computing Surveys 1969 Vol 1 No 2 pp 105-116
3 L KLEINROCK
Analysis of a time-shared processor
Naval Research Logistics Quarterly 1964 Vol 11 No 10
pp 59_-73
4 E G KOFFMAN
Analysis of two time-sharing algorithms designed for limited
swapping
JACM 1968 Vol 15 No 3 pp 341-353
5 P J DENNING
Virtual memory
Computing Surveys 1970 Vol 2 No 3 pp 153-189
6 R L MATTSON J GECSEI D R SLUTZ
I W TRAIGER
Evaluation techniques for storage hierarchies
IBM Systems Journal 1970 Vol 9 No 2 pp 78-117
7 T PINKERTON
Program behavior and control in virtual storage computer
systems
TR No 4 CONCOMP Project University of Michigan
April 1968
8 E G KOFFMAN
Analysis of a drum input/output queue under scheduled
operation in a paged computer system
JACM 1969 Vol 16 No 1 pp 73-90
9 J ABATE H DUBNER S B WEINBERG
Queueing analysis of the IBM 2314 disk storage facility
JACM 1968 Vol 15 No 4 pp 577-589
10 T J TEOREY T B PINKERTON
A comparison analysis of disk scheduling policies
Proceedings Third Symposium on Operating System
Principles pp 114-121 1971
11 C E SKINNER J RASHER
Effects of storage contention on system performance
IBM Systems Journal 1969 Vol 8 No 4 pp 319-337
12WWCHU
Buffer behavior for poisson arrivals and multiple synchronous
constant outputs
IEEE Transactions on Computers 1970 Vol C-19 No 6
pp 530-534
13 D GAVER
Probability models for multiprogramming computer systems
JACM 1967 Vol 14 No 3 pp 423-438
14 F HANSSMANN W KISTLER H SCHULTZ
Modeling for computing center planning
IBM Systems Journal 1971 Vol 10 No 4 pp 305-324
15 D TEICHROEW
An introduction to management science: Deterministic models
J Wiley New York New York 1964
416
Spring Joint Computer Conference, 1972
16 P CALINGAERT
System performance evaluation-Survey and appraisal
Comm ACM January 1967 VollO No 1 pp 12-18
17 P DENNING
The working set model for program behavior
CACM 1968 Vol 11 No 5 pp 323-333
18 S R KIMBLETON C G MOORE
A probabilistic approach to systems performance evaluation
Proceedings of the ACM SIGOPS Workshop on Systems
Performance Evaluation 5-7 April 1971
19 S R KIMBLETON C G MOORE
A limited resource approach to system performance evaluation
Technical Report No. 71-2 ISDOS Research Project/
Performance Modeling Group Department of Industrial
Engineering The University of Michigan Ann Arbor
Michigan 1971
20 S M ROSS
Applied probability models with optimization applications
Holden-Day 1970
21 T B PINKERTON
The MTS data collection facility
Memorandum 18 CONCOM Project University of Michigan
June 1968
22 M MEHTA
Unpublished Memorandum Department of Industrial
Engineering The University of Michigan Ann Arbor
Michigan 1971
23 P J DENNING
Effects of scheduling on file memory operations
SJCC 1967 pp 9-21
Protection-Principles and practice*
by G. SCOTT GRAHAM and PETER J. DENNING
Princeton University
Princeton, New Jersey
structure; levels 6 and 7 in general require control over
internal program structure. Moreover, little is known
about the mechanisms for levels 6 and 7, whereas much
is known about the mechanisms for levels 1 to 5.
Much has been written about the legal and social
implications of protection and privacy (see, for example Reference 10). We deal exclusively with the
technical aspects of protection-i.e., the procedures
governing the access of executing programs (processes)
to various resources in the system. This is because little
has been written about the technical side of the problem. It is also because the technical approach, when
balanced with the legal approach, is useful in clarifying
the inadequacies of both approaches and in understanding how they can complement one another. For example,
without a technically sound protection system, a user
might find it possible to perform malicious acts undetected, rendering certain laws unenforceable. Even with
a sound protection system, however, certain aspects of
protection can be dealt with only by laws, e.g., the
problem of false identification.
The first step in the design of a protection system is
the specification of the main parties and their interactions. That is, the entities to be protected and the
entities to be protected against are identified, and rules
by which the latter may access the former are formulated. For this, common sense and examples of existing
protection systems can be used to guide our thinking in
the development of the elements and principles of a
protection system. We formalize these principles as a
model (theory) of protection, based on one developed
by Lampson. *16 Perhaps the most important aspect of
INTRODUCTION
The protection mechanisms of computer systems control
the access to objects, especially information objects.
The range of responsibilities of these mechanisms includes at one extreme completely isolating executing
programs from each other, and at the other extreme
permitting complete cooperation and shared access
among executing programs. Within this range one can
identify at least seven levels at which protection mechanisms can be conceived as being required, each level
being more difficult than its predecessor to implement:
1. No sharing at all (complete isolation).
2. Sharing copies of programs or data files.
3 .. Sharing originals of programs or data files.
4. Sharing programming systems or subsystems.
5. Permitting the cooperation of mutually suspicious subsystems-e.g., as with debugging or
proprietary subsystems.
6. Providing "memoryless" subsystems-i.e., systems which, having performed their tasks, are
guaranteed to have kept no secret record of the
task performed (an income-tax computing service, for example, must be allowed to keep billing
information on its use by customers but not to
store information secretly on customers'
incomes).
7. Providing "certified" subsystems-i.e., those
whose correctness has been completely validated
and is guaranteed a priori.
We shall consider here the protection mechanisms required for level 5, but not those required for levels
6 or 7. We do this because we are interested in specifying the structure of protection mechanisms that work
irrespective of considerations of internal program
* Approximately half our development here is an exposition and
reformulation of the elements of Lampson's modeL The remainder
extends Lampson's in several important ways. We have investigated the problems of establishing the correctness of a protection
system, of creating and deleting objects, of implementing
cooperation among mutually suspicious subsystems, and of
identifying the existence or absence of the elements of the model
in contemporary systems.
* Work reported herein was suppo~ted in part by NASA Grant
NGR-31-001-170 and by National Research Council of Canada
Grant A7146.
417
418
Spring Joint Computer Conference, 1972
the model is the notion that each process has a unique
identification number which is attached by the system
to each access attempted by the process. As will be
seen, this will make it impossible for a process to· disguise
its identity and will allow us to establish the correctness
of the model with respect to implementing protection
at level 5.
The implications of the protection model with respect
to operating system structure and hardware architecture will be considered. Although the model is abstracted from examples of existing systems, we shall see
that few current commercial systems meet the requirements of a complete (secure) protection system. We
shall identify a few existing systems which do meet
the completeness requirement of our model.
A THEORY OF PROTECTION
In current systems, protection takes many forms.
The IBM Systemj360 uses a "key-lock" approach to
memory protection. 12 A "ring" protection mechanism
is used in Multics. 9,18 The Hitac 5020 Time-Sharing
, System uses a key-Iock-ring mechanism. 17 There are
many other examples. As Lampson has pointed out,
the myriad of implementations forces us, as observers,
to take an abstract approach to the subject of protection ;16 otherwise, we might never make sense out of the
seemingly endless variety of solutions to protection
problems.
Elements of the model
A protection system comprises three parts, which
will be reflected as components of our model. The first
component is a set of objects, an object being an entity
to which access must be controlled. Examples of objects
are pages of main memory, files, programs, auxiliary
memory devices, and instructions. Associated with each
object X is a unique identification number which is assinged to the object when it is created in the operating
system. Identification numbers might, for example, be
derived from a clock which measures time in microseconds since the system was first built; the time-of-day
clock on the IBM Systemj370, being a 52-bit counter,
could allow a new object name every microsecond for
approximately 143 years.13 We shall use the symbol X
interchangeably for an object's name and number.
The second component of the protection model is a
set of subjects, a subject being an active entity whose
access to objects must be controlled. A subject may be
regarded as a pair (process, domain) , in which a process
is a program in execution and a domain is the protection
environment (context) in which the process is operating. Examples of domains include supervisorjproblemprogram states in IBM Systemj360,12 the 15 user environments in IBM's OSj360-MVT,1l or the file directories and rings in Multics. 1 Other terms which have
been used to denote the idea of domain are "sphere of
protection" 4 and "ring." 9,18 Since subjects must be
protected, they too are objects, and each has a unique
identification number.
The third component of a protection system is the
rules which govern the accessing of objects by subjects.
We shall describe a particular choice of rules shortly.
These rules are the heart of the protection system. The
rules must be simple, allowing users to gain an immediate understanding of their scope and use. They must
be complete, not allowing a subject to gain unauthorized access to an object. They must be flexible, providing mechanisms which easily allow the desired degree of
authorized sharing of objects among subjects.
An important property of our model is: each and
every attempted access by a subject to an object is
validated. This is necessary in order to permit cooperation among mutually suspicious subj ects, for it cannot
otherwise be guaranteed that a previously well-behaved
subject which suddenly turned malicious or went awry
will be denied access when authorization is lacking.
The choice of the subjects, objects, and rules of a
protection system is at the discretion of the system designer and will be made to meet the protection and
sharing requirements of the given system. We return
later to the problems of choosing subjects and objects.
It is convenient to regard all the information specifying the types of access subjects have to objects as constituting a "protection state" of the system. There are
three distinct problems to be solved: representing the
protection state, causing subjects to access objects
only as permitted by the protection state, and allowing
OBJECTS
subjects
5,
s,
SUBJECTS
52
files
52
devices
D,
block
read
write
wakeup
stop
seek
update
delete
execute
Figure I-Portion of an access matrix
seek
Protection-Principles and Practice
subjects to alter the protection state in certain ways.
With respect to the first, we may represent the protection state of the system as an access matrix A, with
subjects identifying the rows and objects the columns
(see Figure 1). The entry A[8,X] contains strings,
called access attributes, specifying the access privileges
held by subject 8 to object X. If string a appears in
A[8, X], we say "8 has a access to X." For example,
in Figure 1, subject 8 1 may read file F1, since 'read'
appears in A[81, F1 ] ; or, 8 2 may stop 8 3 • Figure 2
shows that an alternative representation of the protection state is a directed graph, which is in one-to-one
correspondence with the access matrix.
Associated with each type of object is a monitor,
through which all access to objects of that type must
pass to be validated. Examples of monitors are the file
system for files, the hardware for instruction execution
and memory addressing, and the protection system for
subj ects. An access proceeds as follows:
r----
Syslem
I
SUBJECTS
read t:
419
Inlervenlion
MONITORS
OBJECTS
(S;, read,F)
Sj
( Sj, wakeup, p)
granla 10 Sn. X
S.
S de~p.Y
m
I(s•• granl,a.sn.x)
(Sm,delele • .B,Sp.Y)
I
I
I
I
Figure 3-0rganization of protection system
1. 8 initiates access to X in manner a.
2. The computer system supplies the triple
(8, a, X) to the monitor of X.
3. The monitor of X interrogates the access matrix
to determine if a is in A[8, X]; if it is, access is
permitted, otherwise, it is denied and a protection violation occurs.
Note that access attributes are interpreted by object
read
write
~------------~
5,
seek
~------------~D,
block
wakeup
delete
stop
execute
Figure 2-Access diagram
monitors at the times accesses are attempted. Figure 3
shows the organization of the protection system. The
mechanisms between the dashed lines of that diagram
are invisible to subjects-subjects direct their references to objects, these references being intercepted and
validated by the monitors of the protection system.
It is important to note that the identification number
of a subject is system-provided in rule 2 above, and
cannot be forged by 8. That is, even if every subject
knows the identification number of every other subject,
there is no way for 8 to alter the fact that its identification number is presented to the monitor in rule 2;
hence the monitor cannot be "tricked" into interrogating the wrong entry of A. Since no subj ect may access
A, it is on this basis that we can develop proofs concerning the correctness of the protection system. The
correctness of the protection system can be reduced to
the correctness of the monitors.
The foregoing rules govern the use, by monitors, of
the access matrix, once it has been specified. We require
rules for changing the access matrix itself. These rules
will be enforced by the monitor of the access matrix.
Unlike the monitors of system objects, the access
matrix monitor may modify the access matrix. In particular, it may transfer, grant, or delete access attributes on command of subjects and only on appropriate
authorization. For this purpose, we introduce the access
attributes 'owner' and 'control,' and the notion of a
copy flag (denoted by asterisk), and the rules R1-R3 of
Table I to be implemented by the access matrix
monitor.
420
Spring Joint Computer Conference, 1972
TABLE I-Protection System Commands
Rule
Command (by So)
Rl
transfert~
R2
grant a
R3
delete a froID S, X
'control' in A[So, Sl
or
'owner' in A[So, Xl
delete a from A[S, X]
R4
w:= readS, X
'control' in A[So, Sl
or
'owner' in A[So, Xl
copy A[S, Xl into w
R5
create object X
none
add column for X to A; store
'owner' in A[So, X]
R6
destroy object X
'owner' in A[So, Xl
delete column for X from A
R7
create subject S
none
add row for S to A;
execute create object S;
store 'control' in A[S, S]
R8
destroy subject S
'owner' in A[So, S]
delete row for S from A;
execute destroy object S
(a' }
1(a'}
Authorization
to S, X
to S, X
Rule 1 permits a subject to transfer any access attribute it holds for an object to any other subject, provided
the copy flag of the attribute is set, and it may specify
whether the copy flag of the transferred attribute is to
be set; in Figure 4, for example, 8 1 may place 'read*' in
A[S2, FIJ or 'write' in A[S3, F1J, but it may not transfer its ability to block S2 to any other subject. The
purpose of the copy flag is preventing an untrustworthy
subject from wantonly giving away access to objects.
Rule R2 permits a subject to grant to any subject
access attributes for an object it owns; in Figure 4, for
example, SI can grant any type of access for S2 to any
subject, or any type of access to device D2 to any subject. Rule R3 permits a subject to delete any access
attribute (or copy flag) from the column of an object
it owns, or the row of a subject it controls; in Figure 4,
for example, SI can delete any entry from columns
S2 or S3, or from row S3. In order to facilitate these
rules, we require that 'control' be in A [8, 8J for every
subject S and we include rule R4, which permits a
subject to read that portion of the access .matrix which
it owns or controls. Rules R5-R8, which govern the
creation and deletion of subjects and objects, will be
discussed shortly.
It should be noted that a subject may hold 'owner'
access to any object, but 'control' access only to sub-
Operation
(a' }
l
'a*' in A[So, Xl
store a
'owner' in A[So, X]
storet'}in
in A[S, Xl
A[S,
Xl
jects. For reasons to be discussed shortly, we shall
assume each subject is owned or controlled by at most
one other subject, though other multiply-owned nonsubject objects are allowable. If a subject has 'owner'
access to another subject, the former can grant itself
'control' access to the latter, so that 'control' is implied
by 'owner.' It is undesirable for a subject to be 'owner'
of itself, for then (by Rule R3) it can delete other subjects' access to itself.
The rules R1-R4 and access attributes shown in
Figures 1 and 4 should be interpreted as examples of
rules which can be provided for the purposes intended.
One might, for example, introduce a "transfer-only"
D,
$,
$,
control
owner
owner
block
wakeup control
read*
write*
control
stop
owner
update
control
delete
owner
execute
seek
owner
owner
seek*
Figure 4-Extended access matrix
Protection-Principles and Practice
421
mode by postulating a "transfer-only copy flag"; if
this flag is denoted by the symbol ., then in R1 the
command to transfer a (or a.) from 80 to 8 for object
X would be authorized if a. were in A [80, X] and
would cause a • to be deleted from A[80, X] and a
(or a.) be placed in A[8, X} This is useful if one
wants to limit the number of outstanding access attributes to a given object-e.g., if it is required that each
subject be owned by at most one other subject, or
that a given object be accessible to a limited number
of subjects. One can also define "limited-use" access
attributes, of the form (a, k); access in manner a is
permitted only if k>O, and each use of this attribute
decreases k by one.
Figure 5-0wnership diagram
Creation and deletion of subjects and objects
The creation of a non-subject object, e.g., a file, is
straightforward, consisting of adding a new column to
the access matrix. The creator subject executes a command (rule R5 of Table I) and is given 'owner' access
to the newly created object; it then may grant access
attributes to other subjects for the object according to
rule R2. The destruction of an object, permitted only
to its owner, corresponds to deleting the column from
the access matrix (rule R6).
Creating a subject consists of creating a row and
column for the new subject in the access matrix, giving
the creator 'owner' access to the new subject, and
giving the new subject 'control' access to itself (rule
R7). The destruction of a subject, permitted only to
its 'owner,' corresponds to deleting both the row and
the column from the access matrix (rule R8).
According to our definition of subject as a pair (process, domain), there are two ways a subject can come
into existence: a given process switches from one domain
to another, or a new process is created in some domain.
(Similarly, there are two ways a subject can go out of
existence.) With respect to the former problem, a process must have authorization to switch domains since
domain-switching entails a gain or loss of access attributes. Specifically, if process P wishes to switch from
domain D1 to domain D2 , subjects 81 = (P, D1) and
8 2 = (P, D 2 ) would exist in the system; the switch by
P from D1 to D2 is permitted only if authorization (e.g.,
access attribute 'switch') is in A[81, 8 2 } In practice,
it would be more efficient to regard a subject as being
dormant (rather than nonexistent) when its process is
operating in another domain-i.e., if P switches from
D1 to D2, subject (P, D1) becomes dormant and subject
(P, D 2 ) becomes active, but the switch neither creates
a new subject nor destroys an old one. (The idea is
very much like that of transferring control between
coroutines.) In practice, therefore, rules R7 and R8
would be invoked only when a process is created or
destroyed.
We suppose that the system enforces the requirement
that each subject be owned by at most one other subject-i.e., an owner may not grant 'owner,' and 'owner'
is either untransferable or is transfer-only. In this case
the relation 'owner' defines naturally a tree hierarchy
of subjects. Figure 5 shows the subject tree for the
access matrix of Figure 4. If 81 is 'owner' of 8 2, 8 2 is
subordinate to 81. By rule R1, a subject can transfer
only a subset of its access attributes to a subordinate;
by rule R2, it can grant any access for a subordinate to
any other subject; by rule R3, it can delete any access
attribute from a subordinate; and by rule R4, it can
discover what access attributes a subordinate has. We
have carefully avoided including any provision for a
subject to acquire for itself (copy) an access attribute
it does not have but which a subordinate has obtained.
This can be incorporated, if desired, as an extension to
the model.
It is not overly restrictive to require that subjects be
members of a hierarchy, the utility of hierarchies having been demonstrated adequately in practice. This
mechanism can be used to ensure that a subordinate,
upon creation, has no more privileges than its creator.
It can be used to define a protocol for reporting protection violations (and indeed any other fault condition),
for the violation can be reported to the immediate
superior of the subject generating it. It can be used as
an aid in resource allocation and accounting, for a subordinate can be granted only a subset of the resources
held by its creator~ Considerations such as these motivated the design of the RC4000 system. 2 Our subject
422
Spring Joint Computer Conference, 1972
indirect
owner
a
Figure 6-Sharing an untrustworthy subsystem
hierarchy is in fact the same as the sphere-of-protection
hierarchy proposed by Dennis and Van Horn, 4 or the
domain hierarchy used by Lampson. Is If one regards a
process operating in the context of a file directory as a
subject, then the directory hierarchy of Multics defines
another example of a subject hierarchy. 1 As will be
seen, the rings of M ultics also define a subj ect
hierarchy. 9 ,18
A subject in a hierarchy without an owner is called a
universal· subject. For convenience, we assume there is
only one universal subject, and it has every possible
access attribute to every object. When a user wishes to
sign on the system, he communicates with the universal
subject. Having convinced itself of the user's identity,
the universal subject wil1 create a subordinate subject
for the user, and will initialize the row of the access
matrix corresponding to that subject with attributes
derived from some data file private to the universal
subject.
But if X is a subject, we must ensure that 8 2 is allowed
access to objects X can access and that X, if an active
entity, cannot access objects of S2 without authorization.
Suppose subject Sl owns a subsystem 8 which it
wishes to share with subject 8 2 • However, 8 2 does not
trust 8, and 8 1 may wish to revoke 8 2 's access to 8 at
any time. We introduce the access attribute 'indirect'
for use among subjects: if one subject has 'indirect'
access to another, the former may access objects in the
same manner as the latter, and it may read but not
acquire for itself access attributes of the latter; the
subject which owns the latter may (rule R3) revoke
the former's 'indirect' access at any time. The sharing
of 8 among 8 1 and 8 2 according to this idea is illustrated
in Figure 6. The rules of operation of object monitors
must be modified slightly to allow for indirect access:
1. S2 initiates indirect access to X through S in
manner a;
2. The system supplies (S2, a, 8-X) to the
monitor of X;
3. The monitor of X interrogates the access matrix
to determine if 'indirect' is in A[82 , 8] and a is
in A[8, X]; if so access is permitted, otherwise
it is denied and a protection violation occurs.
owner
owner
indirect
indirect
a,
Sharing untrustworthy subsystems
It is clear from the above that, if subject Sl wishes to
share an object X with subject 8 2, it may do so without
risk of S2 acquiring access to any other of its objects.
Figure 7-Cooperation between mutually suspicious subsystems
Protection-Principles and Practice
An example of the type of sharing in Figure 6 is the
"debugging problem," in which 8 1 wishes 8 2 to debug
8. Here 8 2 needs complete access to all objects accessible
to 8, but 8 must be denied access to 8 2 or its other
objects. Another example of the same type of sharing
is the "grading program" problem, where 8 1 corresponds to a student who is submitting a program 8 to
an instructor-program 8 2 for grading.
A more complicated example involves mutually suspicious subsystems. Suppose 8 1 and 8 2 own respectively
subsystems T1 and T 2; T1 and T2 are to cooperate, but
neither trusts the other. For example, T1 might be a
proprietary subroutine which 8 1 wants executed, but
not read, by others; and T2 might be a data management system which accesses certain files owned by 8 2•
Figure 7 shows how the cooperation can be arranged.
Observe that T1 may access only the objects of 8 2 (such
as X 2 ) which are accessible to T 2 , but no others, and
that 8 2 may revoke Tr's access to T2 at any time. (The
converse is true for T2 and 8 1.) Observe that T1 can
only use, but not acquire for itself, access attributes
of T 2•
We have now developed the necessary basis for a
protection theory, allowing us to view the protection
state of a system as being defined dynamically by its
access matrix. We have shown how this model allows
for protection at the fifth level discussed in the introduction. The utility of the abstractions, both in understanding current protection systems and in formulating
future "ideal" protection systems will be discussed
shortly, after we have considered the notion of correctness of a protection system.
CORRECTNESS, SHARING, AND TRUST
To prove that a protection model, or an implementation of it, is correct, one must show that a subject can
never access an object except in an authorized manner.
Two things must be proved: any action by a subject
which does not change the protection state cannot be
an unauthorized access; and any action by a subject
which does change the protection state cannot lead to
a new protection state in which some subject has unauthorized access to some object.
With respect to the first, given the correctness of
each monitor, it follows that the attachment by the
system of the identification number of a calling subject
to each reference makes it impossible for a subject to
gain unauthorized access to an object. The most important requirement in the argument is thus the assumption that the system attaches a nonforgeable
identification number to each attempted access. It is
423
necessary to prove that the operating system attaches
the identification number correctly, the monitors interrogate the correct entry in the access matrix, and no
monitor (except the access matrix monitor) alters the
contents of the access matrix.
With respect to the second, it is clear that each application of rules RI-R8 produces a new protection state
in the manner specified, assuming the correctness of
the access matrix monitor. There are, however, variou§l
aspects of trust implicit in rules RI-R8. Specifically, if
the owner of a given object is not careful, it is possible
for untrustworthy subjects, acting singly or in collusion,
to grant some subject access to that object, access not
intended by the object's owner. Since the model cannot
deal satisfactorily with problems relating to trust, this
will demonstrate the need for external regulations or
laws to complement the technical solution implemented
by the model. We shall explore this point in the paragraphs following.
Consider the transferring and granting rules (Rl and
R2). Suppose subject 8 1 has created an object X and
granted various types of access for X to subjects
8 2, ••• , 8 n • Suppose further that 8 1 intends that, under
no circumstances, should 8 0 gain access to X. He can
do this by avoiding granting any access attributes to 8 0,
but he must also grant attributes with the copy flags
off to any subject among 8 2, ••• , 8 n who he feels might
violate trust and grant access for X to 8 0 indirectly. In
other wOrds, an understanding must exist between 8 1
and subjects receiving access to X that 8 0 is not to
/receive, either directly or indirectly, any access to X.
Only when these considerations are understood and the
requisite trust is present should 8 1 be willing to pass a
copyable attribute. With this, rules Rl and R2 are
correct.
On the basis of the foregoing argument, we conclude
that the protection system is correct and will operate
exactly as intended among trustworthy subjects. Untrustworthy subjects cannot be dealt with completely
by mechanisms of the protection system. External
regulation, together with a system for detecting and
reporting violations, is required.
Consider the subject creation rule (R7). The correc~.,.
ness of the environment of the created subject is
founded on .the assumption that the creator's environment is correct, since a subordinate subject cannot be
initialized with any access attribute not held by its
creator. Thus the correctness of any subject's environment derives ultimately from the universal subject's
having created a correct environment for a user when
he signs on the system. Here is where the problem of
false identification enters. An arbitrari1y complicated
question-and-answer procedure can be developed to
424
Spring Joint Computer Conference, 1972
duration. It is not clear that (2) or (3) are
viable solutions.
indirect
owner
Figure 8-Preventing unwanted indirect access
establish the identity of a user to within any reasonable
doubt, but it cannot be done absolutely. Again, a system for detecting and reporting violations of this type
is required, and external regulations must deal with
offenders.
As further illustration of the role of trust in the
model, we consider four instances of trust's being implicit in the interpretation of access attributes themselves. First, consider the 'read' attribute. Reading is
an unusual1y powerful operation, as it implies, for example, the ability to read and copy a file. It is then
possible for one subject to distribute access attributes
for the copy freely to other subjects, even to subjects
who were not authorized to read the original. In this
sense, the 'read' attribute is equivalent to the 'read*'
attribute.
Second, consider the 'indirect' attribute, and refer to
Figure 8. Subject 8 2 has a* access to X and wishes to
transfer a to 8. However, the owner 8 1 of 8 may grant
itself 'indirect' access to 8 and so gain a access to X,
even though this may not have been intended by 8 2 •
There are several ways to solve this:
(1) Define an access mode, denoted by the symbol
'+,' which cannot be used in an indirect manner;
thus a+ is not only nontransferable, but it is
usable only by the subject to whom it was
granted. t This is shown in Figure 8.
(2) Do not allow an owner to grant itself 'indirect'
access to a subordinate subject.
(3) Make a a "limited-use" attribute so that the
exposure of X to the owner of 8 is of limited
t We have defined altogether four modes for access attributes: a*,
a', a, and a+, where a+ is the most restricted mode of a and a*
the least.
Third, consider the 'owner' attribute. A subject
creating an object is given 'owner' access to that object,
indicating that it may grant access attributes for that
object to other subjects. It is possible in our model for
the 'owner' attribute of a nonsubject object to be
transferred, and thus multiple ownership may arise.
Prior arrangements must exist among the owners, else
contradictory actions may result-e.g., one owner
grants access the others do not want granted. Such
difficulties can be avoided by allowing only one owner,
e.g., 'owner' is either untransferable or transfer-only
but it is not clear whether this is a desirable or useful
solution.
Fourth, consider rule R3, which permits the owner of
an object to revoke arbitrarily any access held by any
nonsubordinate subject to that object. This ability is
open to question. Vanderbilt argues that no such ability
is warranted as, in effect, the owner of an object and
those to whom access has been granted have entered a
contract I9-i.e., the nonowners presumably have used
the object in their programs and depend on its presence.
Lampson, on the other hand, argues that, for the proper
implementation of cooperation among mutually suspicious subsystems, absolute power of revocation is
warranted. I6 The latter view is reflected in our model.
These considerations illustrate that trust is a distinctly nontechnical concept. They reemphasize an
earlier point, viz., the complete solution to the protection problem must strike a balance between technical
and nontechnical issues. More research is required on
both issues, especially on methods of detecting and reporting violations and on coordinating external regulations with internal protection mechanisms.
Two other ways of breaching the security of protection systems exist, but do not fall in the province of the
model. First is the "wire-tapping" issue. We consider
this a solved problem, since coding techniques exist
that render it essentially impossib~e for anyone tapping
a data line to decode what he finds there. Second is the
"system-error" issue. What if a system error changes
the access matrix or the identification number of a subject or other object? Can a subject gain access it did not
have before the error? The problem can be solved by
appropriate use of coding techniques for subject and
object identification numbers and for access attributes;
in particular, it is possible to use error-correcting codes,
and to arrange that the probability of an identification
number. (or access attribute) being changed to another
valid identification number (or access attribute) is
arbitrarily small.
Protection-Principles and Practice
SYSTEM IMPLICATIONS
The protection model presented above does not resemble any particular system with which the reader is
familiar, although it likely contains concepts with which
he is. By considering implementations of the access
matrix, one can show that many protection systems are
practical examples of the theory.
Storing the access matrix
Since the access matrix is likely to be sparse, it would
be impractical to implement it directly as a twodimensional matrix. A more efficient implementation
could store the access matrix as a table of tripJes
(S, X, A[S, X])-i.e., the nonempty entries of A.
Since most subjects and objects would not be active at
any given time, it would be unnecessary to store all the
triples in fast memory at once. Moreover, it is often
necessary in practice to be able to determine what object a given subject can access (or what subject can
access a given object) ; a simple table of triples has too
little structure to permit efficient search procedures to
be implemented. Therefore, this method is unlikely to
be practical, especially when the number of subjects
and objects is large.
There are, however, at least three practical implementations. The first uses the idea of storing the access
matrix A by rows, i.e., with each subject S is associated
a list of pairs (X, A[S, X]), each pair being called a
capability and the list a capability list (C-list).4 A C-list
represents all the objects that a subject can access, together with the authorized modes of access. Following
this approach, one may regard a C-list as defining the
environment (domain) of a process, a subject as a pair
(process, C-list), and the operation of switching domains as switching to a new C-list.4,16 Because the protection system allows only authorized operations on
C-lists, possession of a capability by a process is prima
facie proof that the process has access to an object.I 5
A second approach uses the idea of storing the access
matrix by columns, i.e., with each object X is associated a list of pairs (S, A[S, X]). In Multics, such a list
is called an access control list when the objects are segments;1,18 in the Cambridge multiple-access system, it is
called an authority list. 20
A third approach represents a compromise between
the C-list and the access-control list implementations.
Suppase a set of subjects desires access to a certain set
of objects. In the C-list of each subject will appear
entries (X, K) where X is an object name and K a key.
Associated with the set of objects is a lock list containing
425
entries cf the form (L, a) where L is a lock and a an
access attribute. The monitor of the set of objects,
upon detecting that S is attempting to access X in
manner {3, will obtain an (X, K) -pair from the C-list of
X; it then will search the lock list and permit the access
only if it finds an (L, a)-pair for which K =L and a={3
(i.e., the key fits a lock that, when opened, releases the
desired access attribute). In this system, the owner of
an object X can distribute a access to X simply by
granting (X, K) pairs to various subjects and placing
(K, a) in the lock list. He can revoke this instance of a
access to X simply by deleting (K, a) from the lock
list (i.e., changing the lock) ; in this case the outstanding (X, K) pairs will be invalidated. It is possible for
an owner to create various keys and locks for the same
access attribute a-e.g., he can grant (X, K 1 ) to some
subjects and (X, K 2 ) to others, placing both (Kl' a)
and (K2' a) in the lock list. This resembles the system
of "storage keys" used in IBM System/36012 with one
important difference-viz., there is no concept of a
C-list and it is possible for certain subjects to forge
storage keys.
Efficiency
The viability of the model in practice will depend
on the efficiency of its implementation. With respect to
this, a few observations can be made. (1) Access attributes would not be represented as strings. An entry
A[S, X] of the access matrix might be represented as
a binary word whose ith bit is 1 if and only if the ith
access attribute is present. A correspondjng binary
word could be used to store the copy flags. (2) According to the rules, there is nothing to prevent one subject
from granting another unwanted or unusable access
attributes. Although this does not alter the correctness
of the model, a practical implementation may require
some mechanismto limit this effect. (3) The identification number of a subject can be stored in a protected
processor register where it is quickly accessible to object monitors. (4) The implementation of the rules for
creating and deleting columns and rows of the access
matrix must be tailored to the manner in which the
matrix is stored. In the C-list implementation (storage
by rows), for example, deleting a row corresponds to
deleting a C-list, but deleting a column would imply a
search of all C-lists. In this case, it would be simpler to
invalidate the name of the object whose column is deleted and use a garbage collection scheme to remove
invalid capabilities from C-lists. (5) The C-list implementation is inherently more efficient than the access
control list implementation because a C-list must be
426
Spring Joint Computer Conference, 1972
stored in fast-access memory whenever a subject is
active whereas an object may not be active often
enough to warrant keeping its access control list in fastaccess memory at all times.
It is worth a special note that the mapping tables of a
virtual memory system are a highly efficient form of
the C-list implementation for memory protection. A
separate table is associated with each process, and each
entry of such a table is of the form (X, Y, a) where
X is the name of a segment or page, Y is its location
in main memory, and a specifies the types of access permitted to X (typically, a is some combination of 'read,'
'write' and 'execute'). In fact, the C-list proposal by
Dennis and Van Horn4 was motivated by generalizing
the idea of mapping tables to include entries for objects
other than segments. The point is: the same techniques
used to make virtual memory efficient can be generalized to make the C-list implementation efficient. The
requisite hardware has been described by Fabry 6 and
Wilkes. 20 It is interesting to note that Multics, even
though it centers on the access control list implementation, uses a form of the C-list implementation (the
"descriptor segment") as well, the appropriate entries
of the access control list being copied into the descriptor
segment as needed. I
Choosing subjects and objicts
The model assumes that an access attribute applies
uniformly to an object and all its components, but
allows components of objects to be objects themselves.
It is possible, for example, to regard a file as an object
and some of its records as objects too. Thus the designer
has great flexibility in the choice of objects.
By taking a subject to be a (process, domain) pair,
the model forces all components of a process to have
identical access privileges to objects. Thus, whenever
it is necessary to grant components of a process differing access privileges, it is necessary to define different
subjects for each component. To illustrate this paint,
suppose a process P operating in domain D consists of
subprocesses PI, ... , P n which must be accorded
differing access powers. Since the domain defines the
access powers of a process, the subjects (PI, D), ... ,
(P n , D) would have identical access privileges. Instead,
the system would have to allow the definition of subjects
(P, D 1 ), ••• , (P, Dn) where domain Di is effective
while subprocess Pi is executing; only then can the subprocess Pi of P be accorded differing access privileges.
As further illustration of the latter problem, consider a system implementing segmentation, in which a
process P is uniquely and permanently associated with
a name space described by a segment table T; i.e., each
subject is a pair (P, T). Suppose T = [( S1, al), ... ,
(Sn, an) ] where Si is the ith segment and ai defines the
access P has to Si. If now we want to debug a new scgment Sn+l, there is no way to change P's access power
when it enters segment Sn+l. In terms of Figure 6, it is
not possible in this system to put the segment being
debugged at a subordinate level. One solution would be
to place Sn+1 in its own name space with segmcnt table
T' and process P', so that the subject (P', T') being
debugged is subordinated to the debugger (P, T). This
cannot be done very efficiently, as software-implemented message-transmitting facilities would have to
be used for communicating between the processes P and
P'. The problem could have been avoided in the first
place if it were possible to define a series of domains
Ti = [(Si, ai) ] and subjects Si == (P, T i ) so that Sn+1
can be made subordinate to SI, ... , Sn. This is the
approach suggested by Evans and Leclerc. 5
Existing systems
We examine now several important systems in the
light of the model. For each system we will identify
the elements of the model, points of inefficiency, and
points of insecurity (if they exist).
One of the most common systems, in use is IBM's
OS/360.u In this system, objects typically are files,
tasks, and instructions. The domains correspond to
pairs (mode, block) where "mode" refers to the supervisor/problem-program machine states and "block"
refers to a block of the multiprogramming partition of
main memory. A subject is then a triple (task, mode,
block). One of the principal elements of the model is
not present, viz., the idea of attaching a subject identifier to each attempted access; the storage-key mechanism in effect does this for access to objects in memory,
but there is no such notion associated with attempts to
switch domains or to reference files. It is possible for a
task to guess a supervisor call number and issue a supervisor call (SVC) with that number, thereby gaining
unauthorized access to the supervisor domain. It is also
possible for a user to guess a file name and access it
through the job control language.
OS/360 is representative of many current commercial
systems in the lack of an adequate protection system
and underlying protection theory. The limitations above
indicate the OS/360 does not even provide protection
at the lowest level mentioned in the Introduction, i.e.,
it cannot guarantee absolutely that each user is protected from the ravages of other users. The two systems
described below (RC4000 and Multics) do embrace
Protection-Principles and Practice
the concepts of the model, concepts which must be embraced widely in the commercial systems before they
will be capable of providing protection at the level
required for sharing mutually suspicious subsystems.
There are, of course, other systems which embrace the
concepts of the model, but which cannot be discussed
here for lack of space; these include the CAL system at
Berkeley,14 the capability hardware proposed by Fabry
at Chicag0 6 and Wilkes,20 Project SUE at the University of Toronto,S and the IDA system. 7
The RC4000 system is one example of a commercial
system having a protection system incorporating all the
elements of the modeJ.2 The objects of this system include the usual repertoire of files, devices, instructions,
and processes. In this system, each process defines a domain (i.e., subjects are identical to processes), and a
"father-son" relation defines a hierarchy of processes.
Each object is associated with exactly one domain;
therefore each process has exclusive control over certain
objects, and it must request other processes to access
other objects on its behalf. (In this sense, each process
is the monitor of its objects.) For this purpose, the
system implements a message-transmission facility and
associates with each process a message buffer in which
are collected all messages from other processes. A process P wishing to send message a to process P' uses a
system call
send Illessage (a, P'),
the effect of which is to place the pair (P, a) in the
message buffer of P'. Note that this is precisely the
notion of attaching the identification number of a subject to an attempted access, if we take the view that
each process is an object monitor and a message is an
attempted access to some object controlled by the
monitor. This system provides a great deal of flexibility: each process plays the role of a monitor; the
number of monitors is variable; the definition of an
object can be dynamic since the programming of a process can be used to implement "virtual objects" which
are accessible to other processes via the mess agetransmission facility; and each process can determine
the authenticity of each message it finds in its message
buffer. The limitations of this system include: the
message facility, being implemented in software, is of
limited efficiency; there is no way to stop a runaway
process, as the system cannot force a process to look in
its message buffer; and a possibly elaborate system of
conventions may need to be adopted in order that receivers can learn the identification numbers of senders.
Further discussions of these points are found in References 3 and 15.
The M ultics system at MIT is an example of a non-
427
commercial system which implements the elements of
the protection model. Typical objects are segments and
processes. The virtual memory is the monitor of the
segments and the traffic-controller the monitor of the
processes. The domains of this system are defined by
pairs (ring, base) where "ring" refers to integers
0, 1, 2, ... and "base" is a pointer to the descriptor
segment (segment table) of the name space. Each process is associated with exactly one name space so the
base can be used as its identification number. Each
segment s has associated with it a ring number ns; if
process P is executing instructions from segment s in
name space with base b, the subject is the triple (P,
n s , b). Observe that a control transfer from segment s
to segment tfor which ns~nt defines a change of subject. The access privileges of a subject are considered
to diminish as its ring number increases; in other words,
for given P and b, the ring numbers 0, 1, 2, . /•. define a
linear hierarchy of subjects (P, 0, b), (P, 1, b), (P,
2, b), .... Associated with segment s are three pairs of
integers
(rl' r2)-the read bracket, rl::;r2
(WI, w2)-the write bracket, WI::; W2
(el' e2)-the execute bracket, el::;e2
(These numbers can be stored in the segment table
along with flags indicating whether each type of access
is permitted at all. In Multics, only three of the seven
integers associated with a segment are distinct, so only
three integers need be stored to represent the three
access brackets and ring number.) In terms of a subject
hierarchy, the notion of an access bracket for access
attribute a of an object means simply, for a certain
range of levels above and below the owner of the given
object, a superior or subordinate subject within the
range is automatically granted a access to the object.
It is an extension of the concept of access attribute.
The access matrix is stored statically in the form of
access control lists associated with objects (segments).
This information is copied dynamically into the descriptor segment as segments are referenced for the
first time, so that the descriptor segment is a form of a
capability list. A subject (P, n s , b) may access in any
manner any segment t listed in the descriptor segment
when nt > ns; furthermore, if nt::; ns it may read, write,
or execute (transfer control to) t if ns falls in the proper
attribute access bracket of segment t. If it wishes to
transfer control to a segment t whose execute bracket
is (el' e2) but ez < n s , it may do so by transferring to a
"gate" (protected entry point) of segment t; the attempt to do so generates an interrupt which invokes a
"gatekeeper" that permits transfers only to gates. A
428
Spring Joint Computer Conference, 1972
full description of the mechanism as outlined above can
be found in References 9 andJ8.
CONCLUSIONS
We have carefully tried to limit the complexity of the
model, omitting from its basic structure any feature
which is either controversial or not completely understood. It is possible to extend the model in any or all
of the following ways. (1) A subject which creates an
object can specify that the object is permanent, so
that the universal subject can make that object available for future reincarnations of that subject. Alternatively, a subject can specify that, if it dies, ownership
of objects it owns can revert to a superior subject. (2)
In a subject hierarchy, superior subjects can be regarded as dormant when their processes are not executing, so that subordinates can send messages which, for
example, request additional access attributes. (3) Since
a subordinate subject may acquire access attributes not
held by its superiors, rules may be required specifying
when superiors can acquire such attributes for themselves; Lampson allows for this.15 (4) Given the possibility of multiply-owned objects, rules may be required
to permit owners to guard their access attributes from
deletion by other owners. (5) If one adopts the view
that a subject and all its subordinates constitute a
"family," 2 one can make a case for allowing a subject
to transfer an access attribute to a subordinate even if
the copy flag is not set.
The considerations of the section on System Implications indicate that most current commercial systems do
not implement a complete protection mechanism, even
at the lowest level described in the Introduction. The
most serious defect is the lack of completeness when a
process changes protection environments. Although the
incompleteness of these systems could be rectified by
(probably extensive) software modifications, a complete
protection system cannot hope to be efficient unless the
basic elements of the model are implemented in hardware. The requisite hardware has been described in
many forms-by Fabry,6 by Schroeder and Saltzer,18
and by Wilkes 2°-and is in fact quite straightforward.
It can be noted that the "average" user, who employs
only system compilers and library routines, is unlikely
to break the security of the system if only. because
compilers and library routines will not cause the loopholes to be exercised. This does not mean attention
should not be paid to structuring the hardware so that
even the most enterprising and malicious user cannot
break security. It takes only one such user to compromise another's privacy which, once lost, may be irre-
coverable. On this basis, the cost of hardware and
software development required to achieve efficient implementations of protection is of the utmost value.
We began the paper with the statement that the
technical approach to protection had not been treated
adequately to date in the literature. Hopefully, the
discussion here has shown that it is possible to state
the problem on an abstract level where the elements of
protection can be isolated, where methods of proving
the correctness of a protection system can be formulated, where drastically different physical implementations of the one model can be compared and evaluated,
and where the nontechnical issues required to complement the technical ones can be identified. The discussion here has been intended as an example of what is
possible in a model; we are under no delusions that
this is the only model or that this is the best model.
Our preliminary work has indicated that the abstractions formed in the modeling process are useful in
themselves and that the model provides a framework
in which to formulate precisely previously vague questions. We hope that this discussion will motivate others
to undertake additional research in this area. Much
needs to be done.
ACKNOWLEDGMENTS
We are indebted to Michael Schroeder for pJinting out
the seven levels of sharing mentioned in the Introduction, and to Richard Holt, Butler Lampson, Richard
Muntz, and Dennis Tsichritzis for many helpful discussions ,and insights.
REFERENCES
1 A BENSOUSSAN C T CLINGEN R C DALEY
The MULTICS virtual memory
Proc 2nd ACM Symposium on Operating Systems Principles
Oct 1969 pp 30-42
2 P BRINCH-HANSEN (Ed)
RC-4000 software multiprogramming system
AjS Regnecentralen Copenhagen April 1969
3 P J DENNING
Third generation computer systems
Computing Surveys 3 4 Dec 1971
4 J B DENNIS E C VAN HORN
Programming semantics for multiprogrammed computations
Comm ACM 9 3 March 1966 pp 143-155
5 D C EVANS J Y LECLERC
Address mapping and the control of access in an interactive
computer
AFIPS Conf Proc 30 Spring Joint Computer Conference
1967 pp 23-30
Protection-Principles and Practice
6 R S FABRY
Preliminary description of a supervisor for a machine
oriented around capabilities
ICR Quarterly Report 18 University of Chicago August
1968 Section I pp 1-97
7 R S GAINES
A n operating system based on the concept of a supervisory
computer
Comm ACM 153 March 1972
8 G S GRAHAM
Protection structures in operating systems
MSc Thesis Department of Computer Science University
of Toronto August 1971
9 R M GRAHAM
Protection in an information processing utility
Comm ACM 11 5 May 1968 pp 365-369
10 L J HOFFMAN
Computers and privacy: a survey
Computing Surveys 1 2 June 1969 pp 85-104
11 IBM System/360 operating system concepts and facilities
IBM Report No GC28-6535 November 1968
12 IBM System/360 principles of operation
IBM Report No GA22-6821 September 1968
13 IBM System/370 principles of operation
IBM Report No GA22-7000 June 1970
429
14 B W LAMPSON
On reliable and extendable operating systems
Techniques in software engineering NATO Science
Committee Working Material Vol II September 1969
15 B W LAMPSON
Dynamic protection structures
AFIPS Conf Proc 35 Fall Joint Computer Conference 1969
pp 27-38
16 B W LAMPSON
Protection
Proc Fifth Annual Princeton Conference on Information
Sciences and Systems Department of Electrical Engineering
Princeton University Princeton New Jersey 08540 March
1971 pp 437-443
17 S MOTOBAYASHI T MASUDA N TAKAHASHI
The Hitac 5020 time sharing system
Proc 24th ACM N at'l Conference 1969 pp 419-429
18 M D SCHROEDER J H SALTZER
A hardware architecture for implementing protection rings
Comm ACM 15 3 March 1972
19 D H VANDERBILT
Controlled information sharing in a computer utility
MIT Project MAC report MAC-TR-67 October 1969
20 M V WILKES
Time sharing computer systems
American Elsevier 1968
PRIME-A modular architecture
for terminal-oriented systems*
'by HERBERT B. BASKIN, BARRY R. BORGERSON and ROGER ROBERTS
University of California
Berkeley, California
INTRODUCTION
The main attribute of a computing facility that will
serve many users simultaneously is that it provide
continuous service. By this we mean the ability to
service as many users as possible even when a failure
has occurred within the system. Failures must be
considered normal occurrences which can co-exist with
a full range of other normal operations such as resource
allocation, interpreting user commands, etc. However,
conventional time-sharing systems cannot cope with
these failures, and hence cannot offer continuous
availability, since large and complex portions of both
hardware and software are concentrated in unique
units of the system. vVhile it may appear on the surface
that further development and refinement of the basic
strategy will bring one closer to the goal of continuous
availability, we feel this is a false evolutionary path.
Instead the approach we have taken is to begin with a
totally different architecture which achieves these
goals at the very outset.
All of the above considerations are no less true when
several processing units are employed as scheduling
processors, communications processors, file control
processors, etc. The basic problem is that such organizations are all predicated upon the notion that the
normal mode of operation of the overall system is
when no failures exist. In any practical utility, such as
a telephone system or power system, it is always assumed that failures exist as a normal occurrence and
must be treated while continuing as near normal
operation as possible. This assumption is one of the
basic cornerstones of the architecture described in this
paper.
Another motivation behind our approach is to provide
the ability for any user to continue undisturbed with
his use of the system even though it is undergoing
considerable change. In a conventional architecture,
all user programs run under system-wide software
which, if changed, may require the user to update his
programs. Even when a considerable effort is made to
The architecture of most interactive systems is based
on the general strategy that suitable terminal service
can be provided by a central processor that is timemultiplexed among all the active terminals. In order
to achieve adequate response time in an interactive
environment, the CPU is usually time sliced. Other
major system facilities such as I/O channels and
secondary storage units are also shared among the
users, and multiprogramming techniques are employed
to keep all the major system resources as fully utilized
as possible. An operating system is usually developed
which performs these functions as well as supervising
the terminal communications, implementing a systemwide filing subsystem, handling user commands, etc.
The result of combining these and other functions into
a time-sharing operating system is a highly complex
software system which transforms what is basically
a batch processing computer structure into a multiterminal system with significant limitations that are
an outgrowth of this strategy. While a failure can occur
in any section of the hardware or software, we know
that hardware failures axe more likely to occur in the
electromechanical and core memory sectors than in
solid state logic, and that software failures tend to be
concentrated in the more complex areas of code.
Failures of hardware components may require modification of the operating system in order to regain
operational status since the allocation strategies may
need more than parametric modification when system
resources are affected.
* This research was supported by the Advanced Research Projects
Agency of the Department of Defense under Contract No.
DAHC15 70 C 0274. The views and conclusions contained in
this document are those of the authors and should not be
interpreted as necessarily representing the official policies, either
expressed or implied, of the Advanced Research Projects Agency
or the U.S. Government.
431
432
Spring Joint Computer Conference, 1972
SUB-SYSTEM 1
r--
SUB-SYSTEM N
SUB-SYSTEM 2
SECONDARY
SECONDARY
SECONDARY
MEMORY
MEMORY
MEMORY
PROCESSOR
r--
-
PROCESSOR
PROCESSOR
PRIMARY
PRIMARY
PRIMARY
MEMORY
MEMORY
MEMORY
COMMUNICATIONS CHANNEL
-
-
Figure 1-Canonical system
avoid such situations, they do occur, and represent a
fundamental flaw in the design. In the PRIl\llE system,
the only requirement is that user software be compatible with the processor instruction set.
A user who wishes to have a local operating system
supplied to him may avail himself of a currently available version, use a colleague's system, or supply his
own. As a result of this new degree of freedom the user
may elect to continue using a version of an operating
system which has been superseded, thus insuring that
his programs, which have been running in a satisfactory manner, will continue to do so. This is of considerable importance in a commercial environment.
SYSTEM ARCHITECTURE
The PRIME system structure is highly modular in
that it is composed of a small set of different functional
units, each of which is replicated many times. The
major functional units include primary memory
modules, secondary storage modules, and processing
modules, which are so interconnected that larger functional units are obtained, each a replication of another.
An understanding of this architecture can best be
gained by examining the structure and properties of a
conceptual system which we call the canonical system.
As can be seen from Figure 1, the canonical system is
composed of a number of subsystems, each independent
of the others, which can communicate with each other
through a communications channel. Since a subsystem
is composed of a processor, primary memory, and
secondary storage, it is completely self-contained and
able to function independently. The communications
channel is used to facilitate data transfers between
subsystems. I t can be used only in a very specific
manner, in that both the sender and the receiver of
the data must agree to set up the communications
path, and is present mainly for data base sharing
operations among users.
This canonical system consists of n identical sub-
systems which can process n independent jobs with an
extremely high degree of protection from each other.
Software faults within a subsystem, whether in the
user software or in the local operating system (within
each subsystem) cannot affect the other subsystems.
In addition, hardware failures for the most part only
affect the faulty subsystem. There are, however, some
possibilities that certain hardware failures (in the
communications channel) can cause erroneous interconnections between the subsystems. In these cases,
which are strictly non-electromechanical, fault detection schemes can be provided which would guarantee
the integrity of the communications channel. System
availability with this approach is therefore very high
since a failure (hardware or software) usually affects
very few of the subsystems.
The canonical system, as was shown above, could
provide us with a highly secure and available system.
However, in order to achieve more efficient and useful
system operation, it is necessary to have methods for
allocating the system resources among a large number
of users. This must be accomplished without degrading
the security or availability characteristics of the
canonical system. Accordingly, three additions are
made to the canonical system structure just described.
The first addition is to place a memory switching unit
in each path from a processing module to its primary
memory modules, and to allow each memory switching
unit to connect to a large number of primary memory
modules. This allows processing modules, and therefore basic subsystems, to share primary memory modules and therefore allows for variable primary memory
resource sharing. The second addition is to place a
switching unit in each path from a processing module
to its secondary storage modules. This modification,
together with the previous one, allows for extensive
resource sharing within the system. The third addition
which is necessary to manage allocation of system
components is a controlling process, called the control
monitor.
The resultant system now has facilities for extensive
resource allocation, but still retains the security and
availability properties of the basic canonical system.
This is because, at any instant in time, PRIME is
configured to be n subsystems, each consisting of a
processor, primary memory, and secondary storage.
Each of these subsystems can be considered to be
logically and electrically distinct, and as such, compose
a system which is essentially similar in structure to the
canonical system. The effect of the additions was
merely to allow the specific partitioning of the configurations to vary over time. In order to achieve the
capability to allocate and repartition the system we
use one subsystem to implement the control monitor.
PRIME
Its processor is designated the control processor while
the remaining processors are called problem processors.
Since the assignment of roles of the processors is completely arbitrary, it can vary on a dynamic basis. The
functions of the control monitor include job scheduling,
terminal buffer management, secondary storage allocation, primary memory allocation, low-level accounting, system diagnosis and problem processor
monitoring. The problem processors, on the other hand,
have as their main responsibility that of executing
user jobs. In order to accomplish user service functions,
each problem processor contains a local monitor, whose
functions include user program file transfers, user
program trap routines, and general program I/O.
Each of the subsystems is completely self-contained
in that each processing module is composed of a number
of functional units which allow it to fully complete a
processing cycle. By this we mean that once a subsystem composition is formed and a user process has
been activated, no further interaction between that
process and the control monitor is necessary until the
completion of the job step. Additionally, each processing module contains functional units, inaccessible
to user processes, which are used for system-wide
functions and control. The particular functional units
implemented in each processing module are:
(1)
(2)
(3)
(4)
(5)
(6)
target machine
disk control
memory access
terminal control
communications channel
control monitor extension
where the first three are for user process execution and
the last three are system functions.
The target machine functional unit executes machine
language instructions and is the interface between user
software and the system. A complete description of it
would be beyond the scope of this paper. 2
The memory access and disk control functional units
allow the processing module to access, in a secure manner, primary memory modules and secondary storage
modules. Each is composed of machinery restricting
these accesses to allocated modules. This latter machinery is in the form of maps, which translate user
virtual addresses into system absolute addresses. The
contents of the maps are set by the control monitor,
in a manner described below, at the inception of a job
step, when the control monitor allocates primary
memory and secondary storage modules to the process
just starting up.
The terminal control functional unit in each processing module is connected to a subset of all the
433
terminals connected to the system, and transfers characters between them and the control monitor. With
this organization, we have obviated the need for a
unique multiplexor, with its attendant reliability
problems, and have distributed the terminal control
throughout the system. It should be noted that there
is no direct relationship between the terminals connected to a processing module and the user processes
executing on it.
The information flow between the control monitor
and processing modules, as discussed above, is accomplished through the agency of the communications
channel functional unit in each processing module.
This unit allows for data to be exchanged between the
control processor and any of the problem processors.
At the heart of each processing module, managing
the activities of the previously discussed functional
units, is the control monitor extension functional unit.
Each ECM (extended control monitor) is actually a
part of the control monitor, performing local actions
on its behalf within each subsystem. These actions
include setting and reading the map entries of the
memory access and disk control functional units, saving
and restoring the state of user processes, managing the
swapping of user processes, interfacing between the
control monitor and user processes, and implementing
local error checking and diagnostic algorithms. It
should again be noted that the ECM is not implemented in software, executing on the target machine
functional unit, but is a distinct functional unit completely inaccessible to and independent of user programs.
The combination of the control monitor executing
on the control processor, and each of the ECMs contained within problem processors provides for a rational
distribution of responsibility and a concomitant decrease in complexity. Global allocation of primary
memory modules and secondary storage modules to
processes, and processes to processors is performed by
the control monitor, while local allocation of virtual
addresses to absolute addresses and local process control is performed by each EClVl. Similarly, global error
checking and diagnosis are performed by the control
monitor, while local error and consistency checks are
performed by each EClV1.
The main result of this organization is that system
functions are completely shielded from user programs
in that the control monitor and user processes are
never executed on the same processor. There is a physical barrier, brought about by the structure of the
system, between those system operations which must
remain secure from interference by potentially harmful
user software. The allocation of the system between
system functions and user functions is not time-multi-
434
Spring Joint Computer Conference, 1972
plexed, as in most conventional organizations, but
rather distributed in space. This has many implications relating to system security. The two most important are that since the control monitor is always
executing, it is able to continuously monitor the state
of the system and that a failure, either in hardware or
software, does not cause a breach in the barrier between
the system and a user. The decrease in complexity of
the control monitor which accrues from the fact that
it runs on an independent processor and is involved
with each active process only at its initiation also
contributes to system security and availability. With
a less complex monitor, it is considerably easier to
prove that the system software, as it relates to security
functions, is operating correctly. Additionally, since
the control monitor is responsible for only a subset of
the system functions, and hence maintains only a few
of the system state tables, it is decidedly easier to recover from a control processor failure.
The processing modules, as described, consist of six
independent functional units. In the first implementation of PRIME, however, these processing modules
will be constructed from microprocessors and a
modest amount of special hardware, with the separate
functional units being micro-code subroutines. We feel
that this organization is desirable since we are developing a system with which we can conduct experiments with different operating procedures and system
organizations. We consider the first implementation
of the PRIME system to be a laboratory within which
we can experimentally implement a variety of different systems that have in common a number of the
architectural features described above.
The decision to employ microprocessors was made
to allow for maximum flexibility of the system for such
experimentation. An alternate implementation choice
would be to construct each processor module from a
number of very small inexpensive processors. In addition to the flexibility advantage, the microprocessor
choice currently has a cost advantage. However, this
situation is expected to radically reverse itself in the
next few years. The PRIME architecture will allow
us to keep up with the trend toward low cost LSI
processors without any architectural changes to the
system since later expansion would be with additional
modules that are functionally similar to the microprocessor modules, but are internally implemented
using several LSI processing units.
processing modules are general-purpose micro-programmable processors which operate on 16-bit operands
with a cycle time of approximately lOOns. The control
storage for these processors is arranged in 32-bit words,
which is also the instruction width. When fetching
operands from control store, only half of the word is
used. The processor has 2048 words (32-bit wide) of
control store and 32 directly addressable 16-bit registers. The data processing logic consists of an arithmetic/logical unit which processes data received from two
source buses (A and B buses) and stores the result into
the destination register via a third bus (D-bus) after
passing the data through a shifter unit. The processor
we use which has these characteristics is the META 4
microprocessor units supplied by Digital Scientific
Corp.
The processing element uses 21 double bus accumulators and eight general-purpose I/O registers.
Five of the I/O registers are used to drive the primary
memory system. Of these, two are for transferring
data, one for the operand address, one for the instruction address, and one for the memory status. In each
processor, the remaining three I/O registers drive the
I/O bus which is used for all communications between
that processor and external devices. This includes devices attached to the I/O terminals, the real-time clock,
the time-of-day clock, the memory map, fault detection messages, and the external access network which
will be described below.
The primary memory system for each processing
module consists of the five I/O registers, a memory
interface which controls memory traffic and contains
\ a memory map, and a memory bus. As shown in Figure
SYSTEM COMPONENTS AND OPERATION
EACH MEMORY BUXK (MB) CONSISTS OF TWO 4K MODULES
The components of the PRIME system are interconnected in the manner illustrated in Figure 2. The
Figure 2-A block diagram of the PRIME system
PRIME
3 each memory block consists of a four-by-two switching matrix and two 4k X 33 bit memory modules,
each of which is partitioned into four 1k word pages. 3
There are five memory buses in the system, each of
which connects a processor to eight memory blocks.
Thus each processor connects to 16 of the 26 4k memory
modules in the system.
Since 64k words of memory is substantially greater
than the size of the working sets we anticipate encountering, the allocation of memory modules will be
simple and \. straightforward. In addition, the possibility of being unable to schedule a process due to insufficient free memory /modules will be remote. The
use of the four-port memory switching units not only
provides a distributed memory switch which contributes to the high availability of the system, but also
allows for experimentation with different memory /
processor connection algorithms.
With the exception of fault reporting and map loading
and reading, the memory interface is independent of
the I/O bus. The conflicts between the processor and
the disks for the use of a memory bus are resolved in
the memory control and switching unit shown in
Figure 4. This unit also buffers a single word requested
by the instruction address register, thus allowing instruction prefetches. In addition to translating logical
pages into real pages, the memory map contains bits
that specify whether a page is writable, readable, or
executable. The use of separate operand and instruction address registers allows the hardware to determine
the difference between an operand fetch and an
instruction fetch and thus to easily detect when any
reference violation has occurred. Other bits in the map
include a dirty-page bit, a use bit, and a parity bit.
The memory is constructed from lk bit lV108 de-
PORT A
PORT B
PORT D
PORT C
r r I r
4 x 2
4K X
33 MOS MEMORY
SWrrCHING MATRIX
4K X
33 MOS MEMORY
POWER SUPPLY
Figure 3-Memory block
435
EACH BUS
GOES TO
8 MEMORY
BUlCKS
}
Figure 4-PRIME memory system
vices instead of the traditional core storage technology.
Each 4k X 33 bit memory module is made up from 132
such chips. The memory modules have 400ns access
and 550ns cycle times. Refresh is performed automatically within the module, using one cycle every
100 microseconds.
In the PRIME system, swapping space, secondary
storage, and third level storage all reside on a single
type of storage unit. This gives us another level of
modularity and interchangeability which in turn contributes to the continuous availability of the system.
The unique feature of the PRIME architecture which
provides that each active process has its own processor
and secondary storage unit makes possible this use of
a single device for all of these functions. For this purpose we have chosen a commercially available highperformance moving-head disk drive, and have modified it to transfer data at twice its normal rate. This
drive is a modified 1\10del 213 unit supplied by Century
Data. The basic lVrodel 213 has 11 platters, 20 heads,
400 tracks, a capacity of approximately 60 million
bytes, an average access time of 32 milliseconds, a
latency of 12.5 milliseconds, and a transfer rate of 2.5
MHz. We have modified the units to read two heads
in parallel so that at the interface it appears to have
10 heads and a transfer rate of 5MHz. Using two heads
in parallel with moving head disks drives results in a
deskewing problem which is especially acute when one
tries to read data from a disk pack written on another
drive. Rather than attempt to provide enough buffering to handle the worst possible case of head skewing,
we chose to deskew the data by reading words from
each head into every other memory location. That
is, words assembled from one head are written into
odd memory locations, and those from the other head
into even memory locations. Thus if one head gets
ahead of the other, the controller will simply wait for
the last head to finish reading before proceeding. With
this scheme we can roll in an 18k working set in under
200 milliseconds.
436
Spring Joint Computer Conference, 1972
Each processor in the system can simultaneously
connect to any two of the disk drives through the External Access Network as shown in Figure 2. One of
these disk paths will normally be used for user file
operations, and the other will be used for overlap
swapping. Hence, if all ten disk drive paths are transferring simultaneously, the total transfer rate between
secondary and primary memory will be 50 MHz or
better than 6 million bytes per second. This is indeed
a very high rate obtained from such inexpensive devices (approximately $.00003 per bit including modifications and controller). This type of high performance
file capability is particularly important to interactive
users as well as those who are data-base oriented. Such
users tend to require turnaround times of Y2 to 2
seconds within which they need only several tens of
milliseconds of processing time. In the PRIME system,
a process can be continuously active for up to several
hundred milliseconds during which user paging activity
could take place directly between a problem processor
and its dedicated secondary storage unit. In such an
environment, the amount of primary memory needed
to efficiently execute a process is substantially less than
that required in previous system structures.
With the exception of the terminals, all I/O between
the PRIME system and external devices takes place
via the External Access Network (EAN). This unit
allows any processor to connect itself to any external
device or to any other processor. Each processing
module has three paths to the EAN. Each path contains a parallel interface which is 40 bits wide and
transfers data asynchronously at a rate of about lOOk
words per second. On the processor end the data are
routed directly to and from the processor by the I/O
controller. In addition to the 40-bit path that communicates directly with the processor, each path
through the EAN contains two lines that assemble
data from the disk and transfer them directly to
memory. These two bits are used only by the disk data
paths. All other I/O, including that of the remote end
of the disk controllers, takes place through the standard
40-bit path. Actually, the internal switching unit
tha t is part of the EAN is only four bits wide in each
direction. The 40 bits are always disassembled, transmitted through the switch, and then reassembled at
the other end. However, these are internal details
within the EAN and are not apparent at any of its
ports. The cost of the switch within the EAN is a
function of the product of the number of processors
and external· devices and also is proportional to the
width of its internal data path. These considerations
together with our bandwidth requirements have led
us to the selection of a four-bit internal switching path.
A more complete discussion of the design considerations
of the EAN is presented in another paper in these proceedings.4
Each processing module is connected to an equal
number of terminals, thereby achieving a distributed
input/ output capability. Each terminal is connected
to two processors so it can continue to run in the
presence of a failure of a processing module. This
provides back-up at minimum cost since the connections to the processors consist simply of level shifting
circuits. All assembly and disassembly of characters
is done by the microprocessor on a bit by bit basis.
As soon as a character is assembled by a processor, it
is sent to the control· processor where line editing and
buffering takes place.
Interprocessor communication takes place via the
External Access Network. Direct communication between problem processors is not allowed. Rather, all
interprocessor communication is ini tiated by the control
processor connecting itself to a problem processor
through the EAN.
The External Access Network treats all of the
processor ports in a symmetrical manner. However,
at any point in time one processor port is designated
as the controlling port and as such has the capability
to establish a link between any other processor port
(addressing port) and an addressable port to which
external devices may be connected. Thus we not only
achieve the above mentioned ability for a control
processor to communicate with other processors and
for any processor to connect to any external device,
but by redesignating the controlling port, we can make
any of the processors in the system the control processor. We have developed techniques for the redesignation of the control processor that would allow for continuous operation of the PRIME system in the presence
of a hardware failure anywhere in the system. These
techniques will be described in a later paper.
SUMMARY
We have described a system which is currently being
constructed by the Computer Systems Research
Project at the University of California at Berkeley
with the support of the Advanced Research Projects
Agency. Our principal goals are to open up new architectural avenues that will lead to simpler, more reliable, and secure terminal oriented systems. The
architecture we have described here provides the user
with a target machine having an exceptionally high
bandwidth to secondary storage and a powerful medium
scale computer on a dedicated basis during the period
PRIME
that he needs processing. The technique of having a
bank of components to draw from to construct such a
user subsystem allows for nearly continuous operation
without having to use redundant components.
ACKNOWLEDGMENTS
The authors wish to acknowledge the contributions
of a number of people who include Larry Barnes,
Robert Fabry, Domenico Ferrari, Richard Freitas,
Charles Grant, Mar, Greenberg, Paul Morton, Jesse
Quatse, and C. V. Ravi.
437
REFERENCES
1 H BASKIN et al
A modular computer sharing system
Communications of the ACM 12 pp 551-559 October 1969
2 R ROBERTS
The target machine for the PRIME system
Internal document no. R-1.0 November 1971
3 C V RAVI
M emory addressing and processor-memory interconnection
Internal document no. W-13.0 August 1970
4 J QUATSE P GAULENE D DODGE
The external access network of a modular computer system
AFIPS Conference Proceedings Vol 40 Spring Joint
Computer Conference 1972
Computer graphics terminals-A backward look
by CARL MACHOVER
Information Displays, Inc.
Mt. Kisc~, New York
INTRODUCTION
duced in Spring 1964 with the IBM 360 Series comupter,
three additional versions were subsequently offered.
Two companies (Stromberg Carlson and Philco-Ford)
have essentially withdrawn from the commercial field.
Several companies do not appear in either list, because
either they introduced and then withdrew products in
the intervening years, or they introduced products and
were then merged into another company. For example,
Corning Data Systems and Graphics Display Ltd
(England) both introduced low cost graphic terminals
several years ago and then either formally, or informally,
withdrew them from the market a year or so later. Computer Displays, Inc. introduced the first low cost graphic
terminal (using a storage tube) about four years ago,
and then merged into Adage about a year ago, losing its
corporate identity.
I will not be surprised if there are other changes by
the time this is published in May 1972 ... new products
and suppliers, mergers, or product withdrawals. For example, plasma panels and liquid crystal panels with associated displays are just now becoming commercially
available from Owens-Illinois and Optel, respectively.
I estimate that the companies listed have each spent
in the range of $250,000 to $3,000,000 to bring these
commercial products into the market place. Perhaps,
then, some $50,000,000 has been invested in these
terminals, whose current installed value is about equal
to that investment. Certainly, graphic terminal business
is not a "get-rich-quick" scheme!
Five years ago, the price of admission into Interactive
Computer Graphics was spending about $50,000 or
more for the Graphics Terminal and associated hardware, plus writing almost all of the applications software, as well as much of the basic software. And, only
about a dozen suppliers offered commercial equipment.
Today, the price of admission has dropped dramatically. Graphics Terminals can be purchased for less than
$10,000. Some turnkey applications software packages
are available. And the buyer can choose from among
more than 35 hardware and system suppliers, offering
over 60 different models.
Some aspects of graphics terminal performance have
not changed materially over the past five years. For example, maximum screen data content (number of flickerfree points, characters and lines) has remained almost
constant for refresh displays. However, there have been
significant advances in other areas, such as intelligent
(minicomputer-based) terminals, low cost terminals,
color displays, specialized hardware function devices,
graphic tablets, and the use of storage tubes and digital
TV to increase screen content.
SUPPLIERS
In my FJCC Paper about five years ago,! I listed sixteen manufacturers of commercially available CRT
graphic terminals. A comparison between that list and
an updated version compiled from Computer Display
Review,2 and Modern Data Systems,S is given in Table
1.
The number of suppliers has more than doubled in the
past five years. During the past five years, several
companies, such as Adage, IBM, and IDI, have offered upgraded versions of earlier systems. Probably the
most widely used graphic terminals over the past five
years were the IBM 2250 Series units. Originally intro-
TERMINAL CONFIGURATIONS
Intelligent terminal
Five years ago, most terminals consisted of a display
generator (with digital logic and some analog function
generators) and a refreshed CRT. Only one system
used a storage tube (the BBN Teleputer System), and
only two systems included their own computers (DEC
439
440
Spring Joint Computer Conference, 1972
TABLE I -Graphics Terminal Manufacturers
Available Configurations Now & Then
Company
Adage
AEG-Telefunken (Germany)
Bunker-Ramo
Computek
Conograph
Control Data Corporation (CDC)
Data Disc
Digital Equipment Corporation
(DEC)
Evans & Sutherland
Ferranti Ltd
Fujitt:lu
Hazeltine
Honeywell
Imlac
Information Displays, Inc. (IDI)
Information International (III)
International Business Machines
(IBM)
International Computer (ICL)
International Tel & Tel (ITT)
Lundy
Marconi (England)
Monitor Systems
Philco-Ford
Princeton Electronics
Sanders Associates
SINTRA (France)
Standard Radio (Sweden)
Stromberg Carlson
Systems Engineering (SEL)
Systems Concepts
Tasker
Tektronix
Toshiba
Vector General
UNIVAC
Xerox Data Systems (XDS)
Supplier
-/2
-/2
-/2
-/2
-/2
7/2
-/2
7/2
-/2
7/2
-/2
-/2
-/2
-/2
7/2
7/2
7/2
-/2
7/2
-/2
-/2
-/2
7/-/2
7/2
-/2
-/2
7/7/2
-/2
7/2
-/2
-/2
-/2
7/2
7/2
In telligen t
Terminal
Storage
Tube
Low Cost
Graphic
-/2
-/2
-/2
Digital
TV
Scan-Conv.
TV
Unlimited Unlimited
Graphics
Graphics
Buffered Unbuffered
-/2
-/2
-/2
-/2
7/2
-/2
-/2
-/2
-/2
-/2
-/2
-/2
-/2
-/2
7/2
7/2
-/2
7/2
-/2
-/2
-/2
-/2
-/2
-/2
-/2
-/2
7/-
-/2
7/2
7/2
7/2
-/2
-/2
-/2
-/2
-/2
7/2
-/2
-/2
-/2
7/-
-/2
7/2
-/2
-/2
7/-
-/2
-/2
-/2
7/2
7/2
-/2
7/2
-/2
7/2
7/2
-/2
-/2
7/2
7/2
-/2
KEY
No product.
7/2+-Supplier in 1971/72.
L-Supplier in 1966/67.
-
and Bunker-Ramo). The other units used either nonprogrammable mass memories (such as core or drum) to
refresh the display, or were refreshed from the core of
the host computer.
In the past five years, the spectrum of configurations
has significantly increased. Because of the sharp break
in commercially available minicomputer prices, many
more intelligent terminals4 are now offered. A comment
from the 1966 Computer Display Review 5 emphasizes
the minicomputer price decline.
"In fact, the DEC 338 has a general-purpose PDP8 satellite computer which operates independently
of the display controller. While the DEC display
may seem expensive, the PDP-8 alone is worth
$18,000."
Versions of the PDP-8 are now available for less than
one-third of the 1966 price. Software supported intelli-
gent terminals (which include their own commercial
mini or midi OP computers) are now offered by Adage,
Computer Graphics Terminals
Bunker-Ramo, CDC, DEC, IDI, IBM, Sanders and
SEL. Conograph, Imlac and System Concepts furnish
software supported intelligent terminals which use
their own designed minicomputers.
Almost all other commercial graphic terminal suppliers are prepared to, or have interfaced their units to a
variety of mini or other large scale host computers.
The 1966 Computer Display Review 5 could comment
quite legitimately that:
"There are presently no generally accepted standards or methods for evaluating line-drawing equipment."
In an effort to remedy the situation, the Computer
Display Review developed a series of quantitative measures for refreshed displays, based on the manufacturers
data. Figure 1 shows the range of price and performance
for the displays included in the 1966 Review, compared
to the 1971 Review. Note that although the data content
characteristics have not changed significantly (the range
of flicker-free points, lines, characters and frames), the
minimum cost per function has in general been greatly
reduced.
Low cost graphics terminals
Storage tubes have introduced one of the major
changes in terminal configurations. Until about four
years ago, essentially all graphic terminals used refreshed CRT's, with tube sizes ranging from 16" round
to 23" round ... resulting in usable display areas of
about 10" X 10" up to about 14" X 14". After Tektronix introduced the Model 611 X-Y Storage Tube
Unit with a 6" X 8" usable area, several companies
including Computer Displays (now Adage), Computek,
Tektronix, DEC, and Conograph, began to market
r
0.9
10,000
MINIMUM POINT POSITION
100,000
USEe
_ _ _ ...J 3
1966
INCHES LONG LI
8
$/FLIC
*$4
R FRE
~
_
$1000
$10 000
$100 000
POINT
i % 6 - _ _ _ _ _ ...J $286
_
~
~n
$/INCH
INE 8" long)
$8 L..
1966 _ _ _ _ _
....J $220
P
~
$lINCH (2" LINl )
$41... _ _
:L%6- _
r- __
-oJ $234
$3
$253
1971
$/INCH' 1/2" LINE)
*$291.... _
_
1-
_ _ _ ....J $ 65
1966
V.fLIC
R FREE CHARACTER
r
$11L..
-1966- __
...I 92
'-+----,;;;-:;;---1---t--.J
$194
$/FRAME.J
va1rt SyremS
*j$l1' OOjO L..
*Lower rate 'Juoted in References (2), (5) for
non-equi
j
1966
*$3800«
~::.J00
$82,O?O
1971
t
Figure 1b-Cost per graphic function
interactive terminals based on the Model 611. These
storage tube terminals marked the beginning of low cost
CRT graphics ... originally introduced in the $12,000
to $15,000 range, the units are now selling for about
$8000. In late October 1971, Tektronix introduced a
limited graphic storage terminal selling for less than
$4000.
Within the past two years, several other low cost
terminals (under $10,000), using either refreshed displays or some form of TV (either scan conversion or
digital TV), have been introduced. Included are refresh
displays from Imlac and IDI, scan converter displays
from Princeton Electronics, and digital TV displays
from Data Disc.
Generally, these low cost units are available with
varying levels of software support.
Typically, the low cost graphics terminals involve
some compromise in terminal performance ... such as
small picture area, low contrast, restricted dynamic
motion, poorer picture quality (lower resolution and
some line drawing limitations), and no gray levels.
However, for many applications, these are acceptable
compromises.
II
300
I...
_
r-
-1966 _ .... _ _
...J
18,000
'----+_+-.....,......,--~-+' 11,110
INCHES/LINE
$1 0
$0
441
Long persistence phosphors
2"
INCHES SHORT L NE
1 2
II
I
I
1~5
300
I...
_
~966--oJ
1971
500
444
~
-
rr966 -
~
4000
551,
-
1.10
...J 60
13,333
I
Figure la-Flicker free graphic functions
In order to increase the flicker-free data content of
refreshed displays, many terminals now use longpersistence phosphor CRT's. Until about three years
ago, the only satisfactory long persistence phosphor was
the P7 ... a combination P19 phosphor for persistence
and P4 for fast response (in order to use a light pen).
This phosphor couples reasonable burn resistance with
satisfactory performance in the 30 frame per second refresh range.
442
Spring Joint Computer Conference, 1972
TABLE II-3-D Picture Manipulation
Software vs. Hardware Comparison
(Adapted from Reference 30)
SOFTWARE
ITEM
1. Number of lines which can be rotated
flicker-free.
HARDWARE
ANALOG
Independent of rotation method. Depends only
upon display techniques.
DIGITAL
May bef unction of picture composition if average line drawing
time less than matrix multiply
time. Line content then determined by matrix mUltiply time.
2. Time to calculate constant data. Assumes
approximately 600 machine cycles per
calculation.
Independent of rotation method. Approximately 0.5 millisecond per new angular position.
3. Time to calculate rotated point (line).
(For Software, assumes approximately
170 machine cycles per calculation.)
130 USEC
1-6 USEC, due to transformation array settling time.
4. Resident program size.
Approx. 650 decimal
words
Approximately 300 decimal words.
2.3W
5. Display list buffer size (including 3D and
2D display files), where W is number of
words required to store 3D display file.
5-10 USEC
W
W
6. Number of lines that can be smoothly
dynamically rotated (without apparent
jump from frame to frame).
a. Maximum rate (180° /sec) beyond
which eye gives "strobe" effect at 30
cps refresh, P31 phosphor.
b. At 1°/second
c. At 2° /second
d. At 4° /second
250 lines
Limited by vector drawing time: number of vectors drawn
@ 30 f/s.
2000 lines
1000 lines
500 lines
7. Perspective
Yes, incl. in routines
No, can be simulated by
Z dependent intensity
modulation for depth
cueing
Yes
8. Hidden Line
Yes, special cases processed in real-time.
No, requires software.
No, requires software.
9. Delta cost (approximate)
$5000
Assumes additional 4K
memory increment
required. (3D program
650 words; 2D display
File #1 1675 words;
2D display File #2
1675 words.) However this increment
can be used in other
programs as well.
$15,000
$40,000
$70,000
----
/
Computer Graphics Terminals
443
TABLE III-Cost per Console Hour
(From Reference 7)
TYPE
I Non-graphic teletype
II Non-graphic refresher CRT
III Graphic Storage Tube
IV Graphic Storage Tube
V Graphic Refresher CRT
CAPABILITY
alphanumerics
only
alphanumerics
only
alphanumerics
and vector
generation
alphanumerics
& vector I/O
alphanumerics
& v:ector I/O
Recently, doped P39 phosphors, and the Ferranti L4
phosphor, have offered the same burn resistance with
acceptable performance in the 16-25 frame per second
refresh range.
Hardware function generators
Hardware vs. software trade-offs were continuously
modified over the past five years. Most early systems
included hardware line and character generation, some
included circle generators, but picture manipulation and
curve generation were done in software.
While this is still the predominant situation, some
terminals including those manufactured by Adage,
Conograph, Evans & Sutherland, Lundy, Sanders, and
Vector General, offer 2-D and 3-D rotation hardware.
Others, including those offered by Conograph, Lundy,
and Sanders, offer some form of arbitrary curve generation hardware. Like most trade-offs, choosing hardware
vs. software for these functions involve a clear understanding of the application in order to decide if the additional cost is warranted. Factors involved in such a
trade-off study are illustrated in Table II.
Operator input devices
Over the past five years, the light pen and keyboard
have persisted as the predominant operator input devices for graphic terminals. Joysticks and trackballs are
used occasionally, and there has been continuing, although not large, interest in the SRI MOUSE.6
Rapidly assuming a major role as an operator input
device is the Graphic Tablet. Until the advent of the
storage tube display, the Graphic Tablet was viewed
simply as direct competition to the light pen. Early ver-
INPUT
OUTPUT
EXAMPLE
COST PER
HOUR
keyboard
keyboard
ASR33
$10
keyboard
display
IBM 2260
$15
keyboard
display
$20
keyboard
& tablet
display
keyboard, light
pen, & function
buttons
display
ARDS and
Computek
without tablet
ARDS and
Computek
with tablet
IBM 2250
CDC 274
$30
$80 to $150
sions, such as the Rand Tablet (supplied by BBN),
were relatively expensive, (about $10,000 to $15,000),
but there evolved a number of devoted users. Sylvania
entered the market with an analog version, the price
level came down somewhat (about $7000), but the lower
priced light pen (about $1500) continued to dominate.
However, the light pen could not be used with storage
tube systems, and much attention became directed to
the development of a lower cost graphic tablet. Cur~
rently, at least two, under $3000, units are available;
one from Science Accessories (the Graf Pen, using an
acoustic principle) and the other from Computek (using
a resistance technique). Undoubtedly others will be
marketed.
Color displays
Five years ago, color displays could be most readily
obtained with TV techniques, using the commercial,
color mask tube. Although there were some isolated usage of the color mask tube in random (non-TV) systems,
the systems were costly, and relatively difficult to keep
satisfactorily aligned. TV was not widely used for
Computer Graphics.
Several years ago, a new color tube, the Penetron, was
introduced by several tube manufacturers, including
Thomas, Sylvania and GE. The Penetron uses a dual
phosphor, and color changes (over the range from red,
through orange, to green) are obtained by switching
the anode potential, usually over a range from 6000 to
12,000 volts. Switching times are currently in the order
of 150 USEC/color, and the tube seems best used in a
non-synchronous field sequential mode. Penetron systems offer essentially the same resolution as convention
monochromatic random positioned systems (as com-
444
Spring Joint Computer Conference, 1972
pared to the lower resolution of commercial TV). At
least one manufacturer (IDI) now offers the Penetron
as an optional output display for both its low cost terminal (IDIgraf) and its higher cost intelligent terminal
(IDIIOM), at a cost premium of about $8000 per
display.
Deflection systems
Five years ago, most displays were magnetically deflected. In the terminals featuring fast hardware character generation (in the order of 10 USEC/character, or
faster), the display usually included a second high speed
deflection channel, either magnetic or electrostatic.
Currently, however, because of better deflection yoke
design and improved transistor drivers, newer terminals,
such as those supplied by IDI and Sanders, feature a
single, wide bandwidth, magnetic deflection channel,
capable of full screen deflection in 10 USEC, and capable
of responding to characters written in about 3 USEC.
Improved tube and transistor design have also revived interest in electrostatically deflected displays.
Storage tube systems use electrostatic deflection, but
because of storage requirements, the writing speeds are
relatively low. However, a new series of electrostatic,
solid state, X-Y displays offered by Hewlett-Packard,
feature fast deflection (1 USEC full screen), wide video
bandwidth (5 MHz), good spot size (20 MIL), relatively
large screen (up to 19-" rectangular), and low price
(about $3000).
A terminal manufacturer can now also buy "off-theshelf" magnetically deflected X-Y displays from suppliers such as Kratos and Optomation. Five years ago,
Fairchild and ITT offered similar units, but they no
longer market a commercial product.
APPLICATIONS
Five years ago, commercial usage of graphic terminals
was limited almost exclusively to Computer Aided Design and Simulation. lVlany other applications were being investigated, but each investigator was essentially
a pioneer. Except for the software supplied by a computer manufacturer to support his terminal (such as
CDC and IBM), each user had to "start from scratch."
Today, the situation is considerably improved (although there is much more that can be done). Most
intelligent terminal suppliers furnish some graphic software, including graphic subroutines, operating systems
and higher level languages. Some offer complete application packages for free-standing versions of their systems
(such as the IDI Automatic Drafting System, IDADS).
Others (such as CDC and IDI) offer emulator packages
that permit their terminals to appear like the IB:\f
Series 22.50 displays, and hence are capable of utilizing
IBl\1:, or IB::\1 user, developed software. A number of
systems organizations, such as Applicon and Computer
Vision, also offer turnkey graphic terminal-based systems. These systems permit the user to use computer
graphics for making PC boards and IC masks, without
any further software investment. In fact, it appears now
that most IC manufacturers are using terminal-based
computer graphics.
Computer-Aided Design (CAD) remains a major application area, although reported usage is still concentrated in the Aerospace and Automotive industries.
However, there appears to be increasing use in Architecture, Shipbuilding, and Civil Engineering.
Over the past five years, the use of graphic terminals
in Utility Control has been accelerating. I estimate that
about 10 percent of all investor owned utilities are now
using or are planning to install graphic terminals for
this purpose.
Enough commercial experience has been gained over
the past few years to allow meaningful cost justifications
to be prepared. The results of one survey giving console
costs per hour billed to users for various types of consoles7 are given in Table III. Five years ago, much
justification for computer graphics was based on faith!
PUBLICATIONS, COURSES AND SElVlINARS
Certainly, one measure of growth (or at least interest)
in a field is the amount published, or the number of related discussions. In the past five years, several engineering level display and computer graphics texts, relating to computer displays, have been published8,9,10,11 and
numerous national and international meetings have
been held. References 12-16 list several representative
meetings. Several universities, including the University
of California, the University of Michigan, Stanford, the
University of Wisconsin, and Brooklyn Polytechnic,
have sponsored short courses oriented to displays and
computer graphics. ACM organized a special interest
group for graphics (SIGGRAPH), and the Society for
Information Display continues to flourish. Annual or
periodic graphic terminal equipment surveys have become common like those published by Keydata * Corporation,2,5 Modern Data Systems,3 Auerbach Corporation,17 Data Product News,18 Computer Design,19 and
Computer Decisions. 20 Even the American lVIanagement
Association,21 the Harvard Business Review,22 Scientific
American,23 Newsweek,24 and the Jewish Museum25 have
* In late 1971, Keydata Corporation sold its publishing business
to GML Corporation.
Computer Graphics Terminals
taken note of computer graphics. Computer graphics
terminals were featured on several national TV shows,
like the David Frost Show and San Francisco Airport.
A few of the Seminars were concerned with "breast
beating". It became increasingly popular in 1969 and
1970 to ask the question, "Why hasn't computer graphics lived up to its initial promise ... a terminal in every
home and office?"26,27 Early predictions of a $200,000,000
market by 197028 were not being fulfilled. As a participant in many of these sessions, I felt that the question
was being "begged". Some of the applications predicted for graphic terminals were being effectively
handled by A/N CRT terminals (of which there are
now estimated to be some 75,000 units installed).
The growth in other applications depended on a consolidation and analysis of results from the previous
year's efforts. Still others couldn't be exploited until
appropriate software, or less expensive hardware became available. And, 1970 was a miserable business
year, anyway!
During these sessions, my position was, and continues
to be, that although some early predictions were overly
optimistic, conditions now exist for attractive growth.
A number of market surveys, and projections have
been published in the last five years ... but the future is
the province of another speaker in this session. Some review of the past five years might provide a useful bridge,
however. For commercial applications, the consensus is
that there are currently about 1200 high cost graphic
terminals and about 700 low cost graphic terminals
installed. 29 Five years ago, there were probably (my
guesstimate) about 300 high cost graphic terminals
installed. There were no low cost graphic terminals.
445
market and withdrew the product. All was not lost,
however, because they were able to sell the software
package to Tektronix.
Ported CRT's seemed to be a promising techn'que
five years ago. However, the added cost and complexity
limited the use to selected military applications, and
there is little current commercial interest in the configuration.
1VIany practitioners expected (or at least hoped) that
there would be a universal higher level graphics language by now ... but that didn't quite make it, either!
SUMMARY
It was an exciting five years!
New suppliers, new products, and new applications
surfaced during this period. Because of lower cost
terminals and turnkey software/hardware systems, the
use of graphic terminals began to spread beyond the
Fortune 500 ... beyond the Aerospace and Automotive
Industries.
Generally, terminal performance was maintained,
while prices were lowered. This was a reasonable trend
since most applications were not hardware limited.
Of necessity, a survey paper like this tends to be
superficial. For every example cited, several more may
exist. But the purpose has been to give the sense of
movement over the past five years, perhaps at the expense of some detail.
Usually, this kind of paper ends with a forecast ... a
prediction of things to come. Fortunately (since predictions have a habit of coming back to haunt), the
seer's mantle has been placed firmly on another speaker's shoulders!
WHAT DIDN'T QUITE MAKE IT
As shown in Table I, almost all suppliers from five
years ago are still offering commercial equipment. Several products and concepts which seemed promising
during the period didn't quite make it though. For example, abo\lt four years ago, a British company,
Graphic Displays Ltd, had an interesting idea for a low
cost graphic terminal. The ETOM 2000 coupled an inexpensive drum memory to a long persistent phosphor
display. Operator input was achieved with an X-Y
mechanical table arrangement. Apparently technical
problems and limited customer acceptance scuttled the
project.
Corning Data Systems exploited a photochromic
storage technique in their Corning 904 terminal. For
about $20,000, the customer was offered a storage display with hard copy output, and extensive software
support. But Corning couldn't find a large enough
REFERENCES
1 C MACHOVER
Graphic CRT terminals-Characteristics of commercially
available equipment
AFIPS CONFERENCE PROCEEDINGS Vol 31 1967
Fall Joint Computer Conference Thompson Book Company
Washington D C
2 Computer Display Review, 1971
Keydata Corporation 108 Water Street Watertown
Massachusetts
3 Interactive CRT terminals, Part 1-full graphic CRT terminals
& systems
Modern Data June 1971 pp 44-55
4 C MACHOVER
The intelligent terminal
Paper presented at the University of Illinois "Pertinent
Concepts in Computer Graphics" Conference 30 March-2
April 1969
5 Computer Display Review, 1966
Adams Associates Inc Bedford Massachusetts p V.214.0
446
Spring Joint Computer Conference, 1972
6 C MACHOVER
Computer graphics in the United States
Computer Graphics Techniques & Applications Plenum
Press New York NY 1969 pp 61-83
7 T J MOFFETT
The economics of computer graphics Part IV, cost effectiveness
Lecture notes from "Computer Graphics for Designers"
University of Michigan Engineering Summer Conferences
July 12-23 1971
8 H R LUXENBERG R M KUEHN
Display system engineering
McGraw-Hill New York NY 1968
9 S DAVIS
Computer data displays
Prentice-Hall Englewood Cliffs NJ 1969
10 S SHERR
Fundamentals of display system design
Wiley-Inter science New York NY 1970
11 M D PRINCE
Interactive graphics for computer-aided design
Addison-Wesley Publishing Company Reading
Massachusetts 1971
12 Computer Graphics '68 Seminar
BruneI University Uxbridge England July 1968
13 Computer Graphics '70 Seminar
BruneI U niversi ty Uxbridge England April 1970
14 Recent advances in display media
National Aeronautics & Space Administration, Washington
DC A Symposium held in Cambridge Massachusetts
19-20 September 1967 Publication NASA SP-159
15 Pertinent concepts in computer graphics
Conference University of Illinois 30 March-2 April 1969
16 DoD / Industry symposium on computer-aided design and
computer-aided manufacturing/numerical control
Rock Island Army Arsenal Davenport Iowa 14-17 October
1969
17 Auerbach graphic processing reports
Auerbach Info Inc Philadelphia Penna 1969
18 M MANDELL
A buying guide to visual display/CRT terminals
Data Product News October 1970 pp 1-7
19 J E BRYDEN
Visual displays for computers
Computer Design October 1971
20 Graphic terminals-Man' s window to interactive graphics
Computer Decisions November 1971
21 Computer-aided design engineering: the new technology for
profit potentials in the seventies
Session # 6311-60 American Management Assoc New York
NY 5-7 October 1970
22 I M MILLER
Computer graphics for decision making
Harvard Business Review November-December 1969
pp 121-132
23 I E SUTHERLAND
Computer displays
Scientific American June 1970
24 The artist and the computer
Newsweek September 13 1971 pp 78-81
25 Software Show
The Jewish Museum New York NY 16 September-8
November 1970
26 Interactive graphics ... where is the market?
Proceedings of Symposium Boston Mass 13 May 1969
Keydata Corporation Watertown Mass
27 Interactive computer displays
Data Systems News August-September 1970
28 D E WEISBERG
Computer-controlled graphical display: its applications and
market
Computers & Automation May 1964 pp 29-31
29 High growth plotted for computer graphics
April 1971 pp 3-8 Samson Technology Trends Samson
Science Corporation 245 Park Avenue New York NY
30 B WALDER C MACHOVER
Why ware . .. hardware vs. software rotation
Unpublished notes 29 October 1971
The future of computer graphics
by THOMAS G. HAGAN and ROBERT H. STOTZ
Adage Inc.
Boston, Massachusetts
point has just been reached for computer-aided engineering design (except for exotic cases which have been
economic for several years) and for some forms of
drafting. In the future lie still broader drafting applications, publishing industry applications for editing and
page layout, architectural design, routine use for film
and video tape animation and editing, management
information systems, hospital information systems, and
computer-aided instruction. We shall discuss each of
these applications areas in turn, but first let us examine
the technological prospects for computer graphics: the
display hardware itself and the computer systems
technology behind it.
Predicting the future is a hazardous enterpriseespecially in high technology where seers tend to be too
optimistic in the short run (3-5 years) and overcautious in the long run (10-20 years). In computer
graphics, the forecasts started about 10 years ago,
and so far almost all seem to have been too optimistic.
But the pace now quickens, and the next 10 years'
developments may at last outstrip the visions of 10
years ago. At least, so it seems now to us, and so we join
the optimists, even though to date they've all been
wrong.
The optimists (i.e., almost everyone in the field)
have been disappointed because they failed to recognize
at the outset the level of completeness necessary in a
graphics system to do a useful job. They consequently
either tried to work with incomplete systems, producing
negligible results, or, in achieving completeness,
encountered higher than expected costs for both
development and subsequent production use. The
realists, on the other hand, knew that achievement of
successful on-line graphics applications would at first
be a slow and costly process, and planned accordingly.
They concentrated on applications areas where the high
initial costs could be justified, and where the available
hardware and software technology was sufficient for the
job. They have achieved some significant successes.
Based upon those achievements, we believe that
computer graphics is entering a new phase which will
be characterized by rapid growth.
We can summarize our conclusions for the future by
saying that the technical feasibility of graphics applications has now been demonstrated in many areas,
that economic feasibility has been established in a few
areas, that costs will come down by a factor of 10 in
10 years, and that graphics systems will therefore
proliferate, first in areas where the economics are
already favorable, then into new ones as they become so.
Areas where growth can be expected on the basis of
already proven economics includ.e situation display,
data analysis, and simulation. The economic turning
DISPLAY HARDWARE TECHNOLOGY
Only five years ago, the random-access refreshed
CRT was the only serious graphic display technology.
Today, we have a plethora of new techniques. Interestingly, all of this new technology has been directed
toward the image storage approach to graphic display.
That is, the picture is stored in its two-dimensional form
or in some one-to-one map of that form (e.g., video
disk). Therefore, one cannot meaningfully discuss
display technique without including the memory for
retaining images.
In the next 10 years, it is reasonable to expect the
bistable direct view storage tube (DVST), the video
scan converter tube and the video disk each to mature
and to find particular application in areas where its
advantages will be realized. A long life for each approach
can be expected, although, particularly for the DVST,
new hardware will probably succeed present equipment.
One new direct view storage technique is the plasma
panel, which appears to be nearing commercial application. The plasma panel performs functionally like the
bistable DVST; that is, it retains images for direct view
once it has been written. But it has some interesting
advantages. It is fundamentally flat and reasonably
447
448
Spring Joint Computer Conference, 1972
transparent, which makes rear projection of static data
easy. It should be more rugged than a CRT and it is
digitally addressed, thereby eliminating all analog
circuitry. But its most interesting feature may be its
price. The cost of this panel has been projected by
authoritative sources to be as low as a few hundred
dollars for a panel with drivers. At any price below
$1000, the plasma panel will certainly be a popular
device.
Several other DVST techniques have been introduced, but we do not foresee major impact from any
of them. Photo chromic storage systems are slow and too
expensive and, in fact, the one commercial entry utilizing
a photochromic system has been withdrawn from the
market. The cathodochromic direct view storage tube
is viewed by reflected light, which is an advantage in a
high ambient light environment. However, its slow
erase property will limit its utility.
The random-access CRT does not have much competition today where dynamic performance is required.
There will be a shift toward raster displays, however,
possibly for even the most dynamic pictures. The
flexibility of TV video format for remote transmission,
large screen display, and image mixing, particularly
with non-computer generated pictures, argues for this,
as does system cost. In the past, the scan conversion
cost was prohibitive, but as digital logic cost drops
further and its speed improves, the cost will become
more competitive.
The move toward video format will encourage the
work being done on display of solid figures. However,
applications for solid figure display (limited more by
computer systems technology than display hardware)
will probably continue to be limited, even in 10 years.
Quite likely, too, by the early 1980's, several new
display techniques will be with us that we are not even
aware of today. It is hard to project the impact of
currently unknown techniques, but, as has been the
case in the past five years, they will probably be directed
more at cost reduction than at performance improvement. In fact, in the next decade, it may be that all the
significant technological developments in display devices
will result in cost reduction rather than in performance
improvement.
COMPUTER SYSTEMS TECHNOLOGY
The factor that has limited the utility, and therefore
the market growth, of interactive computer graphics
systems has not been the display hardware technology
(CRT's have worked fine for years) but the computer
systems technology behind the display. By this we
refer to the whole system for providing enough on-line
processing power, sufficiently responsive, with enough
memory to be effective, with adequate programming
support, and with communications adequate to get the
data to the user at the necessary speed, all at a low
enough cost.
Interactive graphics systems are by definition conversational. In order to be truly interactive, they must
provide responses within a few seconds for many or
most of the actions taken by the user at the console.
Cost for graphics systems has always seemed high to
users, and attention has often been focused on the cost
of the display terminal itself as an obvious target for
reduction. But compared to keyboard-only conversational systems, conversational graphics entails manipulation of relatively large data files, with consequently
much longer messages between terminal and mass
memory. Concentration on cost of the display device
often has led to overlooking the cost of the processor
hardware and the mass memory necessary to support
the terminal device with the levels of performance
needed for a conversational graphics environment. In
the past, some systems disappointed users because of
the large amount of core memory needed in the system
to support each terminal, or the high cost of the communications facilities necessary to provide the link to
the CRT, or the lack of enough fast mass memory to
support a reasonably complete application. Proliferation of graphics systems, therefore, depends not only
upon reducing cost of the display itself, but also upon
reducing the cost of the processor hardware and the
mass memory needed to support the display. Numerous
users have concluded that each graphics console requires
in the range of 10 million to one hundred million bits of
mass memory with access time well below 1 second.
Communications costs are significant whenever this
mass memory and the processing hard ware are remote
from the console. Even though present digital communications costs are expected to be reduced dramatically, we believe that many or most graphics systems
will incorporate local processing power, and some form
of local mass memory. The communications burden
then reduces to one of occasionally shifting data from
individual consoles or clusters of consoles through
communications lines to a central repository accessible
to many users.
The need for sufficient processing power, core
memory, and mass memory behind the tube is the
reason that useful interactive graphics systems today
cost $100,000, and up, per console. We believe that 10
years will see a 10: 1 reduction in these costs, permitting
complete, useful systems with the equivalent of today's
functional performance for $10,000. Cost per console
hour will therefore drop from today's $25.00 to $50.00
range to about $2.50, permitting significant growth of
Future of Computer Graphics
current applications, and penetration of computer
graphics techniques into many areas currently untouchable. Here are our thoughts on prospects for a
number of different present and future applications.
APPLICATIONS
Many people assume that Interactive Graphics =
Computer Aided Design (CAD). It is true that CAD is
an important applications area for computer graphics
and the one that most easily captures the imagination,
but there are many other application areas, including
some that have achieved a higher degree of maturity
(i.e., proven economic effectiveness) than CAD. We
shall discuss a series of application areas in turn, roughly
in the order of their currently demonstrated effectiveness. (We are specificallY not discussing them in the
order of present or potential market sizes, which cover a
wide range, although clearly areas where economic
effectiveness is established soonest generally achieve
earliest penetration of the available potential market.)
Situation display
About $100 million has already been committed by
the FAA for computer graphics systems for air traffic
control situation displays. The next 10 years should see
computer graphics firmly established for real-time
situation displays in many areas. Other forms of
traffic will be brought under control of systems which
will include computer graphics for overall situation
display: rail, transit, harbors, shipping lanes. Computers will be inserted between the antennae and
CRT's of almost all radar systems, converting them
into computer graphics systems capable of much more
comprehensive situation display than current "simple"
radars. Thus, specialized computer graphics systems
will eventually be found aboard all airliners and all
ships as part of the navigation and piloting systems-if
not by 1982, then by 2001, just as we were informed by
Stanley Kubrick's film.
The few computer graphics systems now installed for
monitoring and control of chemical processes and
utility distribution systems presage what we believe
will be widespread use of computer graphics for situation display in these areas, possibly replacing completely the walls full of panel meters and recorders that
have come to typify the industrial process control room.
As discrete manufacturing operations become more
automatic, situation displays will begin to be used for
monitoring material flow and inventory levels. In other
words, for supervisory control, somewhat analogous to
449
that practiced in continuous flow chemical manufacturing processes.
Computer graphics systems are already being used as
situation displays for monitoring tests and experiments
conducted with the use of expensive test facilities, and
frequently for assisting with control of the facility.
Aircraft flight test, wind tunnel test, and Van de
Graaf generator experiments are all today being conducted with computer graphics systems used for realtime display and control. Achievement of even a small
increment of increased utilization (or enhanced safety)
of a very expensive test facility can justify a computer
graphics situation display system at today's costs. As
costs come down, such display systems will proliferate,
finding use in conjunction with larger numbers of
gradually less expensive test facilities.
Data analysis
Any operation involving the collection of large
quantities of data for subsequent human interpretation
constitutes a potential application area for computer
graphics. Today's successful applications (in the
military, electronic intelligence data analysis; in
industry, oil exploration data analysis) can be expected
to continue growing and should lead to applications in
similar areas: semi-automatic map-making (photogrammetry) , weather data reporting and forecasting,
and other forms of mineralogical survey data analysis
besides oil exploration. Increased use of automatic
sensors to collect data should lead to increased use of
computer graphics as an aid to analysis of that data. In
addition, some data sets built up by keyboard source
data entry (census data, for example) have become
large enough to be candidates for analysis via computer
graphics.
Simulation
This is an area that has used computers in an on-line,
interactive mode right from the start, and usually with
some form of graphic output-strip charts or X-Y
plots. Analog computers were used almost exclusively
at first, then hybrids took over, and now much simulation is done on purely digital machines. Simulation
models have grown more and more complex so that
systems behavior can be studied in toto rather than
piecemeal. Flexible dynamic display has become more
and more necessary, either to achieve "picture-outthe-window" verisimilitude in the case of vehicular
simulations, or to achieve an over-all "situation display"
for the simulation model-with the same general
I
450
Spring Joint Computer Conference, 1972
requirements (plus flexibility) required for the "real
world" situation displays discussed above.
To date, engineering simulation has been highly
mathematical and quantitative, even where the object
was to get the "feel" of sensitivity to parameter
variations. The display flexibility of computer graphics
will permit a more qualitative kind of simulation, still
based upon an underlying mathematical model, but
where there is less a "numerical" and more a "graphical"
sense of the model. In short, simulation will be used for
what we think of as styling as well as for what we think
of as engineering design. The distinction between the
two, already blurred, may gradually disappear. In the
future, dynamic aspects will be "styled," as static
aspects now are.
Computer aided design
Meanwhile, there is CAD. After a long slow start,
great strides are being made and numerous on-line
applications are felt by their users to be cost-effective
today. However, the dream of an integrated design
system which takes a large design task from concept to
final production drawing (or microfilm or magnetic
tape) will be realized in only a few areas even in 10
years. Clearly one such area is the layout and design of
electronic circuits. In 10 years, virtually all circuits will
be designed with the aid of the computer. Circuit and
logic designs will be synthesized and tested by computer, and test specifications for completed circuits will
be an automatic by-product. Almost all of this kind of
design work will be done with on-line interaction via
graphic terminals.
One consequence, in this and other areas, will be a
change in the economics of short-run production. By
cutting design costs, CAD will make the production of
"custom" circuits more practical. *
Interactive graphics are being used successfully today
in several dozen places for performing various kinds of
engineering analyses that form a part of the design
process. Success has come quickest where a pre-existing
and already proven applications package developed for
batch operation has been adapted to be made available
* Similarly, wherever the high cost of processing information
"by hand," for either the design or the manufacturing portion of
the production process, has resulted in a large cost differential
between "custom" and "mass" production, CAD, with computer
graphics playing a significant role, may redress the balance, and
much of our industrial output may return to the "one-of-a-kind"
production typical of pre-industrial times. If so, computers will
have (in this respect at least) an effect upon the quality of our
lives quite opposite from that expected by those who see them
only as a threatening source of increased standardization and
regimentation.
on a conversational basis via interactive graphics. The
usual main result is a dramatic shortening of the cycle
time for the part of the design job converted to
graphics-a job involving many iterations that used to
take six weeks under batch being finished in one twohour console session, etc. There is also often the feeling
(hard to prove) that a better design job was done. The
high cost of graphics systems and applications programming today restricts these applications to a few
critical points in the design process. As costs come down
and confidence increases, use is spreading to less critical
design jobs: from today's computation-intensive jobs
(stress analysis, heat flow, vibration analysis) to
geometry-intensive jobs (complex layouts, clearance
analysis, pipe routing, numerically-controlled machine
tool tape generation and verification) and finally to
drafting/ clerical intensive jobs (detailed drafting) .
Some forms of detailed drafting are already costeffective using computer graphics, in particular the
preparation, editing, revision and file maintenance for
drawings made up from a set of standard symbols.
(Circuit diagram, logic diagrams, flow charts, block
diagrams, etc. ) Especially where revision is frequent
and fast turn-around is important, as in the preparation
and revision of system maintenance drawings, computer
graphics is now ready to compete with traditional
drafting and technical illustration methods.
The design function is a social activity. Design tasks
are usually undertaken by groups of people, with the
overall design job in one way or another divided
among members of the group. It is easy to think of
CAD as a means for helping an individual designer with
his task, and to overlook the implications of CAD with
regard to communications within the design group. In
thinking about the long run, it is important to visualize
teams of designers using on-line interactive devices to
communicate with a data base containing both the
design constraints they are working with (specifications,
costs, catalogs of available parts) and the results to
date of their joint effort. Much of their communication
with one another will be via the design itself as it exists
in storage. What will happen when (and if) 10, 100, 1000
d~signers are interconnected on line? The airlines
reservations systems constitute the closest current
model to such a situation-and the detailed total
reservation schedules the thousands of clerks at CRT
terminals are constantly building up is a kind of
"design"-but the constraints they work with are few
and fairly simple.
Architecture
We think the introduction of computer graphics here
will be relatively slow because of the diffuse nature of
Future of Computer Graphics
the business structure, with many small independent
firms, most without the resources for investment in
hardware and development of software. City and
regional planning may be an exception if government
money is used to fund the necessary development.
Emphasis upon the creation of presentation drawings is
misplaced. The cost of renderings and models for client
presentations represents a small part of the total
architectural cost, the bulk consisting, as in other
design activities, of the creation of working drawings.
Therefore architecture may benefit mostly from progress made elsewhere with generalized drafting: the
creation of dimensional drawings with materials lists.
Publishing
Computer graphics has promise as a publishing tool,
and we expect substantial progress in this area in the
next 10 years. Preparation and editing of text and
graphics source material, and page layout, are the
functions that graphics systems can help with. Automatic typesetting has gone as far as it can go without
the front end of the publishing process being automated.
Cost reduction and shortening of the cycle time are
again the primary benefits. By 1982, it will no longer be
necessary to submit SJCC papers "in final form suitable
for printing" seven months prior to publication of the
Proceedings, as it now is. But, in order for graphics to
see widespread use for this function, it is clear that
console time must first get most of the way down to
that $2.50 per hour.
Film and video tape production
There is an obvious role for computer graphics for
producing and editing visuals (as they are called in the
trade) for television and motion pictures. Entertainment programs, commercials and educational programs
have all been produced on a limited but already commercial scale. The first full length feature movie shot
and edited solely on video tape, then transferred to
standard 35 mm color film, has been produced and
distributed. We expect to see increased use of computer
graphics as combined animation stand and editing
console, both for creating "computer generated pictures"-i.e., computer animation-and also for editing
live-action film or VTR footage.
Computer aided instruction
The current high-priced applications such as trainers
for airplane pilots and astronauts are of course already
economic, but nprmal classroom use of computer
graphics as a standard teaching tool, which is what
most peopl~ mean when they talk about CAl, clearly
451
requires system costs in the range of $2.50 per hour and
down, and therefore we do not believe that the next 10
years will see massive proliferation. On the other hand,
small computer graphics systems will become standard
lecture/demonstration tools in many areas of education,
both for "live" use and for creating simple low- or nobudget teaching films or tapes-i.e., canning lectures.
Management information systems
Of course every organization has some kind of
management information system-partly verbal, partly
a manual paper system, and in most large organizations
these days, at least partly computerized. But the
computer part is batch, not on-line, so it isn't what
people mean who talk about MIS. So far it's been mostly
talk, with not much in the way of results. Maybe
because on-line MIS isn't needed-top management
really doesn't care what goes on minute by minute, and
counts itself lucky to get reliable reports weekly or
monthly. But down in the infra-structure, there is a
need to know minute by minute about material location,
tool availability, stockroom levels, etc. If on-line computer systems begin to get applied for these functions,
then MIS as commonly envisioned will be a by-product,
and computer graphics will be a popular tool for
analyzing the data contained in such systems.
Hospital information systems
Many people seem to believe that Hospital Information Systems, as distinct from other types of computerized management information systems, are needed,
feasible, and about to happen. If so, there will be a role
for graphics, since so much patient care data are graphical in nature. The need will be for low cost inquiry
stations capable of displaying static charts, graphs, and
possibly even line drawings abstracted from X-rays.
These would be terminals connected into an overall
integrated information system primarily concerned with
record keeping.
On the other hand, there will be another use for
computer graphics in the form of higher cost, more
dynamic systems used for patient monitoring in operating rooms and intensive care wards. Use of these
systems will not depend upon creation of an integrated
HIS.
CONCLUSIONS
In interactive computer graphics, we are at the end of
the beginning. About $50 million has been invested to
452
Spring Joint Computer Conference, 1972
develop the products now on the market. Users and
government sponsors have invested an additional $20
to $40 million in software development to tell us what
we now know can and can't be done working in front of
a CRT. In keeping with the New Accounting, almost all
of these development costs have been written off as
losses by the various organizations that have made
investments to get started in graphics. Now computer
graphics has entered a new phase. Most of the systems
currently installed (about $100 million worth of hardware, by our estimate) were ordered as interesting but
risky and somewhat daring experiments-many of
which failed; but in the last year, graphics systems
began to be ordered to do specific jobs, \vith reasonable
certainty that they would be effective in those jobs.
Thus we believe that an important corner has been
turned.
Two ingredients are necessary for the field of computer graphics to experience grmvth-the availability of
systems complete enough in hardware and software to
do a variety of useful jobs, and a pattern of decreasing
costs to end users. Both of these ingredients are now
present, and we therefore believe that the period of
significant growth for computer graphics, long anticipated, has now begun, and will be sustained throughout
the coming decade.
A versatile computer drivell display system for the
classroom
by J. W. WILLHIDE
Boston University
Boston, Massachusetts
INTRODUCTION
allows the user to animate, in real-time, iconic representations of physical systems in a highly interactive
environment. The user can change parameters and immediately observe the effect of the change on a CRT
display. In addition to its real-time dynamic graphics
capabilities, the system also makes use of the more
conventional static information transmittal modes such
as alphanumeric text, graphs and symbolic diagrams.
The AID System is structured around a PDP-9/
AD-40 hybrid computer. The AD-40 analog computer
is used to simulate the system under study or serve as
a signal processor for experimentally derived data.
Animation is produced by dynamically manipulating a
set of geometric figures generated on the PDP-9 digital
computer as functions of the time-varying signals
sampled from the analog computer. These animation
sequences can be accompanied by graphs which unfold
in time synchronism with the animation. For cases
where animation does not make sense, graphs of selected simulation variables can be displayed.
A high-level language, the AID Language, is under
development to support the system. This language can
be easily learned by a highly motivated sophomore
engineering student. It is not intended, however, for
the professional animator or casual user of the system,
since some background in analog and digital computation is assumed. A film illustrating some of the attributes of the AID System and produced on the system
itself using the AID Language will be shown.
The last two decades have seen education in the
sciences, mathematics and engineering move from a
practical base to the teaching of highly sophisticated
abstract principles. The changes have been rapid and
radical. Generally, they have affected subject matter
only and for the most part this new material is being
taught by traditional methods. The changes in subject
matter are proper, but they must be accompanied by
changes in pedagogy. The use of display-based, highly
interactive computer simulations represents one approach toward building the required new pedagogy.
The educational system in this country is almost
totally classroom based-one teacher interacting with a
class of students on a regularly scheduled basis. This
unanimity of approach implies that most administrators feel this is the most cost-effective approach to
teaching available today that lies within their financial
resources. In a similar fashion, one of the most costeffective ways to implement a model-oriented pedagogy
today is through the use of a computer-driven display
system in the classroom. Other approaches to a modeloriented pedagogy such as individual student terminals
supported by a CAl (Computer-Aided Instruction)
system may at some point in the future challenge the
classroom system on a cost-effective basis. However, it
will be some time until such an approach will become
the rule rather than the exception. One must bear in
mind that even if CAl systems offered a cost-effective
advantage over the classroom system today, many
schools could not afford such a system because of the
large initial investment and relatively long pay-back
period.
At Boston University, the College of Engineering has
implemented a versatile computer-driven classroom
display system known as the AID System. The AID
System is unique in its emphasis on real-time dynamic
graphics, i.e., computer generated animation. AID
ROLE OF THE SYSTEM
The system serves a dual role in the classroom. First,
it can be used to assist the student in grasping difficult
concepts through the use of iconic and graphical presentations. Second, since the system is computerbased, it can be used to illustrate the role of simulation
and computation in engineering design. The above
453
454
Spring Joint Computer Conference, 1972
CLASSROOM DISPLAY
COMPlTfER ROOM DISPLAY
, Q lQJ
----f~
PDP-9
COMPUTER
I/O
BUS
INTERFACE
The system, with its dynamic systems simulation
and graphics capabilities is ideal for generating demonstrations in a wide variety of undergraduate engineering
disciplines. We hope to add interest to lectures while
clarifying points which are difficult to perceive in terms
of verbal descriptions or blackboard sketches. The
demonstration examples will in some cases precede the
lecture material to motivate and prepare the student
for the abstract material. In other cases, the demonstrations will follow the presentation of a concept to validate
and reinforce that concept. In both cases it is expected
that the real-time interaction offered by the system
will considerably heighten the sense of discovery and
intellectual curiosity of the students in the classroom.
Figure I-AID system
SYSTEM CONFIGURATION
dichotomy is not always clear in many classroom situations. However, it does serve to focus attention on the
two fundamentally different roles of the computer in
the system-as an invisible "helper" and as a visible
computer performing calculations and other tasks that
a student thinks a computer should do.
The classroom-oriented display system can also
serve several useful functions outside the classroom.
First, since a duplicate display system is also located
in the computer room, highly inquisitive or troubled
students can interact with a preprogrammed simulation
sequence on an individual basis and often answer their
own questions. Meaningful interaction can be achieved
with minimal programmed support because the student
has been introduced to the simulation sequence in the
classroom. A second function of the system outside the
classroom is with student use of the system hardware
and supporting software to add a new dimension to
their project work. As an example, a group of sophomore-level students programmed, as an extracurricular
activity, an animation of a pendulum swinging in an
accelerating railroad car to accompany a· project in
their Dynamics course. The third function the system
can perform outside the classroom is in conjunction
with the laboratory exercises associated with our introductory analog computer course. In these exercises the
students animate, in real-time, a pictorial representation
of the physical system they are studying by signals
generated in their analog computer simulation. The resulting iconic communication mode helps students
bridge the gap between the typical "squiggly-line" output of the analog computer and the physical system
which they are Elimulating. In addition, it has been
found that the introduction of computer animation
into an undergraduate course brings with it a fresh new
breath of life-a level of excitement and motivation
rarely seen today.
The classroom display system at Boston University
is depicted in Figure 1. From the figure it can be noted
that the bulk of the system is a typical hybrid computer
configuration consisting of a Digital Equipment Corp.
PDP-9 digital computer, two Applied Dynamics AD-40
analog computers and a custom designed interface.
Thus, the step from a hybrid computer to an interactive classroom display system is a relatively small
one-consisting of adding a Control Interface with remote control units, a Display Interface and large screen
CRT displays.
A hybrid computer was chosen to drive the system
to gain the complementary attributes of its constituent
analog and digital computers. The analog computer
offers a convenient means to simulate the dynamic systems used in most classroom presentations. The digital
computer is used to give the user a simple and yet
effective interaction with the simulation through the
use of a special control box located in the classroom.
Through its graphics abilities, it also gives the system
alphanumerics for giving instructions to the user and
displaying parameter values, and line graphics for
static and dynamic pictorial presentations.
Two independent large screen CRT displays placed
side-by-side are used in the classroom. This provides
the system with what the author believes is the visual
channel capacity required for a flexible and effective
computer-driven interactive classroom display system.
For example, in demonstrating the response of an electriC' circuit to some excitation, one display would present the schematic diagram of the circuit complete with
parameter values while the other display would present
the excitation and circuit response. Once given a dual
display system, it seems that almost all demonstrations
require such a system for effective presentations. This
may either be a coronary to Parkinson's Law, or, as
Versatile Computer Driven Display System
the author interprets it, an indication that two independent displays are essential.
Display Assignment
Configuration
DISPLA Y SUBSYSTEM
Of the two displays in the AID System, one is primarily used for the presentation of static or slowly
changing images such as alphanumeric text, pictorial
diagrams and graphs. This display, the left-hand one of
the pair, is a large screen TV monitor. It is driven by a
Tektronix 4501 Scan Converter, a device which accepts
x - y inputs and produces a video output signal. The
scan converter is based on the use of a bistable storage
CRT. Hence, this display functions as a stored type
display. It need only be written once and it will retain
the stored image until erased. When driven by a digital
computer, the stored type display places considerably
less burden on the computer than a refreshed type dis-
STORED
DISPLAY
REFRESHED
DISPLAY
~
TO
ANALOG
COMPUTER
VIDEO
INTS
X
Y
455
ASl
AS2
closed
closed
open
open
Refreshed
AS3
AS4
Stored
open
closed
open
DIGITAL
DIGITAL
open
open
closed
DIGITAL
ANALOG
closed
closed
open
ANALOG
DIGITAL
closed
open
closed
ANALOG
ANALOG
Figure 3-Source/display combinations
A functional diagram of the AID Display Interface
is given in Figure 2. Analog switches which are under
program control are used to set the system configuration to suit the particular problem being solved. Figure
3 presents the various combinations between driving
sources and displays. When both displays are driven
from the digital computer, the programmer selects the
display he wishes to write through the use of an appropriate display command. Both displays receive the
same x-y inputs. However, only the one being written
receives an intensify pulse. This allows the programmer
to switch back and forth between the displays. When
the displays are driven by the analog computer, display selection is achieved through trunkline patching.
CLASSROOM CONTROL UNIT
I/O
BUS
AS2
)
AN!~G
COMPUTER
Figure 2-Functional diagram of display interface
play. The stored type display is also convenient to have
for many analog computer generated displays. For example, a simulation may be running in the repetitive
operation mode with one value of a particular variable
being generated during each run. A storage type display
is required to present a plot of this variable versus time
in the classroom.
The other display of the system is used primarily
for the presentation of dynamic graphics such as animated iconic models (e.g., a pictorial spring-masssystem which looks and behaves like a real spring-mass
system) and curves generated by the analog computer
in the repetitive operation mode. This display is a large
screen x - y CRT which functions as a refreshed display.
It is driven directly by analog signals from either the
analog computer or the digital computer display
interface.
A remote control unit is used in the classroom to
give real-time interactive control to the system user. A
pictorial representation of this unit is given in Figure 4.
It was designed to fill the dual objective of presenting
to the user an extremely simple and yet versatile interface with the system while at the same time minimizing
the hardware and software needed to support the unit.
The AID Interactive Control Unit allows the user to:
(1) Set and change parameters.
(2) Set initial conditions.
GO
©
Ie
©
PARAM
©
I
2
3
4
5
6
7
8
9
10
II
12
+
VARIABLE
AID
CONTROL
Figure 4-AID interactive control unit
13
14
HELP
456
Spring Joint Computer Conference, 1972
(3) Choose a preprogrammed presentation mode,
i.e., what variables will be displayed, what
parameter will be variable, etc.
(4) Request HELP messages, e.g., switch assignments, presentation modes available and how to
use them, etc.
A more detailed look at the classroom use of the AID
Interactive Control Unit will be given in the following
section.
All interactive parameter and initial condition values
are entered into the system via a single potentiometer
on the· control unit. The analog signal from this potentiometer is read into the PDP-9 computer through
a channel of the AjD converter in the hybrid computer
interface. The digital computer then either· sets the
appropriate digital pot on the analog computer or
changes a program variable. It also presents the classroom user with a "dif,itaJ voltmeter" type display on
one of the display units so that he can set the variable
to the desired value. This visual feedback technique
not only compensates for resistive voltage drop in the
long lines to the computer room but also couples the
class in with "the action" and visually indicates to the
students the current value of the parameter being
changed.
When a user initiated response is requested by depressing one of the three pushbuttons, a serial data
stream containing information on the pushbutton depressed and states of the switches is transmitted over a
single line to the Control Unit Interface in the computer
room. When the complete message has been received,
a program interrupt request to the PDP-9 computer is
initiated. The computer responds to this interrupt and
branches to an appropriate point in the AID program
to carry out the requested response.
AN ILLUSTRATIVE EXAMPLE
Several segments from a presentation developed on
coupled oscillators will be used to illustrate the type of
typical interactive classroom use which can be made of
the system. When first initiated, the system presents a
title, a "what to do" message and then awaits further
commands from the classroom control unit. For the
example we are considering, the left-hand display
would present "MASS-SPRING SYSTEM . . . FOR
NORMAL SEQUENCING HIT 'GO' AT THE END
OF EACH STEP . . . OTHERWISE USE 'HELP'
SWITCH IN CONJUNCTION WITH 'GO' FOR
DIRECTIONS." In normal sequencing, the first depression of the GO button takes the system to the
parameter mode. In this mode the user can change any
of the parameter values from those nominally entered.
He does this by setting the appropriate switch, hitting
the PARAM pushbutton and then adjusting the potentiometer on the control unit for the desired value
while watching the "digital voltmeter" on the display.
This is illustrated by the top display pair of Figure 5.
The user is in the process of changing K3 from the
nominally entered value of 1.0 to a ne,,, value of 0.100.
The numbers in the < )'s are the switch assignments for
the parameters. Other parameter changes are made by
repeating the above sequence. The next depression of
the GO button takes the system to the initial condition
mode. For this particular example, the user does not
set any values for initial conditions but simply chooses
the perturbations to be made on the mass-spring system. When the IC pushbutton is depressed, the masses
are gently nudged to their initial condition position by
AID's "helpful little computer hands." The middle display pair of Figure 5 illustrates the initial condition
mode-it can be thought of as a snapshot of the displays as the hands are in the process of moving the
masses to their initial condition positions (down for
M1 and zero for M2). Subsequent depressions of the
GO button take the system through various run modes
such as the one illustrated in the bottom display pair
of Figure 5. For the case shown, an animation of the
bobbing mass-spring system is on one display while the
corresponding displacement of each mass from equilibrium position is plotted on the other display. Other
run sequences plot various combinations of accelerations, velocities and energies.
The above example illustrated the user following
normal sequencing by repeated depressions of the GO
button. By using the switches in conjunction with the
GO button, the user can break the normal sequence
and branch to any particular desired segment of the
presentation. Through use of the PARAM and IC pushbuttons, parameters and initial conditions can be
changed at any time during a presentation.
COMPUTER ROOM CONSOLE
A special console is used by the programmer in developing AID programs. It features dual displays
whose characteristics are identical to those in the classroom, an AID Interactive Control Unit, and a Computek GT50j10 graphic tablet. Thus, all phases of
program development ranging from initial image generation to final debugging and checkout can be done at
the console.
The console, in conjunction with the AID Language,
will not only make the programming of AID presentations convenient and easy but will also provide a
stimulating environment in which· to work. Weare de-
Versatile Computer Driven Display System
(I)
KI
(2)
MI
(3)
K3
(4)
M2
(5)
K2
PARAMETERS
KI = 1.0
MI=I.O
K3= .153
M2= 1.0
K2=1.0
INITIAL CONDITIONS
X I (O):
I FOR UP
2 FOR ZERO
3 FOR DOWN
X2(0}: 4 FOR UP
5 FOR ZERO
6 FOR DOWN
XI=O
~---'---"'""-
X2=O
~
Figure 5-Illustrative classroom display sequence
457
458
Spring Joint Computer Conference, 1972
pending on the latter attribute coupled with the drive
for relevance and accomplishment on the part of today's
students to supply a manpower pool to assist the instructional staff in developing AID presentations.
SOFTWARE SUPPORT
The AID Language under development to support
the system is in an experimental phase and might best
be described as a pseudo high-level language at this
point in time. I t has many of the appearances and
attributes of a high-level language but has no compiler
or interpreter. In its present form it is simply a collection of subroutines and symbol definitions that are
used in conjunction with the PDP-9 assembly language
programming system. This approach allows for changes
to be quickly and easily implemented-an important
consideration during the early experimental stages of
developing a language. Its chief disadvantages are a
slight awkwardness in the association of control variables with their commands-they must follow in a
vertical string underneath the command-and the use
of an octal rather than a decimal number system base.
However, even in this experimental form the language
is easy enough to use such that sophomore students
can write program sequences.
The language provides commands for:
(1) Servicing the interactive control unit.
(2) Controlling the analog computer.
(3) Generating static and dynamic graphical
displays.
It features an on-line mode which allows the program
developer to perform the following functions interactively while sitting at the computer room console:
Write his program in a conversational mode.
Enter graphical images via a graphic tablet.
Scale, move and synthesize graphical images.
Generate, scale and move alphanumeric text
displays.
(5) Tune up timing used in sequencing.
(1)
(2)
(3)
(4)
To illustrate the basic structure of the AID Language,
an example AID program is given in Figure 6. This
example shows how the top support, spring, and mass
of the MASS-SPRIN G SYSTEM discussed earlier
are generated. The analog computer is solving the differential equations governing the system in real-time.
From these system variables, the analog computer
generates the dynamic animation variables used to
animate the static images stored in the PDP-9 computer. The dynamic animation variables are read into
the digital computer on each pass through the program
by the SAMPLE commands.
In order to avoid becoming prematurely displaybound in a system designed for real-time dynamic
graphics it is essential that a continuous stream of
data flow to the display. Compound images must not
be constructed in memory and then displayed. They
must be displayed as they are constructed. This philosophy is inherent in the instruction pair TRANSFER/
CONTINUE. One point at a time is transferred from
a source table to a specified destination-usually a display. During this transfer of the image from the source
table, any of the AID manipulative commands placed
between the TRANSFER and CONTINUE command
operate on the image being transferred. All images
which are to be dynamically displayed are stored
centered around the origin of the coordinate system
used for the displays. This system has its origin located
in the center of the display area. Such an approach
simplifies the definition and generation of the dynamic
animation variables.
In the example of Figure 6 the image SPRIN G,
which consists only of the zig-zag lines, was dynamically
scaled in the x and y directions to convey the illusion
of a spring being alternately stretched and then compressed. The invariant vertical segments of the spring
were associated with the images TOP and MASS.
Another, and even better approach, is to use the command ANIMATE in conjunction with two key frames
stored in memory. In this case, the invariant vertical
segments of the spring could be associated with the
stored images of the spring rather than the mass and
top support. The number of control variables would be
reduced from three to two-one for translation and
one to govern the amount of linear interpolation between the key frames specified by the ANIMATE
command.
The header statement VIEW runs the program in
real-time for direct viewing in the classroom or computer room. When making a film, this mode allows for
previewing a sequence before it is actually recorded on
film. Once a satisfactory sequence has been obtained,
the statement CAl\1ERA is substituted for VIEW and
the system is ready for filming. The header statement
CAMERA automatically slows the system timing down
for filming at four frames per second and synchronizes
the computer to the movie camera.
FUTURE PLANS
We view the AID System configuration of Figure 1
only as a starting point in our endeavor to couple the
computer effectively into the classroom. For example,
Versatile Computer Driven Display System
459
LINE 0/
NEW
Initializes the system for a new run from t
LINE 1/
VIEW
Sets up timing, synchronization, etc. for realtime viewing
LINE 2/
CONFIGURATION DD
Sets up Configuration 1 - both displays driven
by digital computer
LINE 3/
LINE 4/
SAMPLE 0
SlL
Sample A/D channel 0 and assign the value to the
variableSl-L (Spring 1 Length Scale Factor)
LINE 5/
LINE 6/
SAMPLE
SlW
Sample A/D channell and assign the value to the
variable SlW (Spring 1 Width Scale Factor)
LINE 7/
LINE 10/
SAMPLE 2
SlV
Sample A/D channel 2 and assign the value to the
variable SlV (Spr1ng 1 Vertical Displacement)
LINE 11/
LINE 12/
SAMPLE 3
M1V
Sample A/D channel 3 and assign the value to the
variable M1V (Mass 1 Vertical Displacement)
LINE 13/
LINE 14/
LINE 15/
TRANSFER
TOP
DISPLAY 2V
Transfer one point of the image from the source
table named TOP to the refreshed display and
display in the vector mode
LINE 16/
CONTINUE
Continue the above initiated transfer until
completed
LINE 17/
LINE 20/
LINE 21/
TRANSFER
MASS
DISPLAY 2V
Transfer one point of the image from the source
table named MASS to the refreshed display
and display in the vector mode
LINE 22/
LINE 23/
LINE 24/
MOVE
ZERO
M1V
During the above initiated transfer, move the
image in the X direction per the variable ZERO
(which has a value of 0) and in the Y direction
per M1V
LINE 25/
CONTINUE
Continue the above initiated transfer until
completed
LINE 26/
LINE 27/
LINE 30/
TRANSFER
SPRING
DISPLAY 2V
Transfer one point of the image from the source
table named SPRING to the refreshed display
and display in the vector mode
LINE 31/
LINE 32/
LINE 33/
SCALE
SlW
SlL
During the above initiated transfer, scale the
image in the X direction per the variable SlW
and in the Y direction per SlL
LINE 34/
LINE 35/
LINE 36/
MOVE
ZERO
SlV
During the above initiated transfer, move the
image in the X direction per the variable ZERO
and in the Y direction per SlV
LINE 37/
CONTINUE
Continue the above initiated transfer until
completed
GOTO LINE 1
Figure 6-Illustrative example of AID programming
=
0
460
Spring Joint Computer Conference, 1972
interest has been expressed by a group of students in
tying the College's two wind tunnels into the PDP-9
for on-line control and data reduction. Once this has
been accomplished it is but a small step to bring the
thrill of direct on-line real-time experimentation into
the classroom through use of the AID System. Another
area of expansion under active consideration is a link
to the IBM 360/50 at our computer center. This would
open up new areas of application in which the problems
are best cast in general or problem-oriented high-level
languages such as FORTRAN, GPSS, NASAP, etc. In
this mode of operation the classroom control unit would
most likely be a typewriter-like keyboard. Still yet
another area of expansion is in application programs
resident in the PDP-9 itself. Work is under way in this
area with program packages for deterministic and
stochastic signal analysis (e.g., FFT algorithms, random
number generators, etc.). In this as well as in the above
cases, the structure of the AID Language will allow for
efficient integration of the expansions into the AID
System.
REFERENCES
1 R M BAECKER
Interactive computer-mediated animation
PhD Thesis Massachusetts Institute of Technology 1969
2 C CSURI
Real-time film animation
Proceedings of UAIDE Annual Meeting 1970
3 F GRACER M W BLASGEN
Karma: A system for storyboard animation
Proceedings of UAIDE Annual Meeting 1970
4 W H HUGGINS
I conic communications
IEEE Transactions on Education November 1971
5 D C MARTIN
A different approach to classroom computer use
ACEUG Transactions Vol 1 No 1 January 1969
6 J W WILLHIDE
A system for real-time dynamic graphics
Proceedings of Fifth Hawaii International Conference on
System Sciences 1972
GOLD-A Graphical On-Line Design System
by L. J. FRENCH and A. H. TEGER
RCA Laboratories
Princeton, New Jersey
INTRODUCTION
circuit designer; it must correspond to the natural
thinking process that the designer would use to make
corrections by hand. Yet the graphical language must
also be general enough to apply to other application
areas, and to deal with a hierarchical data structure
smoothly enough so that the user can take advantage
of its power without needing to understand how the
structure is organized.
Perhaps the two most significant contributions of the
work described herein are the creation of an efficient,
hierarchical data structure, and of general graphical
editing techniques that incorporate application dependent parts within the confines of a small stand-alone
computer. General purpose graphical systems and
graphical editing systems for IC masks exist, some of
which are listed in the references, but the GOLD system represents an attempt to achieve the generality of
large graphical systems and the practicality of smaller
IC mask design systems on a small stand-alone
computer.
The data structure described herein is ring type and
hence similar to that of McCarthy, 8 Sutherland, l and
Wiseman2 yet is different in design in that it is specifically partitioned for secondary storage and is efficient
in core utilization both in storage of the data structure
and of the data structure functions themselves. The
SELECT and LOCK editing functions are new and
represent attempts at overcoming refresh display hardware limitations (flicker) and providing convenient
techniques for rapidly protecting and interacting with
various hierarchical levels in the data structure.
Computer programs do not "design." They blindly
follow procedures that the computer programmer
thought should solve a given class of problems. However, the methods of solution for many design problems
are not a priori known. Actively inserting the human
in the design process can add the elements of experience, insight, and creativity to the computer's ability
to perform rote design procedures and repeated checking operations.
Graphic displays are ideally suited to this combination of computer power and human intellect if, and we
must emphasize only if, the application deals with
large quantities of data that must be absorbed or modified graphically. Teletypes or text displays are inadequate to deal with these pictorial problems. Full graphic
displays are the only practical mechanism to provide
rapid creation of a complex picture that can be quickly
understood by the designer.
We have developed a general system for Graphical
On-Line Design that operates stand-alone on a small
computer, and yet supports a large, powerful data
structure partitioned for local disc storage. The data
structure, described in more detail later, is capable of
storing relationships needed for computer-aided design,
including non-graphic as well as graphic information.
The GOLD system has been applied to the design of
integrated circuit masks. IC masks, especially for large
arrays, contain huge amounts of graphical data that
cannot be checked by the human designer without
some display or plot. Furthermore, attempting to correct the artwork for these masks from a file of text
plotting statements is an error-prone and time-consuming process. The interactive graphical editing possible
with GOLD is alleviating these problems.
We designed GOLD to be a user-oriented interface
between the computer and the designer. As such, the
graphical language used to modify the artwork has to
be easy to understand and to use by an integrated
SYSTEM DESCRIPTION
GOLD hardware system
The large capital investment and operating costs for
large computers and the advent of inexpensive, relatively powerful mini-computers convinced us to utilize
461
462
Spring Joint Computer Conference, 1972
SPECTRA 70/45
SPECTRA 70/25
SMALL
t------LOMPUTER
TIME SHARIN
SYSTEM
(USED FOR
CENTRAL FILE
STORAGE)
These files can be accessed by GOLD, where they can
rapidly be displayed, edited, and stored either locally,
or returned to the time sharing system.
PLOTS, also developed at RCA Solid State Division,
is an artwork language used to describe drawings interactively on the time sharing system via a teletype. The
files of PLOTS statements can similarly be accessed by
GOLD for interactive graphical manipulation with the
option of returning the modified files to the time shared
system. An output program can convert either PLOTS
or digitizer files to drive high accuracy plotters to obtain finished artwork. The compatibility that GOLD
has with these two artwork systems gives a mask designer the flexibility of being able to select the best
editing system for any part of a mask design.
GOLD software system
Figure 1-GOLD hardware system
a small computer in our interactive graphical design
system. If such a system can perform a useful task, it
might then be, and present evidence suggests that it is,
economically justifiable.
The advantages of convenient and rapid interaction
influenced our decision to utilize a refresh type display.
A block diagram of the GOLD system is shown in
Figure 1. The display is a refresh type, custom made by
Information Displays, Inc. and is refreshed via a Spectra 70/25 computer having 32K bytes of memory with a
1.5 fJ,sec cycle time. The input/output devices are a
light pen, typewriter, card read_er/punch, and a remote
time sharing system. The disc is a single, 774: million
byte capacity RCA 70/564 drive.
The philosophy of the GOLD system is that the fast
secondary storage medium (disc unit in this case) can
be utilized to provide access rates fast enough for
rapid on-line interaction with a very large data base.
The small computer can operate on a stand-alone basis,
not simply as a display controller.
A block diagram of the GOLD software system is
shown in Figure 2. Mask descriptions can be entered
via the on-line typewriter, light pen, cards, or from a
time sharing file. The mask description is processed by
the input language compiler which checks syntax and
produces object code for the Data Structure Compiler
(DSC). The DSC builds a partitioned hierarchical
data structure using a ring type language and a set of
subroutines which provide techniques of creating and
traversing partitioned ring type data structures. The
Computer-aided design system for integrated circuit masks
The GOLD system is compatible with other techniques for creating and editing integrated circuit artwork that have been developed at the RCA Solid State
Division in Somerville, New Jersey. Two of these techniques are a digitizer system and a user-oriented mask
description language, called PLOTS. The digitizer system captures a mask description by physically tracing
a drawing point by point. The mask description obtained is stored in central files of a time sharing system.
TIME SHARING FILE
Figure 2-GOLD software system
GOLD
partitioned data structure contains the accurate and
hierarchical description of the application being undertaken and provides a general interface for all data
manipulations.
The Picture Compiler (PC) is a recursive program
that traverses the partitioned data structure and creates
a binary display file within the confines of the user
supplied specifications (see the display function in the
third section). The binary display file is contained in
part of main memory and is used to refresh the display
to produce a picture. The picture compiler inserts into
the binary display file markers that provide the hierarchical connection between the binary picture representation and its corresponding description in the data
structure.
The light pen aids in graphical interaction by detecting light and interrupting the processor. The light pen
interrupt is processed via the Identification Program
which blinks the identified entity and provides the link
to the actual representation of the entity in the data
structure. The Graphical Editing Functions use the information supplied by the Identification Program to
gain access to the data structure and all editing is performed- on the data structure using the PRSP language
and corresponding functions. Finally, the output programs traverse the data'structure, again using PRSP,
and provide an output mask description on either cards
or in a time sharing file.
The data structure and data structure language
The data structure that has been designed and implemented within the GOLD system is a partitioned
ring type data structure. It has the capability of containing 500K bytes of data which is partitioned into
128 segments in secondary storage. The data structure
provides the capability of storing graphical information
and hierarchical relationships. All mask coordinates are
stored in a floating point notation created specifically
for the Spectra 70/25 and all floating point operations
are performed via software due to the absence of hardware. Any graphical entity can be edited and entities
can be combined into higher ordered entities within the
data structure.
Any entity can be locked or selected, which in the
data structure simply corresponds to a few bits being
set in the proper entity. If an entity has been locked,
editing will not be permitted on that entity. If an entity
that is locked is pointed to by the light pen, the identification program automatically identifies the next
higher unlocked entity. Thus, the lock function provides
the graphics user the capability of controlling what can
be edited and on what hierarchical level identification
463
should initially occur. Each entity in the data structure
has a bit which can be set to indicate that the entity
has been selected. Presently this general data structure
function has been employed only in displaying entities
as discussed in the third section. Select is a general
function which allows a user to select a class of data
structure entities for any desired operation.
The data structure language (PRSP) provides a
general language for creating and traversing partitioned
ring type data structures. It is a new language based
primarily on the work of Wiseman and Hiles of the
University of Cambridge in England. PRSP is a macro
language that expands into subroutine calls on 32 different data structure functions to provide full data manipulation capability with a common but well specified
interface. Perhaps most noteworthy of all is that the
data structure subroutines and the file management
program occupy only 100016 bytes of core. Core is at a
premium in a small computer and the size of any program must be weighed very carefully against the power
the program adds to the overall system. Each function
in PRSP has been designed to provide the greatest
capability in the least amount of core storage. In
PRSP the programmer has the capability of partitioning his data structure on secondary storage to suit his
particular circumstances. For the GOLD system a partitioning algorithm was selected to minimize disc I/O
for operations on a specific mask level.
The file management routines in conjunction with
PRSP provide rapid access to secondary storage for
program overlays as well as for data structure operations. If a small computer is to handle 500K bytes of
data structure and all the programs to provide a standalone system, the secondary storage retrieval time is
crucial to the success or failure of such a system. In the
GOLD system the average access time per segment
(4120 bytes of information) is about 55 msec. This is
fast considering that the disc rotation time for the raw
information is 31 msec. PRSP can handle any number
of data structure segments in core. However, present
core size has limited this to two data structure segments.
The file management routines calculate a "success factor" for each data structure segment in core. Whenever
a data structure function requests a segment that is
presently in core, the success factor is incremented by
one. Whenever a segment is requested that is not in
core, the least successful segment is overwritten by the
new segment. In the fourth section the results of two
file management algorithms are discussed.
Picture compilation
In the GOLD system the picture compiler compiles
a picture as constrained by the user. Since the amount
464
Spring Joint Computer Conference, 1972
picture compiler program
section.
IS
contained in the fourth
GRAPHICAL CAPABILITIES
Figure 3-Display hardware layout
A user of the GOLD system wants to modify the artwork for a given set of masks by making additions or
corrections to it. He therefore needs to access the files
containing the artwork description, choose the portion
to be displayed, and then be able to do the actual
editing operations. GOLD provides a set of graphical
tools to perform these functions. The light pen is used
to pick operations, identify parts of the drawing, and
perform many of the manipulations. The user inputs
lengthy text messages such as personal file names or
identification with the on-line typewriter. Figures 3, 4
and 5 show examples of display usage.
of data involved in a mask description may be roughly
Y2 million bytes, it is impossible to maintain the entire
mask description in a display file in core. Thus, the
user specifies what part of the mask he wishes to see
and the picture compiler provides that specific display
file by traversing the data structure. One of the func~
tions the picture compiler performs is zoom (windowing). While our display does not have hardware zoom,
software zoom would be required to provide a reasonably sized display file. The speed of the picture compiler
is the most critical of all programs since it affects the
interaction time of the system. An evaluation of the
Figure 5-Display of part of a complex mask (zoom used).
Flicker is evident
Figure 4-Display screen showning an Ie design with 3 mask
levels superimposed. There is no display flicker
The display screen is divided into three functional
areas. On the right side of the display, the menu of
command choices is shown. These choices change as the
user performs a given function so as to guarantee that
only legal commands can be picked at any step in the
process, and to provide detailed commands for each
general function requested. At the top of the screen,
system messages are displayed to guide the user in
choosing the correct sequence of operations, and to
issue error messages when needed. Error messages are
blinked to attract the user's immediate attention; normal requests to indicate the next step are not blinked.
GOLD
465
•
By pointing the light pen at the command FILE, the
user has a choice of retrieving artwork files in various
formats. For example, PLOTS files, consisting of
"English-like" plotting statements, can be accessed via
the local card reader or from remote files on the time
sharing system. The system allows the user to define
and repeatedly call graphical subroutines of any degree
of complexity. These calls may be nested up to 10
levels deep in PLOTS, however, the nesting is unlimited in the data structure used by GOLD.
Another input format is the data structure itself.
The user may store files on the local disc or on cards
with all the structural information added during the
graphical design session, and then retrieve the files for
later enhancement.
the inherent inaccuracies of any graphical display. The
zoom operation is performed on the data structure so
that full precision is maintained in the display file. At
any time, the user may point to a light button requesting full arhvork size. This gives in effect a quick zoom
out to display the full artwork.
The major problem in thc GOLD systcm is display
flicker, that is, the amount of information that can be
displayed. Presently the system has memory space to
display 2000 vectors while flicker occurs at about 800
vectors. The fact that new display hardware currently
available is a factor of 2 or 3 faster than our display
would aid in this problem but certainly vwuld not solve
it. The functions WIN,DOW and SELECT (described
under Editing techniques) in some cases solve the problem by allmving the user to remove unnecessary parts
of the drawing from the screen in order to eliminate
confusing detail and reduce flicker. However, in other
cases the user cannot eliminate parts (or enough parts)
of the picture and needs to display 4000 to 5000 vectors
without flicker. Some of the users who originally
thought they could do little, if any, editing \vithQut
seeing large quantities of the picture at a time, have
since learned to think about mask design in a different
fashion and have found they can do a great deal of
work in a piecewise manner.
Display creation
Editing techniques
Having read in a file, a user has several tools for
creating the desired display. He can specify which mask
level should be shown, or request a combination of any
number of mask levels. The line structure for eaph
mask level can be individually chosen as either solid,
dotted, dashed, or dot-dashed. Thus, he can check
alignment of entities between mask levels, and still distinguish, by the line structures, which level each shape
is on.
The WINDOW function permits a user to zoom in
or out on any section of the· artwork. To zoom in, he
uses the light pen to position a tracking mark at the
origin of the desired window. The absolute X,y value in
mils of this coordinate is displayed as a numeric check.
He draws a square with the light pen indicating the
area he is interested in. When satisfied, he points to an
OFF button attached to the tracking mark, and the
area within the square is enlarged to full screen. Whichever mask levels and line· structures were displayed before are retained after the windowing operation. The
zoom feature permits a user to work on large drawings
to whatever precision he desires by magnifying that
section of the artwork and consequently overcoming
All the graphical functions can operate on any entity
displayed on the screen. The lowest level (atomic) entities are lines, simple polygons and orthogonal polygons. The system will treat a light pen hit on any
vector on the screen as though the entire entity had
been identified and will blink that entity. For example,
a hit on a side of a complicated polygon will cause the
entire polygon to blink, and the user, having visually
verified that he does mean that polygon, can now
modify the polygon via one of the graphic functions.
The general editing functions encompassed by the
system are building block, move, copy, delete, rotate,
measure, input and select.
Beneath the message line is a line that can contain
temporary information for the user, such as X,y data,
and in which the user composes various light pen responses for the system. The third and largest functional
area, occupying the central portion of the screen, displays the picture requested by the user. The actual
editing changes are seen here.
File access
1. BUILDING BLOCK
The power of graphical interaction lies in being able
to create and operate on more complicated entities. The
user, by pointing at the words BLDG BLOCK (a light
button in the menu), can designate any number of
atomic entities and previously defined building blocks
as a new building block. The entities may be connected
466
Spring Joint Computer Conference, 1972
or unconnected, and may be from several different
mask levels. The new building block is placed in the
data structure to indicate its relationship to the rest of
the artwork. Building ,blocks may be nested to any
desired degree.
In order to use these building blocks, the light buttons
MORE, LESS and NONE are part of the menu. On a
light pen hit, the lowest level non-locked entity will
blink on the screen. Pointing at MORE tells the system
to move up to the next level of complexity in the data
structure, i.e., the next higher building block. This can
be repeated till the most complex building block, of
which the original vector is a part, is blinking. Whatever is blinking at a given time can be operated on by
anyone of the graphical functions. LESS steps downward in complexity through the building blocks, and
NONE stops everything from blinking.
4. ROTATE
The user may rotate certain entities in increments of
90°, and may mirror them about the x or y axis. All
eight possibilities of mirroring and rotation are
available.
5. DELETE
Any identified (blinking) entity may be deleted.
6. MEASURE
The tracking mark provides a numeric check on any
x,y location on the screen. The optional imposed grid
and x only, or y only, tracking constraints are the same
as those described in MOVE.
2. MOVE
7. INPUT
Any blinking entity (entity and building block will
be used synonymously from this point on) can be
moved using the light pen. A tracking mark appears on
the reference point of the entity. By pointing at the
tracking mark, the user moves the entire entity across
the screen. The x,y location of the tracking mark in mils
is shown at the top of the screen as a numeric check.
The user can constrain the motion to x only, or y only,
at any time. When the light pen is released, the entity
"jumps" to the nearest user-defined grid location. This
grid, which can be. changed whenever desired, permits
smooth tracking of entities, and yet precise positioning
to any degree of coarseness. The user can also step the
entity in increments of this grid horizontally or
vertically.
The user may specify the absolute x,y position where
the entity should be moved or he may give a numerical
increment (up, down, right or left). In these cases the
entity jumps to the new position and the absolute x,y
location is again displayed on the screen.
When satisfied, the user points to 'OK' to finalize the
change.
3. COpy
Any degree of complexity of building blocks may be
copied. The user identifies the desired entity, checks
that it is blinking, and requests a copy. The copy is
drawn, slightly displaced from the original, and IVIOVE
automatically called to operate on the copy.
This function allows the user to create new atomic
entities, namely lines, simple polygons or orthogonal
polygons. The user specifies which mask level the new
entity is to appear on, and a desired width if the entity
is a line. Lines are drawn as a center line representation
to reduce clutter on the screen, and can have an optional orthogonality constraint applied. Simple polygons may have sides at any angle, although the tracking
mark can be used to make any given segment horizontal or vertical. The system will guarantee closure of
both simple and orthogonal polygons, or give an error
message if not possible. The special case of rectangles is
handled by allowing the user to fix one corner of the
new rectangle with the tracking mark, and then move
the diagonally opposite corner (via the tracking mark)
to draw in one motion all four sides. All x,y values are
continually displayed at the top of the screen while
these entities are being drawn.
8. SELECT
In order to reduce clutter and to minimize flicker on
the display, the user can select any number of entities
with the light pen. He then can choose to display only
the selected entities, to blank only the selected entities,
or to display all entities. The system reminds· him of
how many entities are selected at any given time. This
feature permits work on complicated artwork at full
size without destroying the sanity of the user.
GOLD
File storage
During a design session, the entire data structure
may be stored temporarily in any of four work areas
on the disc. This allows the user to try different modifications of the job, and still be able to back up to any
of these previous check points if desired.
After editing is complete, the file may be stored
locally in data structure form, or converted back to
PLOTS and stored on the time sharing system or cards.
From the time sharing system, the files may be plotted
on either of two high accuracy flat bed plotters to produce the final artwork for the masks.
467
picture compilation required a total of twenty minutes.
We must stress that this is not a real case. The amount
of information here (all parts of all mask levels) is far
more than the user could visually understand or work
with on a refresh display, and more than could fit in
any display file.
The picture compile time distributes as follows:
DISC I/O
TOTAL DISC TIME=2.71 l\lINUTES
= 13.6 PERCENT OF TOTAL TIl\lE
TOTAL # OF DISC I/0=2937
SYSTEM EVALUATION
All editing functions in the GOLD system are performed on the data structure using PRSP and require
no more than at most a few seconds. As explained in
the second section, the interaction rate of the system is
critically dependent upon the picture compiler. The
picture compiler program extracts entities on the user
specified mask levels, handles the SELECT and LOCK
functions, performs scaling, rotation, all windowing,
and the creation of a binary display file with embedded
data structure markers. The picture compilation time
varies in a rather complicated fashion from a few seconds to a maximum of about 1Y2 minutes with the
average being about Y2 minute. As an example, to
create a display file of 800 vectors, the picture compiler
requires 15 seconds.
A memory array designed at RCA Laboratories by
J. Meyer and N. Kudrajashev using the GOLD system
has been used as a benchmark to evaluate the operation
of the system. The circuit is a 256-bit random access
CMOS/SOS memory chip which measures 144X173
mils. The description consists of 7 mask levels. and approximately 17,000 points. To evaluate where the picture compile time is spent, measurements were made
on the picture compilation of all mask levels with
everything inside the window. In the actual operation
of the GOLD system this picture compilation would
terminate abruptly when the display file core space was
exhausted. To overcome this, the picture compiler was
temporarily patched such that the actual binary display
file words were discarded. Thus, this compilation represents a situation that cannot exist in practice but does
give a worse case evaluation that is an order of magnitude
worse than actual conditions.
Using a file management algorithm which handles
only one piece of data structure in core at a time, the
FLOATING POINT OPERATIONS
(software subroutines)
# ADD'S = 157,984
# MULT'S= 60,225
(1.46 msec/ ADD)
(1.36 msec/::.YIUL T)
TOTAL #=218,209
TOTAL FLOATING POINT TIME
= 5.22 MINUTES
= 26.1 PERCENT OF TOTAL TIME
DATA STRUCTURE OPERATIONS
TOTAL # OPERATIONS (FUNCTION CALLS)
=393,339
TOTAL D.S. OPERATION TIME
= 7.0 MINUTES
= 35 PERCENT OF TOTAL TIl\lE
OTHER COMPUTE TIME
(EXCLUDING ABOVE)
= 5.07 MINUTES
=25.3 PERCENT OF TOTAL TIME
The entry labeled "OTHER TE\lE" accounts for
the decision making time of the picture compiler. The
average instruction execution time of the 70/25 is approximately 20 J.lsec. Thus, in twenty minutes this is
about 2.4 X 109 executed instructions. These numbers
show two significant things. First, the amount of information contained in integrated circuit artwork is
enormous. Second, it is important to notice that the
468
Spring Joint Computer Conference, 1972
disc I/O time, even with the very simplest of file management algorithms as used in this measurement, is
relatively small. This is impressive considering that the
entire GOLD system operates on both the data structure and all programs in a partitioned (virtual memory)
environment.
The same picture compilation was rerun using a file
management algorithm that manipulates two data
structure segments in core at a time. This algorithm reduced the number of disc I/O's to 759 and a total disc
time of .7 minutes. This reduced the overall compile
time to 18 minutes, such that the disc I/O time was
only 3.9 percent of the total compilation time. While this
algorithm reduces the disc I/O time significantly, the
overall effect on the system time is small. The conclusion to be drawn from this is that the GOLD system
is not disc limited as one might anticipate from a virtual
memory system. Part of this is due to the design of the
data structure, part to the design of the file management routines, part to the disc file organization, and
part due to the fact that the 70/25 is a moderate, if not
slow, computer. To explain the latter point in more detail, it is possible that many of the modern minicomputers could decrease the average instruction execution time by roughly an order of magnitude. Some
have hardware push down stacks which would significantly decrease the time, perhaps even more than the
ten to one reduction in the faster instruction set. In
any case a faster instruction speed would decrease the
PRSP and OTHER TIlVIE by a factor of ten but would
harve no effect on the disc I/O time. The times for the
various items would then be as follows:
DISC I/O
# READS=759
UNCHANGED
TOTAL DISC TIME
=.71 MINUTES = 12.8 PERCENT
FLOATING POINT OPERATIONS
# ADD'S = 157,984
# MULT'S= 60,225
(1 msec/ADD)
(1 msec/1VIULT)
TOTAL #=218,209
TOTAL F.P. TIME
= 3.62 MINUTES = 65.3 PERCENT
PRSP FUNCTIONS
TOTAL # OPERATIONS=393,339
TOTAL TIME
=.7 MINUTES = 12.8 PERCENT
OTHER TIME
=.51 MINUTES=9.1 PERCENT
TOTAL COMPILATION TIME
= 5.54 MINUTES
These last figures show that if the computer was a
modern mini-computer, the disc I/O time would become a somewhat more significant part of the system
time but would still be relatively unimportant. Another
way of viewing this is that if the system described
above had infinite core, such that the disc I/O time was
zero, it would only be 12.8 percent (disc I/O part)
faster.
These figures also show the usefulness of floating
point hardware. If the system described above had 10
,usec floating point hardware instructions, the total
floating point time would be 2.18 seconds instead of the
3.62 minutes required by the software floating point
operations. This would increase the overall speed of the
system by approximately 65 percent and reduce the
total compilation time to less than 2 minutes. Thus, a
modern mini-computer with floating point hardware
would have more impact than a mini-computer with a
large memory capacity.
One of the problems generally encountered in the
utilization of list type data structures is the large
amount of overhead storage required due to pointers,
etc. In the GOLD system significant effort has gone
into creating an efficient data structure while maintaining the advantages of list type structures. In many list
type data structures it is not uncommon for the data
structure to require 10 times more storage than the
raw data alone (canonical form). The GOLD data
structure, for the benchmark integrated circuit previously described, requires 71,677 bytes of storage. The
canonical raw data form (non-structured) requires
25,158 bytes of storage. This is a ratio of 2.8 to 1,
which shows that the data structure is rather efficient
in storage utilization. Recent work in this area has resulted in relatively simple techniques (simple in implementation) which will reduce the storage from 71,677
bytes to approximately 56,000 bytes, and would make
the ratio 2.2 to 1. The size of data structures at this
point presents little problem to the GOLD system. The
mask description for the benchmark integrated circuit
is one of the more complicated circuits being designed
GOLD
yet only uses about 15 percent of the available data
structure storage.
SUMMARY
The GOLD system has been utilized on an experimental basis for about one year. Most users have found
the system easy to learn, and to use. However, all users
have required some training, to varying degrees, to
utilize the system's more sophisticated capabilities.
We have overcome the basic inaccuracies of the display hardware by providing continual numeric checks,
a quantized user grid, and z~oming ability. The power
of GOLD is illustrated by building block, which gives
the ability to work with functional units as a whole, and
to define new functional units dynamically. Thus, the
user can, for example, apply all the graphical manipulations to a line or to the transistor it belongs to, or to
the circuit the transistor belongs to, etc.
The system offers very rapid and convenient interaction and is compatible with all other parts of the
overall CAD system for integrated circuit artwork. We
believe the GOLD system proves that it is possible and
economically desirable to utilize a small computer on a
stand-alone basis to provide a large, sophisticated,
hierarchical data structure and graphical system.
ACKNOWLEDGMENTS
The authors wish to express their appreciation for the
programming contributions to GOLD made by M.
Gilchrist, J. Grabowski, G. Held, F. Larkin, C. Neroth,
G. Payor, and H. Schnitzler. N. Wiseman and J.
Hiles of Cambridge University, England, aided in the
original version of the data structure routines, and M.
Lewin designed and debugged the computer-display
hardware interface. The cooperation of J. Miller and
D. Ressler contributed to making GOLD compatible
with RCA Solid State Division's artwork systems.
Finally the support of G. B. Herzog and B. Lechner of
RCA Laboratories made this work possible.
REFERENCES
1 I E SUTHERLAND
Sketchpad-A man-machine graphical communication system
Lincoln Lab Technical Report #296 30 Jan 1963
2 N E WISEMAN J 0 HILES
A ring structure processor for a small computer
the Computer Journal Vol 10 No 4 Feb 1968
3 T E JOHNSON
A mass storage relational data structure
MIT Dept of Architecture Preprint No 866
4 D E KNUTH
Fundamental algorithms
Addison and Wesley Vol 1 1968
5 D T ROSS C G FELDMANN
Project MAC
MIT Report MAC-TR-4 May 6 1964
6 M H LEWIN
An introduction to computer graphic terminals
Proc IEEE Sept 1967
7 ADAMS ASSOCIATES
The computer display review
Vol 1 July 1966
8 J McCARTHY et al
LISP 1.5 programmer's manual
MIT August 17 1962
9 N E WISEMAN
A note on compiling display file from a data structure
University Mathematical Laboratory Cambridge MaEs
March 1968
10 L G ROBERTS
Graphical communication and control languages
Lincoln Lab Report
11 W R SUTHERLAND
The coral language and data structure
Lincoln Lab Techn Report 405 Jan 1966
12 L G ROBERTS
Homogeneous matrix representation and manipulation of
N-dimensional constructs
Lincoln Lab Report MS-1405 May 1965
13 L G ROBERTS
A graphical service system with variable syntax
Lincoln Lab Report Vol 9 No 3 March 1966
14 Development of on-line system for computer-aided design of
integral circuits
N orden Division of United Aircraft Corp
Report AFML-TR-67-342 Vol 1 Oct 1967
15 W R SUTHERLAND
On-line graphical specification of computer procedures
Lincoln Lab Techn Report 405 23 May 1966
16 W H NINKE
Graphic 1-A remote graphical display console system
Bell Telephone System Tech Publication 1965
17 Graphics
Lincoln Laboratory Semiannual Technical Summary
31 May 1969
18 J C GRAY
Compound data structure for computer-aided design
ACM Proceedings 1967
19 T E JOHNSON
Sketchpad III, a computer program for drawing in three
dimensions
SJCC 1963
20 I E SUTHERLAND
Computer graphics
Datamation May 1966
21 N LINDGREN
Human factors in engineering
IEEE Spectrum April 1966
22 L J FRENCH
An interactive graphical debugging system
Design Automation Workshop June 1970
469
470
Spring Joint Computer Conference, 1972
23 J C MILLER C M WINE
A simple display for characters and graphics
IEEE Transactions on Computers Vol C-17 No 5 May 1968
24 L J FRENCH
A partitioned data structure system
Ph D Thesis Columbia University June 1971
25 F K RICHARDSON et al
An interactive, graphical system for the design of photomasks
NEREM Nov 1970
26 L H HAZLET
I am an integrated circuit design engineer
Electronic Design News June 1969
27 A SPITALNY M J GOLDBERG
On-line graphics applied to layout design of integrated
circuits
IEEE Proc Nov 1967
28 D K LYNN
Computer-aided layout system for integrated circuits
IEEE Transactions on Circuit Theory Jan 1971
29 J S ZUCKER
Graphical layout system for integrated circuit mask design
IEEE Transactions on Circuit Theory Jan 1971
30 J F JARVIS
Interactive graphics mask design program
ISSCC Feb 1971
Establishing lower bounds on algorithms-A survey
by E. M. REINGOLD
University of Illinois
Urbana, Illinois
Even for a specific answer to the first question, how
the efficiency of an algorithm should be measured is not
obvious. Ideally, we would like to assign a realistic cost
to every operation performed; such a model usually
makes the establishment of lower bounds too difficult.
To simplify the problem, we isolate the "key" operations and ignore all others. There are two ways to count
the operations used by an algorithm: the number used
on the worst case input Ot the expected number used
on a random input, assuming some distribution of the
inputs. An algorithm is minimax optimal or worst case
optimal if no algorithm is more efficient in the worst
case; an algorithm is minimean optimal or average case
optimal if no algorithm is more efficient in the average
case.
It should be noted that some of the results discussed
here have never been formally published, but have
become a part of the "folklore" of the area; in such
cases the citation will be to the place they first found
th~ir way i~to print-usually a textbook. ::V[oreover,
thIS survey IS not complete: to include every known
result would give the paper undue length; in addition,
many results undoubtedly remain unnoticed buried in
.
'
Journals, technical reports, and unpublished manuscripts.
INTRODUCTION
Algorithms for various computations have been known
and studied for centuries, but it is only recently that
much theoretical attention has been devoted to the
analysis of algorithms. Turing machines and recursive
functions were the first approaches, but these models
which provide much interesting mathematics, do no~
look at the problem from a practical standpoint. In
"real" computing, no one uses Turing machines to
evaluate polynomials or to multiply matrices, and
little of practical significance is obtained from that
approach. On the other hand, recent work has led to
more. realistic models and, correspondingly, to more
practICal results. Most of the results cannot be considered to be truly practical, but, all of them were
motivated by practical considerations.
This survey is concerned with efforts to establish
lower bounds on the number of operations required to
solve. various practically inspired problems; in particular
we dISCUSS the problems of sorting, searching, merging,
root finding, polynomial evaluation, matrix multiplication, and many others. No theorems will be
rigorously proved; for some the idea of the proof will
be presented, and most will only be stated. The reader
is ~rged ~o p.ursue in the literature the details of any
tOPICS whICh Interest him.
In the establishment of lower bounds on algorithms
we must consider the following questions:
NOTATION
The floor and ceiling operations are defined as usual:
Lx J is the greatest integer less than or equal to x and
rxl is the least integer greater than or equal to ;. We
• What function or class of functions is to be
computed?
• What class of algorithms is allowed?
• With what are we measuring lower bounds?
use the standard notation for the order of magnitude
of a function: fen) =O(g(n)) if there is a constant
k> 0 such that
The answers to the last two of these questions are
inherently interwoven with the answer to the first
question. In analyzing sorting we will consider different
t?ings impo~tant than in analyzing matrix multiplicatIOn, and so In each case we will allow different kinds of
algorithms and we will measure their efficiency in
different ways.
.
fen)
hmsup-- =k
n ..... oo
g (n)
.
If the limit
lim fen) =k
n ..... oo g (n)
471
472
Spring Joint Computer Conference, 1972
Lemma 2:
The minimum height of an extended binary tree with
n external nodes is rIgn l.
A complete discussion of most of the results discussed
below can be found/ in Knuth. Kn72
Sorting
Figure I-An extended binary tree representing the computation
of the median of three numbers x, y, and z
exists and k = 1, we say that f (n) is asymptotic to g (n) ,
written f(n)r-..;g(n); if k=O then we say that
f(n) =O(g(n)).
The symbol "lg" is used to represent logarithms base
2, while "In" is used for natural logarithms. We use
"log" as the generic term when the base is unimportant.
CO~VIBINATORIAL
PROBLEMS
In studying the complexity of algorithms for combinatorial problems such as sorting, finding the median,
merging, and others, we will allow algorithms to have
only pairwise, errorless comparisons and no other
operations. It is convenient to represent the algorithms
as extended binary trees (like flowcharts), an example of
which is shown in Figure 1. Each internal node, drawn
as a circle, represents a comparison between two
numbers (inputs or constants) and each external node,
drawn as a rectangle, represents a possible outcome of
the algorithm. Thus Figure 1 is the tree corresponding
to an algorithm to find the median of three numbers
x, y, and z.
The height of the tree corresponds to the number of
comparisons used in the worst'case. The external path
length of a tree is defined as the sum of the distances
from the root to each external node; thus if there are n
external nodes, the external path length is n times the
average number of compares, assuming all outcomes are
equally probable. Both the worst case and the average
case provide reasonable measures of efficiency. The
following are useful:
Lemma 1:
The minimum external path length of an extended
binary tree with n external nodes is nrIgn l+n-2flgnl.
Suppose we are given a set {Xl, ... , Xn} ; what is the
minimum number of comparisons required to determine
the permutation 7f' so that X'lT"(I) ij =
{
if j=iq+k
ootherwise
and letting X = (xu, ... , Xl q, X21, ... , X2q, ••• , Xpq) •
FiducciaFid71 proved a theorem similar to Winograd's,
but involvi~g submatrices rather than columns:
Theorem 12:
Let <1>, (j>, X and F be as in Theorem 10. If has a
u by v sub matrix S such that there are no nontrivial
vectors a, artd {3 such that as{3 is in zero, then at least
u+v-l multiplications/divisions are required to compute x+(j>.
Winograd gave a very general definition of a scheme
without .preconditioning, and considered only the
number of multiplications/divisions. He showed:
Immediate corollaries to this theorem are that at
least three real multiplications are required to compute
the product of two complex numbers (also proved by
Munro Mu71a ) and that at least seven real multiplications
are required to compute the product of two quaternions.
WinogradWi70 similarly generalized Motzkin's result
(part of Theorem 8) on the number of multiplications
when preconditioning is allowed:
Theorem 10:
Theorem 13:
Let be an m by n matrix whose elements are in the
field F, let (j> be an m vector of elements in F, and let X
denote the n column vector (Xl, ... , Xn) so that
Let <1>, (j>, X and F be as in Theorem 10. If there are
u column vectors in such that no nontrivial linear
combination of them (over F) is in Fm, then any scheme
with preconditioning computing x+(j> requires at
least L(u+ 1) /2 J multiplications/divisions.
i=I, ... , m.
x+(j>E F (Xl, ... , Xn) m.
If there are u column vectors in such that no nontrivial linear combination of them (over F) is in Fm,
then any scheme, without preconditioning, computing
x+(j> requires at least u multiplications/divisions.
Pan's result on the number of multiplications needed
for polynomial evaluation without preconditioning
(part of Theorem 7) follows from this theorem as a
corollary, for here is the 1 by n+ 1 matrix
and the columns of 0 there is a multiplication algorithm such that the
time required to multiply two n digit numbers is
O(nHE ). Schonhage and StrassenScho71 devised a
different algorithm which requires at most time
o(n logn log logn) ; this is the most efficient algorithm
known, but it has not been proved optimal.
The only non-trivial optimality result is due to
Cook and Aanderaa Co69 where they proved that on a
bounded activity machine, an on-line "super" Turing
machine, multiplication cannot be performed in less
than time O(n logn/ (log logn)2).
Ofmano f62 introduced the idea of studying the delay
time of a circuit and the number of elements in a circuit
which computes some given function, say addition.
ToomToo63 extended this work to multiplication and
WinogradWi65 ,wi67 and Spirasp69 derived lower bounds on
the number of delays and elements required for various
operations. Elementary discussions of some of this
material appears in References Arb69 and Wi68. This
work is not really germane to the present discussion
since it deals with circuitry rather than computational
schemes of a programmable nature.
Graphs
Other than information theory arguments, there is
only one known technique for establishing lower bounds
on graph algorithms: if the graph of n nodes is presented
as an n by n binary connection matrix then 0 (n2)
operations are needed to examine all of the arcs of a
graph. Based on this observation, Holt and ReingoldH0172
have shown that determining shortest paths, the
existence of cycles, and connectedness requires 0(n2)
operations for graphs with n nodes. These results show
that the "usual" 0 (n 2 ) algorithms for these problems
are optimal to within a multiplicative constant factor,
when the graph is represented as a connection matrix.
Hopcroft and TarjanHop71b have devised an O(n logn)
algorithm which determines whether or not an n node
graph is planar; TarjanTa71 has improved this to O(n).
These algorithms do not violate the lower bound of
o(n2 ) since a planar graph of n nodes can contain at
most 3n - 2 arcs; additionally, their algorithm requires
that the graph be presented in a certain linked list
format, rather than as a connection matrix.
Computing the transitive closure of a graph is another
well-known problem in this area. Warshallwa62 gave an
o(n3 ) algorithm for computing the transitive closure of
a graph from its connection matrix. FurmanFu70 applied
Strassen's method of matrix multiplication to that
same computation obtaining an 0[n 1g7 (logn) 2+ EJ;
Arlazarov, Dinic, Kronrod, and FaradzhevAr170 developed another 0(n3 ) algorithm. Recently, it has
been shown Mu71c,Fis71 that the problems of doing Boolean
matrix multiplication and of computing the transitive
closure are equivalent to one another; that is, given an
o(f) algorithm to multiply Boolean matrices, we can
derive an O( f) algorithm for transitive closure, and
vice versa. In connection with this result, an
o(n 197 (logn) HE) algorithm is developed.
Harper and Savage (unpublished) have shown that
the problem of matching bipartite graphs with n nodes
is at least 0 (n 3 ) in complexity when the computation is
done by combinatorial switching network. In contrast
with this, Hopcroft and KarpHop71c have developed an
o(n\/n) algorithm, using a different model of computation.
Maximization of unimodal functions
A unimodal function of one variable is function f
which has a unique maximum x; it is characterized by
xy>x=} f(x) Xo. Thus, the first input record becomes the root
of the Quicksort tree, the second input record the root
of one of the two principal subtrees, and so on.
Evaluation of expected values presupposes the
existence of a probability distribution over input
permutations; we shall adopt the hypothesis that all
such permutations are equally likely. Although there
are definitely situations in which such is not the case,
there are many others to which it is a reasonable
approximation. In addition, the results of such an
analysis usually are observed to be good indicators of
the measured performance of running programs.
Parenthetically, although this may seem a strong
assumption, it is actually weaker than assuming, for
example, that the key values are independent, identically distributed, random variables.
To proceed with the analysis, we need once again to
choose a figure of merit, but before we can choose one
we need more information about how the algorithm is
to be implemented. Suppose the input sequence is in
locations numbered 1 through n: Transfer the first
record to another location t, and begin a search of
2,3, ... , looking for the first record, say Xj in location
j, larger than XI(Xj>XI). Following examination, each
such record is returned to a location numbered one less
than its original one. Now begin a search of locations
n, n-l, ... , looking for the first record, say Xk in
location k, smaller than Xl, and returning each record
to its original location. Interchange the contents of
locations (j -1) and k-i.e., Xj and Xk. Now all records
in locations· 1 through j -1 are smaller than Xl and all
those in locations k through n are larger; location j
is redundant. We now repeat the above process on
locations (j + 1) through k -1 and continue this until
the pointers j and k converge to adjacent locations, say,
rand r+ 1. Then Xl is inserted into r, its correct position
in the output sequence, and the two sequences in
locations 1 through (r-l) and (r+ 1) through n are
each treated by the above process.
At the level of detail we are considering, the only
obvious figure of merit is the number of comparisons
made in the searches. There are no other obvious
memory accesses or operations, except those required to
maintain pointers to the boundaries of partitioned
subsequences, such as (r-l) and (r+ 1) above. In
fact, it is possible to hold this requirement to quite
reasonable limits6 ,7,8 and we shall therefore concentrate
on the expected number of comparisons, which corresponds to the expected path length of the Quicksort
tree.
Let E (n) be the expected compares required to sort a
sequence of n records. Then, if per) =probability that
the root of the Quicksort tree ranks rth in the input
sequence,
n
E(n) =
L: per) [E(r-ll r) +E(n-r+ll r) + (n-l) ]
T=l
where E(y I r) denotes the expected compares to sort a
sequence of y records conditioned on the fact that r is
the root. But under our assumptions, any record is
equally likely to be the root; thus p (r) = 1/n for all r;
furthermore E(y r) is similarly independent of r.
Thus:
E(n) = (n-l)
2
n
n
T=l
+ - L: E(r-l)
Similarly, following Windley:19
2
E(n-l) = (n-2)
n-l
+ (n-l)
~E(r-l)
nE(n) - (n-l)E(n-l) =2(n-l) +2E(n-l)
E(n)
E(n-l)
--n+l
n
2 (n-l)
4
n+l
n(n+l)
(1)
2
n
4
n-l
2
=-+L:-.--l
n+l
i=2 ~+1
or
E(n) =2(n+l)
n
1
i=l
~+1
L: -.-
~1.39(n+l)
-2n
log2n-O(n)
This kind of analysis is roughly the same as that which
we encountered previously, and the technique of
arranging for some linear combination of the variables
on the left which will be equal to a tractable sum is one
frequently employed. Often, however, recurrence equations will not succumb to such analysis. Consequently,
488
Spring Joint Computer Conference, 1972
another technique frequently called upon is the use of
generating functions. A generating function for a
sequence is an infinite formal power series expansion in
which the coefficient of xn is the nth term in the sequence. Thus, if G(x) is the generating function for
E(n) :
Thus
~ [(I~X) lnC~x)]
= 1+2(1+V2)x+3(1+V2+}i)x2+ •..
=
G(x) =E(1)x+E(2)x2+ .•. +E(n)xn + ...
Furthermore the generating function for nE (n ) is
x(d/dx)G(x) =E(1)x+2E(2)x2+ .... Now using this
fact the recurrence equation (1) can be rewritten in
terms of generating functions as
d
In
I-x
:,y=2~[_1_ln(_1)]
dx ( 1- x)
1- x
_
(1-x)2
2x
(1- x) 2
+
c-2
(
1- x) 2
Looking at E (1), the coefficient of x in G (x) :
E(l) =0=4(1+V2) -2+2(c-2)
:.c=o
d
x dx G(x) = G(2(n-1)) + dx (x 2G(x))
1 (_1_) + 1
(1-x)2
and
n+l1
E(n) =2(n+1)
where
2X2
G(2(n-1)) = (1-x)2
n
=2(n+1)
.
Notice that this equation is in fact an equation involving
infinite power series and thus constitutes an infinite set
of coefficient equations, one for each power of x since
the powers of x are linearly independent. Setting
y=G(x), we have
xy' = [2X2/ (1-x)2J+2xy+x 2y'
y' - [2/ (I-x) Jy=2x/(1-x)3
This differential equation has an integrating factor
exp [-
f C':x) dx] (I-x)'.
=
Thus
(1-x)2y' -2(1-x)y=2x/ (I-x)
Integrating both sides:
y(1-x)2=2( -x- In(l-x)) +c
or
G(x) =y=
(_1_) +
2
In
(1-x)2
I-x
L --: -2(n+1) -2n
i=l ~
c
_ _ ,_2x_
. (1-x)2
(1-x)2
Now
(I~X) In(I~X) =x+ (1+Y2)x'+(1+Y2+Y2)x'+ ...
1
L: -.
~+1
-2n
i=l
as before.
Although in this instance the generating function
solution is somewhat more elaborate than the direct
solution, we took the trouble to illustrate both because
the existence of a direct solution is rather a fortuitous
circumstance. (The example was chosen, in fact,
because both kinds of solution were possible.) The
availability of all of the functional power of infinite
series vastly increases one's flexibility when dealing
with problems of analysis, as may be apparent from
the operations above. Of course, there are a large
number of other approaches to the solution of recurrence and difference equations [cf. References 9, 12,
14, 17].
A final remark is in order regarding the question of
expected performance of graph algorithms. The unfortunate fact is that there seems at present to be no
way effectively to characterize a "random" graph.
The kinds of graphs submitted to graph algorithms
normally have the imprint of human intelligence in
design or at least selection. This imprint is not captured
effectively by choosing a random incidence matrix, for
example, nor by any of the other obvious choices of a
definition of randomness to which one is tempted. The
discovery of a natural and analytically tractable characterization of a random graph remains a major open
question in the analysis of algorithms.
VARIANCE: HOW OFTEN DOES "AVERAGE"
PERFORMANCE OCCUR?
Expected performance is most probable performance,
but for some algorithms actual performance can be a
Analysis of Combinatory Algorithms
highly variable function of input data as we have
noted. Among all of the kinds of analysis to which
algorithms are subjected, analysis of the variance of
performance is unquestionably the most difficult-and
the most often omitted.
There are, however, sometimes legitimate ways in
which to justify omission of computation of the variance. For example, in the case of Quicksort, the extremes of performance occur when the tree is a single
path (i.e., completely unbalanced) and when it is
completely balanced. In the former case, this number
of comparisons is [n(n-I) /2J, while in the latter it is
(n+I) log2(n+I) -2n. Thus, expected performance is
qualitatively the same as best performance, i.e.,
D[ (n) log (n)]. Therefore, even though performance in
the worst case can deteriorate somewhat severely, this
must be a consequence of a long "tail" in the distribution and hence quite unlikely under the hypothesis
of equally likely input permutations.
As a final example, consider the problem of inserting
a new record into a sorted sequence of records. Rather
than adopt the standard "binary search" approach,
however, let us proceed as follows: Given an nth record
to be inserted into a sorted sequence of (n-I) records,
we shall pick a point, i, at random, make a comparison
with the ith record, and thereby determine whether the
new record belongs among the first (i -1) or the last
(n-i+I). (We shall again assume that all key values
are distinct.) We will then repeat the "random probe"
process on the appropriate subsequence and continue
recursively in this way until the proper position for the
new record has been found. Again, let us assume that
the new record is equally likely to belong anywhere in
the sequence-including at the ends. Let p(k, n) ==
prob. that k compares are required to insert an item
into a set of n. Then
p(k, n) =
:t [(!)
i=l
n
By symmetry
2
p(k,n)=
1) (1)
~ p(k-I, n-i)
n
(
n n+I
) Lip(k-I,i-I)
i=l
Setting
00
Gn(x) = ~ p(k, n)xk
k=l
we have
00
[
2
n
]
Gn(x) = L
( 1) Lip(k-I,i-I) Xk
k=l n n+
i=l
It now appears that we are in trouble, for not only do
we have two indices in the recurrence, but, in addition,
the index upon which we based the definition of the
generating function will not help with the factors i or
[1/ n (n+ 1)]. In order to get such assistance, we define
00
F= L Gn(x)yn
n=O
iJ
00
(yF) = ~ nGn_Iyn-l
iJy
n=l
A= -
A
I-y
n=l
Ady
i=l
nyn
= L L iG
l ----=1 y
n=l
00
i=l
li
Ad2y
-
. I-y
( _ i ) p(k-I, i-I)
n+I
+ ( n-i+
n+I
489
i-I -
n
00
n
yn+l
n=l
i=l
n(n+ 1)
= ~ ~ iG i - I --=---
]
where
I/n=prob.that the ith record is chosen
at random
i/(n+I) =prob. that the new record belongs
among the first (i-I), given that
i was chosen
(n-i+I)/(n+I) =prob. that the new record belongs
among the last (n-i), given that
i was chosen
Notice how we have approached, step by step, the form
we wish on the right hand side. Each step utilizes a
standard technique for generating functions, and the
result is very close to what we need; all that is required
is a factor of two and an adjustment of the x and y
indices:
2x
y
II
t [t [:t
A:2y =
1 y
n=l k=l
=F
i=l
2ip(k-I, i-I)] Xk 1 yn
n ( n + 1)
J
490
Spring Joint Computer Conference, 1972
Differentiating:
rence is the occasional emergence of a tractable recurrence involving the derivative of the generating function
itself which enables one to arrive at an expected value
and a variance without ever obtaining a closed form for
the generating function (cf. Reference 12, Vol. I, p. 99),
but this did not happen here.
Pursuing our analysis, we find that
A= l-y ~A
2x ay
1 aA
A ay
2x
(l-y)
A=
2
~ 2x(2x+ 1) ... (2x+n-l)
Gn'(x) = - - - £....J
(n+l) !i=O
2x+i
C
(l-y)2x
=c
t (-2X)
n=O
or
(_y)n
n
n
Gn '(I) =2
where (-~X) is a "generalized" binomial coefficient ll
defined by
(-:X)
~ (-1)' 2x(2x+1) (2X+~ ... (2x+n-l)
.
Therefore, using the fact that G1(x) =X to find c= 1,
a
A= -yF=I+xy+
ay
yF=
n=O
F=
n
n.
and
1 (2x+n-l)
G (x) = n
n+l
.
n
Why go to all this trouble? Observe that
E
co
kp(k, n)xk -
1
•
This means that Gn '(I) = mean (k). Similarly
co
Gn" (x) =
L
n
L k(k-l)p(k, n)x
k-
1
-:--1 - 4
~+
L
n
i=l
(
1
)?
-:--1 .
~+
So, in this instance, average performance is fairly
typical, since the variance is nearly equal to the mean.
By comparison, the "worst case" performance for
this algorithm requires comparison of the new item with
each of the (n-l) others. Thus, here again, there is a
long tail to the distribution. This is not surprising in
light of the close relationship between this procedure
and Quicksort, the precise nature of which we shall
leave to the reader to discover for himself.
As a final. remark, we observe that the factor of
(21n 2) which appears in both the analysis just completed and that of Quicksort is characteristic of binary
tree-based random algorithms. As we have seen, the
technique of basing the course of action of an algorithm
upon operations made on a randomly selected argument
is rather more powerful than might at first be apparent
[cf. Reference 6J.
co
1 (2x+n-l)
L
yn
d
Gn'(x) = dx Gn(x) =
Thus, strangely enough, as n grows larger this
"random probing" insertion requires only about
(2ln 2) or less than 1.4 times as many compares on the
average as does binary search. We shall leave it as a
simple mathematical exercise to complete the computation and verify that
i=1
. n+l
n=O n+l
i=1
variance (k) = 2
(-2X) (_y)n+l
co
L
(2x) (2x+ l)y
y2+ •••
2
1
L -(.~2[ln(n+l) -IJ
~+ 1)
2
n=O
SUMMARY
and
Gn"(I) = variance
(k) - mean
(k) + mean
2(k)
or
variance
(k) = Gn"(I) + G'(I) - [G'(I)]2.
This provides the motivation; when the generating
function is a generating function for a probability distribution, the moment information can be obtained
easily from it as shown. A particularly fortuitous occur-
In this brief space, it has of course been impossible to
do justice to even the nascent field of combinatory
algorithm analysis. We have, however, attempted to
indicate at least in a qualitative way both the types of
information usually sought (and why) and the general
character of the accompanying analysis. By far the
most authoritative single current source in the areas of
performance is the Knuth series,12 but having the
Analysis of Combinatory Algorithms
techniques and ideas in hand, there is a broad range of
more classical literature to which one may turn for
assistance [e.g., References 4,9, 11, 14, 17].
This is an area of very rapid growth. As it matures,
one would expect to see a considerable broadening of
analytic technique, but more important will be (a)
results which increase our understanding of the principles of algorithm design analogous to, but deeper
than, our earlier remark about randomized binary tree
algorithms, and (b) results which broaden the scope
of possible analysis-such as a good definition(s) of a
"random" graph.
REFERENCES
1 FE ALLEN
Program optimization
In Ann Rev Auto Programming V Pergamon Press New
York 1969
2 K E BATCHER
Sorting networks and their applications
AFIPS Proc SJCC 1968 pp 307-314
3 E W DIJKSTRA
A note on two problems in connection with graphs
Num Mathematik I pp 269-711959
4 WFELLER
A n introduction to probability theory and its applications
Vol 1 New York John Wiley and Sons 1950
5 R W FLOYD
Assigning meanings to programs
Proc Symp Appl Math 19 J Schwartz Ed Providence
Rhode Island Amer Math Soc 1967 pp 19-32
6 W D FRAZER A C McKELLAR
Samplesort: A random sampling approach to minimal
storage tree sorting
JACM 173 pp 496-507 July 1970
7 T N HIBBARD
Some combinatorial properties of certain trees with
applications to searching and sorting
JACM 9 pp 13-28 January 1962
8 CAR HOARE
Quicksort
Computer J 5 1962 pp 10-15
9 C JORDAN
Calculus of finite differences
2nd Ed New York Chelsea Pub 1947
10 J C KING
A program verifier
PhD Dissertation Carnegie-Mellon University 1969
11 K KNOPP
Theory and application of infinite series
Blackie and Sons Ltd London 1928
12 D E KNUTH
The art of computer programming
I, II, III 1968 1969 1972 Addison Wesley Reading
Massachusetts
13
Mathematical analysis of algorithms
Proc Cong IFIP-71 To appear
14 L M MILNE-THOMPSON
The calculus of finite differences
London McMillan and Co 1933
15 R C PRIM
Shortest connecting networks and some generalizations
Bell Syst Tech Journal 36 pp 1389-1401 1957
16 E M REINGOLD
Establishing lower bounds on algorithms, a survey
This Proceedings
17 J RIORDAN
A n introduction to combinatorial analysis
New York John Wiley and Sons 1958
18 H R STRONG
Translating recursion equations into flowcharts
J Comp and Syst Sci 5 3 pp 254-285 1971
19 P F WINDLEY
Trees, forests, and rearranging
Computer J 3 2 pp 84-881960
491
On the complexity of proving functions*
by ANDY N. C. KANG
University of California
Rerkeley, California
INTRODUCTION
Let f be a recursive function. We shall be interested in
the following question: given x and y, how difficult is it
to decide whether f(x) =y or f(x) ~y? Since the problem of decidingf(x) =y or f(x) ~y is the same problem
as that of computing the characteristic function Ct of
the graph of f, we can study the above question by
looking into the complexity of computing Ct.
We say that algorithm j serves to prove (or disprove)
f(x) =y if cP/2) ER2 and cPP) computes the characteristic
function, C" of the graph of f and cPP) (x, y) = 1
(cPP) (x, y) =0).
We shall show that the complexity of computing
functions and the complexity of proving them are approximately equal modulo some recursive function h.
Let g and f be recursive functions. We say that "f is
difficult to prove almost everywhere (infinitely often)
modulo g" if every algorithm which computes Ct takes
more than g(x, y) steps to output a 1 for almost all x
(infinitely many x) and all y. We say that "fjs difficult
to disp~ove almost everywhere (infinitely often) modulo
g" if every algorithm which computes Ct takes more
than g(x, y) steps to output a 0 for almost all x (infinitely many x) and at least one y.
Based on these definitions, we prove the following
results: (1) A function is difficult to prove infinitely
often if and only if it is difficult to disprove infinitely
often. (2) There exjsts a function which is difficult to
prove almost everywhere, but, surprisingly, -it is not
difficult to disprove almost everywhere. (3) There
exists a function which is difficult to disprove almost
everywhere, but it is not difficult to prove almost
everywhere.
Before proceeding with our study, we give some preliminaries. Let Rn be the set of recursive functions of
n variables. Let cPO(2), cPl (2), ••• be an acceptable Godel
* Research sponsored by the National Science Foundation,
Grant GJ-70S.
numbering of all the partial recursive functions of two
variables [Ref. 4]. A partial recursive function cJ?/2) ,
the "step counting function," is associated with each
cP/2). The set of partial recursive functions {cJ?/2)} i2!O is
arbitrary save for two axioms:
(1) cP/2) (x, y) converges P cJ?/2) (x, y) converges, and
(2) the function
if cJ?/2) (x, y) =Z
M(~, x, y, z) =
o otherwise
is recursive.
Intuitively cJ?/2) (x, y) represents the amount of time
(or space) used by program i when it finally halts
after receiving inputs x and y.
.
{I
THE COMPLEXITY OF COMPUTING
VERSUS PROVING FUNCTIONS
Definition 1 :
Let fE R
offif
I • cPk(2)
is a characteristic function for the graph
cPk(2)
(x, y)
=
{
I
if f(x) =y
o
if not
We write cPk(2) = C" where Ct is the characteristic
function for the graph of f.
Definition 2:
cJ?k(2) (x, y) is the complexity of algorithm k of disproving f(x) = y if cPk(2) = Ct and cPk(2) (x, y) = O.
Definition 3:
cJ?k(2) (x, y) is the complexity of algorithm k of proving
f(x) = y if cPk(2) = Ct and cPk(2) (x, y) = 1.
The following lemma asserts that the complexity of
computing f(x) and the complexity of proving f(x) =Y
are approximately equal modulo some recursive
function h.
Spring Joint Computer Conference, 1972
494
Let
Lemma 1:
Let <.I> be any complexity measure. Th.ere exist three
functions hE R 3, 'Y E R I , (J ERI such that for any given
P2(k, x, y, z)
=
fERI:
{O<.l>U(k) (x)
(a) If CPi=j, then CP'Y(i)(2)=C, and
otherwise
00
VxVy[f(x)
=y~<.I>'Y(i)(2)(X,
y)
y, <.I>i(X)) J
~h(x,
(b) If CPk(2) = C" then CPu(k) = f and
00
VxVy[f(x)
=y~<.I>u(k) (x) ~h(x,
if <.I>k(2) (x, y) =Z and CPk(2) (x, y) = 1
y, <.I>k(2) (x, y)) J
P2 is recursive, since AXYZ[<.I>k(2) (x, y) =zJ is a recursive
predicate, and CPk(2) (x, y) = 1 implies <.I>u(k) (x) converges.
Define h2(x, y, z) = max{P2(k, x, y, z) I k~x}
Then we have that for all k:
00
VXVy[cpk(2) (x, y) = l~<.I>u(k) (x)
Proof:
(a) Any algorithm to compute f can obviously be
used to obtain an algorithm for proving f. The complexity of the algorithm for proving f is then bounded
by the complexity of the algorithm for computing j.
Formally: let 'Y be a recursive function such that:
I
if CPi(X) converges and CPi(X) =y
CP'Y(i) (2) (x, y) = 0
if CPi(X) converges and cp .• (x) ~y
{
diverge otherwise
If cpi=f,
converges.
CP'Y(i) (2) = C,.
Let
.
PI(2, X, y, z)
then CP'Y(i) (2) is recursive since CPi always
Then CP'Y(i) (2) (x, y) =l~cpi(X) =y, i.e.,
_{<.I>'Y(i)(2) (x, y)
-
if <.I>i(X) =Z and CPi(X) =y
o
otherwise
PI is recursive, since AXZ[i(X) =zJ is a recursive
predicate, and CPi(X) convergent implies 'Y(i) (2) (x, y)
converges.
Define hl(x, y, z) = max{PI(i, x, y, z) I i~x}.
Then we have that for all i:
00
VXVy[cp'Y(i) (2) (x, y)
=l~cpi(X)
CPi(X)
=y~hl(X,
~h2(X,
y, <.I>k(2) (x, y))].
If CPk(2) = C,. Then
00
VxVy[f(x)
=y~<.I>u(k)
(x)
~~(x,
y, <.I>k(2) (x, y))].
h in the lemma is defined by
hex, y, z) = max{hl(x, y, z), h2(x, y, z)}
for all x, y, and z.
Notice that h is independent of the choice of f.
Let (cp, <.1» be the class of multitape Turing machines
with step counting measure. Then the function h of
lemma 1 is roughly given by hex, y, z) ~Z3. This can be
done by a straightforward construction of a Turing
machine.
We will now show that a recursive j exists for which
there is no lower bound on the complexity for proving
f(x) =y. This result basically follows from the speed-up
theorem [Ref. 2J and lemma 1.
Theorem 1:
Let <.I> be any complexity measure. For all r E RI there
is a 0 - 1 valued recursive function f E Rl such that:
converges and
00
Vk(cpk(2) = C, )3j(cpP) = C,) VxVy[f(x)
y, <.I>i(X)) ;;:::<.I>'Y(i)(2) (x, y)].
=y~<.I>k(2) (x,
If CPi = f. Then
y) >r( <.1>/2) (x, y)) J
Prooj:
00
VxVy[f(x)
=y~<.I>'Y(i)(2) (x,
y)
~hl(X,
y, <.I>i(X))].
(b) Given an oracle CPk(2) for the graph of j, a program can compute f by asking questions about CPk(2).
Because the graph of f is single-valued, an affirmative
answer from CPk(2) gives the value of f. Formally: let
(J be a recursive function such that:
CPu(k) (x) = "With input x, compute CPk(2) (x, 0),
CPk(2) (x, 1), ... by dovetailing, until a y appears such
that CPk (2) (x, y) = 1; let the output be y."
If CPk(2) computes C,. Then CPu(k) is recursive and
Without loss generality, we assume r to be monotone
increasing. Let hE R3 be any sufficiently large recursive
function monotone increasing in the third variable
(h need only be large enough to satisfy lemma 1).
Define
r'(x,z) = max{h(x,y,r(h(x,y,z))) ly=O,l}
(1)
By the speed-up theorem, there exists a 0-1 valued
function f E RI such that:
00
VX[CPu(k) (x)
whence CPu(k) = f.
=y~k(2) (x,
y) = l~f(x) =yJ
Vi(cpi=f)3l(CPl=f) VX[i(X) >r' (x, <.I>l(X)) J
(2)
Given CPk(2) = C" it follows from lemma 1 that there
On the Complexity of Proving Functions .
exists an i such that:
and
00
VxVy[f(x) =y~<)\(x) 5:h(x, y, l = f and
00
(4)
VX[i(X) >r'(x, l(X))J
Applying lemma 1 again, we get j = 'Y (l) such that:
4>P)=Cj
495
For example, Rabin's 0-1 valued recursive function f
[Ref. IJ is difficult to compute, hence by lemma 1, f is
difficult to prove. As to the complexity of disproving f:
if y$. to, 1}, then we know immediately that f(x) ~y.
However, if yE to, I}, then f(x) ~y is not easy to
verify; it is easy to show that this must be the case,
i.e., if yE to, 1 J, then to prove f(x) =y or to disprove
f(x) = y is of the same difficulty.
Since functions, like Rabin's 0-1 valued function,
are generally treated as difficult, we have the following
definition for the compJexity of disproving functions.
Definition 5:
and
00
VxVy[f(x) =y~P) (x, y) 5:h(x, y, l(X)) J
(5)
Therefore we have:
00
VxVy[f(x)
=y~h(x,
y, i(X)
(byEq. (3))
>r'(x, l(X))
~h(x,
g(x, y).
The complement of this definition is:
Definition 6:
(by Eq. (4))
y, r(h(x, y, P) (x, y))) J
(by Eq. (5) and
the fact that r is monotone increasing)
This implies that
00
VxVy[f(x)
=y~k(2)(X,
Let g E R 2 , we say that f is "easy to disprove almost
everywhere (infinitely often) modulo g" if some
4>/2) = Ct has the property that for almost all x (infinitely many x) and all y,* f(x)~y~/2)(X,y)5:
y) >r(p) (x, y))J,
since h is monotone increasing in the third variable.
Although the faster program exists, we cannot effectively get such a program. This fact fol1ows from the
theorem in Ref. (3).
THE COMPLEXITY OF PROVING VERSUS
DISPROVING FUNCTIONS
Let g E R 2 , we say that f is "difficult to disprove almost
everywhere (infinitely often) modulo g" if every
4>/2) = Ct has the property that for almost all x (infinitely many x) and some y, f(x) ~y and <1>/2) (x, y) >
g(x, y).
The following theorem asserts that if function f is
difficult to prove infinitely often, then it is also difficult
to disprove infinitely often.
Theorem 2:
Let be any complexity measure. There is an hERa
such that for every step counting function g E R2 and
for all fE R I , if f is difficult to prove infinitely often
modulo Axy[h (x, y, g (x, y) ) J, then f is difficult to disprove infinitely often modulo g.
Proof:
Assume to the contrary that there is a program for
N ext we are going to investigate the complexity for
proving and disproving functions. First we make a
definition.
Definition
4-:
Let gER2,fERI • We say fis "difficult to prove almost
everywhere (infinitely often) modulo g" if every 4>/2)
computing Ct has the property that for almost all
x (infinitely many x) and all y f(x) =y implies
i(2)
(x, y) >g(x, y).
Let f E R I . For each x there is only one y with the
property that y = f(x). Hence it is ambiguous to say
f is difficult or easy to disprove at x, since the complexity of disproving f at x also depends on argument y.
C" which disproves f easily almost everywhere modulo
g,
i.e.,
00
3jO(4)io (2) = Ct ) VxVy[f(x) ~y~jO(2) (x, y) 5:g(x, y)].
(1)
Then we may use this program to construct a program which easily proves f almost everywhere. This
relies on g being a step counting function. With inputs
x and y, our program simply computes g(x, y), then
starts computing the given program 4>i/2) (x, y). When
* If this were "almost all y," then every f would be easy to
disprove almost everywhere.
496
Spring Joint Computer Conference, 1972
x is sufficiently large, if the computation of cl>jo (2) (X, y)
takes more than g(x, y) steps, then we know f(x) =y
immediately. Otherwise cPjo (2) (x, y) takes less than
g(x, y) steps to converge. In that case we can prove or
disprove f(x) =y according to the value of cl>jO(2) (x, y).
N ow we are going to give a formal proof of the above
outline.
Let a be a recursive function such that:
cl>j(x,'u) (2)
if x < lor
(x~landcl>/2)(x,y)
and
cl>a(i,j,l) (2) (x, y) = 1
i(2) (x, y)
converges and
cJ>/2) (x, y)
diverge otherwise
Lemma:
If g = a(io,jo,lo) (2) = Ct.
Proof:
Since cl>io (2) and cl>jo (2) are total, cl>a(io,jo,l) (2) is total. By
Eq. (1) there is a number lo such that for all x and all y,
if x~lo and f(x) ~y, then a(io,jo,lo) (2) computes Ct. End of lemma.
N ow we shall construct the h of the theorem. Define:
p(i, j, l, x, y, z)
o
{o
= /2) (x,
y) =z
otherwise
p is recursive, for if x~l and a(io,jo,lo)(2)(x, y)],
since a(io,jo,lo) (2) is a program that
computes Ct.
Conversely, we can show that if f is difficult to disprove infinitely often, then it is also difficult to prove
infinitely often.
Theorem 3:
Let P) for C, which proves f
easily almost everywhere modulo g, then by definition
this means that for almost all x there is a y such that
f(x) =y and g(x, y), then
f(x) cannot possibly be equal to y.
Theorems 2 and 3 show that a function is difficult to
prove infinitely often if and only if it is difficult to disprove infinitely often.
Naturally, we may ask the question: if f(x) =y is
difficult to prove for almost all x, then does it follow
that for each such x there is a y such that f (x) = y is
also difficult to disprove? This is false by the following
theorem.
Theorem
4:
Let i=a) ¥X[h(x, 0, g(x, 0))]
(1)
The existence of ~x[a(x)] follows from Rabin's theorem
[Ref. 1].
Let cl>io be a fixed program for ~x[a (x) ]. We define
f as follows:f(x): "With input x, first computef(y) for
all y i will be cancelled.) Second compute cl>io (x) .
Case 1: cl>io(X) =0, let the output be O.
On the Complexity of Proving Functions
Case 2: c/>io(X) =1, look for jO=fJ.j[j~x and j is not
cancelled and cf>j(x) ~ 1 + max {h (x, y, g (x, y)) lyE {cf>io
(x) +1, cf>io(X) +2} }.
If no such jo is found, let the output be cf>io (x) + l.
Otherwise, let the output be cf>io(X) +2 if c/>jo(x) =
cf>io(X)+l. Let the output be cf>io(x)+l if c/>jo(x)¢
cf>io (x) + l.
Then cancel c/>jo from the standard list."
Let us see why f works:
(b) We know that for any sufficiently difficult 0-1
function a, a(x) =0 for infinitely many x. From the
construction of f, a(x) =0 imp1ies f(x) =0. We shall
exhibit a program which has the property that it disproves f(x) =y quickly whenever a(x) =0 and y¢O. In
fact, we will define a recursive function b, which does
not depend on f such that b is an upper bound for the
number of steps to disprovef(x) =y whenever a(x) =0
andy¢O.
First we construct c/>u(i,k) (2). We will show that
c/>u(i,k) (2) is the program that disproves f quickly when
k is an index for f and i is io, where c/>io is the program
used in the construction of f.
Let (j be a recursive function such that:
if y = 0 and c/>k (x) converges
if y¢O and
(cf>i(X) >y or c/>i(X) =0
or v ( c/>k (x) converges and
c/>k(X) ¢y))
c/>u(i,k)(2) (x, y) =
if y¢O and cf>i(X) ~y and
c/>i(X) ¢O and c/>k(X) converges and c/>k(X) =y
otherwise
1
diverge
Lemma 4.1:
497
1, u(i,k)(2) (x, y)
~b(x,
y)].
This finishes the proof of part (b).
The proof of part (a) is easier: Let c/>k be any program
which computes f.
Lemma 4.3:
co
VX[h(x,f(x), g(x,f(x)))]
Proof:
Case 1: f(x) =0
(3)
498
Spring Joint Computer Conference, 1972
Assume to the contrary that
00
3X[cJ>k(X) -5:h(x, 0, g(x, 0))]
By the definition of f, we know f(x) =OPh(x, 0, g(x, 0))],
may ask the question: if f is difficult to disprove almost
everywhere, is it also difficult to prove almost everywhere? The answer is again negative by a similar construction of f as in theorem 4.
Theorem 5:
Let cJ> be any complexity measure. There is a function
bE R2 such that for all function g ERa, there exists a
function f ERI with two properties:
f
(a)
if difficult to disprove almost everywhere
modulo g.
(b) f is easy to prove infinitely often modulo b.
by Eq. (1).
Proof/:
Case 2: f(x) rfO.
The proof is similar to that of theorem 4. First we
define a function hI ER 4, the reason we define hI will be
clear later.
Let 0 be a recursive function such that
Assume to the contrary that
00
3x[ cJ>k(X) -5: h (x, I(x), g (x, f(x) ))].
io(x) +1,
cJ>io(X) +2}. Look at the definition of f: there are infinitely many chances for k to be cancelled. Since at
most k programs with index less than k may be cancelled, k(X) -5:h(x, y, cJ>/2) (x, y))]
(4)
CombiningEq. (3) andEq. (4), we have:
"With input x and y. Compute i(X) I
Case 2: k(X)
y, cJ>/2) (x, y))
>h(x, y, g(x, y))].
If follows that:
00
VxVy[f(x) =y~Cf?P) (x, y) >g(x, y)],
since h is monotone increasing in the third variable.
This finishes the proof of part (a).
Let (O, run y steps of io(x) +1, cJ>io(x) +2) D.
Otherwise i(X) =W and
(cJ>/2) (x, 0) -5:z or cJ>P)(x, 1) -5:z)}
o otherwise
hI is recursive, since we can effectively decide whether
(i,j)EA or not. And in case (i,j)EA, cJ>8(i,i) (2) (x, y)
converges.
Lemma 5.1:
00
ViVjVXVY[8(i,i) (2)
(x, y) -5: hI (x, y, cJ>i(X) ,
min {cJ>P) (x, 0), cJ>P) (x, 1) D]
On the Complexity of Proving Functions
Proof:
499
Proof:
Assume to the contrary that: /2) (x, O)::=:; min{cI>/2) (x, 0), <1>/2) (x, I)}
3X[cf>io (x) = 0
or
and
Vy[f(x)
<1>/2) (x, I)::=:; min{/2) (x, 0), <1>/2) (x, I)},
by the definition of A we know that (i,j)EA. Therefore, for all x ~ max {i, j} and all y
[il(i.i) (2) (x, y) ::=:;hl(x, y, i(X) ,
min {/2) (x, 0), <1>/2) (x, 1) }) ].
End of lemma 5.1.
N ow we are going to define f. Let hI be any sufficiently
large function monotone increasing in the fourth variable (hI need only be large enough to satisfy lemma 5.1
above). Let g E R2 be given. Let hE R3 be any sufficiently
large function monotone increasing in the third variable
(h need only be large enough to satisfy lemma 1). Let
AX[a (x) ] be a 0 -1 valued recursive function such that:
00
Vi(cf>i=a)Vx[cI>i(X) >2+ max{g(x, 0), g(x, I)}].
(1)
The existence of Ax[a(x) ] follows from Rabin's theorem
[Ref. 1].
Let cf>io be a fixed program for Ax[a(x)]. We define
f as follows: f(x): "With input x, first compute fey)
for all y i will be cancelled.) Second compute cf>io (x).
Case 1: cf>io(X) =0, let the output be cI>io(x).
Case 2: cf>io(X) = 1, look for jo=p,j[j::=:;x and j is not
cancelled and
.i(x)::=:; max {hex, y, max {hI (x, w, io(X),
uE{O.I}
;;z!=y~cI>io(2)
(x, y) ::=:;g(x, y)]
(2)
From the construction off, we know that 1. Therefore, if we can decide f(x) > 1 in less
than max{g(x, 0), g(x, I)} steps for infinitely many x,
then we can compute 1 or not is to compute 1 in less
than max {g(x, 0), g(x, I)} steps for infinitely many x.
End of lemma 5.2.
Lemma 5.3:
For all sufficiently large x such that i(X, y) >g(x, y)]]
Proof:
Claim:
For all sufficiently large x such that cf>io(X) = 1,
f(x) =y is difficult to prove modulo
wE{O.I}
AX[ max {hl(x, w, iO(X) , max{g(x, 0), g(x, 1) }) }]
max{g(x, 0), g(x, 1) }) }) }]
If no such jo is found, let the output be o. Otherwise,
let the output be 1...!...P)(x,
(a) We will show that for all sufficiently large x,
there exists some y such that f (x) ;;z!= y and <1>/2) (x, y) >
g(x,-y) for every cf>/2) computing Cf.
Lemma 5.2:
>
max {hI (x, w,
y)
io (x),
wE {o.l}
max{g(x, 0), g(x, 1) }) }]]
Proof:
For all sufficiently large x such that k(x)
00
Vj(io(x) =0~3y[f(x);;z!=y
>
max {hex, y, max {hl(x, w, iO(X) ,
yE{O.I}
and
<1>/2) (x, y) >g(x, y)]].
wE{O.I}
max{g(x, 0), g(x, I)})})}]]
(3)
500
Spring Joint Computer Conference, 1972
Since otherwise there is a cPk such that cPk = f and
it is easy to see that cPo(io,io)(2) computes Cj, since cPio
computes C/ and cPio is used in defining f.
Since cPjo (2) is total and cPio (x) = 1 implies that
f(x) E to, 1}. From lemma 5.1 and Eq. (5) above we
have the result that for infinitely many x such that
cPio(X) =1 and for yE to, 1},
00
3X[cPiO(X) = 1
and
cI>k(X)~
max {h(x,y, max {hl(x,w, io (x, 0), jo (x, 0), io (x),
wE {O,l}
max{g(x,O),g(x,l)})
(since hI is monotone increasing in the fourth variable
and either io(X,
y) 5::g(x, y)]]
(5)
We will use cPjo to construct a program which proves
f(x) = y in less than
max {hl(x, w, l and l
and (cI>i(X) >y or (1
and 1 and cPi(X) =0
REFERENCES
~b(x,y)].
Proof:
Let x~ max{i, k}. If y>1 and cPi(X) =0 and
1 by Eq. (1). Hence by
1 M RABIN
Degree of difficulty of computing a function and a partial
ordering on recursive sets
Technical Report No 2 Hebrew University April 1960
2 M BLUM
A machine independent theory of computational complexity
JACM 14 322-336 1967
3 On effective procedure for speeding up algorithms
ACM Symposium on Theory of Computing Marina del
Ray May 1969
4 H ROGERS
Theory of recursive functions and effective computability
McGraw-Hill New York 1967
\
On the structure of Blum measure*
by TSUN S. CHOW
University of California
Berkeley, California
At this point, a natural question to ask is the
following: for every recursive function r, does there
exist a pair of recursive step-counting functions 4>i and
r(x, 4>i(X» for almost all x and
there are no step-counting functions between them?
Corollary will show that, in fact, for all sufficiently
large recursive function r, there can be no such gaps
between any two recursive step-counting functions, or
even any two partial recursive step-counting functions
with same but infinite domain.
The following proposition shows that for any partial
rec~rsive function cf>i there exists another program u,
whlCh computes cf>i but takes slightly more steps than
that required to compute cf>i.
PRELIMIN ARIES
We assume that the reader is familiar with the basic
paper of Blum, 1 and Borodin's paper on the existence
of complexity gaps.2
m is the set of nonnegative integers. ffin is the set of
(total) recursive functions of n variables. CPn is the set
of partial recursive functions of n variables.
The abbreviation "a.e." is used for "almost everywhere." If P(x) is a statement containing the variable
x then AX[P(x)] is a predicate of one variable on m.
The A-notation is also used for functions. The statement
"Ax[P(x)] (a.e.)" means that P(x) is true for all but
finitely many xEm. Similarly, "Axy[P(x,y)] (a.e.)"
means that P(x, y) is true for all but finitely many
pairs of x and y E m. The phrase "for sufficiently large
function f E ffin ... " means "there is abE ffin such that
for allf,f~b (a.e.)=} .... "
The function cf>i is then ith partial recursive function
in a standard enumeration of CP i. A Blum measure
1, ... } is a sequence of functions in CP1 satisfying two axioms:
Proposition
There exist functions u E ffil and hE ffi2 such that for
every i, we have
and
(a) cf>q(i) = cf>i
(b) 4>i(X) q(i) (x) ~h(x, 4>i(X»
a.e. in the domain of cf>i.
1. domain (cf>i) = domain (4)i) for all i Em,
and
2. Ai, x, y[4>i(X) =y] is a recursive predicate.
Proof:
Let u be defined as follows:
As an aid in exposition, we say f is less (greater)
than g, modulo r to mean that rf rg a.e.).
Choose a recursive 1-1 map of the integers onto the
set of all 2-tuples of integers. Let (x, y) denote the
integer which maps onto (x, y).
diverge if cf>i(X)
cf>q(i) (x) =
or
1
cf>i (x)
diverges
4>q(i)(X)~4>i(X)
otherwise
Clearly u is recursive and cf>q(i) = cf>i. Also, for all x in
the domain of cf>i' we have 4>i(X) < q(i) (x)
o
if otherwise
hex, z) = max {p(i, x, z)}
* Research sponsored by the National Science Foundation,
Grant GJ-708
i5,.x
503
504
Spring Joint Computer Conference, 1972
Clearly p is recursive and so is h. Further we have for
almost all x in the domain of cf>i
Corollary:
Proof:
Instead of working directly 'with r, r=cf>i and g, g=cf>h
we choose to work with i) and j). Besides majorizing the recursive
functions, these {i) = domain (cf>j) = W
(b) r(x, u=cf>i
and
(d) h a.e.
For every i, j satisfying (a) and (b) above, we have
that for almost all x in the domain of cf>i
by Proposition (2.1)
by choice of r
by choice of j
u(i) = cf>i
Hence (T (i) is the u desired by the corollary.
"TOP" AND "BOTTOM" OF GAPS
There is another slightly weaker way to talk about
gaps. With hE CR2 fixed, pick a recursive function r much
greater than h. Then we say that" i(X)
(b) y
(c) if i recursive.
(e) if 1)(i,j) (x) ? 1)(i,j) (X») =z] is recursive
(c) if cf>i, cf>j are recursive, then cf>ijCi,j) is recursive and
has the following property:
VkVx?k[I[cf>oCi,j) (x) ~ij(i,j) (x) »]]
Lemma 2 (b) is needed to make the construction of h
in Lemma 4 become recursive.
Lemma 3:
With a as in Lemma 1 and 0 as in Lemma 2, there
exists (T E CR2 such that for every i, j, x
(a) ij(i,j) (x) » converges if and only if
1)(i,j) (x) » ~oCi,j) (x)
»
? g (x)]
and
co
(c) VkVx[h(x, u (x) ]
h is given by Lemma 4. Let recursive function r = cf>i
and g = cf>j be given. We choose u = (T (i, j). Since cf>i, cf>j
recursive imply, by Lemma l(d) and Lemma 2(c),
that o(i,j) are recursive, we conclude, by
Lemma 3 (a), that o(i,j) (x) » for every x.
On the Structure of Blum Measure
Recalling Lemma 1 (b), Lemma 2 (a), and Lemma
1 (a), this implies
cf>i(X) =g(x)
for every x.
This proves (b) of the theorem.
It remains to show that (j (i, j) also satisfies (c) of
the theorem.
Let max{i, j, k}
hex, o(i,i) (X»»
we have
Since h is monotonically increasing on the second variable, this implies
o(i,i) (x)) =z] recursive, we have to
take extra trouble in defining cf>oCi,i) (x).
We first introduce a recursive predicate Q and then
define cf>o(i,j) (x) in terms of Q, such that if Q(i, j, x, z)
is true for some z, then cf>o(i,i) (x) converges.
Q(i, j, x, z) =3y[ (1) o(i,i) (x) »
cf>o(i,i) (x)
by Lemma 2(c)
={
y
otherwise,
where y is the unique integer
such that
o(i,i) (x) »
(*)
Since by Lemma 1 (a) ,
cf>i ( (x, oCi.i) (x) ~ o(i,j) (x)
(x, y») = z
and
By Lemma 2(c), cf>o(i,i) is recursive. Since by Lemma 4,
for x~ max{i,j}:
o(i.i) (x)) =zf-'}Q(i, j, x, z)
and
vwo(i,j) (x) ») = z] is
also recursive. This proves (b) of the lemma.
To prove (c), we assume cf>i and cf>i to be total. By
Lemma 1 (d), we have o(i,i) (x) converges for every x, and so cf>o(i,i) is recursive.
Also, from construction of 0, for every x, cf>o(i,j) (x)
defined implies that
Proof of Lemma 2:
VkVx~k[-'[cf>O(i,i) (x) ~ oCi,j) (x)
Given o(i,i)(X) =y for the least y such that y is greater than
o(i,i) at some x. Hence, in order to make the predicate
Proof of Lemma 3:
cf>i«X, i( (x,
o-(i,j) (x)
0
=
1
diverge
if
(x, cf>o(i,i) (x)) converges
and o(i,i) (x)
a(i) and c!>o(i,i) are partial recursive, (j is recursive. From the definition of (j it is clear that 4>u(i,i) has
the same domain as AX[a(i)( (x, c!>o(i,i> (x) )J and for
every x, 4>u(i,i) (x) exceeds 4>a(i) ( (x, c!>o(i,i) (x) » whenever
the latter converges.
we can show the following lemma:
Lemma:
For every t E(R2 there exist (j E (Rl and hE (R2 such that
for every i, we have:
(a) c!>u(i) = c!>i and
(b) t(x, 4>i(X»<4>u(i) (x) i(X)) a.e. In the
domain of 4>i.
Proof of Lemma 4:
Let a, 0, and (j be as in Lemma 1, 2, 3, respectively.
Let
..
_{4>U(i'i) (x) if 4>a(i) «x, c!>o(i,i) (x) » =Z
PC''', J, x, z) otherwise.
°
By Lemma 3, if 4>a(i) ( (x, c!>o(i,i) (x) » converges then
4>u(i,i> (x) also converges, and by Lemma 2,
Ai, j, x, z[ 4>a(i) ( (x, c!>o(i,i> (x) » = z J
is recursive. Therefore, p is recursive.
Let
h(x,O)=l+ max {p(i,j,x,O)}
i:5,x,i:5,x
and for z>O
h(x,z+l)=l+ max {p(i,j,x,z),h(x,z)}
i$.x,i$.x
= (i) and assume r is greater than h a.e.
(j
CONCLUSION
Besides Borodin's Gap Theorem, we have presented
two other ways to look at the gap phenomenon in the
structure of Blum measure. It is no accident that the
proof of Theorem (Top of the Gap Theorem) is closely
related to that of Borodin's Gap Theorem while the
proof of Theorem (Bottom of the Gap Theorem) is
very similar to that of Corollary. In a way, they explain
why the gap that exists in Borodin's formulation fails
to appear in Corollary. Our main results point out the
existence of an interesting asymmetry in the properties
of step-counting functions.
ACKNOWLEDGMENTS
The author is deeply indebted to Professor M. Blum for
suggesting the topic and close supervision throughout
the whole study, especially in the proof of Theorem
(Top of the Gap Theorem) .
Clearly h has the desired properties.
Theorem (Bottom of the gap theorem)
Let t E(R2 be given. If r E(R2 is sufficiently large, then
for every c!>i there exists u such that:
(a) c!>u=c!>i and
(b) t(x, 4>i(X» <4>u(x) i(X»
domain of c!>i ..
The theorem follows from the Lemma, if we let
U
a.e.
in the
Proof:
By a trivial modification in the proof of Proposition, .
REFERENCES
1 M BLUM
A machine independent theory of computational complexity
JACM 14 pp 322-336 April 1960
2 A BORODIN
Complexity classes of recursive functions and the existence of
complexity gaps
ACM Symposium on the Theory of Computing 1969 pp
67-78
Management information systems, public policy
and social change
by ABE GOTTLIEB
Office of State Planning and Development
Harrisburg, Pennsylvania
I would like to address a few of my remarks to the
character and implications of computer usage in government but before I do so, I might indicate that I'm
with the Pennsylvania Office of State Planning and
Development and my frame of reference has three
outward tracks-as an urban planner, as a participant
in data systems and as an official and sometimes un;..
official stimulator of social change. These three biases
ought to surface in the remarks I am going to make.
State governments as well as national and local ones
are basically concerned with two kinds of computer
uses. The first, and much less important, puts the computer to work at massaging multi-purpose information
that can cover an almost infinite spectrum of urban
oriented subject areas. These have come to be known
as urban information systems. In theory, they can
furnish the planner and decision maker with data and
analyses in land use changes, population and housing
shifts, economic trends, fiscal information and social
statistics for a community or any group of communities.
But computer technology in government plays a
much more critical role than what is inherent in the
operations and outputs of such urban information systems. It is almost a truism today that no public agency,
bureau, commission, board or any other unit of government can operate without some computerized control
of its programs, processes and service delivery capabilities. For example, in Pennsylvania each of the 18
executive departments and most of the commissions
and boards have their own data systems. Many of
these, especially the larger ones, are computerized to
a fairly high level of sophistication. The State Departments of Transportation, Labor and Industry,
Revenue, Education and Public Welfare all have a
tremendous amount of stored information and a commensurate technology to utilize that data.
This kind of operation and use of computers is associated with a relatively new breed called Management
Information Systems. Its focus is the day to day, month
to month control of inventory, bookkeeping, record
keeping, disbursements and receipts in the myriads of
government programs that inter-act with each other
and with many recipients of public services. My concern therefore, is with the Management Information
Systems that are utilized by States and municipalities
throughout the country. These systems exist by virtue
of controlling an inventory or a process and by sometimes delivering a service to public or private recipients.
INFORMATION SYSTEMS AS
MANAGEMENT TOOLS
Now as I get into the substance of my discussion, I
want to explore a number of ideas that relate more
directly to the relationship of these computerized systems to the bureaucracies in which they flourish, to the
formation or paralysis of public policy and to their
impact on the possibilities of social change. Since
these are the central themes around which our discussion will resolve, I will direct my remarks to the following points:
1. Urban data systems and management informa-
tion systems are not merely respositories of facts
and instructions for manipulating them. They
are also collections of technologies as well and if
there ever was any truth to the cliche that the
"medium is the message," I am almost tempted
to make the point that it is really the computer
and its applications that will fashion, modify
and transform our social structure and not the
data that is poured into and out of it.
2. Management information systems at the State,
local and national levels are used to serve management. In Pennsylvania State government as
elsewhere the data systems are designed to assist
in the operation of a Department's or agency's
program more efficiently and perhaps more
507
/
508
Spring Joint Computer Conference, 1972
3.
4.
5.
6.
7.
cheaply than would have been possible under
other arrangements.
Management rationality and efficiency are the
overriding considerations of the "worth" of such
systems. Whether to design, install, enlarge,
merge with other systems or evaluate, the
principal factors are judged to be speed,
thoroughness, cost and labor savings. These are
managerial-administrative considerations and
almost never socially oriented ones. They look
inward to the process, not outward to the consequences.
The programs or process controls which are the
heart of such data systems sometimes result in
services to various segments of the State's population. Sometimes they do not and we will
speak about both situations shortly.
Management information systems that typically
extend such services as auto registrations, tax
notifications and collections, unemployment and
welfare assistance, etc., mayor may not be
necessary or desirable. They can, however,
make little claim to generating, sustaining or
otherwise influencing the direction, depth or
quality of social change in the State.
Any data management system with the capability of mounting substantially greater research
and analytic capabilities. than was previously
possible, can sometimes produce an innovative
breakthrough, a new way of seeing and understanding the dynamics of a community. Conceivably, this might lead to important changes
and realignments in our social, political and
economic structures but. I remain skeptical and
would like to be convinced.
Finally, I feel that if we turned the proposition
the other way around and considered the impact
of currently changing social values on the information systems and their related technologies,
we would get a new dimension to the problem.
If the events, moods and changes that surfaced
in the latter part of the 1960s mean anything
for the coming decades, we can expect major
incursions into the organization, content and
uses or perhaps even selective abandonment of
urban oriented information systems.
THE REACH OF MANAGEMENT
INFORMATION SYSTEMS
N ow before anyone hands in his union card, I would
like to make it clear that while data and management
information systems are rarely the catalysts for social
change, they can and do penetrate to the lives of a
great many people in all segments of our society. This
stems directly from the operations of the record keeping
and process controls that are at the very heart of the
systems. At the State level of government in Pennsylvania such operations probably account for over 90
percent of all computer usage so that it would not be
amiss to say that both the administrators of the
information systems and the machinery itself is
thoroughly committed to keeping the records and controlling the processes. For example, the State Department of Public Education receives a veritable deluge of
data from the local school districts relating to almost
all aspects of running an educational bureaucracy. The
Department of Revenue must maintain a computerized
information system for the calculation, billing, mailing,
recording and analyzing of tax receipts. Similarly, the
information systems of the State Department of Labor
and Industry and the Department of Transportation
(just to name a few of the larger operations) are deeply
committed to the routinized processes of maintaining
a complex unemployment insurance system in the first
case and keeping auto ownership inventories, issuing
licenses and recording accidents in the second.
Basically, therefore, the data systems of the State
work towards the delivery of services to a wide range
of individual residents as well as to local communities
and to other State agencies. There are of course adjacent
and parallel operations such as internal payroll, bookkeeping and property inventory and control that generally do not reach out to any segment of the population. One can easily see the counter-part of these operations at the city, county and township levels as well.
This is, admittedly, a capsule version of the Pennsylvania Management Information System but I think it is
important to appreciate the data areas, the kinds of
controlled operations and a few examples of the services
delivered before we speak about the roles, if any, that
these systems play in social change.
THE LIMITING LIDS ON SOCIAL
INNOVATIONS
You may have noticed that I have deliberately
divorced the objectives and operation of management
information systems from the larger State programs of
which they are part. I admit that this is not quite fair
and that such a division would be a highly artificial
one so I would like to bridge the gap at this point. The
State of Pennsylvania has defined eight broad, long
range objectives toward which it wants to move and
Management Information Systems
had identified several hundred currently operating
programs (many in the social arena) that mayor may
not be reinforcing these objectives. All the data systems
I have been talking about live and operate in some
uneasy relationship to these programs and objectives
and it is these connections that I would like to discuss.
To begin with, the State information systems that
keep records, control processes and deliver some services
in Pennsylvania (and there are almost no other kinds)
are themselves very substantial organizational entities.
The investment in time, professional staff, money
hardware and software and support personnel is quite
considerable and this whole range of activity has gained
structural and administrative solidity in the last few
years. In Pennsylvania and in many other States we
can speak of an information system bureaucracy that
is not without substantial power and influence. Like all
bureaucracies, it does not always look kindly. upon
change inside or outside its own domain; social, managerial or otherwise.
I have also made the point earlier that management
information systems are tools to serve management
which means more precisely to serve administrators
and decision makers in operating programs and process
as efficiently, rapidly and cheaply as possible. Now
while these are the criteria that make the computer so
valuable they are also the criteria that draw the administrator to the narrow focus of the procedural
rationality of his program rather than towards an examination and concern with the impacts and consequences of his acts. In other words, the machine together with its operations, controls and data base induce
the administrator to look inwards to the managerial
objectives of his world when he should be involved with
the political,. social and economic meaning of what he
does. Weare very accustomed to visualize information
systems as devices to facilitate policies and programs
but it seems to me that the feedback (if you will pardon
the expression) might be even more significant than the
initial impulse that is, the systems themselves (singly
and in concert) set the pattern, depth and range of
current and future concerns of the State and many
municipalities. From this point of view, the tail is very
definitely wagging the dog and something is wrong.
I am not intimating that programs made effective
by the use of information systems and process controls
are unimportant or negative accomplishments in the
State. But I am saying that the systems, controls and
processes should not be the measuring rod for the social
and economic interactions between the State and its
residents. Nor should they be (as they almost inevitably become) the determinants that freeze public
policy.
509
CONSTRAINTS ON PUBLIC POLICY
At this point in our discussion, I feel that we are
beginning to zero in on a critical area. Almost at the
outset, I made the observation that social changes
among various groups and segments of our population
can usually be traced to a shift in values, attitudes and
aspirations that arise in these groups and the conviction
that such aspirations can be realized in one's lifetime.
However, to these basic stimulants I would like to add
a second kind of possibility and that is the nature and
scope of public policy.
Under certain circumstances, public policy can translate the values and aspirations of various groups into
attainable benefits. Such policies and programs can
even set off a chain reaction extending into social,
political and economic areas far beyond the point of
initial program impact. It is my contention that what
happens to existing programs and especially the breadth
and vision brought to bear by public administrators in
creating new social objectives will go a long way towards making a management information system responsive to social realities. The field is wide open in
health, criminal justice, education, consumer protection, public welfare, environmental improvement and
others. And it is in these areas and among these kinds
of public efforts that I have some qualified reasons to
be1ieve that the State may become attuned to the explosive social transformations that are sometimes above
and usually just below the surface in the major urban
areas of the State.
However, the obstacles to this kind of sequence are
formidable. To begin with, public policies, objectives
and programs are heavily dependent on what the agency
or the administrator is doing now and doing it with all
the management tools, personnel and investments at
his disposal. Realistically speaking, there is no particular reason to assume that State, city or national management people look forward to gearing themselves,
their program control processes, their machines and
their data to ventures that cannot be justified beyond
running smooth, self-:regulating and almost self-perpetuating operations.
For example, it is with considerable fear and trepidation that many administrators look upon program
evaluations where the focus is on social, educational
and economic consequences, ameliorations ·and status
changes rather than what is expected and dictated by
the flow processes of paper, forms and data. This feeling
is especially acute when the validity of existing programs and sequenced actions are questioned and new
ones might be suggested. The real threat of P.P.B. is
not that cost-effectiveness studies are hard to define
510
Spring Joint Computer Conference, 1972
and difficult to mount (all too true) but that P.P.B.
insists that management and its information systems
clarify and justify their efforts in terms of its impacts
and consequences on all classes and categories of recipients. In the social arenas of criminal justice, poverty, education, housing arid even science aild technology, this begins to get close to tampering with the
cement that holds the structure together and whether
we call it P.P.B. or anything else it is clearly a kind of
opening wedge in that direction.
Therefore, the way I see it two related things must
happen. The first is a willingness for the public policy
makers to realign State and local objectives and programs so that definable improvements are explicitly
built into them and the second a willingness for the
information systems directors to accept new standards,
criteria, data and processes to make this work. It could
be that the policy makers and the information directors
are not always the same people with the same interests
and outlooks on all issues of program and process control. Sometimes they wear the same hat and sometimes
they, don't but it seems reasonable to suppose that
they have been mutually reinforcing each other as
long as information systems have continued to remain
program and management tools. If I were to venture
a guess, I would say that the policy and program
makers are as much locked into the uniquely narrow
perspectives of data, inventory and process control as
are the information systems directors themselves.
I would like to quote from Elizabeth Drew writing in
a publication called "The Public Interest":
SOME PROOF OF THE PUDDING-SOCIAL
INDICATORS
If this is true of the national level and with Federal
programs, it is more than doubly so with the States
and the localities. Our knowledge vacuum is truly an
anomolous situation. It stares us in the face despite
the fact (or more correctly because of the fact) that the
Federal, State and local governments have amassed
and computerized a vast body of statistical information
necessary to run their programs and churn their processes. Paradoxically, while we are inundated in a sea
of paper, ink and printouts, we cannot measure the
human toll of illness, the pollution of the environment,
the quality of our education and the nature of the
alienation expressed in burning and looting in the
ghetto, strife on the campus and crime in the city
streets. From everything I have said up till now, management and its information systems want to have no
part of these "social" changes except perhaps to wish
that they go away.
My theory about management being quite allergic
to social change might be reinforced by a telling fact
about management and here I mean the public agencies,
State, Federal and local that operate in what we have
been calling the social arena. For the brutal fact of the
matter is that· they have shut ourselves off from the
data and intelligence that might tell them just a tiny
bit about the social world around us. In "Towards a
Social Report" of the Department of Health, Education and Welfare we are made painfully a ware of the
fact that "the nation has no comprehensive set of
statistics reflecting social progress or retrogression.
There is no government procedure for stock taking of
the social health of the nation."
Somebody has said this much better than I can and
\
"Those who picture Washington as one mass of
files and computers containing more information
than they would like will be comforted by the experiences of program-planners in attempting to
evaluate on-going programs. Whatever the files
and computers do contain, there is precious little
in them about how many and whom the programs
are reaching, and whether they are doing what
they are supposed to do. If the purpose of an adult .
basic education program is to teach people how to
read and write, the Office of Education might
reasonably be expected to know how many
people thereby actually learned how to read and
write but it does not.... The Public Health
Service might be expected to know whether its
various health services are in fact making people
healthier but it does not. The study of disease
control was to have encompassed more diseases,
but so little was known about the effective treatment of alcoholism and heart disease that these
components had to be dropped. Those working
on the income maintenance study found that the
Welfare Administration could not tell them very
much about the public assistance case load-who
was on welfare, where did they come from, why
were they on it; what they needed in order to get
off·"
Geographic information systems in the U.S.-An overview
by ROBERT AMSTERDAM, EDWARD ANDRESEN and HARRY LIPTON
Office of the Mayor-Office of Administration
New York, New York
graphic Information Systems; these are the Address
Coding Guide/Geographic Base File and the Parcelj
Building File.
A Geographic Information System (GIS) can be
defined as one which is oriented to supplying information pertaining to the geography or spatial relationships
of the information in the system.
When one asks for the total of all school aged children
from a welfare file who are in school district 52 or when
one wants to affix the health area code to a file of birth
or death records, one is involved in relating geographic
descriptors (e.g., the school district and health area
codes which represent finite, fixed areas of space), to
other geographic descriptions (e.g., the address of the
welfare child, the home address of the mother ... etc.).
Information such as the above has only recently
become processable via computer. Heretofore, for a
file of any significant size, large amounts of manual
effort were required in order to enable one to relate one
set of geographic descriptors to another. Now, through
the use of the principal components of a typical Geographic Information System, these files can be related
at computer processing speeds.
The principal components of a typical GIS are:
Address coding guide/geographic base files
These files were first developed in the early 1960's for
regional transportation studies such as the Penn-Jersey
Study in the Philadelphia area and the Tri-State
Transportation Study in the Metropolitan N ew York
area. The files were used in compiling information on
origin and destination of trips by all means of travel
within the study area. The results were used in planning
new transportation routes, determining patterns of
economic and residential growth, and planning for
development of new resources. Comparable files were
developed by private firms for use in market analysis
by commercial organizations. Such files have also been
developed by the Post Office to assist in zipcoding. By
the mid-1960's, the U. S. Bureau of the Census recognized the value of these files in coordinating a mail-out
census and began encouraging their development in all
urban areas of the country. Since then their broad range
of uses has .been increasingly recognized by local
government and groups engaged in analysis of small
area data. The files have been modified, expanded and
updated to meet the demands of local users.
In its basic form, an Address Coding Guide (ACG)
relates ranges of addresses to defined geographic areas.
Most simply, it could contain the range of building
addresses in a traffic zone or postal area. A series of
records is prepared for each street name. Each record
contains the highest and lowest building numbers on
that street which lie within the specific zone. Generally,
separate records are prepared for odd and even house
number ranges.
As Address Coding Guides have developed, it has
been recognized that as more different area designations
are incorporated in the file, the more useful it becomes.
• Geographic information files (GIF) containing all
the geographic descriptors of interest for the
geographic area covered
• A program or set of programs that enable the GIF
to be accessed (matched) against data files and
appropriate geographic descriptor information
appended from the "matched" GIF record to the
"matched" data file record.
• Graphical display programs and equipment which
enable the matched output to be displayed, via
computer, in the form of maps or charts in addition
to the usual listings.
GEOGRAPHIC INFORMATION FILES
Geographic files can encompass the entire range of
local government activities. Two types of files, however,
have played a major role in the development of Geo-
511
512
Spring Joint Computer Conference, 1972
Since many operational jurisdictions (e.g., post office
routes, police precincts, census enumeration districts)
bound whole city blocks, it is usually convenient to
create a separate record for each block side. This record
contains the street name, highest and lowest building
numbers that can be used on that street section, and
whatever area codes can be usefully related to that
block or block side. Additionally, the record can contain
alternate names for that street, the names of intersecting streets, the width of the street, whether it is
paved, the type of paving, whether it is privately or
publicly owned, direction of traffic, speed limit and
other information of general interest
This information can be related to other data files in
order to develop a profile of a community, to coordinate
operational data or to retrieve specific information
contained in the ACG. One significant example of its
use is in relating the number of incidents in an area,
such as number of births, or crime reports, to the
total population in the area in order to calculate the
overall birth rate or crime rate for the community.
Such data is required for many types 0 f community
planning and deployment of facilities.
An important extension of the ACG is the Geographic
Base File (GBF). In a GBF, each record can be the
same as an ACG record but it also includes x and y
coordinates of one or more fixed points on the block
related to a grid system which is uniformly referenced
for the entire locality. The individual record may
contain the coordinates of a corner of the block, the
center of the block, the center of the blockside, the
intersections of the streets bounding the blockside or
some other recognizable point. With this added data,
the location of any block or address is determined with
reference to any other location in the area. This allows
the user to calculate distance, determine the entities
in a given perimeter or radius and make other spatial
determinations. This capability is important in transportation planning, in setting up routes or district lines
and in determining the potential users for a new facility.
Grid coordinates are also valuable in the preparation of
computer-generated maps. Maps are essential in many
local government operations and the ability to produce
detailed maps showing the locations of specific properties or addresses is increasingly playing an important
part in administrative decisions.
As one example of use of the GBF, complaints of
cracks or holes in street paving can be correlated with
street segment identification numbers in the GBF.
When street repair work is scheduled, crews can be
readily informed of all complaints in a compact area so
that minimal time is lost in traveling.
ACG's and GBF's are being used in many local areas
throughout the United States and Canada. They are
also being developed for several major cities in Europe,
Israel and South America. Their development requires a
considerable investment by the locality to check out and
inventory all streets, blocks and significant land features
in their jurisdiction and to update the information as
changes occur. Hovvever these files are critical for the
development of many types of municipal information
systems and operational activities and the effort is
increasingly proving to be justified.
The U. S. Census Bureau is developing a standard
format for these files called DI:\1E (for Dual Independent l\lap Encoding). In a DIlVIE file, each record
is related to a street segment. It identifies the street
name, address range on each side of the segment,
census block on each side of the segment and intersection node coordinates at each end of the segment. 1
Parcel/building files
The second major file important for local area data
collection systems is the Building File. This contains
one record for each building in the region with its
address, dimensions, floor space, usage, owner's name
and whatever additional data the local government
finds useful to maintain.
Traditionally, the source for this data is the property
assessment department. Assessors are required to
maintain a complete inventory of the property in their
district in order to insure that all land is taxed and that
valuations are reviewed and updated periodically to
reflect improvements to the property, improvements to
the neighborhood and changes in market values. In
most parts of the United States assessment is a county
responsibility. Cities lying within a county and metropolitan areas which lie in several counties frequently
have administrative problems in gaining access to
assessors' files.
There have also been technical obstacles to using
this data: Many assessors' files are in detailed, handwritten records which have been accumulated over long
periods of time. Data is not standardized and difficult
decisions must be made on which data can most usefully be converted to computerized form. Another
obstacle has been that assessors usually keep records of
land parcels or lots, since this allows the most complete
inventory of the land in a county. However this makes
it difficult to obtain clear information on individual
buildings when there is more than one building on a lot.
One final problem will be mentioned: it is frequently
impossible to record the owner of a parcel on a compact,
fixed-length field. The property may be owned by a
corporation, a partnership or a group of heirs. For
some operational purposes, it is more important to
Geographic Information Systems
know the name of the mortgage holder, taxpayer or
managing agent. These identities are frequently confused, ambiguous or deliberately concealed by the
owner.
As a result of these and other obstacles, development
of comprehensive building files which can be use d for
inter-agency activities has proceeded slowly. Washington, D.C., and Philadelphia are among east-coast cities
which have developed such files. New York City plans
to have one in use by the spring of 1972. New York's
has been used on a pilot basis to prepare a list of selected
office buildings for use by the Fire Department in
evaluating a new fireproofing code for fully air-conditioned buildings and development work has begun to
use it for estimating population.
In general, the most significant work in this area has
been done in localities which grew up in the days of
electronic data processing. Southern California communities have been particularly outstanding in developing and using Building Files.
Los Angeles County, for example, has had a tapeoriented property records system since 1958 for use by
the Assessor, Tax Collector and County Auditor. The
system contains 1,850,000 records describing every
parcel in the county. Los Angeles County contains 77
cities plus countless water, school and fire districts and
other taxing entities with overlapping jurisdictions such
as are found in most counties. All property tax bills are
calculated by the county. Receipts are distributed to
the local taxing groups based on their particular tax
rates and the amount of taxable property in their
jurisdiction.
The Los Angeles master parcel file contains the
following data: tax block and lot number, which
uniquely identify the property; the address of the
property; the name of up to two owners; the address of
each owner if it differs from the property address; the
land and building dimensions; the tax area codes which
identify the agencies with jurisdiction for that parcel;
zoning classification, use codes, current and prior year
valuations for both land and buildings; history of up to
three last sales prices for the property; homeowner,
veteran and religious exemption codes. In the last two
years the county has been adding more detailed data
describing specifics of construction on the property;
year built, quality, class and shape of building, number
of bedrooms, number of bathrooms, total square feet,
cost of construction, quality of view, presence of mineral
deposits and other data which would help the assessor
in more accurately computing the value of the property.
This data is of great value for functions such as city
planning, renewal and site selection activities. Local
governments are working with the county authorities
to obtain greater access to this wealth of data.
513
Looking into the future a few years, we predict that
building files will be accessed by on-line systems, with
every agency that currently keeps building related
files, having instant access to fields related to their
special areas of interest. Thus, the Fire Department can
develop a history of fires by building and even apartment; the Housing Agency can manipulate data
concerned with elevator inspections, building code
violations and their status by building or apartment,
rent control status by apartment, building and occupancy permits status; the Environment Pollution
Agency can access fields concerned with incinerators,
boilers and so on.
Thus, instead of each agency developing and maintaining its own building file, it can be centrally maintained, and where required, the interagency information
can be readily analyzed for operational and planning
purposes by other than the agency controlling the data
in the field of interest.
In addition to ACG/GBF's and Parcel/Building
Files, several other files may be developed, depending on
local conditions. These could include Alias Street Names
which include alternate names or alternate spellings of
street names in the locality; Familiar Places which
includes places not known by normal address, such as
parks, landmarks, department stores and shopping
centers; Highways which identify limited-access highways in terms of segments; and Boundary (Polygon)
Files. Boundary Files are used to describe the perimeter
of a jurisdiction. They may be organized in terms of the
street intersections which form the boundary of an area,
or, especially if used for automatic mapping, they will
give the (x, y) coordinates of the points which form the
polygon describing the area.
All of these files require considerable effort to develop
and maintain in urban areas which are· complex and
constantly changing. However, as they are used more
widely, more local agencies will participate in their
development and exchange of information.
ACCESSING (l\iATCHING) APPROACHES
ADMATCH
Admatch is a set of address matching programs that
enables a blbckside type of GBF (e.g., ACG, DIME,
etc., file) to be matched against any data file on street
address. This package was originally developed by the
U. S. Bureau of the Census for the New Haven Census
Use project in 1967. It has since been significantly
upgraded and improved.
It consists of a preprocessor and a matcher program
separated by a standard sort program. The preprocessor
514
Spring Joint Computer Conference, 1972
program analyzes the address field of each record to be
matched, identifies the specific components of the
address and places these components into -specific fields
of a record segment called the "match key" which is
appended to the original data record as part of the
preprocessor output record.
For example, the address:
2520 South Flatbush Avenue Extension
Brooklyn, N ew York
would have the address components stored In the
"match key" as follows:
2520
= House number
*South
= Primary directional
Flatbush = Street Name
*Avenue = Primary Street Type
*Extension = Secondary Street Type
*Brooklyn = County
*New York = State
All the * items are first standardized through the use of
tables before being placed in the output record.
The next step in the overall matching procedure is
to sort the preprocessor output file on house number
within odd/even-side of the street parity code within
street name (within county, within state if a multicounty and multi-state file is involved).
The sorted data file is now matched on the "match
key" field against a blockside GBF reference file "match
key" field that has previously been created via preprocessing and sorting as above. The matcher program
compares the data record match key to all the GBF
records with the same street name and selects the
"best match." The "best match" is determined by a
weighting scheme determined by the user. That is,
each component of the address is given a weighted
value and thus each component that matches, or in the
case of house number, falls within the high-low blockside range of house numbers gets the weighted value
added to its total weighted score. Thus, a record can be
accepted as "matching" even though each address
component does not match identically with the
"matched" GBF record.
Admatch is available in IBM 360 DOS and OS and
RCA Spector 70 versions, at a nominal fee ($60) from
the Bureau of the Census. Over 100 municipalities and
regional entities are using this package. The package
requires a minimum of 32K bytes of magnetic core to
run under DOS.
In Charlotte, North Carolina, a file of 35,000 sewer
connection records were put into machine readable form
and via Admatch, matched against a master water
billing file and a master sewer billing file. Seventy-five
percent of these records matched at a 98 percent
acceptance level. The balance of the man-matched
records were then manually processed. Of these, 10
percent were true non-matches, that is, they had sewer
connections but were never billed for water and/or
sewer services. This resulted in considerable additional
yearly revenue for Charlotte.
In the Los Angeles area, both the City of Los AngeJes
and the Census Bureau's Southern California Regional
Information Study (SCRIS) have been making extensive use of Admatch.
Building Permit information has had Census Tract
and Block numbers added to it. This has been done for
every year since 1960. It enables one to ascertain the
yearly growth of the housing stock and via the housing
stock, an estimation of the population growth.
Motor Vehicle applications have been coded with
Census tracts and blocks via Admatch. This enables
transportation planners to get an accurate fix as to
where the vehicle owners are located.
Orange County, California has used Admatch to
code housing inspection reports with census tract and
block codes. This is used to analyze the quality of
housing stock in the various geographic areas of the
county.
UNIMATCH
The Bureau of the Census is currently developing this
package which, in essence, is a generalized file linkage
system. It is structurally similar to ADMATCH,
however, not only will it match on street addresses, but
also on street intersections, major traffic generators or
any other logical connection. This generality is achieved
by allowing the user to specify what fields to compare,
what comparisons to make, what significance to attach
to a success or failure to compare and finally what
action to take depending on the level of success of
that comparison.
STREET ADDRESS MATCHING SYSTEM
(SAMS)
SAMS is a proprietary package of Urban Data
Processing, Inc. of Cambridge, Massachusetts that
matches addresses in a fashion similar to Admatch.
This may not be too surprising since the authors of
SAMS were involved in the development of the original
Admatch package. SAMS processing, like Admatch,
consists of a preprocessor run, a sort on the house
number and street name, and a match against a
similarly processed GBF.
SAMS operates under IBJVI 360 DOS and OS oper-
Geographic Information Systems
ating systems with a minimum of 96K bytes of core
storage.
The City of New York (our home town) has used
SAMS for numerous address matching applications. In
one very dramatic application, we were able to match
the Department of Social Services Welfare Recipient
file to the G BF and affix the census tract and block
number to 95 percent of the records. The Board of
Education then used the file to determine the school
district of each welfare recipient between the ages of 5
and 18. This was ultimately used to satisfy both the
Federal Government and community school boards in
the allocation of federal free lunch money to the school
districts based upon the percentage of school children
qualified for this program and not on a simple percentage of school children in each school district. With
over 1,000,000 school children and over 300,000 of
these qualified for the free lunch program via their
welfare status, one can readily see the difficulty in
performing this analysis any other way.
Work is under way to use SAMS to automatically
code each birth and death record with the health area
and district of the person's home address. This will
eliminate a time consuming and somewhat inaccurate
current clerical effort. Plans are also under way to use
SAMS to add all the various types of geographic
descriptors to the citywide building file we are creating.
The building file, which contains the key dimensions
and building classifications of each building in the city
can be used for population estimation. Couple this with
the geographic description, and one can then readily
estimate population by specific census tracts, health
areas, school districts, ... etc., for a multitude of
planning activities.
OTHER BATCH PROCESSING ADDRESS
MATCHING. PROGRAMS
Kettering, Ohio, has developed an Admatch type
package that operates on an IBM 1130; They have
.utilized it to code and analyze health data by various
geographic descriptors.
Raymond Soller of Florida State 1Jniversity has
developed an Admatch type package for the CDC 3600
which may be available to other CDC users.
REAL TIME ADDRESS MATCHING
A number of real time address matching systems
exist. They tend to differ based upon the amount of
conversation one wishes to accept between the terminal
operator and the system and the average amount of
515
time, during peak load conditions, that one is willing to
wait in order to find the address in question. Generally
speaking, the less conversation between the system and
the operator and the faster the access required, the more
expensive the system in terms of programming and file
storage.
In Chicago, building code violation complaints are
being entered on-line via terminals. The street name is
first converted to a standard street number code. The
house number is then used with the street code to
access the file. In N ew York City, the Police Department· has installed a system, SPRINT, which enables
telephone operators to enter the request for emergency
help, including the house number or the street intersection into the system via CRT type terminals. The
system analyzes the address portion of the message and
finds the blockside record which either:
(a) contains the house number within its high-low
address range or
(b) is adjacent to the intersection.
Finding the matching blockside record enables the
system to then determine:
(1) the police precinct and sector for that blockside
(2) the police car(s) nearest the precinct and sector
that are free
and to flash the original message and the police car
availability message to a radio dispatcher who in turn
broadcasts a dispatching message to the police car(s)
he selects to assign to the call. It should be noted that
the SPRINT address file was built from the same base
file that was used to create New York City's GBF.
This illustrates that a GBF can support both batch
processing and real time operating systems.
ACCESSING OTHER GEOGRAPHIC
DESCRIPTORS POINT-IN-THE-POLYGON
ACCESSING
This approach requires that a file be develcped which
represents, in essence, polygons for the specific geographic descriptor of interest. That is, the extreme
(X, Y) coordinate sets for each vertex of an area, say a
health area, are recorded as a specific polygon. This is
done for every health area in the system. Then, given
the (X, Y) values fora specific item of interest, say a
birth, one can determine, through the use of a point-inthe-polygon algorithm which polygon, and thus which
health area, the item falls in. Tulsa, Oklahoma, has
used this approach in a real-time system to determine
which police district a specific address lies in, so that it
can dispatch the proper police car to the scene.
516
Spring Joint Computer Conference, 1972
MULTI-INDEX GEOGRAPHIC FILES
Kettering, Ohio, has developed a multi-indexed
geographic information system which enables one to
access their 22,200 record parcel file by (a) plat, section,
and lot code; (b) tract, block and parcel\ number code;
or (c) book, page and index code in addition to the
parcel's address. A series of index files for each of these
access items has been developed to support this capability. This system has been used by their Planning
Division to obtain building and land valuations on
proposed zoning changes and to analyze the parcel file
to determine the existence of non-conforming land uses.
COMPUTER GRAPHICS
In this section we confine the broad subject of computer graphics to the aggregation, analysis, reformatting ~d graphic display via computers for the
support of urban planning in all its facets.
In almost all instances, government use of computer
graphics has taken the form of producing maps or map
representations at various scales and, most important,
the insertion into these maps of the aggregation and
factor analysis of data in varied formats.
To focus more sharply on our topic let us glance at
some classes of data displays as they have appeared on
maps used by government urban planners.
available by the growing world of computers, the
planner, to avoid being buried or immobilized, must be
supported by distilled data in the form of computer
reports or graphic displays or, most likely, a combination of both.
The need of a combination of maps and specific data
was proven, and was used by military, navigational,
and government planners thousands of years ago. Today
the fantastic growth in available planning data and the
volatile nature of today's world will force further
sophistication and use of computer-driven graphic
displays.
N ow let's take a look at the classes and specific types
of computer-driven graphics currently in use by
government at various levels.
HIGH-SPEED PRINTERS
First and currently most widely developed and used
are high-speed printers which use the characters of the
mFir'4Hi~:!TTF;;fi>'~
HEAL TH
FiHEFi!~i
1. Specific quantitative data by volume, capacity or
total incidence represented on the map by
shading and/or specific numbers.
2. Exception type data resulting from the comparison of two quantities, such as surplusses or
deficits of various resources.
3. Time oriented data which focus on trend
analysis or the comparison of specific resources
at two or more points of time.
It might be well at this point to remind ourselves
that there is a considerable difference between an
information system supporting an administrative
process such as invoicing, payroll or tax collection, and
one designed to. support any planning or programming
activity. In the first instance the system must handle
data by individual documents or transactions. The
planner, however, is concerned with data behavioral
patterns, trend analysis of many types, simulations or
model studies. All of these demand the aggregation of
information from many diverse scmrces, such as the
Bureau of the Census, Housing and Development
Authority, or the tax assessor's records-and perhaps
the total incidence of police or fire calls, welfare cases
and so on.
With the increasing mountain of data being made
Figure I-Manhattan Health Areas-Shading is proportional to
number of public assistance cases-SYMAP-Conformal option
Geographic Information Systems
printer and overprints of characters to produce various
levels and densities of shading to illustrate data on
areas representing map areas. Since lines cannot be
drawn on this type of map, boundaries of areas can
only be approximated. These approximations, however,
are often adequate for planning support. In addition to
shading, specific data values can be shown for certain
points on the map.
The two mapping programs using high-speed printers
that are in most common use by governmental planners
are "SYMAP" and "GRIDS."
SYMAP is the best known, most comprehensive, and
most widely used computer mapping program currently
available. It uses a standard high-speed printer to print
typewriter-like characters, on a standard 11 X 15-inch
computer printout sheet. Lines can be roughly approximated with printer characters, and areas can be shaded
with up to 10 progressively darker shades. The darkest
shades are created by overprinting two or more printer
characters.
The original SYMAP program was written in 1963
under the direction of Howard Fisher at Northwestern
University. The program is currently being maintained
by the Harvard Laboratory for Computer Graphics,
where it is supported by a technical staff, ongoing
research, and teaching materials such as correspondence
courses and seminars.
Figure 2-0utpatient residence distribution for Montefiore
Hospital by Bronx health areas-SYMAP-Conformal
option
517
Figure 3-Ratio of shelters to daytime population in
Long Island City-SYMAP-Contour option
Generally, SYMAP has been programmed for the
larger scale IBM systems, although modifications of
SYMAP have been used on other computer vendors'
large scale computers.
SYMAP enables three basic types of maps to be
produced through its three primary options: the conformal option, where the areas shaded are approximate
representations of the polygonal geographic areas that
they represent; the contour option, where the data
values are assigned to particular points (such as block
face centers or block or tract centroids) and the program
shades contours by establishing equal-width intervals
representing the range of values between each pair of
points; and the proximal option, where the data values
are again assigned to particular points and the. program
shades the respective values from each point to an
imaginary line equidistant between each pair of adj acent points.
In Conformal (see Figures one and two), the areas
shaded represent the actual areas which the data values
represent. In Contour (see Figures three and four) 2,
the areas shaded represent equal-width intervals
between the centroids of the data areas. For example,
between the centroid of the area with data value six
and the centroid of the. area with data value four, three
equal-width intervals have been established representing data values six, five and four. In Proximal, the
areas shaded are represented by imaginary polygons
whose boundaries are described as equidistant from the
centroids of the actual data areas. For example, the
518
Spring Joint Computer Conference, 1972
,. .-.,- . .- . ,. . . - . - . . . .- . . - . . . .- . - . . -.,- -. - . - . . . . . . . . . . . . . . . .- . . .- . . . . . . . . . . . . . . . . . . .- . . .- - - .- . . .-.. . ·. -··-· -. -.·- . ·-·-. --·---1
I
I
Ii
I,
\i
Ii
[
i
I
I
I
I
I
\
\
I
I
I
I
I
-;;~:;!!":::---::"
I
NE
It.
~.~
H R I.) E to(. C D
\
\
I
t·~
N.
. .......... ,_., .............
.1"
Figure 4-SYMAP shading map showing contour levels-Density
of preschool children
boundaries of the imaginary polygon describing data
value two are equidistant from the centroid of the actual
data area for two and the centroids of the surrounding
actual data areas.
In addition, SYMAP has a large number of statisticalsupport options which permit calculations of means,
standard deviations, histograms, and percentile
groups-all within the same mapping program package.
Within the SYMAP system, changing from one type
of map using one mapping option to another type of
map is not easy. For instance, switching from a map
using irregular polygon areas, as in conformal block
shading, to a map using single data points, as in contour
shading, requires the input of a completely rearranged
geographic data base.
"GRIDS" (Grid Relat~d Information Display
System) produces maps by dividing the area to be
mapped into a network of rectangular grid cells. A grid
cell may be as small as one printed character or as large
as 55 X 55 characters.
The system was developed by the Census Bureau's
Southern California Regional Information Study in an
effort to simplify required programming skills and data
preparation.
GRIDS is very flexible both in digesting input data
and producing maps. There are three types of maps
available: (1) shaded, in which data values are represented by overprinted characters of varying darkness;
(2) density, in which a character is splattered randomly
throughout each grid cell with more characters representing higher values; (3) value, in which the actual
data value is printed in each grid cell.
GRIDS accepts as many as 10 input variables to be
mapped, provides for manipulation of the data in any
desired way, and produces up to five different maps for
each run. No previous preparation of the data is necessary and no knowledge of the data values is necessary.
GRIDS provides for data manipulation through
MAPTRAN, a built-in FORTRAN-like programming
language, or a user exit routine if necessary.
GRIDS is especially easy to use because all specifications are free format keyword type and there are many
default values for the user with simple needs.
The program will run on nearly any system with a
FORTRAN Compiler. It has been run on an IBM
360-30 with 32K bytes of storage.
Among the most published users of line printers and
SYMAP for graphical display programs is the U. S.
Census Bureau. They have used both census related
data and locally obtainable data to perform comparisons
and display of results such as Densities of Populations
of Preschool Children, and Hour's Spent by Visiting
Nurses (Figures four and fi:ve).2
The University of Kansas, at Wichita, has experimented with line printer graphics' at the block level
using SYMAP, to display correlated data of land value
f-------·--·..
I
.. -_ ..•....,.._- ........_-_._ .. _...•. _... _...............- .....,.....-..•......•....._....
-_._-----,
: : :1
: :\
:\
''':'':''':':::::'''mm:mH·.\
.
·1
: :\
\
: :\
i
. . .I
\
:\
\
\
I
1. __
I
:- ~- c
I ·N E ~.~
H R I.}E N. C D N
L.~.~_.~~. _.~.~.--.:.. . ._·.~.:._..,
\
t·t
Figure 5~SYMAP shading map showing grid cell levelsAdjusted hours spent by visiting nurses association
I
I
I
I
I
Geographic Information Systems
519
by block area. This is different from Census Bureau
studies which are predominantly oriented to aggregations at the tract level.
N ew York City has made extensive use of SYMAP
capabilities to analyze and display a variety of City
problems, including air pollution, health statistics and
public assistance cases. It has also been used in conjunction with a" highly sophisticated emergency preparedness display system.
The Battelle Memorial Institute is using SYMAP in
conjunction with their pollution research efforts. These
include studies that determine patterns of waste-water
discharges from industrial and municipal operations
Figure 7-Pen plotter tract outline map showing incidence
occurrence-U nder-weigh t births
flatbed models on which the pen is moved over a flat
sheet of paper in both the X and Y direction.
Later, California Computer Products, Inc. (CAL
COMP) and the Benson-Lehner Corporation developed
Figure 6-Pen plotter tract outline map showing tract levelsPercent non-white
and to evaluate their effects on surrounding waters.
The research technique, developed by Battelle, consists
of collecting aerial infrared and tracer dye imagery of
surface water discharges. Data recorded from the
infrared imager is processed and a high-speed printer
then prints out isothermal plots, density plots, and
contour plots. The contour plots provide two different
views. Used with a stereoscope, these two views provide
simulated three-dimensional temperature contours.
PEN PLOTTERS physically move a pen over a
piece of paper, under program control, to produce a
graphic output. Examples of graphics produced by
these plotters are shown in Figures six, seven and eight. 2
The first mechanical computer-driven pen plotters were
Figure 8-Pen plotter outline map of Northwestern New Haven
520
Spring Joint Computer Conference, 1972
drum plotters which move the pen to obtain one direction and the paper to obtain the other.
An important difference in plotters is the manner in
which the movement of the pen is controlled.
Analog Plotting Systems convert the (X, Y) distance
through which the pen must be moved to a voltage or
other electrical measurement which in turn is used to
drive motors through a proportional number of turns
to reposition the pen. Thus the digital input is converted to a specific distance or analog value.
Digital Incremental Plotting Systems drive the pen
(and the paper, in the case of drum plotters) on a quite
different principle. The drive mechanisms on these
machines operate in discrete steps, or increments. The
step size is usually 0.005 or 0.010 inch, or the metric
equivalent to the nearest tenth of a millimeter. Socalled step motors control these motions. The step
motors can make from two hundred (on the slowest
plotters) to about sixteen or eighteen hundred (on the
fastest) steps per second for a corresponding plotting
speed of between two and eighteen inches per second.
The input to the step motors comes from the magnetic
tape or computer to which the plotter is attached. This
input, under program control, specifies the exact
number of steps through which the motors are to move.
There is thus no conversion from digital to analog
values. At anyone time the program preparing input
for the plotter "knows" the exact location of the pen,
and thus, even after drawing thousands of lines on the
paper the pen can return to the exact starting point.
There is another important difference between the
analog and the incremental plotters. On the former the
regular pen is useful for drawing lines, and can draw
them quickly once set into motion; but the line-drawing
pen is very slow if used to annotate the plot with
numbers or letters. Hence, many analog plotters have a
separate device, which may ride on the same arm as the
regular pen or on a separate one and which is used
exclusively for annotating the plot. The mechanism
usually consists of a type wheel set in a vertical plane,
which is rotated to bring each desired character next to
the paper and then forced down to make its impression
on the plot through a ribbon. The process is slow and
cumbersome. Such a character-printing turret can
increase the price of the plotter by several thousand
dollars. Moreover, the size of the characters is fixed,
and they can be placed on the plot only in one or at
most two orientations.
On the incremental plotters the same pen mechanism
that draws Jines is also used to perform all desired
annotation. Only with such plotters is it usually practical
to do extensive annotating on a plot. The characters
can be made in any size, at any desired orientation, and
they may be of any kind, subject only to the symbol
table built into the computer programs used to create
the plot.
The New Haven Census Use study was an early
user of a GBF and SYMAP to plot census data. This
was done to show comparisons of data at the Census
Tract level, with distinctly drawn tract boundary lines,
such as percent of non-white to white populations
throughout New Haven, Connecticut (Figure six).2
The Santa Clara County (Cal.) Planning Department has developed a census tract polygon base fi]e
which they have been using with a pen plotter to
graphically depict employment, population and housing
data by Census tracts within the county. They are also
using their pen plotter to prepare map overlays, which
Figure 9-Geo-space plotter map showing blocks of
lower Manhattan
Geographic Information Systems
521
correspond to county base maps with a high degree of
resolution, to illustrate census tract level information
in conjunction with block level street maps.
New York City, as part of a voter redistricting
demonstration project, prepared a block map of a
section of the City which indicated the number of
registered voters at the approximate location of their
house on the block.
CATHODE RAY TUBE (CRT) PLOTTERS most
likely will show the/greatest advancement in computer
graphics in the next few years. As most of us know, a
cathode ray tube (CRT) is a display device similar to a
television picture tube for which programs are written
to control the generation of displays on the face. of the
tube. These images can be observed, recorded on
microfilm for permanent storage or recorded on photosensitive paper which can be developed into distributable hard copy.
There are a number of CRT based scanrnng and
plotting devices currently in the research and development stage and under intensive study by various
branches of the government.
Although some of these projects offer the possibility
of significant advances in computer graphics, conclusions that would be useful to you do not yet exist.
We will confine our discussion, therefore, to hardware
and systems that have given at least limited support to
government planners.
Figure lO-Geo-Space plotter shading map identifying block area
levels percent of owner occupied housing
Figure 11 ~Geo-Space plotter outline map showing
incidence occurrence-Police calls
The Geo-Space Plotter produced by the Geo-Space
Corporation of Houston, Texas is a digital CRT drum
plotter that will produce map and data representations
on up to 40"X60" film or photo sensitive paper.
Figures 9, 10 and 11 illustrate maps drawn by this
device (Figures 10 and 11). 2
The Geo-Space uses a cathode ray tube and a lens
assembly which focuses its rayon the film or paper.
The CRT and lens assembly are housed in a tube that
can be moved horizontally 40 inches. The media (paper
or film) is attached to a drum large enough to hold a
sheet sixty inches long. The arrangement is analogous
to a drum pen plotter with the CRT and lens replacing
the pen.
The Geo-Space is designed for on-line operation with
a digital computer and is available with the channel
interface for several different computers. Information
to be plotted is developed within the digital computer
central processing unit and stored in a prescribed format
in core storage, or disk storage. The information to be
plotted is then transferred from the on-line storage
device to the plotter for display.
Plotting can be accomplished at 32 levels of intensity.
A plot of 40 by 60 inches can be completed in less than
two minutes regardless of the amount of data to be
plotted. This rate is many, many times faster than the
fastest mechanical plotters.
522
Spring Joint Computer Conference, 1972
data comparisons and display of Census data on a
"Geo-Space" CRT plotter. They are also preparing
state and county outlines for use throughout the
United States. Previous use of Geo-Space equipment was
performed during the New Haven Census Use Study.
The United States Army Map Service, in conjunction
with IBM, is developing software for use with IBM's
Multipurpose Digitizer/Plotter. This work has been
primarily concerned with automated cartography;
however, the equipment and software developed
appears to have direct applicability to urban data users.
A frequent need in planning operations is to determine
where a pattern or a concentration of a particular
activity is occurring. New York City, using a GeoSpace plotter, has prepared a block map of Manhattan,
indicating where high valued real estate changed hands.
This provided a good indicator of the areas where new
building activity is likely to be concentrated and where
new utilities and support services will be needed.
TYPICAL GIS PROCESSING
DENSITY
:'~TRIBUT10N
Figure 12-Typical use of GIS programs
The software support supplied by Geo-Space is a
program called ALPACA which uses FORTRAN
subroutines to perform character generation, generate
lines and circles and control the operation of the plotter.
I t might be timely to remind ourselves that each
computer driven plotter, including the Geo-Space,
requires the user to develop the programs needed to edit
and to reformat the data to be displayed in the array or
sequence demanded by the plotter under consideration.
In the case of Geo-Space, the data to be plotted
must be manipulated within core on a large computer
or retrieved from a disk on smaller computers to enable
the plotter to produce 2-inch wide strips up to 60
inches long and then produce the adjacent 2-inch strip
until the entire sheet (up to 40 inches wide) has been
completed.
SCRIS (Southern California Regional Information
Study) is currently developing user software to facilitate
Figure 12 is a system flowchart that illustrates the
typical processing one may go through in utilizing the
principal components of a GIS.
SUMMARY
Geographic Information System development and
application is proceeding at a rapidly accelerating pace.
We envision a continuance of this over the foreseeable
future as improved files get built, as more files are put
on-line with more sophisticated accessing schemes, and
as these systems become more and more involved with
operational as well as planning type applications.
REFERENCES
1 The DIME geocoding system
U S Bureau of the Census
Washington D C 1970
2 Computer mapping
U S Bureau of the Census
Washington D C 1969
Census Use Study
Census Use Study Report No 2
UNIMATCH-A computer system for generalized
record linkage under conditions of
uncertainty
by MATTHEW A. JARO
U.S. Bureau of the Census
Washington, D.C.
causes the reference file to be advanced by one record.
In this case, the domain of the candidate records on
the reference file is one, since a single reference file
record is a prospective match candidate for each data
file record (it is assumed that the key numbers are
unique in this example).
INTRODUCTION
The Census Use Study of the Bureau of the Census is
planning to release a computer program package to the
general public providing a generalized record linkage
capability, under the name of UNIlV[ATCH (for
UNI versal MATCHer).
For the purposes of this paper, record linkage may
be defined as the process of examining each record
independently on a data file, and comparing information with a domain of records on a second file, which
will henceforth be referred to as the reference file,
according to pre-determined comparison criteria with
the object of selecting a unique record on the reference
file that maximally meets or exceeds the criteria (if
such a record exists), and transferring (or linking)
information from the selected reference file record (if
any) to the data file record.
If a unique reference file record is successfully obtained for a given data file record, that data file record is considered to be accepted (or matched), and the
transfer of information from the reference file to the
data file can occur. If no un:que reference file record
is obtained, the data file record in question is considered to be rejected (or nonmatched), and no linkage
of information will transpire.
The most rudimentary example of the record linkage
process is the file update problem, where a master
data file is e{Camined sequentially, and a key field
(such as a record control number) is compared with
an identical field on the transaction update file (the
reference file). If the fields match, information is transferred from the reference file to the data file, thereby
updating the master record. If the fields do not match,
the data file is advanced to the next record with no
data transfer occurring. The reference file is sorted by
the key field, and every equal or high comparison
CRITICAL FIELDS AND CANDIDACY D01V[AIN
Any key field where an exact match is necessary
before any further comparisons or data transfer can
be considered will be referred to as a critical field. It
follows then, that a mis-match on any critical field is
sufficient to cause the rejection of the data record.
Matches (successful comparisons) on all critical fields
are necessary (but often, not sufficient) conditions to
cause the acceptance of a data file record.
Critical fields serve to limit the domain of reference
file candidacy. If no critical fields are defined for a
record linkage application, the entire reference file
must be examined for each data file record. This
universal domain will provide the greatest potential
for a high match rate, but is often prohibitively expensive in terms of execution efficiency, and generally
does not provide a sufficient cost/benefit for a real
application. The total number of records that must
be examined by the system in a universal domain application is the product of the number of data file
records and the number of reference file records, added
to the number of data file records, so that large files
~~ill require a considerable number of comparisons.
The number of records that must be examinea in
the other extreme, where the reference file candidacy
domain is limited to one record (as in the file update
example), is equal to the sum of the number of data
file records and the number of reference file records.
523
524
Spring Joint Computer Conference, 1972
In this case, the selectivity of the system is nearly
zero, since at most only one record is considered for
candidacy. For this reason, a match on critical fields
only will provide the least potential for a high match
rate.
The reference file domain of a real application can
be determined by weighing the reliability gained by
increasing the domain against the resultant cost increase. Let the average domain be defined as the number of reference file records accepted as match candidates for the average data record. The average domain
can be computed by first summing the number of
candidates for each data record. If a data record does
not match on all critical fields, the number of candidates is considered to be zero. If a data record does
match on all critical fields, the number of candidates
is equal to the number of reference file records having
identical critical field values. The final sum can be
divided by the number of data records read, yielding
the average domain. The average domain ranges from
zero (if no data record matches any reference file
record on all critical fields) to the number of reference
file records (if the entire reference file becomes the
domain because of the omission of critical field comparisons). The average domain is not meaningful if
all comparisons are critical field comparisons (that is,
there are no probabilistic or weighted comparisons),
since the result of the match is based only upon the
values of the critical field keys, and additional reference
file records bearing the same key values need not be
examined. In the file update problem, for example,
where the only comparisons made are key field comparisons, no additional information will be obtained
by reading all reference file records having the same
key values. In fact, such applications generally require
that the key numbers be unique.
THE COST OF A RECORD LINKAGE
APPLICATION
The cost of an individual record linkage application
can be computed as follows:
Cost=n·Cn+m·Cm+max(n,m) .
Ce+D·n·Cd+f·n·Ct+H
(1)
where:
n = number of data file records read
m = number of reference file records read. All
the reference file records on the file will
not be read if the reference file contains
critical field key data values that are greater
than any found on the data file.
Cn = cost of reading and writing one data file
record.
C m= cost of reading one reference file record
from original data set.
C e= cost of comparing the critical fields. This
cost is an average cost, since the highest
level critical fie~d mis-match terminates
the comparison algorithm.
D = average domain. The number of reference
file records accepted as match candidates
for the average data file record.
Cd = cost of comparing all non-critical fields for
one data record with one reference fi Ie
record within the domain.
f = the fraction of the file that
be matched
(successfully linked).
C t = cost of linking one reference file record to
one data file record. This is an average cost
based on the number of co mparisons and
lengths of strings to be moved.
H = system overhead.
,,,ill
The cost of comparing all non-critical fields for one
data record with one reference file record within the
domain (Cd), which is the most complex factor in
equation (1), may be computed as follows:
g
Cd=g·(Cz+Px·Cx)+ 2:
i=l
ki
2:c
ij
j=l
where:
g=number of ranked groups (the concept of
ranked groups is discussed in the section on
ranked grouping).
ki=number of fields in group i.
Cz = cost of determining whether group score
for one reference file candidate record
exceeds maximum score.
Cx == cost of storing all group scores in the case
that the reference file candidate record has
a higher score than any yet encountered.
P x = fraction of ranked groups whose scores are
monotonically increasing (i.e., the number
of groups where it is necessary to replace a
previously encountered maximum score
divided by the total number of groups).
C ij = cost of comparing field j in group i. This
includes the cost of string compression
(such as SOUNDEX), field padding, fixed
or interval logical comparisons, weight
determination and adding the derived
weights and penalties to the total ranked
group scores.
UNIMATCH
Note: The derivation of these terms will become
apparent when the ranked grouping algorithm is
discussed.
CRITICAL FIELD HIERARCHY
Since the critical fields serve to limit the domain of
reference file candidacy, each critical field is an identification key. For sequential files, these identification
keys must be sort keys, and both the data file and the
reference file must be sorted on all such keys in ascending collating sequence. For direct access files, the
identification keys can be used to retrieve records
sequentially. For the purposes of this paper, it is
assumed that both files are sequent:al files, since
direct access files can be processed sequentially.
Let the major critical field be defined as the critical
field with the highest level (major) sort key. The major
critical field must be the major sort key. The minor
critical field (or search field) is, of course, the critical
field with a sort key of lower hierarchy (more minor)
than any other critical field. It is therefore the minor
sort key in the set of all critical fields, and not necessarily the true minor sort key. The minor critical
field is the search field. This field is used to construct
the domain of reference file candidacy. All reference
file records having the same search field (minor critical
field) contents as the equivalent field on the data file
will become prospective match candidates for that
data file record. S:nce the minor critical field defines
the domain (which is the most important factor to
the cost of a record linkage application), this field
should be chosen with great care.
THE UNIMATCH LANGUAGE
Before embarking upon a discussion of the record
linkage theory governing the comparisons of noncritical fields, the relationships between critical field
hierarchy, domain construction, and field definitions
within the UNIMATCH language will be explained.
The basic operation of the system and the structure
of the UNIl\;IATCH language are prerequisite topics
toward an understanding of these relationships, and
will therefore be discussed presently.
The language itself is composed of a series of statements consisting of fixed-field keywords with operands,
and tables which follow some statements. The keyword
identifying a certain statement type is always punched
in· column one of the control stream record. The number and position of the operands are dependent upon
the individual statement. In general, the statements
525
are not directly executable commands (like the FORTRAN Arithmetic statements), but are for the most
part, definitions. The statements are edited, and
reduced to numerical form by the UNIMATCH
Compiler. Arrays defining the structure of the problem,
and blocks containing control information are created.
The UNIMATCH Assembler reduces this basically
tabular compilation into blocks of relocatable executable machine code for the IBlVI System/360, and
blocks of control information. These blocks are loaded
and executed under control of the UNIMA TCH
Executer. The three programs of the UNIMATCH
system (the Compiler, the Assembler and the Executer) are written in IBlVI System 360 Assembler
Language, and both OS and DOS versions of the
system will be released.
As many runs as desired may be compiled, assembled and executed by each phase, respectively, so that
multiple-pass linkage applications can be executed
during one job step. Splitting the system into three
phases enables the generation of efficient program
code that will not penalize the user for features not
desired, and provides greater core storage for users of
limited computer facilities. Furthermore, production
runs need only be compiled and assembled initially
because the assembler creates object modules that
can be retained.
FIELD DEFINITION
Due to their importance in subsequent discussion,
considerable attent~on will be g',ven to the KEYFIELD
and EQUATE statements. In general, however, exact
details of the language will not be presented in this
paper. Every field used in a comparison (critical or
non-critical), and every field used in a field manipulation context must be defined via the KEYFIELD
statement. This statement consists of the keyword
(KEYFIELD) followed by the beginning character
position of the field, the field width in characters, and
a 1-8 character label (or field name) which provides
reference to the unique field. Unless otherwise specified
(via the EQUATE statement), all fields are considered
to be identical (having the same beginning column
and fie:d width) in both the data and reference files.
The inclusion of a field in the KEYFIELD or EQUATE
statements does not necessarily imply that any actions
or comparisons will be made on the field, but inclusion
does define the comparison configuration, should
subsequent statements require such comparisons.
The EQUATE statement allows the user to define
the appropriate comparison configuration for the
defined fields, and to establish which fields belong to
526
Spring Joint Computer Conference, 1972
either the data file or the reference file (the omiss' on
of an EQUATE statement for a field results in that
field belonging to both the data and reference files).
The EQUATE statement consists of the keyword
followed by a two character code, followed by two or
three names (prev:ously defined in a KEYFIELD
statement). The first name given in all cases is called
the base name. All subsequent references to equated
fields should be by base name. The true configuration
of the comparison and aL fields involved will be utilized in creating the object code blocks, without having
to be restated by the user. A code of FC or FN requires two names: the name of the data file field followed by the name of the reference file field. The
locations and lengths of these fields have been previously defined (by KEYFIELD statements). The
field on the data file will be compared character by
character with the equated field on the reference file
should any subsequent statement require a comparison. Codes FC and FN differ in their treatment of
unequal length fields (the data file field is not equal
in length to the reference file field). FC causes padding
of the short field with blanks to the right, and FN
causes padding of the short field with leading zeros,
to equalize the lengths. FC can therefore be used with
character data, and FN with numeric data.
Codes RI and RP requ' re three names: the name of
the data file field, followed by the name of the reference file field contain:ng the low extreme of a closed
interval, followed by the name of the reference file field
containing the high extreme of the interval. By this
means, comparisons may be made between fixed values
on the data file, and closed intervals (where the endpoints are included in the interval) on the reference
file. Subsequent statements will only require the base
name (in this case the data file field name) to cause
the appropriate interval comparisons to be made.
Code RP is identical to RI except that the parity of
the fixed field must match the parity of the low extreme
of the interval. In this case parity refers to whether
the values are even or odd. Parity agreement is useful
for street address matching, where a house number
is to be compared to a range of addresses on a street,
and the odd and even addresses are on differing street
sides. Codes DI and DP pertain to fixed fields on the
reference file being compared to intervals on the data
file. All interval fields are treated as numeric, and the
short fields are padded with leading zeros at execution
time before comparisons are made.
CRITICAL FIELD DEFINITION
The l\1:ATCH, SORT, and SEARCH statements
define the hierarchy of the critical field structure and
the domain construction. The keyword lVIATCH,
followed by a field name, indicates that the field is a
critical field, and the appropriate comparisons will be
made for the configuration defined via the KEYFIELD
and EQUATE statements. A mis-match on any critical
field is sufficient to reject the data file record. The
domain of candidacy is thereby reduced by means of
the lVIATCH statements. If a critical field represents
an interval comparison, the ranges covered by the
interval must not overlap. The SORT statement
defines the sort order of the critical fields by requiring
a level number and critical field name. The SEARCH
statement defines the reference file domain. The
keyword SEARCH is followed by a field name (which
must appear in the SORT statement). All reference
file records having the same search field contents as
the equivalent field on the data file record will become
prospective match candidates for that data file record.
Operationally, reference file records are read into core
storage, until the end Of the partition is reached, at
which time they are written on disk and paged in as
required. The program will operate more efficiently in
larger storage partitions. If the domain is chosen
carefully, there should be few (if any) input/output
operations of this sort. The program will process
domains as large or small as desired without any user
modification. The disk paging operations are optimized
to minimize the number of accesses.
WEIGHTED COl\1:PARISONS
After the reference file domain is constructed, it is
often desirable to make a number of comparisons with
the object of selecting the most probable record for a
match if that record is within the acceptability tolerances. The concept of weighted comparisons makes
this possible. l\/Iuch work has been done on the derivation of weighting schema. A paper written by Sidney
H. Brounstein of the IBl\f Corp.1 provides a comprehensive review of the weighting techniques developed, and will be quoted extensively in this section.
Robert T. O'Reagan of the Census Bureau2 •3 has
done considerable work in the derivation of practical
weighting algorithms. The fundamental weight" ng
theory underlying most modern methods is the "Direct
Weighting Concept", derived by N ewcombe4~5. The
following quote from Brounstein ,vill illustrate the
basic concept:
Given a pair of records that are candidates for a
match, the number of the components that agree
and disagree is observed. If equal impact were
given to each component, the discriminating
power of some components that are measurably
UNIMATCH
more powerful than others would be wasted. For
example, if two American health records agree on
the surname Smith, that would be some ind~cation
that this m;ght be a true match. However, if they
agree and both say Hinton in that component, it
is a much stronger clue. The rarer the argument,
the less like" y that accidental agreement will
occur between components in records brought
together at random.
If the sets 1\1: (matched pairs) and U (unmatched
pairs) preexisted in totality, there would be no
matching problem. The problem exists because
some method of characterizing M and U is required to decide to which of the sets a new comparison pair (representing two records not previously linked) belongs. This implies the use of
sampling methods, computations based on frequency analyses of the separate files, or inferences
based on knowledge of the total populations from
which the data files are drawn.
Practical weights and penalties (negative weights)
can be computed by determining the following four
probabilities (by dividing the frequency of occurence
by the number of compari;son pairs tested).
P1=Pr(component
P 2=Pr(component
P 3 = Pre component
P 4 =Pr(component
agreeslpair is a true match)
agreeslpair is not a true match)
disagreeslpair is a true match)
disagreeslpair is not a true match)
The appropriate weight for the comparison pair can
be computed by:
Sw=log2 (PdP 2)
The appropriate penalty can be computed by:
Sp = log2(P 3/P4)
Weights and penalties can be derived in this manner
for all components (or configurations of components).
A component is a field for which a weighted comparison is to be made, and its configuration is the value of
the field on both the data and reference files. The score
for each prospective candidate in the domain can be
computed by adding (separately) the weights and'
penalties for each component (determined before the
actual record linkage application by means of a sample
population, and the above method). The reference
file record· with the greatest weight and lowest penalty
is the most probable match within the domain. If the
penalty of this best record is greater than a certain
threshold value, the data file record can be rejected
on the basis that the probability of the chosen reference
file record being a correct link is too low for the particular application.
527
This method of computing weights and penalties
assumes the statistical independence of each component (if this is not true, then joint distributions must
be computed by taking the set of all components at
one time," generally an immense undertaking). For
address matching purposes (geographic coding), the
assumption of independence is fairly good. Allowing
this assumption, the addition of the logarithmic weight
scores for each component is equivalent to multiplying
the likelihood ratios, thereby attaining the joint probability for the record being a match.
The following example will illustrate the method of
deriving weights for an address coding application.
The probabilities PI to P 4 are computed using a sample
file where all records have been linked manually
(assuming no clerical error!). Consider the component
"street type":
PI = Pr(street
P 2=Pr(street
P 3 = Pr(street
P 4 =Pr(street
type agreeslpair is a match) = 0.64
type agreeslpair is not a match) =0.16
type disagrees Ipair is a match) = 0.02
type disagreeslpair is not a match) =0.74
These probabilities are based on frequencies of occurrences divided by the number of comparisons made.
One comparison is made for every reference file record
in the domain for a given data file record. The weight
for a match on street type is:
log2(0.64/0.16) =log2(4) =2
The penalty for a mis-match on street type is:
log2(0.02/0. 74) = log2(1/32) = - 5
Next consider an additional component "direction".
Assume that weights derived in a similar manner are
4 and - 6 respectively.
In future record linkage applications the two components can be examined against the equivalent reference file components. If both street type and direction
matched, the total weight for the candidate record
would be 2+4 = 6, with a penalty of zero. If direction
matched, but street type did not, the weight would
be 4 and the penalty would be 5 (the penalty score is
considered to be a positive number, not a negative
weight). The converse case would produce a weight of
2 and penalty of 6. Disagreement on both components
would produce a weight of zero and a penalty of 11.
THRESHOLD LEVELS
The we~ghts and penalties computed in the previous
section can" be used to determine the threshold level
for the data file record rejection. If the weight obtained
for a particular record is equal to the penalty score,
528
Spring Joint Computer Conference, 1972
then there is a 50 percent chance (1: 1 odds) that the
reference file record will provide a correct match. If the
weight obtained is one greater than the penalty, the
odds favoring a correct match are 2: 1. If the weight
is lessthan the penalty, the odds do not favor a correct
match. In general, the difference between the weight
and penalty scores is the logarithm (to the base two)
of the odds favor ng a match.
Odds in favor of a correct match = 2(Sw- S p)
The amount of error tolerable for a given application
must be determined by the user, in order to set an
appropriate threshold level.
RANKED GROUPING
The UNIMATCH system has a feature whereby as
many fields as desired may be grouped together.
Grouping establishes a separate weight and penalty
score counter for the set of fields in each group, as well
as group hierarchy (or ranking). The selection of the
best reference file candidate is determined by examining
the domain, and retaining only those reference file
records having the maximum weight in the highest
ranking group. All other records are removed from
the domain. The remaining records are examined, and
only those reference file records having the maximum
weight in the second highest ranking group are retained. All others are removed from the domain. This
process is continued until the lowest ranking group
weights are examined. In practice, this process is conducted in a single pass through the reference file domain. The weights for all groups are computed for a
given record, if the weights are better than the maximum encountered previously, then the current record
becomes the prospective candidate, if not, the next
record is inspected. At the termination of the scan, the
weight and penalty counters reflect the values of the
best record, and pointers indicate the position of that
record in the domain. A record is better than a previous one if there exists a "\veight in a high ranking
group that is greater than the existing weight (weight
scores are maximized within rank, e.g., a record bearing
a score of 1,4,7 will not replace a record bearing a
score of 2, 1 ,1 where the first number in each set of
three is the highest rank).
A further condition is added to the criteria for
reference file record selection: If the weight score for
any group (regardless of rank) is zero, that record
will not be considered a prospective candidate. This
convention allows a secondary hierarchy· to be constructed. It may be desirable to automatically reject
the data file record if certain minimum information
is desired.
The ranked grouping concept allows a system of
intuitive weighting to be established, where the ranks
are assigned upon the basis of the information content
of each field, and group of fie~ds. ~Iore importantly,
the ranked grouping concept permits reduction of the
reference file domain when the fields cannot be expressed as sort keys (via the critical field :.\IATCH
statements). A common example of this is the comparison of a field to an interval where the intervals are
allowed to overlap. No sorting scheme will be able to
construct a domain that will ;nclude various values of
the single field if the ranges of the intervals vary and
the values overlap. Including all va:ues of the intervals
(within the critical sort keys, of course) into the domain, and defining the interval comparison to be within
a group, and assigning a weight of one for a match
and a weight of zero for a mis-match, will result in the
retention of all intervals containing the field value (or
vice versa, if the interval is on the data file) in the
domain. Another example, is the phonetic compression
of a character string (another feature provided by
UNIl\1ATCH). All values sufficiently close to the
data file value can be retained in the domain. This is
useful for name matching. The interval comparison
method given is useful for matching a street address
to a range of addresses in a city.
IMPLEMENTATION OF WEIGHTED
C01VIPARISONS
The UNIl\1ATCH system requires all fields where
weighted comparisons are needed, to be organized into
ranked groups. The GROUP statement requires a
group name (which is a 1-8 character label not previously used, that will uniquely identify the group),
and a list of all fields (by field name) that comprise
the group. Any particular field may be used in as many
groups as desired. At least one group must be defined
to allow weighted comparisons, but fields may be
grouped in any fashion desired. Each group carries its
o\vn weight and penalty score counters. The LEVEL
statement defines the group ranking. It consists of
the level number and group name. The ACCEPT
statement defines the maximum penalty score permitted for the group named. If the penalty score of
the chosen candidate (the reference file record with
the highest ranked positive weight scores) is greater
than the amount specified in the ACCEPT statement,
the data file record will be rejected.
WEIGHT statements must be provided for all
fields specified in GROUP statements. Rather than
specifying the two states discussed earlier (match and
mis-match), the WEIGHT statement prov des for five
possible states:(l) the data file field matches the refer-
UNIMATCH
ence file field, and neither field contains blank nor
zero entries (match) ;(2) the data file field contains a
blank or zero entry and the reference file field does
not (data file omission) ;(3) the data file field contaIns
a coded entry and the reference file field contains a
blank or zero entry (reference file omission);(4) both
fields contain blank or zero entries (null match) ;(5) the
fields conta"n conflicting non-zero (or non-blank)
entries (mis-match). These states also apply to intervals.
An interval is considered null if both extremes are
zero. Conditional weight tables may be created which
will modify the group weights contingent upon certain
configurations of reference file field values. For example,
if the "street type" field is considered, and the data
file record has no entry coded, it might be desirable
to give added weight to those reference file candidates
containing a street type of "ST", "BLVD", "RD",
etc., over those containing street types of "PL", "CT",
"SQ" etc., on the basis that the frequency of occurrence
of "ST", "BLVD" etc., is likely to be higher. Conversely, if the data file field value is "COURT" and
it matched the reference file field, a higher weight may
be assigned because the frequency of occurrence is
less than "ST" and therefore the information content
is greater.
DATA TRANSFER CONTROL
Since the object of the record linkage process is the
transfer of data from the reference file to the data file,
considerable thought was given to the design of an
effective data transfer control system. The system
allows the user to code a number of executable commands describing the procedure for transferring information from the chosen reference file record to the
data file record (or if the data file record is rejected,
transferring messages to the data file record). The
unconditional "move" is the simplest operation. A
field in the reference file is moved to a location on the
data file (or appended to the end of the record, if
desired). A "compare" command causes transfer of
information contingent upon the stated value being
present in the data file or reference file. This allows
records of different types to be processed correctly.
UNIMATCH maintains a set of internal flags which
indicate whether individual fields were successfully
matched for the chosen candidate record. Data transfer can occur contingent upon the successful linking
(or non-linking) of any individual field for the candidate.
This feature makes it possible to take alternative
actions for various comparison results. A practical
529
example is in address coding against a Geographic
Base File where the records contain two address ranges,
one for each side of the street. If a match occurred
with a range on one side of the street, it is desirable
to transfer the geographic codes relating to that side
only. Other commands permit examination of the
group weight and penalty scores providing for data
transfer contingent upon a range of values. Character
text can be moved into the data file record instead of
information from the reference file record. The transfer
of text can be conditional upon comparison results,
weight and penalty values, etc. Simple arithmetic
functions can be executed upon the weights and penalties, allowing for example, the placing of the odds
favoring a match on each data file record. A memory
feature allows the reformatting of fields on the data
file, imputation of information on the data file, as well
as computations on data file fields.
FIELD MANIPULATION AND FILE CONTROL
FEATURES
The UNIMATCH system provides the capability
of converting input field values to new values on the
basis of conversion tables. For example, area codes
may differ between both files, in which case a correspondence dictionary may be prepared to provide for
conversion of the area codes. The capability of assigning default values to fields not coded is also provided.
Selection of data file records for matching may be
accomplished via SELECT statements. For example,
it may be desired only to match records occurring in
one city where a number of cities are present in the
data file.
The file management system provides the capability
of separating rejected output records from the accepted ones, or combining them as desired. In addition,
it is possible to separate rejected records of different
types, and to print listings of selected records in the
output file. A post-processor feature allows the matcher
to be used in non-record linkage applications where
field conversion, record selection, and reject separation
tasks can be performed on single data files.
STATISTICAL INFORJVfATION
UNIMATCH provides much statistical information
regarding each run that is executed. The output data
records contain twelve digit status codes prefixed to
the body of the record which indicate the status of
that output record. A code of "lVIT" indicates that
the record was matched successfully, and the penalty
scores of up to five high ranking groups are printed.
530
Spring Joint Computer Conference, 1972
I t is thereby possible to determine if a given data file
record is an exact match, and if not, what the degree
of uncertainty is. Critical field rejects are indicated
by a code of "CR" followed by the name of the field
that caused the mismatch. Group rejects produce a
code of "GR" followed by the group name and the
penalty score for that group. This gives the user an
indication of how much he must "loosen the reins" to
permit the record to be linked. Selection rejects and
search field rejects are also flagged.
At the end of each run the number of rejects by
type, field name and group name are printed. In addition, statistics are printed tabulating the number of
exact matches, the number of input/ output disk
operations required, the number of different reference
file domains used, the average domain, the effective
domain (the average number of records for any domain), input and output record counts, etc. This
information provides the user with a good picture of
the effectiveness of the record linkage application.
CONCLUSION
This paper has attempted to present the operation of
UNIMATCH by presenting both the theory underlying the development and the physical implementation of the system. All features and the exact details
of the specifications could not be discussed in a paper
of this scope. UNIMATCH will provide a generalized
record linkage capability to IBM System/360 users,
but more importantly will permit experimentation
with varying linkage algorithms with resultant greater
knowledge of the practical considerations of the record
linkage problem. Since a large portion of the record
linkage problem is record standardization, a Universal
Standardizer (UNISTAND) is being written as a
companion system for UNIlVIATCH. UNISTAND
will scan free-form text under pattern recognition
control in order to place recognizable components in
fixed fields for matching. Procedures will be supplied
to the user of both systems to process the most common problems (such as address coding, transportation
coding, etc.). These procedures will allow the user to
perform complex record linkage tasks without requiring
the sophistication needed for weight and algorithm
development. It is expected that these systems, along
with supplied procedures, will provide the capa,bility
of solving most of the current record linkage problems.
BIBLIOGRAPHY
1 S H BROUNSTEIN
Data record linkage under conditions of uncertainty
Delivered at the Seventh Annual Conference of the Urban
and Regional Information Systems Association Sept 6 1969
Los Angeles Calif
2 R T O'REAGAN
Address matching by computer
1968 U S Bureau of the Census unpublished
3 R T O'REAGAN
Application of information theory to bureau problems in
record linking
3/8/68 U S Bureau of the Census unpublished
4 H B NEWCOMBE J M KENNEDY
Record linkage making maximum use of the discriminating
power of identifying information
Communications of the Association for Computing
Machinery 5 1962 pp 563-566
5 H B NEWCOMBE J M KENNEDY S J AXFORD
A P JAMES
A utomatic linkage of vital records
Science 130 1959 pp 954-959
New directions in legal information processing*
by R. T. CHIEN**
Massachusetts Institute of Technology
Cambridge, Massachusetts
P. B. MAGGS and F. A. STAHL
University of Illinois at Urbana-Champaign
Urbana, Illinois
INTRODUCTION
deal with, for example, a set of conflicting laws or
regulations. Problems such as these must be attacked
at a level where the interrelationships among the various words and phrases (as well as their individual
meanings) are understood.
Comprehensive machine-readable data bases of legal
materials are rapidly becoming available as a result of
the economies they afford in such areas as typesetting
and legislative drafting. However, the conversion of
legal materials to machine-readable form has not made
them significantly more accessible to those who must
use them. Because of the great complexity and volume
of legal materials their analysis now requires great
investment of time by highly trained personnel. If
computers could "understand" legal materials, their
attractive assets (their large reliable memory, and their
extraordinary capacity for rapid and accurate information processing) would make them ideal assistants in
the field of law.
The ability to provide such an understanding is
emerging in new techniques currently being developed
in a computer area called "artificial intelligence" in
dealing with such problems as automated logical deduction, problem solving, and natural language understanding. These techniques appear to be the key to
solving many of the problems of legal automation.
In particular, we foresee the development of a number of computer based services in this new technology.
These include:
Present areas of application of computers to the law
fall into three broad categories: (1) those involving
applications of business accounting techniques such as
in tax preparation and client billing, (2) those involving
data management techniques such as law enforcement,
criminal justice, and keyword legal source material
information systems, and (3) those involving on-line
file manipulation in such areas as text-editing and
drafting. These systems demonstrate that computers
can work very well with problems that can be expressed
in terms of numbers or information that can be handled
on the basis of its external form.
During the coming decade, we foresee the continued
expansion of the use of existing systems and also the
development of some new systems based on conventional data processing techniques. Such new systems
may be expected in automating the accession to index
systems patterned on existing manual systems, processing land use documents, supervising paroled offenders,
etc. However, ordinary data processing methods are
by their very nature incapable of providing muchneeded assistance in the central area of legal work,
where the content of the material at hand (laws, contracts, depositions, etc.) must be understood and analyzed in terms of its meaning and logical relationships.
It is impossible, using file management techniques to
1. Automated systems to provide quick and inexpensive assistance for many non-controversial,
but not necessarily simple legal questions to aid
lawyers, social and welfare workers, administrators, police, and of course the public itself;
2. Automated consistency-checking, and consequence-finding systems to aid in codification
* The work presented here was performed at the Coordinated
Science Laboratory of the University of Illinois at UrbanaChampaign. It was supported by the Joint Services Electronics
Program (U.S. Army, U.S. Navy, U.S. Air Force) under Contract
No. DAAB-07-67-C-0199.
** On leave from the Coordinated Science Laboratory and the
Department of Electrical Engineering at the University of
Illinois at Urbana-Champaign.
531
532
Spring Joint Computer Conference, 1972
and law reform for legislative and administrative
bodies;
3. Automated systems to assist in teaching law
and legal reasoning for those who need to know
the law; and
4. Automated interviewing systems for initial
client and witness screening.
In this paper we include a brief survey of recent
applications of computers to the law, a discussion of
the further types of automation that are needed in the
law, an outline of current developments in artificial
intelligence which could be applied to aid in the automation of the law, and finally a description of the new
directions we envision for legal information processing
during the 1970s.
A SURVEY OF RECENT APPLICATIONS OF
COMPUTERS TO THE LAW
Automation has been applied to problems in criminal
justice and law enforcement as well as a host of other
applications including legal information retrieval, income tax preparation, and legislative drafting systems.
In this section a brief description of these application
areas is given. For a more thorough survey of this
work see Robins;47 Bigelow,1 the May, 1971 issue of
Law Library Journal, which is devoted to computers
and law; and the individual references cited in this
paper.
Criminal justice and law enforcement information systems
For our purposes, we can view criminal justice and
law enforcement information systems as consisting of
users, a computer, and an ever changing data base
being used to collect, store, and update information in
such a way so as to facilitate the retrieval and exchange of criminal justice and law enforcement information for governmental units. The most advanced of
these systems include: Project SEARCH61 (System for
Electronic Analysis and Retrieval of Criminal Histories) developed jointly by LEAA (Law Enforcement
Assistance Administration) of the Justice Department
and a number of participating states, the NCIC19,23
(N ational Criminal Information Center) computer network of the Federal Bureau of Investigation, and the
NYSIIS22 (N ew York State Identification and Intelligence System).
Legal information retrieval systems
The volume of jurisprudential reference material in
the· form of cases, statutes, and administrative rulings
and regulations has prompted the development of
automated law retrieval systems to aid the legal researcher. This work has been based in part upon research being carried out in the area of library automation and is specifically related to the problem of
document retrieval.
Of the experimental projects that have been undertaken for performing automated legal information retrieval the basic assumptions have been that a person
seeking technical legal information can be led to
relevant information using a keyword type approach,
and that technical legal information can be categorized
in such a fashion as to be retrieved by a keyword type
approach. Within this framework there are basically
two approaches that have been taken: those systems
which rely on prior manual abstracting of library
material and those which operate on full natural text
without abstracting.
Systems requiring manual abstracting
The first system for computer storage and retrieval
of legal material developed by Morgan42 ,58 was used
for the retrieval of case law. It employed an approach
where concepts were identified and assigned code numbers which were in turn linked back to the original
case. Thus, having once determined the relevant concepts one could retrieve the citations to pertinent
cases. This approach was very similar to the manual
indices that have widespread use today such as the
West Key Number System. Other attempts at automated legal research using this approach have been
made by the Federal Trade Commission,2 and the
Antitrust Division of the Department of Justice.47
Systems operating on full natural text
A significant departure from the manual abstracting approach is the Key Word in Combination approach
of John Horty.28,29,31 Here, no abstracting or indexing
of the material was done manually. Retrieval was done
by finding combinations of keywords in the original
text. A researcher could specify lists of words that must
appear in the same sentence or statute as well as the
desired word ordering. The LITE (Legal Information
Through Electronics) Project developed by the Air
Force Accounting and Finance Center37 and the Root
Index System developed by the Southwestern Legal
Foundation43 ,49,56 are two other systems that are similar
in design with the Key Word in Combination approach.
The OBAR System developed by the Ohio Bar Association45 and Mead Data Central has added signifi-
New Directions in Legal Information Processing
cant on-line interactive capabilities to this type of
approach.
The ABF-IBM project
The ABF-IBM (American Bar Foundation and
International Business Machines) Project15- 18 attempted to overcome the disadvantages of either of the
other previous approaches by automatically generating
frequencies for each word used in the original case.
Deviations or "skewness" of certain words from a
normal distribution were assumed to convey information about the contents of the case.
Other applications of computers to the law
There are many other applications within the legal
area for which automation has been proposed, and in
some cases even implemented. 6,34,35,39 Most of this work
represents straightforward applications of current
technology to the particular problems encountered in
the legal area using methodology well established in
other areas, such as office management and business
accounting. Automated legislative drafting and revision, will drafting, as well as general law office document drafting are good examples of the extension of
available hardware and software that has been made
available in recent years. Automated court management, legislative reapportionment, law office management, income tax preparation, land title recording,
and estate planning are examples of established data
processing techniques that have been used for legal
problems.
THE NEED FOR NEW DIRECTIONS
The quantity and complexity of legal materials is
increasing at a rate that cannot be adequately handled
by traditional means. In many areas the growing demands of modern society have been met by automation.
However, modern computer techniques have had only
a minor effect on the three major areas of legal work
where they might seem applicable : legal research,
legislation, and legal education. As mentioned above
numerous attempts have been made to apply scientific
and business data processing techniques to such legal
problems, but all have fallen short of major impact
because they have been by their nature unable to deal
with the verbal and logical complexities of the law.
Most areas of legal work have remained relatively
untouched by automation. The problem is not that the
legal profession has neglected automation; rather it is
533
that technology has failed to meet the demands of the
law. What is lacking is the capacity to give legal personnel the same sort of assistance in their routine work
with words and concepts that engineers get from the
computer in their routine work with numbers and
formulas. What is needed is the automation of the process involved in routine legal reasoning and research.
Modern statutes and administrative regulations are
of such immense complexity as to be impossible to
understand for the layman and difficult even for the
lawyer. The problem is particularly acute in many
areas where the task of interpreting and enforcing the
law has traditionally been left to non-lawyers, for instance, welfare administration.
To give an example of the problem: At present when
local administrative authorities receive an application
for welfare benefits, the eligibility of the applicant and
the benefits to which he is entitled are determined by
a large and conflicting body of local, state, and federal
welfare laws and regulations which may total hundreds,
if not thousands, of pages in length. Typically an applicant may have to wait for weeks or even months while
an overburdened administrator attempts to determine
his legal status. As another example, a business transaction involving questions of tax laws, zoning regulations, and building codes may fall through because of
the delays and expense involved in the drafting of the
transaction to conform to the many, and possibly conflicting, requirements of the law.
The successful development of automated techniques
for dealing with complex legal situations would help in
these and many other areas by providing quick and
inexpensive answers to many routine legal questions.
Such techniques could also help employers and employees determine their rights under labor relations
contracts. They could help both the taxpayer and the
government in tax planning and administration. It
would be possible to provide legal guidance for some
small businessman's transactions which involve too
little money to justify full scale analysis by a lawyer.
In many areas, where the law now consists of confusing and conflicting regulations at different levelsfederal, state, and local, the first step toward law reform
would be the unscrambling of a situation that has been
caused by years of haphazard legislation so as to provide
a clearer assignment of rights, duties, and administrative responsibilities. However, legislators have been
unable to take even this first step, not merely because
of the cost, but also because human ability to enact
complex legislation appears to exceed human ability to
reorganize, recodify and simplify that legislation.
The total length of the United States Code and the
collected statutes of the various states has doubled in
534
Spring Joint Computer Conference, 1972
which in turn refer to still other sections creating an
incredibly complex network (as illustrated in Figure 1).
Even one of the shortest sections referred to by §602,
namely §625, which defines "child welfare service" has
an extraordinarily complicated internal logical structure (as illustrated in Figure 2).
There is a major unfilled demand for legal services
in the United States. It is particularly acute for lower
. . . . - - - - - - - - - - , No
r---------------~
No
Supervision
No
No
Figure I-Network of References from 42 U.S.C. §602, "State
Plans for Aid and Services to Needy Families with Children."
References to the laws of the fifty states, implicit cross references,
and references to federal and state administrative and judicial
interpretation of the statute have been omitted for lack of space.
the past few years and promises to double again in this
decade. In commercially important areas such as tax
law, it is possible, at high cost, to find specialists who
understand even the present incredibly complex legal
picture. In many socially important areas, such as welfare law, pollution control law, environmental quality
law, and urban planning law, it is almost impossible
to find anyone who has a thorough working knowledge
of the field. As a result, many important social programs
are either slowed down or stifled.
To illustrate the complexity of the problems involved
consider a single section of federal welfare legislation,
for instance, that dealing with state plans for aid to
needy families with children (42 U.S.C. §602). This
single section refers to eight other sections, most of
No
Figure 2-Logical structure of 42 U.S.C. §625 " 'Child-Welfare
Services' Defined." One of the Simpler Sections. The appendix
contains the text of this section
New Directions in Legal Information Processing
income groups, but legal services, like other unautomated services, are increasingly becoming priced out of
the reach of larger and larger segments of the American
public. At present large law firms provide excellent
legal services for those able to pay their fees. Most of
the lawyers in these firms spend most of their time in
legal research and drafting legal documents. 55 The small
businessman or average citizen, if he can afford legal
service at all, typically employs a sole practitioner who
cannot afford the library or the time necessary to do an
adequate job of legal research on his client's problems. ll
The experience of the medical profession in dealing
with the problem of the cost of doctors' services suggests that two approaches be tried simultaneously.
First, the rapid automation of those areas suitable for
automation, and second the training of paraprofessionals to free the professional from routine tasks. However, the training of paraprofessionals in law-welfare
administrators, social workers, lay magistrates, law
clerks, etc., has been neglected by American education
until very recently. Application of traditional methods
of legal education to the problem would be possible,
but it would be expensive, and would be difficult in
view of the fact that all American law schools are filled
to capacity. 5
RECENT DEVELOPMENTS IN ARTIFICIAL
INTELLIGENCE APPLICABLE TO LEGAL
AUTOMATION
A significantly broad theoretical framework has been
established for the application of computers to the law
as the result of research and development in the area of
artificial intelligence, in particular in question-answering systems where work has been carried on for over a
decade. For information concerning such systems we
refer the reader to Simmons. 52,53 Of the more advanced
question-answering systems Green and Raphae124,25
have developed a very powerful deductive procedure,
and Simmons, Burger, and Schwarcz51 ,54 introduced an
extremely attractive representation scheme, while
Biss, Chien and Stahl 8 have developed the R2 system
which incorporates a number of advanced features not
found in these other systems. These systems have attacked the problem of understanding facts and answering questions about them on an automatic basis. It is
understood as a result of the development of these
systems, how to, for example, resolve certain kinds of
semantic and syntactic ambiguities. In addition, a number of sophisticated formal internal structures have
been developed that allow much of the expressiveness
found in natural English and yet can be manipulated
by machines in a systematic fashion.
535
Transformation of natural English into a formal internal
representation
Generally, natural language question-answering systems use some formal internal representation for information in order to facilitate deductive manipulations. In a number of earlier systems the representation
was based upon some type of limited relational calculi,
as for example Raphael's SIR,64 and Black's SQA.9
Green and Raphael24 ,25 subsequently developed a system that offered the full expressiveness of the first-order
predicate calculus for the representation of natural language information. Simmons, Burger, and Schwarcz51 ,54
developed a system that used nested binary relations
for the formal representation of natural language information. The R2 question-answering system developed by Biss, Chien, and Stahl 8 uses a high-order
formal language for the internal representation of information. This system represents relations between
relations and quantification of variables ranging over
rather complex structures. The data base chosen to
demonstrate the capabilities of this system is an informal description of the motor vechicle laws of Illinois.
Logical deduction as performed by computers
What types of "reasoning" or logical operations can
be. performed by a computer upon factual information
expressed in a formal language? There has been significant progress in recent years in the research of deductive reasoning as performed by computers. N evertheless the computer's ability to reason with formal
concepts such as those as found in legal materials is
still far from fully realized.
Automated deduction procedures have been developed for the propositional calculus, but the limitations
of this calculus for most practical applications led to
the search for automated procedures for the first-order
predicate calculus. For the first-order predicate calculus,
an effective deduction procedure based upon an automatic theorem-proving algorithm was first described by
Robinson48 and was improved upon by Wos, et al. 62-65
and others. 3,4,33 Currently work is being done by a
number of researchers to find effective procedures for
high-order logic where concepts that cannot be handled
adequately in the first-order logic can be accommodated.
NEW DIRECTIONS
The use of computers as an aid to the legal process is
already extensive as indicated by the work described
above. There is, however, a vast difference between
536
Spring Joint Computer Conference, 1972
providing automated criminal justice and law enforcement information systems or legal information retrieval
systems on the one hand, and improving the availability and quality of legal services on the other hand.
In the first case the computer is used to accomplish
well-defined but time-consuming routine tasks; the
second case has been almost completely ignored with
respect to the cognitive potential that computers can
provide. Research in this country in this second area is
virtually non-existent.
We envision the initiation of research programs
within the near future to meet the need for automation
in the law with the following objectives: first, to increase
the ability of lawyers, administrators and the public to
deal effectively with many of their legal problems;
second, to aid legislative and administrative agencies
in the reform and development of legislation and regulations concerning current social problems; third, to
provide legal training on an automated basis for lawyers, social workers, police, and others who need to
know the law for the performance of their duties; and
fourth, to automate client and witness interviewing
and screening.
As outlined above, the theoretical framework for
such research must be drawn from the field of artificial
intelligence and in particular from current investigations in automated natural language question-answering
and logical deduction. Eventually the development of
automated inductive logic may also offer significant
aid in legal work. For an excellent discussion of this
possibility see Reference 10. Numerous data bases of
machine-readable legal materials already exist. The
specific tasks that must be accomplished are:
1. The development of techniques for the transformation of natural language legal information
into formal internal representations.
2. The development of techniques for automated
logical deduction from legal materials in formal
internal representations.
3. The development of practical automated legal
question-answering systems based upon these
logical deduction techniques.
4. The development of systems for machine assisted
consistency-checking and consequence-finding to
aid in the normalization, integration, and modification of legislation and administrative
regulations.
5. The development of computer based legal education systems based upon the automation of
the traditional Socratic method of legal instruction, using dynamic question-generating techniques rather than preprogrammed instruction;
and
6. The development of conversational computer
techniques for obtaining information from clients
and witnesses.
The data base
A large quantity of federal and state legislation has
already been converted to machine-readable form, and
in a number of jurisdictions new legislation is being recorded initially in machine-readable form. The availability of legislation in this form has led to significant
economies in the process of inserting amendments both
at the original enactment of a statute and as a result
of later legislative action, and has helped in the development of keyword document retrieval schemes. The
Illinois Legislative Reference Bureau, for instance, has
an advanced on-line system developed by Data Retrieval Corporation, with a dozen terminals for use in
legislative drafting, law revision and keyword retrieval.
While these techniques are not in the central area of
legal work, their existence, and the benefits and economies they provide, guarantee the availability of data
bases in machine readable form.
Existing machine-readable materials include all
types of primary legal sources. These are: comprehensive codes such as the Uniform Commercial Code and
the Internal Revenue Code; un codified legislation such
as state statute collections; and judicial and administrative decisions.
Selection of relevant materials from the data base
The selection of relevant materials from the data
base may be based on a combination of four methods.
The keyword method, despite the shortcomings which
have prevented its widespread adoption in legal research, is very efficient for certain types of questions.
The automation of the present manual system involving
networks of case and statutory citations would present
few technical problems. 36 The automation of the current
system of abstracts and digests combined with new
techniques of automated abstracting might save the
current system from the strain of the legal information
explosion. Finally, as computer time becomes cheaper
and cheaper, the artificial intelligence techniques discussed below (which might be expected to bring significantly better results but to use substantially more
computer time) might supplant the other methods.
Transformation of legal English into a formal internal
representation
Lawyers have already developed a highly formalized
language as a means of communication. Development
New Directions in Legal Information Processing
of effective legal information systems will require investigation of the problems associated with transforming this subset of natural English into an internal
representation suitable for use in legal questionanswering, consistency-checking, consequence-finding,
and instruction systems. This research can draw upon
recent advances in automated syntactic and semantic
analysis, e.g. 7,5 0,59
Logical deduction
In order to automate the processes involved in legal
reasoning an analysis of the logical structure of legal
information is necessary. Knowledge of this structure
will aid in the selection and development of effective
automated legal reasoning techniques based upon
theorem-proving techniques mentioned above. Within
the framework provided by automated theorem-proving
techniques it is necessary to find reasonable models for
deductive legal reasoning. These procedures can be incorporated in the legal question-answering, consistencychecking, consequence-finding, and instruction systems
described in the next few paragraphs.
Legal question-answering
Interactive legal question-answering systems with
internal representation and logical deduction techniques
adapted from prior research on general natural language question-answering systems to reflect the nature
of legal materials should be developed, for only natural
language question-answering systems allow the user to
engage a machine in a meaningful dialogue in order to
specify his needs and receive appropriate responses.
Since almost no legal personnel have any knowledge of
computer programming, communications between the
user and the machine should be performed entirely in
the natural language question-answering mode in
English.
Consistency-checking and consequence-finding
In addition to the question-answering function of the
future systems, the ability to find relevant consequences
for given sets of facts with respect to specified rules,
regulations, laws, statutes, contracts, etc., should be
incorporated. They should be capable of determining
the relative consistency of any body of legal information. At present these functions, as carried out by
lawyers on a manual basis, are very time consuming
and are subject to error.
These systems when completed will involve direct
benefits for legislators and administrative rule-makers.
537
They will be able to use their capabilities to help in the
detection and elimination of contradictions and ambiguities in existing law. Legislators will also be able to
examine more fully the implications of proposed additions to the existing body of legislations.
A utomated legal instruction
Legal instruction now takes many forms. 5 Some of
the methods which are and will be most important in
the future lend themselves to automation using artificial intelligence techniques. These include basic instruction in legal doctrine and method designed to give
the student basic skills in legal vocabulary and reasoning;5, pp. 17-18 extensive instruction designed to expose the student to surveys of broad areas of the
law,5, pp. 21-22 and simulated clinical instruction designed
to develop practical skills and awareness. 5, pp. 41-42
The accepted method of teaching basic skills in legal
vocabulary and reasoning in the United States has long
involved the asking of specific questions and their
answering by the students as a major if not the major
component of the instructional process. However, because this procedure is effective only when applied by
highly qualified instructors to relatively small groups,
it has been expensive to use in law schools and it has
found comparatively little use in programs of legal
education for non-lawyers. An authoritative recent
study places the cost per legal instructor in programs
for non-lawyers at $55,000, a large figure, even though
less than the $80,000 a year cost for each professor in
regular law school instruction. 5, pp. 69 It is hoped that
the automation of this process will reduce its cost and
extend its availability.
A legal question-answering system may be modified
to form a system where questions are generated automatically to aid in the instruction of the law. Such a
system could supplement some of the instruction now
being given in law schools, but perhaps a more important application would be in training administrative
officials, police, social workers, and others whose job
requires day-to-day legal interpretation and administration.
One approach to such a system would be as follows:
A series of typical factual situations would be posed
for each of the conditions of a given statute. In order to
ask a question an appropriate selection of a number of
conditions would be automatically made such that the
conclusion under consideration would be true. A question could be made false by eliminating some necessary
conditions, and could be made more difficult by adding
some irrelevant condition. In either case the answer
given would be checked for consistency against the
538
Spring Joint Computer Conference, 1972
given situation and pertinent statutes. The coverage
and difficulty of the questions could be structured by a
dynamic teaching strategy determined by the nature
and quality of student response.
Survey courses for practitioners, advanced law students, and non-lawyers are now taught largely by a
lecture method, a method adopted largely for reasons of
speed and economy. Automation would allow the institution of more efficient interactive methods of this
type of instruction.
Computer-simulated clinical instruction, even without natural language capability, has already proved to
be of considerable significance in medical teaching. It
could be of similar importance in law if artificial intelligence techniques capable of handling the highly verbal
nature of the lawyer-client interview were developed.
Prototypes of this approach already existing in the
medical area suggest the direction simulated legal
clinic instruction can take. 12 ,13,60
A utomated client and witness screening
An experimental program has already been put into
use for automated client interviewing at a legal aid
office. Because the program lacks natural language
capabilities, it can only accept yes/no or multiple
choice answers from the interviewee. 3s Addition of
natural language interactive capability would greatly
enhance the power of such computerized interviewing
and allow a real dialogue between the interviewee and
the system.
CONCLUSION
The American public is becoming increasingly dissatisfied with the expense, delay, and inefficiency of the legal
system. Application of existing computer techniques
can help with some of these problems. However, real
progress .during the next decade demands new directions. Recent success in the field of artificial intelligence
points the way for the future of legal automation.
ACKNOWLEDGMENTS
The authors, while taking full responsibility for all
errors and omissions, wish to thank Professor Stephen
Marx of the School of Law of the State University of
New York at Buffalo and Professor Layman Allen of
the University of Michigan Law School for their many
comments and suggestions related to the subject of this
paper. In particular, we would like to acknowledge
Stephen Marx for his suggestion on simulated clinical
instruction and Layman Allen for his corrections to the
logic of Figure 2.
REFERENCES
1 L ALLEN R BROOKS P JAMES
Storage and retrieval of legal information: Possibilities
of automation
Modern Uses of Logic in Law 1960 p 68
2 American Bar Association Special Committee on
Electronic Data Retrieval
Law/fact retrieval at F.T.C.
Modern Uses of Logic in Law 1963 p 43
3 R ANDERSON W W BLEDSOE
A linear format for resolution with merging and a new
technique for establishing completeness
Journal of the ACM Vol 17 No 3 July 1970 pp 525-534
4 P B ANDREWS
Resolution and merging
Journal of the ACM Vol 15 No 3 July 1968 pp 367-381
5 Association of American Law Schools Curriculum Study
Project Committee
Training for the public professions of the law: 1971
In Association of American Law Schools 1971
Annual Meeting Proceedings Part 1
Washington DC 1971
6 R P BIGELOW (ed.)
Computers and the law: An introductory handbook
(2nd edition) Commerce Clearing House 1969
7 R P BIGELOW
How lawyers can use computers to practice law-Now
Unpublished Revision of an Article by the Same Title in
Law Office Economics and Management Manual
R P Bigelow ed
8 K 0 BISS R T CHIEN F A STAHL
R2-A natural language question-answering system
In Proceedings of the AFIPS 1971 Spring Joint
Computer Conference Vol 38 AFIPS Press
Montvale New Jersey 1971 pp 303-308
9 F S BLACK
A deductive question-answering system
In Semantic Information Processing M Minsky (ed.)
MIT Press Cambridge Mass 1968 pp 354-402
10 B G BUCHANAN T E HEADRICK
Some speculation about artificial intelligence and
legal reasoning
Stanford Law Review Vol 23 1970 P 40
11 J E CARLIN
Lawyers on their own
Rutgers University Press New Brunswick New Jersey
1962
12 K M COLBY D C SMITH
Dialogues between humans and an artificial belief system
In Proceedings of the International Joint Conference
on Artificial Intelligence DEWalker and L H Norton
(eds) Washington DC May 1969 pp 319-324
13 K M COLBY S WEBER F D HILF
A rtificial paranoia
Artificial Intelligence Vol 2 No 1 Spring 1971 pp 1-25
14 J M CONVEY
Information retrieval in law: Problems and progress
with legal computers
Dickinson Law Review Vol 67 1963 pp 353-362
New Directions in Legal Information Processing
15 W B DENNIS
Status of American Bar Foundation research on automatic
indexing-searching computer system
Modern Uses of Logic in Law 1965 p 131
16 S F ELDRIDGE
The American Bar Foundation project
Modern Uses of Logic in Law 1965 p 129
17 S F ELDRIDGE W B DENNIS
The computer as a tool for legal research
Law and Contemporary Problems Vol 28 1963 pp 78-99
18 S F ELDRIDGE W B DENNIS
Report of status of the joint American Bar FoundationIBM study of electronic methods applied to legal
information retrieval
Modern Uses of Logic in Law 1963 p 27
19 Federal Bureau of Investigation
The FBI's computer network
Datamation June 1970 pp 146-151
20 R FREED
Prepare now for machine-assisted legal research
American Bar Association Journal 1961 p 764
21 S E FURTH
Automated information retrieval-A state of the art report
Modern Uses of Logic in Law 1965 p 189
22 R R GALLATI
State criminal justice information systems-N YSnS
case study
Proceedings of the AFIPS 1971 Fall Joint Computer
Conference Vol 39 AFIPS Press Montvale New Jersey
1971 pp 303-308
23 F P GRAHAM
FBI operating computerized criminal data book
New York Times Nov 30 1971 p 30
24 C C GREEN
Theorem-proving by resolution as a basis for
question-answering systems
Machine Intelligence 4 B Metltzer and D Michie
(eds) Edinburgh Univ Press Edinburgh 1969 pp 151-170
25 C C GREEN B RAPHAEL
The use of theorem-proving techniques in
question-answering systems
Proceedings of the ACM National Conference 1968
pp 169-181
26 W HARRINGTON H D WILSON
R W BENNETT
The Mead data central system of computerized legal
research
Law Library Journal Vol 64 No 2 May 1971 pp 184-189
27 P HOFFMAN
Evaluating legal research services
In Computers and the Law; an Introductory Handbook
R P Bigelow (ed) 1969 p 51
28 J F HORTY
The 'Keywords in combination' approach
Modern Uses of Logic in Law 1962 p 54
29 J F HORTY
Use of the computer in statutory research and the
legislative process
In Computers and the Law; an Introductory Handbook
R P Bigelow (ed) 1969 2nd edition p 46-51
30 I KAYTON
Retrieving case law by computer: Fact, fiction and future
George Washington University Law Review Vol 35
1966 p 1
539
31 W KEHL J HORTY C BACON D MITCHELL
An information retrieval language for legal studies
Communications of the ACM Vol 4 1961 P 380
32 K E LATTA
Information retrieval: An automated system for case law
Canadian Bar Journal Vol 10 1967
33 D W LOVELAND
A linear format for resolution
University of Pittsburgh Dept of Computer Science 1968
34 J C LYONS
New frontiers of the legal technique
Modern Uses of Logic in Law 1962 p 256
35 J C LYONS
Computers in legislative drafting: An aid or a menace
American Bar Association Journal Vol 51 1965 p 591
36 S M MARX
Citation networks in the law
Jurimetrics Journal Vol 10 No 4 June 1970 pp 121-137
37 W McCARTHY
LITE (Legal information through electronics)-A
progress report
Law Library Journal Vol 64 No 2 May 1971 pp 193-197
38 R W McCOY
University of Wisconsin computer assisted legal services
project
Law and Computer Technology Vol 3 Nos 7-8 1970
pp 187-188
39 R W McCOY W A CHATTERTON
Computer-assisted legal services
Law and Computer Technology Vol11968 p 2
40 J S MELTON R C BENSING
Searching legal literature electronically: Results of
a test program
Minnesota Law Review Vol 45 1960 p 229
41 J S MELTON
The 'semantic coded abstract' approach
Modern Uses of Logic in Law 1962 p 48
42 R T MORGAN
The 'point of law' approach
Modern Uses of Logic in Law 1962 pp 44-48
43 Note, science-computer-The use of data processing
in legal research
Michigan Law Review Vol 65 1967 P 987
44 T PLOWDEN-WARDLAW
Computer-aided legal information retrieval
Forum Vol 4 1969 P 286
45 J PRESTON
OBAR and Mead data central system
Law Library Journal Vol 64 No 2 May 1971
pp 190-192
46 B RAPHAEL
A computer program for semantic information retrieval
In Semantic Information Processing M Minsky (ed)
MIT Press Cambridge Mass 1968
47 W RONALD ROBINS
A utomated legal information retrieval
Houston Law Review Vol 5 No 4 1968 pp 691-716
48 J A ROBINSON
A machine-oriented logic based on the resolution principle
Journal of the ACM Vol 12 No 1 January 1965
pp 23-41
49 H K SCHREUR
Dual-inverted file method for computer retrieval under
study at southwestern legal center
Modern Uses of Logic in Law 1963 p 162
540
Spring Joint Computer Conference, 1972
50 J A SCHULTZ W T BIELBY
An algorithm for the syntactic analysis in the R2
information system
Coordinated Science Laboratory University of Illinois
Urbana Illinois 1970
51 R M SCHWARCZ J F BURGER
R F SIMMONS
A deductive question-answer for natural
language inference
Communications of the ACM Vol 13 No 3 March
1970 pp 167-183
52 R F SIMMONS
Answering English questions by computer:A survey
Communications of the ACM Vol 8 No 1
January 1965 pp 53-69
53 R F SIMMONS
Natural language question-answering systems: 1969
Communications of the ACM Vol 13 No 1
January 1970 pp 15-36
54 R F SIMMONS J F BURGER
R M SCHWARCZ
A computational model of verbal understanding
Proceedings of the Fall Joint Computer Conference
Spartan Books 1968 pp 441-456
55 E 0 SMIGEL
The Wall Street lawyer
Indiana University Press Bloomington Indiana 1969
56 R A WILSON
Computer retrieval of case law
Southwestern Law Journal Vol 16 1962 p 409
57 R A WILSON
Case law searching by machine
In Computers and the Law: an Introductory Handbook
R P Bigelow (ed) 2nd edition 1969 p 55
58 R A WILSON
Memorial resolution to Robert T. Morgan
Modern Uses of Logic in Law 1962 p 267
59 T WINOGRAD
Procedures as a representation for data in a computer
program for understanding natural language
Report MAC TR-84 MIT Cambridge Mass Feb 1971
60 J WEIZENBAUM
ELIZA-A computer program for the study of natural
language communication between man and machine
Communications of the ACM Vol 9 No 1
January 1966 pp 36-45
61 P K WORMELI
The SEARCH for automated justice
Datamation Vol 17 No 12 June 15 1971 pp 32-36
62 L WOS G A ROBINSON D F CARSON
Some theorem-prom:ng strategies and their
implementation
Argonne National Laboratory Technical Memorandum
No 72 Argonne Illinois 1964
63 L WOS G A ROBINSON D F CARSON
The unit preference strategy in theorem-proving
AFIPS 26 Proceedings of the Fall Joint Computer
Conference Spartan Books 1964 pp 615-621
64 L WOS G A ROBINSON D F CARSON
Efficiency and completeness of the set of support
strategy in theorem-proving
Journal of the ACM Vol 12 No 4 October 1965
pp 536-541
65 L WOS G A ROBINSON D F CARSON
L SHALLA
The concept of demodulation in theorem-proving
Journal of the ACM Vol 14 No 4 October 1967
pp 698-709
APPENDIX
Text of 42 U.S.C. §625-"Child-welfare services" defined
§625. "Child-welfare services" defined.
For pruposes of this subchapter, the term ."childwelfare services" means public social services which
supplement, or substitute for, parental care and supervision for the purpose of (1) preventing or remedying,
or assisting in the solution of problems which may result
in, the neglect, abuse, exploitation, or deliquency of
children, (2) protecting and caring for homeless, dependent, or neglected children, (3) protecting and
promoting the welfare of children of working mothers,
and (4) otherwise protecting and promoting the welfare
of children, including the strengthening of their own
homes where possible or, where needed, the provision
of adequate care of children away from their homes in
foster family homes or day-care or other child-care
facilities. (Aug. 14, 1935, ch. 531, title IV, §425, as
added Jan. 2, 1968, Pub.L.90-248, title II, §250(c),
81 Stat.914.)
HOMLIST-A computerized real estate
information retrieval system
by DONALD J. SIMON and BARRY L. BATElVIAN
University of Southwestern Louisiana
Lafayette, Louisiana
INTRODUCTION
Outline of the system
An automated information retrieval system for real
estate dealers would be desirable when the number of
business transactions is large and the file of available
homes is also quite large. A manual search of such a
large file may be tedious and, most important, may
fail to retrieve the desired information when it is
actually contained within the file. 1
In designing such a retrieval system for high-volume
dealers, the fact that many homes have quite similar
specifications must be borne in mind. The designer of
the system must strive for a workable balance between
lack of specificity and too great a degree of specificity
in creating records for such real estate files. Too great
a degree of specificity will result in a very limited
number of records from which to choose and too little
specificity may result in an unwieldy list which could
only confuse the customer. It is apparent that an
information retrieval system designed for this purpose
should allow for future modification so as to incorporate
the optimum degree of specificity in record and file
structure as determined through usage.
The HOMLST system is designed to be operated
from a remote termina12 and employs the indexedsequential file processing facility 3 to add, delete, and
retrieve records. These records each contain a unique
record-key, part of which is constructed manually,
and part by programming.
Two indexed-sequential disk files are used in
the operation of the HOMLST system. One file,
(HOMFIL), contains records of the homes for sale
and the other, (KEYFIL), is a file of sequential numbers used to create part of the record-key for each
record on HOMFIL.
The system consists of two main programs each
having several routines which perform various functions. One of the main programs, HOMUP, performs
updating functions and the other, HOMRET, is used
for retrieval of records from HOMFIL.
Record descriptions
The record description for a record in HOMFIL is
as follows:
THE HOMLST SYSTEM
HOMFIL utilizes a variable length record which
is accessed by a unique record-key containing 14
digits. The first 9 digit field is referred to as the
HOME-RECORD-CODE and is constructed as
shown below:
The HOMLST system is an information retrieval
system designed for the recording, updating, and listing
of homes for sale by a real estate dealer.
System requirements
DIGITS
determine price range of home-for
1-2
example 15 would be entered for a home
costing between $15,000 and $20,000;
20 for a home costing between $20,000
and $25,000, etc.
The HOMLST system, written in the COBOL
language, was designed to be implemented on the
RCA Spectra 70j46-G TSOS. The M70-590 disk
storage unit is required for file storage and file access
is achieved through a remote terminal.
541
542
Spring Joint Computer Conference, 1972
3
4
5
6
7
8
9
Location: North = 1, South=2,
East=3, West=4
Exterior: Brick = 1, Wood=2, Frame =3
Baths: 1 Bath = 1, 1};2 Bath=2,
2 Baths =3
Carpet: None = 0, Carpeting = 1
Bedrooms: 1 Bedroom = 1, 2 Bedrooms
= 2, 3 Bedrooms = 3
Carport: None = 0, Single = 1,
Double=2
Garage: None=O, Single = 1,
Double = 2
The remammg 5 digits are taken from KEYFIL
which contains sequentially generated, unique numbers
so as to make each record-key unique even in cases
where the home's specifications are the same as another's and the first 9 digits are identical. The following
example of a record-key illustrates how it was
constructed:
15121322000150
This record-key represents a home costing between
$15,000 and $20,000, located on the north side of the
city, with brick exterior, having two bathrooms,
carpeting, and three bedrooms with a double carport.
This was the 150th home record added to the file.
The following record description, using COBOL
field designators, shows the positions of the data fields
within the record:
01
HOM-REC.
02 DUM PICTURE X.
02 FIX-PRT.
03 HOM-KEY PICTURE X (14).
03 ACT-PRC
PICTURE 9(6) v99.
03 IRC
PICTURE S99
COMPUTATIONAL
02 VAR-PRT OCCURS 10 TIMES
DEPENDING ON
IRC.
03 DETAL PICTURE X (65).
DUM-this is a dummy character which, by its
position in the record, is used for deletion of
records. In COBOL, a READ followed by a
move of HIGH-VALUE to this data field with
a subsequent REWRITE will delete the desired
record.
FIX-PRT-this part of the record consits of fixed
length data fields.
HOM-KEY-this field contains the record-key.
ACT-PRC-this field contains the actual price
of the home.
IRC-this field, depending on its value, will
determine how many lines of descriptive data
about the home are contained in the record.
VAR-PRT-this part of the record is variable in
length.
DETAL-this field is used to enter descriptive
data about the home. In the record description
shown above, there may be as many as 10 lines
of descriptive data each containing 65 characters.
The record description for a record in KEYFIL is as
follows:
01
KEY-REC.
02 DUM2 PICTURE X.
02 KEY-NO PICTURE X (5).
DUM2-this data field is used to delete the
record from the file in the manner described
above.
KEY-NO-this is the record-key and also the
record itself. These records are 5 digit
numbers, sequentially generated for subsequent use in the formation of a unique
record-key for records on HOMFIL.
File construction and maintenance
The files comprising the HOMLST system are
constructed as follows:
KEYFIL-this indexed-sequential file, containing
only 5 digit unique numbers as records, is constructed
using the PRIMARY LOAD MODE of the indexedsequential file processing facility. A pre-determined
number of records is placed on the file during this load
routine.
HOMFIL-this indexed-sequential file containing
the records of homes for sale is constructed by entering
a previously determined HOME-RECORD-CODE
on a remote terminal during the execution of the updating program, HOMUP. The program then obtains
a 5 digit number from KEYFIL and deletes this number
from the file in order that no other record on HOMFIL
may contain this number. This 5 digit number is then
appended to the 9 digit HOME-RECORD-CODE
thereby comprising a 14 digit, unique record-key. The
actual price is then entered and finally from 1 to 10
lines of descriptive data about the home is entered as
part of the record.
HOl\t{LIST
The two above files are updated each time a home is
added to or deleted from HOMFIL. Detailed descriptions of the updating routines are contained in the
section on HOMUP's routines.
H omret' s routines
Operating instructions for this program and for
HOMUP are provided to an operator upon request.
Both programs provide the operator of the system with
simple and direct instructions in response to the
message: DO YOU WISH INSTRUCTIONS (YES
OR NO)?Other than providing operating instructions,
HOMRET has essentially only one routine whose
function is to retrieve records of homes upon request.
In response to the message: ENTER HOMERECORD-CODE, a previously constructed HOMERECORD-CODE is entered from the terminal. The
14 digit FULL-RECORD-KEY is displayed as the
first item in the home record followed by the actual
price and the descriptive data for the home. If there
are no homes matching the specifications denoted by the
HOME-RECORD-CODE, a message is displayed
stating this. After all homes fitting the desired specifications are listed, a message is displayed on the terminal
indicating such. The operator is then asked-if he wishes
to enter other specifications or terminate the program.
HOMRET has an error recovery routine to provide
for the entrance of a non-numeric HOME-RECORDCODE wherein the operator is informed of this fact
and asked to reenter the number.
H omup' s routines
HOMUP contains a CONTROL ROUTINE from
which the operator may branch to anyone of three
separate routines to perform various functions. These
routines are as follows:
1. ADD ROUTINE-the functions of this routine
were described under HOMFIL in the section on File
Construction and Maintenance.
2. DELETE ROUTINE-this routine provides for
the deletion of records from HOMFIL. The record-key
is entered from the terminal in response to the message:
ENTER FULL-RECORD-KEY. The record-key is
obtained from the listing of the home record by
HOMRET. It is the first item listed in the home record.
When this record-key is entered and a READ to
HOMFIL is issued, a move of HIGH-VALUE to the
543
first character in the record (the dummy character)
with a subsequent REWRITE, results in the deletion
of the desired record from HOMFIL. As part of the
delete operation, the 5 digit suffix of the record-key is
replaced on KEYFIL for reuse at a later time.
3. UPDATE ROUTINE-if a change in the selling
price of a home is required, this may be accomplished
in this routine. The record-key is entered from the
terminal and the record is retrieved indicating the old
price. The new price is then entered and a REWRITE
is issued thereby updating the record.
When the functions of the above routines are complete, a branch to the CONTROL ROUTINE may
be executed by the operator or he may terminate the
program.
There are several error recovery provisions in the
above routines. If a non-numeric HOME-RECORDCODE or FULL-RECORD-KEY is entered, the
operator is notified of this and asked to reenter the
number. If the actual price of the home entered is
non-numeric the same messages are displayed. Also,
when the price entered exceeds the range implied by
the first two digits of the HOME-RECORD-CODE, a
message is displayed stating this and the operator is
asked to reenter the price.
PROPOSED EXTENSIONS
Since many home specifications are sometimes
quite similar, a greater degree of specificity may be
required in constructing the HOME-RECORDCODE. This would require changing the length of this
subfield from 9 digits to the desired length. This could
be accomplished with little difficulty if the record-key
length would be made greater by increasing the length
of the suffix from 5 digits to possibly 10 digits. Hence,
when a lengthening of the HOME-RECORD-CODE
is desired, the suffix could be shortened thereby not
affecting the record-key length and the total record
length would also be unaffected.
EVALUATION
Retrieval of records using the HOMLST system is
sufficiently fast and the record provision of descriptive
data concerning the homes simulates the detailed
description found in most home listings. This provides
the customer with most of the detailed information
he requires. This provision also imposes little format
restriction when entering data for a record.
544
Spring Joint-Computer Conference, 1972
SELECTED BIBLIOGRAPHY
1 C T MEADOW
The analysis of information systems
New York John Wiley & Sons Inc 1967
2 Spectra 70 time sharing operating system (TSOS)
Data Management Systems Heference Manual IlCA Corp
Camden NJ June 1970
3 Spectra 70 all systems cobol reference manual
RCA Corp NJ June 1970
Organization of a natural resources
data hank system
by ALVIN J. SURKAN
University of Nebraska
Lincoln, Nebraska
INTRODUCTION
necessary to store as a time series such irregular entities as mapped areas of rock or soil type and land use
variations or descriptions of river systems and the
locations of natural boundaries of watersheds, lakes
and coastlines or sometimes artificial administrative
boundaries created by govern~ent agencies. After
it is clear how such data might be cast into a time
series form, it is possible to describe general algorithms
for performing operations on the series to accomplish
the transformation needed in analyzing the internal
structure and interrelationships of such geographic
entities.
If one is to accept that nearly all geophysical data
can be stored and processed in time series form, it is
necessary to show how a data bank system storing the
various series can be related to the acquisition system
and logically organized to now accommodate current
types of data and ideally, other data arising in the
future. The approach taken here for the design of such
a data bank system is an evolutionary one as indicated
in Figure 1. The results of this paper include a review
of relateds ystems, a formulation of objectives and the
identification of an approach to the decomposition of
the data base.
The growing dependence on electronic computers for
analysis of geophysical and other environmental data,
brings an increasing awareness that the organization
of these data in storage and retrieval systems is intimately connected with the acquisition systems and
analytic transformations the data are to undergo.
Current computer technology is almost totally dominated by serial storage and processing mechanisms.
This peculiarity of available hardware dictates a
design of data structures oriented toward the storage,
retrieval and analysis of time series.
Nearly every acquisition system, whether it consists
of automatic analog or digital recording instruments
or humans manually keeping records, generates time
HcricH that are subsequently analyzed as continuous
HcqucneCH. The subl"iequent analysis requires either
int.ernal tompadr-:;ons within sequences or intercompariHonH among other sequences collected in the same
general area. Consequently, an appropriate organization for such sequenced data should readily allow a
natural decomposition of the entire data base into
time series-like sequences of elements which are the
values of either time varying data at fixed locations
or of data differing at various geographic locations
and changing negligibly during the period in which
observations over a set of locations are made.
The organization of the blocks of time series data
generated by some acquisition system is relatively
straightforward since the acquisition device dictates
the sequencing. Attention must be given only to de:vising an indexing system that allows each such series
to be located whenever its space and time coordinates
fall inside a particular search window supplied to the
retrieval system.
The procedure for casting the geophysical data
specifying geographic variations into a time series form
is not so straightforward. For example, it may be
CONSTRAINTS ON THE ORGANIZATION OF
THE DATA BANK SYSTEM
The system must provide a data organization
flexible enough to accommodate geophysical, environmental or administrative information that is now useful
in connection with the natural resources of a state.
Emphasis must be placed on preserving the natural
groupings arising from proximity or other regional
factors which influence the sequences of acquisition or
use, such as the topologic connections within hydrologic
networks, geographic location within basin boundaries
or position with respect to a natural divide. The same
545
546
Spring Joint Computer Conference, 1972
provide the capability of identifying those subsets of
structures modeled by mathematical trees which influence a particular point in the modeled system or
those which are influenced by changes at a given point.
For example, one might program the computer to
indicate which points of a system are possibly responsible for pollution appearing at a specific point,
or in the case of a known pollution source, it might be
necessary to know what points could be influenced.
REVIEW OTHER
DATA SYSTEMS
FORMULATE
OBJECTIVES AND
IDENTIFY PARAMETERS
------------ ---------SYSTEM
DESIGN
....
SIMULATE
SYSTEM
BEHAVIOR
------------ --------IMPLEMENT
SYSTEM
CREATE
FILES
UPDATE
FILES
PARAMETERS
BANK
CHARACTERIZING
A
DATA
In describing a data bank system, it is convenient
to separate the parameters into two classes. The first
class characterizes the input and storage while the
second characterizes the output functions and internal
transformations that are associated with its operation.
Parameters identified in each of these classes are summarized in Table I.
After identifying these parameters, one then seeks
independent methods for finding what values apply to
a data bank system needed for the geophysical data of
a state. The data members will, in general, be labeled
time series-like vectors. The amount of data in each
consists of bit or character estimates for the size of
the label plus the total number of bits or characters
required for representing all the elements of the associated data vector. The total number of such vectors
will, of course, depend on how finely divided, on the
average, is the area of interest. For an area corresponding to an average sized state, one expects 105
square units of area could have varying data vectors of
importance. The amount of data in each vector will
typically be a few hundreds of characters or thousands
of bits. Thus, the most conservative estimates of the
amount of data that must be stored is 108 bits. In
practice one must expect about 1010 bits and at most
Figure 1
TABLE I
system should accommodate artificially grouped data
within the same framework as those data with natural
groupings. Artificially grouped data might, for example,
be based on arbitrary and idealized administrative
factors such as the positions of state or county boundaries or arbitrarily mapped survey grids, shorelines,
stream limits and ridges.
Various networks such as the mathematical tree
structure representations of drainage systems or administrative hierarchies, must be stored in some
representation which can be easily retrieved, updated
or analyzed. The analysis of such· tree structures must
CLASSr:S
Estimate Range
of Values
DESCRIPTIG:1 OF PARAMETER
Initial amounts of data
10 8 -10 12 bits
Rate of adding data
10 7 _10 11 bits/yr
Rate of data purging
0-10 7
Rate of updating of data value
10 6 _10 10 bits/yr
Levels of data categorization
Rate of arrival of search requests
bits/yr
levels
0.1-1.10 min
Number of search priority categories 6
levels
Documents retrieval rate
.01-.1
Number of types of document display
2-6
document/
minute
types
Organization of Natural Resources Data Bank System
1012 bits after continued data accumulation concurrent
with a maximum of purging of obsolete data.
The rate at which data will be added will increase
with time and therefore might best be estimated for a
particular time from the number of sources of data
multiplied by the average number of bits or pages
delivered by each. Again a conservative estimate
might be 500 sources, each delivering 2 X 105 bits.
These would yield 107 bits per year ora growth factor
of 0.1 in static or permanent data. This growth factor
is also reasonable for the continuously recorded time
series data, if it is assumed that effectively such data
would also have a ten year life and could be automatically purged to microfilm archives after that
period of time.
The purge rate will then also be a function of time
which is initially zero and then should grow to approach
the addition rate. Such growth will require a period of
time approximately of the order of the mean useful
lifetime for all non-permanent information.
The rate of modification or updating of values for
permanent data is estimated not to exceed 0.01 of the
static component of the data base. Thus, a time of 100
years would have elapsed before the entire base would
be renewed.
The number of levels of categorization of data could
be kept small. The categorized data members would
be vectors of typically 104 bits, the elements of each
being addressable only by index. This would mean the
number of logical routes or decision points leading to
all data vectors or stored series would be between 104
and 106. Suppose there were on the average a 10-way
branch or an organization tree having an average dispersion or bifurcation ratio of 10, only log 10104 = 4 or
at most log 10106 = 6 levels of classification would
suffice. An estimate of the number of levels of categorization needed is important because it is directly
related to the ease with which time series information
can be classified and retrieved. Classification is consciously or unconsciously imposed by the person presenting information to the data bank. Not more than
six different qualifiers each chosen from an alphabet of
ten or fewer letters or words need be specified to enter
or retrieve a vector or time series. This estimate can
serve as' a realistic guideline in the structuring of the
index for a properly organized, practical data bank
system.
~
ESTIMATES OF VALUES OF PERFORMANCE
PARAMETERS
The rate of arrival of requests for searches of the data
bank is most important, and in fact, is a self-dependent
547
parameter. Whenever the value of results of the search,
measured in terms of its completeness and freedom from
errors, compared with cost and time required is high,
the arrival rate for requests will increase. This will in
turn degrade the subsequent service of any system
operated close to its ultimate capability. For planning
purposes, one might arbitrarily select a request rate
which is consistent with the economics of storage for
the various data sequences in the data bank system.
On the assumption there are between 104 and 106
documents or time series stored in the system when
in operation and that such a system might cost $1000
to $10,000 per year to operate, it seems reasonable to
expect a request rate of 1000 to 10,000 per year or
~30-300/day or ~0.1-1.0/minute.
Priority categories for search could allow for a range
of search services and responses ranging from immediate with the system dedicated to a single user to
delayed service permitting economization resulting
from periods for the accumulation or batching of
search arguments. Six appropriate priority categories
might be (a) no waiting; (b) 1 minute; (c) 6 minutes;
(d) 30 minutes; (e) half day; and (f) daily.
Document retrieval rate might be estimated as 0.1
to 0.5 times the search rate. The number of classes of
document display will depend on what output terminal
devices are available. These might include the printed
page, magnetic tape, paper tape, cathode ray tube
photographs, and incremental plotters. Thus, control
signals or interfacing with at least six different output
devices must be provided.
DESIGN GOALS OR OBJECTIVES FOR
A FUNCTIONAL SYSTEM
The central reason for constructing a data bank
system is the concentration or channeling of the output
from a number of acquisition systems into a single
channel that leads to unique storage and complete
updating functions. The systems make nearly simultaneous modifications of what is stored and make it
feasible to detect duplication of information by independent sources. It then becomes possible to determine if specific information has been previously
introduced. These capabilities of a data bank system
provide the information needed for generating reports
on the current state or past changes in certain resources. The ability to determine which data are not
present provides the information directly needed for
planning data collection programs. Using the system
to provide the amount and location of resources makes
it possible for various strategies of resource manage-
548
Spring Joint Computer Conference, 1972
ment to be optimized with respect to certain objectives.
In the case of exhaustible or unreplenished resources,
the depletion rates of the remnants may be quantitatively monitored. This information can then be used
for making policy with regard to the updating of records
of licenses or other legal rights to resource utilization.
FUNCTIONS OF COMPUTER DATA
BANK SYSTEM
Three broad classes of functions that the system
must perform with the information handled by it are:
(1) storage, (2) retrieval, and (3) reporting. The first
function, storage, has two subdivisions, namely (a)
the classification of a series and (b) the writing of its
elements into machine addressable locations. The
classification aspect of storage facilitates the retrieval
and introduces local coherence into the storage system
that will permit data with similar space and time
coordinates to be obtained with a minimum of reaccessing of the storage medium. The writing aspect of
storage is the production of a machine-readable change
of state at the addressed locations of memory.
The retrieval of information proceeds in two phases.
The first, which is referred to as a search, identifies
the entries which satisfy the given search arguments
according to some criterion and indicates some of the
descriptive properties of each, such as the location,
size and the nature of contents. The extraction or
display phase of retrieval then copies the set or subset
of desired entries to an output unit which may make
an electronic record, a physical punched or printed
record, or a temporary image such as a cathode ray
tube display.
The third function, that of reporting, involves an
automatic use of the retrieval function for the purpose
of generating reports with statistical or other measures
summarizing the data present or indicating what data
are missing in a specified region and time interval.
The locations of a specific file entry or retrieval point
should not be available without a protective password.
A provision for enciphering and deciphering the data
in sensitive files using pseudo-random number sequences
should be available (Carrol 1970). The user should
be provided with a facility for creating personal index
files to be created for individual user's own applications. Data should be accepted by the system only if
it is accompanied by an automatic purge date. All
active system files should be backed up by external
self-contained files with both table of contents directory
and the data records.
OVERALL VIEW OF A DATA BANK SYSTEM
The key feature of a natural resources data bank
system is the high degree of structuring derived from
the geographic proximity in natural networks and
environmental factors such as geologic composition,
soil types and rainfall patterns. The total data bank
system involves the three components (Figure 2);
(1) personnel, (2) programs, and (3) hardware or
equipment. The personnel constitute an interface
between the acquisition system and the input devices.
They also demand that the system stores, searches for,
and retrieves data. The programs serve as a vehicle for
instructing the hardware to accept instructions from
the users. Additional functions that can be performed
by the programs include directing further data acquisition, reducing data, and preparing summaries
and reports (Figure 3).
It is expected that user's requirements can continue
tOe be met by direct communication of data from the
acquisition system and augmented increasingly by
the computer-based data bank system. The latter
should permit the generation of a central data depository making possible unique and complete updating
as well as automation in search and retrieval functions.
FEATURES REQUIRED IN A PRACTICAL
IMPLEMENTATION
The central feature of a data bank system that gives
rise to its value is the provision for sharing single copies
of data, programs and processing units. The system
can remain useful and manageable if it can be insured
that only one internal and one or more external backup
copies of a specific set of data from any given source
can be retained. Also, storage wastage must be minimized by the elimination of unallocated locations
through the use of chaining vectors and list structures.
Figure 2
Organization of Natural Resources Data Bank System
Figure 3
The creation of a data bank system, because of
changes in needs and computing systems, must be
evolutionary. It is proposed that effective steps are:
(1) review of other viable systems, (2) design a system
based on data acquisition and unmet needs, (3) simu. lation of the proposed system design, (4) implementation and use, and finally (5) a redesign or extension
repeated recursively, followed by steps 3 through 5.
ENTITIES RECOGNIZED IN THE DATA
BANK SYSTEM
One may recognize four distinct classes of natural
resources or environmental data, namely: (1) observa-
549
tory sequences, (2) labeled document-type objects,
(3) graph or mathematical tree structures, and (4) area
boundaries. Each entity upon undergoing appropriate
transformations can be reduced to series to be stored
by a computer. The observatory sequences are usually
numeric and require little altering other than the affixing of appropriate labels. The sequencing of the
elements or values constituting these entities remain,
at least within each stored data member, as supplied
by the acquisition system. Labeled objects refer to
documents with two specified source dimensions. For
storage purposes their representation must be decomposed into one-dimensional bit sequences which can
be used to reconstruct a display of the source. The
graph structures of most frequent interest in natural
resources systems are the trees representing drainage
networks. These may be decomposed into a binary
vector specifying the topology of a particular network
and auxiliary vectors corresponding with the types of
data associated with each link of the network as shown
in Figure 5(a). All such vectors have the same length.
Consequently, storing of graphs this way reduces to
storing matrices or families of regular sequences.
Finally, the fourth distinct entity that arises in natural
resources systems are area boundaries. Vectors of equal
length may also be used for specifying these by choosing
Figure 4
550
Spring Joint Computer Conference, 1972
TOPOLOGY-BOOLEAN
a
1
a a
1
a
1
J
J
DIRECTIOI1-1/L1'1mIC
LE:!GIHS-IIUi1E:i.IC
Figure 5a
to approximate a boundary of an area with a sequence
of linear segments forming a closed polygon. A pair
of vectors with length equal to the number of linear
segments can provide the values of coordinate pairs at
the terminus of each segment as shown in Figure 5(b).
The current word size of computers allows adequate
resolution for specifying the segments with all the
precision of currently used survey data.
AN ORGANIZATIONAL TREE REDUCING
DATA ENTITIES TO SERIES
Data, independent of the form in which it is presented
to a computer-based system, must for purposes of
computer manipulation be reduced to sequences of
bits representing characters or numeric words. The
effectiveness with which these data can be retrieved
and manipulated depends on how well adapted to the
applications is its reduction to the internal form stored
within the computer. Economy and rapidity in the
manipulation of data depend largely on the data structures chosen for representing the entities of interest.
A practical system should allow the naturally sequenced time series type of data such as observatory
records to be stored in their numeric form as directly
as possible. A data entity such as time series after
being labeled need only have its file entry indexed with
respect to geographic location, time, and appropriate
documentation.
Another type of data entity, referred to here as
labeled objects, may be utilized for storing such documentation. These labeled objects may also take on a
number of different forms of literal, numeric or graphical information. The common feature of the members
of this entity is their internal structure being essentially the sequences of markings· and control information required to reconstruct charts or pages of
symbols, print, tables, or line drawings. The possibility
of the further decompositions of the labeled object
type of entity is shown in Figure 4.
Natural resources are usually associated with locations or networks that are concentrated at points or
along lines. The points are frequently linked to at
least their nearest neighbors by some relationship
described by mathematical graph representations which
are very often tree structures. An example of a usually
low area-density tree is the system of converging
channels which make up drainage basins. It is necessary that in the acquisition and storage of the data
associated with such systems there be recognized a
graph or tree type of entity to provide a consistent and
organized way of coding and storing their linked data
in series form. It is then possible to formulate algorithms
to perform operations defined with respect to the systems they constitute. For example, one might define
operations which would correspond with the transport
of pollutants from a point in a network to downstream
points and identify the latter. Similar tree structures
may be needed for storing administrative linkages
important in organized data acquisition.
Finally, the fourth entity or data type recognized
to be important in geophysical and natural resources
information is that of the geographic area which is
most economically delineated by describing the path
of its boundary. These areas and the boundaries
representing them may be natural such as those of
watersheds and soil or rock types or artificial such as
those representing administrative districts or land use
patterns. In many cases the areas overlap or have
important memberships in larger areas. Such relationships can be established using appropriate programs
designed to operate on series representations of the
areas. These representations may be formed out of
vectors containing sequenced pairs of numbers corresponding to boundary segments.
CONCLUSIONS
The organization structure identifies a natural resources data bank system with flexibility to accom-
VERTEXCOORDlIIATES
91
4IL
Figure 5b
e2
4>2'"
ell
4>"
Organization of Natural Resources Data Bank System
modate environmental data within a standardized
framework designed to insure low redundancy and
high accessibility for regionally distributed data. The
central thesis for efficient storage and retrieval is a
classification based on the type of format or medium
available from the acquisition source and an indexing
based on the geographic and time frames of the data.
Four types of data entities are proposed, namely:
(1) observatory records, (2) labeled objects, (3) tree
structures, and (4) geographic areas. Each entity of
this classification is decomposed to terminal members
which point to the stored sequences or time series-like vectors. Such classification structure is aimed at
ideally structured hardware independence to be exploited for the efficient distribution or selective dissemination of geophysical data.
The current acquisition methods and uses of environmental data require a computer based storage
system that is organized to facilitate selective retrieval
and mapping or data displays. Important features of
the system include program controlled purging of
obsolescent data and objective program-implemented
measures that determine the potential value of particular data members. These two features are needed
for the judicious release and allocation of computing
resources. The actual implementation of such a system
will always be some compromise among cost, access
time, integrity of data, and the ease of use. Ease of use
refers primarily to data and updating but it is also
necessary that requesting a search or retrieval be
551
simple. Search programs serve either to locate available
data or indicate data not available. The retrieval
function may be used for acquiring statistics on data
values, for monitoring purposes, scientific studies, or
administrative report generation.
REFERENCES
1 B H BOOM
2
3
4
5
6
Some techniques and trade-offs affecting large daia base
retrieval times
Proceedings ACM National Conference 1969 pp 83-95
J M CARROL P M McLELLAND
Fast 'infinite-key' privacy transformation for resource-sharing
systems
AFIPS Conference Proceedings Houston Vol 37 1970
November 17-19 1970
G DODD
Elements of data management systems
Computing Surveys ACM Vol 1 No 2 1969
H T FISCHER
Synagraphic mapping system (SYMAP)
Harvard Laboratory for Computer Graphics
R L SHELTON
A photo interpretation and computer graphics for land use
and natural resources inventory
Center for Aerial Photographic Studies Cornell University
Ithaca N ew York American Society of Photographmetry
Proceedings of 34 Annual Meeting 1968 March 10-15
pp 198-204
D H SWANN P B DuMONTELLE R F MAST
L H VAN DYKE
ILLIMAP-A computer-based mapping system for Illinois
Circular 451 1970 Illinois State Geological Survey
THE COMMAND TERMINAL-A computerized law
enforcement tool
by DAVID M. HUDAK
Automation Technology, Incorporated
Champaign, Illinois
INTRODUCTION
couraged from using the system because he usually cannot obtain responses in the time frame that he requires. 1
The most crucial problems being faced by local law enforcement agencies today are the collection, analysis,
and utilization of police-oriented data. Information is
the life blood of any law enforcement agency, and there
exists a continuous requirement to collect and produce
data which provide information useful to operation,
planning, records maintenance, and management decision making. l
Police data may occur in many forms; i.e., contact
reports, patrol observations, fingerprint files, arrest reports, warrant files, or other identification files. Government agencies at the federal and state level are currently collecting information and making it available to
local law enforcement agencies via police teleprocessing
techniques (see Figure 1). The NCIC (National Crime
Information Center) operated by the Federal Bureau of
Investigation in Washington, D.C. is an example of this
type of system. It can best be described as a computerized index to documented police information concerning crime and criminals of nationwide interest. 2 Over 25
states now have their own computerized law enforcement systems modeled after the NCIC.
With information pertaining to criminals and criminal activity being maintained at the federal and some
state levels, it is to the advantage of police officers to
have access to that information whenever possible. If a
patrol officer at the scene of an incident or investigation
is able to query these data banks at the state and
federal levels for the "wanted" status of vehicles or
people, he will be able to use this information to make a
better judgment of his situation. The timeliness of this
inquiry and subsequent response is extremely important, and should be typically less than three to four
minutes. Unfortunately, most of the systems currently
in use do not accomplish this in an efficient manner,
and thus the prime user, the patrol officer, is dis-
THE DISPATCH CENTER
The patrol officer's contact with supporting resources
is through the radio or dispatch center. Almost all of his
assignments and emergency directives come to him via
radio communications and under the control of a radio
dispatcher.
Radio dispatchers, monitoring the activities of a
widely scattered fleet of vehicles, are the recipients of a
vast amount of vital information which has to be sifted,
organized, and made available for use in making operational and administrative decisions. The dispatcher's
effectiveness depends critically upon the ability of his
information handling systems to supply critical data as
quickly as possible, with a minimum of wasted effort.
The functions of the dispatch center have changed
tremendously in recent years. With the advent of
modern communication techniquef) which can effectively
place a two-way radio on every patrol officer, and with
Inquiries
File Entries
Status Messages
Crime Reports
G
Assignments
Alerts
Net Messages
Responses
Figure I-General information flow
553
554
Spring Joint Computer Conference, 1972
the mobile capabilities of law enforcement forces such
as patrol cars, motorcycles, scooters, and even helicopters, the dispatch center has become a scene of busy
and sometimes frenzied activity, with a corresponding
increase in paperwork. 4 lVlost radio rooms or dispatch
centers are not prepared to handle the current volume
of activity that exists in law enforcement agencies
today. They are often overcrowded, understaffed, and
are usually working under an antiquated system that
has been "updated" only occasionally over the past
years. Although the dispatcher is the field officer's link
to other law enforcement resources, responses to their
requests for information are frequently delayed minutes,
and sometimes hours.
Another important function of the dispatcher accepting complaints or requests for service from citizens is
assigning the proper personnel to those incidents from a
list of available resources. Recent studies show that 65
percent of all crimes can be solved if the police respond
within two minutes of an occurrence of the crime, but if
they are delayed up to five minutes, this efficiency drops
to 20 percent. 5 In making these assignments, the dispatcher usually makes use of policy and procedure guidelines, experience, and sometimes visual aids such as
status boards. It is necessary that he have at his finger
tips the status, location, and degree of availability of all
of his forces, in order to assign the correct resource to
each task. 6
RADIO TICKETS
The flow of data through a dispatch center is usually
controlled by paper forms called radio tickets (or dispatch tickets, complaint tickets, etc.). This is a data collection method that has been used in police departments
throughout the country for a number of years. As much
as they may vary from department to department, radio
tickets are generally used to record some basic facts
about each assignment, event, or incident that requires
the use of the police departments' primary resource,
manpower.7 Some of the most common elements of the
radio ticket include: time complaint was received, type
of incident, location of incident, unit number assigned,
time dispatched, time of arrival on scene, a document
control number, time assignment was concluded, etc.
These tickets may be completed entirely by the dispatcher as the incident progresses, or may be later filled
in by the patrol officer when he returns to the station.
In larger departments the radio tickets are initiated by
complaint clerks who take the complaints from the
public and pass them on to dispatchers, who assign the
mobile units and complete the radio tickets.
Current manual radio tickets provide a very important collection device in the data management procedures of a law enforcement agency. However, there
are some serious drawbacks to their use. For instance,
if the data are going to be input to a law enforcement
management information system, then the information
on the radio ticket must be recorded twice, once by the
dispatcher as it occurs, and again by a clerk who codes
the information into machine-sensible form. In some
cases the physical environment of the dispatch room requires that some mechanical method be used to transport the radio ticket from one position to another, thereby increasing the time from receipt of complaint to the
time the unit is dispatched.
Should a patrol officer wish to make an inquiry on a
wanted person or car, the request for information must
be logged on a radio ticket, and the dispatcher must
relay the request via a terminal to the state or regional
data base inquiry system. The dispatcher must input the
inquiry in a very rigorous format, because errors will
cause it to be rejected and necessitate its reentry. Not
only is this activity frustrating to the operator of the
terminal, but in emergency situations it could endanger the patrol officer who has asked for this informa. tion NOW and is unable to get it.
It is readily apparent that there are many stumbling
blocks between the information system and its user, the
officer on patrol. The system often appears unresponsive
to his needs, so he tends to use it only when absolutely
necessary, and not as part of a normal operating sequence. To cope with these problems, the attack must
be launched at the nucleus of the difficulty, the radio
room itself, its operating personnel and procedures, and
the operator-information system interface. The radio
dispatcher must be provided with an integrated mechanism for handling his normal dispatching and data collection duties, and also for interfacing with the automated information system in an efficient manner. A
system has been constructed which will solve many of
these problems. This system is called the COMMAND
TERMINAL.
FUNCTIONS OF THE COMMAND TERMINAL
SYSTEM
The basic COMMAND TERlVHNAL System is composed of a minicomputer, a disk, a visual display device
(CRT), a standard keyboard unit, a special function
keyboard unit, a standard teletypewriter, and a set of
operational computer programs. While the system is
welded together logically into a total operating package,
the dispatcher is physically confronted with only the
The Command Terminal
visual display device, the two keyboards, and infrequently, the teletypewriter (see Figure 2).
In many cases the visual display device can be integrated into the radio console itself, so that it is immediately in front of the dispatcher when he is seated
in his normal operating position. The two keyboards are
placed on the console desk top in front of the dispatcher.
The teletypewriter, which is used primarily for hard
copy output, may be located in various places, depending upon the department's normal operational procedures. All other equipment may be located in a separate
555
COMPLAINT ~
OISTRICT ~
NUMBER ®
RECEIVED ®
~~?TU~TS OSP'O @
OUT &ISPO~~T~H
LOCATIOU, ETC. @
ST
MK ~
6
PL YR ,
CR YR
2
HAME
OOB
1
10 TYPE @
NR @
STL @
®
CLR @)
R/S@
ST @
H~
@
@
Completed
Radio Tickets
(Optional)
5
DISK
10
r -
Type of complaint
14
License Plate Number
Document Control Number
15
Model Year of Car
Applicable Patrol District
16
Make of Car
Time Complaint Received
17
Style of Car
Units Responding to this Incident
18
Color of Car
Disposition Code
19
Name of Person
Mobile Unit Identifier
20
Race/Sex
Dispatched Time
21
Date of Birth
Out-of-service Time
22
Type of ID Number Following
In-service Time
23
State, if Driver's License Number
11
Locat ion of Incident
24
ID Number
I
12
License Plate Year
25
Additional Comments
I
13
License Plate State
{JiJaper
Tape
I
------+-
Figure 3a-Blank radio ticket
I
:
INCOMING DIRECTED MESSAGES
FULL TEXT OF INQUIRY RESPONSE
~@
L_~
OUTPUT
OPTIONS
TELETYPE
KEYED-IN
DATA
ALPHANUMERIC
KEYBOARD
SYSTEM
COMMANDS
FUNCTION
KEYS
MOBILE. UNIT STATUS
INQUIRY RESPONSE
RADIO TICKETS
BACKLOG STATUS
stead, the radio ticket is an electronic form appearing
before the dispatcher on a display device. The dispatcher fills in some of the blanks by utilizing a keyboard, while the system assists him by filling in others
automatically (see Figure 3). In some cases, when data
fields have been filled in by the dispatcher, an auto-
CRT
Figure 2-Information flow for COMMAND TERMINAL
SYSTEM
room with the communications equipment, or in any
other suitable place. The system is designed to replace,
on a plug-for-plug basis, the present real-time information system terminal. Since the COMl\1AND TERl\1INAL can emulate the previous type of terminal, no
modification to the real-time system's programs is
necessary.
With the COMMAND TER1VIINAL, radio tickets
are no longer pieces of paper to be completed in handwriting, time stamped, filed in slots, and ultimately keypunched to permit further analysis by computer. In-
COMPLAINT 1023
HUMBER Q23S592S0
DISTRICT
2
RECEIVED 1629
ALL UNITS
A2
AS K9-2
DISPOSITION
UNIT
AS
OSP'O 1623 OUT 1643 IN
LOCATION, ETC. FIGHT AT SAM'S BAR - CORNER OF
FRINK AND RUSSELL
PL YR 71
ST OH
NR 729 4963
CR YR
11K
STL
CLR
HIT
NAME SAMUEL J. SMITH
R/S WM
OOB 10-18-36
10 TYPE SS
ST
HR 039-14-3952
MISS
**
**
**
**
Figure 3b-Radio ticket in progress
556
Spring Joint Computer Conference, 1972
IN SERVICE •
1 1697
Al
3 1607
A3
6 1641
F6
10 1609
Ale
12 1689
A12
13 1649
813
14 1649
B14
16 1609
A16
A22 CENT 1699
064 SPEC 1619
A6S SPEC 1619
OUT OF SERVICE •
F1 1019 1616
F2 1019 1617
AS 1028 1634
A23 1014 1619
C64 HH9 1618
TAC 1 1050 1613
Cl
84
1 1697
4 1609
a 1609
11 1609
13 1609
14 1609
IS 1609
16 !~.;a
BS
All
AIJ
A14
AIS
C16
A24 sou 16e~
A83 SPEC 1619
K9-4 SPEC 1611
A2 1023 1623
A4 1019 1616
AS 1023 1643
A2S 1027 161S
B7G la2S 1615
B21 113513 1613
DEPRESS MORE TEXT OR OTHER
-
Figure 4-Mobile unit status
matic edit is performed by the system to check the
validity of the data.
Tickets may be temporarily filed a way in the system's
computer memory at any time to permit the dispatcher
to process or initiate other tickets. These stored-away
tickets may be recalled at will by the dispatcher until
such time as the particular assignment has been concluded and the mobile unit is back in service.
A mobile unit status display is maintained on an upto-the-minute basis by the system as a by-product of
processing the radio tickets. Thus, the dispatcher can
at any time press one function key and review the in- or
out-of-service status of all cars under his command,
along with some additional facts about various units
(see Figure 4).
As the dispatcher records the particular beat or
patrol area identifier for an incoming complaint, the
system will automatically recommend a specific mobile
unit to handle the incident. The recommendation is
based on a priority structure established initially by the
department and, naturally, also considers the present
availability status of all units. On more sophisticated
models of the system, it will be possible to automatically
translate a street address into the appropriate beat
number, thereby saving the dispatcher this task.
The dispatcher also has the option of placing a new
incident on backlog status, instead of assigning it immediately to a unit. If he does, the system automatically
assigns the ticket a priority based on the type of incident, and backlogs it for future reference. Subsequently,
it will be brought to the attention of the dispatcher as a
logical unit becomes available. A status report on the
backlog can be viewed at any time by the dispatcher
(see Figure 5).
As name and vehicle checks come in from the mobile
unit handling a specific incident, the dispatcher need
only fill in the necessary fields on that unit's radio ticket.
The system then automatically formats this data into
the proper inquiry language, and transmits the resultant inquiry to the real-time system.
As a safety feature for the man on the street, the system contains a "watchdog timer" which notifies the
dispatcher if no contact has been made with a particular
unit within some predetermined amount of time. The
amount of time permitted before an alert message is
displayed can vary, depending upon the type of incident
being handled.
Complete radio tickets, being recorded originally in
machine-sensible form, can be sent directly to the
management information system computer if it is capable of accepting data this way, or it can be recorded on
any type of output medium desired, such as paper tape,
punched cards, or magnetic tape.
Directed or point-to-point messages coming to the
agency through the real-time-information/messageswitching system are automatically routed for output
to the teletype by the COMMAND TERMINAL's
small computer. This precludes interference with the
dispatcher's normal operation. Outgoing directed messages can be sent from the dispatcher's visual display
unit, or the teletype. In either event, the system will
handle all necessary formatting and the insertion of fixed
message header elements.
SYSTEM CONFIGURATION
As mentioned before, the basic system consists of a
minicomputer, a disk, a CRT with a standard keyboard,
------------------------------.---------,
REQUESTS FOR SERVICE
DCN
INC BEAT TIME
PRIORITY 1
13 1637
8253 1053
5 1637
8255 1010
8249
6234
DCN
INC
1053
1005
BEAT
8
CENT
TIME
1620
1637
PRIORITY 3
8252 112187
8257 leaa
8246
8256
92sa
1021
1044
1065
SPEC
8
RICH
1617
1638
1638
PRIORITY 2
sou
17
1636
163a
TO ASSIGN BACKLOG.
PRESS SKIP
Figure 5-Backlog status
The Command Terminal
and a function keyboard. One of the design goals in the
development of the COMMAND TER]VIINAL was to
achieve a satisfactory price/performance relationship
with a sound functional system. The Honeywell H316
computer was selected as the system CPU. The Engineered Data Peripherals 3032 disk was interfaced inhouse, and the basic sector size set at 128 16-bit words.
This sector size was defined so as to contain a single
radio ticket with an average number of entries, and to
minimize the number of sector transfers when executing
program overlays. The CRT used is a TEC Model 400
with a complete set of edit functions and standard alphanumeric keyboard. The special function keyboard was
built in house and merely converts the dispatcher's
finger stroke into an 8-bit character. All of the system
functions are implemented by programming.
All of the computer programs were coded in DAP,
the machine assembly language of the Honeywell computer. A disk-based monitor was designed to control
the disk-resident overlay processors and data storage.
Almost all of the data being handled are maintained on
the disk. This includes completed radio tickets, radio
tickets in progress, unit status tables, patrol area status
tables, input and output message queues, and other
user-specified information that needs to be maintained
in real-time.
Due to the variety of data base structures and the
individuality of each law enforcement agency, a major
design goal was modularity of function programs. It is
now a minimal effort to design and implement a tailormade system to any agency's specifications. Parameters
such as radio ticket format, patrol area labels, response
patterns, and even incident priorities can be specified
during an installation by a short system generation procedure.
557
DISK
(
DISPATCHER)
(
DISPATCHER)
Figure 6-Medium-sized city configuration
matting of already developed character streams, and is,
therefore, relatively easy to implement.
SUMMARY
EXPANDABILITY
The basic system is easily expandable both in core
and disk size. For larger installations that require more
than one dispatcher station, additional CRTs and keyboards may be added to the system (see Figure 6).
However, each additional dispatcher station approximately doubles the processing requirements of the system, and therefore usually requires additional core and
disk space in order to guarantee acceptable interaction
of the dispatcher with the system. "Acceptable Interaction" is defined as the system's response to data input or action by the dispatcher, and has a maximum
time lapse of two seconds. The COMlVIAND TERlVIINAL interface to a police real-time information system
is usually via a modem and requires only specific for-
We have described a system that has been designed to
facilitate the flow of police information through the
dispatch station of a typical law enforcement agency.
Particular attention has been given to system modularity, flexibility, and ease of modification for varied
installations. Use of a general purpose computer as the
system controller guarantees ease of expandability when
future "add-ons," such as mobile teleprinters and automatic vehicle monitoring devices, become available.
These two items would serve to automatically close the
loop for an integrated command-and-control system. 9
The COMMAND TERlVIINAL has proved itself a
capable tool in a real-time computer-oriented dispatch
environment. It is valuable because any tool that collects and organizes data in a complicated and changing
fact situation is a significant aid to judgment. 1o And that
558
Spring Joint Computer Conference, 1972
is the goal-to provide a tool for our law enforcement
officers.
REFERENCES
1 P M WHISENAND
T T TAMARU
A utomated police information systems
John Wiley & Sons Inc N ew York 1970
2 Federal Bureau of Investigation
NClC operating manual
Revision G September 1969
3 P J PITCHESS
New computer based dispatching system cuts response time
The Police Chief Volume 38 No 2 pp 8 58-59
4 E G COLUMBUS
Management by systems
The Police Chief Volume 37 No 7 pp 14-16 July 1970
5 C M KELLEY
News article
Datamation p 16 December 1970
6 R J RIEDER
Command and control for law enforcement
The Police Chief Volume 37 No 7 pp 24-29 July 1970
7 P M WHISENAND T T TAMARU
A utomated police information systems
Chapter 6
8 D M HUDAK
(Internal Communication)
Automation Technology Incorporated 1970
9 S A YET SKY J D HODGES JR
Field communications for command and control
The Police Chief Volume 37 No 7 pp 34-42 July 1970
10 P M 'WHISENAND T T TAMARU
A utomated police information systems
pp 198-199
Experience gained in the development and use of TSS
by RICHARD E. SCHWEMM
IBM Corporation
White Plains, New York
INTRODUCTION
SYSTEM STRUCTURE
Six and a half years have elapsed since W. T. Comfort
described TSSj360 to the 1965 Fall Joint Computer
Conference. 1 Since that time, much has been learned by
IBM and its customers about time-sharing, about
TSS, and about large-scale, interactive systems in
general. Scores of people have worked with the system;
dozens of articles have been published; it would clearly
be impossible to put in one paper a comprehensive
answer to the question-what has been learned developing TSS? Yet, with the availability of Release 8.1,
the major development work on the system has been
completed, and this is an appropriate time to take stock
of where we have been, where we are, and where we
might go from here.
One summary paragraph of that 1965 paper says the
following: "This report attempts to give an overall
picture of the Systemj360 Model 67 Time-Sharing
System, its system design, and major hardwa!e ~nd
control program characteristics. The unique comblnatlOn
of hardware and software objectives makes a very
complex problem, for which a simple and efficient
solution is desired-a difficult task at best." Indeed,
bringing TSSj360 to the marketplace and making it
productive in customer installations has been a very
difficult task, both technically and financially.
.
No attempt has been made in this paper to gIve
detailed technical descriptions of programming systems
problems and solutions. Instead problems have been
described in a general way, their impact on the system
discussed and the strategy for solution outlined along
with the' results obtained. Four major areas will be
discussed:
Version 1 of TSSj360 was released in October, 1967.
Use for experimental, developmental, and instructional
purposes was advised. By the fall of 1968, A. S. L.ett
and W. L. Konigsford were able to report2 on a verSlOn
which was more stable, performed better, and contained
more function. Based on this progress made during the
first year in the field, plus progress anticipated ~r?m
items designed and then in development, a very pOSItive
view of the system was presented.
Several important lessons had emerged from the
TSS experience by this time. It seems clear that the
proper way to construct a system of this type is to build
a small hard-core base first, and add function later.
As Lett and Konigsford put it-"The initial emphasis
was on building a stable system, followed by extensive
measurement-and-analysis efforts to identify potential system modifications."
The same paper reported that the design of the TSS
Resident Supervisor had proved sound and remain~d
essentially as described in 1965, a statement as va~ld
today .as it was in 1968. On the other hand, major
portions of the original design had to be abandoned for
the simple reason that they were unacceptable to the
Users. One example of this was the replacement of the
original rigid set of commands with Command System
II.3 Another was the replacement of the system's
hard-coded scheduling algorithm with an extremely
flexible Table Driven Scheduler.4 The important thing
here is not that the original design was unacceptable,
but that a communication channel was open from the
Users to TSS Development, and that the latter was
.
t s. *
responsive to the former ,s reqUlremen
• Lessons Learned about System Structure
• Lessons Learned about System Performance
Analysis
• Lessons Learned about Software Development
Tools
• Lessons Learned about Management of Software
Development
* In both cases cited as examples, Users made strong technical
presentations. T. A. Dolotta of Princeton University and
A. Irvine of System Development Corporation made a "Proposal
for Time-Sharing Command Structure" at SHARE in August,
1966. The basic thinking behind table driven scheduling came
from F. G. Livermore of General Motors Research.
559
560
Spring Joint Computer Conference, 1972
The table below displays the functional buildup of
TSSj360 by release:
TABLE I-Summary of Major Functions Added to TSS/360
Date
Release
2/1/68
4/15/68
1.1
1.2
7/1/68
2.0
Major Functions Added
(Incremental reliability improvements only)
(Incremental performance improvements
only)
• Support for Extended Address Translation
(32 bit)
10/21/68
Date
1/20/69
7/8/69
10/15/69
3/31/70
Date
5/15/70
6/30/70
On Model 67 equipped with the special
feature, users can address up to 4096
virtual memory segments.
• Multiple Sequential Access Method
(MSAM)
This is a special access method for card
equipment and printers which allows a
single task (BULKIO) to process all
spooling operations.
3.0
• Command System II
This system provides a consistent command syntax, an extensive default and
profile facility, a general editing capability, and allows users to define their own
commands and call programs directly.
Release
Major Functions Added
• Time Sharing Support System (TS3)
A Virtual Support SUbsystem executes in
parallel with other TSS operations, allowing system programmers to access and
modify the privileged, shared Virtual
Memory; a Resident Support SUbsystem
provides the same facility for the resident
supervisor in a non time-shared mode.
4.0
• Table Driven Scheduler
This technique provides installation control and dynamic regulation of scheduling
parameters, for complete flexibility in
obtaining optimum scheduling balance
within and among tasks.
5.0
• Support For Duplex Configurations
This was the first system release which
was tested on and suitable for a multiprocessing configuration.
• Virtual Access M eihod I I
This rewrite of VAM provides more
efficient handling of physical devices,
ability to create duplicate data sets, and
an overall improvement to data set
integrity.
5.1
(Incremental human factors improvements
only)
6.0
• Resident
Terminal
Access
Method
(RTAM)
Removing TAM from shared virtual
memory reduces paging which i'lignificantly improves conversational task
performance.
12/17/70
10/1/71
• Multiple Terminals per Task (MTT)
A large number of users can share the
same task and the concomitant overhead.
The effect is the addition of a generalized
way to add subsystems.
Release
Major Functions Added
6.1
(Maintenance only)
7.0
• PL/I Compiler
A version of the OS/360 F-Ievel compiler
is modified to operate within TSS.
• Remote Job Entry
Non-conversational job streams can be
introduced into TSS from a remotely
located work station; spooling to/from
the work station is also provided.
8.0
(Incremental improvements only)
8.1
• Dynamic Catalog
The user portion of the master catalog is
made a working catalog for the duration
of the user's task, eliminating contention
for the master catalog.
• Page Table Paging
Demand paging of page tables allows
effective use of very large virtual
memories.
This functional buildup was accompanied by a
steady improvement in performance and reliability.
The performance picture is discussed in detail in a
subsequent section. To date, a total of 2442 program
errors detected by Users have been corrected.
Figure 1 displays the system size as a function of
release. It is worthy of note that only the addition of
the PLjI Compiler caused a significant increase in
system size.
SYSTEM PERFORMANCE ANALYSIS
The economic viability of any system is determined
by a complex equation which combines price, performance, and the value of function. Ii Since a given set of
hardware has a fixed price, and a given set of software
functions appear to a User to have a constant value,
performance is the critical factor in determining success
or failure. A simple example will illustrate this:
Let us assume that an interactive system operates
on a configuration that costs $1,000,000 per year.
Let us further assume that users feel that each
professional employee using this system. will
double his productive output and that an average
employee of this type costs $30,000. Then the
value of the system is a simple function of how
many users it can support-if it supports 33 or
fewer, it will be a loser, 34 or more a winner.
Experience Gained in Development and Use of TSS
During the development of TSS/360, a comprehensive scheme for treatment of system performance
evolved. The elements of this scheme are:
• Establishment of Performance Objectives
• Creation of External Performance Measurement
Tools
• Creation of Internal Recording Tools and Appropriate Data Reduction Facilities
Performance objectives
How well will the system perform the functions it
provides? This simple question receives a complex
answer. TSS/360 is designed for conversational use,
batch use, and a mixture of the two. A performance
objective was established for each type of use. The
conversational objective is the most difficult to describe
and of greatest interest here, so our discussion will
be restricted to it.
Basically, conversational performance is defined as
the maximum number of tasks which the system will
900
561
support with acceptable response time. This very
general definition is made more specific by creating a
benchmark terminal session and dividing the interactions created by the session into three classes-trivial
response, non-trivial response, and data-dependent
response. Acceptable response to trivial commands
(such as text entry) is defined as four seconds. Acceptable response to non-trivial commands (such as
data set creation) is defined as 7.5 seconds. Datadependent commands (such as compilation) have no
specific acceptability criteria. With this definition of
conversational performance, we have a constant,
calibrated yardstick that answers the performance
question.
Here we should point out that no User of TSS accepts
our benchmark terminal session as typical of his conversational work load. :\Iost have specified their own
benchmarks. However, there is general agreement that
the definition of performance is adequate. We have a
yardstick; the users have metersticks; we are in fact
measuring the same thing.
The initial conversational performance objective
established for TSS/360 was to support 40 tasks running
the benchmark terminal session on a configuration
composed of 1 processing unit, 512K bytes of memory,
1 paging drum, and disk modules on 1 channel. Subsequep.tly, objectives for larger configurations were
established.
External performance measurement tools
TSS operates in an extremely dynamic environment,
and the load imposed upon it by live users is characterized by peaks and valleys of activity and demands
for services. Yet, for performance objectives to be
useful, they must be measurable, and the measurements
must be repeatable. To achieve this, a measurement
driver was created to simulate the actual environment
under controlled and reproducible conditions.
Shown schematically in Figure 2, the driver has the
following characteristics:
r-------
I
I
I
I
I
I
600
I
I
I
I
I
I
I
I
I
500
,
I
I
.....- __ .....r- __ ...... - - 4
Total System Modules
300
500
200
100
1.0
1.1
1.2
2.0
3.0
4.0
5.0
5.1
6.0
6.1
7.0
TSS/360 Release
Figure I-Size of TSS/360 as a function of release
8.0
8.1
• It interfaces with the system in the same manner
as actual terminals and, to the system, appears
indistinguishable from them.
• It is capable of bringing the system up to a stable
load level and keeping it there during the measurement period in order to eliminate starting and
stopping transients from a measurement.
• It is capable of recognizing the expected system
response for each transmission and contains sufficient logic to take appropriate action for any
response received.
562
Spring Joint Computer Conference, 1972
Conversationall--_ _--t Measurement
Benchmarks
Driver
I--_-tlvlt::a;)u
Terminal
Simulator
Data Sets
Communication
Link
Transmission
Control
Unit
Disk
Storage
Disk
Storage
Time
Sharing
System
Conversational performance is measured by executing
a series of driver runs varying the number of tasks for
each run. A curve is then constructed which represents
response time as a function of the number of tasks. Such
a curve for TSS Release 6.0 is shown in Figure 3.
The measurement driver developed by IBM runs on
a System/360 Model 40. Several Users of TSS have used
this system to evaluate system performance on their
own benchmarks. A second measurement driver has
been developed by Carnegie-Mellon University. This
driver has the advantage of running on the System/360
Model 67 with the version of TSS under study. Although
compensation must be made for the system resources
devoted to the driver function, the Carnegie-Mellon
Simulator (SLIN) is compatible in script and timing
characteristics with IBM's, and the output produced
is comparable.
I nternal recording tools
Disk
Storage
Disk
Storage
between machine-driven transmission rates and
real keying rates.
• It records and time-stamps all transmissions in
both directions on all lines, together with the
control parameters and other such data, to allow
data reduction and analysis at a later time.
• It is capable of terminating a run, based upon
cut-off criteria specified for that run, to avoid
wasteful use of machine time.
• It is data directed in its operation, so that not only
the transaction to be transmitted but also the
control of the individual delays between each
interaction can be specified in the conversational
benchmarks, in accordance with the measurement
rules.
Drum
Storage
Figure 2-Schematic view of TSSj360 measurement driver
• It is capable of recovery from at least the "ordinary"
kind of unexpected response, such as might result
. from transmission errors .
• It accepts as a parameter, a "human keying rate"
for each "terminal" to adjust for the .difference
Answering the question "how well is the system
performing?" from an external viewpoint provides
little insight into the question "how can performance
be improved?" For this task, internal recording tools
must be used to obtain knowledge of the internal
operation of the programming system and of how that
system utilizes its hardware facilities. The basic measurement and recording tools used by TSS Development
are Systems Performance Activity Recorder (SPAR), 6
Systems Internal Performance Evaluation (SIPE),7
and Instruction Trace Monitor (ITM).
The System Performance Activity Recorder (SPAR)
is a one-of-a-kind hardware recording system. It is
hardwired to the system being monitored and does not
cause any degradation in performance. * SPAR can
* Similar capability is provided by IBM's System Measurement Instrument Unit (SMI).
Experience Gained in Development and Use of TSS
I
/
_.L
/
4
563
512 K Memory. 1 Drum
1 Disk Channel
CI)
-g
3
o
(,)
Cll
CI)
.S
Cll
E
i=
2
1 M Memory. 2 Drums
2 Disk Channels
o
------.-----.------r----~----_,------r_----r_----~----~----_r----~~
10
20
30
40
50
60
70
80
90
100
__
110
Conversational Tasks
Figure 3-TSSj360 release 6.D response to trivial commands as a function of number of tasks
provide accurate measurements of system facility
utilization. The facilities monitored for TSS/360
include the CPU, processor storage, I/O channels, and
direct access devices. SPAR is used to provide the
following types of information:
• Time utilization of the system hardware facilities
• Counts and time relationship of indentifiable
events such as:
• Time-slice ends
• Pages transferred between devices
• Entries to a module
System Internal Performance Evaluation (SIPE) is
a software recording system that produces a degradation
of approximately five percent in system performance.
Hooks in the resident supervisor cause information to
be collected and written on tape. The internal actions
of the supervisor are then available for later data
reduction. SIPE is used to provide the following types
of information:
• Time utilization of system hardware facilities
• Space utilization of processor storage, drum,
disk storage
• Counts of system events
• Time relationship of important internal events in
the supervisor
The Instruction Trace l\10nitor (IT::\1) is a hardware
and software combination that causes every instruction
executed to be written in sequence on tape. The instruction sequence in resident supervisor or virtual memory
is thus available for later data reduction. It should be
noted that ITM causes a relatively large degradation in
system performance by increasing system running time.
ITM is used to provide the following types of information:
• Time sequence of virtual memory modules executed
and referenced
• Time spent in each module
• SVC's issued from each module
With these tools, and with an appropriate set of
reduction programs, virtually any question dealing \vith
the internal system performance can be ans\vered.
Access to information of this type, allows an intelligent,
aggressive program of performance improvement to be
carried out. The results of such a program are shmvn
in Figure 4.
One final point should be made about internal
recording tools-they have been as valuable to Users
as they were to the development organization. As
mentioned earlier, Users have their unique workloads,
and TSS's completely flexible scheduling technique is
most effectively used with detailed knowledge of how
564
Spring Joint Computer Conference, 1972
reduction, and the monitoring of tasks that are imposing an excessive load upon the system, with the
possibility of changing priorities and scheduling parameters for such tasks.
100
90
1 M Memory, 2 Drums
2 Disk Channels
SOFTWARE DEVELOPMENT TOOLS
80
"Give us the tools, and we will finish the job."
Looking back over six years much can be said
about the tools necessary to develop a system such as
TSS, and that is the subject matter of this section.
The types of tools utilized can be broken into three
general categories:
1
70
~
'1;
.Ii
§
Z
60
50
• IVlachinery
• Language Translator with appropriate utilities
• Debugging Aids
1 M Memory, 2 Drums (2 ch)
1 Disk Channel
40
/
/
/"
/
.r·_·-._._._.
/ ' 512 K Memory. 1 Drum
/
1 Disk Channel
30
/
/
/
20
....... ,-.
10
2.0
4.0
5.0
6.0
7.0
8.0
TSS/360 Release
Figure 4-Number of tasks within response time objectives
the system is operating on that individual workload.
SIPE is in use at most TSS installations, and several
Users have developed their own measurement tools. Of
particular interest in this category are DEMON-a
real time software measurement morn tor developed at
Bell Telephone Laboratories, Naperville, Illinois and
XDEMON-an expanded version developed jointly
by Carnegie-Mellon University and IBM's Watson
Research Center.
XDEMON is a time-driven measurement tool providing statistics on the usage of resources in TSSj360.
XD~MON works as a shared facility under the system
maintaining a set of public tables, whose information
is updated automatically and made available to the
users, who can display selected information concerning
TSS usage accumulated since STARTUP time and for
the period since the last update. There is a privileged
user, called the 'MONITOR' who has the capability of
issuing some selected commands, including the updating
of the shared tables, the recording of statistics for later
Little that is unique in the first two categories was
done by TSS Development. As in the case of many total
systems projects (hardware and software combinations)
software development began well in advance of the
availability of the Systemj360 Model 67 hardware. To
overcome this situation, a Model 67 Simulator was
created to operate on the standard Systemj360. The
TSS system itself is written in Macro Assembler.
Initial assemblies were accomplished on a version of the
Basic Operating Systemj360 (BOSj360) Assembler
modified to expand TSS macros. Additionally, a utility
function was created which produced TSS object
module format from the output of the BOSj360
Linkage Editor.
Debugging aids
The initial set of TSS debugging aids was provided
by a system called Support for Test, Release and
Time-Shared Operations (STRATO). STRATO was a
major modification of BOSj360. It provided three
major functions:
• An Interactive Console Command Language
• A Model 67 Simulator
• A Test Case Driver
The STRATO Command Language provided facilities to system programmers to load and unload programs, to start, stop, and dynamically interrupt
programs, to display, alter and dump memory. The
Test Case Driver would supply inputs to a version of
TSS running under the Simulator and record outputs.
Early versions of the TSS Resident Supervisor were
hand-built as BOSj360 Jobs and then run and tested
Experience Gained in Development and Use of TSS
under STRATa. Once the Supervisor was cycling,
critical Virtual Memory Functions were integrated.
Much of this work was completed on Model 40 systems
before the first Model 67 was installed.
The second phase in the development of debugging
aids consisted of removing the dependency upon
STRATa. With the availability of the Model 67, the
Simulator function was removed, and STRATa was
moved to the Model 67. Integration and Test of the
TSS Assembler and Dynamic Loader was the next
milestone; the dependency upon the BaS Assembler
was removed. STRATa itself was released with TSS,
since it remained the only system programmer tool for
manipulating the resident supervisor and shared virtual
memory.
The Time-Sharing Support System (TS3) which was
565
User (Non-shared)
Virtual Memory
Initial (Shared)
Virtual Memory
I
IL
______ _
-------,
IPL
I
I
I
STARTUP
interrogates
operator
I
I
N
STARTUP loads
CSECTs in SYSIVM.
RESSUP. and
RSSSUP from
IPL Volume
L_____ _
for CSECTs; continues processing
STARTUP
COMPLETE
TSS/360 is
operational
Figure 5-TSS/360 dynamic modification procedure
Resident
Supervisor
Figure 6-Schematic views of TSS/360 debugging aids
delivered with Release 3.0 removed the final dependency
upon STRATO. The Resident Support Subsystem
(RSS) and Virtual Support Subsystem (VSS) are
more general and easier to use than STRATa command
language, but they have one significant weakness.
RSS itself is dependent upon some resident supervisor
facilities, e.g., interrupt stacker and supervisor core
allocation. The effect is that RSS is not a valuable
debugging aid for those parts of the resident supervisor.
One of the most valuable aids in TSS was a fortuitous
invention-dynamic modification of the system through
the use of Delta Data Sets. The system initialization
program, STARTUP, builds both the resident supervisor and Initial Virtual Memory (IV::\l) from modules
stored on the Initial Program L'Jad (IPL) Control
Volume. (This is in contrast to OS/360 in which the
entire supervisor is link edited together during the
System Generation procedure.) If dynamic modifica-
566
Spring Joint Computer Conference, 1972
tion of the resident supervisor or IVM is desired, the
changes are prepared on a private disk and the operator
informs STARTUP to search this disk for "deltas."
The process is shown schematically in Figure 5. The
modifications included in this manner stay in effect
only until shutdown. The next time the system is
started, they can be removed or altered at the user's
option.
To understand the next phase in the development of
debugging aids, let us summarize where we stood with
Release 3.0. Figure 6 gives a schematic view of the
system operation. At his individual terminal, each user
had at his command a comprehensive set of debugging
aids to work within his virtual memory. With the
Program Control Subsystem (PCS) of Command
System II, he could dynamically start, stop, or interrupt programs, and he could display or patch within
them. The TSS Dynamic Loader allowed him to
substitute an altered copy for any module within his
virtual memory. This power and flexibility was replicated for each active user, i.e., debugging in non-shared
virtual memory was time-shared.
The sa~e was not true either for shared virtual
memory or the resident supervisor. Exploratory debugging could be done with RSS and VSS but modules
could only be replaced by going through STARTUP.
What was desired beyond these aids were techniques
to allow time-shared debugging work on both shared
virtual memory and the resident supervisor.
Such a facility for modules within shared virtual
memory is provided by HOOK. With HOOK a system
programmer can cause a private (modified) copy of a
shared virtual memory module to be used for his task
only. Linkage to the private copy is established dynamically in response to a HK command. If testing shows an
error in the module, the programmer can UNHOOK it,
assemble further modifications, and HOOK that version
for further testing. This activity goes on in parallel with
other use of the system, including other users of HOOK.
What was said previously about the value of measurement tools to users is probably more true of debugging
aids. Recognizing this and realizing that users desire to
modify shared as well as non-shared virtual memory,
HOOK was made available to all TSS users late in
1971.
Achieving time-shared debugging for the resident
supervisor is a more difficult challenge. To meet it,
TSS Development looked outside its own domain to
Virtual Machines. Such technology underlies the design
of CP-67/CMS.s CP-67 creates a complete Virtual
Machine for each user, so several users can work with
virtual Model 67 machines and debug versions of CPo
It is clearly feasible to provide Virtual Machines under
TSS, and the addition of such a facility would complete
a most powerful set of program debugging aids. With
Virtual Machines, there would be little, if any, need for
single-thread, restart-prone debugging. Figure 7 shows
the debugging aids as they could be with Virtual
Machine added.
MANAGING SOFTWARE DEVELOPMENT
Bringing any large system from concept to fruition
is a difficult task. TSS Development had many problems,
some not unlike those described recently by F. P.
Brooks, Jr.9 Probably the most valuable lesson learned
in the process was how to manage a large software
development proj ect in the "steady state."
The TSS development organization was composed of
three major functions: Design, Development, and
Build and Test. lO Ideally, these functions should be
accomplished serially, for in this case, the same people
could do the work, and no need would exist for communications mechanisms between functions. For practical purposes, the functions do overlap. The design
cannot be complete or perfect. The development job
must continue to correct program errors and implement
new functions. Build and Test is required until the total
system is stabilized. Further, the size of TSS both in
concept and design precluded implementation by a
small group.
Here I will insert an opinion on the merits of large
versus small development groups. A small group has
two distinct advantages. It is easy to manage (one
VI RTUAL Model 67 Machines
Figure 7-Schematic views of TSSj360 debugging aids
Experience Gained in Development and Use of TSS
person can direct the efforts of 7-12 people); and a
uniformly high standard of quality can be maintained
in the selection of the group's members. Large groups
suffer from the opposite problems. There is, however,
nothing inherently bad about a large programming
group. The critical requirement is for effective management.
The systems management technique employed in
TSS was known as the New Scope Review Board
(NSRB). Control was exercised in the following way.
The design of TSS was considered complete at the
Release 1.0 level so that the only source of new code
would be fixes to identified programming errors
(APAR's). Any other change that was identified was
designed and presented to the NSRB for approval.
The board was composed of representatives of all
functional areas with the System Manager serving as
chairman. Approval of a given item meant inclusion of
its design into the system and hence implementation,
test, and integration in a System Release. With this
mechanism in place, sources of new code were restricted
to error correction and approved NSRB items.
Each proposal to change TSS was described in an
NSRB Technical Summary, composed of eight (8)
parts.
1.
2.
3.
4.
5.
Title of the item and sequence number
Four line abstract of the item
Reference to the design document
List of all external publications affected
A description of the character of the change,
e.g., does the item affect performance, reliability,
human factors, or function-positively or
negatively-and how much?
6. List of other items upon which this item depends,
i.e., other NSRB items, APAR's or hardware
Engineering Changes
7. List of all parts of the system affected, e.g.,
what modules, DSECT's, Macros, or Data Sets
are revised, added or deleted-and, if a revision,
is the change small, medium, or large?
8. Signature of the designer and his manager
With all proposals for new programming before the
Board and in a standard format, the system became
manageable. For instance, a concentrated program to
improve performance was instituted by selecting
NSRB items whose character indicated large, performance plus while rejecting others. A control on
resources was also possible since each NSRB item
carried with it an estimate of the work required to
complete it. The System Manager could either restrict
the quantity of new scope to match his resource or he
Requirements
for New Programs
Design
567
Business
Planning
NEW SCOPE
REVIEW
BOARD
APAR
Control
Approved New
Scope
APAR's
Development
Unit Tested Modules
Detected
Program Errors
Build and Test
Requirements
for New Programs
Detected
Program Errors
Users
Figure 8-TSSj360 development cycle showing major functions
and the flow of information
could add or substract resource to match the new
scope desired.
Figure 8 illustrates the interrelationships of the
various functions and the flow of information behveen
them.
The major sources for requirements input are the
System Users and a Business Planning Group. Once a
requirement is known, a dpsign is prepared and the
item is submitted to the NSRB. Those items 'which are
approved form one of two sources of work for the
development group.
Here a word should be said about the unique place
occupied by the design function. We have mentioned
that TSS had a sound basic design, and certainly this
was essential to the success of its implementation. ,We
also subscribe to the philosophy that designers must
have control over the manner in which the system is
developed. Yet, design must be responsive to a multitude of outside influences, including Systems ::\lanagement. Several of the best features of TSS have resulted
from corrections to short-sited design.
568
Spring Joint Computer Conference, 1972
A philosophy used throughout TSS has been to
deliver the best possible code. Therefore, all program
errors detected by the build and test group are submitted to the same APAR Control group as U serdetected errors. APAR control verifies the error,
eliminates duplicates, and tracks the status of all errors.
Errors to be fixed form the second source of work for
Development. Here we have had success with the idea
of module ownership. The development programmer
responsible for a module does all the work necessary to
implement NSRB changes and APAR corrections.
(Having a separate maintenance group tends to remove
an incentive for qualtity development work, i.e., ones
bugs come back to haunt the maintenance programmer
not the developer.) The resultant changed modules are
the source of input to Build and Test.
The cycle is completed when Build and Test ships a
system release.
The table below shows the activity of TSS Development from the three sources described.
TABLE II-System Content by Release
Release
Number of
N umber of AP ARS Corrected
NSRB
Internal
Items Included User-detected
1.1
1.2
2.0
3.0
4.0
5.0
5.1
6.0
6.1
7.0
8.0
8.1
Subsequent
TOTAL
9
32
49
56
42
80
32
84
64
50
70
568
91
136
181
190
111
321
192
226
40
174
206
574
NA
7
72
255
201
534
471
538
85
466
442
1016
NA
2442
4087
CONCLUSION
Where does TSS go from here? What is the prognosis
for large-scale, interactive systems in general? The
first question is easier to answer.
Work remains to be done to bring TSS up to a high
degree of reliability. This task is receiving the highest
priority. In addition, we are dedicated to improving the
system's error recovery facilities. There is a high
potential plateau for dependability and availability;
we are working to reach it.
Impresfive as the TSS performance story has' been,
we accept our users' contention that performance is
not as good as it needs to be. The proper course now is
to specify new benchmarks that more closely parallel
the real customers workloads, and to use the powerful
tools previously described to drive performance upward.
Last, but not least, is the fact that TSS users have
been and are continuing to improve the system. Both
the usability and the utility of TSS continue to grow.
The prognosis? I cannot provide that, but I can put
forward two thoughts-both deeply rooted in the
TSSj360 experience.
I have noted that where TSSj360 has succeeded
people efficiency is held more important than machine
efficiency, and that it is becoming broadly accepted that
the availability of skilled people, not the availability of
better hardware, is the limiting factor in the growth of
our industry. From this I conclude that, if our industry
is to thrive, systems which go to the user, which make
people more efficient, in short, interactive systems like
TSS must playa dominant role in the decade ahead.
Finally, I will express my belief that the single most
important requirement before us is to modernize the
program development process itself. Years ago, the
application of computing to hardware design and
manufacture removed bottlenecks which threatened to
retard industry growth. Today, the bottlenecks are in
software design and manufacture.
ACKNOWLEDGMENTS
The outlook of this paper is historical not journalistic.
I hope that readers who have been more deeply involved
in TSS development than I will agree with the sense of
the paper even though they disagree with this or that
detail.
I have cited some references, and I have made use
of some unpublished information. For the latter, I
would like to thank M. R. Babacci, D. R. Cease, K. lVI.
Hilmar, A. Kamerman, O. R. LaMaire, and C. E.
Seabold.
Finally, it must be said that TSSj360 would have
been a very uninteresting subject were it not the
creation of fine people. Each man and woman who
worked on the system deserves a fair share of credit.
My special thanks go to Bill Florac, Scott Locken,
Nick Martellotto, and Ida Scott. These people more
than any others gave me insight into the nature of
TSS.
Experience Gained in Development and Use of TSS
REFERENCES
1 W T COMFORT
A computing system design for user service
1965 FJCC Sparten Books
2 A S LETT W L KONIGSFORD
TSS/360: A time-shared operating system
1968 FJCC Thompson Book Company
3 IBM System/360 time sharing system-Command system
users guide
IBM Corporation Form GC28-2001
4 W J DOHERTY
Scheduling TSS/360 for responsiveness
1970 FJCC AFIPS Press
5 D N STREETER
Cost/benefits of computing services in a scientific environment
IBM Research Report RC 3453
569
6 F D SCHULMAN
Hardware measurement device for IBM System/360 time
sharing evaluation
22nd National ACM Conference Proceedings
7 W R DENISTON
SIPE: A TSS/360 software measurement technique
24th National ACM Conference Proceedings
8 CP-67 JCMS system description manual
IBM Form GH20-0802
9 F P BROOKS JR
Why is the software late?
Data Management August 1971
10 N A ZIMMERMAN
System integration as a programming function
24th National ACM Conference Proceedings
Multics-The first seven years*
by F. J. CORBATO and J. H. SALTZER
Massachusetts Institute of Technology
Cambridge, Massachusetts
and
C. T. CLINGEN
Honeywell Information Systems Inc.
Cambridge, Massachusetts
feel to be of special interest. We do not attempt detailed
discussion of the organization of lVlultics; that is the
purpose of specialized technical books and papers. *
INTRODUCTION
In 1964, following implementation of the Compatible
Time-Sharing System (CTSS)l,2 serious planning began
on the development of a new computer system specifically organized as a prototype of a computer utility. The
plans and aspirations for this system, called Multics
(for Multiplexed Information and Computing Service),
were described in a set of six papers presented at the
1965 Fall Joint Computer Conference. 3- 8 The development of the system was undertaken as a cooperative effort involving the Bell Telephone Laboratories (from
1965 to 1969), the computer department of the General
Electric Company,* and Project 1\1AC of lVL I. T.
Implicit in the 1965 papers was the expectation that
there should be a later examination of the development
effort. From the present vantage point, however, it is
clear that a definitive examination cannot be presented
in a single paper. As a result, the present paper discusses
only some of the many possible topics. First we review
the goals, history and current status of the lVlultics project. This review is followed by a brief description of the
appearance of the lVlultics system to its various classes
of users. Finally several topics are given which represent
some of the research insights which have come out of
the development activities. This organization has been
chosen in order to emphasize those aspects of software
systems having the goals of a computer utility which we
GOALS
The goals of the computer utility, although stated at
length in the 1/965 papers, deserve a brief review. By a
computer utility it was meant that one had a community computer facility with:
(1) Convenient remote terminal access as the normal
mode of system usage;
(2) A view of continuous operation analogous to that
of the electric power and telephone companies;
(3) A wide range of capacity to allow growth or
(4)
(5)
(6)
(7)
(8)
* Work reported herein was sponsored (in part) by Project MAC,
an M.LT. research program sponsored by the Advanced Research
Projects Agency, Department of Defense, under office of Naval
Research Contract Number N00014-70-A-0362-0001. Reproduction is permitted for any purpose of the United States
Government.
* Subsequently acquired by Honeywell Information Systems Inc.
contraction without either system or user reorganization;
An internal file system so reliable that users trust
their only copy of programs and data to be stored
in it;
Sufficient control of access to allow selective
sharing of information;
The ability to structure hierarchically both the
logical storage of information as well as the administration of the system;
The capability of serving large and small users
without inefficiency to either;
The ability to support different programming
environments and human interfaces within a
single system;
* For example, the essential mechanisms for much of the Multics
system are given in books by Organick9 and Watson. 10
571
/
572
Spring Joint Computer Conference, 1972
(9) The flexibility and generality of system organization required for evolution through successive
waves of technological improvements and the
inevitable growth of user expectations.
In an absolute sense the above goals are extremely
difficult to achieve. Nevertheless, it is our belief that
Multics, as it now exists, has made substantial progress
toward achieving each of the nine goals. * Most importantly, none of these goals had to be compromised
in any important way.
HISTORY OF THE DEVELOPMENT
As previously mentioned, the 1\lultics project got
under way in the Fall of 1964. The computer equipment
to be used was a modified General Electric 635 which
was later named the 645. The most significant changes
made were in the processor addressing and access control
logic where paging and segmentation were introduced;
A completely new Generalized Input/Output Controller
was designed and implemented to accommodate the
varied needs of devices such as disks, tapes and teletypewriters without presenting an excessive interrupt
burden to the processors. To handle the expected paging
traffic, a 4-million word (36-bit) high-performance drum
system with hardware queueing was developed. The
design specifications for these items were completed by
Fall 1965, and the equipment became available for software development in early 1967.
Software preparation underwent several phases. The
first phase was the development and blocking out of
major ideas, followed by the writing of detailed program
module specifications. The resulting 3,000 typewritten
pages formed the Multics System Programmers' Manual and served as the starting point for all programming. Furthermore, the software designers were expected to implement their own designs. As a general
policy PL/I was used as the system programming
language wherever possible to maximize lucidity and
maintainability of the system. 14, 15 This policy also increased the effectiveness of system programmers by allowing each one to keep more of the system within his
grasp.
The second major phase of software development,
well under way by early 1967, was that of module implementation and unit checkout followed by merging
into larger aggregates for integrated testing. Up to then
most software and hardware difficulties had been anticipated on the basis of previous experience. But what
* To the best of our knowledge, the only other attempt to
comprehensively attack all of these goals simultaneously is the
TSSj360 project at IBMy,12,13
gradually became apparent as the module integration
continued was that there were gross discrepancies between actual and expected performance of the various
logical execution paths throughout the software. The
result was that an unanticipated phase of design iterations was necessary. These design iterations did not
mean that major portions of the system were scrapped
without being used. On the contrary, until their replacements could be implemented, often months later,
they were crucially necessary to allow the testing and
evaluation of the other portions of the system. The
cause of the required redesigns was rarely "bad coding"
since most of the system programmers were well above
average ability. 1\loreover the redesigns did not mean
that the goals of the project were compromised. Rather
three recurrent phenomena were observed: (1) typically,
specifications representing less-important features were
found to be introducing much of the complexity, (2)
the initial choice of modularity and interfacing between
modules was sometimes awkward and (3) it was rediscovered that the most important property of algorithms is simplicity rather than special mechanisms
for unusual cases.*
The reason for bringing out in detail the above design
iteration experience is that frequently the planning of
large software projects still does not properly take the
need for continuing iteration into account. And yet we
believe that design iterations are a required activity on
any large scale system which attempts to break new conceptual ground such that individual programmers cannot comprehend the entire system in detail. For when
new ground is broken, it is usually impossible to deduce the consequent system behavior except by experimental operation. Simulation is not particularly effective when the system concepts and user behavior are
new. Unfortunately, one does not understand the system
well enough to simplify it correctly and thereby obtain
a manageable model which requires less effort to implement than the system itself. Instead one must develop
a different view:
(1) The initial program version of a module should
be viewed only as the first complete specification
of the module and should be subject to design
review before being debugged or checked out.
(2) l\1odule design and implementation should be
based upon an assumption of periodic evaluation,
redesign, and evolution.
In retrospect, the design iteration effect was apparent
* "In anything at all, perfection is finally attained not when there
is no longer anything to add, but when there is no longer anything
to take away ... "
-Antoine de Saint-Exupery, Wind, Sand and Stars Quoted
with permission of Harcourt Brace Jovanovich, Inc.
lVlultics
even in the development of the earlier Compatible TimeSharing System (CTSS) when a second file system with
many functional improvements turned out to have poor
performance when initially installed. A hasty design
iteration succeeded in rectifying the matter but the
episode at the time was viewed as an anomaly perhaps
due to inadequate technical review of individual programming efforts.
TABLE I-A comparison of the system development and use
periods of CTSS and Multics. The Multics development period is not significantly longer than that for
CTSS despite the development of about 10 times as
much code for Multics as for CTSS and a geographically distributed staff. Although reasons for this
similarity in time span include the use of a higherlevel programming language and a somewhat larger
staff, the use of CTSS as a develonment tool for
Multics was of pivitol importance.
CURRENT STATUS
System
In spite of the unexpected design iteration phase, the
lVIultics system became sufficiently effective by late 1968
to allow system programmers to use the system while
still developing it. By October 1969, the system was
made available for general use on a "cost-recovery"
charging basis similar to that used for other major
computation facilities at M.LT. Multics is now the
most widely used time-sharing system at lVLLT., supporting a user community of some 500 registered subscribers. The system is currently operated for users 22
hours per day, 7 days per week. For at least eight hours
each day the system operates with two processors and
three memory modules containing a total of 384k (k =
1024) 36-bit words. This configuration currently is rated
at a capacity of about 55 fairly demanding users such
that most trivial requests obtain response in one to five
seconds. (Future design iterations are expected to increase the capacity rating.) Several times a day during
the off-peak usage hours the system is dynamically reconfigured into two systems: a reduced capacity service
system and an independent development system. The
development system is used for testing those hardware
and software changes which cannot be done under normal service operation.
The reliability of the round-the-clock system operation described above has been a matter of great concern, for in anyon-line real-time system the impact of
mishaps is usually far more severe than in batch processing systems. In an on-line system especially important considerations are:
(1) the time required before the system is usable
again following a mishap,
(2) the extra precautions required for restoring possibly lost files, and
(3) the psychological stress of breaking the interactive dialogue with users who were counting on
system availability.
Because of the importance of these considerations, careful logs are kept of all lVlultics "crashes" (i.e., system
service disruption for all active users) at M.LT. in
order that analysis can reveal their causes. These analyses indicate currently an average of between one and
573
CTSS
Multics
Development
Only
Development
Use
1960-1963
1964-1969
1963-1965
1969-present
+
Use Only
1965-present
two crashes per 24 hour day. These crashes have no
single cause. Some are due to hardware failures, others
to operator error and still others to software bugs introduced during the course of development. At the two
other sites where lVlultics is operated, but where active
system development does not take place, there have
been almost no system failures traced to software.
Currently the lVlultics system, including compilers,
commands, and subroutine libraries, consists of about
1500 modules, averaging roughly 200 lines of PL/I
apiece. These compile to produce some 1,000,000 words
of procedure code. Another measure of the system is the
size of the resident supervisor which is about 30k words
of procedure and, for a 55 user load, about 36k words of
data and buffer areas.
Because the system is so large, the most powerful
maintenance tool available was chosen-the system itself. vVith all of the system modules stored on-line, it is
easy to manipulate the many components of different
versions of the system. Thus it has been possible to
maintain steadily for the last year or so a pace of installing 5 or 10 new or modified system modules a day.
Some three-quarters of these changes can be installed
while the system is in operation. The remainder, pertaining to the central supervisor, are installed in batches
once or twice a week. This on-line maintenance capability has proven indispensable to the rapid development and maintenance of Multics since it permits constant upgrading of the user interface without interrupting the service. Weare just beginning to see instances of
user-written applications which require this same capability so that the application users need not be interrupted while the software they are using is being
modified.
The software effort which has been spent on Multics
is difficult to est:mate. Approximately 150 man-years
were applied directly to design and system programming
during the "development-only" period of Table 1.
574
Spring Joint Computer Conference, 1972
Since then we estimate that another .50 man-years have
been devoted to improving and extending the system.
But the actual cost of a single successful system is misleading, for if one starts afresh to build a similar system,
one must compensate for the non-zero probability of
failure.
THE APPEARANCE OF lVIULTICS TO
ITS USERS
Having reviewed the background of the project, we
may now ask who are the users of the lVlultics system
and what do the facilities that lVlultics provides mean
to these users. Before answering, it is worth describing
the generic user as "viewed" by l\1ultics. Although
from the system's point of view all users have the same
general characteristics and interface with it uniformly,
no single human interface represents the l\1ultics machine. That machine is determined by each user's
initial procedure coupled with those functions accessible
to him. Thus there exists the potential to present each
Multics user with a unique external interface.
However, Multics does provide a native internal
program environment consisting of a stack-oriented,
pure-procedure, collection of PL/I procedures imbedded
in a segmented virtual memory containing all procedures and data stored on-line. The extent to which
some, all, or none of this internal environment is visible
to the various users is an administrative choice.
The implications of these two views-both the external interface and the internal programming environment-are discussed in terms of the following categories
of users:
• System programmers and user application programmers responsible for writing system and user
software.
• Administrative personnel responsible for the management of system resources and privileges.
• The ultimate users of applications systems.
• Operations and hardware maintenance personnel
responsible, respectively, for running the machine
room and maintaining the hardware.
M ultics as viewed by system and subsystem programmers
The machine presented to both the Multics system
programmer and the application system programmer is
the one with which we have the most experience; it is
the raw material from which one constructs other environments. It is worth reemphasizing that the only
differentiation between l\1ultics system programmers
and user programmers is embodied in the access control
mechanism ,vhich determines what on-line information
can be referenced; therefore, what are apparently two
groups of users can be discussed as one.
l\lajor interfaces presented to programmers on the
l\Iultics system can be classified as the program preparation and documentation facilities and the program execution and debugging environment.·· They will be
touched upon briefly, in the order used for program
preparation.
Progralll preparation and doculllen ta tion
The facilities for program preparation on ::\Iultics are
typical of those found on other time-sharing systems,
with some shifts in emphasis (see the Appendix). For
example, programmers consider the file system sufficiently invulnerable to physical loss that it is used
casually and routinely to save all information. Thus,
the punched card has vanished from the work routine
of l\1ultics programmers and access to one's programs
and the ability to work on them are provided by the
closest terminal.
As another example, the full ASCII character set is
employed in preparing programs, data, and documentation, thereby eliminating the need for multiple text
editors, several varieties of text formatting and comparison programs, and multiple facilities for printing
information both on-line and off-line. This generalization of user interfaces facilitates the learning and subsequent use of the system by reducing the number of
conventions. which must be mastered.
Finally, because the PL/I compiler is a large set of
programs, considerable attention was given to shielding
the user from the size of the compiler and to aiding
him in mastering the complexities of the language. As
in many other time-sharing systems, the compiler is
invoked by issuing a simple command line from a
terminal exactly as for the less ambitious commands.
No ~nowledge is required of the user regarding the
various phases of compilation, temporary files required,
and optional capabilities for the specialist; explanatory
"sermons" diagnosing syntactic errors are delivered to
the terminal to effect a self-teaching session during each
compilation. To the programmer, the PLjI compiler is
just another command.
Progralll execution environlllen t
Another set of interfaces is embodied in the implementation environment seen by PL/I programmers.
This environment consists of a directly addressable
virtual memory containing the entire hierarchy of online information, a dynamic linking facility which
Multics
searches this hierarchy to bind procedure references, a
device-independent input/output16 system, * and program debugging and metering facilities. These facilities
enjoy a symbiotic relationship with the PL/I procedure
environment used both to implement them and to implement user facilities co-existing with them. Of major
significance is that the natural internal environment
provided and required by the system is exactly that
environment expected by PL/I procedures. For example,
PL/I pointer variables, call and return statements,
conditions, and static and automatic storage all correspond directly to mechanisms provided in the internal
environment. Consequently, the system supports PL/I
code as a matter of course.
The main effect of the combination of these features
is to permit the implementer to spend his time concentrating on the logic of his problem; for the most part
he is freed from the usual mechanical problems of
storage management and overlays, input/output device
quirks, and machine-dependent features.
SOIlle iIllpleIllentation experience
The l\1:ultics team began to be much more productive
once the l\1:ultics system became useful for software
development. A few cases are worth citing to illustrate
the effectiveness of the implementation environment.
A good example is the current PL/I compiler, which is
the third one to be implemented for the project, and
which consists of some 250 procedures and about 125k
words of object code. Four people implemented this
compiler in two years, from start to first general use.
The first version of the Multics program debugging
system, composed of over 3,000 lines of source code,
was usable after one person spent some six months of
nights and weekends "bootlegging" its implementation.
As a last example, a facility consisting of 50 procedures
with a total of nearly 4,000 PL/I statements permitting
execution of Honeywell 635 programs under Multics
became operational after- one person spent eight months
learning about the GCOS operating system for the 635,
PL/I, and Multics, and then implemented the environment. In each of these examples the implementation
was accomplished from remote terminals usingPL/I.
l\1ultics users have discovered that it is possible to
get their programs running very quickly in this environment. They frequently prepare "rough drafts" of programs, execute them, and then improve their overall
design and operating strategy using the results of experience obtained during actual operation. As an example, again drawn from the implementation of Mul-
* The Michigan Terminal System17 has a similar device-independent input/output system.
575
tics, the early designs and implementations of the programs supporting the virtual memory18 made overoptimistic use of variable-sized storage allocation
techniques. The result was a functionally correct but
inadequately performing set of programs. Nevertheless,
these modules were used as the foundation for subsequent work for many months. When they were finally
replaced with modules using simplified fixed-size storage
techniques, performance improvements of over an order
of magnitude were realized. This technique emphasizes
two points: first, it is frequently possible to provide a
practical, usable facility containing temporary versions
of programs; second, often the insight required to significantly improve the behavior of a program comes
only after it is studied in operation. As implied in the
earlier discussion of design iteration, our experience has
been that structural and strategic changes rather than
"polishing" (or recoding in assembly language) produce
the most significant performance improvements.
In general, we have noticed a significant "amplifier"
or "leverage" effect with the use of an effective on-line
environment as a system programming facility. Major
implementation projects on the l\1:ultics system seldom
involve more than a few programmers, thereby easing
the management and communications problems usually
entailed by complex system implementations. As would
be expected, the amplification effect is most apparent
with the best project personnel.
Administration oJMultics facilities and resources
The problem of managing the capabilities of a computer utility with geographically dispersed subscribers
leads to a requirement of decentralized administration.
At the apex of an administrative pyramid resides a system administrator with the ability to register new users,
confer resource quotas, and generate periodi2 bills for
services rendered. The system administrator deals with
user groups called projects. Each group can in turn
designate a project administrator who is delegated the
authority to manage a budget of system resources on
behalf of the project. The project administrator is then
free to dAj/(r-l) for each
j = 1, 2, ... , n then any r-node file assignment is more
costly than the optimal one-node assignment.
We prove the theorem by means of the following
lemma:
Lemma:
If ~j= PAj for j = 1,2, ... ,n then, an r-node assignment cannot be less costly than the optimal one-node
assignment if p?l/ (r-l).
1=1
where
Proof of Lemma:
n
Uk=Uk+ L ~jdjk'
1=1
Gj(I) = Aj min djk
keI
With C (I) expressed in this form the problem of
minimizing cost is seen to be exactly the problem
investigated by Efroymson and Ray,! Feldman, et al.,2
Consider an arbitrary assignment 1= {I, 2, ... , r}.
Let the elements of I be ordered such that node 1 is the
lowest cost single-node assignment.
We have
r
n
n
r
C(I) =PL LAjdjk+ L min Ajdjk+ L Uk
k=1
1=1 kEI
k=1 1=1
Allocation of Copies of a File in an Information Network
and
n
C( {k})
= (1+p) L Ajdjk+Uk
k= 1,2, ... , r
i=1
By the optimality of node 1 there are nonnegative
numbers a2, ... , aT such that
k=2,3, ... ,r.
n
L
pak
no more than r nodes.
k=2
~ . "\ d + p(r-1)ul
mIn I\j jk
+ £....
i=1 k
l+p
1 r
+-LUk
l+p k=2
which is certainly nonnegative if (pr- p-1) is nonnegative. That is, p~ 1/ (r-1) implies that C (1) ~
C({l}).
If the optimal single node assignment is in I, then it
is node 1 and the lemma is proved. If the optimal node,
say k', is not in I, then we have p~ 1/ (r-1) implies
C(/) ~C( {I}) >C({k'}) and so the lemma is true in
this case as well.
Proof of Theorem 1
The lemma concerns the case where each user
generates the same proportion of update traffic to query
traffic. Suppose now that the proportions vary from
node to node, but always exceed a given amount p.
Then, there are nonnegative quantities Ej such that
j=1,2, ... ,n
The cost functions can now be written:
n
Proof
If 1/1j ~ Ail (r -1) for each j then certainly for any
integer l
and so theorem 1 rules out the optimality of an (r+l)node assignment.
Corollary 2
If each user generates at least 50 percent of his
traffic in the form of updates, then the optimal assignment policy is to locate only a single copy of the file
in the network.
The corollary follows directly from the theorem by
setting r = 2, but is worth stating separately since it
sets a bound beyond which multiple copies of the file
should not be considered. Furthermore, it is easy to
show that for equal proportions of update and query
traffic the two-node assignment is no more costly than
a one-node assignment of the file only if storage costs
are neglected, and the rows and columns of the cost
matrix can be permuted to yield the form:
n
= L (1+P+Ej)A jdJ1 +u=C( {I}) + L EjAjdjl
i=1
[:.
i=1
n
C' (/)
Corollary 1
(r an integer) then the optimal allocation consists of
T
= [pr-p-1] L Ajdj1 +
i=1
C'( {I})
But clearly C' (/) ~ C' ( {I}) whenever C (/) ~ C ( {I} ).
Then applying the lemma, the condition p~ 1/ (r-1) is
sufficient to ensure that the r-node assignment is not
optimal. In addition, if at least one of the E/S is greater
than zero, we must have the strict inequality C (/) >
C({I}).
If the update/query traffic ratio satisfies p~ 1/ (r-l)
Substituting the above, we can write
C(/) -C( {I})
T
= L (P+Ej) Aj
i=1
L djk
n
r
EjAj
al
a2 .. . am
0
b2 . .. b l
0
0 ... 0
0 0 ... 0
0 ... ]
where
+ L min (P+Ej) djk+rou
i=1 k
n
0 ... 0
(rest of matrix)
k=1
= C (/) + L
i=1
619
m
L
n
L djk + L
k=1
i=1
Ej
min djk
k
where the unprimed costs are those given in the lemma.
m
aiAa = L biAb,
i=1
i=1
Aa and Ab being the respective traffic volumes for the
first two rows (query or update) .
620
Spring Joint Computer Conference, 1972
A PROPERTY OF THE OPTIMAL FILE
ALLOCATION
In this section, we examine the behavior of the cost
function as additional file nodes are added. In particular, we consider a graph such as Figure 1, where each
vertex is identified with a file assignment (denoted by
a binary vector having l's in those positions corresponding to file nodes, O's elsewhere). Associated with
each vertex is the corresponding value of the cost
function (not shown in Figure 1). For mathematical
convenience the null vertex is assigned infinite cost.
The edges of the graph are directed paths corresponding
to the addition of a single file node to the previous
assignment. The graph is conveniently arranged in
levels where the vertices at the kth level represent all
k-node file assignments.
We demonstrate the significant property of this
graph (which we shall call the "cost" graph) that if a
given vertex has a cost less than the cost of any vertex
along the paths leading to it, then the sequence of costs
encountered along anyone of these paths decreases
monotonically. Thus, in order to find the optimal
allocation policy, it is sufficient to follow every path of
the cost graph until the cost increases, and no further.
Because of this property, only a small subset of the
possible assignments need be tested, compared with the
exhaustive search procedure in which 2n different file
allocations must be evaluated.
The monotonicity will be exhibited in two stages:
first, for the case of two steps through the graph, and
then for the general case.
Let I'""X, where XCI, denote the index set I with
the elements of set X removed.
Consider an arbitrary file assignment corresponding
to index set I, and assume the nodes are so numbered
that 1= [1,2, ... ,r]. We proceed to show:
Lemma:
If C(I) ~C(I'""{k}) for k= 1,2, then C (I'"" {k} ~
C(I'""{l, 2}) fork=l, 2.
Proof of Lemma:
The cost function can be written, in general,
n
L:
C(I'""X) =
Uk
+ L: Aj
i=I
keI,...,X
min
djk
keI,...,X
Thus
n
L: Ajdj
C(I) -C(I'""{l}) = U 1 -
i=I
where
dj =
min
d jk -
keI,...,{ I}
min d jk
keI
Also
n
L Ajd/
C(I,",,{2}) -C(I'""{l, 2}) = U 1 -
i=I
where
d/ =
min
d jk -
keI,...,{ I,2}
mIn
d jk
keI,...,{ 2}
Consider the difference
d/-dj=
min
d jk
kEI,...,{ I,2}
+
mindjk keI
min
min d jk
d jk -
keI,...,{ 2}
keI,...,{ I}
We have
min d jk = mine min
keI
djk~
min
d jk ,
keI,...,{ I}
max (min
keI,...,{ I,2}
keI,...,{ I}
mIn
d jk )
keI,...,{ 2}
d jk ,
min
d jk )
keI,...,{ 2}
Therefore
d/-dj~O,
that is
d/~dh
and so
C (I'"" {2 }) - C (I'"" {1, 2} ) ~ C (I) - C (I'" {1 })
thus,
implies that
By a mere permutation of indexes we may likewise
prove that
/
Figure 1-Graph of the allocation process
Allocation of Copies of a File in an Information Network
implies that
C(lrv{l}) :::;C(1rv{l, 2})
and so the lemma is true.
By means of this lemma, we can now prove the
general theorem:
Theorem 2:
Given an index set X CI containing r elements, and
having the property
C(l) :::;C(lrv{x}) for each xeX
then for every sequence RCI), R (2), ... ,RCT) of subsets
of X such that RCk) has k elements, and RCk)CRCHI) it
is true that
C(l) :::;C(lrvR(l) :::;C(lrvRC2)
:::;C(lrvRC3):::; ••• :::;C(1rvRCT)
Proof: (by induction)
The first inequality above is given in the hypothesis.
Since R(2) has two elements the second inequality
follows from the lemma. I t may thus be taken as
hypothesis to prove the third, and so on. Each inequality
proved can be used together with the lemma to prove
the inequality to its right.
621
antecedent contains the file nodes of v less one node,
while each successor contains the nodes of v plus one
additional node. A vertex at the rth level of the graph
has r antecedents, and (n-r) successors, where n is
the number of nodes in the network. (Note that, for
clarity, we use the term "node" in referring to the
computer network, and the term "vertex" with respect
to the cost graph.)
We shall also define a "local optimum" of the cost
graph as a vertex which is less costly than all of its
antecedents and successors. Clearly, the global optimum
we seek belongs to the set of local optima of the graph.
The theorem permits us to discover all the local
optima without computing the cost of every vertex, for
each path leading from the 0 level to a local optimum
must give rise to a monotonically decreasing sequence cJ
costs. Whenever an increase is encountered in a step
forward through the graph, that path can be abandoned
since it cannot lead to a local (or global) optimum. A
"path-tracing" routine which evaluates each possible
sequence of node additions in this way is certain to
produce the minimum value of C (1). The amount of
computation needed to extract the minimum will
increase with the number of local optima, and with the
number of nodes in the optimal configuration.
A computer algorithm can be implemented in several
different ways to select file nodes one at a time up to
the optimum configuration. One approach is to follow
all paths in parallel through the cost graph, stepping
Observations:
If we take X = I in the theorem, then it states that
along any path in the cost graph from the null vertex
(which we have assigned infinite cost) to the vertex
corresponding to I, cost decreases monotonically from
one vertex to the next, providing of course that index
set I satisfies the hypothesis of the theorem. The
monotonic decreasing property can also be shown to
hold in the reverse direction; i.e., for paths from the
vertex {1, 2, ... ,n} to the optimum.*
APPLICATION TO FILE ALLOCATION
The theorem just proved provides a test that is
useful in determining the minimum cost allocation of
file copies to nodes of the network. Referring to the
cost graph (Figure 1), let us define an '''antecedent'' of
an arbitrary vertex v as a vertex which has a connection
to v from the next lower level, and a "successor" of v
as a vertex connected to v at the next higher level. An
* A reviewer pointed out this generalization.
COST PER
MEGABYTE SHIPPED
INPUT PARAMETERS
U
S
E
R
S
1
2
3
4
5
QUERY UPDATE FILE
TRAFFIC TRAFFIC
1
24
2
0
24
3
6
24
4
12
24
6
9
24
8
6
QUERYING COSTS
1
2
1
0
144
2
144
0
3
144
288
4
216
288
144
5
216
UPDATE COSTS
1
1
0
2
18
3
48
4
54
5
48
3
288
144
0
144
288
2
12
0
24
72
72
3
24
18
0
36
96
NODES
2
6
0
6
12
9
4
216
288
144
0
144
4
18
36
24
0
48
Figure 2-A five-node example
3
12
6
0
6
12
4
5
9
6
12
9
6 12
0
6
0
6
5
144
216
288
144
0
5
12
27
48
36
0
622
Spring Joint,; Computer Conference, 1972
"%\
Figure 3-The cost graph for the example.
J.Jocal optima are circled
one level per iteration. This method is computationally
efficient, but may require a great deal of storage in a
large problem. Alternatively, a program can be written
to trace systematically one path at a time. Such a
technique uses less storage, but may require redundant
calculations since many different paths intersect each
vertex.
EXAMPLES
We consider a five-node network with query and
update parameters, and cost matrix as in Figure 2.
Figure 3 shows the file node cost graph, and indicates
the optimal allocations. This small-scale example
illustrates the monotonicity of the cost function along
paths leading to a local optimum.
Note that the matrix {d jk } is symmetric and has zero
elements along the main diagonal. This is a plausible
condition in a practical case, but is not required in any
way by the theorems proven here.
As a second example, we postulate the ARPA computer network and its traffic matrix as given by Kleinrock. 7 In order to treat this case, which is not initially
posed as a centralized data base configuration, we make
the following rather arbitrary assumptions:
(1) All the resources of the network represented in
the traffic matrix are gathered into one large
file, copies of which are to be allocated to a
subset of the nodes.
(2) The query traffic (Figure 4) from each user to
the file is as given under the "node output"
column in Kleinrock's table. If the user is accessing a program, we may think of this "query"
traffic as comprising the command messages he
must send in order to run the program, plus the
program output sent back to him. (Note:
Kleinrock does not give figures for each node's
use of its own facilities.)
(3) "Update" traffic, which causes modification of
programs and data in all copies of the· file, is a
fixed percentage of the query traffic defined in
(2). The update/query ratio is the same for
each user, and is varied as a parameter in the
computer runs described below.
(4) The "cost" of communicating between two
network nodes is as shown in Figure 4. The
quantities given here are roughly the straightline distances between nodes. Thus, the cost
function to be minimized is the total amount of
"flow" in the network, i.e., the product of
message length in bits, multiplied by the distance
through which the message must travel on a
direct path to its destination, summed over all
messages. In this view an update message is
assumed to be sent separately to each file location, rather than relayed.
Assumptions (1)-(4) ignore the network communication links as configured by Kleinrock. Ordinarily
these would determine the cost matrix. Substituting
"distance" for "cost," as done here, might be expedient
in a preliminary analysis to allocate resources prior to a
topological design of the network. We employ the
ARPA data primarily because it tests our model on a
problem involving many nodes. In addition, we should
like to encourage speculation on the concept of multiple
copies of a resource (data or programs), and whether
such a facility is attractive in future ARPA-like networks.
Figure 5 summarizes the file allocation experiments
conducted using this data, in which the proportion of
update traffic to query traffic was varied from 100
percent to 10 percent in steps. As expected, only single
node allocations are indicated when the two types of
traffic are equal. As a smaller volume of update traffic
is generated, multiple node solutions begin to appear.
The copies of the file are widely distributed geographically, and the single node solution is centrally located.
However, such features result from the particular
traffic distribution assumed, and are not generalizations
valid for every case.
I t is interesting to note the large number of local
optima generated (see Figure 5). Because certain
ARPA sites, e.g., MIT, BBN, Harvard, and Lincoln
Laboratories, are very near one another, if one occurs
in a local optimum one of its neighbors may be substituted for it to produce a second configuration that
Allocation of Copies of a File in an Information Network
623
COST PER MEGABYTE SHIPPED
U
S
E
R
S
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
QUERY FILE
1
TRAFFIC
0
8
21
75
7
75
75
6
10
75
350
4
450
3
10
490
9
640
50
900
1050
3
26
2080
20
2700
21
2700
2700
3
2670
5
4
2610
2610
8
2610
7
NODES
2
75
0
5
5
5
300
400
480
660
920
1060
2110
2720
2720
2720
2700
2640
2640
2640
3
75
5
0
5
5
300
400
480
660
920
1060
2110
2720
2720
2720
2700
2640
2640
2640
4
75
5
5
0
5
300
400
480
660
920
1060
2110
2720
2720
2720
2700
2640
2640
2640
5
75
5
5
5
0
300
400
480
660
920
1060
2110
2720
2720
2720
2700
2640
2640
2640
6
350
300
300
300
300
0
160
280
500
710
850
1940
2570
2570
2570
2520
2450
2450
2450
7
450
400
400
400
400
160
0
190
430
610
730
1850
2470
2470
2470
2400
2330
2330
2330
8
490
480
480
480
480
280
190
0
240
430
570
1670
2300
2300
2300
2240
2170
2170
2170
9
640
660
660
660
660
500
430
240
0
280
430
1460
2090
2090
2090
2050
1980
1980
1980
10
900
920
920
920
920
710
610
430
280
0
160
1250
1860
1860
1860
1800
1730
1730
1730
12
2080
2110
2110
2110
2110
1940
1850
1670
1460
1250
o 1160
1160
0
1760 610
1760 620
1760 620
1680 640
1610 600
1610 600
1610 600
11
1050
1060
1060
1060
1060
850
730
570
430
160
13
2700
2720
2720
2720
2720
2570
247
2300
2090
1860
1760
610
0
40
40
290
340
340
340
14
2700
2720
2720
2720
2720
2570
247
2300
2090
1860
1760
620
40
0
5
250
320
320
320
15
2700
2720
2720
2720
2720
2570
247
2300
2090
1860
1760
620
40
5
0
250
320
320
320
16 17 18 19
2670 2610 2610 2610
2700 2640 2640 2640
2700 2640 2640 2640
2700 2640 2640 2640
2700 2640 2640 2640
2520 2450 2450 2450
240 233' 233 233
2240 2170 2170 2170
2050 1980 1980 1980
1800 1730 1730 1730
1680 1610 1610 1610
640 600 600 600
290 340 340 340
250 320 320 320
250 320 320 320
0 80 80 80
80
0 10 10
0
80 10
5
5
80 10
0
Figure 4-The ARPA example. The locations of the nodes (from Kleinrock 7) are: (1) Hanover, N.H., (2)-(5) Boston Area, (6) Murray
Hill, N.J., (7) Washington, D.C., (8) Pittsburgh, Pa., (9) Ann Arbor, Michigan, (10) Urbana, Illinois, (11) St. Louis, Mo., (12) Salt
Lake City, Utah, (13)-(15) San Francisco Bay Area, (16) Santa Barbara, California, (17)-(19) Los Angeles Area
is also locally optimum. Most of the local optima are
due to this phenomenom, suggesting that greater
computational efficiency would have resulted from
lumping neighboring sites into a single network node
for an initial application of the algorithm, followed by a
stage of finer calculations. Such artifices are hardly
necessary in problems of this size, however. The
sequence of six runs depicted in Figure 5 was carried
out on an IBM 360/91 in less than ten seconds, including Fortran compilation.
EXTENSIONS
Path tracing on a related problem
One feature of the path-tracing technique is its
versatility. It can be applied to problems that do not
Update/Query Optimal Allocation
Percent
10
20
30
40
100
2,10,14
9,14
10,14
10,12
10
Cost
#Local Minima
117,544
188, 738
242, 546
291, 754
427,460
140
88
88
77
19
Figure 5-Results for the ARPA example
fit the linear programming framework. As one example
consider the following modification of the file allocation
model. The cost function as defined in the text assumes
that the expense of transmitting an update message to
all copies of the file is the sum of the costs of communicating with each copy separately, as if a distinct
message had to be sent from the up dater to every file
node.
Actually, the preferred mode of operation would be
to relay the message through the network in the most
economical manner. The resulting cost is less than that
incurred by sending duplicate messages. It is the cost
associated with the most economical subtree of the
network that contains the originating node and the
file nodes (see Figure 6). This new cost function defined
when update costs are calculated in this way is nonlinear in a very complex way. Yet the path-tracing
algorithm can still be applied to the allocation problem.
We no longer have the assurance provided by Theorem
2, which guarantees that the method will generate the
optimal allocation. However, the cost function behaves
in much the same manner as before. It still consists of
two parts: an update (and fixed cost) term that increases as additional file copies are allocated, and a
query term that decreases with additional copies. The
algorithm may be heuristic in the new framework, but
with only slight modification it can be programmed to
determine at least allocations of the type we have called
"local optima," of which the true optimum is one.
624
Spring Joint Computer Conference, 1972
4
Given Network:
~
file nodes,
Q
node originating an update.
Linear cost of update as per ceI) = 2 + 3 + 8 + (8 + 5) + 7
Figure 6.
=
33.
Most economical subtree.
Cost of relaying update
=
23.
Figure 6-Most economical subtree for relaying
an update message
Heuristic modification of the path-tracing routine
If the optimal solution to the allocation problem
consists of many network nodes then the general rule of
following every monotonically decreasing path in the
cost graph may be computationally too expensive. For
example, if the optimum contains 40 nodes then at
least 240 == 1012 values of the cost function must be
evaluated. In order to decrease the amount of computation, it is necessary to sacrifice optimality for
speed. We suggest several methods by which this may
be done in a reasonable manner.
Assume that the cost graph is being searched levelby-level (i.e., in parallel). At each level, the vertices
which are lower in cost than their antecedents are
recorded. We call these vertices "admissible" and denote them by the set Ak at the kth level. We wish to
carry only a limited number of the members of Ak into
the (k+1)th stage. One plausible selection rule is to
keep the vertices having the lowest cost. Alternatively,
we may reason that if two assignments are similar
(i.e., differ in only a few file nodes) then probably
their union will also lie on a monotonic cost path, and
it would' be redundant to trace paths through both. In
this view, we want to select the most "dissimilar"
vertices from A k • Several techniques are available to
do this selection. One method, previously used in
pattern recognition, is the following. Order the members
of Ak arbitrarily, specify a threshold T (a parameter),
and examine the members of Ak in order. Denote by
Ak' the subset being formed. The first member of Ak'
is the first member of A k , say al. The next member of
Ak' (denoted a2) is the first member of Ak which differs
from al by at least T units. Next, test for an aa which
differs from both al and a2 by at least T and so on. If
Ak' has too many members, or too few, the routine
may be repeated with T larger, or smaller, respectively.
The set Ak' is used to generate A k +l , which is in turn
thinned down to A k +l '.
A third method has actually been programmed and
compared with the general search technique. The
procedure is to do complete path-tracing (applying
Theorem 2) up to a level of the cost graph at which set
Ak begins to get too large. From this level on, only the
most "promising" paths are followed. For example, as
programmed the cost graph is completely evaluated
through the second level (2-file nodes per vertex).
From each admissible second level vertex only a single
path is followed; namely, that path which gives minimal
cost at each succeeding level. Since this program only
has one-step look ahead, the optimum may be missed.
In sample runs on the ARPA problem, the optimum
was always found (for each value of the update/query
parameter), although local optima were sometimes
overlooked.
This heuristic program was also tested on the ARPA
configuration using the revised cost function described
above, i.e., a function which assumes that updates are
relayed between file notes in the most economical
manner. Use of a simplified program is called for in this
case; the heuristic program required 12 minutes to
repeat the five runs of Figure 5, which were performed
in under ten seconds using the linear cost relationship.
Figure 7 shows the allocations produced by this experiment. These assignments may not be global optima.
They do satisfy our definition of a local optimum. Note
that, as expected, for the same traffic more copies of the
Update/Query
Percent
10
20
30
40
100
Optimal Allocation
(Nodes)
2, 6, 8, 9, 10, 12, 13, 14, 16, 18
2, 8, 10, 12, 14
2, 8, 10, 12, 14
8, 10, 12
10
Cost
38, 285
105, 800
171, 225
227,340
427,460
Figure 7-Allocation results using the nonlinear cost
model CARPA network)
Allocation of Copies of a File in an Information Network
file are assigned if updates are relayed. In addition,
total cost is reduced markedly under conditions of low
update traffic, indicating the importance of including
the more complex cost relations in the model.
CONCLUSION
The analytical properties of a linear-cost model of an
information network have been investigated. The
proportions of update traffic to query traffic generated
by the users of a given file in the network were shown
to determine an upper bound on the number of copies
of the file present in the least-cost network. In addition,
a basic property of the cost function was demonstrated
and shown to justify a path-tracing procedure for
determining the optimal assignment of copies of the
file to nodes of the network.
The model, while simple, expresses relevant features
of the tradeoff between the costs of querying and
updating in the network. Presumably, the general
properties derived apply at least approximately when
more complex models are considered.
ACKNOWLEDGMENT
Dr. M. E. Senko first pointed out to the author the
need for an allocation model which would distinguish
between the query and update activity in a network.
The work reported here owes additional debts to the
625
encouragement and commentary of Drs. C. P. Wang,
H. Ling and V. Lum.
REFERENCES
1 M A EFROYMSON T L RAY
A branch-bound algorithm for plant location
Operations Research Vol 14 No 3 pp 361-368 May-June
1966
2 E FELDMAN et al
Warehouse location under continuous economies of scale
Management Science Vol 12 No 9 pp 670-684 May 1966
3 K SPIELBERG
Algorithm for the simple plant-location problem with some
side conditions
Operations Research Vol 17 1969 pp 85-111
4 W D FRAZER
A n approximate algorithm for plant location under
piecewise linear concave costs
IBM Research Report RC 1875 IBM Watson
Research Center Yorktown Heights N Y July 25 1967
5WWCHU
Optimal file allocation in a multiple computer system
IEEE Trans on Computers Vol C-18 No 10 October 1969
6 V K M WHITNEY
A study of optimal file assignment and communication
network configuration in remote-access computer message
processing and communication systems
SEL Technical Report No 48 Systems Engrg La
Dept of Elect Engrg University of Michigan September
1970 (PhD Dissertation)
7 L KLEINROCK
Models for computer networks
Proc International Conference on Comm Boulder
Colorado pp 2.9-2.16 June 1969
Production and utilization of computer manpower
in U.S. higher education*
by JOHN
w.
HAMBLEN
Southern Regional Education Board
Atlanta, Georgia
Extensive modifications were made in the data collection forms for the third survey. The base year was
1969-70.
Problems resulting from lack of standardization in
the computer industry are well-known. Unfortunately
the educational and occupational nomenclature also
suffers this malady. The shifting of terms and definitions over the years can inject disastrous consequences
on estimates and, particularly, projections. Attempts
to make comparisons with other studies become even
more hazardous. In the following only estimates and
projections based upon the three surveys described
abdve will be presented. Two other papers in these
proceedings4,5 by Gilchrist and Weber will treat comparisons and incorporate higher education's role in
manpower production and utilization· to give a total
picture of the supply and demand for computer personnel in the U.S.
SURVEYS
During the past five years the Computer Science
Project of the Southern Regional Education Board
(SREB) has conducted three surveys on Computers in
U.S. Higher Education including their utilization and
related educational programs. These studies have resulted in three publications1 ,2,3 the first by the SREB
and the latter two by the National Science Foundation.
The first survey was a stratified random sample of
739 institutions, from a population of 2219, selected by
systematic random sampling within strata by the U.S.
Office of Education. Six hundred sixty nine or 92 percent of the institutions in the sample responded.
The base year for data collection was 1964-65 and
projections were requested from the institutions for
1968-69. The data collection instrument was designed
by the Mathematical Sciences Section of NSF to meet
their existing program needs for planning. Consequently, emphasis was placed upon the financial aspects
of college and university computer center operations
and only limited information was gathered with regard
to manpower training and utilization.
The second survey was much more comprehensive
and was sent to all institutions of higher education
listed in the U.S. Office of Education's Higher Education General Information Survey (HEGIS) file. Nineteen hundred sixty five or 79 percent of the 2477 institutions responded. The data collection forms were designed with the advice and counsel of thirty or more
national professional and institutional associations and
government agencies. The base year for reporting data
was 1966-67.
MANPOWER PRODUCTION
Educational programs in Computer Science, Data
Processing, Information Science, etc., exist in institutions of higher education at all levels. Two year programs terminate with an associate degree and four year
programs with a bachelor's degree. Master's and doctorate programs exist at many institutions. Although
computer science and data processing are by far the
most popular program names (see Table I) there appears still to be far too many different names used for
educational programs in institutions of higher education. Further consolidation is necessary to ensure a
healthy and unified development of the disciplines. The
efforts of the ACM Curriculum Committee on Computer Science6 and the ACM Committee on Computer
Education for ManagementS have and will continue to
have a unifying influence on academic programs in
computer and information science. The work of these
* The data upon which this paper is based was collected and
processed through partial support from the National Science
Foundation under contracts C465, C508 and C604. The SREB
Computer Sciences Project is also supported by grants from the
Esso Education Foundation and the IBM Corporation.
627
628
Spring Joint Computer Conference, 1972
TABLE I-Reported Degree Programs in Computer Science, Data Processing, Information Science, etc. for Academic Years
1966-67, 1969-70, 1970-71, and 1971-72
Associate
Program Name
Computer Science: Total
In Departments of:
Computer Science
Mathematics
Electrical Engineering
Computer and Information Science
Information and
Computer Science
Management Science
Industrial Engineering
Miscellaneous (fourteen)
Computer Programming:
Total
In Departments of:
Data Processing
Computer Programming
Miscellaneous (eight)
Information Systems:
Total
In Departments of:
Miscellaneous (nine)
Information Science:
Total
In Departments of:
Miscellaneous (six)
Systems Engineering:
Total
In Departments of:
Systems Engineering
Electrical Engineering
Engineering
Industrial Engineering
Doctorate
66-67 69-70 70-71 71-72 66-67 69-70 70-71 71-72 66-67 69-70 70-71 71-72 66-67 69:-70 70-71 71-72
Data Processing: Total
122
In Departments of:
Data Processing
0
Business Administration
Business
Computer Science
Miscellaneous (seven)1
0
Computer Technology:
Total
In Departments of:
Computer Technology
Miscellaneous (eight)1
Master's
Bachelor's
204
217
219
15
136
34
17
143
36
20
143
11
5
38
1
11
20
2
2
2
2
2
3
3
3
1
o
15
3
2
o
o
15
1
4
o
14
1
4
1
1
1
8
33
37
42
50
90
113
133
58
76
86
7
0
0
20
.27
30
52
23
8
1
1
1
1
10
3
4
9
8
8
66
26
11
37
7
40
19
35
o
23
0
0
o
0
o
2
o
o
o
21
25
26
5
6
6
12
2
13
1
2
1
1
1
1
1
1
o
o
o
o
o
o
o
1
o
o
1
1
o
35
50
54
59
39
49
22
24
25
28
8
9
4
3
12
13
14.
6
9
3
10
10
3
3
3
3
2
2
2
2
2
1
1
2
2
2
3
3
o
6
7
8
o
3
2
2
2
1
10
11
2
12
14
4
38
40
41
o
6
7
22
24
5
5
11
11
24
5
12
21
22
22
12
13
13
2
2
2
9
9
9
7
7
7
5
6
7
7
9
10
5
6
7
7
9
o
o
o
3
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
4
2
102
2
o
1
1
0
11
o
1
1
2
o
5
o
o
o
5
o
o
0
0
8
6
3
o
1
2
1
o
o
o
4
4
4
o
3
11
17
19
2
2
8
3
15
3
3
4
9
10
7
o
o
o
o
o
1
o
o
o
o
o
o
3
4
3
o
o
3
4
2
5
6
6
10
2
5
6
6
6
5
9
7
10
10
3
6
5
9
7
10
10
1
7
7
8
1
12
12
12
1
3
2
1
1
3
2
3
3
1
1
1
1
3
3
5
3
3
5
1
1
3
3
5
1
1
3
2
1
1
1
o
o
o
5
6
6
9
9
9
o
o
o
1
o
o
o
o
1
1
2
2
2
o
o
o
o
3
2
2
2
3
4
4
3
4
4
6
6
6
6
6
6
1
7
8
7
1
o
o
o
3
3
3
3
3
o
o
o
1
8
1
4
1
Production and Utilization of Computer Manpower
629
TABLE I-Reported Degree Programs in Computer Science, Data Processing, Information Science, etc. for Academic Years
1966-67, 1969-70, 1970-71, and 1971-72-Continued
Miscellaneous (seven):
Total
In Departments of:
Miscellaneous (ten)
1
1
1
5
6
8
1
5
6
6
3
5
5
1
1
1
5
6
8
1
5
6
6
3
5
5
TOTAL
142
302
323
332
72
148
182
206
78
116
137
142
46
73
82
85
Estimated Population
Totals2
178
405
433
445
90
198
244
276
98
155
184
190
58
98
110
114
! ( ) Refer to 69-70, 70-71, 71-72
2 Reported Totals x (Number Institutions in Population)/(Number Institutions Responding)
After the reportS of the ACM Curriculum Committee
for Computer Education for Management has had a
chance to be circulated, I expect to see a surge in the
master's level programs in Information Systems
(Analysis and Design).
The numbers of majors enrolled in undergraduate
programs have nearly tripled and the numbers of
graduates per year have increased fourfold between
1966-67 and 1969-70 (see Table II). Figure 1 shows the
growth trends at present. I do not expect significant
changes in these trends for the next three to five years.
After 1975 I believe that we can expect to see some
committees was supported by National Science
Foundation.
Since 1966-67 the numbers of degree programs have
doubled with the highest increase nearly threefold at
the bachelor's level. Three out of five of the latter
programs are called Computer Science and the next
largest group (26) are designated as Data Processing.
Twenty (20) new programsin Computer Science at the
bachelor's level were expected to be started during
1971-72 and the next highest increase was expected to
be at the master's level in Computer Science with sixteen new programs.
TABLE II-Reported Majors Enrolled for 1966-67 and 1969-70 and Degrees Awarded for 1966-67, 1969-70 and 1970-71
Program Name
Undergraduate
Graduate
No. Majors
Bachelor's
No. Majors
Associate
Master's
Doctorates
66-67 69-70 66-67 69-70 70-71 66-67 69-70 70-71 66-67 69-70 66-67 69-70 70-7166-67 69.;7070-71
Data Processing
Computer Science
Computer Programming
Computer Technology
Information Systems
Information Science
Systems Engineering
Miscellaneous (seven)
12815 27712
3187 10909
281
4786
2791
496
737
1198
100
546
113
893
356
Total
17729
49191
Estimated Population Totals! 22161
65916
1
872
62
78
13
0
0
0
3285
259
688
218
66
0
0
0
74
355
0
20
19
0
7
286
976
12
60
91
28
143
52
395
1537
32
88
133
78
149
107
317
159
63
2926 4725 446
0
63
0
0
53
0
31
241
6
240
627
64
402
48
15
925
1025 4516
5614 475
1648
2519
3949
6808
1281
7523
2208
3375
4936
9123
6051
3971
435
819
295
94
0
0
0
594
Reported Totals x (Number Institiutions in Population)/(Number Institutions Responding)
9
892
0
4
24
34
85
28
19
1249
0
9
43
66
98
60
0
1
133 187
0
0
0
2
0
1
3
11
2
10
18
2
198
0
2
6
13
14
20
594
1076
1544
139
229
255
742
1442
2069
174
307
342
630
Spring Joint Computer Conference, 1972
_Actual
_ _ Projected
9000
/
8000
/
/
/
/
/
/
/
I
/
I
6000
I
"0
Q)
IBI;
2. index of significance of A is greater than that
ofB;
3. difference of the exponents of A and B is five;
4. result requires one-bit left shift for normalization.
The execution times of the addition with an index of
significance and unnormalized addition on these
operands are 119 and 69 cycles, respectively. The index
method requires nearly twice as much time as the
unnormalized method for bookkeeping operations such
as extracting exponent, index and mantissa to perform
computation, shifting, testing, etc., separately on each
part.
The same algorithms were hand-coded directly in the
Interdata 4 microprogramming code for a comparison
with the software programs. In these directly-coded
microprograms, much redundancy introduced in the
emulator-translated microprograms was eliminated. The
index method was coded in 78 microinstructions and the
unnormalized method in 51 microinstructions. For the
670
Spring Joint Computer Conference, 1972
TABLE I-Estimated Execution Time
(in Interdata 4 clock cycles)
Software
Sequential
Microprogram
Parallel
Microprogram
Normalized Arithmetic
with an Index of
Significance
Unnormalized
arithmetic
Addi- Multi- Divition plication sion
Addi- Multi- Divition . plication sion
119
633
1210
69
655
1350
68
35
467
316
780
510
43
27
491
326
810
540
same operands, the microprogram for addition with an
index of significance takes 68 cycles whereas that for
unnormalized addition uses 43 cycles. Comparing execution times of microprogrammed algorithm with that of
software programmed algorithm, reduction realized by
hand-coded microprograms is remarkable. Microprogramming the algorithms, about 43 percent of execution
time is saved for the index method and about 37 percent
is saved for the unnormalized method. In other words,
the speed of performing significance arithmetic can be
increased by approximately 40 percent by directly
microprogramming.
Note that the execution of the Interdata microprograms is strictly sequential. If parallel data paths at
gate-level are available, a better execution time reduction rate may be expected. Assuming that the microprograms coded for the Interdata 4 can be executed in
"ideal" parallel, i.e., any possible parallelism in the
microprograms may be realized, the index method for
the two operands would take 35 cycles and the unnormalized method 27 cycles. Reductions realized in
this case are nearly 70 percent and 61 percent, respectively, over software programmed algorithms, and
approximately 49 percent and 37 percent over sequential microprograms. It may be anticipated that a
further comparison of the parallel microprogram with a
higher level language program for these algorithms
would yield more than 80 percent reduction in execution
time.
The estimated execution times of the other arithmetics is shown in Table 1. Since execution time varies
depending upon particular operands, an amount of
significance, etc., times shown are approximate. The
estimated execution times of normalized arithmetic
with an index of significance are based on 44-bit mantissas and those of unnormalized arithmetic are based
on 48-bit mantissas.
To illustrate the consequence of execution time
reduction in significance arithmetic realizable by microprogramming, the overhead execution times for n Xn
matrix computation are estimated. Although the execution time for arithmetic operations varies according
to the value of operands, an assumption is made that
the execution times computed in the simulation and
shown in Table 1 are about an average.
For an n Xn matrix addition, n 2 additions are necessary. When normalized addition with an index of
significance is used it would take 119 Xn 2 cycles for a
software program and 68 Xn2 cycles for a sequential
microprogram. For n= 10, this would mean 11,700
cycles for a software program and 6,800 cycles for a
microprogram. Furthermore, it is conceivable that the
difference becomes much larger if a large number of
bits must be shifted for normalizing. Unnormalized
addition would take approximately 69 Xn2 cycles in
a software program and 43 Xn 2 cycles in a microprogram. For n = 10, the software program for unnormalized matrix addition takes approximately 6,900
cycles and the microprogram 4,300 cycles.
An n Xn matrix multiplication requires n 3 multiplications and n2(n -1) additions. This would mean that
multiplying two nXn matrices using normalized
arithmetic with an index of significance takes
633 Xn3 + 119 Xn2(n -1) cycles in software
and
467 Xn3 +68 Xn2(n -1) cycles in microprogram.
Using unnormalized arithmetic, the same matrix multiplication would take
655 Xn3 +69 Xn2(n -1) cycles in software
and
491 Xn 3 +43 Xn2(n -1) cycles in microprogram.
From these execution time estimates, it is readily
observed that a small amount of reduction at microprogram level may be significant in the overall efficiency of computation.
REQUIREMENTS FOR COMPUTER
ORGANIZATION
There are a number of desirable features in computer
organization for an effective significance arithmetic.
Some of them may coincide with the numerical analysts' wishes in the design of computers for numerical
computations such as a large word-size, multiplelength arithmetic registers, etc. The requirements for
computer organization here, however, are considered
from the standpoint of microprogramming.
Microprogrammed Significance Arithmetic
The first requirement in computer organization for
significance arithmetic is a double-length register to
preserve significance. Wilkinson shows that if only a
single-length arithmetic register is available rounding
errors propagates to widen error bounds and to reduce
significance. 1 Besides ,preserving significance, a doublelength register may be used for double-precision arithmetic for greater accuracy.
A small arithmetic register large enough for computing exponent and index of significance is desirable
for parallel execution of microprograms. With this
register available, mantissa and exponent (and index
of significance) can be computed simultaneously. For
a faster normalized arithmetic with an index of significance, two such arithmetic registers may be necessary:
one for exponent computation, the other for index
computation. They are particularly useful in normalization in the index method. Normalization calls for left
shifts of mantissa and, for every shift, reduction of
exponent and index values. The two registers are used
for the exponent and index computations concurrently
with the mantissa shift operation to reduce overall
execution time.
Two or more registers capable of shifting one bit at
a time are necessary. They have many, uses in both
normalized and unnormalized arithmetics. They may
be used in multiplication for a multiplier and partial
product, in division for a dividend (and partial remainder) and a partial quotient, and in normalization.
At least one of them should be able to shift its content
in a group of bits at a time. Such register would reduce
a time requirement in binary-point alignment for
addition/ subtraction in which a shift of many bits is
often necessary.
Three or more mask registers for extracting any part
of the register content are desirable. If they can be set
to extract any part of the register content, the separation of exponent, index, and mantissa for separate
computation is done faster.
A high-speed, alterable microprogram memory is
desirable. It permits flexible specifications of controL
When a new algorithm for significance arithmetic becomes available, it may be microprogrammed to replace
the old microprogrammed algorithm without hardware
rewiring. Thus, the alterable microprogram memory
will prevent obsolescence of a machine with a small cost
for remicroprogramming control specifications.
The microinstruction format should be horizontal.
The horizontal microinstruction format permits
specifying simultaneous activities of multiple data
paths; it permits elemental control for efficient executions. Microprogram coding scheme must be simple,
however, so that basic controls can be specified easily.
If the microprogram operation code is encoded as
671
Sign bit for mantissa
Irgn bit foe exponent
mantissa
Figure lIa-Format for normalized arithmetic with an
index of significance
in the case of Honeywell H4200, microprogramming
becomes, somewhat restricted in terms of specifying
data paths. Therefore, a more general microprogramming method and supporting tools such as microprogram interpreter, simulator, etc., are desirable for easier
microprogramming.
The machine code instruction format should have a
provision for specifying the number of significant digits.
Basically the following machine code instructions are
desirable for significance arithmetic: the input instruction for specifying a number of significant digits of input
data; the significance arithmetic operation code separate from the regular arithmetic instruction; the output
instruction to output the number of significant digits.
The input instruction is a pseudo code that simply defines a constant and its significant digits. The significance arithmetic operation code may be the regular
arithmetic instruction with its tag field set to indicate
the significant arithmetic mode. The output instruction
to extract and output the number of significant digits
may be used to print out the number of significant
digits. It may be also used to pass the number of
significant digits to a routine that monitors significance
and determines the next action such as a use of multiple-precision arithmetic, etc.
A possible format for a number representation in a
60-bit word for significance arithmetic with an index is
shown in Figure Ila. It consists of two sign bits, one for
exponent, the other for mantissa, eight bits for exponent,
six bits for an index of significance, and 44 bits for
mantissa. A format for the unnormalized number
representation in a 60-bit word is shown in Figure lIb.
It consists of a sign bit for exponent, a sign bit for
Sign bit for mantissa
lrgn bit foe exponent
mantissa
Figure lIb -Format for unnormalized arithmetic
672
Spring Joint Computer Conference, 1972
TABLE II-Comparisons of the Two Significance Arithmetic Methods
Index method
U nnormalized
method
memory requirement
execution speed
microprogram
simplicity
parallelism in
procedure
range of
representable numbers
larger
nearly the same
slightly complex
more parallelism
smaller
smaller
faster add/sub
simpler
less parallelism
larger
mantissa, ten bits for exponent, and 48 bits for mantissa.
Clearly, for the same word size, the unnormalized format
has a potential capacity for maintaining a larger number of significant digit (because of a larger mantissa) and
representing a wider range of numbers (because of a
larger field for exponent).
None of the requirements discussed so far is extreme
or special-purpose oriented. Most of the desirable
features are in fact provided by the existing, generalpurpose computer except the alterable microprogram
memory. A general speculation, however, is that the
alterable, high-speed microprogram memory will be
available at a reasonable cost in the near future with the
advancement of memory technology. It will be used
more widely as better microprogramming techniques are
developed. In conclusion, the results suggest that the
existing microprogrammable computers are reasonably
well suited for microprogram implementing significance
arithmetic.
CONCLUSION
JVIicroprograms have been designed and shown in flow
diagrams for the two significance arithmetic methods:
normalized arithmetic with an index of significance and
unnormalized arithmetic. The two methods are compared in terms of speed, simplicity in microprograms,
and effects in computer organization.
Software implementation and microprogram implementation of significance arithmetic are also compared
to justify the microprogrammed implementation. A
software implementation of significance arithmetic
appears to require a formidable amount of overhead
computation.
The results of this study suggest many advantages
for the microprogrammed implementation of significance arithmetic. Whereas the unnormalized method
is considerably faster in addition than the index method,
the index method is more suitable to a computer with
parallel processable characteristics. The microprogram
using computational parallelism for the index method
is slightly simpler than that of the unnormalized
method. Although the difference in execution time
between the two methods is small, it can be significant
over a long period of time especially when arithmetic
functions are used more frequently in the computation.
Where memory requirements are of concern, the
choice seems apparent. If the sizes of exponent and
mantissa are fixed, the index method requires additional
bits for the index of significance. If the mantissa consists of m bits, it requires rIog2 m l* additional bits for
the index of every operand. For an nXn matrix, this
would mean that at least rIog2 m l Xn2 additional bits
are necessary.
If on the other hand the exponent, index, and mantissa are packed into a fixed word size, the size of exponent and/or mantissa fields becomes smaller for
the index number representation. The index method
in this case would suffer in the range of representable
numbers due to smaller exponent and mantissa fields.
A smaller size for mantissa would also mean less accuracy in representing numbers.
The observations and comparisons discussed above
are summarized in Table II. The entry comments in
the table are for the two methods relative to each other.
In conclusion, our studies have shown beyond doubt
that significance arithmetic can be implemented in
microprograms for a performance that costs little overhead ovel comparable regular floating-point arithmetic.
REFERENCES
1 J H WILKINSON
Rounding errors in algebraic processes
Prentice-Hall Englewood Cliffs N J 1963
2 H L GRAY C HARRISON JR
Normalized floating-point arithmetic with an index of
significance
Proc of the Eastern Joint Computer Conference
pp 244-248
3 N METROPOLIS R L ASHENHURST
Significant digit computer arithmetic
IRE Trans on Elec Computers Dec 1958 pp 265-267
* The notation rxl denotes the smallest integer greater than or
equal to x.
lVlicroprogrammed Significance Arithmetic
4 R E MOORE
The automatic analysis and control of error in digital
computation based on the use of interval numbers
Error in Digital Computation Vol 1 ed by L B RaIl John
Wiley & Sons Inc 1964
5 H S BRIGHT B A COLHOUN F B MALLORY
A software system for tracing numerical significance during
computer program execution
AFIPS Proc of SJCC 1971 pp 387-392
673
6 C V RAMAMOORTHY M TSUCHIYA
A study of user-microprogrammable computers
AFIPS Proc of SJCC 1970 pp 165-181
7 R L ASHENHURST
Techniques for automatic error monitoring and control
Error in Digital Computation Vol 1 ed by L B RaIl John
Wiley & Sons Inc 1964
Architectural considerations of a signal processor
under nlicroprogram control
by Y. S.
wu
International Business Machines Corporation*
Gaithersburg, Maryland
INTRODUCTION
BASIC DIGITAL SIGNAL PROCESSING
ALGORITHMS
The application of microprogramming to seismic,
acoustic and radar processing is well-known. 1,2,3,4 The
system architecture required to address wide bandwidth signal processing problems is of a general form
shown in Figure 1. In order to provide the high throughput which is required by digital signal processing,
parallelif>m is generally accepted as the proper design
concept for the signal processing arithmetic element. A
microprogram processor (or a hm,t processor) could be
used to control the arithmetic element which can be
either an associative processor,5 functional memory,6
parallel ensemble,7 matrix array processors or a vector
processor. 9 The efficient design of the microprogram
processor is the key to insure the high duty cycle
utilization of the expensive arithmetic element hardware. Parallel architectures fall far short of their expectations because of the control problem associated
with keeping all the hardware usefully occupied all the
time. 10
This paper surveys basic digital signal processing
algorithms. It proposes a signal processing architecture
consisting of a microprogrammed control processor
(l\1CP), a highly efficient sequential ~ignal processing
arithmetic unit (SPAU) and necessary buffer memories. Emphasis is placed on the MCP architecture because of its importance in enhancing the system performance. An application example, optimum processingll in frequency domain, is given to verify the applicability of the architecture.
Hardware technology surveys, and fabrication and
packaging considerations are beyond the scope of this
paper. The firmware and microprogramming support
software discussions are also omitted.
A wealth of literature, including several very good
text books is available in signal processing and digital
signal processing. 12 ,13,14 A brief description of some of
the processing algorithms is included here. In general,
linear filter theory and spectrum analysis techniques
form the baEis of digital signal processing. Time-domain
and frequency domain equivalence of processing is
widely assumed. In practice, time-domain digital
processing is only used in real time applications with
relatively short sample data block. The fast Fourier
transform (fFt) algorithm15 ,16 provides the efficient
digital processing link between time and frequency
domains, and frequency domain processing is preferred
for narrow-band analysis with fine resolution and large
quantities of input data.
Time-domain processing
Consider a sampled signal {x(tn)}, where tn=nT,
n=O, 1, ... nand T is the sample period. A linear
digital filter is written as:
N
y(t n )
=
L: h(t
m ) X (t n - m )
(1)
m=O
where {y(t n )} are filtered outputs of {x(t n )} and
{h(tn) } are sampled impulse responses of the filter.
Similarly, the correlation function of {f(t n )} and
{g(t n) } can be written as:
N
Z(t n) =
L
f(tm+n)g(t m)
(2)
m=~N
Another type of time-domain processing, which is
known as recursive filter, is commonly used for limited
number of samples to compute successive value of out-
* Presently employed at Naval Research Laboratory, Washington, D.C.
675
676
Spring Joint Computer Conference, 1972
where {Y (fj)} and {H (fj)} are discrete Fourier transforms of {y(t n)} and {h(tn)} respectively.
Similarly, the equivalent correlation function in frequency domain can be shown as:
Main
Processor
(GP Computer)
(6)
I
-
Microprogram
Processor
-
Arthimetic Element
• Associative Processor
• Functional Memory
...
• Parallel Ensemble
• Matrix Array Processor or
• Vector Processor
Figure I-System organization
puts. Let {x(t n )} be the input signal samples, then the
filtered outputs {y(t n )} are expressed by the linear
difference equation:
y(tn) =
N
r
k=l
k=O
L Wky(t n- k) + L
Akx(tn-k)
Fast fourier transform
Frequency domain processing
Let {X (fi)} be the discrete Fourier transform of a
signal {x(t n ) } that
N-l
L
n=O
X(tn) exp ( -i21rfj tn)
(4)
Since 1965, a great deal of attention has been given
to the fFt algorithm by the digital signal processing
community. Interested readers can find detailed derivations and variations of the algorithm in references
listed in the Bibliography.13.15.16.17 A simple derivation
is included below.
Let's rewrite the discrete Fourier transform expression shown in equation (4).
Ar=
where: i=
N-l
N-l
k=O
k=O
L Xk exp(21rirk/N) = L xkWrk
(8)
Y -1
W =exp(21ri/N)
wherei=y-1, j=O, 1,2, ... N-1 andfj=j(1/NT).
This discrete transform involves a couple of assumptions. Equally spaced time samples are assumed. Also
the sampling rate must be above the Nyquist rate,
twice the frequency of the highest frequency in the
waveform being sampled. When these criteria are met,
the discrete Fourier transform has parallel properties to
the continuous transform. The original waveform can
be completely recreated from the samples. Transformations between the time and frequency domains are performed by using the discrete transform and its inverse.
It can be shown that the equivalent frequency domain
digital filter in equation (1) can be written as:
Y(li)
It is seen that for N frequency domain samples, the
equivalent digital filtering or correlation function requires N complex multiplications instead of N2 productsum operations in the time-domain. Tremendous computational savings for large N can be achieved if an
efficient processing link between time domain and
frequency domain is pstablished. The fast Fourier
transform algorithm is this missing link.
(3)
where {wd and {Ad are weighting or filter coefficients
of the recursive filter.
For N sample points, time-domain processing requires
N2 multiply...sum operations. Therefore, real time application of time-domain processing is limited to short
sample data blocks only. Typically, N equals 64 or less.
X C!j) =
where {F(fj)} is the complex conjugate of the discrete
Fourier transform of {f(tn) }.
As a special case, the pmver spectrum density function is:
(7)
= X (fi)H (li)
(5)
N = number of samples
r = harmonic number = 0, 1, ... , N -1
k = time-sample number = 0, 1, ... , N - 1
Thus Ar is the rth coefficient of the Fourier transform
and Xk is the kth sample of the time series.
The samples, Xk, may be complex, and the coefficients, A r , are almost always complex.
Working through an example in which N = 8 will
illustrate some of the calculation short cuts.
In this case: j = 0, 1, ... , 7
k=0,1, ... ,7
Architectural Considerations of Signal Processor
To
put
these
into
binary
A PROPOSED SIGNAL PROCESSOR
ORGANIZATION
form:
j=j2(22) +jl(2 I) +jo
k=k2(22) +k l (2 1 ) +ko
Thus:
I
=
I
I
L: L: L: X (k2' kI' ko) [WCj24+i12+jo)(k 24+kl2+ko)J
677
(10)
The basic arithmetic operation performed by a signal
processor is the high speed multiplication in the form
of product-sum for time-domain processing and complex multiply for the frequency-domain computations
and the 1Ft algorithm. These operations are always
performed on arrays or blocks of sensor data. In other
words, signal processing deals exclusively with 'structured' data. A system architect faces:
ko=O kl=O k2=O
1. The design of a high speed Signal Processing
Arithmetic Unit (SPAU).
N ow the W can be broken down further:
2. The problem of how to keep this arithmetic unit
efficiently and usefully busy.
(11)
Since W8= [exp (27ri/8) J8= exp (27ri) = 1, the bracketed
terms equal one, and can be dropped from the computation. (Note that [exp(27ri) J2= 12= 1.) This saves
many calculations.
Then A (j2, jl, jo) can be obtained by sequentially
calculating the xs as follows:
I
Xl (jo, kl' ko) =
L: (k2, kl' ko) Wjok2 4
k2=O
I
X2 (jo, jl, ko) =
L:
The latter poses a bigger challenge because it dictates
the system through-put by collecting and controlling
sensor inputs, and structuring the input data in a manner that can be most efficiently accepted by the SPAU.
Typical functions are:
• 110 control
• Multiplexing or Decommutation
• Data conditioning
• Scaling
• Orthogonal addressing
1 (jo, ki' ko) WCi12+Jo)k1 2
kl=O
• Format conversion
• Data buffering, blocking and packing.
I
X3 (jo, jI, j2) =
L: = X2 (jo, jI, ko) WCi24+i12+Jo)ko
ko=O
The above listed preprocessing requirements for a
SPAU are characterized by:
• Relatively simple algorithms
Once these computation savings were found, one
may generalize that for N point fast Fourier transform
"72N log2N complex multiplications and summations
are required. For the equivalent digital filter operation
in equation (1), N (1+ log2N) complex multiplications
are performed including the 1Ft on input samples and
the inverse transform to obtain time domain filtered
outputs. Comparing with N2 operations required for
(1), this is a worthwhile saving in processing load,
when N is large.
What are the basic operations?
Product-sum and complex multiplications!
• Highly iterative operations
• Low precision
The advantages of using a Microprogrammed Control
Processor (MCP) rather than special purpose hardware for these interface functions are the lower cost of
such a general purpose architecture and the flexibility
provided· by the ability to change the microprogram.
Furthermore, microprogramming implementation of
these functions offers 5-10 times performance gain over
a conventional general purpose computer of comparable
technology.I,2,3 In addition, macro signal processing
functions can be provided by properly sequencing the
SPA U under microprogram control. Some of these
678
Spring Joint Computer Conference, 1972
If Writable Control Store (WCS) is considered, a dynamic paging hierarchy can again be established for the
microprogram execution. 18 •19 Since both data and the
programs are sequential and block in nature for signal
processing, no c'ache requirement is foreseen. For relatively long data blocks, buffer paging with respect to
the system bulk storage can be accomplished through
the MCP I/O control unit. No additional paging hardware will be required.
From
Sensors
Control
Unit
(IOCU)
Buffer lllelllories
Control Buss
Figure 2-Functional diagram of a microprogrammed
signal processor
macros could be:
•
•
•
•
•
•
•
•
•
•
Convolution Filter
Recursive Filter
Beam Forming
FFT
Inverse FFT
Correlations
Power Spectrum
Filter
Unpack
Matrix Operations
By requiring the system to be under microprogrammed
control, the designer is permitting a single piece of
hardware to be specialized to a particular type of signal
processing calculation by allowing for the design of an
optimum 'instruction set' for that calculation to be
loaded into the control store of the MCP.
Figure 2 depicts the functional diagram of a signal
processor under microprogram control. The major components are System Storage, MCP, and SPAU.
System storage hierarchy
The structured nature of signal processing requires a
block (or page) of data to be operated upon by the
SPAU. Therefore, SPAU performance specifications
define the buffer speed requirements for each 'page' and
the system through-put requirement determines the
transfer rate between the system bulk store and the
buffer memories. A system storage hierarchy is implied.
As to the microprogrammed Control Store (CS), one
may consider each signal processing kernel as a module
(or page) with highly repetitive execution duty cycle.
At least two independent buffer memories will be required because of the over taxing demands on buffer
memory cycles by the pipe-lined SP AU operations
while MCP ALU and IOCU are preparing the next
block of data for SP AU consumption. Two buffer
memories in conjunction with MCP can only support
a SPAU with a 4-cycle basic operation. If a 2-cycle
SPAU is required, four independent buffer memories
will be needed to achieve the desired performance.
A 64-bit buffer memory interface is proposed for the
purpose of increasing real time instantaneous signal
input bandwidth as well as enhancing the paging interface efficiency with the bulk system storage. Experience indicated that each buffer memory should be expandable vertically in 256 by 64-bit words increments
up to 4K words. lK to 2K 64-bit words buffer size is
commonly seen. It is intended that the buffer memory
is the same monolithic storage used for the microprogram control store for commonality and logistic simplicity. The speed of the buffer memory is defined by
the operational requirement of SP AU.
Control store
A 64-bit wide control store compatible with the
buffer memory is used for the microprogram storage.
Each micro-instruction is capable of executing the following operations in parallel:
• Access the Buffer Memories for One or More
Operands
• Manipulate Local Registers and Arithmetic
Registers
• Perform Arithmetic and Logic Functions
• Decode and Status Sensing
• Decision Making
• Form Next l\1icro-Instruction Address
• Other Special Controls
Architectural Considerations of Signal Processor
679
Allowing multiple micro-instruction formats, one can
easily reduce the micro-instruction width to 32-bit
with a degradation of l\1CP performance by less than
15 percent. Double fetch of micro-instructions can be
co.Il-sidered; however, microprogramming will be more
difficult in this case.
Since writable control store is used in the system,
dynamic paging of microprograms will be considered.
Tight kernels are characteristic for MCP microprograms in the signal processing environment. Small
page size (i.e., 64 micro-instructions) may be adequate
for a dynamic control store size of not exceeding lK
64-bit words.
Bulk system storage
Bulk System Storage can be provided as an I/O
attachment to the MCP-SPAU signal processing system
in the stand alone case. Or, the signal processing subsystem can be considered as interfacing through the
bulk system storage with the central computer complex.
In this case, bulk system storage can be a part of the
shared CPU main memory or auxiliary large core
storage (LCS).
The speed requirement of the bulk system storage is
dictated by the type of processing performed in the
l\1CP-SPAU. Assume a block of data with N points are
first transformed into N spectral elements in the frequency domain and then filtered by N corresponding
filter coefficients; the following are observed:
Data TransfersBulk System Storage to MCP-SPAU
N Input Data Points
N Filter Coefficients
MCP-SPAUto Bulk System Storage
N Filtered Outputs
ComputationsN + Y2N log2N Complex Multiplications
If single cycle data transfer and 2-cycle complex
multiply are assumed, the speed ratio between the bulk
system storage and the buffer memories is obtained as
(2+ log2N) /3. When N = 1024, the speed ratio equals
4. This allows bulk system storage bandwidth to be 4
times slower than the buffer memory speed.
Local stores
Local storages will be provided in MCP and SPAU
data flows for internal arithmetic operations. Further
discussions are deferred untillatBr sections.
Figure 3-Microprogrammed control processor data flow (MCP)
Microprogrammed control processor (MCP) architecture
The architecture of the MCP is oriented toward its
signal processing application as an interface and control
processor. The salient features of the MCP required by
this application are:
a.
b.
c.
d.
High-speed buffer and channels
Efficient interrupt scheme
Simple external interfaces
Ease of microprogramming
These design goals were achieved by:
a. Using two independent monolithic storage units
as buffer memories and linking them with a
wide 64-bit channel interface.
b. Using only three registers in the data flow and
matching the storage cycle time with the internal processing time in order to permit the interrupt overhead operation (save and restore) to be
performed in three micro-instructions.
c.Using a monolithic read-write storage as a microprogram control store. A 64-bit microprogram
instruction provides a control format that is 5 to
10 times more powerful than typical 16-bit instructions found in minicomputers and provides
the computing power necessary to perform the
interface tasks. A read-write control store provides the ease of program modification required
to efficiently debug the operational microprograms. It also offers dynamic paging of microprograms through the system storage hierarchy.
The basic data flow is shown in Figure 3. The func-
680
Spring Joint Computer Conference, 1972
tional units include:
a. Sequence Unit. The sequence unit is that portion
of the machine which controls the sequence of
logical operations by determining the order in
which control words are addressed from the control store. The sequence unit operations are
controlled by the control store word, storage bus
condition, data flow conditions, machine status,
and channel conditions. The address for each
control store word access is assembled by the
sequence unit from the above controlling sources
in the next address assembly register (NAAR).
The save address latch (SAL) holds assembled
addresses for storage during interrupt processing. The last address register (LAR) holds the
previous cycle control store address register
(CSAR) when a machine stop occurs.
b. Buffer Memory Control and Bussing. Each of
the basic buffer memories has a word width of
64 bits, used as four 16-bit words in the data
flow. The buffer control unit (BCU) serves as
an interface between the buffer memory and the
various devices that use storage, such as I/O
channels, the MCP data flow, and any other
direct access devices such as SPAU that may be
connected to it. The BCU includes a priority
determination unit, an addressing unit, a storage
bus, and fetch busses.
c. Data Flow. The dat& flow includes three 16-bit
registers that provide the necessary buffering
between the storage bus and the arithmetic and
logic unit (ALU). They are destination registers
for data fetch and ALU operations. Input selection is under direct control of the control store.
All three registers have connections to the storage bus to allow them to be saved following an
interrupt. Selection of operands to the ALU is
controlled by a control store field. The ALU is a
conventional 16-bit parallel adder and logic unit
that performs a function on the selected left (L)
and right (R) operands. 16-bits represents a 96
db dynamic range. Physical measurements or
control signals seldom require more than 16-bit
precision. Microprogrammed double-precision
can be used for rare exceptions. The ALU output
(Z) is latched when the function is completed and
held through the late part of the control cycle,
when the result is transferred to the destination
register. The registers are set late in the control
cycle and are held for an ALU operation in the
next cycle. The ALU functions include adding,
shifting, and logical operations.
d. Local Storage. A 16 word Local Storage is contained in the data flow. The local store provides
16 bit inputs to the ALU. The local store write
rpgister has an input from the ALU latch. Local
store is addressed from thr Local Store Address
Register (LSAR). The LSAR has inputs from
the X register, the CD fipld, and thp LSAR
decrementer. The Local Store can be accesspd and
written in one ::\lCP cycle. It can be pxpanded to
32 words. Or, a second local store can be added
to achieve the operations of two independent
register stacks within one ~lCP ALU cycle.
e. Literals. Two 16-bit literals are available to the
ALU for generation of constants and buffer
.
memory addresses.
f. Interrupt Processing. Interrupt processing consists of saving program status data that \vould
be destroyed in processing the interrupt, and restoring conditions so that the interrupted program may be continued after the interrupt has
been processed. The save operation is performed
in one micro-instruction:
SCXYS(O)
This micro-instruction stores the CSAR, X
register,Y register, S register, stats, and masks
in four consecutive locations in both buffer memories beginning at address 000 16 • The restore
operation requires two micro-instructions:
1. A(O) =X, B(l) = Y
This loads the Y register with the vaule to be
restored into S and places the CSAR value to
be restored into the X register.
2. A(2) =X, B(3) = Y, Y =S, RTN
This restores X, Y, and S registers; RTN
forces CSAR to be loaded from prior X
register value returning to the next address of
the routine that was interrupted and also
restores stats and masks.
The restore operation is .interruptable. Interrupts of MCP can be generated by I/O channels,
program stats and SP AU completion. There are
four programmable interrupt priority levels.
Signal processing arithmetic unit (SP A U)
In preprocessing, it is observed that there is no requirement for a hardware multiplier in interface or control functions. However, an extremely high duty cycle
multiplier is necessary to satisfy signal processing re-
Architectural Considerations of Signal Processor
quirements. Furthermore, a 'structured' multiplier will
be needed in this case.
In ord-er to accommodate both time domain and frequency domain operations, the SPAU is designed to
execute the following basic operation with implicit
addressing:
where i= 1, 2, 3, ... 4096 and A, B, and C are all
complex numbers
Although the SPAU provides a basic 16X16 complex
multiplier, it is hardware equivalent to four 16X 16 real
multiplier or one 32X32 fixed point multiplier. Under
the M CP microprogram control, the SP AU can function as desired in various configurations when application arises. For special case!Ft operations, block floating
point format may be assumed with 12-bit mantissa and
4-bit scaling.
The SPAU buffered operations can be interrupted by
the MCP when MCP ALU registers require a single
multiply operation, i.e., MCP register mode has priority
over the normal buffered mode of SPAU. The SPAU
buffered operations are initiated by MCP microprograms and SPAU interrupts the MCP on completion.
The SPAU design includes the necessary pipeline to
assume an asynchronous operational speed. The basic
SPAU operation requires two to four buffer memory
cycles dependent upon number of independent buffer
memories used in the system. Some special functions
are included in the SPAU design such as ! Ft address
generation and conjugate multiply.
The parallel matrix multiplier logic of SPAU is very
straightforward. However, the amount of hardware
in terms of logic gate counts is probably twice the MCP
ALUIIOCU combined. It is almost anti-climactic to
state again the importance of the 'lean' MCP design in
order to keep the 'fat' SPAU usefully busy.
AN APPLICATION EXAMPLE-ADAPTIVE
SPATIAL PROCESSING
-
Xk(fi)
Xk(j)
FFT
Filter
kj(fi)
----<~
lfi )
9
9
--
Y
681
kj(fi)
Iterative
Filter
Calculation
Figure 4-Adaptive spatial processing
tain the desired beam outputs
k
Yj(!i) = L20kj(!i)Xk (!i)
(14)
k=l
Where Y j ( Ii) is the jth beam output and OKj( Ii) are
optimum filter coefficients including spatial processing
in the frequency domain. These filter coefficients are
updated through iterative gradient search process to
minimize the output noise power. The output power
spectrum is then computed
(15)
Notice the block array forms of data which are efficiently processed by the SPAU. The MCP will control
the paging and 110 for the system.
The optimum gradient search algorithm first computes the gradient for minimization as an input-output
cross correlation function ZKj( Ii) that
Zkj(h) = Yj(!iom) {exp(j27r!iTjk)Xk(!N_i)
(16)
-Xj(!N-i) }
where Xj( !N-i) are average beam outputs computed
much less frequency. Notice the spatial term
exp (j27r!iTjk) in the equation and j = vi -1 in the exponent instead of subscripted j. In order to maximize
the output noise power change between mth and
(m-l)th iteration, an iteration step size aj(m) is
chosen that
N
The function flow of the application example is
shown in Figure 4. The mathematical computations required to achieve the 'optimum' processing are described below.
The sensor input signals XK (t) are first transformed
into spectral elements in frequency domain that
L: Y j ( !N-i;m)Qj( !i;m)
i=l
aj(m) = --------,------
(17)
N
L:
1
Qj( !i;m) 12
i=l
where
(13)
k
Qj( !i;m) =
Then the frequency domain inputs are filtered to ob-
L: X
k=l
k(
Ii) exp (j27r!iTjk) Zkj( Ii)
(18)
682
Spring Joint Computer Conference, 1972
then the iterative processing is completed by
(Jkj( h;m)
=(Jkj( h;m-1) -aj(m)Qj( h;m)
(19)
is approximately one tenth of that of a commercially
available general purpose computer with equivalent
performance.
and
Yj(h;m)
= Yj(fi;m-1) -aj(m)Qj(h;m)
In addition to loop controls for the gradient search
algorithm, the MCP will handle orthogonal addressing
and organize the optimum filter coefficients in such a
manner which can be efficiently retrieved from the
bulk system storage.
The distributed processing load of this application
to M CP and SPAU is normalized to M CP total processing load and tabulated below:
Percent
MCP
Load
FFT
Filter
Iterative Search
Power Spectrum
Total
9.8
86.0
4.2
100
4-cycle
SPAU
Load
9.7
69.7
17.0
0.4
2-cycle
SPAU
Load
4.9
35.0
8.6
0.2
96.8
48.7
It is noted that for the adaptive spatial processing
2-cycle SPAU will not be needed unless an additional
MCP unit is included in the system. The 2-buffer
memory configuration as indicated in Figure 2 will be
applicable to this problem. The load balancing between
MCP and SPAU is accomplished by the heavy involvement of MCP microprograms in the various processing
loop controls of the gradient search algorithm to compute the optimum filter coefficients. For less demanding
MCP control role in other signal processing applications, the 2-cycle SPAU with four buffer memories can
handle higher through-put when needed. Additional
MCP processing can also be applied to post detection
computations which are not described in this example.
CONCLUSION
The Microprogrammed Control Processor and the
Signal Processing Arithmetic Unit architecture presented in this paper blends economy, flexibility and
performance in one design. It can truly be a general
purpose signal processor. If ECL and bi-polar memories
are used for implementation, 50 nanoseconds microinstruction time and 100 nanoseconds complex multiplication speed can be achieved for ground based applications. The hardware size in terms of logic gate counts
ACKNOWLEDGMENT
The author wishes to express his sincere gratitude to
many people who participated in applying microprogramming to signal processing problems. In particular,
he would like to thank R. G. Baron and S. G. Francisco
of IBM for their pioneer work in seismic and acoustic
processing, R. A. Rieth of Teledyne-Brown and J. W.
Fisher of Bell Telephone Laboratories for their active
involvement in radar processing and G. L. Kratz of
IBM for general microprogrammed processor architecture work during the past five years.
REFERENCES
1 R G BARON W VANDERKULK S D LORENZ
A LASA signal processing system
IBM Federal Systems Division internal report Bethesda
Maryland November 1965
2 Large aperture seismic array signal processing study
IBM Final Report-Prepared for the Advance Research
Project Agency Washington DC Contract Number SD-196
July 15 1965
3 G D HORNBUCKLE E I ANCONA
The LX-l microprocessor and its application to real time
signal processing
IEEE Transactions on Computers August 1970 Vol C-19
Number 8
4 Y S WU G L KRATZ
Microprogrammed interface processor (MIP) and its
application to phased array radar
Tech Note Spring Joint Computer Conference May 1971
5 J E SHORE F A POLKINGHORN JR
A fast, flexible, highly parallel associative processor
Naval Research Laboratory Report Number 6961
Washington D C November 28 1969
6 P L GARDNER
Functional memory and its microprogramming implications
IEEE Transactions on Computers July 1971 Vol C-20
Number 7
7 J A GITHENS
An associative, highly-parallel computer for radar data
processing
In L C Hobbs et al eds "Parallel Processing Systems
Technologies and Applications" Spartan 1970 pp 71-87
8 R SENTNER
The advanced avionic digital computer
Ibid pp 203':'214
9 IBM 2938 array processor
IBM System Reference Library 1967
10 J E SHORE
Second thoughts on parallel processing
To be published IEEE International Convention March
1972
Architectural Considerations of Signal Processor
11 B WIDROW P MANTEY L GRIFFITHS
B GOODE
A daptive antenna systems
IEEE Proceedings Vol 55 Number 12 December 1967
12 Y W LEE
Statistical theory of commltnication
Wiley N Y 1960
13 B GOLD C M RADER
Digital processing of signals
McGraw-Hill N Y 1969
14 F K KDO J F KAISER Eds
System analysis by digital computer
·Wiley NY 1967
15 G D DANIELSON C LANCZOS
Some 1:mprovements in practical Fourier analysis and their
application to X-ray scattering from liquids
J Franklin Inst Vol 233 pp 365-380 and 435-452 April
1942
683
16 J W COOLEY J W TUKEY
An algorithm for the machine calculation of complex Fourier
series
Math of Comput Vol 19 pp 297-301 April 1965
17 W T COCHRAN et al
What is the fast Fourier transform?
IEEE Proceedings Vol 55 Number 10 October 1967
18 R W COOK M J FLYNN
System design of a dynamic microprocessor
IEEE Transactions on Computers Vol C-19 Number 3
March 1970
19 W R SMITH
Simulation of AADC system operation with an E2-B
program workload
Naval Research Laboratory Report Number 7259
Washington D C April 22 1971
20 S S HUSSON
Microprogramming principles and practices
Prentice-Hall Englewood Cliffs N J 1970
A building block approach to multiprocessing
by R. L. DAVIS, S. ZUCKER and C. M. CAMPBELL
Burroughs Corporation
Paoli, Pennsylvania
INTRODUCTION
MULTIPROCESSOR INTERCONNECTION
Today most computing systems have dedicated, selfcontained, single processors. When the load on the system exceeds its processing capabilities, it is necessary to
replace the original system with one of greater capacity.
It would be far better if the original system had been
modular in nature, so that additional processing modules could be added in a multiprocessing configuration
with the growth in processing requirements, just as
memory modules or I/O devices are added with the
growth in storage or peripheral requirements. lVIultiprocessing systems are not new, but they have been
previously limited by the processing time consumed in
controlling the processor modules. With the advent of
microprogrammed computers, however, control functions can now be implemented in microcode, and executed at a much faster rate than has been previously
possible. In addition, microprogrammed computers are
simpler and therefore more reliable than conventional
computers.
This paper describes a structure for connecting and
controlling a multiprocessor system using a building
block technique. The hardware is modular and includes
microprogrammable processors called "Interpreters",
memory modules, and devices. Each Interpreter is
interconnected with every memory module and every
device via a data exchange network called a "Switch
Interlock" .
The current operating system is a simple but comprehensive control program \V hich allows for all the basic capabilities of operating systems emphasizing multiprocessing, multiprogramming and error recovery. Plans are
being developed for an extended operating system which
would be a set of independent units of microcode selected from a library of such units for each individual
system. The building block approach has been used by
both the hardware and software implementors of the
system.
A major goal in multiprocessor system design is to
increase system efficiency by the sharing of available
resources in some optimal manner. The primary resource, main memory, may be more effectively shared
when split into several memory "modules". A technique
for reducing delays in accessing data in main memory is
allowing concurrent access to different memory
modules. With this concurrent access capability present,
an attempt is made to assign tasks and data to memory
modules so as to reduce conflicts between processors
attempting to access the same memory module. N evertheless, since some conflicts are unavoidable, a second
technique (reduction of conflict resolution time) is required. These two techniques are largely a function of
the multiprocessor interconnection scheme which
has been discussed by Curtin3 and others. 4,5
Figure 1 shows three basic functional interconnection
schemes. These are described in more detail in Curtin. 3
The disadvantages of the single bus approach (Figure
1) for many processors are:
(1) the obvious bottleneck in information transfer
between processors and memory modules due to
both bus contention and memory contention
(2) the catastrophic failure mode due to a single
component failure in the bus.
A solution to the first problem has been to increase
the frequency of operation of the bus. 3,6
The multiple bus approach is merely an extension of
the single bus approach where all processors contend for
use of any available (non-busy) bus. The advantages
are redundancy and allowing an appropriate number of
buses (less than the number of processors) to handle the
traffic between processors and memory modules.
The third approach utilizes a dedicated bus structure
(one per processor). Although this approach requires
more buses, it requires neither the logic nor, more im-
685
686
Spring Joint Computer Conference, 1972
•••
PRoe
PRoe
MEM
•••
MEM
I
(a) Single Bus IntercoAnection
•••
•••
•
•
•
(b)
Multiple Bus Interconnection
•••
•••
"There generally is no speed differential between
multiport and matrix arrangements. The major
difference lies in the ability to grow in wiring
complexity. Multiprocessors with multiport arrangements are generally wired, at production
time, to the maximum purchased configuration.
Future subsystem expansion generally requires
depot level rewiring. This problem generally does
not exist with the matrix arrangement. The maximum capacity is wired in but the switching logic
complement reflects the purchased system. Subsystem expansion entails purchase of added processor/memory modules (and necessary cabinetry if required) plus the required switch matrix
logic cards."
An important additional point is that even though all
parts of the matrix switch are co-located, they must be
designed such that the failure of one node is equivalent
(c)
Dedicated Bus Interconnection
Figure l-Functional multiprocessor interconnection schemes
portantly, the time for resolving priority between processors requesting the use of a bus. Proponents of this
approach contend that the time penalty for resolving
conflicts for access to a memory module is enough of a
price to pay without having to wait for the availability
of a bus.
In a Hughes report, 5 the authors distinguish the
physical differences between two multiprocessor interconnection schemes. The two approaches (one called
multiport and the other called matrix switch) are
shpwn in Figure 2.
The Hughes report characterizes the two connection
approaches as follows:
"In the multiport approach, the access control
logic for each module is contained within that
module, and intercabling is required between
each processor and memory pair. Thus, the total
number of interconnecting cables is the product
of the number of processors and the number of
memories. Each module must be designed to accommodate the maximum computer configuration.
"In the matrix switch approach, the same interconnection capability is achieved by placing the
access control logic for each module in a separate
module. The addition of this module to the system is compensated [for] by reducing the intercables required to the sum of the processors and
memories rather than the product and by not
penalizing the other modules with maximum
switching logic.
(a)
Multiport
MATRIX
SWITCH
(b)
Matrix Switch
Figure 2-Physical multiprocessor interconnection schemes
Building Block Approach to lVlultiprocessing
to failure of only one element attached to the matrix
switch. For example, failure of a processor-related node
must not disable paths from any other processor to any
memory module.
Apparent from the arguments in the Hughes report
is the desire to reduce the number of wires interconnecting the processors and memory modules. A way to reduce the wiring (in addition to the use of the matrix
switch) is by using serial transmission of partial words
at a frequency several times that of the processors. This
technique has been used by Meng6 and Curtin. 3 The
tradeoff here is between the cost of the transmitting
and receiving shift registers and the extra logic necessary for timing and control of the serial transmission
versus the cost of the wiring and logic for the extra interconnection nodes for a fully parallel transmission path.
Another factor adversely affecting efficiency in a
multiprocessing system is a variation in the amount of
M
M
•••
M
I--~f----+----I
C
•
I---I-----+-----l C
•
PERIPHERAL SUBSYSTEM (Disk, Tape, Printer)
•
DISPLAY SUBSYSTEM
SENSOR SUBSYSTEM (Radar, Navigation)
•
COMMUNICATION SUBSYSTEM
1--1-----1-----1 C
t---t----t----;1/01------+--+----+---t - - - t - - - - t - - - - ; I/O1------+--+----+----
' - - - ' - - - - -.........- - - - l I / O I - - - - - - L - - - L - - - . . I . . - - - -
687
SWITCH INTERLOCK
Figure 4-Distributed multiprocessing interpreter system
a dedicated bus, matrix switch with an optional amount
of serial transmission.
The Switch Interlock is a set of hardware building
blocks for connecting many Interpreters to many
devices and to many memory modules. Connection between Interpreters and devices is by reservation with the
Interpreter having exclusive use of the (locked) device
until specifically released. Connection with a memory
module is for the duration of a single data word exchange, but is maintained until some other module is
requested or some other Interpreter requests that
module.
In any such system it is important to keep the wires
and logic in the crosspoints to a minimum, while still
maintaining a specified transfer rate. This is achieved
by serial transmission of several partial words in parallel
through the crosspoints.
Consistent with the building block philosophy of
Interpreter-based systems, the Switch Interlock is partitioned to permit modular expansion for incremental
numbers of Interpreters, memory modules or devices
and modular selection of the amount of parallelism
in the transfer of address and data through the
Figure 3-Centralized multiprocessor system
computation versus I/O processing that must be done.
In previous multiprocessing systems I/O functions and
data processing functions have been performed in
physically different hardware modules with devices being attached only to the I/O controllers (Figure 3). (This
technique is typical of Burroughs D825, B 5500, or
B 6700.) In the Burroughs Multi-Interpreter system,I.2
however, processing and I/O control functions are all
performed by identical Interpreters whose writable
microprogram memory can be reloaded to change their
function. This technique allows a configuration (Figure
4) in which the devices are attached t.o the same exchange as the memories and processors.
Switch Interlock
The Multi-Interpreter interconnection scheme for
forming a multiprocessor is called a "Switch Interlock:"
r------
I
r-----,
's'
I
MEMORY
1
OE:E
r'---1---.L,
1,_---,,----, "-----_ _--1
I
I
1
I'-r---.---'
1
1
I
1
L ______ J
I
I
___ .JI
- -
I
I
I
l..L ___ ,
I
I
INPUT SWITCH
I
It
::
I I
:i
I
I
,T---
___-_-_-_-_--=-_-_---=-_=_:::~~
I
~-~-
I
I:
I
LL~I------------------~
J- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
: :
_ _ _ _ _ ...I
L ___________________________
Figure 5-Implementation of switch interlock
I
I
~
J
688
Spring Joint Computer Conference, 1972
Switch Interlock from fully parallel to fully serial.
Functionally, the Switch Interlock consists of parallelserial conversion r~.gisters for each Interpreter, input
and output selection gates, parallel-serial conversion
registers for each memory module and each device, and
associated control logic. Figure 5 outlines the implementation of the Switch Interlock and shows the functionallogic units repeated for each Interpreter, memory
module, and device. The bit expandability of the
Switch Interlock is shown by dashed lines between the
input/output switches and the shift registers associated
with the memory module, devices, and Interpreters.
The six basic Switch Interlock modules are described
below:
(1) l\1emory /Device Controls (MDC)
The IHDC is an interface between the Interpreter and
the controls described below (MC and DC), and the
control for the high frequency clock used for the serial
transmission of data. There is one l\1DC per Interpreter.
pends upon both the packaging and the "serialization"
selected for the application.
(5) Input Switch Network (ISN)
The ISN returns data from addressed devices or memory modules to the Interpreters (i.e., the ISN is a
"multiplexer"). This unit also handles wires for up to
four Interpreters and up to eight devices or memory
modules.
Shift Register (SR)
These units are optional and are parallel-to-serial
shift registers or serial-to-parallel shift registers using a
high frequency clock. These are used for serial transmission of data through the ISN's and OSN's. Their
size, number and location are determined by system
parameters.
Switch Interlock Block Diagram
(2) Memory Controls (Me)
The MC resolves conflicts between Interpreters requesting the use of the same memory module and maintains an established connection after completion of the
operation until some other module is requested or some
other Interpreter requests that memory module. This
unit handles up to four Interpreters and up to eight
memory modules. System expansion using this module
may be in number of Interpreters or in number of memory modules.
(3) Device Controls (DC)
Figure 6 is a block diagram of a Switch Interlock
connecting up to four Interpreters to eight devices and
eight memory modules. The shift registers shown are
optional and may be eliminated with the resulting increase in the width of the ISN and OSN transfer paths.
Although it is not indicated by this figure, the Switch
Interlock is expandable in terms of number of Interpreters, devices, memory modules, and path widths.
Overall Switch Interlock Control
In an Interpreter based system utilizing one or more
Interpreters, only Interpreters can issue control signals
The DC resolves conflicts between Interpreters trying
to lock to a device and checks the lock status of any
Interpreter attempting a device operation. This unit
handles up to four Interpreters and up to eight devices.
System expansion using this module may be in number
of Interpreters or in number of devices.
(4) Output Switch Network (OSN)
The OSN sends data and control from Interpreters
to addressed memory modules (i.e., the OSN is a
"demUltiplexer"). This unit handles wires for up to four
Interpreters and eight devices or memory modules.
The number of wires for an OSN (and for an ISN) de-
NOTE:Th,widthiofttItISN/OSN',or.dependentupon
the numblrof bih hingtronsmltt,d ..,lolly.
Figure 6-Switch interlock
Building Block Approach to IVlultiprocessing
to access memories or devices. A memory module or
device cannot initiate a path through the Switch Interlock. It may, however, provide a signal to the Interpreter via a display register or other similar external
request device. Transfers between devices and memories
must be via and under the control of an Interpreter.
Controls are routed from the Interpreters through
the MDC to the MC and the DC which, in turn, check
availability, determine priority and perform the other
functions that are characteristic of the Switch Interlock. Data and addresses do not pass through the MDC.
Switch Interlock Timing
Events are initiated by the Interpreter for access to
memories or devices. The Interpreter awaits return signals from the MDC. Upon receipt of these signals, it
proceeds with its program. Lacking such positive return
signals, it will either wait, or retry continuously, depending upon the Interpreter program (and not on the
Switch Interlock). Any timeout waiting for a response
may be performed by either the program or a device
that will force a STEP in the micropogram after a preset
length of time.
Among the significant signals which are meaningful
responses to an Interpreter and testable as conditions
are the following:
Switch Interlock has
Accepted Information
The address and data output registers of the Interpreter may be reloaded and a memory
or device has been connected.
Read Complete
Data are available to be
gated into the input
data register of the Interpreter.
The rationale for this "handshaking" approach is
consistent with the overall Interpreter-based system design which permits the maximum latitude in the selection of memory and device speeds. Thus the microprogrammer has the ability (as well as the responsibility) to provide the timing constraints for any system
configuration.
Device Operations
The philosophy of device operations is based upon an
Interpreter using a device for a "long" period of time
without interruption. This is accomplished by "lock-
689
ing" an Interpreter to a device. The ground-rules for
device operations are listed below:
(1) An Interpreter must be locked to a device to
which a read or a write is issued.
(2) An Interpreter may be locked to several devices
at the same time.
(3) A device can only be locked to one Interpreter at
a time.
(4) When an Interpreter is finished using a device, it
should be unlocked so other Interpreters can use
it. The exception is the case where devices locked
to a failed Interpreter might be unlocked with a
"privileged" instruction by another operative
Interpreter.
JVlemory Operations
lVlemory modules normally cannot be locked and are
assumed to require minimum access time and a short
"hold" time by any single Interpreter. Conflicts in access to the same module are resolved in favor of the
Interpreter that last accessed the module, or otherwise
in favor of the highest priority requesting Interpreter.
Once access is granted, it continues until that memory
operation is complete. When one access is complete,
the highest priority request is honored from those Interpreters then in contention. The Interpreter completing access is not able to compete again for one clock.
Thus the two highest priority Interpreters are assured
of access. Lower priority Interpreters may have their
access rate significantly curtailed. This problem is resolved through careful allocation of data to memory
modules.
Other Multi-Interpreter System Hardware
The executive concept described in the latter part of
this paper requires special hardware features. Although
in a multiple Interpreter system more than one Interpreter can execute executive programs at one time,
certain tables used by the executive must be locked for
modification by only one Interpreter at a time. The
Interpreter remains in this "table modifying" state for a
short time, thus minimizing executive conflict delays.
The locking capability is implemented with two "global
condition bits" per Interpreter which are chained to
other Interpreters in a priority scheme. These global
condition bits are 2 of the 16 testable condition bits in
each Interpreter. Each bit can be set in only one Interpreter at a time and must be programmatically reset
(the other condition bits in each Interpreter are reset
690
Spring Joint Computer Conference, 1972
-----r--·-- -----,
r---------l
"0"
•••
~r_----------~
"0"
I
• • • ~--4_----~~~
I
I
I
•••
I
CL
I
I
I
I
Set GC )
( Request
Set GC )
( Request
_
CL
Reset GC
INTERP.
#1
I CL
Reset GC
INTERP.
#2
L------ __ ~ ________ J
Reset GC
INTERP. :f:m
L- ________ J
Figure 7-Global condition priority resolver
when they are tested). An Interpreter instruction containing the "Set Global Condition Bit" operation will
set the specified global condition bit in that Interpreter
only if that bit is not set in any Interpreter and no other
higher (wired) priority Interpreter is requesting the
same bit to be set in its own Interpreter.
Figure 7 shows the method of resolving priorities for
each of the global condition bits. The instruction to set a
global condition bit is actually a request to set a global
condition bit. This request is latched for one clock time
during which time a decision is made to honor this request or not. The global condition bits are programmatically reset independent of other Interpreters.
The top string of horizontally connected gates (Figure 7) OR's is the corresponding global condition bit
from all Interpreters together. The other string of horizontally connected gates in the Interpreters is the wired
global condition setting priority. This priority could be
wired differently for the two global condition bits. It
should be noted that in a system with many Interpreters, these two "carry" chains could have a delay long
enough to affect the Interpreter clock rate. In these
cases, a carry-Iookahead scheme could be used to speed
up this path.
It shookl also be noted that such a scheme could be
implemented alternately via programming using Dijkstra's semaphores,1 or using memories with a readmodify-write cycle to insure one processor wasn't reading a memory location in the interval between a read of
that location by another processor and a subsequent
write of a modified value.
One more of the testable condition bits in each Interpreter is wired to provide an additional inter-Interpreter signal. This bit is called the Interrupt Interpreters bit and is simultaneously set in all Interpreters by an operation originating from any Interpreter. This bit is reset in an Interpreter when tested
in that Interpreter.
The global condition bits and the interrupt Interpreters bit are the only multiprocessing hardware
features which are part of an Interpreter. Special purpose logic in an Interpreter is thus minimized, making
it inexpensive and flexible enough to be used across a
wide spectrum of architectures from simple stand-alone
device controllers through multiprocessors. This versatility increases the quantity of Interpreters being produced, which in turn lowers the unit cost of an Interpreter.
Special devices (connected through the Switch Interlock) needed for multiprocessing are an interrupt display register and a real-time clock with time-out capability. The interrupt display register is needed due to
the limited number of externally settable condition bits
in each Interpreter. Such a display register is read as a
device by any Interpreter. The response of the display
register is a function of the interrupt handling philosophy of the particular application and the design of such
a device could be varied without affecting the basic design of the Interpreter or the Switch Interlock.
The same philosophy is true of the real-time clock.
Here, the intent of such a device is to provide an external counter for all Interpreters as well as a means of
Building Block Approach to Multiprocessing
forcing a program STEP in an Interpreter if that Interpreter didn't periodically reset its real-time clock.
This would prevent an Interpreter from waiting forever
for a response from an inoperative memory or device.
REPORT
TIME
PERIODICALLY
DEALLOCATE
RESOURCES,
UPDATE
SCHEDULE
TABLE
691
SAVE
STATE FOR
LATER
PROCESSING
MULTI-INTERPRETER CONTROL PROGRAM
The Multi-Interpreter Control Program is a simple,
yet comprehensive, operating system characterized by
the following capabilities:
"
(1) Multiprogramming and multiprocessing
(2) Fully automatic operation with manual intervention capability.
(3) Error recovery with no loss of data.
Multiprogramming and multiprocessing have characterized Burroughs operating systems for many years.
In previous systems, input/output functions and data
processing functions have been performed in physically
different hardware modules; I/O modules for the former
and processor modules for the latter. In the lVlultiInterpreter System, however, I/O control and processing functions are all performed by identical Interpreters,
and any Interpreter can perform any function simply by
a reloading of its microprogram memory. In the lVlultiInterpreter Control Program I/O operations simply become tasks which are indistinguishable to the control
program from data processing tasks except that they
require the possession of one or two I/O devices before
they can begin to run. (A task is defined as an independent microprogram and its associated "S" level program
and data, which performs explicit functions for the solution of user problems.) Whenever an Interpreter is
available it queries the scheduling tables for the highest
priority ready-to-run task, which may be an I/O task, a
processing task, or a task which combines both processing and I/O functions.
The control program operates automatically, as well
as under the control of the operator. The operator may
enter new tasks, delete old ones, or change the priority
of any task. He may add or delete hardware modules,
and call for diagnostic programs to be run. The operator
enters his commands through either the card reader or
the alphanumeric display console.
The Multi-Interpreter Control Program includes an
automatic error detection and recovery capability. All
data is stored redundantly to avoid loss of data should a
failure occur. The control program maintains this redundancy, in such a way that a restart point is maintained at all times for every task.
Figure 8 defines the flow of tasks through an Interpreter.
Figure 8-Flow of tasks through an interpreter
Task scheduling and initiation
Every time an Interpreter has no task to perform it
scans a Task Table and locates the highest priority
ready-to-run task. If there is no ready-to-run task this
Interpreter runs the diagnostic program, then (if the
diagnostic program indicates no malfunction) again attempts to schedule a task. When the Interpreter finds a
task which can be run the appropriate table entries are
updated. The Interpreter then loads its microprogram
memory with the task's code and begins to execute this
code. The task code must periodically cause the Interpreter to "report in" to a central "timeout" table.
Task termination
The task retains the Interpreter until the task is due
to be suspended (assuming that a timeout does not occur). The task first stores its state, then causes the
Interpreter to load its microprogram memory with a
portion of the control program. This recopies changed
memory areas to ensure the redundancy required for error recovery, deallocates resources which the suspended
task had used, and updates system tables. Then the
Interpreter looks for another task.
Supervisory control
The operator can add or delete tasks or resources as
well as enter the data and code which individual tasks
692
Spring Joint Computer Conference, 1972
require. Commands and data may be entered via either
the card reader or an alphanumeric display. Each of
these devices is "owned" by a system task which inputs
data for the control program and for the other tasks in
the system. Each entry via the card reader begins with
a control card which specifies the nature of the entry.
When the entry is data or program, the control card
specifies the task and the area in that task where subsequent cards are to be loaded.
Commands and data are entered from the alphanumeric display in essentially the same manner as
from the card reader, a line on the display corresponding to a card.
Error recovery
The hardware of the l\'Iulti-Interpreter System detects failures in memory modules and in I/O devices.
When an I/O device fails, it is indicated as "not available" and a message to this effect is sent to the operator
(via both printer and display). The device will remain
"not available" until the operator enters a message to
the contrary. The task whose running caused the malfunction to be detected is immediately aborted, but it
will again run when the needed I/O device or an alternate is available. The redundant copies of storage
areas serve as the restart point for this rerun. (The primary copies cannot be used as the task was aborted at
other than a normal suspension point, hence not at a
valid restart point.)
When the core memory module fails while a task is
using it, the Interpreter which was running this task
marks the failed module "not available", and causes
the initiation of an error message to the operator. The
task which was being run is aborted. This task will be
reinitiated from the redundant core memory areas.
Interpreter failures are detected in either of two ways:
by the diagnostic program or by a timeout method, in
which every Interpreter "checks in" to a central tab1e
at periodic intervals, and every Interpreter checks that
every other Interpreter is checking in on schedule.
When an Interpreter fails it halts (or is halted), and the
task (if any) which it had been running is aborted, and
will eventually be reinitiated at its restart point by an
operative Interpreter.
The system can thus recover from a failure with no
loss of data, provided the primary and alternate storage
areas of a task are not both lost.
Tables
The operation of the Multi-Interpreter Control Program can be seen in more detail by examining the tables
which it utilizes. These tables are divided into two
classifications: system (global) tables, and task tables.
The former are located in core memory in a segment
called the "System Control Segment", and the latter
for each task are located in a "Task Control Segment".
for that task.
For error-recovery purposes all of these tables are
stored redundantly in two different memory modules.
Therefore there are actually two "System Control Segments", a primary one and an alternate one. The two
copies are identical at all times and whenever one is
updated the other is also. In a system that includes
bulk storage this redundancy would be maintained in
the bulk storage, and only one copy of any segment
would be in core memory when the task is running.
The tables for each task are similarly stored redundantly so that there are two copies of each Task Control
Segment. Included in each Task Control Segment are
pointers to allof the data and program areas which this
task may use. These areas may comprise one segment or
many contiguous segments, and may be used either
solely by this task or shared with other tasks. Each such
area is also stored redundantly.
Figure 9 illustrates how the core memory is utilized,
and shows the System Control Segment and its relationship to the Task Control Segments. (The term "segment" refers to a 256 word area of core memory.) The
System Control Segment includes a pointer to each
Task Control Segment, which in turn includes the
pointers to each area used by the task.
l\1emory modules are presently paired, where both
modules of the pair are allocated identically, so that the
primary Task Control Segment and the redundant Task
Control Segment for the same task have the same segment number. The same applies to data and program
areas.
System control segment
The System Control Segment is illustrated in more
detail in Figure 10. This segment is always located in
segment zero (the first segment) of some memory module. Its redundant copy is always located in segment
zero of some other module. Segment zero in all modules
is reserved for possible use as the System Control Segment or its alternate copy. If the module containing the
prime or redundant copy of the control segment should
fail, any remaining module is selected and its segment
zero is overwritten with the contents of the System Control Segment so that redundancy is immediately restored. Word zero in segment zero of every memory
module contains pointers to both the prime and al-
Building Block Approach to l\lultiprocessing
/
/
I
SYSTEM
CONTROL
SEGMENT
/
MODULE
o (AND4)
/
ENTRY (OI\IE PER TASK)
2-15
"A"
1-24
"B"
I
I
I
I
/
/
I
I
TASK CONTROL
SGM'T, TASK "e"
EflJT'~T:'
"C"
1-04
MODULE
1 (AND 5)
SEGMENT,
00
01
00
01
02
02
1-14
"U"
I
I
I
/
SEGMENT:
"V"
--T
2 SEGMENTS
SEGMENT:
00
1-09
- .. ~
02
./
03
~/
04
____ 04
05
AREA "0"
06
FOR TASK "B"
\
TASK CONTROL
SGM'T, TASK "A"
- - - - 05
\
2-19
"M"
08
AREA "V"
09
FOR TASK "C"
06
\
ENTRY*
07
07
"1'1"
09
2-07
~
11
13
-...
"-
14
- -
-"-
11
12
13
14
15
15
16
16
17
17
18
18
19
19
20
20
21
21
22
22
23
23
24
\
AREA'T'
FOR TASK "C"
- - - 10
-\- ". -
12
25
26
\
-----EI\JTRY*
------
27
TASK CONTROL
SGM'T, TASK "B"
"0"
31
-
24
25
26
27
1-06
I
U31
I
I
\
1-14
"R"
\
\
*ONE PER PROGRAM OR DATA AREA
Figure 9-Memory utilization
AREA ""I"
FOR TASK "A"
\
:
10
AREA "U"
FOR TASK "C"
ALSO
AREA "R"
FOR TASK "B"
RESERVED
01
- -;--/- --
03
MODULE
2 (AND6)
I
:
/
RESERVED
1-26
/
/
/
310
693
AREA "M"
FOR TASK "A"
694
Spring Joint Computer Conference, 1972
IADDRESS OF
REDUNDANT SCS
WORDO IN ALL
MEMORY MODULES
IADDRESS OF
PRIME SCS
(NOT USED)
~
TASK TABLE
r---ENTRY NO.1
~
TASK
TABLE
!
ENTRY No.2
-<
-
INDEXED BY
TASK NUMBER
(2 WORDS/TASK)
ENTRY NO.3
I
I
I
•
.... '
RESOURCE
AVAILABILITY
TABLE
I
1 = RESOURCE AVAILABLE
MEMORY MODULE
AVAILABILITY
IDENTITY OF
INTERPRETER
USING THIS RESOURCE
INDEXED BY
RESOURCE
NUMBER
1 = MODULE AVAILABE
}...f-
1 BIT PER SEGMENT PAIR
MEMORY
MAP
1 = AVAILABLE
a:
:
{
I
~ ~~:EXGE~ENT
NUMBER
~.~~.---------------~~~--------------~~---------------------t
TIME NEXT REPORT
DUE
TASK
NUMBER
INTERPRETER
TABLE
l
1 = RUN DIAGNOSTICS ON THIS INTERPRETER
1 = TIMEOUT REPORTED
lNDEXED BY'
INTERPRETER
NUMBER
1 = ERROR ASSOCIATED WITH
THIS UNIT
ERROR FLAGS:
PRINTER
ERROR FLAGS:
DISPLAY
INDEXED BY
UNIT NUMBER
UNIT NUMBER
ERROR REPORTS:
INTERPRETER FAILURE
TASK TIMEOUT
I/O DEVICE FAI LURE
MEMORY MODULE FAILURE
DIAGNOSTICS COMPLETE
I LLEGAL CARD
INDEXED
BY ERROR
CLASSI FICATION
I
Figure lO-System control segment
Building Block Approach to lVlultiprocessing
ternate System Control Segments, so that any Interpreter can "find its way back" to the System Control
Segment should it become "lost" because of a memory
module failure. Word zero of the System Control Segment itself is no exception, and includes these pointers.
Resource Availability Table
This table contains one entry for every hardware resource. The entry includes a flag-bit, which indicates
whether this resource is available or in use, and a field
which, when the resource is in use, gives the identity of
the Interpreter which is using it.
M emory Module Availability Table
This one-word table consists of one bit for every memory module in the system. This bit indicates whether or
not the module is "up" (available for use).
Memory Map Table
This table contains one bit for every usable segment
in core memory. A "1" in the bit position corresponding
to a particular segment means that the segment is unassigned. Since modules are paired, a single bit in this
table actually represents two segments, the prime segment and the segment in the paired module which holds
the redundant copy.
Interpreter Table
This table has one entry for every Interpreter, and is
used primarily to implement the "reporting" scheme
used to detect Interpreter malfunctions. Every task run
on the system is written so that, if it must run for "N"
or more seconds, the Interpreter will "report in" to its
entry in the Interpreter Table at intervals of less than
"N" seconds. This reporting consists of replacing the
"Time Next Report Due" field with the present time
plus "N" seconds. Every Interpreter, when it completes
its present task and is ready to find a new one, scans the
Interpreter Table (after first updating its own-entry in
this table), looking for overdue entries. If any are found,
they are reported to the supervisor. In addition, the
most significant bit in the entry which was found overdue is set, so that other Interpreters will not make this
same report.
Each entry in the Interpreter Table also includes two
other fields. The first of these is a 1-bit field indicating
that diagnostics are to be run on this Interpreter. This
695
bit becomes set from a command entered by the supervisor. When set, the Interpreter will run diagnostics at
the completion of the present task. Once diagnostics
have been run the Interpreter causes a message to be
sent to the supervisor indicating the test results, and
then resets the "Run Diagnostics" bit.
The final field in an Interpreter Table entry gives the
identity of the task which that Interpreter is currently
running.
Error Flags Table
This table indicates the error messages which are to
be sent to the operator. Such messages are sent both via
the line printer and via an alphanumeric CRT display
which is only used by the operator. Each portion of the
table consists of one word for every type of error.
Within each such word, the individual bits form an indexed vector which indicates more specific error information, normally the unit number of the failed unit.
When any type of error is detected, the appropriate bit
is set in both the display and printer portions of the
table. The actual printout is accomplished by a speci fic
task, the Error-Print task. This task (tagged "to be
run") runs as soon as the printer and an Interpreter are
available. When this task runs it scans the entire printer
portion of the Error Flags Table, and for each bit encountered formats and prints the appropriate message
and then resets the bit. This process continues until all
of the bits are reset. There is also an Error Display task
which functions in this same way to display error messages on the CRT screen.
Changing the System Control Segment
Whenever any change to a table in the System Control Segment must be made, the segment is locked.
(This locking is implemented using the "global condition" bits found in every ::\Iulti-Interpreter System.)
The required writing then takes place, to both the prime
and the redundant copy of the table, and the segment is
then unlocked.
The task table
The Task Table contains information about every
task in the system. Figure 11 indicates the contents of
an entry in this table, which consists of two words. The
first word contains the information which an Interpreter
in the process of finding a new task must examine to
determine whether this task is the one which should be
696
Spring Joint Computer Conference, 1972
FIRST WORD
IDENTITY OF
FIRST RESOURCE
NEEDED TO RUN
IDENTITY OF
SECOND SOURCE
NEEDED TO RUN
0= BEING RUN
IDENTITY OF REOUIRED
MEMORY MODULE
PRESENT PRIORITY
v'-----
''----v,-----'
READY-TO-RUN BITS
0= NONE NEEDED
SECOND WORD
PRIORITY AT COMPLETION
TCS LOCATION
INTERPRETER
NUMBER
PRIME AREA IN USE
ALTERNATE AREA IN USE
PRIME AREA READY
ALTERNATE AREA READY
Figure ll-Task table entry
selected. The most significant bit in this first word is
the "not-running" bit. This bit is reset whenever the
task is running and set at all other times. Next are the
"ready-to-run" bits. These bits must all be ones for the
task to be scheduled. If one or more of its bits are zero,
the task lacks something, other than an I/O device,
which it requires for running. For example, if the task
requires data to be supplied by some other task, one of
its ready-to-run bits would remain reset until the completion of the other task. Similarly, if the task in ques-
Building Block Approach to ::\1 ultiprocessing
tion is awaiting data from the card reader, a bit will be
left reset and will be set by the Card Reader Task after
the data has been loaded. These bits have no systemwide assignments, but are assigned for each application.
All unassigned bits remain set at all times. Any task can
reset any of its own bits, and can, upon its suspension,
set bits for other tasks.
The next field in the Task Table Entry is the "present-priority" field. Each task has a priority, and that
ready-to-run task with the highest priority is the one
which is selected.
In order for a task to be "ready-to-run", not only
must all of its ready-to-run bits be set, but also the core
memory which it requires, and any I/O devices which
it may need must be available. The remaining fields of
the first Task Table Entry word deal with these items.
697
There is a field which specifies the memory which this
task requires, and two fields which can specify up to
two I/O devices which it also requires. Before the task
can be considered "ready-to-run", the required areas of
memory, and all required I/O devices must be available.
The second word of the Task Table Entry contains
additional information about the task. The first such
field specifies the priority to which the task reverts
after it has completed running. (A priority-at-completion of zero indicates that the task is to be dropped from
the system at completion.) Next is the location of the
Task Control Segment for this task, as discussed in connection with Figure 9. Another field contains the
identity of the Interpreter which is running this task.
The final field in the Task Table Entry gives the
status of the core memory areas used by this task. The
(ONE PER TASK)
POINTER TO
ADDRESS OF THIS
TTE ADDRESS
(2 X TASK NUM.)
ADDRESS OF
STARTING SGM'T
TASK STATE AND PARAMETERS
COPY OF TTE (2 WORDS)
SET READY-TO-RUN
BITS IN OTHER TASK(S)
AT COMPLETION OF
THIS TASK
}
TTE NO. N
I
TTE NO. M
J
TTE NO. P
J
TTE NO. Q
I
1 = READ ONLY
PROGRAM
AND DATA
REFERENCE
AREA
POINTERS
SEGM'T
ADDRESS
NUMBER OF
CONSECUTIVE SEGMENTS - 1
(VARIABLE LENGTH)
DATA AREA
Figure 12-Task control segment
(FIRST IF MORE
THAN 1)
PATTERN TO BE "ORED"
WITH "RR" BITS OF
INDICATED TASK(S)
698
Spring Joint Computer Conference, 1972
Task Control Segment and all program and data areas
associated with task exist in two different memory
modules. When the task runs, only one module is actually used, and the other holds the state of this task as
it existed after it was last processed. This then serves
as a "restart point" should the present processing be
prematurely terminated by a failure. This alternate
area is not changed until this present processing has
been successfully terminated and the primary copy of
the task's Task Control Segment updated to form a
consistent whole which can itself be used as a restart
point. Only then is the Task Control Segment and all
data areas copied from the primary to the alternate
module.
Task control segment
Figure 12 indicates the contents of the Task Control
Segment. The first field points to the end of the Reference Area, since the size of the Reference Area may differ from task to task. (The otherwise unused end of
the segment may be used as a work area by the task.)
The second field gives the address of this module, so
that, when the task is completed, word zero of segment
zero can be found. (This word must be accessed in order
to locate the System Control Segment.) The third field
in this first word gives the identity of the present
task, and enables the Task Table Entry for this task to
be located once the System Control Segment has been
found.
The next section of the Task Control Segment holds
the state of the task, and also task parameters. First is
the address of the task code at which the task is to be
restarted. This task code then interprets the remainder
of the state information, if any.
The next section of the Task Control Segment contains a copy of the Task Table Entry (from the System
Control Segment), put there by the control program
when the task is initiated. The task may then conveniently modify its Task Table Entry. For example, the
task may reset one or more of its "ready-to-run" bits,
may indicate the identity of an I/O device which is required for further processing, or may even change its
priority. When the task is suspended, and it runs until
it suspends itself (unless it is suspended because of a
time-out), the Task Table Entry in the System Control
Segment will be updated by the control program to correspond to the Task Table Entry as found in the Task
Control Segment.
In addition to modifying its own Task Table Entry,
the task may, upon its suspension, cause Task Table
Entries for other tasks to have one or more ready-to-run
bits set. This is accomplished through the next word in
the Task Control Area. This word· allows the task to
specify up to four other tasks, and to supply a bit pattern to be "ored" with the ready-to-run bits for each of
these tasks. In this way the completion of one task can
be used to initiate another.
The final section in the Task Control Segment is the
reference area, which points to data and program segments which this task may use. Each reference area, in
addition to specifying the address of the segment(s) to
which it refers, also contains a "read-only" bit, and the
control program does not update the alternate copy of
any entry so tagged.
In summary, the Multi-Interpreter Control Program
allows any number of Interpreters to operate concurrently in a multiprocessing and multiprogramming
mode, allows tasks and hardware modules to be added
and deleted by the operator, and provides error recovery capability.
A BUILDING BLOCK APPROACH TO SOFTWARE
There are two approaches that may be followed when
developing an operating system for a multiprocessor
with microprogrammable Interpreters. One is an approach taken in the paper by Davis and Zucker! as well
as B. J. Huberman 8 where a machine language is developed. This language includes instructions which aid in
the development of an operating system. Since operating systems are organized about tables, lists, queues and
stacks the machine language developed allows for easy
handling of tables and other data structures.
We have presently chosen to take a building block approach. The Multi-Interpreter Control Program which
is our current system, presents the operating system as
a set of modules which may be obtained and run by an
Interpreter when needed. A new technique currently
under development generates an operating system
which is basically a set of independent "S" instructions
which may be used by any task on a defined configuration of firmware and hardware.
The building block approach used in the hardware
implementation of the multiprocessor is also being followed for the software development. A simple flexible
method of system configuration is defined. This system
has the ability to automatically select the appropriate
units, either system microcode or system tables, from a
prestored library of such units. This technique permits
using only those units necessary to perform all the desired system functions for a particular set of tasks. System functions are requested as needed from a Parts
List. The appropriate units are selected from the list to
Building Block Approach to :;Vlultiprocessing
form a customized system from a set of standard building blocks.
A primary design criteria of the operating system
(l\lanager) are flexibility, simplicity and reliability.
The operating system must be flexible enough for all
classes of problems to fit within its structure. All tasks
must be able to access all facilities provided by the system with a given configuration of the hardware. Simplicity is necessary to allow the system to be maintained,
changed, tested and initially coded with relative ease.
The system architecture must be sufficiently straightforward so that the users can easily comprehend its
structure and operation. The manager must also be reliable and the recoding of a single unit should not affect
the rest of the system.
To achieve the above criteria a modular, distributed
system manager has been defined. Each unit is a separate group of microinstructions designed to run in a
multiprogrammed mix and must be validated as a
699
standalone program. Extreme attention must be paid
to modularity, allowing new units to be plugged in without causing bugs in the rest of the system. Just as the
multiprocessor's hardware flexibility lies in its easily
changeable hardware configuration so should the multiprocessor's software flexibility lie in its easily changeable software configuration.
The system is composed of a single structure, and a set
of conventions for using this structure. Although systems will differ, both in type of units and hardware, the
set of conventions and the general structure will always
be used in the same way. The specific units needed for
the manager functions will be plugged into the structure
as needed.
The three segments defining the operating system are
the Locator, the Parts List and the units. The units are
the function modules of the system which do the desired
operations for the users. This collection of modules is
both programs and data (tables) normally thought of as
MANAGERS CALL
(UNIT 1)
,
LOCATOR
1
--.
UNIT 1
2
·
UNIT 2
~
•
•
•
•
•
k
•
,~
··
/-,
I
UNITk
\
.. ,, EXIT I
\
I
"-
•
•
•
•
•
•
n
·
UNITn
Figure 13-System manager
-r/
RETURN TO
CALLER
..
GO TO LOCATOR
FOR ANOTHER
UNIT
700
Spring Joint Computer Conference, 1972
-------,
I
I
I
I
I
I
______ --.J
Figure I4-Program traffic in a processor
the operating system. The tasks may select a unit
through the Locator. The Locator is a part of all tasks
and can access all units with a parameter called the
unit number which locates the required unit using the
Parts List. The Parts List is a table containing the location of all units associated with a system. Each time a
new system is required, a new Parts List and a new set
of units are developed. However, the Locator remains
the same for all systems independent of the kind of
hardware or software in use (Figure 13).
The traffic flow within a single processor is shown in
Figure 14. Each task will require the use of the system
units to perform some known utilities for them. This
includes functions like memory allocation, I/O formatting, conversions, editing, debugging, resource allocation, channel checking, etc. The utility units perform a
function and then return to the caller.
Interrupts are soft in a Multi-Interpreter System.
Testing for interrupts is processed by a standard interrupt testing unit called by a task. The detection of an
interrupt may suspend the caller task or it may call
another unit to process the interrupt before returning to
the caller. User tasks may suspend themselves or be
completed by calling the Suspend Self or End units.
When a program has been suspended or ended the next
highest priority program ready to run is selected by the
scheduler unit.
When an Interpreter task is assembled, a Source
Table is developed for all of the manager hardware dependent subroutines it may use, as well as all of the
functions needed by its Interpreter. This table becomes
input information to the operating system Librarian
(Figure 15). Each microprogrammed task has such a
table developed before it can run. When the task must
access the library units, it indexes into the Source
Table. The Source Table defines the library unit needed.
Source Tables for all tasks are used as inputs to the
Operating System Librarian. This information is used
with a catalog of units to develop the Parts List for the
system.
Each Source Table is modified to become a list of
pointers to the Parts List (Figure 16) and to the allocation portion of the Locator in microprogram memory.
As each unit is referenced during a task run, the Source
Table addresses the allocation part of the Locator.
Space is allocated in microprogram memory. The address pointing to the allocation routine is changed to
point to the desired unit now transferred into microprogram memory. The unit can now be executed. Unless this unit is deallocated from microprogram memory,
the Source Table now can point directly to the unit address in this memory.
To locate a unit for allocation in microprogram
memory, the allocator uses the pointer in the Source
Table to locate the pointer in the Parts List which points
to the unit. When the unit is present in main memory it
need only be copied into the required location in microprogram memory. When the unit is not present it must
STOCK
I
FUNCTION
MODULES
APPLICATIONS
·
CATALOGUE
OF
UTILITIES
STOCK
CONTROL FUNCTIONS
HARDWARE
I
I
FUNCTION
MODULES
I
I
LIBRARIAN
I
MANAGER
[;]
PARTS
LIST
I
•
•
DEFINITIONS
I
I
UNITl
···
UNITN
Figure I5-Automatic development of manager
I
I
I
Building Block Approach to :\Iultiprocessing
,-------
I
I
I
~
I
I
I
I
APPLICATION
PROGRAM
r
FREE SPACE
-
-
--
A
B
B
I
I
---
-
UNIT
B
I
I
J
-I
UNIT
X
I
I
-
-
-
-
J
A
-I
UNIT
A
I
I
I
____
I
Z
Z
I
I
I
-
-
-
C
I
I
I
l -'
I
-
l
J
I
I
I
I
I
N
I
I
I
x
I
I
I
~
1
I
I
X
I
I
-'
l
I
C
I
I
I
~
1
I
I
f-----
I
I
I
I
I
SOURCE TABLE
I
I
l
UNIT
1
I
I
I
UNITA
I
J
I
I
UNITC
UNITX
1
I
I
LOCATOR
ALLOCATOR
PARTS LIST
I
I
PROCESSOR
MICRO MEMORY
701
UNIT
z
I
I
UNIT
C
I
I
I
I
I
I
l
J
UNIT
C
I
Figure 16-Single local manager
be read into memory from a peripheral device as defined in the Parts List. This device will be defined by the
file directory (Figure 17) so that units may be accessed
through a hierarchy of storage in a recursive manner.
Since all units of code in the Parts List are reentrant,
all processors may have the same code at the same time
without interfering with one another (provided they use
different work areas). The work area is unique for each
task and within each work area is a unique Source
Table. Figure 18 shows the distributed local operating
system with many Interpreters. Each Interpre Ger is:
executing a different task, working ju a unique work
area, using a unique Source Table. .\.11 Interpreters
share the same Parts List and have identical Locator
sections. Anyone unit can be unique toa task or shared
by many tasks.
Since all system tasks are independent of each other,
the parts that bind the system together are the system
tables. These contain the important interfaces of the
system and the means of communication between In-
terpreters and! or processes. The system tables define
the three main attributes of the system: the tasks to run,
the resources available, and the Interpreters running.
A Task Table is used for scheduling and termination
of tasks at the global level. All information pertaining
to the state, selection criteria, needs, and scheduling
of a task will be found in this table. Intertask communication and task Interpreter communication is performed in the Task Table.
The Resource Table provides the information for allocating system resources among the different tasks by
the various units.
An Interpreter Table contains information pertaining
to each individual Interpreter. The Interpreters check
on each other for the detection of malfunctioning hardware, as well as inter-Interpreter communication via
this Table. An Interpreter may also use its table entry
as temporary storage or for storing information about
future tasks (e.g., an Interpreter may have to run routine diagnostics at the completion of its present task).
702
Spring Joint Computer Conference, 1972
I/O system units would become descriptor building
units or communication units instead of direct execution
I/O units. In some systems, tasks would do their own
I/O by having direct execution Parts List units while
other tasks in the same system might assume an I/O
module and pass descriptors to an I/O Task using
other units.
Those tasks of an operating system which stand alone
(e.g., I/O processor, system loaders, external communicators, etc.) are called and entered in the task table as if
they were an application task with a high priority. Their
ready to run bits can be set and reset by the system
units.
The structure of the building block type operating
system is a systematic way of constructing a manager
APPLICATION
PROGRAM
FILE
MUL TI PROGRAMMING
MULTIPROCESSING
B 3500 USER TASKS
B 5500 USER TASKS
MAIN MEMORY
LEVEL 3
(
TASK
TASK
TASK
TASK
TASK
TASK
TASK
1
2
3
1
2
3
4
,
CI
INTERPRETER
INTERPRETER
INTERPRETER
3
2
SINGLE TASK
ORIENTATION
EXTERNAL DEVICES
Figure I7-Accessing a unit
B 3500
EMULATION
B5500
EMULATION
LEVEL 2
INDEPENDENT
The building block approach assembles an operating
system from a series of directly executable "S" instructions, called units, which can be executed by any task.
These units may be different for different systems. A
system which would want an I/O module could assign
a high priority task the role of doing this job. Then all
MCP
SCHEDULER
,
INTERPRETER
LEVEL
,
MCP SCHEDULER
INTERPRETER
TASK
INTERPRETER
2
3
INTERP RETER
4
TASK TABLE SCHEDULER
Figure I9-Interpreter control level
INTERPRETER
2
LM~M~~
INTERPRETER
N
_ _ _ _ _ _ _ _ _ •_ _ _ _ _ _ _ _ _ _ _ _ _
Figure IS-Distributed local managers system
so that its functions can be applied with identical units
at all levels in a hierarchy of operating systems (e.g.,
course scheduling can be done at a global level while
finer scheduling can be used at the next level). An Interpreter may use a unit to select a system for emulation,
the task being that system's Operating System. Using
the resources assigned to it at the global level, this
Interpreter may choose to run its own set of tasks (which
look like data to the global system). The Operating System of an emulation may be totally in the "S" language
being interpreted or it may be running global units from
the Parts List on its own resources assigned to it at the
global level.
Figure 19 shows the control levels an Interpreter goes
through to execute a user task. Interpreter 1 has been
Building Block Approach to Multiprocessing
given resources and is scheduled at level 1 to run a B
3500 emulation. The initial task to be run is the operating system for the B 3500 called the lVICP. It in turn
receives data about the tasks to be run on a B 3500.
The lVICP sets up the tasks and executes them in a
multiprogramming environment. Figure 19 shows task
2 as running. Interpreter 1 is now running a B 3500
program and is a B 3500 system which is totally independent of the rest of the system except for reporting
status or requesting more resources.
Interpreters 2 and 3 have both been scheduled to become a B 5500 system. These Interpreters now have
become a multiprocessing B 5500 system running the
lVICP and the B 5500 tasks. Interpreter 3 is running
task 1 and Interpreter 2 is running task 3 of the B 5500
system's tasks in the B 5500 schedule.
Interpreter 4 has selected a task oriented emulation.
This is a microprogram specifically oriented to doing a
specific job. It needs no operating system but uses the
units available to it in the Parts List for executing common functions or manager type functions.
A task must decide how critical its need is for quick
access to a system unit. It may decide a unit is important and once it is located and stored in microprogram
memory it is left there for the duration of the task. A
task which is required to process real time interrupts
may want the interrupt testing unit to be a part of its
code and not have to indirectly address the unit via its
Source Table. Such a task may directly assemble the
interrupt unit from the library into its microprogram
memory. Other units which are less critical will be
brought from main memory each time they are accessed.
CONCLUSIONS
Microprogrammed systems in the past have been relatively simple and primarily suitable for small, dedicated
tasks. A technique has been needed to interconnect
many small microprogrammed processors into one
system, and to control this array of processors so that it
can dynamically and efficiently share a large load. This
paper has presented such a technique. The Switch Interlock allows an array of Interpreters to be integrated
into a unified system with many memories and periph-
703
eral devices. The type of software described here provides a means for controlling this unified system, and
allows control programs to be "custom-tailored" to each
application, providing maximum efficiency. Thus the
flexibility of microprogramming can now be applied to
large scale systems, and virtually any size system may
be constructed with a smooth evolution from a small
system to a large one. A degree of reliability and of simplicity in logistics and maintenance not previously possible in medium or large scale systems is provided due to
repeated use of a small number of relatively simple
module types.
Microprogrammed multiprocessing systems thus appear well suited for a wide variety of data processing
applications.
REFERENCES
1 R L DAVIS S ZUCKER
Structure of a multiprocessor using microgrammable b1lilding
blocks
Proc of National Aerospace Electronics Conference Dayton
Ohio pp 186-200 May 1971
2 E W REIGEL D A FISHER U FABER
The interpreter-A microprogrammable processor
AFIPS Conf Proc (SJCC) vol 40 Montvale NJ AFIPR
Press 1972
3 W A CURTIN
Multiple computer systems
Advances in Computers vol 4 F L Alt and l\!I Rubinoff Eds
N ew York Academic Press 1963
4 R CLARKIN
A minicomputer multiprocessing system
Proc of Computer Designers Conference Anaheim Calif
pp 231-235 Jan 1971
5 Seek flex preliminary design study, volume 1: System design
and rationale
Hughes Aircraft Co Ground System Group Report
FR71-16-430 July 23 1971
6 J D MENG
A serial input/output scheme for small computers
Computer Design vol 9 no 3 pp 71-75 March 1970
7 E W DIJSKTRA
The structure of 'THE' multiprogramming system
Communication of ACM VollI N 5 pp 341-346 May 1968
8 B J HUBERMAN
Principles of operation of the venus microprogram
Mitre Technical Report 1843 May 1 1970
The interpreter-A microprogrammable building
block system
by E. W. REIGEL, U. FABER, and D. A. FISHER
Burroughs Corporation
Paoli, Pa.
INTRODUCTION
system architecture as observed at the machine language level. Thus, the same hard ware may be made to
appear as a variety of system structures; thereby
achieving optimum processing capability for each task
to be performed. The ability to alter the microprogram
memory is called dynamic microprogramming as compared to static microprogramming which uses read only
memories.
As can be seen in the following brief historical review,
the concept of microprogramming was not widely accepted except academically during the 1950s. The
primary reason for this was its high cost of implementation, especially the cost of control memories. From the
mid-1960s to the present there has been a definite
trend toward microprogrammable processors and more
recently to dynamic microprogramming. This effort has
been inspired by rapid advances in technology, especially control memories.
What is microprogramming?
Digital computing systems have traditionally been
described as being composed of the five basic units: input, output, memory, arithmetic/logic, and control (see
Figure 1). 2\lachine instructions and data communicated among these units (as indicated by the solid lines
in the figure) are generally well-known and understood.
The control signals (as indicated by dashed lines in the
figure), are generally less well-known and understood
except by the system designer. These control signals
generated in the control unit determine the information
flow and timing of the system.
l\1icroprogramming is a term associated with the
orderly and systematic approach to the design of the
control unit. The functions of the control unit include:
1. Fetching the next machine instruction to be
executed from memory
2. Decoding the machine instruction and providing
each microstep control
3. Controlling the gating of data paths to perform
the specified operation
4. Changing the machine state to allow fetching of
the next instruction.
Brief historical teview of microprogramming
1951
The conventional control unit is designed uS:.I.lg flip-flops
(e.g., registers and counters) and gating in a relatively
irregular ad hoc manner. By contrast the control unit
of a microprogrammable computer is implemented using well structured memory elements; thus providing a
means for well organized and flexible control.
Microprogramming is therefore a technique for implementing the control function of a digital computing
system as sequences of control signals that are organized on a word basis and stored in a memory unit.
It should be noted that if this memory is alterable,
then microprogramming allows the modification of the
Wilkes! objective was "to provide a systematic approach and an orderly approach to designing the control section of
any computing system." He likened the
execution of the individual steps within
a machine instruction to the execution of
the individual instructions in a program;
hence the term microprogramming. This
view is hardware design oriented.
Lincoln Lab (see Van der PoeP) with
different emphasis used the term microprogramming to describe a system in
which the individual bits in an instruction directly control certain gates in the
processor. The objective here was to
provide the programmer with a larger
705
Spring Joint Computer Conference, 1972
706
1967
1967
CONTROL
UNIT
1968
1969
- - - DATA
- - - -
CONTROL
1970
Figure 1-Five basic functional units of digital computing system
1971
1956/7
1958-1960
1961-1964
Feb. 1964
1964
1965
1965
1965-1966
1967
instruction repertoire. This view is software design oriented.
Glantz 3 and Mercer4 pointed out that
through microprogram modifications the
processor instruction set may be varied.
Blankenbaker,5 Dinneen,6 and Kampe 7
described simple computers based on
Wilkes' model.
Great international interest was shown
from U.S., U.K., Italy, Japan, Russia,
Australia and France.
In Datamation 8- 12 five articles appeared
on microprogramming with emphasis on
how it might extend the computing capacity of small machines.
IBM System 360 (Stevens13) demonstrated that through microprogramming,
computers of different power with compatible instruction sets could be provided
(used read only storage).
lVlelbourne and Pugmire14 described microprogramming support for compiling
and interpreting higher level programming languages.
McGee and Peterson15 pointed out the
advantage of using an elementary microprogrammed computer as a peripheral
controller, i.e., as an interface between
computers and peripheral devices.
Green16 and Tucker17 described emulation of one machine on another through
microprogramming.
Opler18 coined the term "firmware" for
microprograms designed to support software and suggests the increased usage of
July 1971
microprogramming and describes its
advantages.
Hawryszkiewycz 19 discussed microprogram support through special instructions for problem oriented languages.
Rose 20 described a microprogrammed
graphical interface computer.
Lawson21 discussed program language
oriented instruction streams.
Wilkes22 and Rosin 23 provided surveys of
the microprogramming advances.
There were also announcements of many
new microprogrammed computers (e.g.,
Standard Computer-Rakoczi 24).
Husson25 provided the first textbook on
microprogramming.
Tucker and Flynn26 pointed out advantages of adapting the machine to the
task through microprogramming.
The IEEE Transactions on Computers
offered a special issue on microprogramming.
Interpreter design philosophy
The main objectives in the design of Burroughs'
Interpreter were simplicity, versatility, technology independence, and modularity. The reasons for these
objectives and their realization in the resulting machine
are stated in Table 1.
The basic concepts that characterize the Interpreter
are its modular structure using simple building blocks
and its application to a wide range of tasks through its
dynamic microprogramming.
A system is composed of a number of Interpreters,
main memories, input/output devices, and a data exchange called the switch interlock. The switch interlock
allows each Interpreter to communicate with all memories and devices and consists of controllable data paths
and conflict resolution logic for access to these paths.
The switch interlock (described in a companion paper)
is an extension of the designs that have been used successfully for many years in Burroughs' multiprocessing
systems (e.g., B 5500 and D 825).
INTERPRETER HARDWARE BUILDING
BLOCKS
The Interpreter is composed of three logic package
types; namely, the Logic Unit (LU), the Control Unit
(CU), and the Memory Control Unit (iVICU). The
microprograms which provide the control functions are
contained in two conventional memories; namely, the
The Interpreter
707
TABLE I
Desired
Characteristic
Simplicity
Reasons for Objectives
Resulting Characteristics
Omission of special functions not applicable
over a wide range of applications
Each Interpreter consists of:
a.
Three logic package types (each
less than 1000 gates)
Ease of maintainability:
Logic Unit (LU) -
Training
Control Unit (CU) -
Documentation
Memory Control Unit (MCU)-
Spare parts
b. Standard memories for microprogram
storage
(e.g. Read/Write or Read Only)
Versatility
Increase volume of production
Peripheral controller
resulting in reduction of cost
I/O controller
Central processor
Decrease design time and effort by
Technology
Independence
Special fu nction processor
eliminating the need for new hardware
Emulator of existing systems
developments for each new product
Direct execution of languages
To provide smooth transition to LSI
Partitioning allows implementation in variety
when economically justified
of packaging schemes
(e.g., SSI, MSI, lSI)
To meet variety of system costl
performance requirements with
Performance may be varied by simply imple-
optimum circuitry
menting in different circuit family
(e.g. MOS, TTL, ECl)
'Modularity
System
to provide smooth and unlimited
system growth
System modularity provided by modular
Switch Interlock
Internal - to provide a variety of
Internal modularity provided by use of
machine word sizes as needed by the
multiple logic units (LU).
application
Microprogram Memory (MPM) and the Nano program
Memory (N ano or NM). These units and their interconnections are shown in Figure 2.
The unique split memory scheme for microprogram
memories allows a significant reduction in the number
of bits for the microinstruction storage. It should be
noted, however, that a single microprogram memory
scheme (MP1V[ and N ano combined) may also be used
potentially increasing the clock rate of the system. In
addition, the cycle rates of the memories may also be
altered, to gain speed or reduce cost, without any redesign of the logic packages. In fact, a variety of memory organizations (single memory and different split
memory configurations) and memory speeds have been
implemented thus providing a range of cost/speed
trade-offs.
The LU performs the shifting and the arithmetic and
logic functions required, as well as providing a set of
scratch pad registers and the data interfaces to and
from the Switch Interlock (SWI). Of primary importance is the modularity of the L U, providing expansion
of the word length in 8-bit increments from 8 bits
through 64 bits using the same functional unit. The
CU contains a condition register, logic for testing the
conditions, a shift amount register for controlling shift
operations in the LU, and part of the control register
used for storage of some of the control signals to be
sent to the LU. The M CU provides addressing logic to
the Switch Interlock for data accesses, controls for the
selection of microinstructions, literal storage, and counter operation. This unit is also expandable when larger
addressing capability is required.
708
Spring Joint Computer Conference, 1972
Main Memory/Peripheral Address
Main Memory/Peripheral Data
Each Interpreter consists of:
•
Three types of logic packages
...
Logic Unit (LU)
-
Registers A1/A2/A3/B/MIR
...
Control Unit (CU)
...
Memory Control Unit (MCU)
- Registers SAR/Command/Condition
-- Registers MPCR/AMPCR; BR1/BR2/MAR; LlT/CTR
•
Two memory packages (standard available units - R/W or R/O)
...
Microprogram Memory (MPM)
...
Nanoinstruction Memory (Nano)
Figure 2-Interpreter building blocks
Logic unit (LU)
A functional block diagram emphasizing the LUis
shown in Figure 3. Registers AI, A2, and A3 are functionally identical. They temporarily store data within
the Interpreter and serve as a primary input to the
adder. Selection gates permit the contents of any A
registers to be used as one of the inputs to the adder.
Any of the A registers can be loaded from the output
of the barrel switch.
The B register is the primary external input interface (from the Switch Interlock). It also serves as the
second input to the adder, and can collect certain side
effects of arithmetic operations. The B register may be
loaded with any of the following (one per instruction) :
1. The barrel switch output
2. The adder output
3. The external data from the Switch Interlock (or
control panel switches)
4. The MIR output (the lVIIR is the output data
register to the Switch Interlock)
5. The carry complements of four- or eight-bit
groups (with selected zeros for use in decimal
arithmetic or character processing)
6. The barrel switch output ORed with two, three,
or four above.
The output of the B register has true/complement
selection gates which are controlled in three separate
sections: the most significant bit, the least significant
bit, and all the remaining central bits. Each of these
parts is controlled independently, and may be either all
ZEROs, all ONEs, the true contents or the complement (ONEs complement) of the contents of the respective bits of the B register.
The MIR buffers information being written to main
system memory or a peripheral device. It is loaded from
the barrel switch output and its output is sent to the
Switch Interlock, or to the B register.
The adder in the LUis a modified version of a
straightforward carry look-ahead adder. Inputs to the
adder are from selection gates which allow various
combinations of the A, Band Z inputs. The A input is
from the A register output selection gates and the B
input is from the B register true complement selection
gates. The Z input is an external input to the L U and
can be:
1. The output of the counter in the MCU into the
most significant eight bits with all other bits
being ZEROs.
2. The output of the literal register in the lVI CU
into the least significant eight bits with all other
bits being ZEROs.
3. An optional input (depending upon the word
length) into the middle bytes (which only exists
in Interpreters that have word lengths greater
than 16 bits) with the most and least significant
bytes being ZEROs.
4. The output of the A~lPCR in the lVICU into the
least significant 12 bits with all other bits being
ZEROs.
5. ALL ZEROs.
Using various combinations of inputs to the selection
gates, any two of the three inputs can be added together, or can be added together with an additional
ONE added to the least significant bit. Also" all binary
Boolean operations between any two adder inputs can
be performed.
The barrel switch is a matrix of gates that shifts a
parallel input data word any number of places to the
left or right, either end-off or end-around.
The output of the barrel switch is connected to:
1.
2.
3.
4.
The A registers (AI, A2, A3)
The B register
Memory Information Register (lVIIR)
Least significant 16 bits of :.V[CU (registers
BR1, BR2, :MAR, Al\,lPCR, CTR)
5. Least significant three to six bits to CU (depending on word length) for the shift amount register
(SAR).
The Interpreter
709
External
Conditions
(16)
--
MICRO
PROGRAM
(54)
Nano
r---*
,'.~EMORY
(~\1PM)
Commands
!
-
Z Inputs
CTR/AMPCR/LiT
Type II
Instr.
1. Provide Commands
to LU
(Command Reg)
!
Commands
----
1. MPM Addressing
MPCR/AMPCR
A2
barrel switch
(SAR)
3. Control condition
testing and setting
Dynamic
2. Memory/Device
I
Xf
J• Y
t
BR1/BR2/MAR
,
BARREL SWITCH
AMPCR/CTR
LIT ICTR
!
Main Memory
I
+CTR/AMPCR/L1T
•
MIR
UP to 8
sections.
ea ch 8
bi ts wide
t
BR1/BR2/MAR
.
Logic Unit
h
ADDER
I
SAR
3. Special Functions
t
Ii B SELECT U
Addressing
MPM
Addr ess
B
A3
.J
Conditions
Je-J
l
A1
2. Specify shift
amount to
LIT
AMPCR
---
LOGIC
UNIT (LU)
CONTROL UNIT (CU)
SAR
rv'iEMORY CONTROL
UNIT (f\IICU)
from
S Memories
and
Peripheral
Devices
via SWI
NANO MEMORY
Type I
Instr.
~
r- Data Input
Address
J
J
to LU
Global Conditions
to Other Interpreters
and
•
Peripheral Addressing
Data Output
to S Memories and
Peripheral Devices via
SWI
Figure 3-Interpreter block diagram
··Control unit (CU)
This unit has five major sections (shown in Figure 4):
the shift amount register (SAR), the condition register
(COND), part of the control register (CR), the MP1\1
content decoding and the clock control.
The functions of the SAR and its associated logic
are:
1. To load shift amounts into the SAR to be used
in the shifting operations.
2. To generate the required controls for the barrel
switch to perform the shift operation indicated
by the controls from the Nanomemory.
3. To generate the "word length complement" of
the SAR contents, where the "complement" is
defined as the amount that will restore the bits
of a word to their original position after an endaround shift of N followed by an end-around of
the "complement" of N.
The condition register (CON D) section of the CU
performs four major functions:
1. Stores 12 resettable condition bits in the condition register. The 12 bits of the condition register
are used as error indicators, interrupts, status
indicators, and lockout indicators.
2. Selects 1 of 16 condition bits; 12 from the condition register and 4 dynamically generated during
the present clock time (by the previous instruction being completed) in the Logic Unit for use
in performing conditional operations.
3. Decodes bits from the memory for resetting,
setting or requesting the setting of certain bits
in the condition register.
4. Resolves priority among Interpreters in the
setting of global condition (GC) bits which provides a facility for inter-Interpreter lock-out
control.
The control register is a 36-bit register that stores the
710
Spring Joint Computer Conference, 1972
MICRO
PROGRAM
MEMORY
External
Conditions
MPM
(16 BIT WDS.)
Microlnnrl!ctions
Type I: N£no Addr.. , - - - - '
Input Cloel· Contror~ f~r:
AMPCR/BR1/BR2/MAR/CTR/SAR
Type II' Value to
{
l!~R ----~---------------~
AOV, MST,
LST, ABT
from Adder
True/Comp
From
Bitrrel
Switch
in LU
Shift Amount
To Ba"el !lwitch
MPM Address
Request ~ignals
for ~ Memory or
[)-.vices
From
Barr.'
in LU
ToLU
(Z Input)
Address for
.nd Device,
~
memory
Controls to:
Logic Unit Clock
COI'trol Reg. Clock
Condo Reg. Adjust
!l Memory/Peripheral Control.
MPAD Contrl.
~witch
(Z Input)
Figure 4-MCU JCU block diagram
subset of the control signals from the memory that are
used in the LU, CU and MCU for controlling the execution phase of a microinstruction.
The 1VIPM content decoding determines the use of
the 1VIPM as a Type I instruction (address) or as a
Type II instruction (literal) based upon the first four
bits of the MP1V1. Several decoding options are
available.
Memory control unit (MeU)
One MCU is required for an Interpreter (providing
access to 216 words maximum) but a second MCU may
be added to provide additional memory addressing
capability (232 words' maximum). This unit has three
major sections (shown in Figure 4):
1. The microprogram address section contains a
microprogram count register (MPCR), the alternate microprogram count register (AMPCR),
the incrementer, the microprogram address controls register, and their associated control logic.
This section is used to address the MPM for the
sequencing of the microinstructions. The
AMPCR content may be used as input to the
adder.
2. The memory/device address section contains
the memory address register CVIAR), base registers one and two (BR1, BR2), the output selection gates, and the associated control logic.
3. The Z register section contains registers which
are the Z inputs to the LU adder: a load able
counter (CTR), the literal register (LIT), selection gates for the loadable counter and their
associated control logic.
I nterpreter operation
The operation of the Interpreter is described assuming a split MPM (16 bits)/Nano (54 bits) memory
scheme (see Figure 5). During each clock, a microinstruction is read from the MP::Vr. The first few bits
of this microinstruction indicate which of two types of
instruction it is. If it is a Type I instruction, the remaining bits of the lVIPM: word specify a N anomemory address to be accessed. The Nanomemory is then initiated
and its output, a set of 54 bits, provides the control
functions as indicated in Table II.
The Interpreter
If the microinstruction is Type II (again specified by
the first few bits of the MPM word), the remaining
bits of the lVIP)\'1 word are stored into one of three
registers; namely, the SAR, LIT, or the AMPCR. The
determination of which register is to be loaded is also
specified by the first bits of the ]VIPM word. The N anomemory is not accessed during a Type II operation.
A Type II microinstruction has an implicit STEP
successor.
The sequencing of microprogram instructions is controlled by the following procedure: The Nanomemory
provides information to the condition testing logic indicating which condition is to be tested. The condition
testing logic provides a True/False signal to the successor selection logic which selects between the three
True and three False successor bits (also from the
Nanomemory). The three selected bits (True/False)
provide eight possible successor command combinations also shown in Figure 5.
The eight successor commands and their associated
interpretations are:
Wait
Step
Skip
Jump
Retn
Call
Save
Exec
Repeat the current instruction
Step to the next instruction
Skip the next instruction
Jump to another area of MPM (as
specified by AMPCR)
Return from Micro subroutine
Call a Micro subroutine
Save the address of the head of a loop
Execute one instruction out of sequence
The particular chosen successor command then provides controls used in the selection (MPCR/
AMPCR) and incrementing logic which generates the
next MPM address. Except for the EXEC command
the MPCR is loaded with this lVIPM address.
From MPM
711
TABLE II-Nanocodes
Nano-Bits
1- 4
5
6
7
8-10
11-16
17-26
27
28-31
32-33
34-36
37-40
41
42
43-48
49-50
51-54
Select a condition
Selects true or complement of condition
Specifies conditional or unconditional LU operation
Specifies conditional or unconditional external
operation (memory or device)
Specify set/reset of condition
Microprogram address controls (wait, skip, step,
etc.) for true and false successor
Selects A, B, and/or Z adder inputs
Carry control
Select Boolean or basic arithmetic operations
Select shift operation
Select inputs to A registers
Select inputs to B register
Enables input to MIR
Enables input to AMPCR
Enable and select input to address registers and
counter (MAR, BR1, BR2, CTR)
Select SAR preset
Select external operations (read, write, lock, etc.)
Each Type I microinstruction requires two clock
intervals for its completion. The first (phase I) involves
the fetching of the instruction from the lVIPM/N anomemories and the second (Phase 3) executes the fetched
instruction. Figure 6 illustrates these two basic phases
(1 and 3) of each Type I microinstruction.
It should be noted that each phase 3 (execution)
clock interval of instruction I is overlapped with phase
1 (fetch) clock interval of instruction I 1. Hence, the
performance of each microinstruction requires effectively one clock interval.
As seen in Figure 6 the fetch phase involves: ]VIPlVI
memory accessing, N anomemory accessing, the logic
for condition testing and successor determination and
in parallel the logic for loading the control register.
The execute phase includes adder input selections,
adder function, barrel switch shifting of the adder· output, and the destination register(s) loading. Figure 7
shows various timing examples for Type I and Type II
instruction sequences.
+
From
Barrel
Switch
SUCCESSOR COMMANDS
Command
Selection
Increment
INTERPRETER MICROPROGRAMMING
Comment
WAIT
MPCR
STEP
MPCR
SKIP
MPCR
JUMP
AMPCR
RETN
AMPCR
CALL
AMPCR
MPCR~AMPCR
SAVE
MPCR
MPCR~AMPCR
EXEC
AMPCR
Inhibit: MPM
addr-+MPCR
Figure 5-Microprogram instruction sequencing
The pattern of Is and Os in the MPM and N anomemories (together with the data) determine the operation of the Interpreter. The microprogrammer is concerned with the generation of these patterns to provide
the desired control functions. However, instead of
actually writing these patterns the microprogrammer is
assisted by a microtranslator (or assembler) that allows
712
Spring Joint Computer Conference, 1972
PHASE 1 (FETCH)
CLOCK
PHASE 3 (EXEC)
CLOCK
CLOCK
CLOCK
L
CONO
Instruction
M_N
L
T:~~
SUCC
DET
C.R. - - - - - 4 - A I S -ADDER --SSW -DEST
Dynamic
Conditions
(AOV,ABT,MST, LST)
PHASE 1 (FETCH)
PHASE 3 (EXEC)
COND
TEST.
M --N
L
Instruction
2
~~~c
C.R. D_ET
_ _ _--I-_ AIS- ADDER -BSW -
DEST
I
Dynamic
+Conditions
M = MPM ACCESS TIME
N = NANO ACCESS TIME
COND TEST AND SUCC DET. = CONDITION TEST AND SUCCESSOR DETERMINATION
BSW = BARREL SWITCH
DEST = BARREL SWITCH OUTPUT DESTINATIONS;I.E., REGISTERS (B, CTR, ETC.) AND THEIR INPUT LOGIC
C.R. = COMMAND REGISTER AND ASSOCIATED LOGIC
AIS = ADDER INPUT SELECTION FROM COMMAND REGISTER
Figure 6-Timing analysis, Type I instructions
him to write microinstructions mnemonically. The
microtranslator then scan~ these instructions and produces the pattern of Is and Os to be placed into the
MPM and N anomemories.
Figure 8 indicates the ease with which one can learn
to microprogram the machine and the simplicity of the
microprogram structure. The high degree of parallelism
extant in the Interpreter is also evident from the powerful statements that can be expressed. For example, the
following actions may be expressed and performed in
one instruction:
•
•
•
•
•
•
•
•
•
test a condition (for either True or False)
set/reset a condition
initiate an external operation (e.g., memory read)
perform an add operation
shift the result of the add
store the results in a number of registers
increment a counter
complement the shift amount
choose the successor microinstruction
It is also possible to perform these operations conditionally or unconditionally as suggested in Figure 8.
The group A and group B portions (either, neither, or
both) of the microinstruction may be placed before the
condition test portion of the instruction. This will result in that portion (A and/or B) being performed
unconditionally.
The following four microinstruction examples illustrate both the parallelism and the conditional/unconditional properties of the microinstructions.
(1) If NOT LST then set LCl, l\1Rl; Al+B+
1C~A2, l\1IR, CSAR, INC; Step else Jump
(2) Set LCl, l\IRl; If NOT LST then Al+B+1C~
A2, :lVlIR, CSAR, INC; Step else Jump
(3) A1+B+IC~A2, :VUR, CSAR, INC; If NOT
LST then Set LCl, ::\I[Rl; Step else Jump
(4) Set LCl, l\1Rl; A1+B+IC~A2, l\I[IR, CSAR,
INC; if NOT LST then; Step else Jump
In (1) the LST bit is tested and if not true, the local
The Interpreter
l.
All Type I unconditional ins tructions
t 1
a ~CR
a.
Al + B --. Al
b.
A2 + B --. A2
c.
A3 + B --. A3
d.
Al C -+ AI;
1
:3
A2
b -CR
1
:3
A:3
CR
C
:3
1
d'" ·CR
2.
:3
1
All type I instructions
Both AOV and ABT test true
a--CR
a.
Al + B --. Al
b.
If AOV then A2 + B -+ A2
c.
If ABT then A3 + B -+ A3
d.
Al C--'Al;
Ai
:3
1
AOVTest
1
b
CR
A2
:3
ABT Test
A:3
c~CR
:3
1
d -CR
1
3. All Type I instructions
AOV tests false; ABT tests true
a
a.
Al + B --. Al
b.
If AOV the n A2 + B-+A2
c.
If ABT then A3 + B --+A3
d.
AIC-+AI;
/
~CR
1
:3
1
CR Re: ins a
AOV Test
1
'IV
:3
"~
)(
ABT Test
CR
Cot
1
A:3
:3
d .... CR
4.
1
Type I and Type II instructions
Re sulting Al contains least four
bit s le ft jus tified
a.
2 -+ SAR;
3 -+LIT
2 ~S
:3 .L
2
b
b.
1
Al and LI'J:' C -+ Al
c.
4 -+ SAR;
d.
Al C --+ AI;
:3
/,CR Rem~ ins b
~CR
1**
:3
'If
:3
4 ... S
2
15 -+LIT
15 .... ·L
d .... -CR
4
Figure 7-Timing examples
:3
713
714
Spring Joint Computer Conference, 1972
~-
Use of nano memory (54 bits)
A
Nanobits
1-7
(7)
8-10
(3)
*. If Condition then Condition Adjust;
GC1/2
LC1/2/3
SAl
EX1/2/3
MST
LST
ABT
AOV
COV
INT
ROC
Set LC1/2/3
Set GC1/2
Set INT
Reset GC
B
51-54
(4)
External
17-41
(25)
LU
42-50
(9)
MCU/CU;
Control for:
A/Z Select
B/Z Select
Adder Function AMPCR
Shift Select
BR1/2
Device:
Destination(s)
MAR
Read/Write
CTR, INC
Lock/Unlock
SAR, CSAR
Main
Memory:
Read/Write
11-13
(3)
True Succ
14-16
(3)
else False Succ
wait
step
save
skip
jump
exec
call
retn
wait
step
save
skip
jump
exec
call
retn
*Groups A and B may be executed either conditionally as shown or unconditionally by being placed before condition test.
Type II - Loads any ~f 3 specified registers (no nano memory access, step successor)
Four variations
k ~
k ~
k ~
k1
SAR
LIT
AMPCR
~
SAR; k2~ LIT
Figure 8-Microinstruction types
condition 1 (LCI) is set, memory read is initiated
(1\IRl), the function AI+B+l is performed in the
adder and the adder output is shifted circular and the
result stored in both the A2 and MIR registers, the
content of the shift amount register is complemented
(CSAR), the counter is incremented (INC), and the
true successor (STEP) is selected.
In (2) the LCI is set and the memory read is initiated
(lVIRI) unconditionally (i.e., without considering the
LST bit). The remaining functions are conditionally
performed as in (1).
In (3), the functions Al+B+IC~A2, lVIIR, CSAR,
INC are performed unconditionally but set LCI and
lVIRI are performed conditionally.
In (4) the functions Set LCI, MRI, AI+B+IC~
A2, lVIIR, CSAR, INC are all performed unconditionally and only the successors Step and Jump depend
upon the LST test.
The Interpreter microprogramming reference card
(Figure 9) specifies the use of each of the MPlVI and
N ano bits and defines the meaning of the mnemonics
found in the microprogram examples.
Two simple examples demonstrating the microprogramming of the Interpreter are shown in Figure 10
Binary l\iJ:ultiply and Figure 12 Fibonacci Series generation. The comments serve to explain the function of
each microinstruction step. Figure 11 shows the microtranslator output (1 and 0 patterns for ::VIPM and Nano)
for the Binary lVlultiply example.
INTERPRETER APPLICATIONS
General
As mentioned earlier, one of the design objectives
was to provide versatility so that a wide range of applications may be performed. The tasks to which the Interpreter has been successfully applied include peripheral controllers, emulators, high level language executors, and special function operators. This versatility
The Interpreter
715
preter approach to their implementation will be
described.
allows the Interpreter to attack not only a wide range
of problem areas but also every phase of a problem
solution.
As indicated in Figure 13 a data processing facility
receives programs written in either machine language
or a high level language (e.g., Algol, Cobol, Fortran)
and data upon which these programs operate. If the
program is written in a high ]evellanguage, then a compilation (or preprocessing) phase may be performed to
translate this program into machine language form before execution. Each phase of this problem solution
operation-recognition, code generation and execution-can be performed by a microprogrammed processor; in fact, each phase can be tuned to optimally
perform the task.
Three main data processing functions to which the
Interpreter may be applied are: Emulation of existing
or hypothetical machines, "direct execution" of high
level languages, and problem solution through microprogram "tuning" of the machine to the problem. These
three function areas-emulation, "direct execution,"
problem "tuning"-will now be defined and the Inter-
Emulation
In a conventional (non-microprogrammable) computer, the control unit is designed using a fixed set of
flip-flops and decoders to perform the execution phase
of the operation. The execution phase includes the
fetching of machine instructions, calculation of effective operand addresses, and the provision of each microstep command in the performance of the machine
instruction.
Emulation is defined in this paper as the ability to
execute machine language programs intended for one
machine (the emulated machine) on another machine
(the host machine). Within this broad definition, any
machine with certain basic capabilities can emulate
any other machine; however, a measure of the efficiency
of operation is generally implied when the term emulation is used. For example, if a conventional computer
MICRO CONTROLS
1 2 3 4 5 6 7 8 9
1011 1213141516
o ~I *
SAR
1999999
1 0
SAR
1
AMPCR
I*
1 1 0 ~I
*
01 ~
III
1 1 1 11
~
*
*
iii
~ ~
~
9
~
o
0
Condition Adjust -- CAJ
~
0
SET LC2
SET GC2
RESET GC
SET INT
SET LC3
SET GCI
SET LCI
LIT
LIT
NANO ADDRESS
Unused
Shorter fields are right justified
NANO CONTROLS
Parentheses surround optionallexic units,
provided by default.
GCI
GC2
LCI
I
LC2
o
MST
LST
ABT
AOV
COV
SAl
RDC
LC3
I
EXI
lINT
I
EX2
I I
EX3
o
1
[II
0
0
I
m
Then Part
Used if SC=I
to MPAD Ctls
WAIT
(STEP)
SAVE
SKIP
JUMP
EXEC
CALL
RETN
Do Unconditionally
Do Conditionally if SC
[1]
Ext Op (MDOP/CAJ) Conditional
Do Unconditionally
Do Conditionally if SC
311
0
I
I
I
o
o
I
I
I
I
I
~ Adder X Input
o
0
0
(0)
I
LIT
I
I
0
ZEXT
CTR
o
I
o
o
120
21
~
Al
A2
A3
23
134
24
25
261
Comp
Com!>
Comp
Comp
0
0
1
1
I
o
o
o
o
o
0
o
Adder Y Input
BO-BT-BF-BI-B-OB-TB--O
B--T
B--F
B--I
B-F-*
B-I-*
LIT
ZEXT
CTR
35
o
0
-
I
137
38
o
+
NOR
NRI
Y +
NAN
OAD
XOR
NIM
IMP
EQV
AAD
AND
Y
RIM
OR
Y
Y
Y
AMPCR Input from BSW
No Change
AMPCR
Xy
XY
143
I
Y
Y
Y
Y
Y
Y
Y
Y
I
Y
Y
Y
XvY
X + (X v y)
XYv XY
XY
XvY
XYv XY
X+(XY)
XY
X+Y
XvY
XVY
X+Y+ I
0
361
45! 461 Mem Dev Address Input
0
I
I
-
0
LMAR
MAR
BR2
MAR2
BRI
MARl
o
LCTR
CTR
INC
o
I
~
401
+1
SARInput
No Change
39
No Change
From LIT*
From BSW*
"tlnes Complement
CSAR
SAR
No Change
Complement
From BSW
541
MemDevOphMDOP
A Register Input from BSW
Al
A2
A3
151
52
53
B Register Input Select
0
BC4
BAD
BC8
BBA
B
BEX
BMI
BBE
BBI
No Change
Comp 4 Bit Carries
Adder
Camp 8 Bit Carries
BSW v Adder
BSW
External
MIR
BSW v External
BSWv MIR
Z
AMPCR
*Use Adder Operation with Complement Y
Figure 9-Interpreter microprogramming reference card
No Change
From LIT
From BSW
From BSW
From BSW
From BSW
From BSW
Counter Input
No Shift
Right End Off
Left End Off
Right Circular
44
-
Shift Type Selection for BSW
R
L
C
Z
22
~
Adder Operation
X
X
X
X+
X
X
X
X
X
X
X
X
XX
X
X
Else Part
Used if SC=O
0
0
cnd=:SC
cnd=:SC
Logic Unit Conditional
30
MIR
Logic
FT Condition Value
NOT
29
MIR Input from BSW
No Change
Allow
Inhibit
~.,uccessor
Condi tion Tested
Re suIt is Boolean end
o
-IC
128
Ii!!
Inhibit Carries into Bytes
No Change
MRI
MR2
MWI
MW2
DLI
DL2
DRI
DR2
DUI
DU2
DWI
DW2
716
Spring Joint Computer Conference, 1972
Assumptions
(1)
Sign-magnitude number representation
(2)
Multiplier in A3; multiplicand in B
(3)
Double length product required with resulting
most significant part, with sign, in B and least
significant part in A3
1.
A3 XOR B~ ;if LC1
2.
Borr'" A2; if MST then Set LC1
Comme~t: S~eP.1 resets LC1. Steps 1 and conditional part of 2
check signs; If different, LC 1 is set.
3.
BOOO-+B, LCTR
Comment: Steps 2 and 3 transfer multiplicand (0 sign) to A2
and clear B.
4.
uN" .... LIT; 1.... SAR
Comment: Steps 3 and 4 load the counter with the number
(N = magnitude length) to be used in terminating the multiply
loop and load the shift amount register with 1.
S.
A3 R-.A3; Save
Comment: Begins test at least bit of multiplier and sets up loop.
6.
LOOP: If not LST then BOTTC-.B skip else step
7.
A2 + BOTTC-.B
8.
A3 OR BTOOR~A3, INC; if not COV then jump else step
Comment: 6 through 8 clocks/bit).
inner loop of multiply (average 2.S
9.
If not LC1 then BOTT ....... B; skip else step
10.
B1T~B
Comment: If LC1 = 0, the signs were the same hence force sign bit
of result in B to be a O.
'
Figure lO-Example of microprogram for binary multiply
emulates another computer, the emulation efficiency is
generally very poor since for each machine language
instruction of the emulated machine there corresponds
a sequence of machine instructions to be executed on
the host machine. This relatively inefficient operation
for conventional computers with fixed machine instruc25
tions (called simulation in IB1\1 literature-see Husson
and Tucker17 ) turns out to be significantly more effi-
cient on microprogrammable computers. In a microprogrammed machine, the controls for performing the
fetching and execution of the machine instructions of
the emulated machine consist of a sequence of microinstructions which allows the increased efficiency.
There are a number of attributes of the Interpreter
which make it uniquely appropriate for emulation applications. In addition to the obvious flexibility allowed by
The Interpreter
microprogramming, the following features of the Interpreter contribute significantly to. an effectiv~ emulation capability:
of some machines have a rather elemental capability; here, it is possible to compose microinstructions of relatively great power. A single
micro-nanoinstruction may specify selective
condition testing and setting, conditional or unconditional logic unit operations between
selected registers, optional shifting, literal loading of certain registers, and independently conditional or unconditional memory or device
read-write operations.
4. The zoned B-register selection affords convenient
testing and setting of special bits.
5. Condition setting and testing allows ease of
communication with peripherals and memories.
6. Multiple units for a variety of system functions
and multiprocessing may be interconnected via
1. l\1odularly variable logic unit word length per-
mits configuring the emulator machine for most
effective match with the emulated machine.
2. The barrel switch provides for arbitrary length
shifts in a single clock time, a very effective
facility for instruction "break-apart" and address calculation.
3. Powerful and extremely flexible microinstructions. There is no fixed, limited-size instruction
repertoire; rather, the Interpreter's nanoinstruction provides practically unlimited flexibility in
instruction composition. The microinstructions
000
100
200
300
400
500
600
700
800
900
1000
717
PROGRAM BIMULT;
A3XOR B=:;IFLC1;
BOTT = : A2; IF MST THEN SET LC1;
BOOO = : B, LCTR;
N = : LIT; 1 = : SAR;
A3 R = : A3; SAVE;
LOOP: I F NOT LST THEN BOOT C = : B; SKIP ELSE STEP;
A2 + BOTT C = : B;
A3 OR BTOO R = : A3, INC; IF NOT COV THEN JUMP ELSE STEP;
IF NOT LCl THEN BOTT = : B; SKIP ELSE STEP;
B1TT = : B;
1
3
2
2
3
2
4
5
2
6
2
7
2
8
1
9
3
10
2
NANO ADDRESS=
16
13
NANO ADDR ESS=
9
7
8
NANO ADDR ESS=
16
13
5
SAR= 1
5
NANO ADDR ESS=
12
15
NANO ADDRESS=
4
6
5
NANO ADDRESS=
16
13
5
NANO ADDR ESS=
17
11 16
NANO ADDRESS=
13
6
12
NANO ADDR ESS=
16
5
13
5
0
17
18
10
13
19
21
1
16
22
2
37
LIT
39
40
48
=0
17
18
12
13
10
3
19
4
16
33
22
5
17
18
18
19
22
6
21
26
28
7
16
22
20
21
26
8
22
000000000000
26
29
30
000000000001
35
000000000010
1111
22
1111
26
1111
37
26
00000100000000
1111
36
1111
26
1111
32
1111
29
1111
39
1111
37
000000000011
000000000100
33
32
000000000101
37
33
000000000110
30
33
000000000111
40
000000001000
40
39
Figure ll-Example of microtranslator output
37
39
39
40
36
47
40
718
Spring Joint Computer Conference, 1972
Assumptions:
A1 contains starting address for storing of series
A2 contains the number representing the length
of the series to be computed
1.
Al -.--..MARl
Comment:
2.
BOOO -
3.
BOOl
load starting address of series into address register
.. B, MIR
~,.A3; MW1
Comment:
load initial element of series (0) into A3 and MIR and write it
into starting address. load second element of series (1) into B.
4.
A2 ~ CTR;SAVE
Comment: load counter with length of series; the counter will be incremented
for each generation of an element of the series; COV will signify
completion. The SAVE sets up the loop.
5.
lOOP: If SAl then Al + 1 ~ Al, MARl, INC, Step else Wait
Comment: Set up the next address and increment counter
6.
A3 + B ---- MIR
Comment: Generate new element in series and place in MIR
7.
B ----A3; BMI, MW1; If NOT COV then Jump else Step
Comment: Write new element into next address
Transfer i - 1 element to A3
Transfer i element to B
Test counter overflow for completion (go to LOOP, if not done)
8.
DONE:
Figure 12-Example of microprogram for generation of Fibonacci series
the Switch Interlock to facilitate emulation of a
large range of target machine structures.
These characteristics of the Interpreter that prove so
useful in emulation derive from the basic design concept that the Interpreter was to be both simple enough
and yet powerful enough that one basic element could
be microprogram specialized and modularly expanded
Data
Program in
Machine Language
Figure 13-Basic data processing functions
The Interpreter
719
Op Code 0 address
Op Code 1 address
Directory
Op Code n address
Instruction
Fetch & Decode
~------
-- - -
General routines
used by the op code routines
Address Calculation,
Operand Fetch, and
Resu It Store
Op Code 0
Op Code
Routines
Special routines
corresponding to
each type of machine
instruction op code
1 Routine
Op Code n
Routine
General operating procedure
1.
Instruction fetch - fetches next machine instruction to be interpreted
2.
Instruction decode - separates the op code field in the machine instruction.
3.
Pass control to appropriate op code routine - using the Directory as a pointer.
4.
Execute the specifiedop code routine - using the general routines (esp. addressing) as needed.
5.
Return control to the instruction fetch routine
Figure 14-Emulation-MPM map and operating procedure
to efficiently cover a broad range of applications from
simple controllers to complex processors or computer
systems.
I t is important to realize that the machine being
emulated may be either an existing· or a hypothetical
machine. The basic items necessary to define a machine
and hence to emulate it are:
1. memory structure (registers, stacks, etc.),
2. machine language format (0, 1, 2, 3 address)
including effective operand address calculation,
and
3. operation codes and their functional meaning
(instructions for arithmetic, branching, etc.).
The process of writing an emulation therefore, involves the following analyses and the microprogramming of these basic items:
1. Mapping the registers (stacks, etc.) from the
emulated machine onto the host machine,
2. Analysis of the machine language format and
addressing structure,
3. Analysis of each operation code defined in the
machine language.
All the registers of the emulated machine must be
mapped onto the host machine; that is, each register
must have a corresponding register on the host machine.
The most frequently used registers are mapped onto
720
Spring Joint Computer Conference, 1972
the registers within the Interpreter Logic Unit (e.g.,
registers AI, A2, A3). The remaining registers are
stored either· in the main system memory or in special
high speed registers depending on the desired emulation
speed. The machine language format may be 0, 1, 2, 3
address or variable length for increased code density,
and may involve indexing, indirection, relative addressing, stacks, and complex address conversions.
Figure 14 shows the general microprogram requirements (MPlVI 1Vlap) and operating procedure for the
emulation task.
Direct execution
The term "direct execution" has a variety of meanings resulting from the possible divisions of effort in
the preprocessing and execution phases of the data
processing operation. It may be understood that a
machine "directly executes" a high level language
(HLL) if a program written in that HLL is submitted
to the machine and results occur without regard to how
this has been accomplished. Under this broad definition,
any machine that has a compiler for this HLL would
be considered a "direct executor" of that HLL and this
represents one extreme. The amount of preprocessing
in this case is quite significant since an entire compiler
is required before execution begins.
At the other extreme, practically no preprocessing
occurs and the entire HLL program resides in the system (e.g., memory or disc) as it was written (i.e., oneto-one correspondence with the characters of the input
code). Each character scanned in the input source
string causes an appropriate action. Although this
definition involves no significant preprocessing, it is
probably only of academic interest because of its slow
inefficient operation. It appears that some amount of
preprocessing is desirable and that an optimum degree
Program
inHlL
I
_ _ _ _ ...1
Results
Results
Figure 15-Direct execution of HLL
of preprocessing may be arrived at for each environment and/or application.
Figure 15 shows two approaches for arriving at results from a program written in a HLL. The one path
involves the standard compilation process followed by
an emulation and the other path involves interpretation.
Compilation consists of two basic functions: Analysis
and Synthesis. The Analysis function depends upon the
HLL and includes the scanner (of the input source
string of characters) and the syntax recognizer which
determines when a syntactic element of the HLL has
been obtained. The output of this analysis is a program
in intermediate language form which is usually in Polish
postfix notion with tables indicating an internal representation of each element of the input string. This
intermediate program has basically a one-to-one correspondence to the in put HLL program.
The Synthesis function depends upon the machine
that performs the execution phase and consists primarily of code generation. The input is the intermediate
language program and the output is a program in the
machine language of the execution machine. The code
generation is generally a one-to-many mapping from
intermediate to machine language.
The term Interpretation generally involves t\VO functions~Analysis and Execution; that is, translation of a
HLL program into an intermediate (or internal) form
and execution of the program directly in this intermediate form without a translation to a machine language. The Analysis is basically the same as that described above for the compilation process. The meaning
of the term Interpretation will be limited in the following discussion to the second part; that is, the execution
of the program in its intermediate form.
An Interpretation is often slower in execution time
than the equivalent execution of a machine language
program. This might not always be the case in a microprogrammed environment, when the control structure
of the HLL is significantly different from that of the
host machine language, or when a significant portion
of the execution time is spent in standard system routines. Interpretation does provide a better facility for
development of new programs through built-in functions (e.g., debugging tools).
The functions involved \vith "direct execution"Analysis, Synthesis, Interpretation-may all be more
effectively performed in a microprogrammed environment. For each function, a set of microprograms may
be developed to provide a significant increase in operating speed (see Tucker and Flynn26).
A combination of· approaches is also easily implemented on a microprogrammed machine. The Interpretation approach may be used during the program
development phase and depending upon its operating
The Interpreter
performance, it may be used for the repeated "production" phase. The compilation approach may be desired
for the "production" phase if the execution of a machine
language program is of higher performance than the
Interpretation approach. The microprogrammed machine provides great versatility here also. In addition
to providing a highly efficient compilation process, the
machine code output may be modified until an "optimum" machine is defined for the application and/or
high level language. This machine would then be emulated on the same Interpreter as described earlier
("Emulation") .
The designing of conventional machines to match a
particular high level language has been demonstrated
to provide high performance. Two examples of this are
the Burroughs B 5500 for the ALGOL language and
the B 3500 for the COBOL language. A number of the
HLL features are reflected in these architectures; for
examples: The B 5500 run time stack in which the
calling environment resides matches the ALGOL block
structure and recursive procedures.
The B 5500 code stream is a reverse Polish notation
corresponding to order of expression execution with
intermixed operators, literals, operand calls, and descriptor calls. This not only matches the ALGOL
operator precedence but also results in increased code
density.
The B 5500 operand fetch is driven by data descriptor
so that uniform codes can be used for call by name,
value, and reference parameters.
The B 5500 performs arithmetic on real numbers,
treating integers as zero exponent reals and Booleans as
a real 0 or 1 thus providing uniform data represeIltation.
The B 5500 stores arrays as a hierarchy of vectors
that contain bases of the next lower level of arrays thus
providing for the ALGOL N-dimensional dynamic
arrays.
TheB 3500 operators work on packed, unpacked, and
mixed stored forms of decimal or character data thereby
providing convenient management of COBOL variable
length operands. The COBOL editing and moving
operations are provided for by the primitive B 3500
instructions for character string editing and moving.
The ability to structure a machine for a particular
language is enhanced through microprogramming;
hence, these same capabilities may be more easily implemented than on the conventional machine.
Tuning the machine for the problem
In the past, conventional machines with fixed instruction sets were used with a force fit approach to solve a
given problem. Furthermore, the language and com-
721
puters (including instruction sets) were developed independently and were based on different requirements
and constraints. The language design depended on the
user and application and the computer hardware depended primarily on cost and general performance relative to all potential problems. At the juncture, a
sometimes complex preprocessor (compiler) was required to make compatible the two designs.
J\1:icroprogrammed machines offer the unique opportunity to modify the system architecture to optimally
solve a given problem. Languages may still be designed
with the application and user in mind but the computer
now may also be designed to be compatible with the
application and the language. As a result, (1) the language is ideal for the user and application; (2) the preprocessing is significantly simpler because both· ends
(i.e., language and machine) are flexible, and (3) the
machine provides an optimum solution to the problem
by matching the language and application requirements.
Among the many advantages to this tuning to the
problem approach in addition to this increased system
performance is the fast turn around time from problem
statement to problem solution. lVlachine hardware does
not have to be built for each new application since the
hardware is off-the-shelf and only the microprograms
must be developed. This also allows a delayed binding
of the required system specification until the problem
is clearly defined. As a matter of fact, no permanent
binding is ever required since the microprograms may
be modified (expanded/contracted) at any time to
meet new system needs.
Two basic methods for initiating the implementation
of this tuning to the problem approach are: (1) design
on paper the ideal machine and/or language for the
particular task and then emulate that machine and/or
directly execute the language and (2) use an existing
machine and/or language as the starting point and
emulate the machine or directly execute the language.
In either case, the process of tuning is generally iterative
in nature. The application programs may be executed
using monitoring techniques to detect and gather a
variety of statistics about the program. This monitoring is very easily implemented on a microprogrammed
machine and may be used for examples (1) to analyze
the operation code usage and (2) to determine the slow
areas within the program where most of the time of
execution is spent. This information may then be used
to modify the instruction set by adding or deleting
operation codes to the original set. In addition to the
instruction sets that may be modified to optimize performance, the data may also be specified as to data
types, word lengths, etc., depending on the data structures and accuracies required. The machine structure
may also be modified (e.g., adding stacks or general
722
Spring Joint Computer Conference, 1972
Machine
by a factor of 10 to 20. The estimated speed improvements were stated by Tucker and Flynn26 in their comparison of the IBM360/50 and their suggested microprogrammed machine. The examples that they chose
for demonstrating the increase in performance were:
array element address calculation,- Fibonacci series
generation, and a table search algorithm. Interpreter
analyses of these and other examples tend to verify
these order of magnitude performance improvements.
c
Description
Program in
r-~~~_Ma_mi_ne_La_n~__
-I____
Program
in HLL
MONITORING
~
EXECUTION
Results
Results
Figure 16-Tuning the machine for the problem
registers, indexing) and the machine language instruction format altered.
Figure 16 indicates a method used for tuning to the
problem. The language description is entered into the
Analysis Builder and the machine description is entered
into the Synthesis Builder. The function of the Analysis
and Synthesis Builders is to develop the internal tables
(syntax recognition, etc.), machine code segments, etc.,
for use by the Analysis and Synthesis sections. This
building function is presently performed manually but
may eventually be performed with computer assistance.
T he functions of the Analysis, Synthesis, Interpretation
a1 Ld Execution sections are basically the same as previoHsly described ("Direct Execution"). The prime enhancement here is the Monitoring of the Execution
function and the feed-back of information for the language and machine descriptions. This allows iteration
on the language and machine descriptions until an
optimum solution is attained. The result is a language
and machine ideal to solve the given problem. Any
number of different machines may be emulated by
simply modifying the microprogram set.
As an example of this process, let us assume that an
emulation of some existing or hypothetical machine
(simple or complex) exists. The application program
may be run and statistics gathered (by monitoring)
concerning this program. The monitoring for dynamic
operation code usage, for example, requires only about
10 lines of microcode. The gathered statistics can indicate the execution areas where most of the processing
time is spent; that is, the section(s) of machine language
instructions most used. The function of this section(s)
of machine instructions may then be specified, a single
new machine instruction may be defined to perform
this same function, and microcode may be developed
to emulate this new machine instruction. This process
of enhancing the original machine language allows a reduction in main memory requirements for the application program in addition to increasing the performance
REFERENCES
1 M V WILKES
The best way to design an automatic calculation machine
Manchester University Computer Inaugural Conference
Proceeding 1951 p 16
2 W L VAN DER POEL
Micro-programming and trickology
John Wiley and Sons Inc 1962 Digital Information
Processors
3 H T GLANTZ
A note on microprogramming
Journal ACM 3 Vol No 2 1956 P 77
4 R J MERCER
Micro-programming
Journal ACM 4 Vol No 2 1957p 157
5 J V BLANKENBAKER
Logically microprogrammed comp'l.lters
IRI Prof Group on Elec Com December 1958 Vol EC-7
No 2 p 103-109
6 G P DINEEN I L LEBOW et al
The logical des1:gn of CG24
Proc EJCC December 1958 p 91-94
7 T W KAMPE
The design of a general-purpose microprogram-controlled
computer with elementary structure
IRE Trans June 1960 Vol EC-9 No 2 p 208-213
8 L BECK F KEELER
The C-8401 data processor
February 1964 Datamation p 33-35
9 0 BOUTWELL JR
The P B 440 computer
February 1964 Datamation p 30-32
10 L D AMDAHL
Microprogramming and stored logic
February 1964 Datamation p 24-26
11 R H HILL
Stored logic programming and applications
February 1964 Datamation p 36-39
12 W C McGEE
The TRW-133 computer
February 1964 Datamation p 27-29
13 W Y STEVENS
The structure of SYSTEM/360 Part II-System
implementation
IBM Systems Journal Vol 3 No 2 1964 p 136-143
14 A J MELBOURNE J M PUGMIRE et al
A small computer for the direct processing of Fortran
statements
Computer Journ England April 1965 Vol 8 No 1 p 24-27
15 W C McGEE H E PETERSON
The Interpreter
16
17
18
19
20
Microprogram control for the experimental sciences
Proc AFIPS 1965 FJCC Vol 27 pp 77-91
J GREEN
Microprogramming emulators and programming languages
Comm of ACM March 1966 Vol 9 No 3 pp 230-232
S G TUCKER
Emulation of large systems
Communications of the ACM December 1965 Vol 8 No 12
pp 753-761
A OPLER
Fourth-generation software, the realignment
Datamation January 1967 Vol 13 No 1 pp 22-24
I T HAWRYSZKIEWYCZ
Microprogrammed control in problem-oriented languages
IEEE Transactions on Electronic Computers October 1967
Vol EC-16 No 5 pp 652-658
G A ROSE
I ntegraphic, a microprogrammed graphical-interface computer
IEEE Transactions December 1967 Vol EC-16 No 6
pp 776-784
723
21 H W LAWSON
Programming language-oriented instruction streams
IEEE Transactions 1968 C-17 p 476
22 M V WILKES
The growth of interest in microprogramming-A literature
survey
Comp Surveys Vol 1 No 3 Sept 1969 pp 139-145
23 R F ROSIN
Contemporary concepts of microprogramming and emulation
Comp Surveys Vol 1 No 4 Dec 1969 pp 197-212
24 L L RAKOCZI
The computer-sithin-a-computer: A fourth generation concept
Computer Group News Vol 2 No 8,March 1969 pp 14-20
25 S HUSSON
Microprogramming: Principles and practices
Prentice Hall Englewood Cliffs NJ 1970
26 A B TUCKER M J FLYNN
Dynamic microprogramming: Processor organization and
programming
CACM April 1971 Vol 14 No 4 pp 240-250
Modeling, measurement and computer power*
by G. ESTRIN, R. R. MUNTZ and R. C. UZGALIS
University of California
Los Angeles, California
INTRODUCTION
user programs and data; and users and user protocol
for entry and exit.
There is no accepted measure for global power or
performance of computer systems. There is even no
accepted measure for computer cost. Only when a
SUbsystem or subfunction is isolated does it become
possible to determine key parameters. However, it is
useful to hypothesize such measures and consider influences on them.
Let us, therefore, define a conceptual measure which
we call computer system power, P, as a multivariate
polynomial function whose coefficients are significance
weights. We would, of course, like to have a set of
orthogonal functions whose independent variables
correspond to measurable parameters but that state
of .happiness is not· apparently within reach. In an
attempt to exemplify our philosophy, the authors
discuss a set of variables which should influence P
keeping in mind that derivation of a figure of merit
would require dividing P by some measure of cost.
We intuitively expect computer system power to
increase if the:
Since the early 1960s the literature9 •32 reveals
increasing concern with effectiveness of information
processing systems and our ability to predict influences
of system parameters. A recent survey paper38 discusses
methods of performance evaluation related to three
practical goals: selection of the best among several
existing systems; design of a not-yet existing system;
and analysis of an existing accessible system. The
classification of goals is useful, but we can point to
neither the models nor the measures nor the measurement tools to allow reliable judgments with respect to
those three important goals at this time.
We choose to discuss three issues which do not fall
cleanly into Lucas' categories but which are certain
to influence our ability to evaluate computer systems
in the 1970s. The three issues are: effectiveness of
models of computer systems; requirements to be met
by measurement experiments; and application of
modeling and measurement to the user interface with
computer systems.
The first section provides a context for the other
sections by reviewing parameters which make computing systems more or less powerful. The second
section gives a critique of the state of modeling. The
third section characterizes measurement tools. The
fourth section discusses the role of nleasurement at
the user interface.
• execution time of any CPU instruction is decreased
• access time of any memory subsystem is decreased
• transfer rate to or from any memory subsystem is
increased
• transmission rate of any buss structure is increased
• transfer rate to and from any input or output device is increased
• delay in resource availability is decreased
• error recovery time is decreased
• number of useful public programs is increased
• performance of any public program is increased
• access time to any public data base is decreased
• arrival, execution, and departure rates of user
programs are increased
• execution time or resource requirement of any user
program is decreased
COMPUTER POWER.
We consider a computer system to be composed of:
a centralized hardware configuration; a set of terminals
for entry and exit of user programs and data; an
operating system; public programs and data bases;
* This research was supported by the National Science Foundation, Grant No. GJ 809.
725
726
Spring Joint Computer Conference, 1972
• number of effective users increases
• amount of protocol for any user decreases
In a deeper, even more qualitative sense, we expect
a computer system to be more powerful if the following
conditions hold:
• system manager has a model permitting adaptation
to changing load
• errors and system imbalances are reported to
maintainers and developers
• program documentation and measurements permit
modification with few side effects
• average number of user runs before correct execution is decreased
• the quality of any user program increases in the
sense that there is more effective use of a source
language on a given computer system.
Although the above observations are useful in
stating expected events of concern they ignore interactions between such events and give no indication
of weighted importance of the individual events. We
further characterize our systems by the following
simple remarks.
If the time required for every physical transition to
reach its new stable state were halved, we would expect
throughput of the system to double. If only some of
the events were reduced in transition time, we could
no longer guarantee that there would be a reduction
in computation time because the scheduling of events
is a function of starting and stopping times of concurrent processes. Anti-intuitive anomalies23 ,3 are
disturbing but do not keep us from conjecturing that
they occur only infrequently. If we' neglect anomalies,
then we cannot expect change in execution time of
anyone instruction or anyone routine or anyone
compiler to produce a decimal order of magnitude
change in a sensibly weighted function of the above
parameters. Given reasonable measurement tools and
design of measurement experiments .we conjecture
that somewhere between 10 percent and 50 percent
improvement in performance can be accomplished for
most systems by changes in assignment and sequencing
of resources. Although these percentages do not seem
dramatic in their impact, the absolute number of
dollars or number of computer hours which would
become available is far from negligible.
In contrast with the heuristic probing and tuning
of a given system, much greater impact is possible
at the user interface with a computer system and by
advances in models, particularly validated models of
our computer systems. For example, we would guess
that there are more than 10 attempts to run a program
during its development before it runs once "correctly."
For complex programs the ratio of number-of-correctruns to number-of-runs can approach -zero. Hence, if
the user interface can be altered so as to increase the
probability of a correct run, large benefits may result.
The effect of model development is a more sophisticated and qualitative issue. It is self evident that to
the extent that we can predict behavior of even a
subsystem through modeling, we can hope to isolate
important parameters and the way they affect p erformance. In fact, only through modeling efforts can
we generalize experimental results at one cente r to
apply to many others. Furthermore, it has been
recognized that simulation is the most widely used
tool in evaluation of systems. If simulation dep ends
upon precise imitation of a computer system, its
development cost is generally prohibitive and it is
fraught will all the unreliability associated with oneshot development. Effective simulation depends upon
validated approximate models of systems and of user
programs. Creation of such strong models is the most
difficult of our tasks. However, the very process of
validating or invalidating simplifying assumptions
used in models can lead to new algorithms and improved models. Margolin, Parmelee and Schatzoff39
very competently demonstrate this effect in their
recent study of free-storage management algorithms.
In this section we have taken cognizance of the fact
that there is no simple (or even complex) formula for
computer performance. The reader's attention has
been focussed on the last five in the list of factors
affecting computer performance because they offer
so much more return. The following sections review
work in analytic modeling, measurement, and the user
interface.
CRITIQUE OF ANALYTIC MODELING
Any system design, any measurement project or
any resource allocation strategy is based on some conception of the environment in which it operates. That
conception is a model. It is beneficial to have such
models explicitly stated so that they can be explored,
tested, criticizeq and revised. Even better, though not
often achieved to the extent desired, is a formal analysis of the models.
Models and methods of analysis vary greatly. Our
concern here is with probabalistic models of systems
and processes and also with discrete graph models of
programs. The goals of these analyses are both insight
and quantitative results to influence the design of
Modeling, Measurement and Computer Power
systems, resource allocation strategies and possibly
the design of languages.
While most will argue that the goals of such analyses
are inherently worthwhile and must be pursued, there
is widespread dissatisfaction with the current state of
the field. Basically, there are three major areas of dissatisfaction. First, the models are generally oversimplified in order to make them mathematically
tractable. This obviously makes the results questionable
and brings us to the second major failing which is that
analytic results/are often not validated by measurement
or simulation. Moreover, in cases where system evaluation studies are carried out, the existing models do not
seem powerful enough to provide a uniform basis for
measurements. The third major criticism is that most
of the literature on analytic modeling is a collection
of analyses of specialized models. This points up the
lack of very general powerful results which would
allow analysis to become an engineering tool. As it is
now, each new situation almost always requires a
separate analysis by an expert.
While the above are substantial criticisms, this is
not to say that analysis has not had its impact. We
can cite, for example, the working set model of program
behavior,12 the work on stack algorithms,41 studies of
time-sharing and multiprogramming system resource
allocation and analyses of I/O scheduling,42 ,49
the work on data transmission systems and on
networks 11 , 35,19 and the work on graph models of
programs.40.26.27.33.14.24.7,10,22
Promising areas of research
Multiple resource Inodels
Much analytic work has dealt with single resource
models. The reason for this is clearly that most of the
analytic tools which are available apply to single resource environments. The computer system analyst
is typically not a mathematician developing new tools
but is generally engaged in applying existing tools.
Nevertheless, computer systems are multiple resource
systems and we must learn to analyze such systems.
Some recent studies of multiple resource models of
computer systems have been made using results by
Gordon and Newell. 21 The general model considered
by Gordon and Newell is one in which customers (or
jobs) require only one resource at a time, but move
from one resource to another. An example is illustrated
in Figure 1 for three resources.
The nodes in this figure represent resources and the
arcs represent possible transitions from one resource
to another. When a customer has finished at resource i
727
Figure I-Example network of queues model
he moves to (requires) resource j next with probability P ij. The arcs are labeled with these probabilities.
The service time at each resource is assumed to be
exponentially distributed. This is a closed system
meaning that the number of customers in the system
remains fixed. Gordon and Newell have found expressions for the equilibrium distribution of customers
in service or queued at each resource. This allows one,
for example, to calculate the utilization of the various
resources.
Moore43 and Buzen 8 have applied this model to
multiprogramming systems. Moore measured the MTS
system to obtain the transition probabilities and mean
service times of the resources and then used the model
to estimate system parameters such as resource utilizations. The relatively close agreement to measured
system parameters leads one to believe that the model
can be used to predict the effect of some changes in
system configuration. In using the model in this way,
one must be careful that the proposed changes do not
significantly affect the basic behavior of the customers.
Buzen used the same model to gain insight into resource allocation in multiple resource models of computer systems. His studies include the investigation of
buffering and the effects of paging algorithms. Both
Moore and Buzen have used the model to try to give
a meaningful formal definition to the term "bottleneck." It is of interest that they arrive at different
definitions of a bottleneck. The reader is referred to
the references for details.
728
Spring Joint Computer Conference, 1972
While the studies mentioned above are clearly advances in the study of computer system models there
are numerous open questions. For example, the model
does not allow the representation of the simultaneous
use of several resources such as memory and CPU.
Also there is no means for representing the synchronization of events such as a process doing buffered I/O.
Another limitation is that the customers in the system
are assumed to have the same statistical behiavor, i.e.,
the transition probabilities and service time distribution are the same for all customers.
Bounds and approximations
Every evaluation technique makes use of approximations. These approximations may arise, for example:
in estimating the system parameters, user and program
behavior; or in simplifying the model of the system
itself. There is clearly a tradeoff between types of
approximations. By simplifying a model one might be
able to handle more general types of user and program
behavior. Much of the analytic work has been concerned with exact mathematical solutions to models
which are themselves gross approximations.
An area which is beginning to be explored is that of
approximate solutions to more general models. ~or
example, Gaver has used the diffusion ap~roximat~on
for the analysis of heavily loaded resources III queueIng
studies. 20 The basic technique is to consider that the
work arrival process is not the arrival of discrete customers requiring service but rather a work arrival flow.
This work arrival flow is a continuous process with the
same mean and variance as the original process. Another
example of the use of approximations is the work by
Kimbleton and Moore on the analysis of systems with
a limiting resource. 34
I t is clear that the use of any approximation requires
validation of the results. This may take the form of
comparing results with measurements of an actual
system, simulation, or obtaining bo~nds. on th~ error
in results. Bounds may also be applIed III a dIfferent
manner. Much has been written on the analysis of
time-sharing scheduling algorithms and their effects
on response times. Kleinrock, Muntz and Hsu 36 have
reported on results which in effect demonstrate the
bounds on response time characteristics for any CPU
scheduling algorithm which does not make use of a
priori knowledge of customers service times. ~h~ importance of the bounds is that one can see the hffilts of
the variation in response characteristics that are
possible by varying the scheduling algorithm and the
extent to which these limits have been approached.
Program behavior
A major problem that must be dealt with in any
evaluation effort concerned with computer systems is
program behavior. Even when using approaches such
as benchmarking or trace-driven modeling there is the
problem of selection of programs which are in some
sense representative of the total population of programs
that will be run on the system.
Studies of memory management in particular have
had to explicitly include models of program behavior.
The early work in this area2 ,12 stressed very general
but powerful aspects of program behavior such as
"locality" and "working set." More recent work deals
with more explicit models of the generation of reference
strings which assume more about program behavior
· 13
but correspondingly allow for more detal·1ed anaIYSIS.
It is hoped that these models will permit more detailed
studies of multiprogramming and procedure sharing.
It is interesting to note that the bulk of this work
has been directed toward finding models which can
represent the universe of possible programs. More
particular:y, the goals of this research have be.en to
isolate parameters characterizing program behaVIOr to
which memory management is sensitive and to compare
the effectiveness of various memory management
strategies. This approach is in line with a common
theme which runs through most of the work on resource
allocation strategies in computer systems. That is, we
see most allocation strategies attempting to work well
over the total population of programs possibly utilizing
measurements of recent past history of the process to
predict the near future. Outside of work arising from
graph models of parallel programs5 ,6,51 very little has
been done to utilize a priori information about a process.
Many systems do make a priori distinctions between
batch and interactive processes. It seems reasonable
though that much more information may be available
which would be useful in allocating resources. For
example, it has been suggested that the time-slice and
paging algorithm parameters be tailored to the process. 46 Use of a priori information assumes that the
process is available for analysis prior to execution. This
is a valid assumption for production jobs, system
processes,and to some degree for all jobs at compile
time. Since these processes consume a significant portion of the system resources, gains in efficiency in
managing such processes might result in major gains
in total efficiency. There are many open problems
associated with this approach:
1. Is there a conflict with a program design goal of
program modularity? How is information about
separately compiled procedures to be combined?
Modeling, Measurement and Computer Power
2. Should processes be permitted to advise the
system as to their resource needs? How does the
system protect itself against false information?
3. How to manage resources effectively for processes which provide a priori information, and
also for processes without associated a priori
information?
4. What kind of a priori information is actually
useful to management of a system: how costly
is it to obtain and utilize effectively?
5. How predictable are the resource requirements
of processes?
While this approach has received only some slight
mention in the literature, it appears to be a fertile
area for research.
Graph models of programs provide an abstraction
of program structure governing flow of control and
demand for resources. 51,10,18,22 They permit a representation fitting somewhere between the full detail of
actual programs and parametric or stochastic representations of them. Most work using graph models
has been concerned with concurrent processing. However, the graph model analyses explicitly reveal sets of
independent tasks which become candidates for alternate sequencing in sequential systems.
Ideally, we search for models of systems and program
behavior which provide principles guiding synthesis of
configurations along with well founded resource management strategies. Measurement must validate effectiveness of such strategies. The diversity of computations
further demands that measured parameters be provided to operating systems and users in order to permit
adaptation to dynamic variations in system behavior
and to unavoidable anomalies in systems and languages.
Studies during the latter half of the '60s showed how
little attention had been given to measurability in
the man-made universe of computer systems. The
next section characterizes some of the problems in
measurement.
MEASUREMENT OF INFORMATION
PROCESSING SYSTEMS
Tools for measurement of computer systems must
satisfy all of the following requirements: detection of
prescribed events; recording of detected events·
.
'
retrIeval of accumulated records; data reduction; and
display.
We comment on each in turn.
729
Detection
We start by rejecting the absurdity of observing all
of the states of a system under observation since it
would imply detecting the state of every input, every
memory element and every output every time there
was a change, along with the time at which the change
occurred. Hence, any set of measurement tools must
include means of selecting a subset of system states.
Hardware measurement tools provide a prescribed
number of sensing probes which may be physically
placed on selected register or buss points in a machine
under observation. Measurement system registers
along with programmed comparators and basic logical
operations permit further filtering by allowing detection of a subset of the events sensed by the probes.
Even with such filtering the rate of change of detected
states may be excessive. If the response time of hardware measurement elements is insufficient basic
. .
'
CIrCUIt changes would be required to make the measurement feasible. If bandwidth is insufficient, it is sometimes possible to introduce a sampling signal and
thereby further reduce the number of detected events.
In the absence of interaction with software monitor programs, a hardware monitor is clearly limited in its utility.
To be convinced of this, one need only consider the
kind of program status information change which is
observable by probes only when it appears in the form
of an operand during the course of computation. Hardware detection can have the virtue of introducing no
artifact into the measured system and of being able to
detect events whose states are not accessible to measurement programs. Sampled detection may be made
more effective by allowing interference with the observed process. If a sampling signal enforces a proper
interruption, observed data may be sequentially sensed
by detection circuits. The recently reported "Neurotron"
monitorl is the most interesting implemented hardware
monitor, and its design shows the foresight of enabling
interaction with software monitor programs.
Software measurement tools consist of programs
which detect selected events by virtue of their insertion
at state-change points in the sequential computational
process. 17 , 47,31 This detection process introduces artifact in execution time, in space required for measurement program storage, and sometimes (e.g., synchronization with asynchronous cyclic processes) in qualitative side effects on existing computational processes.
In a sampling mode, measurement programs can have
their in-line artifact reduced by disturbing the flow
o! computation only at a sampling time. Ata sampling
tIme, measurement programs may be brought in to
check as large a set of memory states as is needed and
730
Spring Joint Computer Conference, 1972
then control is returned to the observed system. In
the absence of hardware support, a software monitor
is limited to observation of those system states which
have affected memory contents. In one case, careful
analysis of measurement of PL/I functions of an IBM
360/915 0 revealed anomalies in recorded system states
which can best be characterized as artifact introduced
by OS/360 when it inserts code associated with I/O
interrupts into the code being measured.
It has become clear that we are not faced with mutually exclusive alternatives of hardware detection
tools or software detection tools. Rather how much of
each; how they are integrated; and how they are made
available to experimenters. A paper by Nemeth and
Rovner45 presents a pleasing example of the power of
combined hardware and software in the hands of a
user. They point out that facilities introduced for hardware debugging are often the kind useful in later program
measurements.
Recording
Data Reduction
The amount and kind of data reduction is determined
by the goal of the measurement experiment and limitations of measurement tool capabilities in detection,
recording and preparation for retrieval. For example,
assume that we want to obtain a history of utilization
of routines in order to decide which should be kept in
primary storage and which should be kept in backup
storage. Assume, further, that every time a routine is
called: the name of the called routine, the time of day,
and the name of the user is recorded. It would not be
very meaningful to generate only a history showing the
times at which each routine in the system was used by
each user. Data reduction would be required to determine, for example, the total number of such uses, an
ordering of routines by number of uses, a determination of the number of routines involved in, say 50
percent, of the uses and their names, etc.
Display
If an event of interest has been detected, its occurrence must affect memory contents. Such action
may be as simple as incrementing a counter or as complex as storing a lot of state information for later
analysis. In the case of non disturbing hardware measurements, external storage must be provided and the
transfer rate must be able to keep up with the rate of
change-of-state information observed by a set of probes
and associated circuits. In the case of software measurements, sufficient memory space must either be provided to record all relevant state information, or else
preprocessing reduction programs must be called in
to reduce storage requirements.
The goal of the data reduction process is defined by
the specified form of display or feedback to the experimenter. If measurement is being made for feedback
to an operating system for use in resource allocation,
parameter values must be delivered to memory cells to
be accessed by the operating system. If measurement
is made for accounting purposes or, more generally, to
provide the user with feedback about his quality of
use and system response, results should be merged into
user and system manager files. If measurement is made
for operator control and management, simple alphanumeric displays are common. For experimental analysis of system behavior, CRT displays, graphs and
computer printout are generally required.
Retrieval
M easurement Methodology
In the construction of any large system, both a data
gathering and retrieval system must be incorporated
into the basic design. Failure to do so will limit the
amount of instrumentation available later when efficiency questions arise. For example, in a large programming system which has transient program segments, data gathering is easily inserted into any
program segment; however, unless a standard data
storing program is available, the data gathered cannot
be easily retrieved. The IBM PL/I F -level compiler
is an example of a programming system broken into
transient program segments. It fails to have a data
storing program with adequate bandwidth to support
'
meaningful measurement activity.
The complexity of computer systems dictates special
care in the planning of measurement experiments. If
the results of experiments are not reproducible, they
are of little value. If any assumptions made are not
recorded and validated, the results cannot be generalized and applied at another time or place. A large body
of statistical theory is available providing methods for
abstracting properties out of individual data points,
but applicability must be carefully checked. We have
little hope of adhering to principles if we do not have a
measurement language to prescribe measurement experiments as sequences of commented operations which
are appropriately integrated with observed data. The
latter step needs wait upon creative development of
Modeling, Measurement and Computer Power
measurement tools and their test in meaningful experiments. Measurement capability must be explicitly
included during periods of system design and must be
available for inclusion in user program design. Digital
computer systems and programs are properly characterized as complexes of very elementary functions.
Full systems or programs, therefore, generally require
partition in order to manage the synthesis process.
Each partition introduces possible measures of validity
of output, of performance and of cost. Means for measurement should be checked at that point in design and
a value judgment made if excessive artifact would be
introduced by the measurement process.
If a system contains the structure and primitive
operations satisfying the five requirements discussed
in this section, it carries the tools for adaptability. We
conjecture that much more than the 10 percent to 50
percent improvement alluded to in the Introduction
becomes attainable-particularly when measurement
tools can influence user behavior.
COMPUTER POWER AND USER INTERFACE
In the seventies some stronger effort must be directed
toward increasing computer power by a reduction of
the complexity of the user interface.
Operating systems and Higher Level Languages are
tools designed to give the user control of the portion of
a computer system he needs. With the exception of
work done at SDC,28,29 little reported effort has been
devoted to the human engineering aspects of these
tools. During the last decade, while hardware made a
dramatic increase in power, the management tasks
required of the operating system increased from trivial
to highly complex. At the same time, the users were
required to supply (in unnatural form like JCL) more
of the parameters which would allow effective management decisions to be made by the operating system.
These user-su pplied parameters have increased the
burden of complexity at the user interface-and reduced the amount of useful work a user can accomp:ish
in a given period of time.
For example, much of the attraction of APL/360
is its simplification of the operating system interface
along with the addition of immediate execution of its
concise powerful primitives. A batch oriented
FORTRAN user perceives this as a tremendous increase in his computer power. A more sophisticated
user might see APL as a powerful desk calculator which
provides immediate access to functions similar to
functions he already commands, less accessibly, in
other languages.
731
Another user interface problem exists at the level
of higher level languages. As more advanced hardware
becomes available to the user, he seeks to solve more
complex problems. When a problem grows beyond a
manageable point, the user segments the problem into
pieces plus associated linkages. In doing so, however,
he introduces a new set of communication problems;
a change in one program which affects an interface can
now wreak havoc in another "completed" portion of the
problem solution. Higher level languages have been lax
in the types of program interconnections (and interactions) allowed.
An example of the problems of creating a large programming system are reported by Belady an d Lehman
using data from the development of OS/360. 4 While
this study concerned programs written in assembly
language for the IBM 360, the properties which produce
the error rates and modification ratios reported in
their paper are characteristics of all large programming
systems today.
Several techniques for im proving the probabilities
that a program can be made error free are available in
the literature. One of the earliest is Dijkstra's "Notes
on Structured Programming, "16 and also "THE Programming System."15 His system breaks the problem
into shells of "pearls" or "primitive" operations. Each
shell is built using the "primitives" of the next lower
level. This system attempts to minimize interactions,
forces the programmer to produce generalized functions which can be tested, and allows easy instrumentation because of the segregation of functions.
Some disadvantages of such a hierarchical scheme
make its practical application difficult. Such a scheme
increases initial development time because it forces
developers to completely understand the structure of
the system being built and to predefine the proper
function for each hierarchy. Transitions between levels
may be costly. Functions at the lowest level are the
most general and, therefore, the most frequently used.
Small inefficiencies in these functions, or in the method
of traversing levels of the structural hierarchy, magnify
costs dramatically and force the user away from centralized functions. This defeats the original purpose of
the organization.
Another disadvantage of a hierarchical scheme is
that while instrumentation of the system is easy, interpretation of the measurements is generally not.
Measurement results could change drastically if the
organization of the program were modified. Therefore,
it is hard to tell how much of what goes on is due to
the structural hierarchy and how much is due to the
intrinsic properties of the program. Such knowledge
points a way toward improvement.
732
Spring Joint Computer Conference, 1972
NUMBER OF
ERROR
OCCURRENCES
ERROR TYPE*
ERROR DESCRIPTION
263
IEM0227
87
IEM0182
74
IEM0725
63
IEM0152
46
IEM1790
39
IEM0185
27
IEM0677
27
IEM0109
25
IEMOO96
23
IEM0673
NO FILE/STRING SPECIFIED. SYSIN/SYSPRINT HAS
BEEN ASSUMED.
TEXT BEGINNING yyyy SKIPPED IN OR FOLLOWING
STMT NUMBER.
STATEMENT NUMBER xxxx HAS BEEN DELETED DUE
TO A SEVERE ERROR NOTED ELSEWHERE.
TEXT BEGINNING yyyy IN STATElVENT NUMBER xxxx
HAS BEEN DELETED.
DATA CONVERSION WILL BE DONE BY SUBROUTINE
CALLS.
OPTION IN GET /PUT IS INVALID AND HAS BEEN
DELETED.
ILLEGAL PARENTHESIZED LIST IN STATEMENT NUMBER xxxx FOLLOWS AN IDENTIFIER WHICH IS NOT A
FUNCTION OR ARRAY.
TEXT BEGINNING yyyy IN OR FOLLOWING STATEMENT
NUMBER xxxx HAS BEEN DELETED.
SEMICOLON NOT FOUND WHEN EXPECTED IN STATEMENT xxxx. ONE HAS BEEN INSERTED.
INVALID USE OF FUNCTION NAME ON LEFT HAND
SIDE OF EQUAL SYMBOL OR IN REPLY, KEYTO OR
STRING OPTION.
14
12
IHE804
IHE320
IHE140
IHE604
COMPILE-TIME
EXECUTION-TIME
ADDRESSING INTERRUPT.
FIXED OVERFLOW.
8
FILE name-END OF FILE ENCOUNTERED.
7
ERROR IN CONVERSION FROM CHARACTER STRING TO
ARITHMETIC.
* IBM, PL/I(F) Programmers' Guide (Appendix K), GC28-6594, January 1971.
Figure 2a-Most frequent PL/I errors
EACH SPACE = 10)000 UNITS.
5 HAVE BEEN DELETED.
GRAPH CF VARIABLE 10
SAMPLES CF LESS THAN
IEM02271
IEM17901
IHE08041
IHE0320 I
IEM05261
*
*
IEMC1821
IEMClOO I
H:MC7251
IEMOI851
IEMO 1521
IEMC0311
IEM2e671
'"
IEfoIC6771
IEMC1091
IfMCC9~1
'"
*
'"
*
*
IEMtCl961
IEMC6731
'"
*
*
IHEOI4CI
IHE06041
IEM18481
IEM( C99 I
lEM( 080 I
*
*
'"
*
*
*
**
*
*
*
1----·----1----·----1----·----\----·----1----·----1----.----1----.----1----.----1----.----1---_1 ____ 1____ •
0.10
0.20
0.30
0.40
0.50
0.60
0.10
0.80
0.91
1.00
u.oo
Figure 2b-Average persistence sorted by average persistence
Modeling, Measurement and Computer Power
733
NUMBER OF
ERROR
OCCURRENCES
ERROR TYPE*
ERROR DESCRIPT:ON
143
131
89
83
76
SY16
SYE5
CGOC
SYOB
SM4E
55
53
48
46
40
SY3A
SY04
SY06
SY09
SM50
IMPROPER ELEMENT(S)
ILLEGAL USE OF COLUMN 1 ON CARD
NO FILE SPECIFIED. SYSINjSYSPRINT ASSUMED
MISSING EEMICOLON
ident HAS TOO MANY SUBSCRIPTS. SUBSCRIPT LIST
DELETED
IMPROPER LABEL
MISSING)
MISSING COMMA
MISSING:
name NEVER DECLARED, OR AMBIGUOUSLY QUALIFIED
(EXPRESSION REPLACED OR CALL DELETED)
827
239
211
189
180
169
141
EX78
EX83
EXBB
EX7D
EX98
EX7B
EXB8
COMPILE-TIME
EXECUTION-TIME
SUBSCRIPT number OF ident IS OUT OF BOUNDS
FIXED POINT OVERFLOW
DELETED STATEMENT ENCOUNTERED
LENGTH OF SUBSTRING LENGTH OF STRING
INCOMPATABLE OPTIONS ON OPEN
INDEX OF SUBSTRING LENGTH OF STRING
ARRAY ELEMENT HAS NOT BEEN INITILIZED. IT IS
SET TO o.
EX9F
90
IMPLIED CONVERSION NOT IMPLEMENTED
46
EX89
PROGRAM IS STOPPED. NO FINISH ON-UNIT AFTER
ERROR
45
ident HAS NOT BEEN INITIALIZED.
EXB7
* Conway, R. W. et al,. User's Guide to PLIC, The Cornell Compiler for PLjI, Release 6, Department of Computer Science, Cornell
University, Ithaca, August 1, 1971.
Figure 3a-Most frequent PLjC errors
Present studies of forced program structure and
program proofs of correctness may begin to provide
models on which HLL designers may base their proposals. However, any major changes should be designed to improve the user's system so that each program submittal can be a learning experience. In this
way a programming system can be milled upon to point
out unusual events; draw the programmer's attention
toward possible errors; and yet, not produce volumes
of output which would be costly to print and which a
programmer would refuse to read.
Work at Cornell toward producing compilers which
correct human failings rather than punish them has
culminated in a highly functional, rapid compiling,
and very permissive PL/I student-oriented compiler
called PL/C.44 This compiler does spelling correction of
keywords, automatic insertion of missing punctuation,
etc. In addition automatic collection of some statistics
is done at execution time. For example, each label
causes a count to be maintained of the number of times
execution passed through that labeled statement.
Compilers such as these increase computer power by
reducing the complexity of the user interface.
Implementations of HLLs could further help a
programmer by glVIng an optional cross reference
listing showing locations where a variable is changed,
could be changed, or just referenced. Items could be
flagged if they were never referenced or set; only referenced; or only set. In the first two cases spelling correction might be applicable. Statements which use
expensive library subroutines or other costly language
features could be flagged. Measurement nodes could
be easy to insert and operate. These should, in turn,
produce meaningful data which relate directly to
questions the programmer wanted to ask.
But such discussions have only beat around the bush
itself. The real problem, the bush, is the higher level
language. The real questions are: What features are
error prone? What features of the language allow automatic validity checking of what is written? How can
these properties be identified and measured? How can
the knowledge of these things be used to reduce complexity of the user interface so that the user perceives
an increase in his computer power? Which language
constructs are seldom used, adding unnecessary complexity and unreliability?
Efforts to measure the human engineering aspects
of computer language use37 and to provide feedback
734
Spring Joint Computer Conference, 1972
GRAPh OF VARIABLE 10
SAMPLES CF LESS THAN
eACH SPACE = leo.oo UNITS.
5 HAVE BEEN DELETED.
CGOC
EX78
EX99
*
SM50
EX89
EX7D
*
*
*
*
*
EX7B
CGIF
SV27
S~Sl
EXF5
SYl6
*
*
*
*
*
*
*
*
SY04
SM47
EXB8
EXeB
SV2f
SV3B
SHE
SYlu
*
'"
*
*
*
*
*
*
*
SVCB
SVIJ6
SVOE
SM5E
SV34
*
SY3A
SYl7
'"
*
*
*
*
*
*
*
*
SV09
EX9F
EX9B
EXi37
SVIB
SYlO
SM4E
*
SM4B
SYl3
SVOS
SVE5
'"
'"
*
*
*
EX83
SV02
SVEB
SM4A
'"
'"
*
*
SV3C
SV3C
SM41
SVED
*
*
*
----1----1----
O.CO
0.10
1
----1-------1-------1-------1----.----1----.----1-------1-------1----.----1---0.20
0.30
0.40
0.50
0.60
0.70
0.80
0.90
1.00
1
1
1
1
1
AVERAGE PERSISTENCE
SORTED BV AVERAGE PERSISTENCE
Figure 3b
into the design stages of higher level languages and
the control and command languages of the operating
system may provide major increases in computer
power by:
• increasing the number of users who can bring
problems to the machine
• decreasing the number of problem submissions
necessary to bring a job to completion
Work is in progress at SDC,28,29,48 moving toward a
man-machine symbiosis. These little publicized approaches to measurement of human problem solving
and computer languages have just begun to scratch
the surface of this very important area. Work at UCLA
has attempted to identify properties of PL/I which
are prone to human error. As a first approximation,
error rates and persistence curves of various errors
identified in students' use of the IBM PL/I F -level
compiler30 is presented in Figure 2. Corresponding
results for errors found by Cornell's PL/C compiler
are presented in Figure 3. Figure· 2a shows a table of
the number of occurrences of the most frequent PL/I
error types recorded during compilation and during
execution times. Figure 2b displays the persistence of
errors by PL/I type during the student runs. The
vertical coordinate is the error type ordered by the
magnitude of PERSISTENCE RATIO. The hori-
1
Modeling, Measurement and Computer Power
735
_____
zontal coordinate is the PERSISTENCE RATIO and
was calculated as an average of (number of sequential
trials during which the particular error persisted)
divided by the total number of trials. If an error type
did not occur in at least 5 problem assignments it was
arbitrarily deleted to keep the displayed range of
values reasonable. Figures 3a and 3b display the same
properties for assignments using PL/C. A total of 128
problem assignments completed by 28 students are
included in the statistics. Follow-up work is intended
to lead more deeply into language design and hopefully
into new techniques for automatically localizing errors
in a program.
The basic technique for doing this is to allow the
programmer to specify more information than the HLL
processor needs to compile the program. An example
would be identifiers of the form "CONSTANT" in a
PL/I data attribute syntax. CONSTANTs as opposed
to variables, would only be set by an initial attribute
and would be illegal as a left-hand side of an assignment or as an argument of a pseudo-variable. In addition, the program could be considered as having this
attribute. At several points in a program (e.g., block
exit time) these constants would be checked to see if
their value had changed. If any had, a warning would
be printed; the correct value restored; and the program
would continue. Such a new PL/I data type allows
automatic checking for consistency to localize errors
and yet is almost painless for a programmer to use.
When a program is debugged, it is easy to turn off this
kind of checking for the sake of more efficient performance. In a hardware environment like the
MULTICS GE 645, these errors can be detected dynamically when illegal accesses occur.
Debugging tools should be designed into the language and taught as part of the language, because the
majority of the time a programmer deals with a lan-
V
~ user~ output
~
listing
Source Input
I
)
. ____ input
data
compilation
execution
~accretion/
libra{~
Figure 4a-Information flow in a standard HLL job
user
listing
~ut.put
Ilstm
)
I L1brory~
~our~diting
~~ Ii)
JJ
{I .~
Z
compl atlOn
"------accretion
libr~~
.
execution
~
/1~;~t
~
Figure 4b-Modified information flow to augment feedback
in a HLL job
guage, he is also dealing with an incorrect program.
Subscript checking, trace information, validity checking
at periodic intervals, time and count information,
formatted displays of all program information and
selective store and fetch recording are the kinds of
things which should be available to the HLL programmer.
In addition, measurement tools should be immediately accessible to any user without burdening
others, so that if questions of efficiency are raised they
can be answered simply and quickly. Some of the
measurement tools which seem important are: (1) flow
charts or tables as optional output which would stress
intermodule dependencies; (2) time and count control
statements which could be output, reset and inactivated
under program control, and would create output automatically if the program terminated abnormally or
without expressly outputting the data gathered; (3)
program size should be easily accessible by the program
dynamically and summaries of available space should
be available at program termination.
In order to increase the complexity of the programming problems which users can handle, languages
must be allowed to accommodate personal ways of
expressing concepts. To do this, at the very minimum,
new data types should be available for the programmer
to define as well as operators which use these data
types. This begins to syntactically approach the
Dijkstra concepts and to allow easier application of
hierarchically structured programs. Hopefully these
approaches will increase the user's computer power by
making the development of his programs easier.
The programming system itself should be restructured so that more information is available to a HLL
processor. Figure 4a shows the diagram of information
flow in a usual batch oriented system. The source code
is compiled; the resulting object code is passed to the
accretion step where library or previously compiled
programs are added to it; and the resulting load module
736
Spring Joint Computer Conference, 1972
is passed to the execution phase; finally, output from
execution is passed back to the user. To provide more
automated feedback, Figure 4b shows information
flow in a system where statistical summaries of one
execution are available to the next compilation. In
addition, the accretion step spends much more of its
time checking linkage conventions and the validity of
argument-parameter choices. This programming system has an editj compile time library which is designed
to help make changes easy. For example, it keeps
"COMMON" declarations uniform (read EXTERNAL if you are a PLjI programmer) and it also
uses information from the compiler to point the user at
syntax errors and information from the execution phase
to point the user at semantic errors.
Such modifications can reduce errors and speed the
development of programs by improving communication between what are now considered separate program steps. However, the most important changes,
across all the proposed modifications, are those changes
which will allow the programmer to receive only those
pieces of information relevant to the level at which he
is programming (i.e., making changes). This would
provide dynamic help; help where the programming
language acts as an extension of the users' mind to
assist in problem solving and optimization.
It is important to view these changes which move
toward dynamic assistance in terms of costs. Each
change must cost something in execution time overhead. Some of the more powerful features like selective
fetch and store monitoring must be expensive. However, if these features were found valuable, then modification to hardware might diminish costs dramatically.
Integrating these techniques into HLLs must be
inherently costly because implementation and testing
of human interaction with these diagnostic features
are difficult to execute in any controlled way-much
work must rest on SUbjective evaluation of users'
behavior. Integration of aids into HLL translators
must be initially done without those very aids which
are deemed necessary to help programmers modify
programs. Therefore, any change is fraught with risks
caused by lack of checks in current systems. Obviously
bootstrapping is called for and we can expect many
passes before achieving effective tools.
The development of richer higher level languages
on the one hand, and the development of debugging
services and error correcting compilers on the other,
exert· forces in the direction of increasing performance
at the user interface. With appropriate use of models
and measurement much more improvement may be
obtained.
SUMMARY
Computer systems are different from other systems by
virtue of the dynamic fashion in which our comprehension of their behavior may be built into their operation. If validated models are developed, they may then
be built into the system itself to serve adaptive resource allocation algorithms. If measurement tools are
effectively integrated, they may be made available to
the user to improve the quality of his use of programming languages. If the user is, in fact, a team deve loping programming systems, the modeling and meas urement facilities may serve to make much more complex
programs possible because a model of progr ams being
built is, itself, generally too complex for a group of
unaided humans to manage in an error free way. In
the above paper we have sought to open up these
questions.
We have not had much experience with effective
modeling and measurement. There is an immense
amount of data to be observed in a computer system.
Cost-effectiveness of performance measurement must
be considered. As one of our reviewers put it, "This
reviewer has seen some measurement studies lead to
system improvements which will payoff sometime in
2018." Hopefully the 1970s will see more effect.ive
modeling and measurement introduced into the design
process and selectively carried into developed systems
to he'p both internal process management and the
enrichment of external US3 through the user interface.
REFERENCES
1 R A ASCHENBRENNER L AMIOT
N K NATARAJAN
The neurotron monitor system
AFIPS Conference Proceedings Vol 39 pp 31-37 1971 Fall
Joint Computer Conference Las Vegas Nevada November
1971
2 L A BELADY
A study of replacement algorithms for a virtual storage
computer
IBM Systems Journal Vol 5 No 2 pp 78-1011966
3 L A BELADY R A NELSON G S SHEDLER
An anomaly in the space-time characteristics of certain
programs running in paging machines
Communications of the ACM Vol 12 No 6 pp 349-353
June 1969
4 L A BELADY M M LEHMAN
Programming system dynamics or the meta-dynamics of
systems in maintenance and grow h
IBM Report No he 3546 September 1971
5 D P BOVET G ESTRIN
A dynamic memory allocation in computer systems
IEEE Transactions on Computers Vol C-19 No 5
pp 403-411 May 1970
Modeling, Measurement and Computer Power
6 D BOVET G ESTRIN
19 H FRANK I T FRISCH
737
W CHOU
On static memory allocation in computer systems
Topological considerations in the A RPA computer network
IEEE Transactions on Computers Vol C-19 No 6
pp 492-503 June 1970
7 T H BREDT
AFIPS Conference Proceedings Vol 3 pp 581-587 1970
Spring Joint Computer Conference Atlantic City New
Jersey May 1970
20 D P GAVER
A nalysis of paral'el systems
IEEE Transactions on Computers Vol C-20 No 11
pp 1403-1407 November 1971
8 J P BUZEN
Queueing network models of multiprogramming
PhD Dissertation Harvard University Cambridge Mass
August 1971
9 V G CERF
Measurement of recursive processes
Computer Science Department Technical Report No
UCLA-ENG-70-43 University of California Los Angeles
May 1970
10 V G CERF K GOSTELOW S VOLANSKY
E FERNANDEZ
Formal properties of a graph model of computation
Computer Science Department Technical Report
No UCLA-ENG-7178 December 1971
llWWCHU
A study of asynchronous time division multiplexing for
time sharing computers
AFIPS Conference Proceedings Vol 39 pp 669-678 1971
Fall Joint Computer Conference Las Vegas Nevada
November 1971
12 P DENNING
The working set model for program behavior
Communications of the ACM Vol 5 No 11 pp 323-333
May 1968
13 P DENNING S C SCHWARTZ
Properties of the working set model
Proceedings of the Third Symposium on Operating Systems
Principles pp 130-140 Stanford University October 1971
14 J B DENNIS
Programming generality, paralle'ism and computer
architecture
Proceedings of the IFIP Congress 68 Booklet C Software 2
pp CI-C7 North Holland Publishing Co Edinburgh England
August 1968
15 E W DIJKSTRA
The structure of the THE multiprogramming system
Communications of the ACM Vol 11 No 5 pp 341-346
May 1968
16 E W DIJKSTRA
Notes on structured programming
Report No EWD249 Technische Hogeschool Eindhoven
Spring 1969
17 G ESTRIN D HOPKINS B COGGAN
S D CROCKER
SNUPER COMPUTER-Instrumentation automation
AFIPS Conference Proceedings Vol 30 pp 645-656 1967
Spring Joint Computer Conference Atlantic City New
Jersey April 1967
18 E B FERNANDEZ
Restructuring and scheduling of parallel computations
Presented at the Fifth Asilomar Conference on Circuits and
Systems Pacific Grove California November 8-91971 To be
published in the proceedings of that conference
Diffusion approximations and models for certain congestion
problems
Journal of Applied Probability Vol 5 pp 607-623 1968
21 W J GORDON G F NEWELL
Closed queueing systems with exponential server3
ORSA Journal Vol 15 No 2 pp 254-265 March 1967
22 K GOSTELOW
Flow of control, resource allocation, and the proper term1:nation
of programs
Computer Science Department Technical Report No
UCLA-ENG-7179 University of California Los Angeles
California December 1971
23 R L GRAHAM
Bounds for certain multiprocessing anomalies
The Bell System Technical Journal pp 1563-1581 November
1966
24 A N HABERMANN
Prevention of system deadlocks
Communications of the AC:Vr Vol 12 No 7 pp 373-377 July
1969
25 L E HART G J LIPOVICH
Choosing a system stethoscope
Computer Decisions Vol 3 No 11 pp 20-23 November 1971
26 A W HOLT H SAINT R M SHAPIRO
S WARSHALL
Final report for the information system theory project
Rome Air Development Center by Applied Data Research
Inc Contract No AF30(602)-4211 1968
27 A W HOLT F COMMONER
Events and condition ~
Parts 1-3 Applied Data Research Inc 450 Seventh Avenue
New York New York 10001 1969
28 A HORMANN A LEAL D CRANDELL
User Adaptive Language (UAL): A step towards
man-machine synergism
SDC TM-4539 June 1969
29 A HORMANN S KAUFMANN-DIAMOND
C CINTO
Problem solving and learning by man-machine teams
SDC TM-4771 July 1971
30 PL/I(F) compiler program, logic manual
GY28-6800 Fifth Edition IBM 1966, 67, 68, 69 October 1969
31 D H H IGNALLS
FETE-A FORTRAN Execution Time Estimator
Computer Science Department Report No STAN-CS-71-204
Stanford University February 1971
32 R R JOHNSON
Needed: A measure for measure
Datamation pp 22-30 December 15 1971
33 R M KARP R E MILLER
Parallel program schemata
Journal of Computer and System Sciences Vol 3 No 4
pp 147-195 May 1969
34 S R KIMBLETON C G MOORE
A limited resource approach to system performance evaluation
Technical Report No 71-2 Department of Industrial
Engineering University of Michigan June 1971
738
Spring Joint Computer Conference, 1972
35 L KLEINROCK
Analytic and simulation methods in computer network design
AFIPS Conference Proceedings Vol 36 pp 569-579 1970
Spring Joint Computer Conference Atlantic City New
Jersey May 1970
36 L KLEINROCK R R MUNTZ J HSU
Tight bounds on the average response time for time-shared
computer systems
Proceedings of the IFIP Congress 71 TA-2 pp 50-58
Ljubljana Yugoslavia August 1971
37 D E KNUTH
An empirical study of FORTRAN programs
Computer Science Department Report No CS-186 Stanford
University 1971
38 H CLUCAS JR
Performance evaluation and monitoring
ACM Computing Surveys Vol 3 No 3 pp 79-91 September
1971
39 B H MARGOLIN P P PARMELEE
M CHATZOFF
A nalysis of free-storage algorithms
IBM Systems Journal Vol 10 No 4 pp 283-3041971
40 D F MARTIN
The automatic assignment and sequencing of computations on
parallel processor systems
PhD Dissertation and Computer Science Department
Technical Report No UCLA-ENG-66-4 University of
California Los Angeles 1966
41 R MATTSON J GECSEI D SLUTZ I TRAIGER
Evaluation techniques for storage hierarchies
IBM Systems Journal Vol 9 No 2 pp 78-117 1970
42 J M McKINNEY
A survey of analytical time-sharing models
Computing Surveys Vol 1 No 2 pp 105-116 June 1969
43.C G MOORE
Network models for large-scale time-sharing systems
PhD Dissertation University of Michigan April 1971
44 H MORGAN R A WAGNER
PL/C-The design of a high performance compiler for PL/I
45
46
47
48
49
50
51
AFIPS Conference Proceedings Vol 38 pp 503-510 1971
Spring Joint Computer Conference Atlantic City New
Jersey May 1971
A G NEMETH P D ROVNER
User program measurement in a timed-shared environment
Communication of the ACM Vol 14 No 10 pp 661-666
October 1971
J RODRIGUEZ-ROSELL
Experimental data on how program behavior affects the choice
of schedular parameters
Proceedings of the Third Symposium on Operating Systems
Principles pp 156-163 Stanford University October 1971
E C RUSSELL G ESTRIN
Measurement based automatic analysis of FORTRAN
programs
AFIPS Conference Proceedings Vol 34 pp 723-732 1969
Spring Joint Computer Conference Boston Massachusetts
May 1969
H SACKMAN
Man-computer problem solving
Auerbach Publishers Inc 1970
T J TEOREY T B PINKERTON
A comparative analysis of disk scheduling policies
Proceedings of the Third Symposium on Operatin; Systems
Principles pp 114-121 Stanford University October 1971
R C UZGALIS J ALLEN
360 model 91 execution times of selected PL/I statements
Modeling and Measurement Note No 7A September 1971
360 assembly language source code for selected PL/I
statements with model 91 execution times
Modeling and Measurement Note No 7B September 1971
Computer Science Department University of California
Los Angeles
S A VOLANSKY
Graph model analysis and implementation of computational
sequences
PhD Disserhtion and Computer Science Department
Technical Report No UCLA-ENG-70-48 University of
C.Jifornia Los Angeles 1970
Experiments in page activity determination
by JOHN G. WILLIAMS
RCA Laboratories
Princeton, New Jersey
presents itself: should a page be moved from large-core
to core when it is needed, or should it be addressed in
the large-core directly?
Algorithms which attempt to resolve this question
will be considered below. Such an algorithm \yill be
called a page promotion procedure, since its function is
to promote a page to a more favorable position in the
memory hierarchy. Although the following discussion
will be in terms of a core, large-core hierarchy, some of
the results might be applied to any directly addressable
hierarchy with two or more levels.
In a way this question resolves itself quite simply.
There is a certain overhead associated \vith moving a
page from large-core to core. However, once a page has
been moved it may be addressed by the processor in a
shorter time. Thus a page should be moved if it is addressed often enough that the shorter access time of the
core more than defrays the overhead costs associated
with moving the page. In other words, those pages
which are addressed more often (termed the more
INTRODUCTION
In a memory hierarchy various storage devices are
structured into various levels. By convention, information at storage level i may be accessed and stored in
less time than information at storage level i+ 1. Since
a smaller access time generally implies a greater cost
per bit of storage, storage level i will generally be
smaller than storage level i+ 1. An example of such an
arrangement with four levels is a system with core,
drum, disc and tape memory devices.
A storage level is called directly addressable if the information stored at that level may be utilized by the
processor directly, without first being moved to another
level. For example, in the core, drum, disc, tape hierarchy only the core memory is directly addressable,
since information at the other levels must be moved
into the core before it can be used by the processor.
If a memory hierarchy contains two or more directly
addressable storage levels, then these levels may themselves form a directly addressable hierarchy.
Recently a device called "large-core storage" has
come into use. This device utilizes the familiar principles
of core operation, only it is designed to have a greater
access and cycle time, and consequently it is less expensive per bit. This allows a larger memory to be built
for a given cost, so that large-core storage may be considered as a replacement for drum memory in a storage
hierarchy. A four-level hierarchy might be formed
using core, large-core, disc and tape. In this case storage levels 1 and 2 would form a directly addressable
hierarchy.
Let us consider this directly addressable hierarchy
in more detail. Information in the large-core store can
be accessed in one of two ways. It can be moved from
large-core to core (as if the large-core were not directly
addressable), and then accessed from the core. Alternatively, the information can be accessed directly in the
large core. Assuming that the information is moved in
fixed-size units called pages, the following question
TABLE I -Properties of the four programs studied
PROGRAM
NUMBER
OF
PAGES
(J)
NUMBER
OF TIMES
ADDRESSED
(N)
INSTRUCTIONS
35
833,907
DATA
45
397,075
INSTRUCTIONS
75
1,877,187
105
1,140,077
INSTRUCTIONS
31
209,973
DATA
48
137,530
INSTRUCTIONS
27
973,786
DATA
46
641,931
1
2
DESCRIPTION
OF
PROGRAM
FORTRAN
IV
COMPILER
SNOBOL
DATA
COBOL
3
4
739
. COMPILER
ASSEMBLER
740
Spring Joint Computer Conference, 1972
active pages) should be moved. The problem is to determine which pages are the more active.
Algorithms which detect the high activity pages may
be divided into two types. Algorithms of the first type
simply assume that page activity is known prior to
processing. This is a reasonable assumption for programs of known characteristics. For example, it may be
known that certain pages in a compiler or in an operating system are more active than are others. This approach has been implemented by Vareha, Rutledge and
Gold3 at Carnegie-Mellon University, and by Freeman1 •2 at the Triangle Universities Computation
Center.
Algorithms of the second type depend upon the statistical properties of page activity, although they assume no a priori knowledge of the activity of any
particular page. * Such an algorithm must be used when
a program is not run often enough to become "known"
in the sense of the first approach discussed above.
Even when a program is known, algorithms of this
second type may still be effective and may be simpler to
implement. The page promotion procedures to be studied below are algorithms of this second type.
In the next section we will introduce some experimental data concerning the page activity of several
programs. The two sections following this are devoted
to an analysis of page promotion procedures. In these
two sections, the experimental data will be used to
test the effectiveness of the procedures.
EXPERIMENTAL DATA
In the previous discussion it was tacitly assumed
that certain pages of a program will be addressed more
often than will others. If this is not so, then the page
promotion procedure is pointless. We will now present
some experimental evidence which shows, at least for
several programs, that some pages are indeed addressed
more often than are others.
We consider the behavior of four programs, each of
which addresses memory for both instructions and
data. Let J be the number of pages addressed, and let
N j be the number of times page j is addressed (j = 1,
... J), where a page is addressed either to access information or to store it away. For each program there
are two sets of J and N 1 , • • • N J defined, one for instruction pages and one for data pages. Let the pages
be numbered so that Nj::;Nj+1 (j = 1, ... , J -1), and
define N = NI +N 2 + ... +N J. Some of the properties
of these four programs are summarized in Table I.
For a given program consider the x percent of the
pages (either instructions or data) which are the most
active. We wish to determine the percent of the total
activity which these pages account for. Since N j ::;Nj +1,
this can be obtained as:
Percent of Pages = 100 (k/J) ,
Percent of Activity = 100
t
Nj /
N,
j=J-k+l
where k= 1,2, ... J.
Figure 1 shows this result for the instruction and
data pages of the four programs studied. Note that
some pages are much more active than are others.
Typically, the 50 percent of the pages which are the
most active account for about 95 percent of all the
activity. Thus, at least for these four programs, it is
apparent that a page promotion procedure could be
effective, if one can be devised. We will now discuss
one such algorithm.
A SEQUENCE-INDEPENDENT ALGORITHM
For a given program, suppose that all of the pages
are in large-core storage at the start of processing. Each
time a page is addressed, assume that there is a fixed
probability P that the page will be moved from largecore to core. Once a page has been moved, assume that
it remains in core storage until processing is finished.
>-
I-
:;
i=
u
«
:s IOO,---~·-=-D:....:..:AT,-,-,A,----.
,----======----.
,-----=-'-'-'-'-'-=---, ,--...::..:....:..-'-'==----0
IZ
lLJ
U
a::
lLJ
* It might be noted that this classification of algorithms has an
analogue in other resource scheduling problems. For example, in
queueing theory the shortest-remaining-processing-time discipline requires an a priori knowledge of the processing time of
each job; while the round-robin discipline achieves its effect due
to the statistical properties of the distribution of processing
times, with no a priori knowledge of the processing time of any
particular job.
a.
Figure l-Page activity of the most active pages
Experiments in Page Activity Determination
NO
YES
ADDRESS PAGE
IN CORE
P
MOVE PAGE
FROM LARGE-CORE
TO CORE
I-P
ADDRESS PAGE
IN LARGE-CORE
ADDRESS PAGE
IN CORE
741
core. This may be done by generating a page-fault
interrupt and temporarily suspending the program
using the page, just as if the page were on a drum or
disc. While this is taking place, the random number
generator may place a new number (independent of the
previous one) into the special register . It should also be
possible to place the probability P under program
control, perhaps by keeping P in another special
register.
It is clear that this algorithm will tend to detect the
higher activity pages in the following sense. Given that
a page is addressed more often, it stands a greater
chance of eventually being moved from large-core to
core. However, when it is moved, most of the addressing
of the page may have alre-ady taken place. While it is
clear that the algorithm will tend to tell which were
the most active pages, it is not clear that it will indicate
this while they still are. In other words, the algorithm
itself must use the activity of the pages to select those
pages with the higher activity. Thus there is a danger
that the algorithm will "use up" the activity in the
selection process, leaving little or none remaining after
the page is selected. For any particular program, this
question can be answered by the analysis to follow.
For a given program, suppose that page j is addressed
N j times, each time using the page promotion procedure
described in Figure 2. Define:
Figure 2-Sequence-independent algorithm
Aj
This, in brief, is the sequence-independent page promotion procedure which will be studied below. A flow
chart of this algorithm is shown in Figure 2.
This algorithm is called "sequence-independent" because it acts on each page in a way which is independent
of its action on all the other pages, so it does not depend
upon the particular sequence in which the pages are
addressed. This aspect will be considered in more detail
when we discuss "sequence-dependent" algorithms
below.
From a hardware standpoint, the implementation of
the sequence-independent algorithm should be relatively straightforward. Suppose that we have a pageoriented machine which supports a translation between
virtual and real page addresses. Then whenever a byte
of any page is addressed, this translation function must
be performed. At that time, a real-address limit comparison may be made to determine if the page is in
large-core storage or core storage. If the page is in
large-core, the output of a ran!iom number generator
may be obtained from a special register. Assume that
this output has a uniform distribution between 0 and 1.
Then if the random number is between 0 and P, the
page may be marked to be moved from large-core to
¢j
The expected number of times page j is addressed
in the large-core storage.
The probability that page j will not be moved
from large-core storage to core storage.
It will be shown in Appendix I that:
For the arbitrary program in question, we further
define:
PA
PP
The expected percent of the N times that memory is addressed which will be directed to core
storage.
The expected percent of the pages which will be
moved from large-core storage to core storage.
Since the algorithm acts upon each page in an independent fashion, it follows that:
PA~100[N -
"'f Ai]/
PP~lO+-
f,q,;]/
N,
J.
742
Spring Joint Computer Conference, 1972
PROGRAM I
100 INSTRU CTIONS
/--
/14/
2.104
-/
I
~
PROGRAM 2
INSTRUCTIONS
/2"6'
T P= 10
P= 10
PROGRAM 3
INSTRUCTIONS
a..
DATA
P=10 5 .
/
J
t-
! 100
~~ /
We wish to show that:
A= [(l-P) (1- (l-P)S) J/P,
(6)
cf>= (l-P)s.
(7)
To establish Equations (6) and (7), we note that
the page will be addressed exactly:
o times in large-core with probability P,
1 time in large-core with probability (1- P) P,
2 times in large-core with probability (l-P)2P,
8 -1 times in large-core with probability
(l_P)S-IP,
8 times in large-core with probability (1- P) s.
Then:
S-l
A=O·P+
.L: [So (1-P)8PJ+8(1-P)S
(8)
8=1
This establishes Equation (7). The equation for A
must now be reduced further. It is not difficult to show
that:
S-l
L: s(1-P)8= [l-P- (1-P)SJ/P2
8=1
-[(8-1) (l-P)sJ/P.
Using this result in Equation (8) :
A=P [
l-P- (l-P)S
p2
(8-1) (I-P)SJ
P
+8(I-P)S,
REFERENCES
1 D N FREEMAN
A storage-hierarchy system for batch processing
1968 Spring Joint Computer Conf AFIPS Proc Vol 32
Washington DC Thompson 1968 pp 229-236
2 D N FREEMAN J R RAGLAND
The response-effidency trade-off in a multiple-university
system
Datamation pp 112-116 March 1970
3 A L VAREHA R M RUTLEDGE M M GOLD
Strategies for structuring two level memories in a paged
environment
Second Symposium on Operating System Principles
Princeton NJ 1969 pp 54-59
APPENDIX I
Suppose that a page is addressed 8 times, each time
using the page promotion procedure described in
A= _l-_P_-_(:...-l_-_P_)_S+_P-,-(_I-_P..=.-)S
P
,
(I-P) (1- (I-P)S)
A=
P
,
which establishes Equation (6).
APPENDIX II
Consider a program with a given N 1, N 2 , ••• , N J.
Suppose that a sequence-dependent algorithm is in use
and that:
k=O, 1, ... , K-l
k=K.
746
Spring Joint Computer Conference, 1972
There are N!j (NI! N2! . . . N J!) different sequences in
which the pages may be addressed. Of these, there is
one sequence in which all of the addressing references
to page j are performed prior to any of the references
to page j+ 1 (j = 1, 2, ... , J -1). This particular sequence is called the MIN sequence. Since Nj~Ni+I it
follows that whenever a page is to be addressed in the
MIN sequence, a page is selected so that no other
page has fewer remaining times to be addressed. We
wish to show that of all the possible sequences with a
given N I, N 2, ... , N J, the MIN sequence minimizes
PA.
For a given program, define:
NAThe number of times that core memory
is addressed.
Since N A is a random variable, it follows that:
PA*= 100E(NA)/N.
Thus it will· suffice to show that the MIN sequence
minimizes E (N A) .
Define:
E(NA I k)
The probability that the sequencedependent algorithm will move exactly
k pages from large-core to core.
The expected value of N A, given that
exactly k pages are moved from largecore to core.
It then follows that:
K
E(NA) = LE(NA I k)ak.
k=O
For a given N I, N 2, ... , N J, we will now show that the
ak are independent of the addressing sequence. It will
then suffice to show that the MIN sequence minimizes
E(NA I k).
Define:
sequence minimizes E (NA I k). Define:
'Y j ,k
tj
The probability that page j is moved
from large-core to core, given that exactly k pages are moved.
The expected contribution of page j to
E(NA), given that it is moved from
large-core to core.
Then:
J
E(NA I k) = L tj'Yj,k.
(9)
j=1
Let us consider tj first. We are given that within N j
addressing references, page j is moved from large-core
to core. At each of these references there is a probability
P that the page will be moved, if it has not been moved
previously. It therefore follows from Equations (6) and
(7) of Appendix I that:
tj(I-¢j) = Nj-Aj,
tj(I- (I-P)N j) =Nj- [(l-P) (1- (I-P)N j) J/P,
tj=Nj/[I- (I-P)NjJ- [[I-PJ/P].
It can be shown that t j is an increasing function of
increasing N j (if 0 < P ~ 1). Since N 1 ~ N 2 ~ ••• ~ N J,
it therefore follows that:
(10)
Note also that t j is not a function of the addressing
sequence.
Let us now discuss 'Y j ,k. The expected number of
pages moved from large-core to core is:
J
L [I'Yj,k+O(I-'Yj,k)].
j=1
But it is known that k pages are moved, so:
(11)
j=1
{3k
The probability that the sequence-independent algorithm will move exactly k
pages from large-core to core.
Then
ak={3k for k=O, 1, ... , K-I,
where k is a constant.
We are now in a position to complete the proof.
Gathering our results from Equations (9) through
(11), we have:
E(NA I k) =tI'YI,k+5"2'Y2,k+·· ·+tJ'YJ,k,
tI~t2~··· ~tJ,
'YI,k+'Y2,k+· •• +'YJ,k = CONSTANT.
For a given N I, N 2, ... , N J , the {3k are independent of
the addressing sequence. From the above two equations,
it therefore follows that the ak are independent of the
sequence too.
We must now show, for arbitrary k, that the MIN
It therefore follows that E(NA I k) is minimized by
making 'YI,k as large as possible. Given this, 'Y2,k must
be made as large as possible, and so on. It is obvious
that this will be accomplished by the MIN sequence.
Thus the MIN sequence minimizes E (N A I k), which
Experiments in Page Activity Determination
implies that it minimizes E (N A), which implies that it
minimizes P A, which completes the prooL
747
can be k pages in core memory just prior to page j
being addressed for the first time:
APPENDIX III
(1) There can be k -1 pages in core memory just
prior to page j -1 being addressed, and page j - l
Suppose that the sequence-dependent algorithm is in
use, and that pages are addressed in the MIN sequence. We wish to devise a method for computing:
can be moved from large-core to core.
(2) There can be k pages in core memory just prior
to page j - 1 being addressed, and page j - 1 can
remain in large-core.
The probability that core storage contains exactly k pages just prior to the
time that the addressing of page j begins.
Prior to the first time that page 1 is addressed there
are no pages in core memory, so for j = 1:
R1,o=
1.
Consider now the case when j> 1. The only way
that there can be no pages in core memory just prior
to the first time page j is addressed is for there to be no
pages in core memory just prior to the first time page
j -1 is addressed, and for page j - 1 to remain in largecore. Thus:
Rj,o = R j-
1 ,OcPj-l ,0,
where cPj,k is the probability that page j will remain in
large-core when addressed N j times by the page promotion procedure using P k • We know from Equation
(7) that:
cPi,k= (I-Pk)N i .
For k 2:: 1 there are exactly two ways in which there
Thus:
When k = j - 1 this becomes:
Rj,j-l
but R j -
= R j - 1 ,i-2 (1- cPj-l,j-2) +R j -
1 .i-l
1 ,j-lcPj-l,j-l,
= 0, so:
Rj,j-l
= R j - 1 ,j-2 (1- cPj-l,j-2).
In summary, Rj,k may be computed for increasing
values of j by using the following equations:
IF j = 1 : Rl,O = 1.
IF j> 1: R j ,0 = R j - 1 ,OcPj-l ,0,
Rj,k
= R j - 1 ,k-l (1- cPj-l,k-l) + R j - 1 ,kcPj-l,k
for k= 1,2, ... , j-2,
RU-l
= R j - 1 ,j-2 (1- cPj-l,j-2).
For j = 1, ... , J and k = 0, 1, ... , j-l, the Rj,k may
then be used in Equations (2) and (3) to compute
PA* and PP*.
Validation of a trace-driven CDC 6400 simulation
by J. D. NOE and G. J. NUTT
University of Washington
Seattle, Washington
A counter argument relates to high cost, which is a
frequently-discussed difficulty with simulation. However, cost is a relative matter. There is no point in spending money to simulate or measure a system unless
the resulting changes lead to savings well in excess of
expense; but, when one is dealing with systems costing
on the order of fifty to one hundred thousand dollars per
month, plus supporting expenses equal or greater to that
amount, a relatively small increase in efficiency can
more than pay for a useful amount of simulation and
measurement effort. It is still important to hold down
the cost of simulation and one way of doing so is to
avoid more detail in the model than is necessary.
These points, of course, lead to a compromise in the
choice of what to include in such a model, and as will
be explained later in the paper, we found that the
process of validating the model and examining the
sensitivity to various parameters gave useful insight on
the level of detail that was necessary.
INTRODUCTION
A computer center typically faces questions of how to
deal with a growing load in the face of tight financial
constraints and with the need for lead time for planning
ways to meet the demand. The needs may be met by
altering the equipment configuration, changing priority
algorithms and other features of the operating system,
controlling the time scheduling of various classes of
job load, or perhaps shifting load from one machine to
another if the center is large enough to have such a
capability. It is often difficult to gather enough data
and insight to show the direction these changes should
go and to support the decision to do so. One useful set
of tools is provided by simulation backed up by measurements required for validation. However, it is all too
common to find that fear of interruptions of the computing center's service to user, combined with an overworked systems programming staff, prevents insertion
of the desired measurement probes into the operating
system. Then one is restricted to measures that can be
derived from the normal accounting log, or "Dayfile",
and to software probes that can be injected in the guise
of user's programs. In spite of these limitations, useful
results can be obtained, and this paper describes validation of a simulation model of a multiprogramming
system, the Control Data 6400, making use of these
restricted measurements.
The level of detail included in the model affects the
degree of confidence one can place on the results of the
simulation. It is necessary to represent the system
accurately at the level of detail needed to support the
predictions of interest. This implies not only enough
detail to include the system resources that may be
altered, but also enough detail to faithfully represent
the interaction of these resources. In a complex system
this becomes an important factor since the change in
one area may have surprising effects in another part of
the system. This argues for inclusion of finer detail.
THE CONTROL DATA 6400
Many descriptions of the Control Data 6000 Series
exist and there is no point in repeating a lengthy discussion (see Thornton,! Control Data, 2 .3 MacDougall,4
Noe5). Only the salient features of the system will be
described here in order to remind readers of its general
structure.
The Control Data 6400 is a multiprogrammed, fileoriented system, using a central processor, ten peripheral processors and twelve channels, a central memory
of up to 131K 60-bit words is available to the system
and to the user programs. Each peripheral processor
has 4K memory (12 bits per word) for its local use. The
peripheral processors communicate with the central
processor through central memory and they take over
many system tasks, such as communicating with the
I/O equipment. Concurrent users' programs within the
749
750
Spring Joint Computer Conference, 1972
system become files on disk and these files are placed in
queues for the needed resources. As the programs are
executed, output files are built and transferred to
disk for scheduling of output printers and card punches.
Programs are executed from central memory by the
central processor, using peripheral processors as necessary for subsidiary tasks. A group of eight control
points or communication areas is set aside in lower
central memory. One of these is unique and is used by
the system to keep track of currently unused resources.
The others of these may be occupied by users' jobs or by
system programs such as JANUS and IMPORT/
EXPORT for communication with users' programs.
Each control point, 200 octal words in length, stores
information unique to the job, such as register contents,
program counter, etc., that is needed when the central
processor is switched from one job to another.
A variety of operating systems for the CDC 6400
exists. The one on which this simulation is based is
SCOPE 3.2 with some modifications that are local to the
University of Washington Computer Center. One of
these modifications is the disk image (DI) option.
This option, when used on a tape request control card,
causes the system to first search the disk directory
to see if that tape has been copied onto disk. If so, the
disk file is used. If not, the operator is requested to
mount a tape, which is then copied to disk and retained
there for some period of time, (e.g., eight hours). This
modification is advantageous in an environment in
which many calls may be made for the same tape during
any given day, providing disk saturation is not a factor.
Another modification is the addition of a staging
queue. Jobs that require magnetic tape are held on
disk in this queue until the operator has mounted the
reel on the tape drive; then they are allowed to proceed
into the input queue where they wait for central memory
and for a control point.
A feature of the operating system that has been
necessary to this simulation and validation study is
the system Dayfile. This file accumulates data on individual jobs, such as time into the card reader, time
of exit from the input queue, amount of central processor time used, time into the output queue and time
off the system. This file, which was originally designed
for accounting purposes, provides a significant amount
of information that can be used for describing the job
load in the trace driven simulator and it will be discussed more fully in subsequent paragraphs.
THE APPROACH
The general approach taken in this study was to
develop a simulation at the level of detail that shows the
interaction between tasks and system resources. The
Dayfile was analyzed to obtain trace data, i.e., to show
how the actual job load on any given day made use of
the system resources. Validation runs were then made
by driving the simulation model with trace data from
various days to provide a range of load conditions.
Provisions are included in the simulation model to
represent the input job load either as individual jobs
(to allow driving the model with the trace data) or as
job classes (to drive the model with distributions representative of groups of jobs). Only the former method
is reported on in this paper, because it is restricted to
a discussion of the model and its validation. The use
of job classes will be discussed in a separate paper reporting on use of the model to explore effects of load
variations.
This work was done under a number of constraints
that limited some of the things we would like to have
done. It was important not to interfere with the service
being provided by the Computer Center. In particular,
it was not possible to insert probes in the system monitor, or to dedicate a peripheral processor to the measurement role, as has been done in work by others (see
Stevens,6 Control Data,7 and ShermanS). As a result,
we were unable to include disk statistics among the
parameters used to describe jobs, except in a very
general way. Disk accesses were not modeled in detail
although their overall effect on job flow was accounted
for in the simulation through the time interval a job
stayed at a control point.
In spite of these constraints, a considerable amount
of information was available through the Dayfile and
inasmuch as the constraints under which we were
operating are not uncommon, it may be of interest to
others to see how much can be done without the freedom
to alter the system programs for measurement purposes.
DESIGN OF THE SIMULATION
In general structure, the simulation parallels the
operating system and allows parameter choices representing a range of available operating system and hardware options. The level of detail of the model is restricted to focus on system resources that may be
altered, omitting wherever possible the inclusion of
resources for which no decisions may be made. Execution speed of the model is approximately fifty times
faster than the real system, i.e., one hour of real system
operation is represented by 70 seconds of operation of
the model (see Nutt9 for a detailed description).
The model is written in ANSI FORTRAN and
Validation of Trace-Driven CDC 6400 Simulation
CARD
READER
STAGING
QUEUE
INPUT
QUEUE
CONTROL POINT
751
OUTPUT
QUEUE
QUEUE
Figure I-Modified Petri net of simulated CDC 6400
its general structure is similar to BASYS (see
MacDougaPO). ANSI FORTRAN was used rather
than a specialized simulation language for two reasons:
first it made the program available on both the CDC
6400 and on the XDS Sigma 5 (for which we had no
discrete system simulation language compiler);
second, since this was done in a learning environment
in a university, the use of FORTRAN gave an opportunity to learn more about the details of queue
handling and sequence timing that are obscured by the
automatic features of simulation languages.
The model is trace-driven, i.e., jobs are represented
by the resources they require. It then provides data
about jobs that are dependent on system efficiency,
such as turnaround, job dwell-time at control points
and dwell-time in input and output queues. It also
provides data on system performance such as queue
lengths, the number of control points in use, CPU
utilization, and the amount of central memory occupied by all jobs at sample intervals.
The system actually simulated is shown in Figure 1.
The notation is that of the modified Petri net, as introduced in Reference 5. To generate a simulation, it is
essential to have a clear representation of the system
being modeled. The modified Petri net notation is used
because it shows the computer structure under the
influence of the operating system. * For the purposes of
the present description, it should be adequate to notA
that the vertical lines are transitions. When the necessary input conditions (denoted by incoming arrows)
exist, the transition "fires" causing the output conditions to come into being (denoted by outgoing arrows).
Arrows marked at either end with the symbol "E9"
denote EXCLUSIVE OR; arrows with no symbol attached denote AND ... i.e., two or more are required.
Note that different symbols may exist at the two ends
(input or output) of an arrow.
As an example of the interpretation of Figure 1,
"JOB IN CARD READER" represents the existence
of one or more jobs in the card reader. Whenever the
"CARD READER AVAILABLE" and "JOB IN
* At the state of development of the notation used here, the
system representation by Petri nets is qualitative. Further work
is in progress to add quantitative features to the modified Petri
nets.
.
752
Spring Joint Computer Conference, 1972
TABLE I-Characteristics in Simulator Job Array
Characteristics that are inputs to the model
(Columns in Job Array)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Central Memory (during compilation)
Central Memory (during execution)
Central Processor Time Limit
Central Processor Time Actually Used
PeripHeral Processor Time Used
Job Priority
Magnetic Tapes Used
Disk Image Files Used
Number of Cards Read
Number of Cards Punched
Number of Lines Printed
Total Rollout Time
Number of Times Job Rolled Out
Time Job Entered Card Reader
Characteristics that may be calculated outputs or
(Columns in Job Array)
15.
16.
17.
18.
19.
Time of Entry into Staging Queue
Time of Entry into Input Queue
Time of Assignment to Control Point
Time of Entry into Output Queue
Time Job Vacated Machine
CARD READER" conditions are true, the associated
transition is fired, causing a job to be removed from the
card reader and to be placed in the staging queue
("JOB IN STAGING QUEUE"). Note that the staging queue can accept jobs from the card reader or the
remote input, but not both simultaneously. The use of
EXCLUSIVE OR when leaving the staging queue is
interpreted as follows: When "JOB IN STAGING
QUEUE" is true and no tape is required, the next
transition fires, altering job status to "JOB IN IN f UT
QUEUE." Or (exclusive) when a "tape job" is in the
staging queue and a tape is assigned to it, the transition
fires.
In making use of the model, it is important to be
aware of system resources that are not included. Most
important are channels, peripheral processors, and the
details of disk access (disk file activity is accounted for
only in length of dwell-time of jobs at a control point*).
A most important reason for not including channels and
peripheral processors is that the number of each avail-
able is fixed, i.e., addition of channels and peripheral
processors is not among the decisions that might be
implemented by the Computer Center. Therefore, it
was pointless to examine simulation results dependent
on changes in the number of these units. However, it is
important to bear in mind that before deciding upon
some system changes suggested by the simulator, one
should make measurements to see if the proposed
change is likely to cause saturation in channel or PPU
usage, thereby shifting the bottleneck out of the "range
of view" of the simulation.
A principal feature of the simulation model is the
method used to describe the job load driving the system.
Because this method provided flexibility, it aided validation of the model as well as extrapolation into future
situations of interest. Visualize an array in which each
row describes a job during the period it is active in the
system. As jobs exit from the system, they are removed
TABLE II-Outputs from Simulator
Job Statistics:
Mean and standard deviation for the group of jobs streaming
through the simulator are provided for all the characteristics
listed in Table 1. In addition, histograms of the distributions are
printed for
• Central Memory (average of compilation phase and execution
phase)
• Processor Times (central and peripheral)
• Length of time in Rollout status
• Time on Control Point·
• Time in Output Queue
• Time in combined Staging and Input queues
• Turnaround Time (from card entry to vacating machine)
Complete trace on each job as it progressed through the model
was provided.
Queue Statistics:
•
•
•
•
•
•
Card Reader Queue
Staging Queue
Input Queue
Central Processor Queue
Output Queue
Rollout Queue (i.e., jobs awaiting Rollin)
Resource Utilization: Accumulated busy-time for
* Specifically, an
average disk access time was used, as measured
by a software probe entered as a user's job. The number of
accesses per job was approximated by dividing the job's peripheral
processor .time by the average access time. The measurement
program was written, and the data gathered, by Geoffrey C.
Leach, University of Washington.
•
•
•
•
•
Card Readers and Punch
Line Printers
Magnetic Tapes
Central Processor
Control Points
Validation of Trace-Driven CDC 6400 Simulation
from the array to provide room for new jobs to be
added. Therefore, the array size need be large enough
only to handle the currently active jobs rather than
all the jobs entered within a given simulation run. The
columns in this array represent the trace characteristics
of each job, and their contents are listed in Table I.
Some of these columns (1 through 14) must be prespecified to describe the job; they may contain positive
numbers representing the actual value of the parameter, or may contain negative integers indicating that
a value is to be obtained by the simulator system from
a distribution identified by the negative integer. This
feature allows driving the model with either actual
trace data extracted from the Dayfile of the real system, or from data approximated by distributions that
represent a job mix, or possibly some combination of the
two.
Columns 15 through 19 in the job array show characteristics that may be prespecified (again from actual
values or from distributions), or may be calculated by
the simulator. This flexibility is helpful during validation of the model since it allows one initially to drive
the model with predetermined data, thus force-fitting
it to behave like the real system; and then one can
back off as confidence is gained, and let the simulator
provide more and more of the parameters. This has
proven to be a very useful tool during model validation.
It is also useful for taking care of. "peculiar" jobs,
such as control programs that handle terminals and
other I/O and which appear to the system as long-term
"user" jobs rather than as part of the operating system.
Based upon these input statistics for individual jobs
and on the simulator's calculation of the time each job
requires to go from point to point in the system, data
are gathered on the overall operation of the multiprogrammed system and the nature of the aggregate
results provided are listed in Table II.
VALIDATION OF MODEL
General
The procedure followed to validate the model is
shown schematically in Figure 2, which starts from the
tape containing the Dayfile, i.e., the CDC 6400 normal
record of the day's operation, originally conceived as
an accounting tool. The Dayfile does not exist in a
format suitable to drive the simulator, since entries are
ordered according to clock time and information on a
unit job is scattered throughout the file. The program
DFPREP extracts the proper parameters for each job,
creating a new file of properly formatted trace data
753
LOG OF ACTUAL OPERATION
EXTRACTION
or
TRACE
PARAMETERS AND ANALYSIS
OF DAYFILE
DFPREP
SIM6000
SIMULATION DRIVEN
BY INPUT TRACE
PARAMETERS
COMPARISON OF SHruLATED
AND ACTUAL SYSTEM PERFORMANCE
Figure 2-System validation procedure
selected over the time period being examined.· As
DFPREP reads the Dayfile and creates input for the
simulator, it analyzes the data to provide statistics on
system performance and on the jobs entered into the
system. The trace data are used to drive the simulator,
entering only the input descriptions of the job into the
simulator and asking it to provide simulated system
performance.
The process just described sounds deceptively simple.
In actual fact, getting the simulated model to agree
with measured performance over a range of parameters
and job mixes proved to be a complex and timeconsuming process. The authors suspect that this is a
typical situation and accounts for the fact that the
extensive literature describing simulation of computer
systems is rather sparsely populated by papers on
validation.
On the other hand, this validation phase proved· to
be very valuable, not only in terms of the essential
point of building confidence in the realism of the simulator's performance, but also in the better understanding of the system and of the model that was gained
during the validation process. For example, during
validation it became clear that it was necessary to
extend the model to include jobs that bypassed part
of the system, e.g., a remote batch capability that bypasses the card reader queue and the output queue had
754
Spring Joint Computer Conference, 1972
DAYfiLE ANALYSIS
SIMULATION
300
i
~
250
"'--_
-'" ®
I
~
MEAN DELAY TIME IN OUTPUT
+
®
(= TURNAROUND)
200
f-<
~
~
~
:c1150
:>
100
MEAN DELAY TIME ON
CONTROL POINT +
®
only serve to lengthen the program writing, debugging,
validation, and execution time. The authors believe it
makes far more sense to construct a model along
reasonably simple lines, containing flexibility for injecting needed changes, then adding features when the
validation process shows them to be necessary.
Interestingly •enough, some of the most difficult
things to validate in the model involved human actions
and human judgment, particularly the time required
to fetch and mount magnetic tapes, aqd the criteria
used by the operators in deciding when to place a program in rollout status (i.e., removing it from contention
for core memory and for the CPU) were subject to
wide variations. On the other hand, inclusion of these
factors was necessary for realism and will provide ways
to test some operational procedures and policies that
might be applied.
MEAN DELAY TIME IN
STAGING/INPUT
50
Validation data
37.5
38.5
64.5
75.7
63.8
87.9
169.4
228.5
% STUDENT JOBS/TOTAL
JOBS/HOUR
Figure 3-Comparison of simulated and actual job delays
grown in importance in actual system use so that it
was necessary to incorporate it. Also, the sensitivity of
the system to the manner in which magnetic tapes were
handled became apparent as did the effect of the disk
image (DI) option. Some errors in the model, in the
control point area and in central memory field length
variation, were detected and corrected as a result of
validation. It was found necessary to approximate the
number and duration of disk accesses in order to properly fragment each job's use of the CPU. It also became
apparent that it is important to be able to precondition
the state of the simulated system when starting it in
the middle of the day's operation. In other words, the
start-up transient in the simulation, which seems to be
on the order of fifteen minutes to one-half hour of
simulated time, can obscure the results if one attempts
to simulate two or three hours of mid-day performance
without. preloading the system.
In retrospect, it is tempting to say that some of the
points that needed changing should have been included
in the model as originally constructed. Yet, we would
argue against going overboard in this direction. The
question is one of performance sensitivity to a given
system feature. If one initially attempts to include so
much detail that all significant factors are likely to be
in the model as originally constructed, one is certain
to end up with a number of unnecessary details that
Validation and alteration of the model finally converged to a point where reasonable confidence in the
model was established. To illustrate this, data are presented that cover four different job mixes and job
densities chosen to represent two extremes in computer
usage and an intermediate case. One extreme was near
the end of an academic quarter, during which the system was used heavily by students trying to finish
problems and term projects. The other extreme was
between academic quarters when the student load had
decreased significantly, leaving a predominance of research jobs and system development jobs running on
the machine. The mixes ranged from a low of 37.5 percent student jobs up to a high of 75.7 percent student
jobs. The job densities covered a range greater than 3.5
DAYFILE ANALYSIS
SIMULATION
100
169.4
64.5%
~
ABOVE ACTUAL
~
BELOW ACTUAL
JOBS/HOUR
snroENT JOBS
~
_b
50
50
100
150
(above 150)
SECONDS
Figure 4-Job dwell time in staging plus input queue
Validation of Trace-Driven CDC 6400 Simulation
to one in jobs per hour, and included densities near the
current record day for this installation.
Figure 3 summarizes the mean values of delay times
as the jobs progressed through the system. It shows
comparison values for the real and simulated system
for each of the four load conditions. The lower curve
(A) in Figure 3 shows average delay times through the
combined staging s,nd input queues. The next higher
curve (B) adds control point dwell times to the staging
and input delays. The top curve (C) adds output queue
times to the cumulative delays and thus represents
turnaround times, i.e.; time between entering the card
reader and ejection from the line printer.
A word of warning about Figure 3: Do not interpret
it as "how delay time varies as a function of rate of
DAYFILE ANALYSIS
SIMlJLATION
ABOVE ACTUAL
BELOW ACTUAL
100
169.4
64.5%
OQ
o
I
50
169.4
64.5%
Fi~llre
snruLATION
ABOVE ACTUAL
~
BELOW ACTUAL
JOBS/HOUR
STUDENT JOBS
TOTAL JOBS
'"~
.., 100
~
I
50
SECONDS
50
100
150
200
Figure 5-Job dwell time at control point
job flow"; instead, interpret it as "for the specific
cases (job mix and density), how do the real and simulated systems compare?" The reason for this is that the
higher densities shown in this figure correspond to
cases in which a higher proportion of student jobs were
run. These jobs on student account numbers are predominantly short jobs with three or four pages of listing
and less than ten seconds central processing time
(see Huntll).
The set of points corresponding to the highest job
density (and highest student job proportion) proved
initially to be very troublesome. Upon closer investigation the difficulty proved to stem from tape jobs. For
some reason the standard deviation in t.ape fetch and
mount time for that day was unusually high (greater
STIJDENT JOBS
TOTAL JOBS
..,'"o
DAYFILE ANALYSIS
~
JOBS/HOUR
to.
180
- - - - --- -
755
360
SECONDS
540
6-Job dwell time in output queue
than three times the mean value). For the other days,
the standard deviation ranged from 1.63 to 2.25 times
the mean value. Therefore; for that troublesome day,
the tape jobs were pre-specified in the model, to allow
validation of its performance on the remaining, more
normal job load.
In Figure 3 the middle curves (B) are critical, since
control point occupancy time directly influences memory and the number of control points available. During
validation overall results were found to be most sensitive to agreement in this area. Figure 3 shows only the
mean values. The variation in these values is quite
great and comparison of the distributions of results is
important to the validation. Figures 4 through 7 com-
DAYFILE MiALYSIS
--- ---- -
169.4
SIMULATION
~
ABOVE ACTUAL
~
BELOI/ ACTUAL
JOBS/HOUR
64.5%
STUDENT JOBS
TOTAL JOBS
50
.
~
...o
'"
I
(above 450)
25
90
ISO
270
360
Figure 7-Job turnaround time
450
SECONDS
756
Spring Joint Computer Conference, 1972
Figure 8-Number of control points in use at sample times
pare the simulated and actual distributions for the
various queues and for overall turnaround time for the
job load corresponding to 169.4 jobs per hour and 64.5
percent student jobs. The agreement between simulated and actual mean values for this case, as shown in
Figure 3, is within 9 percent through the staging and
input queue, 11 percent when the control point dwell
time is added, and 4 percent for overall turnaround
time. The agreement in the distributions, as shown in
Figures 4 through 7, shows that the model is operating
quite well over a wide range in values. Figures 8 and 9
show similar comparisons between the number of control points and the amount of memory in use in the
simulation and in the actual system. These are sample
data with the samples not synchronized between the
real and simulated systems. A sample was taken approximately every ten seconds and the total run during
which comparison was made lasted for two hours.
The agreement of the distribution for this particular
load case was representative for the other cases and
they are not repeated here. The goal was to verify the
model to within 10 to 15 percent. This was generally
---DAYFILEANALYSIS
--------
SIlilTLATION
~ABOVEACTUAL
~BELOWACTIJAL
169.4
64.5l
JOBS/HOUR
SnIDENT JOBS
~
achieved over the range of loads and over a range of
parameters within the model. There are some exceptions, but they are generally understood. For example,
the simulation of the 169.4 jobs/hour and 64.5 percent
student jobs assumed that there was a constant availability of two line printers. Analysis showed this not to
be the case. In the actual system only one line printer
was operating initially. Twenty minutes later, another
line printer was turned on, and 25 minutes after this
event, 3 line printers were operational for a short
period of time. Also there were cases where some very
unusual system development jobs appeared in the real
system and they were not accounted for in the simulation; however, these cases are understood to the point
where they do not detract from the confidence in the
model to predict performance for the major types of
jobs that are important in this environment.
SUMMARY
At this point, the model is ready for use in experiments
to examine the effects of changes in load and system
configuration, and these are proceeding.
Perhaps the most important point established so far
is that it is possible to gather enough data to validate
a useful model, even under the stringent conditions
imposed by a non-interruptible computing service
center. There is no doubt, though, that special software
and hardware measurements would be useful. For one
thing, this would provide validation data for a more
detailed simulation of the disk system.
The model as it now stands can be used to predict
the effects of changes in job arrival density or in job
nature. Effects of changes in job CP use and memory
use (estimated and actual), number of cards, lines
printed, tapes and disk image usage can be observed.
Some configuration changes that can be studied include
those in central memory, central processor speed or
numbers, line printers, card readers, tapes, and number
of control points. Scheduling algorithms for these resources. can be varied, and the effects of a variety of
operational policies can be observed, such as tapehandling, rollout, and control of types and schedules of
jobs submitted to the system.
REFERENCES
1 J E THORNTON
Figure 9-Memory in use at sample times
Design of a computer: The Control Data 6600
Scott Foresman & Co 1970
Validation of Trace-Driven CDC 6400 Simulation
2 CDC 6400/6500/6600 reference manual
Control Data Publication number 60100000 1965
3 CDC 6400/6500/6600 SCOPE 3.2 reference manual
Control Data Publication number 60189400 1968
4 M H MAcDOUGALL
Simulation of an ECS-based operating system
SJCC Proceedings 30 pp 735-7411967
5 J D NOE
A Petri net description of the CDC 6400
Proceedings ACM Workshop on System Performance
Evaluation Harvard University pp 362-378 1971
6 D F STEVENS
System evaluation on the Control Data 6600
IFIP Proceedings C34-38 1968
7 CDC 6400/6500/6600 partner reference manual
Control Data Publication number 60222500
757
8 SHERMAN ET AL
Trace driven modeling and analysis of CPU scheduling in a
multiprogramming system
Proceedings ACM Workshop on System Performance
Evaluation Harvard University pp 173-199 1971
9 G J NUTT
Sf M 6000 program description and use
University of Washington Computer Science Group
Technical Report number 71-07-05
10 M H MACDOUGALL
Computer system simulation: An introduction
Computing Surveys 2 No 3 pp 191-209 1970
11 E HUNT G DIEHR D GARNATZ
Who are the users?-An analysis of computer use in a
university computer center
SJCC Proceedings 38 pp 231-238 1971
The evaluation of a time-sharing
page demand system
by JUAN RODRIGUEZ-ROSELL*
The Royal Institute of Technology
Stockholm, Sweden
and
JEAN-PIERRE DUPUY
IBM France Scientific Center
La Tronche, France
choice, e.g., CMS, OS/360 or even CP-67. Only the
real CP-67 runs in supervisor, non-interruptible mode.
All the generated virtual machines run in problem
state, and the computer is enabled for I/O and timer
interrupts while they are active. Privileged instructions
executed by a virtual machine cause a program interrupt to CP-67 which analyzes it and determines the
action to be taken.
Of special interest are the paging and dispatching
algorithms employed by CP-67. 10 For our purposes it
suffices to mention that when processes request the system resources (for example, CPU and main memory)
they are divided into two sets, interactive and noninteractive, depending on their type of activity. Those
members of each set who have been allocated main
memory belong to the active class. When a process
causes a page fault, the paging algorithm tries to find a
page not in use by someone in the active class. If no
page is found satisfying this criterion it will choose the
first page it finds, in what amounts to essentially random
replacement.
Virtual machines communicate with CP-67 by
means of the diagnose instruction. 10 Thus, it is possible
for a virtual measuring machine to demand the information contained in special locations within CP-67.
The information is updated by CP-67, but the data
collection and treatment is done by the measuring
machine. The treatment includes writing the data in a
disk file and displaying the more important information
in a CRT or a console.
The transfer of information by the diagnose instruction and the data treatment are imputed to the measuring machine, which is viewed as just another process
INTRODUCTION
The techniques of multiprogramming originated in an
attempt to better utilize a computer system's resources.
Multiprogramming supervisory systems are usually
rather complicated and their performance is still poorly
understood. Some of the reasons why performance
should be analyzed are given in Reference 1. It is possible to monitor the system with hardware devices, but
analysis must often wait several hours or days before
it can be performed. Also, there are quantities that are
impossible to reach with conventional hardware monitoring devices. In particular, process identities are lost.
This means that some kind of software monitoring
method must be envisaged.
A number of articles2 ,3,4,5 have discussed different
approaches to software measuring. Since operating systems must compute great quantities of information
during their operation, it is clear that the best informed
piece of software of the system must be the supervisor
itself. In the case of CP-67,l° the system used at the
Institute of Applied Mathematics of the University of
Grenoble, a simple approach to monitoring can be used.
CP-67 runs on an IBM System 360/67, which is a
machine having the dynamic address translation feature. CP-67 creates the time-sharing environment by
generating virtual machines. The real resources of the
system (CPU, main memory, channels, etc.) are shared
among the users concurrently logged-in onto the system. After a virtual machine is generated the user loads
in his virtual computer the operating system of his
* Presently a visitor at IBM France Scientific Center.
759
760
Spring Joint Computer Conference, 1972
by the supervisor. Furthermore, the virtual machine is
dormant waiting for a timer interrupt during the comparatively long intervals between two measurements.
The supervisor overhead in running this measuring
system is updating the information kept in CP's counters and the process management associated with the
virtual measuring machine.
The variables chosen to be observed can be classified
as follows:
1. Variables of identification which identify each
measure. They are: date, time of day, ordinal
number of the present measure.
2. Instantaneous variables. They have a meaning
only at the moment at which the measure is
taken. There is no relationship between values
taken at different times. They are: number of
virtual pages in drums and in disks, number of
users logged-in, interval between two measures.
3. Cumulative variables. When the operating system is loaded these variables are set to zero.
They are incremented by the system. The difference between two values is divided by the time
in terval between two measures. They are: time
in problem state, time in supervisor state, time
in wait state, number of pages read per second,
number of pages written per second, number of
pages "stolen" from the members of the active
class per second (see paging and dispatching
description), number of virtual machine I/O
operations per second, number of CP-67 I/O
operations per second, number of privileged instructions per second.
4. Variables of integration. These are variables
whose instantaneous value, or even the difference
between two values, lacks significance. Instead
it is their time average value that is relevant.
For example, the number of processes in the
active lists may be the same at the moment of
two successive activations of the measuring
machine. Yet, during this time interval the
multiprogramming level has changed often, reflecting the fact that user processes block and
become active again. It has been found necessary
to form the time integral of the number of users
in the active class. This is the only case where
relatively many instructions (about 30) have
been added to the system's code. The quantities
that must be treated· this way are: lengths of
queues of the active class, lengths of channel
I/O request queues.
The results presented correspond to measures taken
during the month of July 1971. The system configuration included 512 K 8-bit bytes. Also, two drums used
solely for paging, both on the same channel, and two
disk units each consisting of 8 disk packs. Each disk
unit has its own selector channel. The system measured
was CP-67 version 3 level O. The computer system is
run under control of CP-67 from 8 :00 to 12 :00 and from
15:00 to 18:00. The time interval between measures
was set to 100 seconds of virtual time. Because virtual
clocks run slower than· real clocks this gives real time
intervals of between 100 to about 140 seconds. About
2500 sets of measures were collected in the four-week
period analyzed in this report.
I t is very difficult to give a characterization, even
approximately, of the system load. Heavily used components are PL/1, Fortran, Assembler, Lisp and various other languages. Also context editors and debugging
aids that run interpretively. Most virtual memories
have either 64 pages or 128 pages. Peak loads correspond
to about 40 terminals simultaneously logged in, though
several of these virtual machines may be running multiaccess systems of their own, such as APL or (virtual)
CP-67.
DISCUSSION OF RESULTS
Direct, on-line visualization has proved invaluable
in discovering anomalous system behavior. The first
lesson we learned is that the system has a tendency to
thrash when the number of logged-in consoles exceeds a
certain value. The symptoms are a low CPU efficiency
and a large number of pages stolen from the members
of the active class. Thrashing has been amply discussed
in Reference 9 and is well-known to be caused by increasing the multiprogramming level beyond a certain
pages
second
5
Figure I-Real page fault rate: mr
VS.
Multiprogramming level:
NAP
Evaluation of Time-Sharing Page Demand System
point. This causes an increase in the page fault rate,
which brings an increase in the traverse time (the time
necessary to bring a missing page in memory). This
leads to a decrease in total processing time. As far as
we know, no experimental data has previously been
published on this phenomenon.
There are other conditions whose influence on system
behavior would have been very difficult to determine
without the CRT display. The supervisor time grows
when a virtual machine writes on its console, or, more
generally, on a virtual device attached to the virtual
multiplexor channel. The supervisor time can easily
reach 70 percent or more of the total time when programs write large amounts of data using the multiplexor channel. Another effect which is easily discernible
is the degradation in performance brought about by
insufficient drum space for paging.
Among the interesting results concerning the system
is the low CPU problem state utilization, about 25 percent. Another result is the time the machine spends in
supervisor state, which is about 35 percent of the total
time. These values are well in agreement with values
obtained by a hardware monitoring device, and other
values reported in Reference 6. This means that the
system, although unbalanced, is not CPU bound.
Some of the results concern thrashing and thrashing
conditions. Explanations of thrashing have to do with
number of processes actively competing for the re-
m
v
pages
second
10
5
Figure2-Real stolen page rate: mll
vs.
Multiprogramming level: NAP
~A.P
Il sys
761
%
40
30
zo
10
s
Figure 3-System efficiency: 1] sY"
vs.
Multiprogramming level: NAP
sources. Paging rates have been given in References
6 and 7, yet they are given as a function of the number
of logged-in users, not as a function of the multiprogramming level.
Figure 1 is a plot of m r , the number of page faults
per second of real time, as a function of NAP the mean
number of active processes, i.e., the mean multiprogramming level. Figure 2 is a plot of mv , the number of
pages stolen from users in the active class, per second
of real time. There is nothing dramatic about m r , certainly not the steep. change that should take place when
a certain multiprogramming level is exceeded. Rather,
the curve keeps its nearly constant slope in the region
shown. Figure 2 indicates that as the multiprogramming
level is increased, more and more pages are stolen from
the processes in the active class. It has also been found
that 70 percent of the pages chosen to be replaced
have been modified and must first be written on the
drum.
Figure 3 shows the percentage of real time spent .in
problem state, which we shall call efficiency, as a function of NAP. The maximum efficiency is attained for
values of NAP between 2.5 and 4. The efficiency decreases as the multiprogramming level is increased beyond 4. This is well in agreement with thrashing
behavior, and it suggests that thrashing sets in at this
point. Figure 2 confirms this impression.
762
Spring Joint Computer Conference, 1972
gram executes V virtual time units it will need a total
real time of
faults
10000 instructions
5
T= V + (Vmp)Tp+ (Vmio)Tio
m
p
I'1.
vp
where the quantities mp and T p are respectively, the
number of page faults per unit of virtual time and the
transfer time of a page fault expressed in virtual time
units. A complete discussion of these quantities is
found in Reference 9. Similarly, mio and T io are the
number of I/O operations per unit virtual time demanded by the process and the time necessary to process one such request. The discussion of the factors
affecting these two parameters parallels that of mp and
T p. It is interesting, however, to notice that mio depends
only on the process being considered.
Hence, the process efficiency will be
V
1
=
T
l+mpTp+mioTio
'1JT= -
Figure 4-Virtual page fault rate: mp
Virtual stolen page rate: mvp
VB.
Multiprogramming level:
NAP
From Figures 1, 2 and 3, Figure 4 can be deduced.
Knowing that the CPU can execute 600000 instructions
per second, Figure 4 gives ffip the expected number of
page faults per instruction executed. This curve is the
thrashing curve of Denning. 9 The sudden change in
slope occurs for values of NAP between 3.5 and 4. Before
these values, mp varies comparatively little. A change
in multiprogramming level from 4 to 4.5 brings about
a change in mp four times as great as a change from
3 to 3.5. The lower curve gives mvp , the number of
pages stolen per instruction executed. If we subtract
mvp from mp it is apparent that the number of page
faults per instruction executed would grow less rapidly
if no pages were stolen.
We can conclude that, from the standpoint of paging
rate behavior, the system follows what amounts essentially to a working set policy before it gets into memory
saturation and thrashing. Afterwards two combined
effects take place. One of them is the increase in paging
rate because there are, on the average, less pages available in memory for each process. The second effect is
due to the paging algorithm that takes the decision of
stealing pages which will soon be referenced again.
This will make the paging rate still greater.
Any discussion concerning system efficiency must
perforce take into account the fact that programs request I/O operations during their execution. If a pro-
In order to simplify the discussion we can assume
that Tp and T io are composed only of seek time and/or
rotational delay plus data transfer time. We can also
include the time spent in the queue waiting for the request to be processed. The overhead in T p and T io is
supposed to be small. Measurement of the paging and
disk file channel queues indicate that before thrashing
no queues are formed at the I/O channels. Unfortunately this condition does not last long, for when NAP
grows the transfer time T p grows, because longer
queues form. There is, in addition, the increase in mp
due to thrashing. In the limit we will have
m pT p»I+mioT io
Before thrashing the system efficiency grows linearJy
with NAP
NAP
p
l+m Tp+mioT io
'1Jsys= - - - - - - -
As the multiprogramming level is increased longer
queues form at the paging channel. If the drum is organized as a FCFS drum, like in CP-67, there will
eventually be N AP -l requests in the queue, each request requiring T p time units to be served. If Tn is the
time the channel is engaged serving one request we
would have
Tp = (NAP -l)T n +T n = NApT n
The quantity mp can be expressed as A + B NAP, A, B
constant.
Consequently,
1
Evaluation of Time-Sharing Page Demand System
And the efficiency decreases hyperbolically with NAP.
We can then distinguish three regions in the response
of the system's efficiency to an increase of the multiprogramming level. In the first region it behaves nearly
linearly, in the third region it decreases hyperbolically
and in the in-between region it will grow slowly until
reaching the maximum possible efficiency (see Figure 3).
The influence of the multiprogramming level on system efficiency has been discussed in Reference 11. However, that model is exceedingly simplified and neither
the variation in paging rate nor I/O operations are
taken into account. But it is .pointed out that some
optimum multiprogramming level must exist. Some
experimental data are given in Reference 8 but the
CPU is near saturation at the measured points.
Proceeding in the same manner as for mp we find
that mio is practically constant. Its value has been
found to be
Typically the time necessary to process an I/O request
is about 50 000 instructions. Since no queues are ever
found at the disk channels the product mioTio can be
assumed to remain essentially constant.
Figure 5 shows the experimental values for nWD, the
number of requests waiting to be served by the drum
channel, as a function of NAP. To obtain a mathematical
model of the system is a more difficult question. lVlost
4
ex!?erimental
theoretical
5
Figure 5-Size of drum wait queue:
vs.
Multiprogramming level: NAP
NAP
nWD
40
theoretical
experimental
30
2.0
to
s
mio = 0.1 X 10-3 requests per instruction
763
Figure 6-System efficiency:
l-J
AP
'¥] sys
VS.
Multiprogramming level: N
AP
feedback queuing models assume exponentially distributed service times, which is not the case of the
drum. Another model is given in Reference 12 where
the drum's service time can be a constant or a random
variable. However, in this model file I/O operations
are not taken into account. The model discussed in
Reference 13 does take into account disk I/O operations, but the I/O request sequence and operations are
fixed. Thus it is of no avail in our case. In view of the
paucity of existing mathematical models we feel justified in applying the simple l\-1/G/1 queuing model to
the drum. The data transfer time of the drum is 3.5
msec for a page and a complete revolution is made in
17 msec. Using the Khinchine-Pollaczek formulae we
can find the theoretical curve plotted also in Figure 5.
The curves diverge after NAP = 3, which is about the
point where the system begins thrashing.
Figure 6 compares the experimental values obtained
by using the results of the M/G/1 model for T p and
the measured values for mp. For small NAP the curve is
very sensitive to mioTio. Further measurements are
necessary in order to obtain better estimates of program
behavior. As NAP grows, the number of requests actually
waiting in the drum queue is greater than the calculated value and their difference causes the theoretical
curve to be an upper bound on the system efficiency.
Figure 7 shows the cumulative distribution function
for NAP. The average multiprogramming level never
764
Spring Joint Computer Conference, 1972
A probability
NAP ~
Since the original dispatcher does not prevent thrashing, it has been modified to follow a working set policy.
Data are being collected to analyze its behavior. In
particular, more information is needed about process
resource demand and I/O behavior.
N
1..0
ACKNOWLEDGMENTS
os·
.5
N
The authors are indebted to Mr. M. Peltier and Mr. C.
Hans, of IBM France Scientific Center, for their guidance and stimulating criticism. Professor B. Arden,
presently visiting Grenoble University, has been kind
enough to suggest some modifications. A. Fusi, of IBM
Italy Scientific Center, and J. P. LeHeiget, of Grenoble
University, collaborated in the initial design of the
measurement system. Many friends have reviewed this
report and the anonymous referees have provided constructive suggestions.
The work of the first author has been supported by a
research grant from IBlVI Svenska A.B. and a scholarship from the French Government.
Figure 7-Cumulative distribution function for N AP
REFERENCES
reached 7 in this case. All values between 0 and 2.5
have the same probability of occurrence. The most
probable value is the same as the mean value and it is
3.0. Assuming the thrashing threshold to be at NAP = 3.5
we find that the probability of thrashing is 40 percent.
There is only a 25 percent probability of being in the
optimum region (2.5~NAP~3.5). Of course the multiprogramming level depends on what the users are doing.
It seems that 35 percent of the time the multiprogramming level is less than 2.5, meaning that the users are
not active enough to impose a heavier load on the system. From the efficiency standpoint it seems that,
should the service demand be large enough, it is better
to tolerate some thrashing (e.g., N AP =4.0) than to be
overly anxious to avoid it, imposing, for example,
N AP =2.0.
CONCLUSION AND FUTURE WORK
The system described permits evaluation of the behavior of CP-67 in a given environment. The limiting
factor was found to be main memory, since neither the
CPU nor the I/O channels were saturated. Main memory has been increased to 1024K bytes, and the measurement system has permitted evaluation of the new
configuration.
1 D J CAMPBELL W J HEFFNER
Measurement and analysis of large operating systems during
system development
FJCC 1968
2 H N CANTRELL A L ELLISON
Multiprogramming system performance measurement and
analysis
SJCC 1968
3 A KARUSH
Two approaches for measuring the performance of time
sharing systems
Second Symposium on Operating Systems Principles
Princeton University 1969
4 B WARDEN D BOETTNER
Measurement and performance of a multiprogramming
system
Second Symposium on Operating Systems Principles
Princeton University 1969
5 J H SALTZER J W GINTELL
The instrumentation of Mult'cs
Second Symposium on Operating Systems Principles
Princeton University 1969
6 Y BARD
CP-67 measurement and analysis: Overhead and throughput
Workshop on System Performance Evaluation Harvard
University 1971
7 8 J MORGANSTEIN J WINOGRAD R HERMAN
SIM/61. A simulation measurement tool for a time shared
demand paging operating system
Workshop on System Performance Evaluation Harvard
University 1971
Evaluation of Time-Sharing Page Demand System
8 S R KIMBLETON C G MOORE
A probabilistic framework for system performance evaluation
Workshop on System Performance Evaluation Harvard
University 1971
9 P J DENNING
Resource allocation in a multiprocess computer system
Tech Report MAC-T -50 MIT Project MAC
10 CP program logic manual
Form GY20-0590-0 IBM Corp Technical Publications
Department
765
11 V L WALLACE
D L MASON
Degree of multiprogramming in page-on-demand systems
CACM June 1969
12 Y C CHEN G S SHEDLER
A cyclic queue network model for demand paging computer
systems
IBM Research Report RC 23498 1969
13 G S SHEDLER
A queuing imodel of a multiprogrammed computer system with
a two level storage system
IBM Research Report RJ 836 1971
LSI and minicomputer system architecture
by L. SELIGMAN
Data General Corporation
Southboro, Massachusetts
INTRODUCTION
year. These large minicomputer manufacturers are
necessarily becoming very manufacturing-oriented.
Their production methodology is growing to resemble
that used in producing consumer electronics. Indeed, as
Figure 1 shows, a modern mini with 32,000 16-bit
words of memory and several peripheral controllers is
about the same size as a stero receiver.
Volume production of such a complex product has
been facilitated by the improved reliability provided by
the new technology. In fact, the greatly increased reliability of the modern mini, based in part on the use of
LSI, has been a major factor in its proliferation, especially in real-time systems.
The basic cycle of a maturing industry-larger market, fewer manufacturers, better product, higher volume, increased manufacturing orientation-has naturally driven prices down and opened new application
areas.
The indirect impact of LSI grows out of the business
cycle as each of the minicomputer manufacturers remaining use many more integrated circuits. The successful manufacture of complex integrated circuitry requires high volume to obtain the high yields required
to achieve profitability. Without large volumes, LSI
manufacture is burdened with high prices, low yields,
stalled development programs, and money-losing sales
efforts. However, as minicomputers begin to use more
LSI-more because the product design calls for more
LSI per unit, and because more units are being made~
large IC production develops. At this point the snowball effect begins to work beneficially. There are large
circuits requirements, higher yield, lower costs, larger
orders. This process is very much in keeping with the
evolutionary character of changes in mini price/performance. That is, the manufacturers are increasing
their use of LSI technology in predictable, evolutionary
way, and not as a means to a breakthrough.
A third element in the growing maturity of the industry has been the diffusion of computer-oriented professionals into most industries. Many of the students
The direct impact of Large Scale Integration (LSI) on
minicomputer system architecture has been and will
continue to be evolutionary and incremental, not revolutionary.
LSI has been applied to minicomputers most effectively in the form of an incrementally improved technology. When well understood, it has offered predictable
cost reductions and performance improvements. It has
been most successful commercially when combined with
other factors such as improved core memory technology
and imaginative new approaches to minicomputer
packaging. While the combination of these factors has
been steadily driving prices down and performance and
reliability up, we are not likely to see the bottom drop
out of prices. There will not be a full scale minicomputer
in every gas pump in the near future; nor will there be
such dramatic improvements in minicomputer performance that minis will replace large System 360s one
for one.
INDUSTRY lVIATURITY
Although technological advances, including increased
use of LSI, have improved both price and performance,
the recent maturing of the industry has had a more
dramatic impact on the minicomputer market; thus, it
has also had an indirect impact on the technological
base of the industry.
A few years ago, there were many companies selling
minis. The cost of entering the market was low, and
many of these companies enjoyed some initial success.
In the last few years, however, price competition has
increased significantly, and the number of manufacturers has shrunk. Concurrently, the OEM minicomputer market has grown, such that, while there are
many fewer companies in this business today, those who
remain are each manufacturing thousands of units a
767
768
Spring Joint Computer Conference, 1972
the system. Peripheral devices and their controllers/
the system hardware package, and the software to run
it all costs as much or more than the basic CPU/
memory package.
It no longer makes sense to hold a strictly processor
centered view nor does it make economic sense to base
all design decisions on a requirement to keep the central
processor busy all the time. The low total costs of
modern minis make multiprocessor minicomputer systems a practical alternative to large multitask monoprocessors, especially in real-time systems which can be
partitioned into individual functional tasks.
Figure I-A modern minicomputer with 32,000 words of memory and several peripheral controllers requires only 57<1" of rack
space
who had hands-on experience with minicomputers in
the university environment will apply this experience
to the development of minicomputer based systems for
specific applications that had not previously used computers, and they contribute a wealth of ideas to the industry itself.
EFFECT OF LSI
While the result of these technological and business
developments has been an evolutionary improvement
in the price, performance, and reliability of minicomputers, the effect of the improvement has been revolutionary in one important area-the basic architecture
of medium-scale computer-based systems.
There have been two elements in the revolution.
First, the minis are real and system designers can trust
them. They have become inexpensive, so inexpensive
that they are impossible to ignore; and they are reliable, largely because they contain far fewer components and are built in long production runs. For those
applications with emphasis on logical decision making,
their performance is comparable to large-scale systems. 1
Thus, system designers are using minicomputers in
new applications such as front ends or preprocessors for
large business data processing installations; at various
levels in hierarchical communications systems; in small,
dedicated accounting systems; and in groups in realtime control applications.
The second part of the revolution is more interesting
and is developed in detail in this paper. As the minis
have become faster, more reliable, and less expensive,
they have forced changes in the traditional perception
of a computer system. Today most minicomputer processors comprise a relatively small part of the cost of
MULTIPROCESSOR CONFIGURATIONS
The use of multiple minicomputers, each performing
some relatively independent function as part of an
overall system, is a natural extension of the concept of
the dedicated realtime minicomputer that has evolved
over the past several years. This technique is in sharp
contrast to the traditional approach to a real-time application, which consists of dropping the entire timecritical package onto a single processor. The alternative
approach outlined here substitutes an individual minicomputer for each of the natural functional subsystems
of a large-scale application, interconnecting the miniprocessors through an adequate communications path.
The "traditional" or general multiprocessor system
is a cross-connected network of processors, memory,
and I/O controllers (channels); this configuration
Channel or
Generalized
Channel or
Generalized
I/O
I/O
Controller
Controller
Channel or
Generalized
I/O
Controller
,~------------~~~--------------~/
Figure 2a-Traditional multiprocessor
LSI and Minicomputer System Architecture
769
shown in Figure 2, is widely described in the literature2
and is most often proposed for the multitask environment.
A number of problems have arisen in the completion
of the development programs for these systems. Very
high utilization is considered imperati-;e for these systems, and a sophisticated multiprogramming executive
is required to keep the processor busy. Use of a large
executive control program is acceptable so long as the
costs of resource allocation and optimization do not
exceed the savings which can be attributed to its use.
This goal has not always been realized,3 although a good
deal of research has been done on "balanced" resource
allocation. 4 Minicomputer multiprocessor systems will
inherit similar problems if configured in the traditional
patterns. In addition, these problems would have to be
solved in light of the particular constraints imposed by
Figure 3-Processor and memory subassemblies
Main CPU
Support CPU
Hain Memory
Memory
Channel or
Generalized
I/O
Controller
Channel or
Generalized
I/O
Controller
qommunication
Facilitv
Lower
Speed
Devices
Figure
2b~Associated
support processor
minicomputers, especially the amount of software development resources which can be applied economically.
"Wrhile there are a number of these traditional multiprocessor systems in use today, many more multiprocessor systems are organized in the form of a main
processor and one or more smaller support processors.
The processor cost in each system is often sufficiently
low compared to the cost of the peripherals required to
support the data base that it is economical to increase
capacity with additional processors.
This associated support processor concept is less elegant, but it has been more successful commercially,
mainly because the program development efforts required to make it operational are within the resources
of the various manufacturers. The support processors
function primarily in the I/O area, freeing the main
processor to perform computational functions, while
communications, file maintenance, and most I/O activities are handled elsewhere. Even without an explicitly programmed support processor, a typical large
scale system is a multiprocessor in that the data channels and some of the peripheral subsystems (especially
the disk) contain a substantial instruction processing
capacity.
The increased use of LSI imposes some new economic
constraints, especially in regards to multiprocessor
configurations, on minicomputer systems engineering.
The cost of the central processing or memory units are
so low that one is forced to view them as modules. In
fact, in the case of the Nova 1200 series, as shown in Figure 3, the processor is a single replaceable printed
circuit card as is an 8192-word memory module. Other
modules, for example a magnetic tape or disk controller,
are about equally complex as a processor. Since the
770
Spring Joint Computer Conference, 1972
manufacturing volume of the processor module is
higher than the others, its sales price can be lower.
Thus, the use of multiple processors need not add significantly to the system cost.
Once it is decided that a multiple processor approach
is the most suitable for a particular application, the
intramodule connection facility must be selected. Due
to the small physical size and low cost of the modules,
the interconnection facility and the mechanical package(s) must be low in cost or much of the potential
economic advantage of LSI is lost. Yet, the interconnection facility must support the extremely high combined data rates found at the processor-memory interfaces.
The generalized crossbar interconnection scheme used
in the traditional multiprocessor does not meet these
needs. Nor does there seem to be a general solution to
the multiprocessor system design problem. One does not
simply replace a single $200,000 large scale processor
with 50 or fewer $4,000 minis, however tempting. However, a number of specialized minicomputer systems
have been developed with the concept of the mini as a
system element, and some general principles can be
abstracted from these designs. As implemented on the
minis, none are multiprogramming systems but by
necessity they would have been if they had been implemented on a one or two processor large scale machine.
They are all organized in a form similar to the associative support processor concept. A processor and sufficient storage to hold its application program and
data buffers form a module. Several of these modules
are connected via a high speed interconnection bus, so
that data and control information can be passed among
the several functional programs.
THE PROCESSOR/STORAGE MODULE
The processor/storage module approach of Figure 4
(PSlVI) calls for the loose interconnection of a number
of such modules into a single system according to a
partition of the overall application into functional
tasks. The modules operate independently but are tied
together via an interconnection bus that allows a
number of concurrent inter module logical communications links to be established. Processing is thereby
distributed across the system rather than concentrated
at a central point.
The logical basis of the PSlVI approach is "locality",
which is the observed phenomenon that the memory
address patterns generated by a processor are not
random but exhibit a strong clustering. This principle
has led to the development of many storage hierarchy
systems ranging from cache memories in modern large
scale machines5 to various overlay systems like the
chaining feature in Fortran to demand paging timesharing systems. The success or failure of these various
approaches depends on the relationship between the
a.mount of locality encountered and the overhead incurred on nonlocal references. The general problem is
difficult to model mathematically, although in recent
years several approaches show promise.
Locality requires, especially in real time systems, that
certain portions of the program be resident in primary
(low access time, executable) memory; other portions
can be brought in as needed. l\Iinicomputer economics
are such that each memory partition might just as well
have a processor associated with it. One would then
think of the memory as defining a function, specializing
a processor for a task just as read-only control memory
has been used to define the function performed by
microprogrammable controllers.
The interconnected processor/storage module organization described here constrains the programs
'written to a form that is highly local. Like chaining in
Fortran, inter module references are quite explicit and,
hence, visible to the individual programmer 'who most
optimally partition the program.
Not all of the individual minicomputer subprograms
need come directly from a partitioning of the task. A
PSlVI can be used as a flexible, programmable controller
to enhance the performance of peripheral equipment.
In the message switching system example below, the
disk control program and associated processor, together
with a simplified hardware controller, perform many of
the more sophisticated key search functions that would,
in a large scale system, be performed in part by the file
controller itself. The major advantage of the mini as a
controller is that it can be programmed by the user for
its particular task rather than micro-programmed at
-
-
-
-
-
-
-
-
-
-
-I -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - -
1
1_ _ _ _ _ _ _ _
_
'~-------------~~----------------~/
Figure 4-Processor/storage module system organization
-
LSI and Minicomputer System Architecture
the factory for a generalized task. It is far easier to
modify a factory supplied operating system than to alter
firmware.
In addition, programs can be swapped in and out of a
physical memory through the inter-module communication facility. In such a situation, one module would
have secondary storage associated with it and would
distribute programs on request (or by some scheduling
algorithm) to other modules. In essence, it would act as
a (micro-) programmable multi-port disk controller
serving many processors and would perform certain
system level executive functions.
The hardware actually used to interconnect the processor is termed a multiprocessor communications
adapter (MCA). One lV[CA is attached to the I/O bus
of each computer in the system, and the adapters are
connected together by a common communication bus
which is time-division multiplexed among the adapters.
Although a single circuit module, an M CA actually
contains independent receiver and transmitter subsections, allowing simultaneous reception and transmission of data. Each interface is connected separately
to the data channel. The program need only set up an
interface for receiving or sending, and all transfers to
and from memory are then handled automatically by
the channel hardware. A processor with an adapter can
establish a link between its transmitter and any receiver it designates, provided that the receiver adapter
has been initialized for reception.
A number of logical links concurrently share the single
communications bus using time-partioning multiplexer
circuitry built into the adapters. If there are N logical
links established and communications is proceeding on
all, each link receives l/N of the communications bus
time. The bandwidth of the bus is 500 KHz (1 million
bytes per second). However, this rate will only be obtained when a large number of links are active concurrently as data rates are primarily determined by the
processor's channel facilities. The typical data rate on
a single link for a pair of Nova-line computers with high
speed data channel feature is 150 KHz.
Each adapter has a unique identifying number assigned to it. These codes are used to specify the number
of a second adapter to which the first is to be logically
connected. Upon receipt of the first data word from some
transmitting adapter, the identifying number of the
transmitter is set into the receiver adapter status register; the receiver will subsequently accept further data
only from the transmitter, i.e., it "locks" to that transmitter. It must be explicitly unlocked by the receiving
processor's program.
A number of the specifications of the lVICA arise from
the need for the whole system to remain functional
771
despite a hardware or software failure. The transmitter
registers must be initialized by the transmitting processor; and the receiver registers must be initialized by
the receiving processor. Thus, a transmitter cannot
force data into a receiving processor at addresses not
specified by the receiver. Transmission of a block terminates when the number of words transferred satisfies
the transmitter or receiver with the shorter word count.
In addition, a receiving processor is not only protected
against a failing transmitter as described above, but
the hardware is arranged so that any of the intercon. .
nected computers can be stopped or have their power
switched off without affecting the other computers still
in operation. If a processor adapter attempts to transmit data to an unavailable receiver adapter, a timeout
interrupt will occur after a delay of approximately 10
milliseconds. If the receiver is unavailable because it is
linked to another transmitter, the transmitter may be
restarted for further attempts or the data may be
routed to a different receiver.
The size and nature of the data transmission can follow any convention established by the user; no particular structure is forced by the hardware design. In a relatively simple system in which the size and nature of the
data block to be transferred is always known in advance, the receiver can simply initialize itself to accept
the next block at the completion of the previous transmission.
If the exact size and nature of the data blocks is
determined dynamically, a control block specifying the
nature of a transfer can be transmitted before the actual
data block. With such a convention, the receiver initializes itself to accept a control block of standard format and unlocks itself. The first word transferred to the
receiver locks it to the sending transmitter by setting
the transmitter's code into its status register, locking
it to that adapter transmitter until explicitly unlocked
by the program. Thus, once the first word in a control
block is accepted, the receiver is locked to that transmitter and can be initialized to accept subsequent
data blocks from the appropriate transmitter.
Alternatively, the control block from adapter A to
adapter B can be a request for data. Adapter B's transmitter can be started sending the desired data while its
receiver is reinitialized to accept a new controf block.
The hardware itself does not distinguish between a
data and a control block.
The first sample system using the PSM approach is
shown in Figure 5. The function of the system is small
scale message switching and it uses the separate control
and data block technique. Separate processors handle:
(1) interfacing to synchronous and asynchronous lines,
(2) disk queuing, and (3) executive and journal func-
772
Spring Joint Computer Conference, 1972
I~--------~/\~--------
Synchronous Line
Disk
Drives
Asvnchronous Line
"lnd Jpurnal Module,
Controller Module,
Line Interfaces,
Tape
Drives
Line Interfaces,
Tal?e Controller, and
Figure 5-Small-scale message switch
tions. The system is an analog of its large scale predecessors in the sense that PSM's duplicate the functional
software components.
The synchronous and asynchronous line control
processors duplicate the functions of a transmission
control unit as well as the functions of the line-control
and polling-sequence subprograms normally run in the
central processor. The number of processors required
for these functions is determined by the total combined
line rate supported. It can vary from one to several
depending on the capacity of the rest of the system.
Similarly, the disk processor duplicates the key search
functions performed by more sophisticated large scale
computer disk subsystems. It also decreases effective
disk access time since it can use its core (up to 64K
bytes) as a data buffer in three ways: First, write operations as seen by the line control processors are virtually
immediate, as the data can be passed through the MCA
at 300 K bytes/sec. to a primary memory buffer area
for future writing on the disk. Second, the queuing
processor can optimize the order of seeks to the disk,
thereby reducing disk latency. Finally, if sufficient primary memory buffering space is available, the queuing
processor can look ahead in the queue for output messages. In some cases, a message accepted by the queuing
processor would be output directly from primary memory if it had not yet been written on disk. All of these
techniques are possible in a single large scale processor
as well as in the multiple mini configuration; however,
they are less practical, due to the relatively higher price
of the needed primary memory and limited processing
time available.
For lines using the bisynchronous communication
discipline, the synchronous line processor is definitely
needed. The control sequences required by that com.;.
munication discipline are complex and expensive to
implement in hardware. By using software drivers, not
only can the control 'procedures be handled for a large
number of lines, but a variety of other line disciplines
can also be accommodated (i.e., "foreign" terminals
can easily be added to a system.)
The journal and executive/monitoring functions are
traditional. As the disk is basically organized as a ring
buffer, older messages can be copied from it onto tape
during the system's idle periods in order to keep as
much space as possible available on disk. A second tape
keeps a permanent record, including sequence numbers,
terminal ID's, etc., of system activity. The executive
function is primarily active in case of error, rebuilding
the system after error through journal tapes; it also
responds to system level messages, such as requests for
retransmission of an earlier message.
The significant point is that nmv functions and applications modules are not limited by total computational capacity, because additional processor modules
can be added as necessary.
A second example of the PS::\I approach is the experimental multiprocessor small computer system developed
at the Plessy Laboratories for the control of a small telephone exchange. 6 The design is inherently extensible
and allows for better performance for both voice and
data users since the processing capability is distributed
among the several processor/memory modules, the
number of which can be varied according to the size of
the switching network being controlled. The modules
are interconnected via a "ring highway" data transmission path similar to the previously described multiprocessor communications adapter.
The organization of the control programs for the
multiprocessor complex is almost identical to the
organization used in the (essentially) single processor
telephone exchange control developed at Bell Laboratories.
In both cases, large tables stored in memory define the
state of the switching network itself, and individual,
table-driven functional programs are run to implement
the various stages in the completion of a call. The major
difference between the two approaches is that a spatial
distribution of programs across several processors is
used in the former, while a time division of the processor is used in the Bell System No. 1 ESS. The amount
of interprogram data movement is proportional to the
number of calls that can be completed per second. This
number is relatively small, since it is limited by the
electromechanical nature of the switching equipment.
A detailed description of the functions performed is
beyond the scope of this paper, but such tasks as dial
pules accumulation, network computation, billing, and
trunk signaling are typical.
A second important distinction between the Plessy
and Bell systems results from different goals influencing
the tradeoffs between the costs and benefits of redundancy and error detec tion. The micro-synchronism of
the two computers used in No.1 ESS allows for the
LSI and Minicomputer System Architecture
immediate detection of hardware errors at the cost of
doubling the amount of hardware required. The PSM
approach allows as few as one additional module to be
used for lower cost redundancy but does not provide as
good error detection. Dual micro-synchronous processors could, of course, be used as modules in the
PSM approach which is probably less susceptible to
software errors. In addition, many of the real-time
problems encountered in a time-division, traditional
multitask system can be avoided because modules can
be added as the traffic load increases. In fact, as in the
message switching system, the modular design facilitates the duplication of a module or application program when use of that program exceeds the available
subsystem capacity.
773
will spur the development of a methodology for system
design.
REFERENCES
1 A KAY
Computer structures: Past, present and future
AFIPS 1971 Fall Joint Computer Conference Vol 39
pp 395-396
2 F J CORBATO V A VYSSOTSKY
Introduction and overview of the multics system
AFIPS 1965 Fall Joint Computer Conference Vol 27
pp 185-196
3 R J KAY
The management of large scale software development projects
AFIPS 1969 Spring Joint Computer Conference Vol 34
pp 425-433
4 P J DENNING
Resource allocation in multiprocess computer systems
SUMMARY
PhD thesis Massachusetts Institute of Technology 1968
5 C J CONTI
Concepts for buffer storage
A number of technical and economic arguments have
been presented for the use of multiprocessor minicomputer systems. It is hoped that the examples given
IEEE Computer Group News March 1969 pp 9-13
6 J R POLLARD
Putting the computer into the telephone exchange
Computer Decisions June 1970 pp 34-37
Approaching the minicomputer on a silicon
chip-Progress and expectations for LSI circuits
by H. G. RUDENBERG
Arthur D. Little, Inc.
Cambridge, Massachusetts
INTRODUCTION
Before attempting to evaluate the possibilities and
assess the likely impact of recent advances in LSI
technology on the minicomputer field, we shall examine
the progress made to date and, from this, draw inferences about likely developments over the next several
years.
Technological progress in semiconductor integrated
circuits during the last five years has been truly astounding, and the results of this progress are being
aggressively exploited in the designs of new minicomputers. During the 1960s, effort in minicomputer
design was concentrated on applying the low price,
high speed, and ever-increasing complexity offered by
the integrated circuit industries to the original architectures so as to provide greater speed and particularly
lower cost. lVluch of this effort consisted of substituting
first 1\181 and now LSI circuits for the simpler integrated circuits with which previous minicomputers
were implemented without greatly changing either
archi tecture or structure and programs. ""Vith such
substitution, however, tremendous decreases in system
cost and some increases in speed were accomplished.
Most recently, new structures and architecture are
being examined so as to further extend the capabilities
as well as economy of minicomputers.
Especially impressive has been the impact of LSI on
small, portable electronic calculators; one can readily
expect a revolutionary impact soon on minicomputers.
For example, during 1969-70, the electronic calculators
then sold required five separate lYIOS/LSI devices.
Present calculators function with two or three different
devices, and one now being developed performs all
calculating functions with a single large M OS /LSI
device. In these examples, modern LSI semiconductor
technology has created the LSI calculator-on-a-chip,
which requires only the input keys, output display, and
power supply in order to provide the four major
mathematical functions for up to sixteen digits. Soon
we shall similarly see the microcomputer and the
minicomputer-on-a-chip or possibly two or three
chips for separate memory logic and interface. A
microcomputer of modest capability using four-bit
words has already been conceived and implemented.
PRESENT ACCOMPLISHl\1ENTS
Performance improvements
The great progress achieved by the semiconductor
industry during recent years has been widely documented. LSI circuits underwent considerable improvements between 1965 and 1970, as shown in Table 1.
TABLE I-Best Characteristics Available in Integrated
Circuits or LSI
Function
Switching delay
(nanoseconds)
Device complexity per chip
Gate circuits
Bipolar
MOS
Bit density
Bipolar
MOS
Price per device package
Per gate or circuit function
Bipolar
MOS
Per memory bit (RAM)
Bipolar
MOS
Source: Arthur D. Little, Inc.
775
1965-66
12
1970-71
1.2
Factor of
Improvement
10:1
12-16
100
150
5-10,000
4
32
$2.00
256
1,024
20¢
$1.00
$0.30
4¢
2¢
25:1
15:1
$4.00
$1.00
6¢
1¢
65:1
100:1
1:10
1:100
1:64
1:32
10:1
776
Spring Joint Computer Conference, 1972
100------------------------------~
>
e:(
..J
W
C
w
le:(
e,:,
1965
1970
naturally, not all of these peak achievements can be
obtained simultaneously from the same device. However, by examining commercial offerings more closely,
trade-off curves depicting the available relationships
between several of these factors can be determined
which describe the data available for any technology
at a given time.
Of considerable interest are the performance tradeoffs against price. With increasing circuit function
complexity, the price of mass-produced bipolar logic
gate circuits will obviously increase due to the decreasing yields obtained for large, complex silicon devices.
Ultimately, when device size or complexity measured
1975
YEAR OF INTRODUCTION
10------------~--------------
SOURCE: ADL
Figure I-Speed of bipolar integrated circuits versus year
of introduction
ena:
These improvements can also be seen from Figures 1-3,
which present the achievements in speed, complexity,
and price of LSI circuits during this period and project
their trends to 1975.
C
INDUSTRY AVERAGE
.'-. . / SELLING PRICE (ASP)
' . PER PACKAGE (EIA)
'.
~
-I
-I
o
w
....
'~PRICE OF LOW-COST
~
(!)
,LOGIC PER PACKAGE
a:
Trade-off relationships
"
w
Q.
The data of Figures 1-3 and Table I represent peak
achievements of devices offered by the industry;
'----....,.
1~--~,~------~~------------~
W
U
a: 0.10 ~------'lIk--+------=-~--I
Q.
a:
o
10,000 -----------------....------..........- 4096
w
Q..
u
J:
U
Q.
a:
a:
1024 _
w
Q..
Q..
J:
U
CI)
5u
1000
a:
256 ~
a:
U
CI)
w
1965
1970
1975
SOURCE: ADL, EIA
l-
Figure 3-Price of bipolar logic circuits
~
o
by the number of gate circuits per module rises into the
hundreds, the yields become low and cost of production
rises disproportionately rapidly. Figure 4 depicts this
relationship for some commonly purchased TTL
circuits. These prices represent recent quotations for
quantities of Y2 to 1 million units per year and are
believed representative of the present status.
A more useful picture is obtained by dividing the
price by the number of gate circuits contained on each
chip, thereby obtaining the price per circuit function;
In mid-range, this price of bipolar TTL circuits ranges
between 3¢ and 4¢ per circuit function. It is readily
seen that for devices of low complexity one primarily
S
le:(
~
~
2
0.01 _ ......_______--""'_...10-._ _.............. - .
64
100
:E
w
:E
w
..J
e:(
16
>
:::>
C
~
10
1965
1970
YEAR OF INTRODUCTION
SOURCE: ADL
Figure 2-Complexity of LSI and IC versus year of introduction
Approaching the Minicomputer on a Silicon Chip
pays for the packaging; in devices of high complexity,
yields become of overwhelming importance and actually
raise the price per circuit function.
This mid-range price has decreased greatly from year
to year and depends, of course, on the volume of
purchasing, the type of package (such as military or
commercial), and other factors as well as the circuit
technology used in implementing the logic functions.
Figure 3 illustrates the time development of this
economic figure of merit for logic, the price per gate
function. In 1965-66, the cheape3t logic circuits readily
available were DTL circuits, whereas at present the
cheapest bipolar integrated circuits are TTL, and some
still less expensive logic circuits are MOS. It is seen
that the reduction applies to the cheapest units available as well as to the average for the industry; the latter
is generally three or four times higher, since it represents
also the effect of smaller unit volume of some types as
well as military and specialized packaging.
In a like fashion, one may survey the price/speed
relationship by plotting such minimum function prices
777
10
en
a:
«
..J
..J
1965-66
-0
C
w
....
«
(!)
(J
(!)
0
..J
a:
W
Q..
W
(J
0.1
a:
Q..
~
=>
1970-71
~
X
«
10
~
0.01 '--_ _
PRICE PER DEVICE
PACKAGE
100
....;._~_"_
_____
10
GATE CIRCUIT DELAY (nsec)
~
1
SOURCE: ADL
en
a:
«
..J
1
Figure 5-Price per logic gate versus speed (delay)
of present offerings against the gate circuit delay or
speed (Figure 5). This shows the enormous improvement achieved during the last five years in both lowered
prices and faster performance. A similar survey of
memory bit prices (Figure 6) also illustrates a dramatic
improvemen t.
..J
0
-u
C
w
a:
Q..
0.1
Price/performance index
0.01~-...I----"--'---'---""'"---
1
2
5
10
20
50
100
GATE CIRCUITS PER DEVICE CHIP
SOURCE: ADL
Figure 4-TTL logic price (1971) versus complexity
These classes of devices may be compared by means
of a price/performance index. The "present best"
figure is obtained by multiplying the price per bit or
gate function times the gate or access delay. The result
is a price/performance index number representative of
the cost per unit speed of the individual logic and
memory components. When plotted against time as in
Figure 7, it illustrates the dramatic improvement in
price/performance achieved by industry during the
late 1960s. It would be too much to hope that this
778
Spring Joint Computer Conference, 1972
COREO
SEMICONDUCTOR
F?z4 SCRATCH-PAD
1,4 v ») CONTROL & BUFFER
kV'i'"' MAIN
I:SS::] EXTENDED/AUXILIARY
0
10.00
en
a:
«
..oJ
1.00
..oJ
0
e
.10
I-
iii
a:
w
.01
0..
W
~
a: .001
0..
100
10
MICROSECONDS
100
10
NANOSECONDS
MEMORY ACCESS TIME
circuit could still be squeezed onto a silicon chip perhaps
Ys inch square. This development naturally also greatly
simplified the assembly of Minicomputers and of all
other types of electronic systems, as dozens, even
hundreds, of packages containing LSI circuits need
only to be mounted and further interconnected to
comprise a highly capable electronic computing system.
At present, more inventive applications are being
developed to capitalize further upon the circuitry
which can be included along with the conventional
serial logic of an integrated circuit semiconductor
chip. One example is the selection, multiplexing, and
decoding circuits which permit channeling appropriate
outputs of the LSI logic to the several communication
buses that interconnect various portions of a
minicomputer.
A major part of the circuitry of every minicomputer is
concerned with memory. Cores were initially used for
this function, but a considerable number of integrated
circuits were needed to perform the addressing, drive,
and sense functions necessary for utilizing core with a
few thousand words. At present, LSI semiconductors
are becoming price competitive with core memories
SOURCE: ADl
Figure 6-Memory component price versus speed (access time)
revolutionary trend will continue for the next five
years; nevertheless, we expect considerable further
improvement on which to base new component offerings, even though we have barely begun to utilize all of
the performance now available from LSI circuits.
~~--------~------------~100
->«-
(j
..J
Q)
w
III
c:
><
C
><
CI)
10 a:
CI)
a:
«
«
..J
..J
..J
..J
APPLICATIONS TO MINICOMPUTERS
0
o
e
C
X
X
The earliest applications of LSI have been in logic.
This has usually entailed straightforward translation of
the transistor circuits of the earliest minicomputers to
integrated circuits and now to LSI. Thousands of transistors are normally manufactured by the semiconductor producer on a single wafer and then cut apart
and packaged individually, only to be wired together
again on a circuit board. In the innovation of integrated
circuits, the interconnections are placed over the
transistors. The wafers can then be cut into groups of
devices that are already interconnected internally.
With more recent improvements in semiconductor
technology, these groups or circuit functions of the
integrated circuit were not cut apart but were further
integrated and interconnected on the same silicon chip,
leading to large-scale integrated circuits or LSI. The
masks also had to be shrunk so that a complex LSI
w
w
~ 10-9r---------~~~~-------~wa---~ 1
C
w
(.)
z
w
z
(.)
z
«
«
~
~
a:
a:
0
o
u.
(.)
-
a:
0..
~ 1(f10~------_+-----..:::IIioOiiIII'""--_I 0.1 a:
w
W
0..
0..
W
W
(.)
a:
0..
0.01
1975
SOURCE: ADL
Figure 7-Price/performance index
Approaching the Minicomputer on a Silicon Chip
TABLE II-Implementation of Small Computing Machines
with Logic Circuits
Avg. no. of Circuit
Functions
TransisIC's
tors
1965-66 1970-71 Increase
Small computer 10,000 30,000
2,000 5,000
Minicomputer
Terminal
1,000
600
(simple)
200
300
Desk
calculator
1:3
1:2.5
1:1. 7
1 :1.5
No. of LSI and
IC Device
Packages
1970-71 Decrease
1,000
100
30
10:1
20:1
20:1
3 66:1
(soon 1) (200: 1)
(Figure 6) and with their associated interface circuits for
memories of a size suitable for minicomputers. Thus, in
the future, semiconductor memories are likely to be
used extensively. However, a somewhat different
systems organization will be necessary to allow for the
refresh and access or cycle timing required for dynamic
M OS memories.
Serial shift registers and read-only memories are
also being used in addition to random-access semiconductor memories. The most recent trend we have
observed is the inclusion of specialized ROM devices to
provide fixed microprogramming or look-up tables for
special functions and sequences.
779
The considerable reduction in package count attainable through the use of LSI semiconductors is shown
in Table II. Between 1965-66 and 1970-71, while
the functional complexity of minicomputers at least
doubled, the actual package count of comparable
machines decreased by a factor of 20 through the aggressive inclusion of LSI circuits for most electronic
functions.
Figure 8 illustrates the number of circuit functions
generally utilized in minicomputers and various other
classes of equipment at a given time. Of course, considerable variations from this generalization are sometimes encountered. The ensuing count of logic and
memory LSI packages is projected into the future in
10,000
(I)
w
u
5 1,000
w
o
u
a:
o
en
-J
100
u.
o
a:
w
10
en
:E
:::>
2:
~
1 , 0 0 0 . 0 0 0 . - - - - - - - - - - - - -......
1
1970
2:
w
:E
Q..
1975
SOURCE: ADL
:::>
ow
Figure 9-Lower limit of LSI and IC devices in minicomputers
a:
w
Figure 9. This figure, however, presents a rather
optimistic situation on the assumption that available
LSI technology is utilized fully with custom circuits. As
this assumption is not always economically justified,
actual machines may lag this curve and use more but
simpler standard integrated circuit devices to achieve
interfacing and control with integrated circuits and LSI
circuits already available.
Q..
en
2:
o
10,000
~
U
2:
:::>
u.
~
:::>
u
a:
u
Ie
LSI
100~------------~-----------1960
1970
SOURCE: ADL
Figure 8-Functional complexity of computers
1980
TECHNOLOGICAL IMPLEMENTATION
Since· the initial development of simple integrated
circuits, a number of processes and circuit technologies
780
Spring Joint Computer Conference, 1972
have been adapted to semiconductor integrated circuits
and more recently to LSI. During most of the decade,
bipolar integrated circuits were fabricated using planar
diffusion processes. Logic circuits developed from resistor-transistor logic (RTL) to diode-transistor logic
(DTL), transistor-transistor logic (TTL), and now, for
the fastest speed, emitter-coupled logic (ECL) or
common-mode logic (CML). For a considerable time
to come, TTL will be the most popular bipolar technology for minicomputers, as it is available in a wide
range of devices at reasonable speed and low price. 1Vlost
recently, several process variations, such as "collector
diffusion isolation," are being developed to a practical
status to provide lower cost bipolar devices for simpler
processes, albeit at somewhat lower speed.
Since 1965 a form of transistor other than the bipolar
transistor, termed the metal-oxide-semiconductor transistor (MOS), has been developed for practical applications in silicon devices. As now implemented, the
various forms of MOS technology have a smaller
cell area for each function and require fewer processes
for manufacture (which leads to higher yields), but
they are slower than bipolar integrated circuits. Thus,
MOS is exceedingly well suited to LSI, and especially
to economic use in minicomputers.
Initially, most MOS devices used the P-channel
process; now a few memory circuits use the more
difficult N-channel process giving higher speed, and a
complementary (C-lVIOS) structure utilizing both Nand P-channels has been perfected. The latter, while
somewhat more expensive to fabricate than P-MOS,
nevertheless is expected to be cheaper and a little
slower than TTL. C-JVIOS is especially attractive for its
low power drain and high noise immunity. Thus, it
may well become the preferred device of the future,
promising a good compromise in optimizing price/
performance trade-offs among different semiconductor
technologies.
11VIPLICATIONS
The present impact of LSI is a restructuring of the
organization and pgrtitioning of minicomputers. To
arrive at a useful architecture, the minicomputer must
be partitioned according to the availability of LSI
circuits and the efficient use of these building blocks
throughout the minicomputer, as well as to preserve
compatibility with programs previously used. Four
directions are observable at this time:
Intermingling of memory and logic. Each LSI
semiconductor memory circuit can now be basically
self-contained (with address, decoding, drive, and
sense circuits where needed) in an economical size.
This circuit will also include chip-select for power
control or input selection as well as output busing
or multiplexing control. Thus, the semiconductor
memory circuit can be placed within this system
wherever it is needed, not where the economics
of core circuits sharing such peripherals dictates.
Utilization of high internal communication speed.
Because a minicomputer does not need to operate
at the highest speed of large machines, it can
benefit somewhat from the speed/price trade-off.
The great improvement in price/performance index
of both LSI logic and semiconductor memory can
provide much more capable small computers
containing only a few functional blocks. Furthermore, as this index at a given time is relatively
insensitive to the particular speed and performance
compromise, a relatively few high-speed memory
and logic circuits used serially may be as economical
(in terms of component cost) as a larger number of
slower components having longer delays. This
permits trade-offs between hierarchical memory
levels and shared high-speed logic against larger
parallel or interleaved logic and memory circuits
to obtain a structure most suited for specific
application.
Use of read-only memories and programmable
ROJl,f's "firmware." This is now the case even in
minicomputers. Microprogrammed memories and
array logic are especially simple to implement in
the short word lengths that suffice for minicomputers. The same reasons of short word length
might even lead to consideration of contentaddressable memories in future special-purpose
computers, whereas such memories are still much
too complex for use in general-purpose machines
having long words and large instruction sets. In
short, the present size of LSI logic and memory
arrays is ideally suited to the design of small
computing systems.
Further reduction of package count. With the
development of a wider range of LSI to implement
all functions or subsystems desired for minicomputers, a further drastic reduction of package
count can be projected. We anticipate that
minicomputers will be designed in the future with
as few as 10-20 LSI complex circuits for all memory,
logic, and control functions, yet which have
capabilities exceeding their present counterparts.
Approaching the Minicomputer on a Silicon Chip
Already we have seen electronic calculators
shrunk to a single LSI device. A four-bit microcomputer that uses as few as four different single
LSI devices is now available, and we should soon
see further applications of semiconductor
LSI to the next generation of highly compact
minicomputers.
REFERENCES
1 B AGUSTA
A 64-bit planar double-diffused monolothic memory chip
ISSCC Digest of Technical Papers Vol 12 pp 38-39 1969
2 Annual supplement of computer characteristics quarterly
Adams Associates Inc Bedford Mass 1968
3 J K AYLING R D MOORE
Monolithic main memory
ISSCC Digest of Tech Papers Vol 14 pp 76-77 Feb 1971
4 J K AYLING R D MOORE G K TU
A high-performance monolithic store
ISSCC Digest of Tech Papers Vol 12 pp 36-37 1969
5 V A DHAKA
Development of a Mgh-performance silicon monolithic circuit
Intern'l Electron Devices Meeting Washington DC
Paper 11.1 Digest p 70 Oct 1970
6 W H ECKTON JR
Development of an EeL gate with a 300 ps propagation delay
Intern'l Electron Devices Meeting Washington DC Paper
13.2 Digest p 100 Oct 1971
781
7 Electronic market data book
Electronic Industries Association Washington DC 1971
8 F S GREENE JR N U PH AN
Megabit LSI memory system
ISSCC Digest of Tech Papers Vol 13 pp 40-41 Feb 1970
9 J A KARP W M REGITZ SCHOU
A 4096-bit dynamic MOS RAM
ISSCC Digest of Tech Papers Vol 15 pp 10-11 Feb 1972
10 W KROLIKOWSKI et al
A 1024-bit N-channel MOS read-write memory chip
Intern'l Electron Devices Meeting Washington DC
Paper 2.1 Digest p 16 Oct 1970
11 T MASUHARA M NAGATA N HASHIMOTO
A high-performance N-channel MOS-LSI
ISSCC Digest of Tech Papers Vol 14 pp 12-13 Feb 1971
12 R N NOYCE
The 4-bit microcomputer
Private communication 1971
13 R N NOYCE
A look at future costs of large integrated arrays
Proc FJCC Vol 29 pp 111-114 1966
14 W M REGITZ J KARP
A 3-transistor-celll024-bit 500 NS MOS RAM
ISSCC Digest of Tech Papers Vol 13 pp 42-43 Feb 1970
15 H G RUDENBERG
Large-scale integration: Promises versus accomplishmentsThe dilemma of our industry
Proc of FJCC Vol 35 pp 359-368 1969
16 H G RUDENBERG
The outlook for integrated circuits
Arthur D Little Inc Chap 3 p 19 1967
The external access network of a modular computer system*
by JESSE T. QUATSE, PIERRE GAULENE and DONALD DODGE
University of California
Berkeley, California
INTRODUCTION
system, specific measures are taken to prevent interprocessor communications through shared primary
memory pages. It was thought that subsystem integrity would be more easily protected if messages are
passed between processors through the EAN. In
general, separate computer systems can be interconnected by a network like the EAN if they are reasonably
close spacially, close enough to make high data transfer
rates economically feasible. For example, the computer
network at the Lawrence Radiation Labs at Livermore 2
satisfies this requirement. However, it does not necessarily require the availability and security features of
the EAN. One PDP-6 is used as a centralized switching
computer, a situation which will be seen to be contrary
to the PRIME architectural approach. A system more
similar to PRIME in some respects is the Burroughs
D825, 3 although it is not a computer network by the
definition we have adopted. Primary memory is the
medium for interprocessor communications; and an
external access network, called the "Automatic Input/
Output Exchange", is used for communications between
a facility pool and primary memory. The D825 and
PRIME share important design objectives, availability being one of them. The similarities are reflected
in the external access networks of the two systems.
However, there are major differences. They stem from
an additional objective of the PRIME system design:
to ensure date security to time-sharing users. This
leads to protection mechanisms described in the text
of this paper and to the fact that the PRIME processors do not communicate through primary memory.
Distances profoundly affect the channel capacity and
therefore the functional properties of a network. The
EAN is to be distinguished from the many networks
designed to operate over great distances. Some similarities do exist in the message formatting, as described
for the EAN later in the text. For example, the end of
message tag and the source and destination identifier
are not new. 4 However, these networks are constrained
to lower channel capacities. One very high capacity
A modular time-sharing computer system, called
PRIME, is currently under development at the University of California, Berkeley. Basically, PRIME
consists of sets of modules such as processors, primary
memory modules, and disk drives, which are dynamically reconfigured into separate subsystems. One
ramification of the architectural approach is the need
for a medium to accommodate three classes of communications:
(1) those between any processor and any other
processor,
(2) those between any processor and any disk drive,
external computer system, or other device in
the facility pool, and
(3) those between primary memory and any device
in the facility pool.
This paper describes the External Access Network
(EAN) which was developed for this purpose. The
EAN is specialized by certain PRIME implementation constraints. Otherwise, it is adaptable to any
system having similar design objectives, or to aggregates of independent computer systems at the same
site, which share a similar facility pool and which require system to system communications.
Such systems are computer networks in the sense
used by Bell and Newell1: that at least two computers,
not connected through primary memory, must communicate with each other through messages. Although
primary memory is a shared resource in the PRIME
* The views and conclusions contained in this document are those
of the authors and should not be interpreted as necessarily
representing the official policies, either expressed or implied, of
the Advanced Research Projects Agency or the U.S. Government.
This research was supported by the Advanced Research Projects
Agency of the Department of Defense under Contract no.
DAHCI5 70 c 0274.
783
784
Spring Joint Computer Conference, 1972
long distance network is based upon 1.5 Mbaud links,5
as opposed to the approximately 20 Mbaud links of the
EAN. The ARPA network uses more economic 50
Kbaud links. 6 Another distinctive feature of long distance networks is the way in which availability .is
achieved. In order to provide routing alternatives, the
ARPA network has a much more complex structure
than is necessary for the EAN. Also, the ARPA network uses the store-and-forward method to accommodate a non-fully connected structure. The EAN uses
a relatively simple structure and has no need to storeand-forward messages.
Thus, the EAN is significantly different from other
networks. The difference arises from differing design
objectives, principally the high channel capacity,
availability, and data security features of PRIME.
The design objectives of PRIME, and its implementation, are outlined in the text and related to the EAN.
The EAN structure and components are described.
Net"work control sequences are given and the results
are summarized.
SYSTEM ASPECTS
The design objectives most important to this paper
are high availability and high data security. Availability implies that the system remains in continuous
operation, suffering as little performance degradation
as possible, during the occurrence of any single hardware or software failure. The PRIME system represents an attempt to achieve high availability without
recourse to component redundancy.7 Instead, the
approach is to develop a modular system which utilizes
system resources as efficiently as possible, but which
is capable of continuous operation whenever individual
modules fail. In addition to continuous operation, the
system must be capable of maintaining data security
in the presence of hardware or software failures. By
data security, we mean that the data of anyone user
is protected from unwanted intrusions by any other
user.
The overall implementation is described by another
paper in this conference proceedings.8 In summary,
modules such as processors, primary memory, and disk
drives, are dynamically reconfigured into separate
subsystems while the system is running. One subsystem is designated to run the control monitor which
defines subsystem configurations by allocating and
scheduling system resources. Its processor is called
the Control Processor. The others are called Problem
Processors. Error detection mechanisms, distributed
throughout the system, enable the Control Processor
to reconfigure subsystems to exclude a faulty module.
When the Control Processor is suspected of faulty
operation, it is automatically replaced by one of the
fault-free Problem Processors. The loss of anyone
module thereby degrades system performance by, at
most, the loss of one subsystem.
The fault detection and system reconfiguration
capabilities both rely upon two hardware entities:
the primary memory map and the EAN. The map
serves to partition memory into non-overlapping sets
of pages, one set per processor. Subsystems are not
permitted to share pages because to do so would considerably complicate the methods used for insuring
data security. Instead, interprocessor messages are
passed through the EAN where various consistency
checks are thought to be more easily implemented.
Mechanisms necessary for the isolation of subsystems
must be built into the EAN.
An additional objective arises from the fact that the
EAN must ensure subsystem integrity while accommodating valid reconfiguration and valid message
flow between subsystems. Mechanisms are described
later in this paper which aid in the detection and isolation of failures which could lead to the penetration of
subsystem boundaries. The subject is treated separately
by another paper.9 Features which ensure availability
are described in broad terms here, with many implementation details being omitted. For example, the
switching characteristics of the EAN are largely determined by a unit called the Switch Matrix. In order
to circumvent catastrophic power failures, each circuit
card of the Switch Matrix is powered by a separate
supply. The loss of one supply removes one subsystem,
but no more. Full details on the Switch Matrix can be
found elsewhere.lO
Other design objectives and PRIME implementation
features effected the design of the EAN. Evolvability
is generally accepted as a desirable system feature. In
our case, evolvability assumes an added significance.
PRIME is intended to be an experimental system, a
computer laboratory for the study of various implementations of a basic architectural approach. Therefore,
the number and types of devices to be interconnected
by the EAN could not have been predicted with certainty at the outset. Our strategy was to establish
reasonable limits on the growth of the main resources,
and to strive for simplicity and generality at the EAN
interfaces. Readily available packaging hardware was
then chosen which permitted the EAN implementation
to meet or exceed the requirements determined by our
strategy.
Figure 1 shows the initial configuration of the
PRIME system. The main resources are primary
External Access Network of Modular Computer System
T
= interactive
terminal connections
Figure 1-A block diagram of the PRIME system
memory, processors, and secondary storage. In this
paper, we group resources in greater detail so that the
functional characteristics of the EAN can be better
understood. We distinguish between four kinds of
resources: primary memory, the processors, the interactive terminals, and the facility pool. The primary
memory resource includes the entire bank of MOS
memory modules,11 the memory maps, and the memory
part of the I/O control logic shown in Figure 1, although the latter two are physically housed in the
processor cabinets. The processor resource includes the
five META 4 processors,12 and all hardware dedicated
to the processors (for example, the processor part of
the I/O control logic shown in Figure 1). Current
plans call for the interactive terminals to be connected
directly to the processors, where characters are assembled and relayed to the Control Processor through
the EAN. All other resources are referred to in this
paper as devices of the facility pool.
The EAN has been scaled to the numbers of processors and devices ever to be found in the PRIME system.
Preliminary estimates of the balance of tasks between
Problem Processors and the Control Processor indicated
that one Control Processor can service approximately
four Problem Processors. With an initial system of
five processors, a failure in anyone results in a total
system degradation of 25 percent or less, an availability level which seems acceptable for our purposes.
For these reasons, we have permitted our packaging
785
constraints to limit the number of processors to eight.
Beyond eight processors, plug-in expansion is no longer
possible; but the next eight require only minor redesign. Each processor has been provided with three
independent connections to the EAN. Typically, two
will be used to control on-going transfers between
primary memory and two independent disk drives. The
third remains available for interprocessor communications or for communications with other devices within
a subsystem. Thus, an eight processor maximum implies a maximum of 24 EAN nodes to be dedicated to
processors.
A system with eight processors is estimated to require
no more that 20 disk drives of the CDS 215 class. 13
Other devices currently planned for the facility pool
include magnetic tape units, a time of day clock, a line
printer, and three other computers: an XDS 940, a
PDP-5, and a Datapoint 2200. The extensive language
repertoire of the XDS 940 on campus will be accessed,
at least initially, by means of a 50 Kbaud link to the
EAN. The PDP-5 will be used as the processor for a
graphic terminal. The Datapoint 2200 is part of the
PRIME maintenance and measurement system. Thus,
at least 26 devices can be counted. In addition, as will
become apparent later, communications between
PRIME subsystems require at least one EAN node
which otherwise would be used for devices. Therefore,
the packaging constraints were permitted to limit to
32 the number of EAN nodes dedicated to devices in
the facility pool.
PROCESSOR
NODES
m,,;
24
n ,,;
31
SWITCH
NODES
A FREE SWITCH NODE
DEVICE
NODES
MULTIPLEXORS
Figure 2-The structure of the EAN
786
Spring Joint Computer Conference, 1972
THE EAN STRUCTURE
24 PROCESSOR NODES
The EAN has the very simple structure shown. in
Figure 2. Each path through the EAN consists of two
terminal nodes linked together by a switch node. Terminal nodes serve the purpose of attaching devices to
the EAN. A device can be attached to more than one
terminal node; but each terminal node is attached to
only one device. As explained in a later section of the
paper, this device can be a multiplexor which interfaces
several devices. Terminal nodes are designated as
either device nodes or processor nodes. Each device node
is attached to one switch node. Switch nodes which
are not attached to device nodes are called free switch
nodes. Each processor node is attached to all switch
nodes, but at anyone time, at most one switch node
can be selected by anyone processor node.
A link between a processor node and a device node is
established by the processor node selecting the corresponding switch node. A link between two processor
nodes is established by both processor nodes selecting
the same free switch node. The partitioning into subsystems, and therefore the establishing of links within
the EAN, is determined by the Control Processor.
However, the dynamic designation of the Control
Processor prevents the selection of switch nodes from
being done by one centralized control node. Distributing
the selection control over all processor nodes makes it
necessary for the Control Processor to specify which
switch node a Problem Processor should select. Mechanisms are built into each terminal node to guarantee
that the Problem Processor has made the correct connection. Therefore the Control Processor retains control
of the EAN and acts as if it were the only processor
which could establish links. The distinction between
processor nodes and device nodes is made for economic
reasons. Not all terminal nodes need to provide switch
node selection logic and the hardware cost is not
negligible.
THE EAN TERMINAL NODES
As is suggested by Figure 3, terminal nodes consist
of one, two, or three ports. Each serves a different
function. A terminal node is customized to a processor
or a particular device by the choice of ports to be included in it. In general, every processor and device is
considered to be a collection of registers interfaced to
the EAN, usually including at least the equivalent of
registers for data input, data output, instruction input,
and status output. The interfaces are simplified by
r~--------~A~--------~
PROCESSOR NODE
, - -_ _~A'__ ____.,
CIRCUITRY FOR
SELECTING ONE OF THE
SWITCH NODES
SWITCH {
NODE
n
---------,.,c--f-H-----J-----+-----,
SWITCH
NODES
DEVICE
NODE
SEPARATE POWER SUPPLIES
FOR EACH SWITCH NODE
Figure 3-Components of the EAN
providing the Standard Message Port (SMP) for register
to register transfers. The SMP transfers single words,
having fixed length and format. A word may be directed
to or from registers within the SMP itself, for purposes
of error detection and reporting. All terminal nodes
haveoneSMP.
A terminal node mayor may not include a Block
Transfer Port (BTP) for transfers between primary
memory and devices in the facility pool. The BTP has
no fixed word length, transmission format, or error
checking capability. Consequently, more complexity
is required of an interface to the BTP; but fewer constraints are placed on its design. The purpose is to
provide a network channel which has a very high
channel capacity and a wide range of operating characteristics. Very high data transfer rates are necessary
in order to accommodate disk transfers. A wide range of
operating characteristics are necessary because the
device controllers of PRIME are not centralized at
the devices. In general, the controller logic resides
partially at the device and partially in the memory
channels. The controller micro-code resides in the
micro-code of the processors. Distributed controllers
are preferred to centralized controllers for economic
reasons. Memory channels and processor micro-code
can be shared by all devices.
Each processor node has one Call Control Port
External Access Network of
(CCP) which is used to select switch nodes, as previously described. The following sections outline the
functioning of each port.
Call Control Port (CCP)
A link between a processor and a device is created
by the selection of the appropriate switch node through
the Call Control Port of the processor node. Two
processors create a link to each other by individually
selecting the same free switch node through their own
Call Control Ports.
The CCP has one more function: to disconnect a
processor node from all other nodes. In effect this
operation selects a non-existent free switch node.
Block Transfer Port (BTP)
The number of signal lines connecting two terminal
nodes must be as small as possible because the number
of decoding, driving, and receiving gates increases as
the product of the number of processor nodes and the
number of device nodes. The BTP was chosen to be
2-bits wide, the minimal width which provides the
desired generality and channel capacity. Transmission modes can be full-duplex with one line devoted
to each direction, half-duplex with data on one line
and clock on the other, or half-duplex two-bit parallel
with clock and data interspersed. Maximum transmission rates are expected to be 20 Mbauds total
including clock. This capacity is approximately one~
third of the· primary memory speed.
In PRIME, a BTP is used to transfer data between
primary memory and disk drives of the CDS 215 class.
The channel capacity of each drive has been doubled to
5 Mbauds (data) by accessing two surfaces in parallel.
One head transfers words with even addresses on one
line while the other head transfers words with odd
addresses on the other line. These words are accessed
from primary memory asynchronously for each line,
thereby greatly reducing the effect of the skew between
surfaces caused by interchangeable disk drives and disk
packs. The half-duplex double frequency transmission
mode is used to transfer data to and from the disk
drives, in order to maintain head independence all the
way to primary memory.
Standard Message Port (SMP)
The SMP accommodates register to register transfers
by sending the 52-bit SMP word shown in Figure 4.
IE
I
~Iodular
1
~
40-BIT WORD
32
PARITY BIT
Computer System
1
DATA
Ii
I
~
~
1 1 sol",
SOURCE ADDRESS
DEALLOCATION BIT
MULTIPLEXOR ADDRESS
BIT
1
Ilo
l
787
Figure 4-The 40-bit SMP word and 12-bit appendage
As with the BTP, similar considerations led to a 2-bit
transfer path for the SMP. Information is transmitted
bit serially on one line, using double frequency encoding. The other line is used to receive synchronization signals or messages from the SMP at the other
end.
The 40-bit word corresponds to the 40-bit parallel
path of an interface to a SMP. The implementation of
the META 4 makes 40 bits convenient, although other
word lengths would be acceptable. This word includes
a data field and a multiplexor address field which
suggests the general structure of an interface to the
EAN. Terminal nodes are attached to multiplexors
which channel SMP messages to addressable registers
of the same or of different devices. In effect, the multiplexor address is the address of a register interfaced to
a SMP. Registers controlled by fixed sequential circuits
can recognize or generate only their own addresses.
Registers controlled by processors can deal with any
address. The I/O bit of this address is separably distinguishable. It specifies whether the addressed register
is an input or an output register. Therefore, the sending
SMP can expect a response message within a fixed
time duration if the message is addressed to an output
register. This feature was added to the Sl\tlP for efficiency. Some other timing source would work as well,
but more processor time and control storage would be
required. The lack of a response is a detectable failure
mode.
One of the main concepts involved in the design of
the SMP is transparency of the network. This concept
is reflected in the fact that anything relevant happening
at one port is reported in some way to the other port.
This includes synchronization as well as error detection. The shaded fields shown in Figure 4 are generated
and used by the EAN for that purpose.
The sounding field precedes the message and is used
to alert and synchronize the receiving S~IP. An error
is detected if the receiving SMP is in transmitting
mode. A message received error free causes a signal to
be sent back to the transmitter. Another signal is re-
788
Spring Joint Computer Conference, 1972
turned to the transmitter when the addressed device
picks up the message. The absence of either signal is
detected as an error. All errors detected by the SMP
of a processor node are reported to the processor as a
standard 40-bit message having a special multiplexor
address which identifies error messages. All errors
detected by the SMP of a device node are transmitted
to the SMP of the processor node where they are reported in a similar fashion. Therefore the loss of messages by collision or overlapping is either avoided or
reported as a failure mode.
A parity bit is appended by the transmitting SMP
and checked by the receiving SMP. In addition, the
receiving SMP checks the format of the bit stream
(number of clock pulses and time interval between
them). These two simple checks, with double frequency
encoding, detect a larger class of errors than without
double frequency encoding. The probability is extremely small that error bursts will complement an
even number of data bits without effecting intervening
clock pulses. The failure of any of these checks is reported as an error. It should be noted that we chose to
provide checks on a message basis. Longer messages
which are made up from several SMP words may
require other checks at the process level (like checksums) to guarantee the contents of the total message.
The error mechanisms described above prevent loss
of information by distortion of message contents or by
message loss. Another mechanism has been introduced
to protect against transmission of messages to the
wrong terminal node. The integrity of a link through
the EAN is ensured by two addresses available at the
terminal nodes. Each SMP has its own unique wired-in
source address which is appended to each transmitted
message. In addition, each SMP has a Source Comparison Register which is loaded as part of the protocol
used to establish a link. It contains the source address
of the SMP located at the other end of the link. The
source address of an incoming message is checked
against the contents of this register. A mismatch causes
the message to be ignored and an error to be reported.
The Source Comparison Register is cleared by an
incoming message having the de allocation bit on. Only
the Control Processor can substitute a zero source
address for the wired-in source address of the SMP to
which it is attached. Thus the clearing of the Source
Comparison Register returns the usage of the terminal
node exclusively to the Control Processor. The loading
of the Source Comparison Register of a device node
is possible only with a zero source address message.
Therefore the protocol to establish a link between a.
processor node and a device node requires the intervention of the Control Processor. This mechanism
allows the Control Processor to retain control of the
EAN and to check that the Problem Processors make
correct connections. By the time a Problem Processor
is allocated to a subsystem, all of its nodes have selected
the non-existent switch node, thereby having disconnected the Problem Processor from the EAN. Thus,
a similar loading procedure cannot be used to set the
Source Comparison Register of a processor node. Each
Problem Processor must load its own register. It does
so, through the CCP, as part of the switch node selection operation. In addition, the cleared state of the
Source Comparison Register is indicated by a SMP
signal which is made available to the device controller. Any controller can have special checking features which distinguish between the Control Processor
and Problem Processors.
EAN CONTROL SEQUENCES
A presentation of all EAN control sequences is
beyond the scope of this paper. The examples represent typical communications within one subsystem,
and between different subsystems. They are simplified
by the elimination of steps that are required for higher
level system control, but not for EAN control. For
simplicity, SMP is not distinguished from the device
to which it is attached. Therefore each Problem Processor, PP, has a source address p; a device, D, is identified by its source address d; and the Control Processor,
CP, has source address o.
The first example allocates a device to a subsystem.
The Source Comparison Register of a free device is
assumed to hold the zero source address reserved to
the CPo A device is considered to be allocated whenever its Source Comparison Register holds the source
address of a PP.
Allocation of a free device D to a PP:
1-CP connects itself to D.
2-CP loads the address p into the Source Comparison Register of D with a zero source address
message.
3-CP receives an acknowledgment from the
SMP of D to verify that the Source Comparison
Register has been loaded correctly.
4-CP disconnects from D.
5-Eventually, by means of a processor to processor
communication, CP instructs PP to connect to
D.
6-PP connects to D and loads its own Source
Comparison Register with d.
External Access Network of Modular Computer System
A path between D and PP is now established, and
the transmission of messages can begin. The validity
of the path is checked by PP with the first message it
sends to D. If the terminal nodes of D and PP have a
BTP, then transfers to or from primary memory can
also be initiated. The form of communication necessary for initializing BTP transfers is generally a oneway stream of messages from PP to D. The memory
channel of PP must be independently instructed by
PP micro-code.
The next example is a control sequence which establishes a link between CP and PP by request of PP.
Two assumptions have been made. First, one free
switch node (N) is dedicated to interprocessor communications. (Consequently, only one pair of processors can be in communication at any time.) Second,
there is an interrupt channel (I), separate from the
EAN, which can be used by any processor to interrupt
any other processor.
Initiation of communications by PP:
1-PP interrupts CP through 1. This is a request
for communication. If possible, PP then continues to run its task while waiting for CP to
satisfy its request.
2-When CP is willing to communicate with PP,
it connects itself to the switch node N and loads
its own Source Comparison Register with p.
3-CP interrupts PP through 1.
4-PP then connects immediately to N and loads
its own Source Comparison Register with zero.
5-PP sends the first word of the message to CP,
thereby notifying CP that the link has been
made.
SUMMARY
The PRIME system can be viewed as a spacially
small computer network for which the EAN serves
two purposes: to interconnect subsystems, and to
interconnect devices within subsystems. The architectural approach represented by PRIME is reflected
in availability, data security, evolvability, and economic
features of the EAN. As a result, the EAN has both
similarities and dissimilarities with other networks.
Communications with subsystems are made possible
by very high channel capacities, a feature which distinguishes the EAN from spacially large networks.
Data security is accommodated by providing for subsystem to subsystem communications through the
789
EAN, instead of through primary memory, and by
detecting failure modes which might lead to penetration of subsystem boundaries. Availability considerations, as well as data security requirements, lead to
various error detecting and reporting mechanisms
which are built into the SMP. Other availability
features are the ability of the EAN to exclude faulty
modules by reconfiguring subsystems, the ability to
redesignate any Problem Processor as the Control
Processor, the limitation of the effect of failures, and
the network transparency which considerably eases
fault diagnosis. Economy considerations lead to the
construction of terminal nodes from three types of
ports, the provisions for distributed controllers, the
simplicity of the SMP interfacing, and the simplicity
of the EAN structure. Finally, evolvability is served
by plug-in expansion to 24 processor nodes and 31 device nodes, and by the multiplexor address field which
permits fan-out from each terminal node.
ACKNOWLEDGMENTS
The authors would like to thank R. S. Fabry, C. V.
Ravi, and particularly B. R. Borgerson for numerous
discussions and ideas which significantly influenced
the design of the EAN.
REFERENCES
1 G C BELL A NEWELL
Computer structures, reading and examples
McGraw-Hill Book Company Inc New York 1971 Chapter
40 pp 504-512
2 Livermore time sharing system
LRL Internal Document
3 J ANDERSON S HOFFMAN J SHIFMAN
R WILLIAMS
D825-A multiple computer system for command and
control
AFIPS Conference Proceedings Volume 22 pp 86-95 F JCC
1962
4 R SCANTLEBURY P WILKINSON K BARTLETT
The design of a message switching centre for a digital
communication network
Information Processing 68 North Holland Publishing Co
Amsterdam 1969 pp 723-727
5 D DAVIES
The principles of a data communication network for computers
and remote peripherals
Information Processing 68 North Holland Publishing Co
Amsterdam 1969 pp 709-715
6 L ROBERTS B WESSLER
Computer network development to achieve resource sharing
AFIPS Conference Proceedings Vol 36 SJCC 1970 pp
543-549
790
Spring Joint Computer Conference, 1972
7 B BORGERSON
A fail-softly system for time sharing use
P-12/CSR Computer Systems Research Project
University of California Berkeley
8 H BASKIN B BORGERSON R ROBERTS
PRIME-A modular architecture for terminal-oriented
systems
AFIPS Conference Proceedings SJCC 1972 Volume 40
9 J QUATSE P GAULENE
Fault protection in the I/O channels of a modular computer
International Computing Symposium Fondazione Cini
Venice Italy April 1972
10 D DODGE
Design of the switching matrix for PRIME
Master's Project University of California Berkeley
December 1971
11 B BORGERSON R FREITAS
The PRIME primary memory system
W-17/CSR Computer Systems Research Project University
of California Berkeley
12 Digital scientific META IV series 16 computer system
Reference Manual Publication Number 7032MD Digital
Scientific Corporation San Diego Jan 1971
13 Century Data Systems-Model 215 disk drive
Reference Manual RM215 Century Data Systems Anaheim
California
14 F HEART et al
The interface message processor for the ARPA computer,
network
AFIPS Conference Proceedings Vol 36 SJCC 1970
pp 551-567
An over-the-shoulder look at
discrete simulation languages
by IRA M. KAY
Southern Simulation Service, Inc.
The past of simulation languages resembles any other
history of a subject. For those interested in computers,
it presents an absorbing story with moments of outstanding achievement. When Shakespeare said "The
Past is the Prologue" he preceded the age of the computer, but he recognized tha.t, regardless of the field, the
history, the habits and the education of those engaged
in any enterprise shape the way the future will be. Accepting this hypothesis, it then behooves us to look to
the past if we are to see what the future holds in digital
discrete simulation.
Any practitioner of the art of simulation for a number
of years ca.n truthfully say that the past ten years have
been both fruitful and full. The term "fruitful" is used
in the sense that a relatively new art has been applied
to such a wide range of subje('ts. Mr. Stanley Reed of
IBl\I, in describing the applications to the attendees of
the First Animal Simulation Symposium in Tampa,
Florida in January 1968 gave a list of applicat.ions, and
they are repeated here as Appendix 1. Any art that can
serve this many fields must certainly be classified as
fruitful! "Full" is used in the sense that simulation
languages have proliferated as tools to serve the researcher. The author, in an invited paper for the Fifth
Annual Simulation Symposium provided an inventory
of general purpose digital discrete simulation languages.
After excluding any special purpose languages, and of
course, any digital continuous languages, there were
thirty-five inventoried and described. An alphabetical
list of the languages (augmented by later additions)
is contained in Appendix II, and demonstrates the
"fullness" of our past ten years.
One might ask why so many languages have appeared
on the scene, and wonder about their availability today.
The "why" is hard to explain, other than to say that in
many cases pride of authorship kept many going when
common sense should have indicated that other available languages would fulfill the needs. In other cases, a
simulation compiler was required for a specific computer, and the authors proceeded with what they felt
met the needs of the user and thus produced a new
language.
Regardless of the numbers, however, there is truly no
difference to the philosophy of how the languages work
for modeling and simulation. The basic alikeness of all
simulation problems is what provides a fertile field for
simulation languages. Each in its own manner has a
timing routine which keeps scheduled future occurrences
in chronological order, each advances a system held
variable representing the current tjme consistent with
the occurrences as their scheduled time is reached, and
each provides for the gathering of statistics concerning
the specific variables (values) the researcher might wish
to evaluate. Examination of the languages produced
reveals that there were three basic approaches to providing the simulation languages and almost all the languages fit into one of these three styles, or "families".
First, the authors took an existing scientific lan~uage
like FORTRAN or ALGOL and prepared sub-routines
to provide the user with the special requirements of
simulation languages, i.e., timing, set manipulation,
random deviate generation, statistical summary and
input-output. Then the user is able to write in the
"host" scientific language, calling the furnished subroutines for the special actions desired. This is a direct
method of getting the new user quickly into using
simulation languages, in fact, we can almost call it the
painless approach, and this ease of transition is the
strongest argument for using languages of this type.
This writer chooses to name this the GASP family,
after the best known of that type language. A "family
portrait" of these languages is:
GASP FAMILY
ESP (The Elliott Simulation Package)
FORSIM IV
GASP (General Activity Simulation Program)
HOCUS (Hand or Computer Universal Simulation)
791
792
Spring Joint Computer Conference, 1972
JASP (JOSS Conversational Simulation Program)
PA3
PROSIM (Program System for Shnulation)
QUICKSCRIPT
SIMON
SIMQUEUE
SPURT (A Simulation Package for University Research)
UNS
UNISIM
The second family of languages uses a logical block
design for describing the model to be simulated. This
means that blocks of certain shapes and identifiers call
for designated actions on the part of the computer.
Almost in a sign language then, a researcher can portray
his model, calling for the generation of transactions,
their path through a complex world, the capacities and
capabilities of the world through which it must pass,
the alternate solutions under blocked overloaded or
changed conditions, and still without, or with most
minor computer programming capability, the researcher
can simulate the world of his model. The compiler interprets the logical design and produces an operational
program, adding without demand a wide range of
statistical summarizations concerning the period of
simulation. This type of family must be called the
GPSS family, after the best known and most copied
language of all. A "group photograph" follows:
GPSS FAIYfILY
BOSS (Burroughs Operational System Simulator)
EGPS (Extended General Purpose Simulator)
FLOW SIMULATOR
GESIM (General Purpose Discrete Shnulator)
GPDS (General Purpose Discrete Simulator)
GPS (General Purpose Simulator)
GPS K (General Purpose Simulation K)
GPSS (General Purpose Simulation System)
GPSSjNORDEN
QUICKSIM
The last family of languages are those which provide
a syntax of their own and have the necessary compiler
capability to react to the simulation demands of the
user for all the aforementioned prerequisites of a simulation language. These type of languages require a programming expertise on the part of the user, but in turn
permit him the widest range of operation in dealing
with complex problems, and the most ability to tailor
his program to fit a particular problem. They are also
the most parsimonious in memory use and least costly
in running time. This group is called the SIMSCRIPT
family after the best known a;nd most widely used of
that type. They include:
SIMSCRIPT FAMILY
CLP (Cornell List Processor)
CSL (Control and Simulation Language)
GEMS (General Electric Marketing System)
GSP (General Simulation Program, Mark II)
MILITRAN
MONTECODE (Monte Carlo Coded Simulations)
OPS-3
SEAL (Simulation, Evaluation and Analysis Language)
SIMPAC
SIMSCRIPT
SIMTRAN
SIMULA
SOL
SOLPASS
SPS-1
All sorts of attempts have been made to "rank" these
languages, or to try to advise a reader that one language
would provide more capability than another. Other
papers have been written which provided detailed comparisons of several of the languages. Presumably, in
the latter case, the reader was to be in a better po~ition
to make a choice. In the opinion of this writer, all of
such effort is futile. First, the choice of a langua~e depends on an expert choosing among them, if all other
factors are equal, which rarely occurs. Next, the choice
depends upon the language in which the researcher can
program. There is no virtue in a choice which cannot be
utilized by the programmer, or at least, acquired by him
within a reasonable time. Last, there is the question of
compiler availability. Given a choice of one language
over others, and given that the researcher is capable in
that language, what earthly purpose is served if a compiler for that language is not available within a reasonable range of the intended user?
It has been the sad experience of the author, in which
he is as much the culprit as the observer, that those who
discuss several languages are rarely expert in more than
one and never in more than two. However, with great
pomposity, the "experts" discuss what each of several
languages can, and cannot do, displaying, by their errors
easily discernible by a real expert in anyone language,
that they have no real rig-ht to qualify or quantify that
language. If several "single language" experts could objectively discuss anyone paper which rates or ranks
Discrete Simulation Languages
languages, it is forecast that much air could be released
from the balloon.
To view these languages in retrospect has, in most
cases, a nostalgic charm. It is even more important to
now identify those which are still "active". With all due
respect to second generation computers that are living a
graceful old age in obscure universities, only those languages with compilers available on third generation
machines are listed.
Arranged by families, the current list is:
GASP Family
GPSSFamily
GASP
HOCUS
PROSIM
BOSS
EGPS
FLOWSIMULATOR
GESIM
GPS
GPSK
GPSS
GPSSj
NORDEN
SIMON
SIMQUEUE
SPURT
UNS
SIMSCRIPT
Family
CSL
SEAL
SIMSCRIPT
SIMULA
SOL
With a backward glance over our shoulder then, we
have every right to look to the future with confidence.
Any discipline which can invent at this prolific rate cannot but move forward with equal ability to formulate
tools for the future work.
REFERENCES
1 R P BENNETT P R COOKEY S W HONEY
C A KRIBBS M R LACKNER
SIMP A C user's manual, T M -602/000/00
Systems Development Corp Apri11962
2 J J CLANCYM S FINEBERG
Digital simulation languages, A critique and a guide
Proceedings, Fall Joint Computer Conference 1965
3 0 J DAHL K NYGAARD
SIMULA: A language for programming and description
of discrete event system
Users Manual Norwegian Computer Center 1965
4 D G EBELING
A general purpose conversational time sharing program
for probabilistic analysis
August 1969
5 J R EMSHOFF R L' SISSON
Design and use of computer simulation models
Macmillan 1970
6 G EHRLING
P ROSIM program system for simulation
DATASAAB-6361E 72.06.23 SAAB AKTIEBOLAG
Sweden 1966
7 E FAMOLARI
FORSIM IV, FORTRAN IV simulation language,
user's guide
The Mitre Corporation SR-99 February 1964
793
8 Flow simulator reference manual 70-00-617
RCA April 1969
9 General purpose simulation system/360 OS version 2,
users manual
IBM Corp SH20-0694-0 1969
10 GESIM user's manual, GES-1022
11 M GREENBERGER M M JONES J H MORRIS
D N NESS
On line computation and simulation: The OPS-3 system
The MIT Press 1965
12 Honeywell reference manual Order No 773 General
purpose simulator K
Apri11969
13 ICL reference manual 3386 1900 CSL
October 1966
14 ICL reference manual 4-138 Simulation language SIMON
January 1969
15 J KATZKE J REITMAN
Norden report 4-269R0003, user's guide to
conversational GPSS
December 1969
16 P J KIVIAT A A B PRITSKER
Simulation with GASP II
Prentice Hall 1969
17 P J KIVIAT R VILLANUEVA
H M MARKOWITZ
The SIMSCRIPT II programming language
R-360-PR
The RAND Corp October 1968
18 H S KRASNOW R A MERIKALLIO
The past, present and future of general simulation
languages TM 17-7004IBM Advanced Systems Development Division 1963
19 H M MAHKOWITZ B HAUSNER
H W KARR
SIMSCRIPT A simulation programming language
Prentice Hall 1963
20 Militran reference manual AD 601-794Systems Research Group Inc
21 T H NAYLOR
Bibliography on simulation and gaming
TIMS College on Simulation and Gaming June 19,68
22 A A B PRITSKER
J ASP: A simulation language for a time shared system
RAND RM-6279-PR June 1970
23 Proceedings of the Second Annual Simulation Symposium
Tampa Fla January 1969
24 Proceedings of the Third Annual Simulation Symposium
Tampa Fla January 1970
25 Proceedings of the Second Conference on Applications
of Simulation
New York 1968
26 Proceedings of the Third Conference on Applications
of Simulation
Los Angeles 1969
27 SI MT RAN reference manual
IBM SDD Dept B85 July 1965
28 Simulation, Evaluation and Analysis Language (SEAL)
system reference manual 360D 15.1.005
January 1968
29 D TEICHROEW J F LUBIN
Computer simulation-discussion of the technique and
comparison of languages
Communications of ACM Vol 9 No 10 October 1966
794
Spring Joint Computer Conference, 1972
30 D TEICHROEW J F LUBIN T D TRUITT
Discussion of computer simulation techniques and
comparison of languages
Simulation October 1967
31 F M TONGE P KELLER
A NEWELL
QUIKSCRIPT, A SIMSCRIPT-like language
for the G-20
Communications of the ACM Vol 8 Number 6 June 1965
32 UNS-Network simulator programmer's reference
UP 7548
1967
33 G A WICKLUND
SIMQUEUE-A queuing simulation model
College of Business Administration University of Iowa
Working Paper Series 69-13 July 1969
34 Xerox General Purpose Discrete Simulator (GPDS)
Sigma 5-9 computers Reference manual 90 17 58A
Xerox Data Systems April 1971
APPENDIX I
1. Advertising
A. J\lIedia selection
B. Impact on sales
C. Campaign strategy evaluation
D. Sales contests
E. Customer contests
2. Airlines
A. Runway utilization
B. Terminal facility planning
C. Crew scheduling
D. Reservation system modeling
E. Airliner seating and freight configurations
F. Spare parts inventory
G. Scheduling of service and maintenance facilities
H. Time tables
1. "Stack" modeling
J. Cargo handling
K. New airport facilities and locations
3. Banking
A. Operation of bank floor (teller model)
B. Behavior of on-line system
C. Check transit model:
1. Collection routes
2. Centralized vs. decentralized processing
3. Schedule arrival of inscriber operators
4. Breakpoint for specially handled items
D. Interest rate and other policy studies
E. Special service studies (credit card, payroll,
etc.)
4. City Planning and Urban Renewal
A. Transportation networks
B. Planning for services, facilities, etc.
C. Welfare studies
D. Crime and law enforcement studies
E. Budget planning
F. Information systems and record planning
5. Communications
A. Information flow in networks
B. Adaptive routing
C. Study polling disciplines, concentrators, buffering, etc.
D. Intercept and rating systems
E. Evaluate telephone information system
F. Maintenance and service facilities planning
G. Studies of future growth needs
6. Data Processing Systems
A. Response time, throughput analysis for realtime systems
B. Organization of direct-access files
C. Study queuing disciplines
D. Storage allocation and buffering
E. Study degraded performance
F. Study operating system behavior
G. Flow of jobs through a computer "shop"
H. Priority assessments
1. Equipment add-on effects
J. Personnel and organization studies
7. Distribution
A. Truck routing
B. Optimization of distribution networks
C. Number and location of warehouses
D. Warehouse automation procedures
E. Inventory management
F. Schedule work crews
G. Design truck docking facilities
H. Design packaging facilities
1. Information systems design
8. Elevator Operation
A. Number of elevators
B. Dispatching rules
9. Enterprise Models
A. Flow of material, men, money, information.
Evaluate all-over behavior-design for maximum profit. Policy studies at corporate levels
B. Effect of reducing delays (such as installation of
management information system)
C. Personnel rules
D. Advertising allocation
E. Capital investment
F. Diversification, merger and risk studies
10. Gaming (other than war games)
A. Management games
B. Purchasing games
C. Creation of sporting events ("dream world
series")
D. Training models
11. Insurance
A. Policy administration and accounting
B. Investment studies
C. Information and retrieval systems design
Discrete Simulation Languages
12.
13.
14.
15.
16.
17.
18.
19.
D. Statistical aging
E. New policy plans
Job Shop Simulation
A. Bottleneck elimination
B. Capacity-production studies (order backlog)
C. Work rules
D. Equipment evaluation and layout
E. Quality control
Manufacturing
A. Facilities planning
B. Assembly line balancing
C. Scheduling
D. Manpower allocation
E. Inventory management
F. Quality control
G. Information systems
H. Equipment maintenance
I. Subcontracting policies and schedules
J. Raw material acquisition
K. Plant location
L. Labor studies
Marketing
A. Pricing
B. Advertising
C. Sales force allocation
D. Product installation and acceptance
E. Competitive strategy
F. Product introduction studies
G. New product requirements
Medical
A. Behavior of real-time information system
B. Blood bank inventory
C. Admission/discharge policies
D. Hospital bed and patient scheduling
E. Scheduling of staff
F. Scheduling nurse activities
Metal Processing
A. Facility planning and scheduling
B. Warehousing
C. Ordering policies
D. Open pit mine design
Monte Carlo simulation of complex deterministic
problems
Paperwork Flow
Personnel Policies
20.
21.
22.
23.
24.
25.
795
A. Hiring and promotion rules
B. Allocation, distribution, and movement of
personnel
Proposals
Demonstrate new system feasibility to customer
Railroads
A. Yard operation
B. Network operations
C. Freight blocking strategies
D. Motive power assignment
E. Crew scheduling
F. Rapid transit-train scheduling
G. "Piggyback" studies
H. Equipment planning
1. Commuter rate studies
Reliability
A. Determine system availability
B. Spare parts requirements
C. Service crew and facility requirements
D. Economic batch size for quality
E. Failure rate studies
F. "Fail softly" systems-effect of duplexing
Shipping
A. Schedule port facilities
B. Schedule freighters, tugs, etc.
C. Cargo mix
D. Automation studies
E. "Fishybacks" and other competitive studies
F. Harbor design
G. Fleet composition
H. Labor practices
Traffic Control
A. Timing of traffic lights
B. Design turning rules at intersections
C. Test real-time control algorithms
D. Automated systems
E. Road planning
F. Safety studies
Trucking
A. Truck docking facilities
B. Scheduling
C. Routing and franchise studies
D. "Piggyback" and other competition
E. Rate studies
F. Information and retrieval systems
796
Spring Joint Computer Conference, 1972
APPENDIX II
General Information about Digital-Discrete Simulation Languages
LANGUAGE NAME
TYPE
DEVELOPING
ORGANIZATION
AUTHORS
COMPlITER
DlPIBMENTATION
DOCUMENTATION OR REFERENCE
BOSS
Process
Burroughs
Roth, Meyerhoff & Troy
B5500, B6700
BOSS Applications Manual, Report lfo66099,
Burroughs Corp., Paoli, Pa., July 1970
CLP
Process
Cornell University
Conway, Maxwell & Walker
CDC 1604
CPL Preliminary Manual, Dept. of Industrial
Eng., Cornell U., Oct. 1963
CSL
Process
IBM(U.K.), Esso
Ltd., ICL
Buxton & Laski
IBM 7090, 7094;
1900 Series
ICL, ICL System
ICL Reference Manual 3386, 1900 CSL, Oct.
1966, and ICL Reference Manual 1105, CSL
EGPS
Process
Nippon Electric Co.
Ltd.
Unk
NEAC Series
2200
NEAC Reference Manual, EGPS
ESP
Unk
Elliott Electric Co.
Unk
Elliott 503 &
803
Unk
FLOW SIMULATOR
Process
RCA CSD
Unk
RCA 3301
Spectra 70
Flow Simulator Reference Manual 70-00-617,
April 1969
FORSIM IV
Event
Mitre Corporation
E. Famolari
IBM 7030
Mitre Progress Memorandum SR-99, FORS 1M IV
FORTRAN IV Simulation Language, User's Guide,
E. Famolari, Feb. 1964
GASP
Event
U. S. Steel, Arizona
State U.
Kiviat & Pritsker
With appropriate
modifications,
any computer
with FORTRAN IV
compiler
Simulation with GASP 11, Kiviat & Pritsker,
Prentice Hall, 1969
4
GEMS
Event
General Electric Co.
Markowitz
Unk
Unk
GESIM
Process
General Electric Co.
Unk
HIS Sys. 600 &
6000 Series
GESIM User's Manual GES-l022
GPDS
Process
Xerox Data Systems
Unk
Sigma 5-9
Xerox General Purpose Discrete Simulator, Sigma
5-9 Computers, Xerox Data Systems, April 1971
GPS
Process
Nippon Elec. Co. Ltd.
Unk
NEAC Series 2200
NEAC Reference Manual, GPS
GPS K
Process
Honeywell, Inc.
Unk
Series 200
Honeywell Order No. 773, April 1969
(models 200/1200/
1250/2200/4200
GPSS
Process
IBM
Gordon and others
IBM 7090, 7094,
7040, 7044, System 360 UNIVAC
1107/1108/1110
General Purpose Simulation System/360 OS Version
2 Users Manual, SH20-0694-0, IBM Corp.
GPSS /360 NORDEN
Process
Norden Div. of United
Aircraft Corp.
Katzke & Reitman
IBM System 360
w/2250 Display
Unit
Norden Report 4269R0003, Users Guide to Conversational GPSS, December 1969
Discrete Simulation Languages
797
APPENDIX II (Cont'd)
LANGUAGE NAME
DEVELOPING
ORGANIZATION
TYPE
AUTHORS
IMP~:rr!~ION
DOCUMENTATION OR REFERENCE
GSP MK II
Unk
U. S. Steel Co. Ltd.
Unk
Ferranti Pegasus
Operational Research Report, !F1l8/0RD 10/ TECH,
1964
HOCUS
Event
P-E Consulting Group
Ltd.
R. Hills
Any with FORTRAN
compiler
HOCUS Manuals I & II
JASP
Event
RAND Corp.
Pritsker
JOSS Language
Computer (RAND
only)
RAND Memo RM-6279-PR, June 1970
MILITRAN
Event
Office of Naval
Research & Systems
Research Group, Inc.
Unk
7090, 7094
MILITRAN Reference Manual, AD 601-794, Systems
Research Group, Inc. (Clearinghouse)
MONTE CODE
Unk
Unk
Kelley, D. H. & Buxton, J. N.
Unk
i
I An
Interpretive Program for Monte Carlo S imu1a-
i tions, Computer Journal, V, 1962
OPS-3
PA3
Event
Unk
M. 1. T.
IOn-Line Computation and Sunu1atl.on
. . OPS- 3 ,
Greenberger, Jones, Morris &
Ness
Only with M. 1. T.
Time Sharing
CTSS System
General Electric Co.
Ebeling and Hurst
GE Mk II Time
Sharing
A General Purpose, Conversational Time-Sharing
Program for Probabalistic Analysis (PA3-1969
version of PAL), August 1969
I
Greenberger, et a1, MIT Press, 1965
PROS 1M
Unk
Data Saab
Unk
D21, D22
Unk
QUIKSCRIPT
Event
Carnegie Inst. of
Technology
Tonge, Keller & Newell
G-20
CODDIlunications of the ACM, June 1965
QUIKSIM
Process
~ationa1 Cash Register
Weamer
~CR 315 RMC
Proceedings of the Third Conference on the Applications of Simulation, December 1969
Simulation, Evaluation and Analysis Language
(SEAL), IBM System Manual, 360D 15.1.005
1"0.
SEAL
iEvent
IBM
Braddock & J)owling
IBM System 360
SIMON
Process
Bristol College of
Science & Technology
and ICL
~nk
jElliott 503, 803, ICL Reference Manual 4138, Simulation Language
ICL 1900 Series
SIMON, January 1969
SIMPAC
Process
ystems Development
Corp.
Bennett, et a1
IBM 7090, 7094
SIMPAC Users Manual, SOC TM602/000/00, Bennett
et a1, April 1962
Event
University of Iowa
Wicklund
IBM System 360
Working Paper Series 69-13, College of Business
Administration, University of Iowa
SI~UEUE
798
Spring Joint Computer Conference, 1972
APPENDIX II (Cont'd)
LANGUAGE NAME
AUTHORS
DEVELOPING
ORGANIZATION
TYPE
COMPUTER
IMPLEMENTA TION
DOCUMENTATION OR REFERENCE
SIMSCRIPT
Event
RAND Corp.
Markowitz, Hausner & Karr
IBM 7090, 7094
S IMSCRIPT, A S imula t ion Prograllmling Language,
7040, 7044, 360
Markowitz, Hausner & Karr, Prentice Hall, 1963
CDC 3600, 3800,
6400, 6600, 7600
UNIVAC 494, 1107,
1108, 1110, RCA
Spectra 70 series
NCR 200 series,
PHILCO 2000 series, HIS 615, 625
635, 655, 6030,
6040, 6060, 6080,
STANDARD IC-6000
SIMSCRIPT II
Event
RAND Corp.
Kiviat, Markowitz, Hausner &
Villaneueva
IBM System 360,
RCA Spectra 70
(object code
only)
S IMSCRIPT II - A Programming Language, Kiviat,
Villaneueva and Markowitz, Prentice Hall 1969
SIMI'RAN
Event
IBM
Braddock, Dowling and Rochelson
IBM 7030
Reference Manual, IBM, SDD, Dept. B85, July 1965
SIMULA
Process
Norwegian Computer
Center
Dahl & Nygaard
UNIVAC 1107, 1108 SIMULA - A language for Programming and description
1110, CDC 6400,
of discrete event system, Users Manual, Dahl &
6600, 6700, 7600 Nygaard, Norwegian Computer Center, 1965
Burroughs B5500,
B6000 series
SOL
Process
Burroughs Corp. &
Case Ins t. of Tech
Knuth & McNeley
Burroughs B5000/ SOL - A symbolic language for general purpose
5500, UNIVAC 1107 systems Simulation, Knuth and McNeley, 1963
1108
SOLPASS
Process
U.S. Army (Ft. MonArmstrong, Ulfers, Miller &
mouth) and Internation- Page
al Computer Sciences,
Inc.
Burroughs B5500
lInk
SPURT
Event
Northwestern U.
CDC 3400, 6000
series, IBM
~PURT Users Manual, Vogelbach Computing Center,
rorthwestern U.
UNISIM
Process
Bell Telephone Labs.
UNIVAC 1108
iuNISIM - A Simulation Program for COIDIIunication
Networks - Case 38931', Oct. 9, 1963
UNS
Process
UNIVAC
Mittman & Goldberg
• A. Gimpelson & J. H. Weber
~nk
~IVAC
490 series Network Simulator Programmer's Reference, UP 7548,
1107, 1108, 1110 1967
OSSL-A specialized language
for simulating computer systems*
by PREM BHUSHAN DEWAN
Mississippi State University
Starkville, Mississippi
and
C. E. DONAGHEY and JOE B. WYATT
University of Houston
Houston, Texas
INTRODUCTION
experiments on a model representing an abstraction of
the system. Simulation may take place only if a model
of the system under investigation is available.
As previously hypothesized, computer systems may
be represented in terms of components, variables,
parameters in conjunction with algorithms which
describe corresponding logical and functional relationships. However, the dynamic complexity of these
systems coupled with the desired level of detail, does
not facilitate the translation of these models into a set
of equations which are analytically tractable. N onetheless, it is possible to apply the description of the
computer system (model) to a given set of input to the
system. The manner in which the model reacts to this
input may be summarized in terms of the variables of
interest such as the time consumed by the management
functions and the fraction of the time the various
system components are busy. By varying the input
and/ or varying the model, an investigator can observe
the variables of interest and make appropriate decisions. The enormity of computations and the volume
of data involved, in investigating systems in this
manner, can be handled effectively if the model is
translated into a computer program. The validity of
this approach is evidenced by the simulation studies
conducted by Nielsen,16.17 Katz,6 Scherr,22 and Rehman
and Gangware 19 among others. These simulation
studies were reported to be successful. The building
of simulation models requires specialized skills and
time. These requirements act as deterrents for conducting generalized simulation studies of computer
systems.
There is a need in several areas for a mechanism that
enables the construction of working simulation models
(at several levels of detail) in relatively short periods
The need for evaluating the performance of contemporary computer systems is well recognized by the
manufacturers as well as the users of these systems.
The evaluation is difficult because of the complexities
and sophistication of the computer hardware and
software system design. The computer manufacturers
have produced an abundance of literature encompassing
somewhat subjective evaluations of their products.
Unfortunately, relatively little effort has been directed
by the manufacturer toward the development of
generalizable scientific tools for the purpose of a
quantified evaluation of the performance of computer
systems operating in a specified environment. The
need for such generalizable scientific tools for studying
the behavior of a given computer system in a specified
environment can hardly be over-emphasized.
Contemporary computer systems are, in general,
architectured from organized semi-independent processing modules which share a finite set of modular
resources. The performance characteristics of a computer system are partly governed by the characteristics
of the various modules and partly by the interactions
and interrelationships among these modules. A performance evaluation instrument for these systems
should provide an insight into the dynamics of the
interactions among the various components of the
system. This hypothesis strongly suggests simulation
techniques for investigating the behavior of computer
systems.
Simulation, by definition, is a process of conducting
* Some of the work leading to this paper was supported in part by
ONR-THEMIS Contract N00014-68-A-0151
799
800
Spring Joint Computer Conference, 1972
of time. Such a mechanism would not only be useful to
the designers and users of the computer systems as a
"quick-look" mechanism but would also have a significant pedagogical value. Students of operating systems
could gain in-depth knowledge through designing and
observing operating systems by the use of such a
mechanism.
In the development of the OSSL language and
simulator an effort has been made to provide the user
with the capability to represent all components of a
computer system including memories, processors, and
input-output systems in both an associative and a
hierarchical relationship. The OSSL language has not
been written for usage in areas other than computer
systems simulation and is intended to be limited to this
area of application. The known limitations of the
language lie in the representation of detailed discrete
phenomena such as a particular memory mapping
algorithm, a hybrid input-output algorithm, etc.,
although most, if not all, of these cases can be represented stochastically in considerable detail. A similar
effort has been made in OSSL to enable the representation of software processors and task sequences, stochastically, in sufficient detail and accuracy to provide for
the simulation of any specific computer system work
load.
THE SIMULATION LANGUAGE
This paper presents an overview of a language
developed for structuring simulation models of computer systems. A more detailed description of the
OSSL Language and its use is presented in a User's
Guide. 25 The various language elements reflect the
phraseology in use by those involved in the implementation of computer systems. The format-free
language has been implemented in a subset of the
FORTRAN IV language for the following reasons:
(a) FORTRAN IV is available on almost all
medium- to large-scale computer systems.
Special features of the language were purposely
avoided in the coding process to facilitate
usability on a variety of implemented systems.
(b) FORTRAN IV has the potential to accommodate
the flow oriented structure of GPSS, and also
the entity, attribute, set, state, and event
concepts of SIMSCRIPT.
(c) FORTRAN IV provides the facility to construct
adequate specialized data structures needed for
simulating computer systems.
(d) Implementation of the language interpreter is
much easier in a general purpose language like
FORTRAN, than in the special purpose simulation languages like GPSS, SIMSCRIPT,
SIMULA, etc.
(e) The simulator and the language interface have
been coded in FORTRAN IV in order to provide
user modularity. The various OSSL segments
have been represented via FORTRAN subroutines which are as accessible as provided for
by the particular FORTRAN compiler.
A simulation model for a given computer system
consists of components representing
(a) the hardware characteristics and system configuration,
(b) the operational philosophy of the system, and
(c) the environment in which the system is to
function.
The simulator employs the asynchronous timing
technique for advancing the model through the simulated time. This implies that the state of the system is
updated upon the occurrence of events. An event may
be the start of a new job, initiation/completion of data
transmission, interruption of a running program to
provide CPU service relative to a different user job,
etc. All the processes to be simulated are viewed as a
series of events. The updating. of the state of the system
consists in changing the simulation parameters as well
as the scheduling of future events induced by the event
causing the update. All future events thus scheduled
are filed in a threaded list. The events are retrieved
from the list in the order of their scheduled occurrence
of time for updating the state of the system. Such a
scheme positions events on the time line and the
updating mechanism relates the events to their respective processes, thereby enabling the handling of concurrent operation of the various processes.
The language described herein allows for a modular
construction of simulation models representing these
components. Each of the components may consist of
one or more segments provided by the language. The
three components of the model may be structured as
follows:
HARDWARE CHARACTERISTICS AND
SYSTEM CONFIGURATION
This component may be defined through the following
two segments of the language:
Central processing units (C p Us)
The CPUs are considered to be interruptible entities
capable of executing instructions related to a single
request at any instant of time. All requests for CPU
service have an associated priority level. The language
allows for the definition of up to 15 CPUs in the system.
OSSL
CPU DATA
CPU 1
QUEUE 7
UNINTERRUPTIBLE LEVEL 45
TIME QUANTUM .050
INSTRUCTION TIMES .00001 .000015 .00005
TABULATE BUSY TABL
END OF CPU DATA
Figure 1
Figure 1 shows an example of the CPU definition
segment. CPU numbered 1 is being defined. Requests
for CPU service are entered in the queue number 7 if
they cannot be met immediately.
The CPU goes into an uninterruptible state if the request being executed has a priority level of 45 or higher.
The time quantum is specified to be .05 units of time.
The CPU can execute one instruction each of class
1, 2 and 3 in .00001, .000015 and .00005 units of time
respectively. The language allows for up to 10 classes
of instructions. The time required for instructions
belonging to classes 3-10 is specified to be zero. The
continuously busy spans of the CPU are to be tabulated
in the frequency table labelled TABL.
Devices and channels
Characteristics of the peripheral devices like the
card-readers, card-punch equipment, teletypes, CR T
801
units, etc., are defined in this segment. The system
configuration is implied through the definition of each
device. Multiplexor channels are not to be included
since these are transparent to the simulation model.
This is because a multiplexor channel is always available
to the device controllers attached to it.
Figure 2 shows a sample definition of the segment.
The system configuration implied is shown in figure 3.
The characteristics of the CPU would be defined in
the CPU segment.
The segment, as defined, specifies one card-reader,
one line printer, one card-punch and two discs. The
strings TCR, TCP, Tl, T2, T3 and T4 are the labels
assigned to the user defined distribution functions.
Requests for the selector channel are to be entered in
queue 5 if they cannot be attended to immediately.
Similarly, requests for disc number 2 are to be entered
in queue number 3 if they cannot be attended to
immediately.
THE OPERATIONAL PHILOSOPHY
This component of the simulation model embodies
the manner in which the user jobs flow through the
system. The flow of jobs involves movement of data
among the system components, allocation of primary
memory, scheduling of jobs for execution and file
management functions. The manner in which these
DEVICES AND CHANNELS SEGMENT
TOTAL
CR
1
TOTAL
LP
1
TOTAL
DISCS
2
TOTAL
CP
1
DEVICE
CR 1
TRANSFER TIME TCR
DEVICE
CP 1
TRANSFER TIME TCP
DEVICE
LP 1
TRANSFER TIME Tl
DEVICE
DISC 1
SEEK TIME T2
TRANSFER TIME T3
SELECTOR CHANNEL 1
DEVICE
DISC 2
TRANSFER TIME T3
SEEK TIME T4
SELECTOR CHANNEL 1
QUEUE 3
CHANNEL 1
QUEUE 5
END OF DEVICES AND CHANNEL DEFINITION
Figure 2
802
Spring Joint Computer Conference, 1972
the bufferpool is disposed of in the following manner:
(a) User defined criterion are applied to the request
to determine if the request is to be met.
(b) Number of instructions (say n) to be executed
for applying the criterion are generated in
accordance with the user specified distribution
function.
(c) If the request is to be met, the number of
instructions to be executed (say m) for the
assignment of space are generated in accordance
with the user specified distribution function.
(d) If the request is not to be met immediately, the
number of instructions (say m) to be executed
to enter a specified queue are generated in accordance with the user specified distribution
function.
( e ) A CPU from the specified list is selected to
execute n+m instructions.
(f) The request is either met or placed in a queue
upon execution of n+m instructions.
Figure 3
activities are to be performed are defined by the
following segments:
Bufferpools
The language allows for the operation of up to twenty
bufferpools numbered 1 to 20. A request for space in
Figure 4 shows a sample definition of the bufferpool '
segment. Bufferpool numbered as 1 containing 100
buffers of a unit space each is being defined. The
number of instructions for decision, assign, refusal and
release activities follow the user defined
BUFFERPOOL DEFINITION
BUFFERPOOL 1
FIXED SIZED BUFFERS
NUMBER OF BUFFERS 100
SPACE 100
INSTRUCTIONS FOR DECISION DISA MIX MXA
INSTRUCTIONS FOR ASSIGN DISC MIX MXA
INSTRUCTIONS FOR REFUSAL DISC MIX MXA
INSTRUCTIONS FOR RELEASE DISD MIX MB
CPU 1
INTERRUPT LEVEL FOR ASSIGN 92
INTERRUPT LEVEL FOR RELEASE 92
DECISION RULES FOR BUFFER SPACE
ASSIGNMENT
FILE IS USING LESS THAN 3 BUFFERS OR
AT LEAST 1 BUFFER AVAILABLE FOR EACH FILE
END OF BUFFERPOOL DEFINITION
Figure 4
distribution functions labelled DISA, DISB, DISC,
DISD. Requests for bufferspace are to be placed in
queue number 10 if they cannot be met. MXA and MB
are the labels assigned to the proportion of the various
classes of instructions to be executed by the CPU
number 1. The priority level for the CPU service
associated with the assignment and release of bufferspace has been specified as 92.
The request for bufferspace is to be met if the file
requesting space is using less than 3 buffers or at least 1
buffer is available for each file attached to the bufferpool.
Movement of data
Movement of data in the system is described via the
definition of one or more PROCEDURES. An example
OSSL
of a procedure is the set of activities associated with the
input of a job in a batch-processing system like the
XDS system SIGMA 7 symbiont and the IBM
System/360 SPOOL (DOS/360 POWER and OS/360
HASP).
The input procedure may consist in the movement
of the source statements from a card reader on to the
disc. This movement of data \vould involve various
activities like the request and assignment of bufferspace, activation of the card-reader, deposition of the
card image into a buffer, emptying of the buffer onto
the disc, release of the bufferspace, and update of the
various tables.
The various· tasks being performed by a computer
system under the direct control of its operating· system
may be grouped into procedures. These procedures are
activated by the services requested by a user's job. A
procedure consists of an ordered list of statements and
thus are flow oriented. The language provides 38
different statements for defining procedures. There are
803
statements to request system services like the movement of data, request/release of bufferspace, request
for CPU service via an interrupt, etc. Statements have
also been provided for the management of records in
files and interrogation of the attributes of files. The
language also provides statements for controlling the
flow within a procedure. The procedures defined by the
user are assigned unique labels. Individual statements
comprising the procedure may be assigned a label.
Some examples of the statements available are as
follows:
Statement:
MOVE TO DISC 2
Execution of this statement causes data to be moved
to Disc 2.
Statement:
INTERRUPT CPU 1 PRIORITY 95 QUANTITY A MIX MX
This statement generates a random value, say n,
from the user defined distribution function labelled A.
A request with a priority level of 95 is placed on CPU
1 to execute n instructions of the mix labelled as MX.
Statement:
REQUEST 1 FROM BUFFERPOOL 2
A request for space from the bufferpool number 2 is
generated and disposed of as prescribed by the user in
the BUFFERPOOL segment.
The statement gets executed only if a record is
available for reading.
Statement:
CHECK IF RECORD IN FILE, ET
The flow is transferred to the statement labelled ET
if the file is empty, otherwise the flow reaches the next
sequential statement.
Statement:
Statement:
INCREMENT DATA IN FILE 6 BY 2
ASSIGN FILE 6
The statement creates file 6 for the job being handled
by the procedure.
This statement increases the number of records in
file 6 by 2.
Statement:
Statement:
ATTACH FILE 8 TO BUFFERPOOL 1
REQUEST CHANNEL 1 2
This statement attaches file 8 belonging to the job to
the bufferpooll.
This statement is considered executed only when
either the selector channel 1 or the selector channel 2 is
made available to the procedure.
A sample procedure to mode input from a teletype
into the system is shown in Figure 5.
Statement:
CHECK IF RECORD READY
PROCEDURE IN
REQUEST 1 FROM BUFFERPOOL 3
MOVE FROM TELETYPE 10
INTERRUPT CPU 1 PRIORITY 90 QUANTITY A MIX X
TERMINATE
Figure 5
804
Spring Joint Computer Conference, 1972
shows a sample definition of the scheduler. A timeslicing system is specified. Jobs awaiting CPU assignment for the execution of code are placed in queue
number 7. CPU number 1 is to be used for executing
the code. The number of jobs under paging at any
time may not exceed 5.
SCHEDULER DEFINITION
QUEUE 7
CPU 1
JOBS ARE SLICED
MAXIMUM JOBS UNDER PAGING 5
END OF SCHEDULER DEFINITION
Figure 6
Memory management
Job scheduler
Assignment of CPU for executing the code specified
by the user's job is handled by the job scheduler. The
model provides for the simulation of batch-processing,
time-sharing and multiprogramming computer systems
by an appropriate definition of scheduler. Figure 6
This segment is for the purpose of defining the
various parameters as well as the decision rules to be
used for allocating primary memory to the various
jobs. A sample definition of the memory management
functions is shown in Figure 7. The primary memory
consists of a single partition
MEMORY MANAGEMENT DEFINITION
PARTITION 1
LAST PAGE OF THE PARTITION 512
RELOCATABLE CODE
GENERATE A SET OF PAGES AS FOLLOWS:
PAGE DOES NOT BELONG TO THE JOB REQUESTING PAGE
PAGE HAS BEEN ACCESSED AT LEAST ONCE
PAGE ASSIGNED FIFO
ROLL IN PROCEDURE RIN
ROLL OUT PROCEDURE ROUT
PAGES SWAPPED ONLY IF MODIFIED
END OF MEMORY MANAGEMENT
DEFINITION
Figure 7
containing 512 pages. All the user specified code is
relocatable. Pages not in use are used for meeting page
demands. If no such page is available, a set of pages is
generated. The pages belonging to this set have been
accessed at least once and do not belong to the job
demanding the page. The page that has been in residence the longest among the members· of the generated
set is selected for meeting the demand. A page is
swapped only if it has been modified. The rolling-in
and rolling-out of pages are in accordance with the user
defined procedures labelled RIN and ROUT respectively.
File management
CPU service, if any, in regard to the opening, closing,
attaching/unattaching of files during the execution of
procedures, is specified in this segment.
Figure 8 shows a sample definition of this segment.
The specifications imply that a request for CPU
service is generated if the files are opened, closed, and
attached/unattached. The number of instructions to be
executed by the CPU number 1 follow the distribution
function labelled INST. The priority level associated
with the request for CPU service is specified to be 97.
FILE MANAGEMENT
CPU 1
INSTRUCTIONS FOR OPENING FILES INST MIX S2
INSTRUCTIONS FOR CLOSING FILES INST MIX S2
INSTRUCTIONS FOR ATTACH/UNATTACH FILES INST MIX S2
INTERRUPT LEVEL FOR OPENING FILES 97
INTERRUPT LEVEL FOR CLOSING FILES 97
INTERRUPT LEVEL FOR ATTACH/UNATTACH FILES 97
END OF FILE MANAGEMENT DEFINITION
Figure 8
OSSL
805
THE ENVIRONMENT
in the block labelled EX is as follows:
This component of the simulation model embodies
the services that the system is called upon to perform.
The language provides for structuring the environment
in terms of jobs. Since the jobs require a variety of
system services, the language allows for the classification of jobs into numbered types. All the jobs belonging
to a particular type demand the same system services
in the same order. However, the amount of service
demanded by jobs of the same type may be different.
The services demanded by the job may be classified
into three categories, viz., entry of the job into the
system, computations as specified by the job and the
delivery of the computational results by the system.
Entry of the job, the delivery of the computational
results and the manner in which the computations are
executed is fixed by the design of the system (as represented via the hardware configuration and the operational philosophy) and is described by specifying job
steps relative to each type of job.
Pages 1, 3, 7, and 9, relative to the job are needed in
core before the code may be executed. Pages 3 and 7
will be modified as a result of the execution of the code.
The statement
Code
The computations to be performed are represented
by the code to be executed. The code may pertain to
the compiling, loading, and the job itself. The language
provides the facilities to specify the code to be executed.
The language allows for the structuring of the various
software processors from the user defined code.
The software representation is at a macroscopic level.
A software program to be represented is divided into
one or more "blocks." Each of these blocks contains the
instructions to be executed, the specific pages needed
in core for the execution of the block. In addition, the
block may also contain specifications on the pages
modified and the frequency with which the various
pages are accessed during the execution of the code
contained in the block.
A block is assigned a unique label so that a reference
may be made to it for the purposes of structuring software processors, specification of code for the user's
jobs and transfer of control during execution.
Figure 9 shows a sample definition of the code.
Three blocks of code labeled EX, ST, AND EX2 have
been defined. A brief explanation of the code contained
INITIATE READ 1 IC 3
implies that the procedure associated with the type 1
read is to be invoked. The number of records to be
read follow the distribution labelled IC and the file
number 3. is involved in the read statement. Control is
transferred to the next statement without awaiting the
completion of the read.
The statement
E READ 2 RDZ 5 ST
specifies that records from file 5 are to be read from file
5 in a manner defined by the procedure associated with
the type 2 read. The number of records to be read is to
be randomly generated in accordance with the distribution function labelled RD2. In case file 5 is empty,
control is transferred to the block labelled ST. Control
is transferred to the next statement only after the
read statement has been completed. E is the label
assigned to this statement.
The statement
COMPUTE COM MX
specifies that the CPU is to be requested to execute
instructions of a mix defined by the label MX. The
number of instructions to be executed are randomly
generated from the distribution function labelled COM.
The statement
WRITE 2 WT1 7
specifies that a number of records, randomly generated
from the distribution function labelled WT1, be written
into file 7. The manner in which the records are to be
written into file 7 is specified via the procedure associated with type 2 write. Control is transferred to the
next statement only after the write operation has been
completed.
806
Spring Joint Computer Conference, 1972
The statement
LOOP LE E
specifies that the statements
CODE DEFINITION
BLOCK
PAGES NEEDED 1 3 7 9
PAGES MODIFIED 3 7
INITIATE READ 1 IC 3
READ 2 RD2 5 ST
E
COMPUTE COM MX
WRITE 2 WT1 7
LOOP LE E
TRANSFER .4 EX 2
WRITE 2 WT2 7
ST
BLOCK
STOP
EX2
BLOCK
PAGES NEEDED 245 689 10
PAGES MODIFIED 4 8
READ 2 RD 6 ST
E
COMPUTE CA MP
WRITE 4 WT 8
JUMP .8 E
STOP
END OF CODE DEFINITION
INPUT/OUTPUT PROCEDURES
READ 1 PROCEDURE RDA
READ 2 PROCEDURE RDB
READ 3 PROCEDURE AD
WRITE 1 PROCEDURE W
WRITE 2 PROCEDURE RITE
END OF INPUT/OUTPUT DEFINITION
EX
Figure 9
starting with the one labelled E and ending with the
one before the LOOP statement are to be executed a
number of times randomly generated from the distribution function labelled LE.
The statement
TRANSFER .4 EX2
would result in the generation of a random value from
the uniform distribution over the interval (0., 1.). If
the value of the number generated is less than or equal
to .4, the control is transferred to the block labelled
EX2, otherwise the control reaches the next sequential
statement.
Input/output
The procedures associated with the different types
of reads/writes are declared as shown in Figure 10.
RDA, RDB, AD, W, AND RITE are the labels of the
user defined procedures.
Figure 10
Software processors
Software processors may be defined from the specified
code. A sample definition of a software processor named
FORT consisting of 31 pages is shown in Figure 11.
EXE is the label of a block of code.
SOFTWARE PROCESSOR
PROCESSOR FORT
STARTS AT EXE PAGES 31
END OF SOFTWARE PROCESSOR
DEFINITION
Figure 11
Code specifications for the jobs
The number of pages and the code of a job arriving
in the system is specified in the job list segment. Each
entry in the list contains the number of pages and the
reference to a label of a block of code. The job list is
subdivided. Each sub-list belongs to a different job
type. The sub-lists are circular and hence endless. Each
of the sub-lists has a pointer indicating the entry to be
used for assigning 'the number of pages and the code to
a job arriving in the system. The pointer moves to the
next entry after the current entry has been used.
Figure 12 shows a sample job list.
JOB LIST
Type 1
PAGES
PAGES
Type 2
PAGES
PAGES
143 STARTS AT BLOCK C1
78 STARTS AT BLOCK LA
47 STARTS AT BLOCK LB
43 STARTS AT BLOCK CN
END OF JOB LIST
Figure 12
OSSL
Job description
The job type is characterized by the specification of
the relationship between the various procedures and
processors. A job type is specified in terms of steps to be
executed sequentially. Each step consists in either the
execution of a procedure or the execution of code.
Figure 13 shows a sample job description.
JOB DESCRIPTION DEFINITION
Type 1
JOB STEPS ARE AS FOLLOWS:
PROCEDURE IN FILE 7 DEVICE 2
EXECUTE FO
EXECUTE LO
EXECUTE JOB
PROCEDURE OUT FILE 8
END OF JOB DESCRIPTION
Figure 13
IN and OUT are the labels of the user defined procedures, whereas FO and LO are the labels of the user
defined software processors.
The language embodies other elements for defining:
(a) the various distribution functions,
(b) the various frequency tables,
(c) the various cumulative distribution functions for
generating the job types,
(d) queue disciplines,
(e ) initial conditions,
(f) limits on the number of jobs in the system at any
instant of time, and
(g) other simulation parameters like the seed for
generating random numbers, length of a simulation run and the number of reports to be generated.
USE OF THE MODEL
Several simulation studies have been carried out to
check the operation of the generalized model. One such
case is included to serve as an example for demonstration of some of the uses of the generalized model. The
particular simulation study concerns an on-line enquiry
system as described on page 79 of the General Purpose
Simulation System/360: Introductory User's Manual,
IBM Inc., Form G H20-0304-4. A G PSS construct of
the enquiry system appears on pages 82-83 of the
807
referenced material. The on-line enquiry system was
selected for simulation due to its relative simplicity
and because of the availability of published results for
comparison purposes.
The experiment consisted of processing the OSSL
version of the basic GPSS model in order to verify the
similarity of the results. The OSSL model was constructed using as nearly as possible identical parametric
information to that assumed for the GPSS representation of the five teletype computer enquiry system. The
basic OSSL model is shown in Figures 14a, 14b, and 14c.
An explanation of various statement types may be
found in Reference number 25 (Wyatt & Dewan, 1971).
All the jobs arriving in the system require the same
set of services from the system. The only distinction
between jobs is the teletype number from which they
originate. This distinction was used to build the five
types of jobs that the model services. Jobs belonging to
type n implies that. they originated from the teletype
number n. Thus a job type 3 implies that the job
originates from the teletype number 3.
The job description segment defines the job steps
associated with each of the five job types. Each of the
five job types consists of a single step, viz., execution
of the procedure labelled ENQY. The specifications
imply that a job arriving in the system would cause the
activation of the procedure ENQY relative to this job.
The file associated with the procedure will be o. The
device number associated with ENQY would depend on
the type of the job. Thus if the arriving job is of type 2
the device number 2 would be associated with ENQY.
The priority associated with jobs is set to 101 due to
lack of specifications.
The Bufferpool Definition segment specifies that the
system is to contain a bufferpool numbered as 1. All the
buffers in this pool are of a fixed size. The total space in
the pool is 10 units divided amongst 10 buffers. Requests
for bufferspace are to be placed in queue 7 if they
cannot be satisfied immediately. Number of instructions to be executed by the CPU for the assignment and
release of bufferspace is specified as zero (by default).
Lack of decision rules specifications for the assignment
of bufferspace imply that the requests for bufferspace
are to be met if bufferspace is available.
The Initial Condition segment specifies that at
simulated time zero one job is to arrive in the system.
The type of this job is to be determined by the cumulative distribution function labelled J1.
The Simulated Time Specification segment specifies
that the model is to be operated for 1020000 units of
simulated time after which a report is to be generated.
Lack of the random number seed specification implies
that the system is to use the built-in random number
seed during the simulation process.
808
Spring Joint Computer Conference, 1972
f)
T1
St: VN
E XP
CON
C ON
C ON
CON
cRoe
U NT
~rFY
TFN
F TTN
ru NC
TI ON c;
SrJQ!)
Sn
1 [j
1 c:
Te::; TR Tq LIT 10 N
ON E~ T1 Al'
ST AN T
ST ANT
5T AN T
5T AN T
75
15 r 4S Q
E NO 0 F D1 ST RI 5U T1 ON FUN CT 10 NS
~O
RM
T AS lE S
40 C 50 Q 60 G 10 C 800
~ NO 0 F T A eL [S
T A BL
3C Ole ~'l
CUMULIl.T rVE CISTRISUTI 0'\
Jl
1
~UNC"'!"
1 SO 0
IONS
?S or: 2 58
FOR
• 2
2
•4
3.5
4.8
c ND () F JO B TV PE r. IS TQ I q 1fT" 10 ~,;S
e pu r AT A
e PO
Q
1
Uf UE
I Nc:
TR
6
ue TI aN
T 1M ~
1
UN: NT ER PU PT I8 L£ l fV El
EN C' Of C PU DAr A
9
~
D EV ICE D!:" ~ I N I Tl 0 N
TOT Al T EL ~: YP ~S
~,
D tV ICE Ti: L E TV PE
1
QUE UE
1
D EV ICE Tf.. LE TV PE
G UE UE
2
D tV Ie E TE LE TV PE
o Uf. Ut:
Ii
EV ICE
o UE UE
(' EV ICE
G UE UE
C HA NN EL
? Uf U~
:3
3
rr LE TV PE
4
4
T[
LE TY PE
:).
5
1
8
CHANNEL
o UE UE
L
2
S
E NI) 0 F DE VI CE D ':F IN IT lOt\'
Figure 14a-OSSL model
~
3000 3 SO C 4G DO
r; :::N ES A TIN G JO ES
5
1 .0
OSSL
ve: LIt S
Q
GU rU t:"
DR
PR TO RI TY
0 F GU E U E DE ~ I NT T rON ~
h
E Nf'
at: '="'D UP E
EN 0v
~
L f. PS f.
T1
S T.A PT NEW JOB
l CG T
Irv~
J 1
E
p [.~ UE ST
T El. E T y~ E
KEG UE ST C HA NN ~ L
1
FL AP SE F IF v
p~ QU EST
1
F 0" f,~
IN Tf RR UD T [0 U 1
o EL [A Sf C HA NN r::-L
I NT fR PU PT CPU 1
D1J F F [R PO Ot
'-'0
C HA t~N e- l
2
IN TF RR UP Teo U 1
10 Rl TV
1
eV:l
au AN TI
T~
TV
".j
;.t EG UE ~T
~ ~I
OR IT Y
EUF~EPPD0L
PELfASE 1
T0
EL .a P Sf
SE VF N
o El [: A SEC HA NN ~ l
f"L E4 Sr::: T t"L ET yo [
C !JL LF CT T p.A E IN T A)). LE
Tf oft" IN AT E
G U~NT IT y
1
h'
J 02
T yr::>
".8 t.
D [5 C £) IP TI ON
E
1
J 08 S TE PS
P PO CE i.'U Rr. .t
!:'"
VP
T
,.
2
J 08 S TE
p
T
,..
EN (.'V
FI l
EN '::iV
r I L ..
P:
EN 0V
L
-
i.-
PO CE ru R;:
EN Qy
F 1 L e-.-
os
PO CE eu qE
T YP E
G
DE. V! C=-:
1
G
C~VTCE
.{
DE VT CE
'
n
DE V! CE
4
Q
DE VI CE
5
3
J OR S Tt=' D<:"
r'P l:;?O Lt.
CU
I~
T yr [:
J 08
p
r
yo
I L
k.
....
4
r-
S TE p,
5
J 03 S
TE Ps
RO re- nu PE:
E.N 0Y
F rL
~ NC 1'1 F JC B ::f SC PI PT II') N
0
... 1....
'-
Figure 14b-OSSL model
r IT
~l
809
810
Spring Joint Computer Conference, 1972
TABLE II-Message Transit Time Distribution
[I~
? t.F FE P? .)') l
r::U FF 1='"0 t:'0 OL
r"r XE
Percent of Total
": cI 7f
'''U FU :-
A(
1G
f\'U MS FO C F BU
f:" "'JG 0 F
rr=- EP S 1 ':
?u Fr:- Fe? PO "l D EF I N IT 10 N
INI~IALlY
~~.I
n or
GENE!:?ATE: JQS~.
Jl
I NI T1 ,a L IZ AT 10 N
NU MR ~p 0 F RE PO RT S
1
~lJ MB [0. 0 F PE PO RT S
1
TI ~E gET WE EN PEP OR T5
C:::T
Interval
GPSS Model
Generalized Model
0-400
400-500
500-600
600-700
700-800
800-900
900-1000
1000-1500
1500-2000
2000-2500
2500-3000
3000-3500
3500-4000
over 4000
10.89
16.14
20.04
11.69
9.34
7.79
6.04
12.75
3.35
1.30
.21
.00
.04
.00
13.026
17.385
18.722
9.807
8.370
6.984
6.043
12.927
4.160
1.535
.545
.347
.149
.000
7
r.
~p
FI NT 11 ON
1
A<: ;:-'l.LOwS:
1020000
AR T <;I MU LA T1 ON
Figure 14c-OSSL model
The output generated by the generalized model is in
the form of a report shown in Figures I5a, I5b, and I5c.
The report contains the various statistics concerning
the teletypes, CPU, the selector channels, the bufferpools and the various queues.
It may be pointed out that the CPU service related
to interrupts is considered as overhead. Since all the
CPU services in the simulated system were represented
by interrupts, the generalized model reports that all
the CPU utilization was for overhead.
The results obtained by the generalized model are
essentially the same as those obtained by the GPSS
model. The equipment utilization as reported by the
two models is shown in Table I.
The total transit time distribution of the messages
as obtained by the two models is shown in Table II.
The differences in results obtained by the two models
may be attributed to sampling error.
Q:::V!
C::TAT IS
~~
T:C~
• ....... **** •• "'***.
:~v:!'
c:-
,
n~E
e.t; cy
T1
~E
M~ ~N
at;'; Y
I
~L'
SP 6 f<.!
S
°A~
TABLE I
1
EQUIPMENT
GPSS
Model
TERM1
TERM2
TERM3
TERM4
TERM5
CHANI
CPU
CHANO
CORE
Generalized Model
TTYP 1
TTYP 2
TTYP 3
TTYP 4
TTYP 5
CHAN 1
PROCESSING UNIT 1
CHAN 2
BUFFERPOOL 1
AVERAGE
UTILIZATION
GPSS
Generalized
Model
Model
.242
.231
.251
.266
.260
.118
.645
.177
.099
.2506
.2512
.2568
.2517
.2510
.1192
.6385
.1782
.1010
?S~;:;
28.
? 5. CC:?
~
S ~. '::: 1
TT Y?
2 7t: C.l 75.
~
5. 11<;
3B.4",
TT yo
3 ?=19SS.
2
t:.
08?
, 3';.97
t..'U "''3 ER
\1 ~ 6. "\
::l:U~Y
L sa:-.
~ll
3~
~'43'::. ~
~Mq;:':1
~,
;:"c.
FS "'!'"":
1.(
TI Vt TT
4~;
3
2421.
07
,"-
2 s. 177
~
2""':. l& ..,.
2' 43 :'.
'c
511
4
TTYD
2C: S??:::.
25. [9 eo
3 2~. 41
2 4f, 4.
I';:
~
sr 1
4 S,)
C~ANN~L
<:"fAT!STICS
4
?C~.;;:~
')"-;<;
GUEU t
~4
~ ~(l
•
T"!"Y';'
~u,u,
.
4::1: S
f
. . \!<:
11
E
*** ........ *.* .......
CH AN 'I". L
Tl ME
5Y
8
~u
T!
3~S
M~
M;:: AN
y
q~("v
CI-IA~
1121';07.
11.!?2'2
~£A~
~l:
... o.~q
f"}
ut'" ~T"
:L C
A ~~
SOli .... ·
£5.2'~
461.71
<:;'0
~
~,
~
"'3£?
0,
AC T! VA TI
:' 17 S
2(')
Figure 15a-Results of experiment 1
11
OSSL
P PO CE 55 IN G UN IT
1
53. 849
T 1M E BU SY
T
53. 849 PE oC EN T
If..4 £: FO R OV EP HE AD
T I~
E Fa R
PR
DC ES
SI
NG
T I~ E F0 R EXECUTION
.
000
Pc PC EN T
•
ao 0
PC: ClC EN T
MfA N Btl SY SPAN
729. 297
SPA N
41.3. 194
MfA. N IDLE
n A <:~. IG N::: 0 TO THE CPU
~
E
;,
TABLE:
p::- PC [t-l T
TABl
;:; PE (lJ EN CY
INTEt?VAL
PC: RC E\i T A GE
• 0 -
4C C. 0
?c: 3
13. Q2 t
40
o. a -
500. 0
3S 1
17. 38 S
50
o. 0
-
60 O.
a
378
1 8. 72 2
so o. 0
-
70
c:. 0
10. 8
9. 80 7
70 o. 0
-
80
o. 0
80 C. 0
-
~o
o. 0
8. 37
141
5.843
900. 0 -1 DC O. D
1 00
o. 0
1 50
o.
a
-1 50 o. 0
261
12.927
o. 0
84
4. 160
2000.0 -2SCO.O
31
1. 53 S
7500.C -3000.0
11
• 54 5
3 00 C. 0 - 3 5 a Q. 0
7
.347
0 -2 00
3500. G -4000.0
OVER 4000.0
• 149
o
TOTAL ENTRIFS
Figure I5h-Results of experiment 1
• coo
811
812
Spring Joint Computer Conference, 1972
R
UF f."" f
R:: GI ON
t'
1
IS
TOT Al SPA CE
7
~
PA eEl t\
A VG.
SP~
MAX.
Sf.> ACt:
T OT Al
.....
US: E
L
C E I\J U C:[
1. 01
US ED
5
N 0 OF R E{~ Ut :::, T 5
REG UE ST S NO T ME T CU
T G SP AC E S~ OR TA G[
;: fO Uf.: '-T
TOOt ( I
Q
c::
~I
UE
NO.
20 21
=
NOT t-1E T DU r:
ON q Ul F.
Uf Uf S TAT:::
o LIt:'"
r
s.r 'I·:. s
T0 T-~ l
fNT PI ES
~A YI~n
r.:
eU;:';:R [(\ T
AV r:-p AG E.
C~NT=:N
T
"0 "JT C"N T
cn NT EN T
· 84
· OS
1
qp
?
'--'~
~
0
9·S
-;
0
·
,..., ....
4
~~
"3
0
•
OSO
5
9~
?-
r,
L:
· 05
-.. '
11 4°
4
1
• 34 3
1 57
2
u'"'
· 00
B
n
'"
Qr
Figure 15c-Results of experiment 1
u~
tv ER fJG E
WAI T
S
4b
E. 88
4
~
~
E-O 0. '31
r.
1
53 Q. 11 7
L
j
51
55
o.
~
!
•
r
~r
3
63
~
£.:J
304. 3iJ
3 3. 13
r
~
OSSL
In developing the OSSL version of the GPSS model,
the following advantages of the OSSL language over
the GPSS language for computer system simulation
were noted:
1. There is a more direct correspondence between
the various components of a computer system
and the available OSSL language segments. This
feature practically eliminates the translation of
the computer system operation concepts into
simulation concepts as contained in GPSS or
any other general purpose simulation package.
2. The OSSL language elements reflect the terminology used by the designers and implementors
of computer systems. This feature goes a long
way in reducing the time required for structuring
and debugging of a simulation model. A side
benefit is expected to be the ability to involve
interested people who do not know the simulation techniques.
3. The OSSL language is self documenting and
thus considerably reduces the need for lengthy
explanations for communicating the model
being simulated.
4. The OSSL simulator is capable in dealing with
fractions of unit time, whereas G PSS deals in
integral values for time. This feature eliminates
the scaling of the time specifications by the
user.
5. The OSSL language provides the user the ability
to define the various distribution functions in
terms of their parameters rather than via a table.
6. The OSSL language provides for free-format
input as opposed to the fixed-field format of
GPSS.
7. The modularity of a particular simulation model
expressed in the OSSL language will allow for
several persons to contribute to a simulation
study much more easily than the GPSS language.
CONCLUSIONS
The OSSL language, developed for simulating computer
systems, seriously attempts to reflect the terminology
used by the designers and implementers of computer
systems. This semantic structure should allow the use
of the language even by those who are not particularly
well-versed in the art (and science) of simulation. The
free-format syntax of the language should also encourage
its use. The OSSL simulator is also inexpensive to use.
The simulation run relative to the o.n-line inquiry
system consumed 30 seconds on the UNIVAC 1108
813
computer system. Other, more complex systems have
been simulated in from approximately one to five
minutes (CPU time) on the UNIVAC 1108. The ratio
of simulated time to real time is not readily generalizable
since it depends heavily on the complexity and number
of concurrent processes being simulated.
A simulation model structured by the use of the
language consists of several interrelatable but modular
segments. This modularity makes it easy to effect
changes in the model. Moreover, it enables several
persons to contribute to the simulation study. In
addition to providing simulation capability, the
generalized model provides a tool to document computer systems in a relatively unambiguous manner as
demonstrated in the examples. This capability, hopefully, will raise the level of communications between
personnel dealing with the different aspects of computer systems.
The language may also be used as a pedagogical
device in the area of computer operating systems.
Modelling of operating systems has the potential of
providing to students invaluable insight into the
dynamic relationships of various elements of an
operating system. For example, the OSSL language is
being used in a graduate course in computer operating
systems design and in graduate research at the U niversity of Houston. The ability of students without
formal training in simulation to grasp, learn, and use
the OSSL language in computer systems simulation
based on this limited experience has been very gratifying. With the OSSL User's Guide25 as a reference ,
students with a strong background in computer
operating systems are able to have simple models
developed and executing in a matter of days. Relatively
complex models have been developed and experiments
implemented by a different group of similarly prepared
students within a matter of three to four weeks. A more
complete analysis of the results of the usage of OSSL
in the tracking of computer operating systems topics is
being prepared for a future paper.
During the brief but intensive period of usage of
OSSL since June of 1971, a list of improvements and
modifications is being compiled and some such changes
are being implemented as time permits. A partial list
of these improvements is as follows:
1. Introduction of dynamic storage allocation for
storage relative to model parameters during
execution.
2. Provision for more extensive and. specific error
messages for both compile time and execution
time errors.
3. Provision of recursive "Subroutine-like" capa-
814
Spring Joint Computer Conference, 1972
bility for procedures written in the OSSL
language~
4. Expansion of memory management and processor simulation capabilities to allow for user
representation of more "exotic" computer system
architectures.
I t is recognized that the language may not be able to
simulate all computer systems, primarily due to the
current weakness of the language in the area of "unconventional" memory management strategies and intraprocessor scheduling algorithms. This weakness suggests
that more research needs to be done in this area. To
this end, the language has been implemented with an
open-ended structure, which will hopefully allow for the
inclusion of these and other developments with minimum difficulty.
I t is hoped that the language will be used extensively
to establish its usefulness as well as its limitations.
REFERENCES
1 L J COHEN
System and software simulator
Defense Documentation Center Number AD 679269
December 1968
2 E G COFFMAN
Stochastic models of multiple and time-shared computer
operations
PhD Dissertation Department of Engineering University
of California at Los Angeles June 1966
3 C J CONTI D H GIBSON S H PITKOWSKY
Structural aspects of system/360 model 85 I-General
organization
IBM Systems Journal Vol 7 Number 1 1968
4 C E DONAGHEY JR
A generalized material handling simulation system
SRCC Report Number 69 University of Pittsburgh
Pittsburgh Pennsylvania February 1968
5 General purpose simulation system/360 introductory user's
manual
IBM Inc Form GH20-0304-4
6 J H KATZ
A n experimental model of system /360
Communications of the ACM Vol 10 November 1967
7 J S LIPTAY
Structural aspects of the system/360 Model 85, II-The Cache
IBM Systems Journal Vol 7 Number 11968
8 M H MAcDOUGALL
Computer system simulation: An introduction
Computing Surveys Vol 2 Number 3 September 1970
9 H M MARKOWTIZ B HAUSNER H W CARR
SIMSCRIPT: A simulation programming language
Prentice Hall Englewood Cliffs New Jersey 1969
10 R L MATTSON J GECSEI D R SLUTZ
I L FRAIGER
Evaluation techniques for storage hierarchies
IBM Systems Journal Vol 9 Number 2 1970
11 R M MEADE
On memory system design
1970 Fall Joint Computer Conference Proceedings Vol 37
AFIPS Press Montvale New Jersey
12 R A MERIKALLIO F C HOLLAND
Simulation design of a multiprocessing system
Proceedings of 1968 FJCC Thompson Book Company
Washington DC December 1968
-13 J H MIZE J G COX
Essentials of simulation
Prentice Hall Inc Englewood Cliffs New Jersey 1968
14 T H NAYLOR J L BALINTFY D S BURDICK
K CHU
Computer simulation techniques
John Wiley and Sons Inc 1966
15 N R NIELSEN
The simulation of time-sharing systems
Communications of the ACM Vol 10 No 7 July 1967
16 N R NIELSEN
Computer simulation of computer system performance
Proceedings of 22nd National Conference ACM Thompson
Book Company Washington DC August 1967
17 N R NIELSEN
An approach to the simulation of time-sharing systems
Proceedings of the 1967 FJCC Thompson Book Company
Washington DC December 1967
18 N R NIELSEN
ECSS: An extendable computer system simulator
Memorandum RM-6132-N ASA The Rand Corporation
Santa Monica California February 1970
19 S L REHMANN S G GANGEWARE JR
A simulation study of resource management in a time-sharing
system
Proceedings of 1968 FJCC Thompson Book Company
Washington DC December 1968
20 S ROSEN
Electronic computers: A historical survey
Computing Surveys Vol 1 Number 1 March 1969
21 R F ROSIN
Supervisory and monitor systems
Computing Surveys Vol 1 Number 1 March 1969
22 A L SCHERR
An analysis of time-share systems
PhD Dissertation Department of Electrical Engineering
Massachusetts Institute of Technology June 1965
23 T J SCHRIBER
General purpose simulation system/36D-Introductory
concepts and case studies
University of Michigan Ann Arbor Michigan September
1968
24 P H SEAMAN R C SOUCY
Simulating operating systems
IBM Systems Journal Vol 8 Number 4 1969
25 J B WYATT P B DEWAN
OSSL-Operating systems simulation language-A user's
guide
University of Houston Press November 1971
Discrete computer simulation-Technology and
applications-The next ten years
by JOHN NORRIS MAGUIRE
Consultant
Reston, Virginia
Digital computer simulation is an effective method
of pretesting proposed systems, plans or policies prior
to the development of expensive prototypes, field tests
or actual implementations. In simulation analysis the
computer traces out in detail the implications and
consequences of a proposed system or course of action.
Compared with other forms of analysis, simulation is
more realistic, more easily understood and more conclusive. Because the results are easier to understand,
the conclusions receive wider acceptance.
As an aid in making important decisions, the use of
computer simulation is growing at an astonishing rate.
A decade ago it was used occasionally in manufacturing,
military, nuclear, and a few other pioneering applications. In more recent years its use has expanded exponentially, both through increased coverage of old
areas and in application to new areas. The growing list
of successful uses includes the simulation of proposed
information systems and manufacturing facilities;
proposed inventory control systems; war games such as
air battles, tank battles, and amphibious operations;
hydroelectric, transportation, and communication systems; and many more.
Five factors have triggered this growth in the past
and will continue to do so in the future. The first is the
increasingly widespread recognition of simulation's
role in careful planning. It pretests proposals under
alternate contingencies prior to implementation. To a
certain extent, it provides hindsight in advance.
The second factor contributing to the growing use of
simulation is the advancement in techniques for producing simulation models and programs.
The third factor is the increasing availability and use
of generalized models which focus on particular problem
areas. The most notable successes here have been in the
information systems area, but the development and
use of generalized models have been spreading rapidly
into other areas such as inventory, transportation,
logistics, financial and management planning systems.
The fourth factor contributing to the increased use of
simulation is the application and acceptance of more
scientific techniques to the experimental design aspects
of simulation experiments. Coupled with this has been
the development of automated analysis techniques for
simulation models.
The fifth factor is the increasing availability of data
vital to the formulation of models. Naturally, this
change has come about mostly in the areas which have
been susceptible to a high degree of automation, e.g.,
computerized information, inventory, financial and
manufacturing systems. Successes in these areas have
accelerated simulation research and applications in
areas such as marketing, social, biomedical, oceanography and environment/ecological systems where the
data is more sparse, but growing rapidly.
These statements are generally true for all types of
modelling. It is convenient to classify simulation models
into two major types: continuous change models and
discrete change (or discrete event) models. Some
models are clearly best described by one type or the
other; for a few problems, either type may be used.
Many of the comments to follow on technological
developments and trends will be applicable to both
kinds of modelling, but the discussion will concentrate
on discrete event modelling.
THE SIMULATION PROCESS
A brief review of the simulation process itself is
appropriate prior to discussing the recent and likely
future technological changes in this process. One view
of the simulation process suggests that there are ten
steps as illustrated in Figure 1.
1. Formulate the Problem This includes a definition
of the general objectives of the study; specification of the questions to be answered; and a
description of decision criteria and processes.
815
816
Spring Joint Computer Conference, 1972
I MODEL REQUIREMENTS
II MODEL DESIGN
5.
6.
III MODEL EXPERIMENTATION
9. Run Experiments Implement model initialization and operating procedure and perform
experiments.
10. Analyze Results Relate the results back to the
real phenomena; decide if further experimentation is required; and document results.
Of these ten steps of specified simulation activity,
step Number 6, Model Construction, is the one that
has seen the most dramatic change in the past decade
through the development of high level simulation
languages and generalized models. Changes will continue to take place in this area and these will be discussed in a later section of this paper.
Significant changes have also taken place in the
following steps:
3. Data Collection
8. Experiment Design
10. Analysis
Figure 1-Modelling tasks
2. Identify Major System Elements A description of
the major system components and features has
to be developed; explaining functional dependencies and interrelationships. Also, the "domain"
of the system under study should be defined in
terms of exogenous and endogenous phenomena.
3. Collect and Analyze Data This involves the
classification and identification of relevant data
sources. Procedures/data collection forms/ computer programs/devices may be used in the
collection of this data.
4. Formulate Model Detail Create the design
specifications defining basic elements and their
characteristics coupled with a verbal description
of model operation.
S. Establish Model Content Specify the degree to
which phenomena will be enacted. Establish
control and experiment parameters along with
system performance measures.
6. Construct Model Evaluate alternative modelling
techniques; flow chart, code and de-bug the
model.
7. Validate Model Compare simulated data with
hypothesized, actual, and/or historic data; and
perform sensitivity analysis.
8. Design Experiments Evaluate alternative experimental design techniques and compare with
/
SimOptimization* procedure; make decision and
set up experiments.
* SimOptimization is a Trademark and Service Mark of Consolidated Analysis Centers Inc.
It is in these three areas where some substantial changes
may be expected to occur in the coming decade.
Again, the five factors which seem to have brought
about an expotential increase in the use of simulation
are:
1. Recognition of simulation's advantages.
2. Advancements in techniques for producing
models.
3. Increased availability of generalized models.
4. Increased application of experimental design and
automated analysis techniques.
S. Increased availability of relevant model data.
Trends in these five areas can be discussed and
extrapolated with a reasonable degree of confidence for
the next decade. Other positive factors will also influence the growing use of simulation. These factors
include:
• Larger numbers of students leaving the campus
trained in simulation techniques.
• Successes with simulation in new application areas.
• Reduction in the cost of using computer simulation,
especially for machine time as we enter the "nocost processor" era in the 1980's.
The major factor on the negative side which might
tend to inhibit the growing use of simulation in a
particular functional area or organization is either the
misapplication of the technique or low quality work
performed by an over zealous, ill equipped individual or
group. This will happen, as it has in the past, as a field
turns from more of an "art" to more of a "science."
Examples of this type appear in every new field, be it
process control computers or heart transplants, but it is
Discrete Computer Simulation
not expected to be a significant deterrent to increased
use of computer simulation.
1. Recognition of Simulation's Advantages
One indicator that this has occurred is simply the
vast sums of money and resources being expended in
the area and the trend is clearly up-after possibly a '
leveling off during the recent recession. One measure
of this effort is the published computer simulation
papers and conferences devoted solely to the subject.
In addition to many simulation papers presented as
parts of many conferences such as this Spring Joint
Computer Conference during the past five years, new
annual simulation conferences include:
• Summer Computer Simulation Conference
(1970 Denver, Colorado-1971 Boston, Massachusetts)
• Applications of Simulation
(Usually New York)
• Annual Simulation Symposium
(Tampa, Florida)
Attendance at these conferences has been growing and
the proceedings from the 1971 SCSC ran 1,323 pages.
Various organizations and societies have co-sponsored
one or more of the above conferences. These societies
include:
• American Institute of Aeronautics and Astronautics
(AIAA)
• American Institute of Chemical Engineers
(AIChE)
~ American Institute of Industrial Engineers (AIlE)
• American Meteorological Society (AMS)
• Association for Computing Machinery (ACM)
• Board of Simulation Conferences (BSC)
• Institute of Electrical and Electronics Engineers
(IEEE)
• Instrument Society of America (ISA)
• Simulation Councils, Inc. (SCi)
• SHARE-IBM User Group
• The Institute of Management Science (TIMS)
While there is a way to go before operating personnel
use, or at least endorse simulation techniques, the
previous paragraphs do indicate that general acceptance of the technique has occurred among professionals working in a variety of fields.
2. Advancements in Techniques for Producing Models
These techniques have centered around the development of high level simulation languages. A detailed
817
discussion of these languages is presented in Mr. Ira
Kay's paper for this session.
The two most widely used discrete event simulation
languages, are SIMSCRIPTl,2,3 and GPSS.4 A recent
development has been the availability of the HOCUS
modelling method. 5 With simulation techniques and
languages, as with most other tools, there is a trade-off
between performance and simplicity of design. The
HOCUS approach occupies a particular point on the
trade-off curve. SIMSCRIPT and GPSS represent two
other distinct trade-off points. Each of the three systems
fulfills an important need not fully met by the other
two, even though the basic principles underlying all
three systems are essentially the same.
The extreme simplicity of HOCUS gives it many
important practical advantages over other methods,
including quick model formulation, the ability to
operate the model by hand, and easy transfer to a
computer. On the other hand, some simulation models
cannot be forced into the limited HOCUS framework.
At the other extreme, SIMSCRIPT is the most
general and powerful of the three techniques. It demands highly skilled simulation analysts or programmers, but its great power and generality are
sometimes indispensable. GPSS falls between HOCUS
and SIMSCRIPT (Reference No. 6 details an evaluation of major simulation languages-although published
in 1966, the study is still reasonably valid). Some systems can be classified as a restricted language or a
generalized model depending upon your viewpoint. An
example of this is ECSS (see: Kosy, D. W., "Experience
with the Extendable Computer System Simulator,"
RAND No. R-560-NASA/PR, December, 1970).
The main point is that the programming "bottleneck" in the development of simulation models has,
for the most part, been solved. Refinements will continue in the simulation language field. Two of the most
promising developments are interactive modelling and
simulation oriented graphics.
The best known interactive simulation language is
OPS-3. 7 This language was designed and implemented
at M.LT. and used successfully to demonstrate the
feasibility of interactive modelling. Operating in a timeshared environment under the M.L T. Compatible
Time Sharing System (CTSS), OPS-3provides a user
with on-line interactive communication between himself and a programming system. Using it, one can, in a
single sitting, compose a program, test and modify it,
expand and embellish it, and prepare it for subsequent
production use.
A considerable amount of simulation-oriented graphics
research is going on right now. At the Norden Division
ofU nited Aircraft, an IBM 2250 is used to modify
source language GPSS programs and view their output
818
Spring Joint Computer Conference, 1972
in graphical form.8 At the RAND Corporation, the
Grail system and the RAND Tablet are used to construct GPSS programs on-line from hand-drawn
flowcharts. 9 At M.LT., the SIMPLE project is using
graphics for man-computer interaction during modelling
and experimentation. Papers have been written on the
use of graphics in simulation modelling and the use of
existing graphics packages for analyzing simulationgenerated output. IO
There is little doubt that interactive modelling is
carried out better with a CRT device than with a
typewriter or line printer. When designing programs,
flow-charts and other symbolic notation can be displayed. For analyzing performance data, graphs provide more insight than do lists of numbers. The growing
use of line-printer plotting simulators testifies to the
utility of graphic output.
Also, we will see during the next decade extensions
of a few simulation languages that will include mass
storage random access data handling capabilities. There
already exists a design and a tested prototype for this
in SIMSCRIPT. The model builder will be able to use
the simulation language itself to acquire most, if not
all, of the data he requires for model formulation and
testing.
3. Increased Availability of Generalized Models
During the early 1960's, a few simulators for discrete,
dynamic models of manufacturing, inventory and EDP
systems appeared and were parameterized and relatively
easy to use, but had a narrow range of application. The
alternative programming solution for a computer model
was frequently machine language or a language such as
FORTRAN or ALGOL which typically consumed a
large amount of time for implementation. After that
period, there emerged a number of simulation languages
that attempted to provide the flexibility of machine
language with the power of a generalized model. In
parallel with these developments, a number of generalized models became available. SCERT,ll CASE,12
S.A.M.,13 LOMUSS,14 and ECSSI5 are examples of
generalized models of EDP systems. These models
possess the advantage of "ease of use" if their structure
happens to fit your EDP modelling problem. Examples
of their general use are numerous,16,17 and growing
rapidly. Successful simulation applications of generalized models have helped to determine EDP design
answers such as machine core size, secondary storage
assignments, peripheral terminal configuration, operating system procedures and allocation rules. Similar
successful use of generalized models in other problem
areas insure their increased use, because of the rapid
implementation and low cost usually experienced with
each application of a generalized model.
4. Increased Application of Experimental Design and
Automated Analysis Techniques
Much has been written about the use of computer
simulation experiments for the study and design of
systems. 18 For the most part, the literature has emphasized the "model building" aspects rather than the
experimental design aspects of simulation experiments.
It may be that by the time the typical model-builder
has gone through all the steps of implementing a model,
he has run out of time and frantically makes a series of
computer runs changing parameters here and there on a
"gut-feeling" basis. He then culls through stacks of
computer output trying to perform analysis. Other
factors presently associated with this situation of not
using more sophisticated techniques may be cost (these
techniques tend to require more labor and computer
time) and training prerequisites (A strong mathematical
and/ or statistical background is required.) N evertheless, increasing use of more analytical techniques for
simulation of systems is a near certainty.
In a well-designed experiment, consideration must '\
be given to methods of analyzing the data once it is
obtained. Most of the classical experimental design
techniques described in the literature (e.g., 19, 20) are
used in the expectation that the data will be analyzed
by one or both of the following two methods: analysis
of variance and regression analysis. Recently, however,
several other techniques have been proposed for analyzing data generated by computer simulation models
including multiple ranking procedures, sequential
sampling plans and time series analysis. Also, a technique called "SimOptimization" shows promise for
automating and minimizing the number of simulation
runs required.
A nalysis of variance
The analysis of variance is a collection of techniques
for data analysis which are appropriate when qualitative factors are present, although quantitative factors
are not excluded. An example of a qualitative factor
would be the testing of different decision rules in a
simulation model. Regression analysis is a collection of
techniques for data analysis which utilizes the numerical properties of the levels of quantitative factors. The
parameters chosen for describing probability distributions are quantitative factors, but the type of
probability distribution (e.g., exponential or normal)
would be a qualitative factor. From a mathematical
Discrete Computer Simulation
point of view the distinction between regression and
analysis of variance is somewhat artificial. For example,
an analysis of variance can be performed as a regression
analysis using dummy variables which can assume only
the values of zero or one. A treatment of the relationship between regression and the analysis of variance can
be found in the book by Graybill. 21
Multiple ranking procedures
Conway22 and others have pointed out that analysis
of variance techniques frequently do not supply the
kind of information that the experimenter seeks.
Referring specifically to the design of computer simulation experiments, Conway has stated that:
the analysis of variance seems a completely
inappropriate approach to these problems. It is
centered upon the test of the hypothesis that all of
the alternatives are equivalent. Yet the alternatives
are actually different and it is reasonable to expect
some differences in performances, however slight.
Thus the failure to reject the null hypothesis only
indicates that the test was not sufficiently powerful to detect the difference-e.g., a longer run
would have been employed. Moreover, even when
the investigator rejects the hypothesis, it is
highly likely that he is more interested in identifying the best alternative than in simply concluding that the alternatives are not equivalent.
Recently proposed ranking ... seem more
appropriate to the problem than the conventional
analysis of variance techniques, but the investigator is still going to have difficulty satisfying the assumptions (normality, common
variance, independence) that the statistician
will require. 22 (P. 53)
Bechhofer's procedure for ranking means of normal
populations with known variances23 .24 and Bechhofer
and Sobel's procedure for ranking variances of normal
populations25 are examples of multiple ranking procedures which seem appropriate to the design of
computer simulation experiments.
Sequential sampling plans
Experimental designs which use analysis of variance
as a technique of data analysis are based upon the
assumption of fixed sample size. However, with certain
kinds of experiments conducted on an "accumulationof-information" basis, sequential sampling methods
can be utilized which may lead to significant reductions
in sample size. Since we are using computers on an
819
accumulation-of-information basis and not planting
plots of beans that will mature next year, we may want
to take advantage of the savings (in terms of computer
time) sequential experiments offer. Sequential sampling
methods were designed for testing hypotheses or
estimating parameters "when the sample size is not
fixed in advance but is determined during the course of
the experiment by criteria which depend on the observations as they occur."26(p.365)
In testing a hypothesis with a computer model, the
sequential method yields a rule for making one of the
following three decisions at each stage of the simulation
experiment :27 (p .271) ( 1) Accept the null hypothesis;
(2) Reject the null hypothesis; (3) Continue the
simulation experiment by generating additional data.
Although W aId's Sequential A nalysis28 is probably the
best known reference on sequential sampling procedures, the optimization procedures developed by
Dvoretzky, Kiefer and Wolfowitz 29 (PP.51-55) appear to
offer promise in analyzing data generated by computer
models. Chernoff's30 article entitled, "Sequential Design
of Experiments" considers a number of important
aspects of sequential designs also.
Spectral analysis
Spectral Analysis31 is a statistical technique widely
used in the physical sciences to analyze time-dependent
physical processes. There are at least two reasons why
one may want to consider spectral analysis as a technique for analyzing data generated by computer
simulation models. First, data generated by computer
simulation experiments are usually highly autocorrelated. Yet classical statistical theory of the design
of experiments (analysis of variance) is based on the
assumption that component observations or experimental outcomes are independently distributed. In
simulation experiments involving autocorrelated data,
classical statistical theory must be replaced by a
sampling theory such as spectral analysis in which the
probabilities of component outcomes in a series depend
on other outcomes at other time points in the series.
Second, as one becomes more sophisticated in the
analysis of computer simulation data, he may become
interested in analyzing more than expected values and
variances. "When one studies a stochastic process, he is
interested in the average level of activity, deviations
from this level, and how long these deviations last,
once they occur. Spectral analysis provides us with this
kind of information. Spectral analysis studies the
salient time properties of a process and presents them
in an easily interpretable fashion for descriptive and
comparative purposes."32
820
Spring Joint Computer Conference, 1972
Fishman and Kiviat32 have written a survey article
on the use of spectral analysis in analyzing data generated by computer simulation models. Tukey 33 has
written an article in which spectral analysis and the
analysis of variance are compared in detail.
SimOptimization
SimOptimization34 ,35,36 is a set of optimum-seeking
techniques embedded in an automatic cycle of simulation-analysis-simulation. These procedures quickly
locate improved policies and computer system configurations in simulation models. Their use greatly
increases the value of simulation analysis.
While simulation is more realistic and easier to
understand than mathematical optimization, it has the
disadvantage of being somewhat clumsy to use. A
typical simulation model has an enormous parameter
space in which the desired optimum solution is concealed. Finding this solution can be difficult.
Fortunately, a good analyst, using his judgment and
intuition can find improved solutions by studying the
results of a limited number of simulation runs. Even so,
the process of making a few runs, studyin~ then:,
deciding what runs to make next, then repeatIng thIS
procedure, is a time consuming and costly way to grope
for a good solution. By using SimOptimization, the
preferred solution for most models can likely be determined in a single computer run consisting of from two
to four simulation and analysis phases.
In most simulation models, optimality cannot, of
course, be proven rigorously. However, SimOptimization solutions are at or very close to the "apparent"
optimum. In every case, a "good" solution to a realistic
model is preferable to an "optimal" solution to an
unrealistic model.
While SimOptimization is still new, all of its applications have been highly successful. Judging from this
empirical experience, SimOptimization seems to offer
the best of two worlds, namely the realism of digital
simulation combined with the convenience of automatic
analytical solutions.
5. Increased Availability of Relevant Model Data
The technological changes taking place today in data
collection in information processing, or "EDP Systems"
is taking place in parallel with other areas such as
finance and manufacturing and portends what is going
to happen in the future in other areas susceptible to
simulation. A detailed discussion follows covering the
trends in EDP System data collection. Within the next
decade we will see similar changes in other areas where
data is now laboriously collected only on an ad hoc
basis for a simulation study.
A key step in the process of constructing an ED P
system model is the collection of data characterizing the
work load. Of course, if we are hypothesizing a new
system in a new environment, it doesn't pose much of a
problem. But, typically, the model builder is studying
possible hardware and software changes to an existing
system. Therefore, he must represent as accurately as
possible the complete system. In the past, this meant
collecting some data on the work load and the computer
system. Job data was (and still is) frequently obtained
from an accounting file generated by the operating
system. The characteristics of the hardware are obtained from the technical manuals. * This is the procedure used in applications, of which the study by
Hutchinson and Maguire17 is an example.
But computer system complexity has increased
faster than our ability to characterize these systems.
Today, the complex interactions between the work
load , hardware and software of computer systems make
.
the batch-processing systems of the second generatlOn
appear very simple, indeed. The difficulty today of even
intuitively being able to predict the performances of
some of these systems creates a situation where simulation for EDP systems is in more demand than ever.
The recent development of EDP System Hardware and
Software monitors offers a solution to this problem.
As will be shown, use of these monitors can help solve
operating problems and increase efficiency in the short
run, but an even greater value may be in their use for
generating data for EDP system models for pretesting
system changes.
Hardware monitors
A hardware monitor consists of sensors, control logic,
accumulators, and a recording unit. The sensors are
attached on the back panels of the computer system
components-CPU, channels, disks, etc. The signals
from registers, indicators and activity lines picked up
by the sensors can be logically combined or entire
registers can be compared at the control panel and then
be routed to the accumulators for combining or timing
events, e.g., CPU active, any channel busy, disk seek
counts and times, etc. Typically the contents of the
accumulators are written periodically to a magnetic
tape unit. The magnetic tape is batch-processed by a
data analysis program to produce a series of analysis,
summary and graphic reports. Figure 2 shows a hardware monitoring system.
* Some generalized models such as SCERT and CASE maintain
this data on tape for convenience in processing.
Discrete Computer Simulation
Table I lists some hardware monitors presently
on the market.
Figure 3 illustrates some typical output from a data
analysis program run against a monitor tape. 37
Two examples of how hardware monitors are used
to improve system performance are:
1. Channel Imbalance
If the channel utilization is high, but the channel load
is not balanced, the device activity needs to be measured to determine device rearranging. A new system
performance profile should be measured to verify the
results.
Low channel utilization would indicate that all the
work can be placed on one channel with little effect on
the system throughput.
2. Multi-programming Effectiveness
A large CPU ACTIVE ONLY time coupled with a
low CPU-CHANNEL OVERLAP indicates that the
benefits of multi-programming are not being obtained.
Possible reasons are poor job scheduling (a balance is
needed between CPU and I/O bound jobs); poor data
set allocation (data sets should be on different channels
so they do not have to be retrieved sequentially), or
inefficiently written programs. Several of the production
jobs which use a large part of the system resources
should be selected and run stand alone in the system to
create an individual job profile. These profiles show
data set usage to make data set placement changes and
processing phases which are CPU or I/O bound to
Hardware Monitor
•
•
•
•
•
Compare
Logic Control
Accumulators
Count
Time
821
TABLE I-Computer Hardware Monitors-A Sampling*
Supplier
Allied Computer
Technology, Inc.
1610 26th Street
Santa Monica, California
90404
Telephone: (213) 828-7471
Hardware
Monitor
Price
CPMII
$35,000 to $80,000
CPM III
$14,700 to $24,000
Computer Learning &
Systems Corp.
5530 Wisconsin Avenue
Suite 1600
Chevy Chase, Maryland
20015
Telephone: (301) 652-9220
X-RAY
$2,350/month or
$50,0000 purchase
Computer Synectics, Inc.
328 Martin Avenue
Santa Clara, California
95050
Telephone: (408) 247-0200
SUM
Starts at $1,750/
month for one year
lease or $34,000
purchase
COMRESS
2 Rockville Court
Rockville, Maryland 20850
Telephone: (301) 948-8000
Dynaprobe
$4,000/monthlease
$34,000-typical
purchase price
IBM Corporation
112 E. Post Road
White Plains, New York
10601
Telephone: (914) 696-1900
SMIS
$1,800 for basic
service contract
Computer & Programming
Analysis Inc.
One Wynnewood Road
Wynnewood, Pa. 19096
CPA 7700
$5,000 to $40,000
* For Suppliers not included or if listed Supplier's information is
not up-to-date, please write to author.
enable efficient job scheduling. This will increase CPU
utilization and system throughput.
While the data derived from the hardware monitor is
useful for immediately improving system performance,
it can also be very valuable to the model builder contemplating major changes or new systems. This data
serves as:
Analysis
f--------fI Sunuuary
Graphs
Figure 2-Hardware monitor system
• Input to development of the model.
• A validation "check point" for model testing.
The hardware monitor does not degrade or interfere
with the system it is measuring and requires no system
overhead. A software monitor, on the other hand, is a
822
Spring Joint Computer Conference, 1972
Measured 10/6/70
System Model 40 and 50 Analysis CPU Active Model 50
o 10 20 30 40 50 60 70
80
90 100
Sees.
x
x
x
x
x
x
x
x
x
x
x
Time
********************************************************
90.0
1111 .
8.31.30.0
180.0
111111111111 .
8.33. 0.0
270.0
1111111111111111111111
8.34.30.0
360.0
11111111111111.
8.36. 0.0
450.0
1111111111111 .
8.37.30.0
540.0
11111111111111111
8.39. 0.0
630.0
11111.
8.40.30.0
720.0
11111111 .
8.42. 0.0
810.0
11111111111111111111111
8.43.30.0
900.0
1111111111111111
8.45. 0.0
990.0
111111111111 .
8.46.30.0
1080.0
1111111111111111
8.48. 0.0
1170.0
1111111 .
8.49.30.0
1260.0
11111111111
8.51. 0.0
1350.0
111111111111111111111111111111.
8.52.30.0
1440.0
1111111111111111111111111111111111111
8.54. 0.0
1530.0
1111111111111111111111111111111111
8.55.30.0
1620.0
1111111111111
8.57. 0.0
1710.0
11111111111
8.58.30.0
1800.0
11111111111
9. O. 0.0
********************************************************
Sees.
x x x
x
x
x
x
x
x
x
x
o 10 20 30 40 50 60 70
80
90 100
Figure 3-Histogram of CPU active
program itself, uses system resources, and adds to
system overhead. Both have their merits. A software
monitor costs less than a hardware monitor and does a
better job of getting a "fix" on the system workload.
Software monitors
The important variables in a computer system can
be classed as either quantitative variables or qualitative
variables. Quantitative variables are concerned with
the magnitude of some quantity such as cpu active
time. Qualitative variables identify which, of a perhaps
very large number of different system elements, are
being considered. For example, when measuring the
work performed by a given program (i.e., the percent of
available cpu cycles being utilized), it is necessary to
identify each module and overlay segment individually
and to show the cpu activity requirements of each. The
module and segment names are the qualitative or
descriptive variables, the cpu activity associated with
each is the quantitative variable.
Qualitative and quantitative variables must be
combined to present a usable set of measurements. One
of the advantages of software monitors is their ability to
obtain both from the system itself. This eliminates the
necessity for using manual techniques to obtain or
correlate information on what elements were active
during the data collection process. When the descriptive
data required is not available through console logs or
other means, then either a pure software approach
must be used or special software supplied to obtain the
needed descriptors in a manner which permits proper
correlation.
How a software monitor extracts variables from
memory is conditioned on the timing and form in which
such variables are retrieved in memory, which in turn
tends to be a function of the structure of the operating
system, compilers, etc. Thus, software monitors are at
least operating systems dependent and can be compiler
dependent or even problem program dependent.
Ideally, the act of taking a measurement should not
alter the system being measured nor require the system
to be altered beforehand. This is not perfectly achievable in software monitors. A good software monitor
extracts data from the system without significantly
altering the run characteristics of the system. This
involves three parameters: cpu cycle requirements,
I/O activity, and core usage. The first two quantitative
variables can be expressed as a percentage of some total
time, rather than an absolute count. Thus classical
sampling techniques can be used instead of activating
special codes or going to the techniques of trace routines.
Furthermore, if the frequency of sampling is less than
the minimum time in which some event can occur, then
other measures of interest can also be supplied. Thus,
Discrete Computer Simulation
even though the sampling techniques are used, software
monitors can obtain the cylinder addresses of successive
head movements on discs by using a sample interval
less than the minimum positIoning time.
The third design parameter-core usage-is resolved
typically by the simple expedient of separating the
data extractor mechanism from the data analysis
function. As an example, Figure 4 illustrates this
structure for the Boole and Babbage program evaluator
823
TABLE II-Computer Software Monitors-A Sampling*
Supplier
Allied Computer
Technology, Inc.
1610 26th Street
Santa Monica, California
90404
Telephone: (213) 828-7471
Software
Monitor
CPS II
Price
$6,500
(PPE) .38
Application examples are given in References 39 and
42 using PPE40 and another software monitor called
CUE.41
This has several other important benefits, such as
the ability to combine and/or reanalyze raw data in
various ways. While some software measurement tools
have been built with the extraction and the data
reduction mechanisms combined, experience with them
User Program
Boole and Babbage, Inc.
1121 San Antonio Road
Palo Alto, California 94303
Telephone: (408) 255-1200
PPE or CUE $8,800 or $15,400
for both
Boothe Resources
CIMS I or II $3,500 to $5,800
International
3435 Wilshire Boulevard
Los Angeles, California 90005
Telephone: (213) 380-5700
Computing Efficiency, Inc.
35 Orville Drive
Islip, New York 11716
Telephone: (516) 567-3600
Compumeter $3,500 for 360lDOS
$15,000 for 36010S
Lambda Corporation
1501 Wilson Boulevard
Arlington, Virginia 22209
LEAP
$8,500
Extractor
Webster Computer
MURS
Corporation
1 Padanaran Road
Danbury, Connecticut 06810
Telephone: (203) 744-6500
Starts at $2,500
* For Suppliers not included, or if listed supplier's information is
not up-to-date, please write to author.
Analyzer
Reports
Figure 4-PPE-General procedure
has tended to further strengthen the case for separation
of these two functions. Table II lists some software
monitors presently available.
The techniques of sampling as used in software
monitors are based on relatively straightforward
mathematical concepts. Assuming randomness (viz.
absence of synchronization) of observation with respect
to the events being sampled, the accuracy of the data
obtained is a function of the number of samples taken,
not the frequency of sampling. For example, monitoring
a one-hour program with a sample frequency of one-half
second, for a total of 7,200 samples, results in data
accurate to within 1.5 percent with a confidence level of
99 percent. The cpu cycle needs of an extraction
mechanism would be much less than 1 percent in this
instance. On the other hand, the "overhead" can run as
high as 20 percent with a sample frequency as small as
16 milliseconds.
824
Spring Joint Computer Conference, 1972
Code Execution Frequency for Each Interval
Starting
Location
Ending
Location
Interval
Percent
Cumulative
Percent
000000
000620
000690
000700
000770
0007EO
000850
000800
000930
0009AO
000B60
OOOBDO
000C40
OOOCBO
00061F
00068F
0006FF
00076F
0007DF
00084F
0008BF
00092F
00099F
000B5F
OOOBCF
000C3F
OOOCAF
OOODIF
0.00
7.39
0.0
1.56
15.59
13.94
12.58
2.39
3.41
0.0
1.28
1.84
3.45
.30
0.00
7.39
7.39
8.95
24.54
38.48
51.06
53.45
53.86
53.86
55.14
56.98
60.43
60.73
Histogram-% of Time (Each * = 0.5%)
4.0
.0
8.0
12.0
**************
***
*******************************
***************************
*************************
****
**
***
******
Figure 5-Partial sample of code activity histogram
An example of software monitor output is illustrated
in Figure 5. 38
These monitors are most useful when used on a job
mix containing programs which are either run frequently or which take a long time when run. The most
effective technique is to maintain a list of the top ten
"cpu cycle using" programs, and to continuously work
on these to reduce their cpu cycle time requirements.
As improvements are made on one, other programs
usually then move up the list for rework. This activity
coupled with configuration improvements can result in
very significant improvements to system throughput
rate.
FUTURE TRENDS
The practical application of hardware and software
monitors for improving EDP system efficiency has been
amply demonstrated in the past year or so. These
monitors provide a wide spectrum of detailed information on EDP systems, their workload and the
interactions between hardware, software (operating
system), and user programs. The potential for using
this information for the construction, validation and
use of EDP system models has not been realized. There
appears to be a need for EDP models for planning
purposes or for pretesting system changes suggested by
intuition or monitor use. The monitors by themselves
have limitations for planning future EDP systems.
There are a few indications that the "monitor people"
will add some simulation capability to their monitors.
For example:
Software adds important new capabilities to the
hardware monitor, significantly increasing the
usefulness, power and flexibility of such systems.
The first software specifically designed to
simulate hardware changes based on actual
measurements made by hardware monitors has
just been announced by Computer Synectics, and
deserves mention. In addition to the 16 hardware
accumulators provided by the hardware monitor,
this software provides 19 pseudo-accumulators
and time of day. A powerful set of operators is
provided to manipulate these pseudo-accumulators. Virtual simulation of a wide range of
possible hardware and software alternatives is
thus made feasible, which can give rise to
marked improvements in overall system performance, but based on recorded data about the
user's actual job mix and working environment
rather than on theoretical factors alone, and
before equipment is physically changed or
installed. A nd these advances are achieved without the inclusion of a minicomputer in the
hardware monitor.43
Recent research work by N oetzel44 conceptualizes a
design where a "meta-system" automates most of the
simulation functions fora system designer. This concept is illustrated in Figure 6.
The concept for such a system has been fairly well
Discrete Computer Simulation
Time-Sharing System
User
Tasks
1------. Output
System
Event
Trace
"t
Performance
Data
Ta'sk
Event Traces
Trial Modifications
Figure 6-META system design
detailed; the operational demonstration of such a
system has yet to be shown; and the economic feasibility of such a system remains dubious.
It appears that the next major step in EDP system
design methodology will be widespread. use of EDP
hardware and software monitors (in addition to their
normal operational use) as valuable sources of data for
EDP model construction and use. These models will
typically be implemented through use of generalized
EDP models such as SCERT or CASE, or through use
of high level software such as SIMSCRIPT, GPSS, or
HOCUS for customized models.
From a simulation viewpoint, these technological
changes taking place in the EDP system design area
are examples of what is being experienced in other
"hard" data areas such as finance, logistics and manufacturing. One can expect similar changes in the "soft"
data areas such as marketing, social, and oceanography
within the next decade.
In the coming decade, management personnel will be
increasingly involved in the development of simulation
models to assist them in making management decisions
at all levels. In the past, the false promise of the computer automating management decision making disillusioned many management personnel who have again
relegated the computer to routine data processing.
A pre-determined simple mathematical statement to
be minimized or maximized by a mathematical procedure inside a computer has, so far, turned out to be a
very poor substitute for the shifting sensitivity of a
good business executive to the implications of a decision
for many groups. There seems to be no alternative to
discussions with a variety of people in order both to
consider the trade-offs between various goals of the
organization and to get from the various parties the
commitment which is essential to the successful implementation of the decision.
But, as standard optimizing procedures, such as
linear programming, have been losing favor with
management, simulation concepts have been attracting
825
more and more interest-and will continue to do so.
The judgment of the manager plays a crucial role in
the formulation of most management-oriented models.
J\1any model interrelationships and variables depend
upon the intuition, experience and judgment of management. With the growing participation of management
in model development and use, further acceptance of
the technique and implementation of models at higher
levels in organizations is likely to follow.
This trend will be accelerated by an increasing
number of models which will be implemented via a
terminal into a time-sharing computer system. Often,
this terminal will consist of a CRT device with associated software for the display of model output data in
graphical forms. These technical innovations will
facilitate the direct participation of management in
model execution and modification. The next ten years
will be an exciting and productive era for simulation
techniques.
REFERENCES
1 H MARKOWITZ B HAUSNER H KARR
SIMSCRIPT: A simulation programming language
Prentice Hall Englewood Cliffs NJ 1963
2 P J KIVIAT R VILLANUEVA H M MARKOWITZ
The SIMSCRIPT II programming language
The Rand Corporation R-460-PR October 1968
3 H W KARR H KLEINE H M MARKOWITZ
SIMSCRIPT 1.5.
CACL CACL 65-INT-l Santa Monica California
June 1965
4 Users manual, general purpose systems simulator
IBM Corporation/360 OS Program No 5734-XSI 251 pp
1969
5 P R HILLS T G POOLE
A method of simplifying the production of computer simulation
models (HOCUS)
A paper presented to the Institute of Management Sciences
Tenth American Meeting Atlanta Georgia October 1-3 1969
6 D TEICHROEW J F LUBIN
Computer Simulation-Discussion of the technique and
comparison of languages
Communications of the ACM Vol 9 No 10 October 1966
7 M GREENBERGER M JONES
On line computation and simulation
The MIT Press 1965
8 J REITMAN
GPSS/360 Norden, The Unbounded and Displayed GPSS
Proceedings of SHARE XXX Houston Texas February 29
1968
9 J P HAVERTY
Grial/GPSS, graphic on-line modeling
The Rand Corporation P 3838 January 1968
10 M R LACKNER
Graphic forms for modeling and simulation
Presented at the 1967 IFIP Working Conference on
Simulation Languages Oslo Norway
11 R G CANNING
Data processing planning via simulation
(SCERT) EDP Analyzer Vol 6 No 4 pp 1-13 April 1968
826
Spring Joint Computer Conference, 1972
12 CASE-Computer-A ided System Evaluation
Technical Manual Computer Learning and Systems
Corporation/Software Products Corporation 1968
13 L J COHEN
System Analysis Machine-Introductory Guide
P-101-S ADRA upril 1970
14 R W GROTE et al
The Lockheed multipurpose simulation system (LOMUSS II)
Lockheed Document M-07-66-1 July 1966
15N R NIELSEN
ECSS: An extendable computer system simulator
RAND Memorandum No RM-6132-NASA February 1970
16 J W SUTHERLAND
The configurator, today and tommorrow
Computer Decisions pp 38-43 February 1971
17 G K HUTCHINSON J N MAGUIRE
Computer systems design and analysis through simulation
AFIPS Proceedings-Fall Joint Computer Conference
Vol 27 pp 161-167 1965
18 D S BURDICK T H NAYLOR
Design of computer simulation experiments for industrial
systems
Communications of the ACM Vol 9 No 5 May 1966
19 W G COCHRAN G M COX
Experimental designs
John Wiley New York 1957
20 D R COX
Planning of experiments
John Wiley New York 1958
21 F A GRAYBILL
An introduction to linear statistical models
Vol 1 McGraw Hill New York 1961
22 R W CONWAY
Some tactical problems in digital simulation
Management Science Vol 10 pp 47-61 October 1963
23 R E BECHHOFER
A three decision problem concerning the mean of a normal
population
American Statistical Association Meeting New York
N ew York December 30 1955
24
A single sample multiple procedure for ranking means of
normal populations with known variances
Annals of Mathematical Statistics Vol 25 pp 16-39 1954
25
A single sample multiple decision proce:1ure for ranking
variances of normal populations
Annals of Mathematical Statistics Vol 25 pp 273-289 1954
26 A M MOOD
Introduction to the theory of statistics
McGraw-Hill New York 1950
27 P G HOEL
Introduction to mathematical statistics
John Wiley New York 1954
28 A WALD
Sequential analysis
John Wiley New York 1947
29 A DVORETZKY I KIEFER J WOLFOWITZ
Sequential decision problems for processes with continuous
time parameter problems of estimation
Annals of Mathematical Statistics Vol 34 pp 403-415 1963
30 H CHERNOFF
Sequential design of experiments
Annals of Mathematical Statistics Vol 30 pp 770-775
September 1959
31 R A FISHER
The design of experiments
Oliver and Boyd London 1951
32 G S FISHMAN P J KIVIAT
Spectral analysis of time series generated by simulation
Models
The Rand Corporation RM-4393-PR February 1965
33 J W TUKEY
Discussion emphasizing the connection between analysis of
variance and spectral analysis
Technometrics Vol 3 pp 191-220 May 1961
34 H W KARR et al
&mOptimization research-Phase I
CACI 65-P 2.0-1 November 1965
35 E L LUTHER H M MARKOWITZ
SimOptimization research-Phase II
CACI 69-P2.0-1 July 1966
36 E L LUTHER N H WRIGHT
SimOptimization research-Phase III
CACI 69-P2.0-1 August 1969
37 J S COCKRUM E D CROCKETT
Interpreting the results of a hardware systems monitor
AFIPS Proceedings-Spring Joint Computer Conference
Vol 38 pp 23-38 1971
38 K W KOLENCE
A software view of measurement tools
Datamation Vol 17 No 1 pp 32-38 January 1971
39 S C DARDEN S B HELLER
Streamline your software development
Computer Decisions pp 29-33 October 1970
40 Problem program evaluator (P P E) user's guide
Boole and Babbage Inc Cupertino California March 1970
41 Configuration utilization (CUE) user's guide
Boole and Babbage Inc Cupertino California March 1970
42 B A LICHTIG
Nevada doesn't gamble on their computer, they measure it!
Unpublished Report 30 pp May 1971
43 C D WARNER
Monitoring: A key to cost efficiency
Datamation Vol 17 No 1 pp 40-49 January 1971
44 A S NOETZEL
The design of a meta-system
AFIPS Proceedings-Spring Joint Computer Conference
Vol 38 pp 415-424 1971
The emergence of the computer utility
by R. S. MANNA
Robert Manna Associates
Dallas, Texas
and
H. W ALDBURGER
University Computing Company
Dallas, Texas
and
D. R. WHITSON
Datotek, Inc.
Dallas, Texas
HISTORY
cilities were provided inside the computer room;
scratch tapes were immediately available; and engineers were assigned to maintain the hardware.
As computers grew in capability· and cost, the opportunity for individual control lessened. The price of
user convenience became too high. A way was sought
to increase the productivity of the computer. Uncorrelated service routines such as memory dumps, loaders,
compilers and assemblers were brought together under
one supervisory program. By the early sixties supervisory programs were gaining control of the operational
environment of the computer, causing the activities
once manually performed in the "hands-on" mode to
now be performed "hands off." System utilization
increased, and by superficial measurement, increased
systems productivity claimed. However, user productivity suffered. Runs frequently were aborted due
to an improper monitor control statement, user awareness of the event following hours after its occurrence.
Large and frequent core dumps, whose processing consumed equipment and increased turnaround, were
taken in order to trap in print much of what once had
been observed by eye. These and similar events discouraged the installation manager because, in spite of
a highly efficient operation, his stated goal-increased
overall productivity-was missed.
Multi-programming and rotating machinery, i.e.,
drums, discs, etc., offered some relief to what had become an intolerable situation. Processing files from
drums and discs reduced tape utilization, and improved
By 1970 some users had regained control of the
computer. This occurred because an operational mode
had come into existence that permitted the man and
the computer to simultaneously attain the productive
heights that each had previously, but separately,
achieved. The installation of this mode was prompted
by the results of analyzing the computing environment
of the late 1950's and early 1960's.
Scientific computer installations circa 1960 operated
in an environment in which computer runs, or "shots",
were pre-scheduled, making the total system responsive
to the individual who had "hands on" control of the
machine. He was permitted to stop processor execution
at some pre-set memory or instruction cycle, insert
changes via the console, manually position tapes, take
and immediately print snapshot dumps, relocate I/O
channels, and isolate hardware failures. The total resources of the installation were provided to achieve
this mode of man and machine interaction that resulted in high user productivity.
Business oriented installations had a less personal
environment because of the production, rather than
developmental nature of their work. However, production runs did require manual intervention because the
processing cycle generally consisted of a progressing
chain of separate events. Consequently, in both situations, operators were designated to service the printer,
punch, reader, and other peripherals; keypunch fa827
828
Spring Joint Computer Conference, 1972
channel usage between main and auxiliary storage.
lVIulti-programming systems provided for a more efficient use of the processor to process data and to service
peripherals. Multi-processing held out the promise of
lower cost through peripheral sharing, processor backup,
and abundant capacity for special processing requirements. Extremely high system utilization was achieved,
but the user was still forced to negotiate with the
computer in a "hands-off" mode. This meant (1) he
was unable to address the system except by those
devices resident within the computer room; (2) he was
forced to predict and prepare for all possible events
that could occur during the execution of his program;
and (3) his employment of the computer was through
a manual operations procedure not under his control.
THE UTILITY
Early form
The effort that surmounted this impeditive mode
was the imaginative coupling of software, hardware
and communications capabilities into systems designed
to accommodate remote access and user interaction
and to remove manual intervention. The card reader,
printer, and keyboard, in becoming terminals, offered
to bring the computer to the user. Simplified and welldesigned control languages and file editors made access
to processor and files more convenient and approachable. A teleprinter became an on-line keypunch as well
as an input and output station; card readers and high
speed printers were available when needed, and no one
intervened. The user at his terminal was regaining the
position of control he had enjoyed previously when he
processed from within the computer room. A computer
could now be utilized in a convenient and productive
manner from wherever its many concurrent users were
located. 1 The utility had its beginning.
Operational problems
Initially, this new operation mode was accompanied
by new operational problems. Field maintenance, essential for terminal up-time, was POOl'. Existing tape
library management was inappropriate because run
request forms no longer existed. Operator console
messages were frequent, untimely and ambiguous. Data
communications were unreliable, undocumented and
without established operational procedures. Central
site hardware maintenance was difficult to schedule,
because output remaining to be transmitted was resident to and controlled by the central processor. Errors
were difficult to trap because of the urgency in continuing on-line communications. Recreating errors was
impractical because the dynamic status of the environment at the time of failure was unknown. Changes to
the monitor system were difficult to te~t because of the
lack of experience about the environment in which they
would exist. Preparation, distribution and user notification of changes was nightmarish.
Central site power was increasingly consumed by
terminal devices whose individual throughput was less
than the central site devices they replaced. Early experience demonstrated a dramatic mis-match between
terminal speed, line speed and processor speed. The
processor became output bound, precluding any computational activity or the acceptance of any additional
input requests. The first action taken to alleviate this
problem was to add additional storage capacity for
I/O buffering. This solution did not accelerate the
throughput of the system but merely delayed the point
at which the system again became output bound, causing
another calamity-delay in turnaround time. In addition, timely communication between the remote
terminal operator and the central site operator, essential, for example, in order to suspend output to replenish printer paper, make forms changes, or correct
terminal malfunction, was non-existent. Numerous
tape mounts caused severe operator intervention,
adding to central processor idle time. Queueing was
primitive and a run requiring seconds of execution
could find itself behind a half-hour run, and/ or its
output stacked behind three hours of printing. Adding
to the upset was the absence of data security and
privacy that contributed to lost and misdirected files.
Solutions
The introduction of communications subsystems
solved some of these problems. The communications
subsystem consisted of a small processor especially
programmed to manage the communication between
the central computer and the remote terminals. Data
compression, site verification and operator communication were among the tasks well performed by this
subsystem. Communications handling was thus removed from the central processor.
Separate queues were established in the central
processor for tape and non-tape runs, as well as for
long and short runs. Tapes were pre-mounted before
run execution and short non-tape runs were executed
on a regularly scheduled interrupt basis. I/O files were
site code identified and terminal verification was established before data transmission began. Notice of
Emergence of the Computer Utility
changes to the system was included in the transmission
to each terminal site. Hardware selection centered
around the computational and the communications
processors. The computational processor was selected
according to maintainability, reliability, instruction
repertoire, execution speed, and other historically
accepted criteria. The communications processor, in
addition to the above, was selected on its ability to
easily handle multiple and dynamically switched
priorities, to accommodate various speeds and dissimilar modems, as well as readily interface with multimedia mass storage devices.
Measurement
Instrumentation was installed to measure system
productivity and to determine the profile of the most
avid, and therefore, perhaps most productive user.
Among the data collected were (1) execution time vs.
output volume, (2) tape vs. no-tape runs, (3) average
number of tapes per tape run, (4) terminal media by
which runs were submitted, (5) time of day for heaviest
traffic, (6) connect time vs. execution time, and many
other criteria independent of and integrated with these.
The analysis of these data revealed that more efficient utilization of the system was achieved. There
was less idle central processor time, faster response to
more users, timely operator communication with the
terminal site, and much improved tape procedures. The
analysis also suggested tha t the configuration of a
computing system could be optimally adapted to a
given job mix. The utility's most productive Ufer
worked in an engineering discipline, demanded minimal input/output, was remote batch oriented, executed
his own applications, and was substantially independent of operations personnel. This user regained
hands-on posture, essentially because he was autonomous in his operating mode. From his terminal he
initiated and resubmitted runs, made his own corrections at his own pace, and therefore bypassed the
impeding nature of a manual operations procedure. He
worked in his habitat and he shared with and solicited
comments from those with whom he worked. His need
for printed output, especially during debugging, diminished as did his need for punched card files.
Extending the service
Enthusiasm within the utility community grew as
more operational problems were resolved. This enthusiasmattracted another class of users who had an
opposite profile to the earlier class. This new user re-
829
quired numerous tape files, voluminous print files, forms
changes, reprints, punched card output; and other
services requiring manual intervention. This user
executed runs that had a much higher ratio between
I/O and processor time (e.g., 40:1 compared to 8:1),
and he represented a group whose computing dollar
expenditure was greater than 90 percent of the total
expenditure of the computing community.
This business data processing user could only partially
capitalize on the increased productivity offered by the
computer utility because of the above stated characteristics of his work profile. The design legacy bequeathed his program, many of which could trace
their roots back to the single function, manual step
mode of unit record equipment, contributed significantly to this profile. lVIuch of the manual processing
flavor of these systems remained when conversion
occurred. Operational compatability for some of these
systems during their conversion from unit record
machines to computers was, in fact, a major consideration. Furthermore, indeterminate output delay, due
to a data communications failure, was sufficient cause
to create a sense of real time urgency in payroll departments, and the possibility that company data
could be compromised without detection was intolerable. Continuing investigation to understand these
problems brought the utility user's profile into sharper
focus. For example, a geologist programmer required
multi-media output and the data he processed was, to
him, urgent and private. Business programmers also
did "compile-and-go" testing. Thus it became apparent
that this was not the case of the engineering vs. business user, but rather the case of the autonomous vs.
the non-autonomous user.
Work began in two areas to provide for the inclusion
of the non-autonomous user. At the central site additional file processing schemes were installed. Print
files were spilled over from drum to tape in background
mode for subsequent low traffic distribution. Store and
forward service was introduced permitting daytime
transmission and nighttime execution of the run, or
vice versa. Rotating machinery for additional buffering,
as well as higher speed and full duplex lines for more
rapid transmission, were added to the communications
subsystem. Te:cminal site soft-ware was modified to
facilitate additional operator communications and to
service the equipment needed for local peripheral
processing.
CURRENT STATUS
By now, computer installations operating in a
utility mode employ several million miles of communica-
830
Spring Joint Computer Conference, 1972
tions lines serving over 200,000 keyboard terminals,
and over 20,000 high speed card reader/printer terminals. User productivity was the objective of the
early installations. The growth in the number of
computer utilities is attributable to that objective
being met, to increased user sophistication, and to
realized additional value by the installation manager.
Users continue to become more aware of the computer's value and less concerned with the computer.
The utility provides a means by which the user can
gain convenient access to the maximum contemporary
computer power he requires. Company or department
size may have little relation to the size of the computing
problem at hand. With the commercial utility, a small
firm has access to a resource similar to that available
to the large corporation. With the in-house utility, all
users within the organization have the opportunity to
capitalize on the total computing resources available.
There are several values realized by the installation
manager. First, there is the reduction in shake-down
time of new systems software and a manpower savings
due to centralized software maintenance. Centralized
usage being at least equal to the sum of the usage of
previously individual sites causes bugs to show up
sooner, and when the bug is fixed, it is fixed for everyone
simultaneously. Second, there is a low cost opportunity
for expansion. Additional capacity can be added to a
utility operation on a cost basis distributed throughout
the user network. And, this expansion provides a low
cost opportunity for back-up heretofore denied individual sites. In addition, there are savings in the
overhead costs such as physical plant, hardware maintenance, site security, and parts inventories.
And, finally, there is the opportunity to focus resources on the challenges of the future. Among these
are (1) low cost reliable data communications, (2)
simpler user file processing procedures, (3) more
efficient on-line mass storage, (4) pricing, (5) data
privacy and security, and (6) effective I/O file processing.
SOLUTIONS IN PROCESS
Items (1), (2) and (3) of the preceding paragraph are
receiving abundant attention. However, pricing remains
as much a challenge to explain as to accomplish. Clearly,
a utility user's job consumes time and space within
the processor and the communications subsystem,
space on peripheral storage devices, channel time to
move data to and fro, communications lines and
terminal devices. Further, there is the question of
continuous operation and priority requests for critical
needs. A multi-environment (user/processor) exists
that precludes use of the historical time quantum and
storage allocation pricing scheme. Determining the
profile of the utility user and the effect this profile has
on the total system is necessary in order to achieve
efficient operations and precision pricing. A unit of
cost based on user value discernible prior to execution
and consistent within reasonable tolerance seems to
be in the offing. 2
Data privacy is in its own right an emerging industry
being prodded into existence because of the sheer
dollar value at risk. Corporation data and computer
programs are assets with high determinable value.
Schemes and procedures for the protection of these
assets are, for many installations, non-existent and,
often where present, inadequate. The installation
manager faces a severe challenge in finding the procedure to achieve data privacy and security. Within
this procedure must be the means to prevent accidental
and deliberate acts that destroy or jeopardize the
storage, processing and retrieval of data. 3 And this
protection, this electronic 10ck4 that may include cryptographic enciphering of files, must be installed without
restricting or encumbering authorized user access. The
security procedure must control physical access to the
computer room, tape library and card file room, audit
installation transactions and encourage a general
security consciousness in installation personnel.
Speedy I/O handling is as critical as the processing
of the data. Transmission queueing and intermediate
storage of the terminal I/O files are among the significant factors contributing to the complexity of the
developing I/O processing solution.
SU1VIMARY
As the past has demonstrated, solutions to processing
problems will be found and, in turn, will provoke
imaginative new ways to consume the power of the
computer. This being the case, the installation manager
will continue to face the decision of what operational
mode his installation should employ. The utility makes
access to contemporary and consummate computer
technology simple and convenient, removes the geographical limitation of those working in cooperative
efforts, and frees talent for creative activities by
automating clerical procedures.
The economic value concomitant with these achievements, whether it be yield on the utility investment
or quality of the final product resulting from the
availability thereof, will be left to the determination
of the reader.
Emergence of the Computer Utility
The utility has emerged. As it matures it will move
closer to the realization of its potential which is to
bring the value of the computer to all who request it
wherever and whenever they desire.
REFERENCES
1 F J CORBATO M M DAGGETT R C DALEY
A n experimental time-sharing system
Proceedings of Spring Joint Computer Conference 21
Spartan Books Baltimore 1962 pp 335-344
831
2 M SEVCIK H W ALDBURGER
Ein Verfahren zur quantitativen Berechnung der
Computerleistung und -energie
Neue Technik Zurich Switzerland Nr A6 November 1970
3 J M CARROLL P M McLELLAND
Fast 'infinite-key' privacy transformation for resource-sharing
systems
AFIPS Conference Proceedings Fall Joint Computer
Conference Vol 37 pp 223-230 1970
4 D R WHITSON
Computer data privacy
Speech presented before National Secretaries Association
Seminar Dallas Texas 1970
Installation management-The next ten years
by RONALDM. RUTLEDGE
Carnegie-Mellon University
Pittsburgh, Pennsylvania
INTRODUCTION
the problem in the latter part of this generation.
By using remote job entry stations, most customers no
longer required their own computer nearby to get
adequate computing service. In this generation the
installation manager had to face up to the full problems
of being a production specialist, a resource accountant,
a businessman and a technocrat.
In what we now view as the fourth and present
generation at Carnegie-Mellon University the distinction between the generations becomes hazier. We will
list the main characteristics of this generation. Awareness that computers cost large sums of money and that
poor utilization is not uncommon here become permanent issues with the economic decline. The possibility
of inexpensive mass secondary storage is becoming very
real and in some cases is almost here. At times our
complex systems appear to be working stably. Computer installations are no longer simple one machine,
one vendor sites.
Telecommunication is now as big a problem as the
computers and people are asking what they are getting
for their dollar rather than how fast they can get the
next piece of equipment.
The fifth generation we project will be characterized
by low cost mass secondary storage, so inexpensive
and efficient that tape drives will become uneconomical
to use in many cases. Telecommunications will be
reliable and economical, so that we will not hesitate to
use a computer at the opposite end of the country.
Time-sharing systems will actually work reliably. No
one will take note of using the system with several
hundred people on it. Computer installations will
become rather amorphous entities consisting of complex inner connections of many different CPUs'
memories, and various storage devices.
In the fifth generation, management information
systems will become paramount. Low-cost mass storage
will make implementation easy and the interconnections
of networks will make distributive data bases a reality.
The challenges in the coming years are put into the
In this paper we will give our extrapolation of the
exciting challenges facing installation managers in the
coming years and how we expect to react to these
challenges. We view the evolution to the present
stage as having gone through three generations of
installation management. The first generation was
marked by the early computers with small memories
and relatively crude input devices in which the operation of the computer was done mainly by the person
using the computer. In this early generation the
computer installation manager had the hardy pioneer
spirit and knew most of his customers by first name.
One of his main worries was how fast he could get the
next model of the computer.
The second generation was marked by the introduction of tape operating systems and some primitive
disc systems which required that the person operating
the computer be very nimble and able to react quickly
to the need for changing tapes so that computer utilization would not drop. In that generation the customer
moved away from being in direct contact with the
computer but there were still many customers who
used the computer directly. Input and output were
becoming a problem. The installation manager now
had to start worrying about planning the layout of the
I/O area carefully and was looking forward to the
coming generation for order of magnitude improvements.
In the third generation we found the introduction of
multiprogramming facilities through the use of primitive drums and improved disc facilities. And here, as in
the second generation, the need for competent operation of the equipment became of increasing importance.
One then had many jobs requiring tapes and discs
running at the same time. The I/O problem increased
even further and the great hope of eliminating it
through terminal access was dismally smashed. The
utilization of remote job entry stations did finally ease
833
834
Spring Joint Computer Conference, 1972
reference framework of cost effectiveness. Cost effectiveness is the main theme of our management's
interest and it should be and probably will be the
main theme for the foreseeable future.
By meeting some of the challenges mentioned,
Carnegie-Mellon University (CMU) was able to cut its
Computation Center costs by 40 percent and at the
same time improve service, deliver more computing
power, and increase customer satisfaction in a short
period of a few months. Some details of this accomplishment have been covered elsewhere. 1 In our experience,
innovation and implementation of automation is not
an easy straightforward process, but the challenges can
be met.
PERSONNEL AND ORGANIZATION
One of the largest voids in today's information
processing technology is the lack of qualified educators
to train the personnel we need. The ACM Curriculum
Committee on Computer Education has presented
reports2 •3 which will probably form the foundation of
many curricula for training our future personnel.
The increasing complexity of the computer installation requires a shift to more technically competent
personnel for daily operations. Unfortunately this
shift in general has been too slow and many present
installations suffer with reduced productivity due to less
than optimally trained personnel.
Several years ago there were studies4- 7 which revealed that the difference in the, productivity of programmers can be an order of magnitude. *
Unfortunately, evaluating programmers3 remains in
a state of witchcraft. We cannot hire enough experienced programmers, and we are willing to train or hire
inexperienced persons. Hopefully, by evaluating them
over a period of employment, we can get a few very
good ones from the crop. eMU receives big dividends in
minimizing the actual number of personnel while
maximizing on the competence of individuals. In other
words, the incremental cost of properly compensating
the excellent programmer is well worth the price if we
are lucky enough to have him.
The actual organization of a computation center is
not so important since the organization should reflect an
attempt to optimize the contributions of the individuals
and inter-personal relationships with respect to the
objective function of the group. Therefore, one would
* These studies were attempts to evaluate the relative merits of
time-sharing versus batch processing as a means of programming.
Although the intended results were inconclusive, the wide range in
programmer productivities was repeatedly demonstrated.
reasonably expect the organization to change in time
as the different members of the team come and go.
Though the usual organizations are somewhat reluctant
to be highly dynamic, the rapid change in the advancement of information processing technology presently
allows one to have a flexible organization without having the appearance of a continual card shuffle.
At CMU the shift to better qualified personnel has
taken the route of the control center concepti with the
elimination of the usual operations groups. The computation center staff sections are hardware, information,
and software systems and with few exceptions every
professional takes his turn being in charge of the control
center. The programmer in charge of the control center
may have as many assistants as the load requires.
This approach is parallel with more automated operations requiring more technical skill and has significantly
reduced operating costs. Better service and a more
stable system result because of the increased technical
ability of the personnel in charge to answer inquiries and
react to contingencies.
Personnel are the only important resource. Whatever
machine we have today will certainly be outdated in
five years whereas our personnel will be more valuable
in five years if we give them the proper motivation to
keep abreast of our challenging field.
THE EXECUTIVE GAP
Most computer installations are a part of a greater
organization which the installation serves. With the
increasing utilization of computing resources the importance of the installation to the parent organization
is increasing. The rising costs of these computing resources to the parent have forced many organizations
to recognize the need for an executive position with the
responsibility for coordinating and integrating the
organization's computing resources. This executive
must be technically and administratively competent.
In most organizations today there is not an executive
position with adequate technical competence for the
magnitude of importance of the organization's computing resources. One or more installation's managers
have been given default technical responsibility without
proper administrative authority for effectively handling
the responsibility. One common symptom of this
executive gap is separate computer installations for
"administrative" and "scientific" computing. The
managers and their organizations who recognize and
react to this common gap in their executive structure
have much to gain in better utilization and reduced
total costs.
Installation Management-The Next Ten Years
Until the executive gap is filled the installation managers must understand the requirements of the organizations they serve as well as keep abreast of computer
technology if their service is to be efficient. This requirement of having an executive position which must
be alert to developments in the rapidly changing computer technology is one of the toughest challenges to be
met if our organizations are to receive the proper
benefits of our technology.
CONFIGURATIONS
Will the small computer installation disappear and
be absorbed by the giant emerging ones or will a small
computer installation have a place in the future?
The answer to this question obviously depends on the
circumstances. Just as a small switchboard has a place in
our present day telephone system, there are many
circumstances where the small switchboard· doesn't
belong. In our projection it will be more than ten years
before the small computer installation is really threatened in the same way as a small telephone switchboard.
Certainly the installations that will exist over the next
few years will become more amorphous entities rather
than one single CPU or one single manufacturer.
Reliability will be markedly improved 9 through new
, circuitry, 10 improved hardware technology,ll and better
software. 12 ,13 Emerging large mass storage systemsl4 ,15
will permit a greater degree of automation and accommodate the developing management information systems. The general population is beginning to understand
the basic principles16 of machine configurations. We
now have our first book characterizing in a systematic
way the various computer structures,17 The minicomputers won't replace the large CPU's but they will
certainly supplement and complement them. Every
large CPU probably will have numerous minis around
in various functions for which the larger CPU is less
cost effective. 18
NETWORKS
Computer networks19 are another area in which the
small computer installation is threatened by replacement with a remote job entry facility or a few terminals.
This will eventually happen, but we certainly do not
think it will be in the next few years. It is, however,
definitely a possibility in five to ten years. Communication 20 ,21 problems have held the development of networks back many years. However, the great thrust
provided by the underwriting of the ARPA Network
835
has provided the enthusiasm for exploring the present
potential of networks. 27
Actually there.will be two forms of networks, the
local network and nonlocal or long distance network.
There are many advantages to local networks which
haven't been properly realized by the installation
manager. Many installations have various computers
with duplicated hardware and software facilities.
The linking of local computers and the reduction of
redundant facilities will result in the elimination of
duplicate costs and also in increasing cost effectiveness
because jobs will be easy to run on the appropriate
machine. This was successfully accomplished recently
at eMU with sizable cost saving (capital and operational), increased effectiveness, and added functional
capability for the customers which formerly used each
system as an independent entity.1
Also the reliability of the total installation will be
improved since one can transfer a job more easily from
one machine to another. The non-local or long distance
networks will satisfy peak load demands and actually
permit installations to run at a greater average capacity
because they will not have to have an excess capacity to
satisfy peak loads. The result will also be an increased
cost effectiveness. The non-local networks will allow
each instal1ation to give one stop service to a broad
spectrum of functions which will be available through
the networks to which it is connected.
RESOURCE ACCOUNTING AND CONTROL
The measurement of computer systems has now come
of age with the first annual workshop on software
system performance evaluation held last year28 and
installations are developing their own means of implementing primitive measurement facilities. In the
coming years manufacturers may actually supply
measurement facilities as parts of the standard system.
We should not have to buy a computer as though it
were a car without a speedometer or gas gauge or odometer. The question of pricing,29 cost accounting, and
the administration of computer resources* is now
considered an integral part of the resource accounting
and control schemes. 30 ,31 The marketplace will demand
the facilities to measure and record utilization. Whether
one should lease or buy and how and why one should
write. off .purchased equipment is a commonly discussed issue. The marketplace will discover that
* With proper accounting and pricing sometime during the coming
years we will stop referring to our customers as 'users.' The label
'user' has adverse psychological effects for the 'user' and the ones
'used.'
836
Spring Joint Computer Conference, 1972
purchasing equipment and using some sort of declining
balance depreciation is the proper and logical way to
cost account for equipment resources of a changing
technology.
can go to third party for maintenance of their standard
operating system and have more options to buy software
packages built to order for them.
CONTRACTS AND LAW
HARDWARE PROJECTS AND MAINTENANCE
This area is becoming a challenge due to the increased
in-house capability of installations not only to maintain
but also to fabricate and enhance their equipment. The
recent emergence of the 'Brand X' peripherals has
created a problem in many installations with multivendors. Now the installation requires at least one
person competent in hardware logic to minimize the
potential conflicts between various vendors. For those
with the capability, a potential savings of some magnitude exists for in-house maintenance of equipment. 1
But for those who do not prefer this route there are
third party vendors who will furnish maintenance for
various manufacturers' equipment.
SOFTWARE PROJECTS AND MAINTENANCE
Software still continues to be one of the biggest
challenges. The Third AGM Symposium on Operating
Systems32 last year gave us the impression that perhaps
operating systems were now being comprehended.
In general we are beginning to see logical structures
and approaches to putting systems together. Three
annual conferences have been held on software engineering. Their accompanying proceedings33- 35 project that
an emerging profession is developing in software
engineering. In the next few years we will even be
getting the handbooks or cookbooks which will tell our
software engineers what pieces to use for the type of
system we want to put together. The education,
training, and development of programmers and operators is still somewhat of a controversial subject. 36
Some curricula are becoming standardized and our
first book on management· of computer programming
was recently published. 37 Perhaps people have not
learned that we still have to develop the art of managing
a large software project. It has been our experience that
the project employing more than three programmers
is likely to have serious problems without careful
structuring of the project38 and software. 39 With the
continual unbundling that is occurring perhaps the
vendor software groups will have to stand on their
own or face up to competition from the outside. Then
the quality of the vendor software will be improved
or the purchaser will not opt to take it. This will
hopefully create more competition where installations
Contracts40 and law unfortunately tend not to be
recognized as the challenge they are, although many
of us have recognized this the hard way. Monopolistic
tendencies of the various competitors in the marketplace require the installation manager to have an understanding of the Antitrust Laws. 41 The field of law is
also now becoming aware 42 of the particular requirements of the computing technology.
STANDARDS
An old and difficult challenge is still with us. The
emergence of the networks has shown that if the networks are going to work, which they surely are, people
will be forced to use standards. 43 The developing of
microprogramming44 capabilities hopefully will allow
not only better standards but also allow a standard
operating system which would run on most computers
and still allow the computer to have its own unique
capabilities.
COMPETITION IN THE MARKETPLACE
Do you really have competition in the marketplace?
With the folding of RCA Commercial Computer
Division and with GE electing to get out of the field,
some think that competition is decreasing rapidly to
zero. Of the many and various extreme views on this
subject one of the more moderate was expressed by
Larsen. 45 He said, "Hurting IBM is easy; solvingnational problems is tough and difficult. A good solution
requires all of the business and technical skill at the
industry's disposal. It also requires that we care-not
about IBM, but about the United States, if we are to
keep the United States in its lead of the computer
technology." Larsen, unfortunately, did not cover the
case of an international monopoly.
The real question is whether or not our workable but
competitive system gives the marketplace a fairly
priced and up-to-date product. If one company spends
more on research and development than most of its
"competitors" gross46 is it possible to compete rather
than just trail behind and subsist on leftovers? Could
Fortran and OS/360 have survived in a free and knowledgeable marketplace? How many installations have
Installation Management-The Next Ten Years
computing contracts tailored to their requirements and
explicitly hold their vendors liable for failure to deliver
as promised rather than the "standard" contract
loaded with the "come hell or high water the installation
will pay the vendor" clauses? Does the installation
have the engineering specifications for equipment worth
millions? What can the installation do if its equipment
is not maintained properly? Go to another company
for maintenance? We must decide if the answers to
these and many other such questions are satisfactory.
If the answers are not satisfactory then one of the most
difficult and important challenges facing us is what
to do to obtain a marketplace where the competition
benefits the customersY
The motivation behind present day monopolies is
not usually the hungry greed of the communist's
stereotyped capitalist, but rather nothing more than
the desire for the easy life (i.e., a secure well-paying job).
To quote Judge Wyzanski,48 "Some truth lurks in the
cynical remark that not high profit but a quiet life is the
chief reward of monopoly power. And even if a particular
enterprise seeks growth and not repose, an increased
rate in the growth of ideas does not follow from an
increased concentration of power." This understandable
motivation permeates the bureaucracy of the monopolistic organizations with the result that the monopoly
power is not overtly exercised by anyone individual
but by a collective effect sometimes expressed as, "It is
our policy" , "We must treat everybody the same", or
"We can't make exceptions". The salesman representing
the monopoly, though benefiting from the monopoly,
is quite helpless at combating his company's policy.
This indirect collective effect can only be effectively
changed by collective effort .. Why can't the customer
groups make their own standard contracts?
The Justice Department has historically acted very
slowly on monopoly power. The large organizations
with power to act do not want to "cast the first stone."
The small installation cannot afford the time and
money, and may times is justifiably afraid to fight. A
giant organization is a fierce and ruthless opponent49
but our obligation to society demands that if we decide
detrimental monopolies exist, then we must face the
challenges.
MANAGEMENT INFORMATION SYSTEMS
Corporations and private communities are recognizing the need for and the potential benefits of being
able to make more informed decisions through the use
of computers. Unfortunately these areas perhaps have
been the hardest to penetrate due to the classical con-
837
servatism of the management 50 which will use these
systems. Operating systems have not been outstanding
successes in delivering past promises, but now that
operating systems have become reliable, many different
management information systems exist. Businesses are
demanding the implementation of systems. 51 ,52 In
fact the Government 53 feels they are absolutely essential
to the future of the congressional operation.
INNOVATION AND AUTOMATION
Innovative operations through automation should be
the theme of the installation manager. He has at his
disposal the machines which represent enormous
advances made in automated processes and which, by
means of information systems, have furnished us the
ability to make informed decisions.
Why hasn't the installation been able to exemplify
the pinnacle of automation and innovation by allowing
the machine to control the routine operations? With
our society's becoming suspicious of computers54 and
their encroachment upon privacy, installation managers
will have to be innovative to impress society 55 that the
powerful facilities are in competent hands. In the postindustrial 56 era, with information doubling every 12
years,57 the challenge of keeping track of one's own
installation will continue and should be met with our
own technology.
SUl\1MARY
Innovation and automation: with this as the theme of
our coming years, the installation manager should set
the goal of making his installation the pinnacle of innovation and automation. He will have to be prepared
to justify to management not only that his present
equipment is cost effective but that what he proposes
to get in the future will improve the installation's cost
effectiveness. Management is forced to recognize
the large cost that information processing technology
is now starting to represent with respect to the organizations' total budget. We are all very lucky to be a
part of this exciting era but we must not make the
mistake of leaning so much on our lessons of the past
to extrapolate our actions into a very innovative and
challenging era which may be totally different from our
past experience.
ACKNOWLEDGMENTS
Although the director prepared this paper, the Computation Center Staff originated many of the ideas
838
Spring Joint Computer Conference, 1972
presented here, and their exceptional competence and
exemplary dedication made possible this exploration
and the actual utilization of some of these ideas.
REFERENCES
1 H B ROWELL JR R M RUTLEDGE
E SCHATZ
Management control
Proceedings EDUCOM Spring Conference 1971
2 ACM curriculum committee on computer education for
management education related to the use of computers in
organizations
Communi3ations of the ACM Vol 14 No 9 pp 573-588 1971
3 J L McKENNEY F M TUNGE
The state of computer oriented curricula in busin'.!ss schools
1970
Communi ~ations of the ACM Vol 14 No 7 pp 443-448 1971
4 M M GOLD
Time-sharing and batch processing: An experimental
comparison of their values in a problem-solving situation
Communications of the ACM Vol 12 No 5 pp 249-2591969
5 H SACKMAN W J ERIKSON E E GRANT
Exploratory experimental studies comparing online and
offline programming performance
Communications of the ACM Vol 11 No 1 pp 3-11 1968
6 L B SMITH
A comparison of batch processing and instant turnaround
Communications of the ACM Vol 10 No 8 pp 495-5001967
7 M SCHATZOFF R TSAO R WnG
An experimental comparison of time-sharing and batch
processing
Communications of the ACM Vol 10 'No 5 pp 261-2641967
8 R ARMSTRONG R BERGER L FERRETTI
J NICKERSON J M PALERMO
A panel session-People-Selecting and evaluating the
computer workforce
Proceedings ACM 70 pp 21-27 ACM 1971
9 Special Issue on Fault-Tolerant Computing IEEE
Transactions on Computers Vol C-20 No 11
10 J S GOLD
On automatic testing of online real time systems
Proceedings SJCC 1971
11 T KURODA T C BUSH
Multiband automatiG test equipment-A computer controlled
checkout system
Proceedings SJCC 1971
12 S A SZYGENDA
Cod'tng techniques for failure recovery in a distribution
modular memory organization
Proceedings SJCC 1971
13 D L DROULETTE
Recovery through programming system/360-system/370
Proceedings SJCC 1971
14 R B GENTILE J R LUCAS JR
The T ABLON mass storage network
Proceedings SJCC 1971
15 M SAKAGUCHI N NISHIDA T NEMOTO
A new associative memory system utilizing holography
IEEE Transactions on Computers Vol C-19 No 12 pp
1174-1180 1970
16 M J DURAO JR
Finding happiness in ... extended core
Datamation Vol 17 No 16 pp 32-34 August 15 1971
17 C G BELL A NEWELL
Computer structures: Reading and examples
McGraw-Hill 1971
18 C G BELL A NEWELL F P BROOK JR
D B G EDWARDS A KAY
A panel session-Computer structure-Past, present and
future
Proceedings FJCC 1971
19 C G BELL A N HABERMANN J McCREDIE
R M RUTLEDGE W WULF
Computer networks
Computer Vol 3 No 5 pp 13-23 1970
20 R G NYSTROM L M PASCHALL
J M RICHARDSON W J SULLIVAN
A panel session-Communications:
Challenges of the
seventies
Proceedings ACM 70 pp 34-43 ACM 1971
21 W M ELLINGHAUS J HENGEL D F FOSTER
J K LADY R H McCONNELL
W G McGOWAN
A panel session-Communications: Data transmission
Proceedings ACM 70 pp 44:-58 ACM 1971
22 L G ROBERTS B D WESSLER
Computer network development to achieve resource sharing
Proceedings SJCC 1970
23 F E HEART R E KAHN S M ORNSTEIN
W R CROWTHER D C WALDEN
The interface message processor for the ARPA computer
network
Proceedings SJCC 1970
24 L KLEINROCK
Analytic and simulation methods in computer network design
Proceedings SJCC 1970
25 H FRANK I T FRISCH W CHOU
Topological considerations in the design of the ARPA
computer network
Proceedings SJCC 1970
26 C S CARR S D CROCKER V G CERF
HOST-HOST communication protocol in the ARPA network
Proceedings SJCC 1970
27 R M RUTLEDGE A L VAREHA L C VARIAN
A H WEISS S F SEROUSSI J F JAFFE
M A K ANGEL
An interactive network of time-sharing computers
Proceedings 1969 ACM National Conference
28 Proceedings ACM SIGOPS Workshop on System
Performance Evaluation Harvard University 1971
29 N R NEILSEN
The allocation of computer resources-Is pricing the answer?
Communications of the ACM Vol 13 No 8 pp 467-474 1970
30 R HARRIS J NOERR T W RINEHART
C E SKIDMORE
A panel session-Management: Administration of computer
system resources
Proceedings ACM 70 pp 351-353 1971
31 L L SELWYN
Computer resource accounting in a time-sharing environment
Proceedings SJCC 1970
32 Proceedings ACM Third Symposium of Operating Systems
Principles Standford University 1971
Installation Management-The Next Ten Years
33 P NAUR B RANDELL
Software engineering
Report on a Conference Sponsored by the NATO Science
Comm'ttee Garmisch Germany October 1968
34 J N BUXTON B RANDELL
Software engineering techniques
Report on a Conference Sponsored by the NATO Science
Committee Rome Italy October 1969
35 J T TOU
Software engineering
Vol 1 and 2 Academic Press 1970 1971
36 D ABE J D BENENATI H CADOW
R S McKENTY
A panel session-Education: Training and development of
programmers and operators
Proceedings ACM 70 pp 89-95 1971
37 G F WEINWURM
On the management of computer programming
Auerbach 1970
38 F T BAKER
Chief programmer team
Proceeding of SHARE XXXVII Vol 1 pp 240-251 New York
August 1971
39 E W DIJKSTRA
The structure of the The multiprogramming system
Communications of the ACM Vol 11 No 5 pp 341-3461968
40 L P SIMPSON
Handbook of the law of contracts
West Publishing St Paul 1954
41 J G VAN CISE
Understanding the antitrust laws
Practising Law Institute New York 1966
42 R N FREED
Materials and cases on computers and law
Roy N Freed Esq Boston 1971
43 N R NIELSEN
The merit of regional computing networks
Communications of the ACM Vol 14 No 5 pp 319-3261971
44 Special issue on microprogramming
IEEE Transactions on Computers Vol C-20 No 7 1971
45 G H LARSEN
DP monopoly hurting the US computer world
p 10 November 17 1971
839
46 International business machines
Forbes Vol 108 No 5 pp 18-22 September 11971
47 Antitrust: Storm signals
Forbes Vol 108 No 9 p:23 Nov 11971
48 C WYZANSKI
United States vs. United Shoe Machinery Corporation
1I0F Supp 295 D Mass 1953 aff'd 347 US 521 1954
49 W RODGERS
Think
Stein and Day New York 1969
50 E BERKELEY H GOLUB C J GRAYSON
P NORDEN J TENNANT
A panel session-management: Management education in data
processing
Proceedings ACM 70 pp 344-3501971
51 H KRIEBEL
Summary of the management sessions
Proceedings ACM 70 p 343 1971
52 R A GILBERT J T GILMORE T WOLLE
F G WITHINGTON
A panel session-management: Management information
systems
Proceed:ngs ACM 70 pp 354-3581971
53 J E HUGHES E J MAHONEY P MEDOW
E R TURNER
A panel session-government: Computers in government
Proceedings ACM 70 pp 174-191 1971
54 P KAMNITZER N F KRISTY J McLEOD
E W PAXTON R WEINBERG
A panel session-Computers and the problems of society
Proceedings FJCC 1971
55 B W BOEHM D COHEN B NAUS
N R NIELSEN E B PARKER
A panel session-Planning community information utilities
Proceedings FJCC 1971
56 H R J GROSCH V C HARE C P LECHT
H PERLMUTTER J M STEWART
A panel session-Management: Management in the
post-industrial era
Proceedings ACM 70 pp 359-365 1971
57 L G BRYAN M S S MONTON K L ZINN
A panel session-Education: Recommendations for action
Proceedings ACM 70 pp 71-79 1971
A set of goals and approaches for education in
computer science
by SAUL AMAREL
Rutgers University
New Brunswick, N ew Jersey
INTRODUCTION
mentation with existing systems. The range extends
from purely theoretical work to practical work within
the state of the art.
In order to evaluate and plan educational programs in
computer science it is important to have a clear conception of the internal structure and content of the discipline, and also of its relationships with other disciplines.
It is also important to have a clear set of goals, values,
and priorities in the light of which given programs can
be evaluated, and new approaches can be developed.
In this paper I will discuss a specific set of goals and
approaches for educational planning in computer science. lVluch of our planning at Rutgers reflects the viewpoints that I am presenting here.
Theory and practice
I think that it is important to maintain a view of the
field which helps to minimize the distance between theoretical and practical work. Computer Science is concerned with analysis and synthesis aspects of various
types of computer applications and systems. A continuous interaction between theoretical and design/ experimental work is needed for a vigorous rate of progress in
the field. Theoretical work in a rich applied environment is likely to receive stimulation along lines of
'relevant' models and theories. Design and experimental
work in a good theoretical environment promises to
lead to more efficient and powerful systems and applications.
An important reason for maintaining a strong coupling between theory and practice in academic computer
science is our responsibility for guiding the growth of
the discipline toward the dual goals of intellectual depth
and coherence, and also of pragmatic significance for the
real world of computing. Because of the phenomenal
growth of the computer field, we are witnessing a rapid
accumulation of vast amounts of unstructured information: specifications of many diverse hardware and
software systems, records of a variety of operating experiences, discussions of different principles, techniques,
and empirical advice, and many fragments of knowledge only weakly related to each other. In order to be
able to build on top of what has been done in the past,
and in order to understand and effectively use new developments, we must plan computer science programs
in accordance with the following: (a) exposure to what
is being done in the real world of computing, (b) study
of ways for bringing order into what is being done.
THE STRUCTURE OF COMPUTER SCIENCE
In Reference 1 I have presented a framework for curriculum planning in computer science which combines a
global view of the discipline and a local view. The global
view is concerned with the kinds of objects, phenomena,
and concepts that form the domain of discourse in computer science, and also with the pattern of relationships
between this domain and other domains of study. The
local view focuses on a structured description of the
knowledge, problems, and activities within the discipline.
In developing the local view of the field, I find it useful to distinguish between two broad categories of activities: (1) activities concerned with problems, methods
of solution and programming; and (2) activities concerned with representations, languages, schemes of
processing, and system designs. They correspond
roughly to computer applications and to systems. Within
each of these two categories there is a broad spectrum
of types of activities: development of formal systems
and formulation of theories; search for fundamental
principles; invention and exploration of new schemes;
design and construction of new systems; and experi-
841
842
Spring Joint Computer Conference, 1972
through an active search for unifying principles, general
methods and theories, and (c) exploration of new computer designs and applications in the light of new concepts and theories.
Clearly any structural description of the subject
matter of computer science reflects certain points of
view and values about what we ought to teach and how.
By not using a separate category for 'Theory' or 'Formal
Systems' in a broad structuring of the field I am injecting a specific viewpoint into curriculum planning which
favors 'rapprochement' between theory and practice in
computer science programs.
Systems and applications
Our academic planning at Rutgers is based on further
substructuring of the two categories 'Systems' and 'Applications' into the four parts 'Hardware Systems'
'Software Systems', 'Numerical Applications', and
'Nonnumerical Applications'. 2,3,4 The 'Hardware Systems' part covers mainly machine organization, digital
subsystems, operating systems, and design processes.
The emphasis in the 'Software Systems' part is on
machine level representation and programming, operating systems and language systems. The 'Numerical
Applications' area is mainly concerned with problems
and procedures where numerical data are dominant,
such as problems in numerical analysis and in statistical
processing, optimization and mathematical programming, and certain classes of modeling and simulation
problems. The 'N onnumerical Applications' area is primarily concerned with processes involving nonnumerical data. Examples of such data are: representations of
problems, situations and programs; symbolic expressions; language text; abstract structures; and graphic
objects. In addition, each of the application oriented
areas is concerned with relevant studies in high level
languages, schemes for representing problems, data
bases and procedures, and related theoretical subjects.
Each of the four parts described above provides a
basis for a "topic of study", which may be chosen by a
student as an area of concentration. The partition into
the four areas reflects an attitude to curricular design
which is widely accepted at present. It has a fairly
sound conceptual basis, and it leads to an implementable
program which can now be supported by considerable
experience and a growing literature. The conceptual
basis is essentially reductionist: computer systems are
decomposed in terms of different types of structural
components (structural properties determine possible
modes of computation), and computer applications are
differentiated in accordance with major types of data
structures (properties of data structures determine
types of information processes). This reductionist attitude will probably change in the next few years, as it
will become increasingly desirable (and feasible) to treat
hardware and software designs in a unified manner, and
as the emphasis in application areas will be on broad
problem types where both numerical and nonnumerical
processes will play essential roles (e.g., modeling and decision making in medicine, large design and optimization problems). The changes are likely to come first in
advanced parts of graduate programs, and they will
gradually move toward undergraduate programs. I
expect the changes to be relatively slow, not only because of the conceptual issues involved in restructuring
the field, but also because of the natural inertia of educational systems where required courses, supporting
texts, and other relevant resources, cannot change overnight.
A structured description of the field is an important
input for planning an educational program, and it already reflects a specific set of viewpoints and decisions
on priorities. We need, in addition, further clarification
of priorities in order to determine (a) the relative emphasis that the program should place on different parts of
the field, and (b) the way in which individual students
should be guided through the program.
Our emphasis at Rutgers is on the relationship and
mutual impact of application areas and computer systems.
This implies a fairly balanced set of activities in applications and systems, with major effort in problem
solving methods, computer procedures, languages, systems software, and associated theories. This approach is
consistent with our view that studies of computation
mechanisms and system designs should grow in an environment which is rich with significant and challenging
computer applications.
COMPUTER APPLICATIONS
I believe that serious work on new types of computer
applications is essential for the healthy development of
computer science. The challenges presented by new applications and the constructive attempts to meet them
will continue to be key factors in the evolution of computer systems and in the conceptual maturation of the
field. Work on new applications will lead to increasing
collaborative ties with people in other disciplines; this
wi1l increase the 'surface of contact' between computer
science and other areas, to the benefit of all involved.
In this context, computer science could provide an
academic home for certain important activities associated with applied mathematics: the formulation and
study of models, the development of methodologies for
bridging the gap between a real life problem and its
Set of Goals and Approaches for Education in Computer Science
representation within a system wherein the problem can
be solved, and the study of broad approaches to problem solving.
In our programs at Rutgers, computer applications
are studied at various levels. A freshman-level introduction to computing is oriented to hands-on experience
with computer problem solving, using BASIC on a time
sharing mode. Sophomore-level courses in computer
problem solving focus on a variety of problem types
(numerical and nonnumerical) and on the use of several
high-level languages-FORTRAN, PL/I, SNOBOL.
Thus computer languages and their features are introduced in the context of their use for formulating computer procedures of different types in a variety of problem areas. The study of computer organization, machine
level programming, and systems software follows the
courses where problem solving is the dominant theme.
Thus, a student is first exposed to what kinds of things
computers do and how can they be used, and then he is
led to consider how computer systems operate, how they
are structured and how they can be designed.
The study of computer applications continues in our
upper level undergraduate classes with courses in
numerical methods, data processing methods and nonnumerical algorithms. At the graduate level, two introductory (and required) courses on numerical analysis
and nonnumerical algorithms are followed by a collection of courses and seminars which explore in different
degrees of depth a variety of application areas, procedures, and approaches to problem solving.
Recently we established an (NIH supported) res~arch resource on computers in biomedicine. This proVIdes a focus for collaborative activities with people in
medicine, bioengineering, psychology and ecology on a
broad range of problems that involve the use of computers in biomedical inquiry. This type of research activity is an extremely important environment for advanced graduate work and for faculty research m
various aspects of advanced computer applications.
N onnumerical applications
The study of nonnumerical applications is of central
importance in a computer science program. It provides
insight into the broad notion of computers as symbol
manipulators, and it permits a clear view of many key
information processing concepts that become obscured
when presented only in the context of mathematical
algorithms for numerical problems. Also, the domain of
nonn~merical applications is extremely large, and it
contams a great variety of significant problems in the
field. In addition to the broad spectrum of problems
from elementary data processing to complex decision
843
and problem solving in artificial intelligence, the entire
area of systems software (languages and operating systems) is mainly founded on nonnumerical processes and
techniques.
Artificial intelligen ce
Work in artificial intelligence problems provides an
excellent opportunity for the study of nonnumerical
processes and for the clarification of certain basic issues
in software design. It is important to work toward the
development of closer links between artificial intelligence studies and other studies in the mainstream of
computer applications and of systems design. I believe
that this will be of benefit to computer science education, and in general, it will stimulate new, significant
developments in the computer field.
It is becoming increasingly clear that there is no
sharp dividing line betvveen the problem solving procedures of artificial intelligence and the procedures of
today's 'conventional' software. 5 It is useful to think
that computer procedures lie in some sort of continuum
and each procedure in the continuum is characterized
by the relative amount of systematic versus heuristic
knowledge available to it, as well as the degree to which
this knowledge can be efficiently exploited by the procedure for the solution of specific problems in its domain. At the one end of the continuum, where systematic knowledge is dominant and its mode of utilization is highly efficient, we have the customized procedures and the formally validated algorithms of the
well developed computer application areas. At the other
end, where amount of systematic knovvledge is low, \ve
have the general, flexible, goal directed procedures of
artificial intelligence, where a set of relatively weak
problem-specific principles are combined with heuristic
methods for the control of processes that search for
solutions. In between, we have the bulk of procedures
that run on computers at present-including procedures
that manipulate computer languages, and those that
control computer operations.
The notion of a procedure continuum, where the
emphasis is on types of information processes and on
types of knowledge associated with them, promises to
provide a fruitful conceptual framework for education
in computer science. It would be interesting to explore
it further in the context of future curriculum designs.
Numerical applications
Numerical analysis and several other subjects in the
general area of numerical applications are among the
best developed in the field in terms of systematic knowl-
844
Spring Joint Computer Conference, 1972
edge available and theoretical treatment of algorithms.
I think that these subjects have an important place in
a computer science curriculum, not only because of
their great significance for many computer applications,
but also because they provide models of 'high quality'
procedures and of successful theoretical approaches to
their study. Such models are needed for progress in
other, less developed areas of the field.
INTERACTION WITH :\IATHE1VIATICS
The study of numerical applications is closely related
to mathematical studies. A strong mathematical background (especially in calculus and linear algebra) is
needed for work in most numerical applications. Conversely, numerical applications are in themselves significant topics of study in mathematics.
The question of mathematical preparation for work in
computer science must receive careful consideration in
the development of computer science programs. Theoretical work in computer science relies on several
branches of mathematics and logic. In addition to the
formal background needed for numerical applicat:ons,
various topics in abstract algebras, in logic and foundations, in combinatorial analysis, in graph theory and in
probability theory are needed for work in well developed
areas of nonnumerical applications and of computer
system design.
A problem aIises when we consider the training of
people who are oriented to the bulk of design and application activities in the field. For the most, these activities are in areas where relevant theoretical knowledge is
poor. There is considerable consensus among computer
science educators that people working in these areas
must have at least a certain level of 'mathematical
maturity.' This does not imply necessarily the knowledge of specific mathematical facts and methods. What
is meant usually is training in disciplined modes of
thought, in the manipulation of abstractions, and in the
development and use of methods that can apply in a
great variety of situations. To obtain this type of
training, we have several approaches: (a) provide sufficient exposure to offerings in regular mathematics curriculi, (b) restructure some mathematical offerings to
attain within a limited time, both the 'maturity' objective and the objective of education in mathematical
topics of special relevance to work in the computer
field, and (c) develop computer-based courses that address themselves directly to the underlying cognitive
skills implied by 'mathematical maturity,' without
using conventional mathematical material. These approaches are not mutually exclusive. I believe that it is
an important challenge for computer science education
to develop the approach (c). In parallel, I would place
considerable stress on the approach (b). I am basing
this on the conviction that even those who graduate at
present from a computer science program and expect to
take a programming job which does not require an immediate specific knowledge of mathematics, must be
equipped against rapid obsolescence in a field which is
extremely dynamic and which requires continuous
learning and adaptation to new concepts and techniques. As theoretical knowledge grows in their area of
activity, they must be prepared to understand it and
to use it. Formal approaches will continue to develop
in computer application areas; they are likely to penetrate more and more in systems design areas as concern
with quality and efficiency of designs will continue to
grow, and as methods of system analysis and evaluation
will become increasingly available.
Wallace Feurzeig and his colleagues at Bolt Beranek
and Newman have started to design courses where
computer programming is being used as a key to the
development of certain basic mathematical ideas and
of skills for abstract reasoning. 6 This work has been
oriented so far to pre-college instruction. It would be
extremely interesting to develop courses of this type for
introductory college instruction. In addition to their
effectiveness for the development of 'mathematical
maturity,' such courses would be exceptionally well
suited for the introduction of computers to a large
number of college students who, because of their 'fear
of math,' hesitate to take introductory computing
courses in their present form (which is commonly biased
toward mathematical calculations).
INTRODUCTION TO COMPUTING AND TO
GENERAL EDUCATION ABOUT
COlVIPUTERS
Computer science departments have an important
responsibility to provide broad introductory computing
courses to the entire College population. In order to
reach a very wide group of students, with a great possible variety of backgrounds and orientations, it is
important to develop courses with no special mathematics requirements and with the main emphasis on the
essentials of information processing and on hands-on
problem solving experience with computers. The design
of such courses is of considerable value for computer
science as a new discipline, since it forces attention on
fundamental concepts in the field and on imaginative
ways of communicating them.
One of the most promising areas for the use of CAl
in a college curriculum is in introductory courses in
computer science and in mathematics. It would be
Set of Goals and Approaches for Education in Computer Science
highly desirable to stimulate the development of such
computer-based courses in computer science departments; this would be a valuable activity for both faculty
and students.
In our program at Rutgers we have had some experience with an introductory course where the emphasis
was on uses of computers and on their impact on society.
We found that students at the freshman level were
much more interested in what computers are and how
they can be used, rather than in general questions
about the impact of computers on society and the broad
significance of a growing computer culture on people.
I think that it is profitable and important to discuss
these issues in a senior seminar; at that level, students
have more knowledge (of computers and of other
things), and more maturity and ~otivation to study
relationships between computers, man, and society.
SUGGESTED APPROACHES TO LONG RANGE
EDUCATIONAL PLANNING IN COMPUTER
SCIENCE
The question of educational breadth versus specialization is central to long range academic planning in computer science. As the computer field grows, there is an
increasing demand for in-depth training of a variety of
specialists. If the rate of generation of general principles
and methods in the field will continue to lag behind the
rate of production of specific computer systems and
specific application packages, then there will be a tendency for computer science curriculi to be overwhelmed
by a variety of fragments of detailed, specialized materifLl-and for students of computer science to have
negligible opportunity of being exposed to other disciplines, and to areas of intellectual activity where computers do not necessarily play maj or roles. On the other
hand, it is essential for computer science not to grow in
isolation, but to actively seek and strengthen intellectual bonds and working contacts with other disciplines.
Accordingly, future contributors in the field must develop the ability to communicate and collaborate with
people in other areas, and to be sensitive to ideas and
concerns outside their discipline. This implies the need
for balance between activities within the discipline and
outside it. Also, the nature of studies in computer science should reflect the dynamic character of the field,
and the need to develop in students a capacity for independent learning and growth.
The following set of approaches are suggested in
response to the requirements for educational balance
and for adaptability to fast changes in the field:
(a) The core of computer science courses that are
needed for an undergraduate major should be
845
limited to between a third and a half of the total
courses needed for an undergraduate degree.
These ratios will be much higher at the graduate
level. In any event, students at all levels should
be encouraged to take courses in other areas.
(b) An important part of academic planning is to
develop (in some detail) options for combined
studies involving computer science and other
disciplines. Undergraduate areas of specialization should be created by combining the computer science core courses with courses in other
appropriate disciplines (in particular, with
Mathematics, Electrical Engineering, and Management Sciences/Business Administration). This
implies a limited core curriculum offered by the
computer science unit, and close curriculum coordination with the other academic units. Similar
curriculum coordination should develop in
graduate programs. One of the most effective
ways of stimulating contact with other disciplines
at the graduate level is to facilitate/induce projects and research which are directly related to
advanced computer applications in these disciplines.
(c) An appropriate balance (and coordination)
should be established between the lecture
courses, the seminars, and the project-oriented
courses that are components of a program. Lecture courses should concentrate on fundamentals, on structured presentations of parts of the
field, and on general guidance to independent
study of the growing body of 'raw data' concerning specific computer systems, languages, and
applications. Seminars should focus on specific
new developments in the field (exploratory current research, attempts to develop principles and
theories) and on discussions of broad issues (e.g.,
computers and society). Project-oriented courses
should provide opportunities for synthesis of information obtained from various sources, for collaboration (with people in the field, as well as
with others), and for extensive practical work
within the state of the art. An important project
course would be an undergraduate, upper-level
"design studio" where students would work on
substantial software designs of operating systems, language processors, interfaces, etc.
(d) The interface between undergraduate and graduate programs in computer science should be
flexible-with students moving relatively freely
both ways, and courses moving steadily from the
graduate to the undergraduate program. This
movement of courses does not mean an increase
in the number of undergraduate courses, but a
846
Spring Joint Computer Conference, 1972
restructuring, updating and general strengthening of the undergraduate program-whose overall size should remain relatively stable. One of the
reasons for a flexible undergraduate-graduate
interface is the fact that most students entering
graduate computer science programs still come
from different academic disciplines, and their
knowledge of computer science varies widely. As
undergraduate computer science becomes more
widespread, the nature of Masters-level programs will change, and prerequisites for graduate
admissions are likely to become more demanding
in areas of computer systems and applications.
In the meantime, criteria for graduate admissions should remain more flexible on questions of
specific subject matter; the emphasis should continue to be on overall undergraduate academic
performance (especially in mathematical sciences), personal characteristics such as initiative
and inventiveness, and motivation to work in
computer science. Because of the dynamic character of the computer field, I expect that we will
have for some time a process of curricular changes
where the Masters program of today will be essentially included in the Bachelors program of
tomorrow. In general, a terminal Masters program in computer science will continue to provide the training needed for advanced professionals in the computer field. Increasingly,
Bachelor programs in computer science will also
train many of the professionals in the field.
(e) A major part of advanced graduate work in computer science should be devoted to exploratory
projects and to research. A good research environment is essential. This means an appropriate intellectual climate, good communications, and
easy access to computer resources. An important
goal, both for faculty and for graduate students,
would be to introduce order and cohesiveness in
the field, to search for basic principles and general methods, and to design better academic
programs in computer science. As part of these
activities, new courses should be developed,
with the emphasis on fundamentals and also on
ways of using computers as integral parts of the
preparation and administration of the courses.
It would be desirable to have doctoral research develop in the context of such educational projects.
In general, we should recognize that systematization
of fundamentals in the computer field, and design of appropriate academic programs is a key responsibility of
computer science educators. These activities constitute
a process of continuous self-improvement of computer
science programs. Such a process is an essential part of
any academic program; it is of special significance in
computer science. Efforts toward academic planning
and program improvement should receive support and
recognition-the same as direct teaching and other
types of research and development. Contributions in
these areas will have important implications both for
the effectiveness of computer science education, and
also for the overall quality and efficiency of work in the
computer field.
REFERENCES
1 S AMAREL
Computer science: A conceptual framework for curriculum
planning
Communications of the ACM Vol 14 No 6 June 1971
2 Undergraduate program in computer science
Department of Computer Science Livingston College
Rutgers University New Brunswick N J 08903 April 1971
Available from the Department
3 Graduate program in computer science
Department of Computer Science Rutgers University
New Brunswick NJ 08903 July 1971 Available from the
Department
4 Descriptions of graduate courses in computer science
Department of Computer Science Rutgers University
New Brunswick NJ 08903 July 1971 Available from the
Department
5 S AMAREL
Problem solving and decision making by computer: An
overview
in "Cognition: A Multiple View" P L Garvin (ed.) Spartan
Books NY 1970
6 W FEURZEIG et al
Programming languages as a conceptual framework for
teaching mathematics
Report No 2165 June 30 1971 Bolt Beranek and Newman
50 Moulton St Cambridge Mass 02138
Computer science education-The need for interaction
by M. STUART LYNN
Rice University
Houston, Texas
use in computer applications, with what priority, and
then working backwards to define the appropriate educational structure. It is not clear that the existence of
numerical analysis in the computer science curriculum
should be an end in itself.
Perhaps too much of computer science has been concerned with formalization. To a degree, such concern is
proper; there is clearly a need to develop and understand, systematically, fundamental principles and the
interaction of these principles with each other; and a
further need to educate in such a way as to encourage
growth based upon a formalized body of knowledge.
This should not, however, be the end in itself, as appears
to be the trend.
This trend, if it exists, is not directly the fault of the
Curriculum 68 Report. 1 It occurs partly perhaps because
Curriculum 68 is too comprehensive, or too ambitious;
and since in practice limited budgets may dictate that
only selected parts are implemented, an unbalanced
educational structure may be achieved. 2 Perhaps, too,
Curriculum 68 is guilty of leaving to chance (see p. 155)
what may be the most difficult question of all; how to
effect the interaction with other disciplines which is so
essential to the vital development of computer science.
AmareP has separated computer science activity into its
synthetic and analytic components, the former having a
"pragmatic flavor largely responsible for major advances
in computers and for great diversity of areas in which
computers are being applied", and the latter " ... providing conceptual guidelines". He advocates a continuous interaction between these two components as
essential to a vigorous rate of progress in the field. I
would suggest that education in computer science, as
structured in Curriculum 68, may be guilty of inhibiting
that interaction, not encouraging it.
lVfore positive steps need to be taken to encourage
this interaction between the science of computing and
the uses of computers. I am not suggesting interaction
does not exist, only that it has received decreasing emphasis in recent years. Perhaps such encouragement
I would suggest that one of the central problems of
computer science today is understanding what it's for.
As a consequence, given this hypothesis, from an educational standpoint it is not clear what students are expected to represent when they graduate with degrees in
computer science. To the potential employer, the situation becomes even more confused when (in better times)
he believes he is recruiting one thing and finds that he
has hired something else.
This lack of understanding and eventual misrepresentation is not surprising in a young discipline. Perhaps one of the difficulties faced by computer science is
what may be an over-eager attempt to formalize its
content and boundaries, and in so doing discouraging
the growth, change and vitality which have characterized the last decade. Perhaps, also, there is an increasing role being played by what may be (but should not
be) an underlying conflict between the systematic and
formalizing demands of science, and the engineering
demands by which concepts are made useful to man; this
conflict underlies much recent uncertainty in education
in other disciplines, and it should not be surprising that
it is becoming increasingly present where computing is
concerned.
An example, in the Curriculum 68 Report,! of where
potentially harmful boundaries exist lies in the treatment of numerical analysis. On the one hand, insufficient
priority is given to this area, insofar as the proposed
course contents are only suggestive of the field and give
no insight as to the relationship of numerical analysis to
the domain of computer science or to the domain of uses
of numerical analysis in computer applications. On the
- other hand, excessive priority is given to numerical
analysis when compared with other uses of mathematical. analysis in computer applications: statistics,
signal analysis, pattern recognition, control theory,
mathematical programming, operations research and
others. The proper role of each of these and related
areas, and of their interrelationships, needs to be determined by examining the ways in which they are put to
847
848
Computer Science Education
cannot be achieved solely within the definition of computer science education itself, but requires closer examination of the administrative structures within which
computer science operates.
It is likely that the industrial employer will become
increasingly selective in its recruiting at all levels. This
will be dictated not only by short-term considerations,
such as the current state of the economy, but also because he will primarily be looking for graduates who
have the breadth to be able to understand and deal with
a wide spectrum of his problems, graduates who have
the flexibility to modify their areas of interest as needs
and priorities change. To the extent that education in
computer science prepares students for their future, and
for a considerable number this may mean industrial
employment, Curriculum 68 needs careful reexamination, since it is not clear that it contributes substantially
to this requirement.
A mathematician has been defined as one who, given
a problem to solve, solves a whole class of problems of
which the original is not a member. It can be argued
that there has been a breakdown in the lengthy com-
munication channels between mathematics and the
environment in which it operates: whether this is good
or bad for mathematics is a matter of point of view. It
would, however, be bad for computer science. If
students are to be prepared for what may be ahead, they
must be given perspective, and a realistic insight. into
how computer science fits into and relates to the world
around it. They should not, to reverse Oscar Wilde's
definition of a cynic, be encouraged to know the value
of everything and the price of nothing.
REFERENCES
1 Curriculum 68
Comm of the ACM 11 1968 P 151
2 R W ELLIOTT
Master's level computer science curricula
Comm of the ACM 11 1968 P 507
3 S AMAREL
Computer Science: a conceptual framework for curriculum
planning
Comm of the ACM 14 1971 p 391
Operating systems principles and
undergraduate computer science curricula*
by PETER J. DENNING
Princeton, University
Princeton, New Jersey
INTRODUCTION
science curricula-especially undergraduate curriculahave distinguished carefully between courses dealing
with first principles and courses dealing with applications. Courses of the former type tend to be considered
as "core curriculum" courses, but not courses of the
latter type. (It is interesting to note that courses on
operating systems were, until very recently, considered
as being of the latter type. Even as it has been discovered that operating systems has a set of first principles independent of details depending on the technology, this subject matter has increasingly been
considered as worthy core material.)
Courses offered in computer science curricula can be
classified (roughly) into four categories: formal systems, programming systems, computer systems, and
applications. The distribution of courses among the
four areaswiil depend on the objectives of a given
institution. (I believe they should be of equal importance.) Formal systems deals with the various mathematical systems for studying computation itself. Some
of the topics taught in courses of this category include:
the theory of automata, the theory of formal languages,
the theory of computability, the theory of complexity
of computations, and the theory of numerical computations and error propagation. Programming systems
deals with the algorithms that perform computations
on a practical level. The topics taught in courses of
this category include both the concepts of programming
languages and the· problems of implementing algorithms. Programming language concepts encompass
topics like programming language control structures
(e.g., sequencing, iteration, conditional transfers, assignments), representing data, use of recursion, use of
subroutines, parsing, compilation, and assembly techniques. The study of algorithms includes topics like
language-independent algorithm specification, data
representation, analysis of algorithms and data structures, proving a priori the correctness of algorithms,
algorithms for searching and sorting, algorithms for
In the years since 1969, the study of computer systems
has assumed a role nearly equal in importance to
"theory of computation" and "programming" in computer science curricula. In contrast, computer systems
was regarded as recently as 1965 as being inferior in
importance to these two more traditional areas of
study. This is a significant change in attitude. The
harbingers of the change appear in ACM's Curriculum
68, 1 and the speed of its development is demonstrated
in the report of Task Force VIII of the COSINE
( Computer Science in Electrical Engineering) committee of the Commission on Education of the National
Academy of Engineering, entitled "An Undergraduate
Course on Operating Systems Principles."2
The reasons for this change, the nature of computersystem studies, and the potential impact on future
developments will be analyzed in this paper. I shall
begin with a brief overview of computer science itself,
in order to place the study of operating systems in
perspective; I shall then discuss the general need in the
computer industry for principles, many of which relate
to computer and operating systems; finally, I shall discuss how an operating systems principles course may
be organized.
ON COMPUTER SCIENCE
Computer science is the study of the design, analysis,
implementation, and application of informationprocessing procedures. 1 ,3,4,5,6 In their writings, our educational leaders have consistently stressed the importance of concepts and first principles in studying the
material of computer science. All proposals for computer
* Work reported herein was supported in part by NSF Grant
GY-6586.
849
850
Spring Joint Computer Conference, 1972
Operating Systems
Concepts
Programming
Concepts
APPLICATIONS
Programming Language
Concepts
Theory of
Computation
FIRST PRINCIPLES
(core curriculum)
Hardware and Logic
Design
Numerical
Analysis
1940
1945
1950
1955
1960
1965
1970
1975
Figure i-Evolution of first principles
dynamic storage allocation, and heuristic algorithms.
Computer systems deals with the problems arising when
algorithms are implemented on physical devices. Some
of the topics taught in courses of this category include
design of hardware and logic circuits, organization and
design of standard equipment (e.g., processors, memories, peripherals), design of software systems, design
of complex systems, control of parallelism and concurrency, control of processor and memory and other
resources, analysis of system behavior, modeling the
behavior of computing processes. As will be discussed
shortly, these three categories deal with what I call the
"first principles" of computer science. Topics which are
dependent on the present-day technology, or are likely
to be of little interest in more than, say, five years,
are the subject of courses in the applications category;
these include discussions of particular languages or
particular machines or particular operating systems,
systems programming techniques, specialized programming techniques, business data processing, and information retrieval.
The reader will note that Artificial Intelligence has
not been mentioned in the above. In many respects, it
cuts across all the categories. In many respects, it is an
entirely different approach to computer science than
the one I have outlined. Many computer science departments offer Artificial Intelligence courses on an
elective basis and do not consider them as part of the
core curriculum.
When I use the term "operating systems principles,"
I mean the software, control, modeling, and analysis
aspects of the computer-systems part of computer
SCIence.
Figure 1 is a very idealized overview of the evolution
of the first principles of computer science. Topics are
listed along the vertical axis, time along the horizontal;
those topics below the curve at a given time are considered as core-curriculum topics at that time. Conceptual approaches to numerical analysis have been
with us since the beginning of electronic computing,
since these were the primary purposes to which Burks,
Eckert, Goldstine, Mauchly, von Neumann and their
contemporaries envisioned their machines being applied.
Although hardware and combinational logic design
concepts using Boolean algebra to describe switching
functions had been proposed by Shannon before 1945,
this area received a strong impetus from the sequential
machine work of Huffman, Mealy, and Moore during
the early 1950's. The modern approach to the theory of
computation, which emphasizes the relations among
abstract machines and abstract languages and computational complexity did not evolve until the mid 1960's
and the first texts in this area did not appear until the
later 1960's.7.s'Programming languages were introduced
in the later 1950's (FORTRAN in 1956, ALGOL in
1958) but the concepts underlying them were not put
down in systematic, textbook form until the mid1960's.9 Concepts about algorithms themselves, concepts more or less independent of programming languages, did not become systematized until the late
1960's.1O And finally, the concepts of computer systems
are only recently being put in text form at a graduate
levelll and nothing save a report exists describjng them
at an undergraduate level. 2 Thus it is evident that the
development of a wide range of core material-the
first principles of computer science-is quite recent in
the era of electronic computing. Since much of the
material of major interest to the industry itself-programming and system concepts-has just recently
entered the "core area", it is no surprise that the industry has long regarded computer science as being
somewhat irrelevant. I do think we can expect a change
in this attitude.
On the basis of Figure 1, one can see why the majority
of computer science departments were not established
until after 1965. Academia has always been reluctant
to establish degree programs in subject areas with no
discernible broad base of first principles.
ON THE NEED FOR PRINCIPLES TO BE
APPLIED IN THE COMPUTER INDUSTRY
As mentioned, Figure 1 illustrates why the industry
has tended to hold computer science education in disregard, i.e., because the topics of interest to it (concepts
of programming and design of systems) have not been
treated on a sound conceptual basis in curricula. Looking at Figure 1 from a different perspective turns up
another interesting observation: For some twenty
Undergraduate Computer Science Curricula
years, the leaders of industry (management) have had
to proceed without a set of first principles in the areas
of major interest to them. This perhaps explains (in
part) why so much difficulty has been experienced in
getting "third generation" computer systems operational: There had been no systematic set of concepts
according to which designers and programmers could
be guided. This had left the industry in the rather uncomfortable situation of being accused in the public
media of misusing, or condoning the misuse of, computers. Witness, for example, the great public outcry
with respect to privacy and protection of information.
In many respects, then, the allegations that the
computing industry is "adrift" and "unprincipled"
have some basis in fact. The allegations that computer
science education has not been of much help to the
industry likewise have some basis in fact. We cannot,
however, afford to wait ten or twenty years for the
present crop of computer science students to move into
the leadership positions of industry. Those presently in
the leadership positions must not only be made aware
of the existence of principles, but they must be made
aware of the principles themselves.
In a recent statement,I2 ACM President Walter
Carlson recognized this problem, saying ct • • • There is
too little systematic codification of fundamentals (i.e.,
first principles). There is almost no communication
between the research people and system designers or
operators. There is a widening sense of frustration
among academics over misuse (or lack of use) of proven
computer technology in practical operations." Figure 1
demonstrates that at least a basis exists for reversing
the trend addressed by Carlson's first point.
To illustrate Carlson's third point, let me discuss
three examples of common misconceptions attributable
to a lack of understanding of the first principles of
computer science: (1) The "software problem," i.e., the
increasingly high costs of software development and
lack of quality control over software packages, is a long
way from being solved. (2) The "protection problem,"
i.e., that of guaranteeing the privacy, security, and
integrity of information, is yet to be solved adequately.
(3) The "computer utility" was a fad which, thankfully, is dead. It would astonish some managers to
know the facts: Solutions to the software and protection
problem exist now-and have existed, in computer
utility research projects, since at least 1965! (I will
elaborate below.) While much work remains to be done,
I think it is safe to say that these solutions are adequate for present-day purposes. The solutions to these
problems evolved in the design and use of such systems
as the CTSS (Compatible Time Sharing System) and
its successor MULTICS (Multiplexed Information
and Computing Service) at MIT. Both these systems
851
are regarded as first steps in the evolution of the computer utility, and rely on the computer-utility environment for their viability; thus, the attitude that the
computer utility was a fad is in fact an attitude hostile
to the solutions of the two problems. That so. many
who hold leadership positions in the computer industry
have failed to recognize that CTSS and l\1ULTICS
implement solutions to these problems-even as undergraduate students exposed to an operating systems
principles course seem to have no such difficultyfurther reinforces my conviction that the first principles
of computer science are not widely disseminated or
appreciated.
The solution to the software problem in CTSS and
MULTI CS is based on the concepts of programming
modularity and sharing of information; the requisite
mechanism took the forms of the CTSS file system and
the MULTICS virtual memory. * The solution to the
protection problem in MULTICS is based on the concepts protection rings (or "domains") and on controlled
access to information.** An important aspect of these
two solutions is, neither can be accommodated on most
systems presently on the market without major alterations in hardware and software architecture. It is the
failure of management to understand the principles on
which the solutions are based that has made them unable to recognize that CTSS and MULTICS solve
these problems, and has led them to market systems in
which technically sound solutions to the software and
protection problems are not possible.
The foregoing criticisms of management are meant to
be constructive in the sense that managers (and other
elements of the computing profession as well) cannot
play their roles to perfection without a thorough understanding of the principles of computer science. And,
because it is only recently that the first principles have
become systematized, it is difficult to expect managers
to interpret new developments in the light of guiding
principles.
ON THE IMPORTANCE OF COl\1PUTER
SYSTEMS CONCEPTS
I have devoted a considerable amount of space to
emphasizing the first principles of computer science and
* A description of the CTSS file system can be found in Wilkes'
remarkably concise 96-page book,13 a description of the
MULTICS/ virtual memory can be found in the paper by
Bensoussan, Clingen, and Daley.14 Both these descriptions make
it adequately clear that these systems, in their own contexts,
have solved the software problem.
** The concepts of protection systems are discussed by Lampson,15
and by Graham and Denning;16 systems implications of protection
are discussed by Wilkes13 and by Schroeder and SaltzerY
852
Spring Joint Computer Conference, 1972
analyzing the effects in the computer industry of having
no first pIinciples. I have done this to emphasize how
the first principles of computer systems have a natural
place in computer science. Aside from these larger considerations, there are several reasons why a systematic
presentation of the first principles of computer systems
is important in and of itself.
First, the so-called case-study approach to teaching
computer systems has been more or less unsuccessful
wherever it has been tried: The student becomes so
immersed in the particulars of the given system that he
cannot distinguish important principle from irrelevant
detail. In my limited experience, I have met only with
success using the "modeling and analysis" approach.
Thus, computer system principles are useful in the
practical task of teaching others about computer
systems.
Second, it is increasingly evident throughout the
computer industry that we literally can no longer
afford to develop ever larger, ever more complex systems without solid notions of how they are to be structured or how they are to behave. We can no longer
afford to put together systems which are extremely
wasteful of their own resources. We can no longer
afford not to apply the concepts and principles III
practice;
Third, for some inexplicable reason, the design of
complex software and hardware systems has been considered traditionally as an "application" problem, a
"technology-dependent" problem. In contrast, it is now
being realized that designing complex systems-systems which operate as intended, whose correctness and
behavior can be established a priori, whose performance can be monitored easily-is an intellectual task
worthy of· our best minds. (In other words, the computer-systems area has inherited one of the most important problem areas of computer science.) This
realization has stimulated increasing amounts of research in computer system modeling and analysis, a
principal result of which has been the emergence of a
teachable, comprehendable. body of operating systems
principles. Much of "computer system theory" is concerned in one way or another both with managing
complexity in software and hardware systems and with
complex algorithms involving parallel processes, so
that it is relevant to many practical problems now
facing the industry.
Fourth, and perhaps of the most long-term significance, there is an ever widening appreciation of the
view that our world has become a vast real-time system
whose complexity is beyond the reach of the unaided
human mind to understand. It is not difficult to identify
the essential elements of information systems in business systems, economic systems, urban systems, and
even social systems. Again and again we see decisions
being taken to regulate such systems as these which,
despite the best of intentions, often turn out to have
the opposite of the intended effect. Jay Forrester has
called this phenomenon the "counterintuitive behavior"
of complex systems. I8 It is explained by the inability of
the unaided mind fu'ly to grasp why the long-term
effect of a policy is often the opposite of its short-term
effect, or fully to comprehend the complexities of, and
interrelations among, the various parameters that influence a system. Forrester's simulation experiments of
urban· and business systems show that the intended result may normally be obtained only when all the controllable parameters of a system are governed by a
single policy, not when each such parameter is controlled individually. This type of phenomenon is hardly
new in the experience of computer system designers.
As computer system "theorists" axiomatize information
systems, developing systematic approaches both for
managing complexity and for guaranteeing a priori
that a system will operate as intended, the results of
their efforts should be applicable to the solutions of
problems in social, urban and other noncomputer information systems.
ON THE APPROACH
As I have stated, I call this the modeling-and-analysis
approach to studying operating systems, to distinguish
it from the case-study approach. The material can be
organized and presented as a sequence of abstractions
together with examples of their applications, each abstraction being a principle from which most implementations can be deduced. The concept-areas (in
which teachable abstractions exist) are:
procedure implementation
concurrent processes
memory management
name management
resource allocation
protection
Experience shows that the most coherent treatment is
obtained if the topics are organized according to this
list of concept-areas.
The COSINE report2 goes into some detail instructing instructors how to present these abstractions; a
COMPUTING SURVEYS paperI9 explores them in
some detail from a student's viewpoint, the CoffmanDenning text ll treats the mathematical analysis related
to them. Accordingly, I shall restrict myself here to
outlining their content.
The background required of students undertaking
Undergraduate Computer Science Curricula
this type of course should include: a working knowledge
of programming language features; an elementary understanding of compilation and loading processes;
processor organization and operation, including interrupts; memory organization and operation; and data
structures such as stacks, queues, arrays, and hash
tables. This background could be obtained from a
course on programming languages (e.g., ACM's Course
1-2)1 and a course on computer organization (e;g.,
ACM's Course 1-3).1 A data structures course (e.g.,
ACM's Course 1-1)1 is helpful but not necessary.
The course itself is related to ACM's systems programming course (ACM Course 1-4)1 but differs in at
least two significant ways. First, the ACM outline suggests a "descriptive," case-study approach whereas
this course is organized along conceptual lines. Second,
ACM's course emphasizes techniques of systems programming whereas this course emphasizes the principles
of system organization and operation. This shift in
emphasis is made possible by new developments, since
the ACM report predates the appearance of much of
the modeling and analysis material on which this
course is based.
The instructor of this course will find it useful to
introduce the subject by pointing out how, despite the
wide range of operating systems types and capabilities,
there is a set of characteristics common to these systems. These characteristics include: (1) concurrency,
i.e., many activities proceeding simultaneously, (2)
sharing of resources and the existence of a centralized
resource allocation mechanism, (3) sharing of information, (4) protection for information, (5) long-term storage
of information, (6) multiplexing, i.e., the technique of
switching a resource (rapidly) among many requestors
so that it is assigned to at most one at a time, (7)
remote conversational access, (8) nondeterminacy, i.e.,
unpredictability of the order in which events will occur,
and (9) modularity in design and operation of systems.
It is important to point out that, for pedagogic reasons,
the course material is presented (more compactly) according to the six concept-areas stated earlier, and not
directly among the lines of these nine common
characteristics.
The area of procedure implementation is important
because the reason computer systems exist at all is to
provide an efficient environment for executing programs. The notion of procedure is important because of
its close relation to programming modularity. The basic
concepts-pure procedure, procedure activations and
activation records, parameters, local and nonlocal
references-should be presented first. Then the main
concept, "procedure in execution" (i.e., a procedure
which has been called but has not yet returned) and
its implementations, is presented. An abstract descrip-
853
tion of "procedure in execution" is a pair of pointers
(i, r) where i is an instruction pointer and r an activation-record pointer (local environment pointer). Every
implementation must solve three problems: (1) allocating and freeing storage on procedure call and return,
(2) interpreting local references, i.e., those to objects
in the activation record, and (3) interpreting nonlocal
references, i.e., those to objects in other activation
records. The implementations of "procedure in execution" in languages like FORTRAN, ALGOL, or PL/l
can be deduced from these concepts by considering the
restrictions imposed by these languages.
The area of concurrent (parallel) processes is important because one of the purposes of an operating
system is controlling many, independently-timed activities. A "process" can be regarded as a "program in
execution" and has an abstract description much like
"procedure in execution." "Parallel Processes" is the
notion that, at any given time, more than one program
will be observed to be somewhere between its initiation
and termination points. There are four process control
problems of principal concern: (1) determinacy, i.e., the
property that· the result of a computation by cooperating processes on common memory cells is independent
of their relative speeds, (2) freedom from deadlock, i.e.,
the property that allocation of resources is controlled
so that at no time does there exist a set of processes,
each. holding some resources and requesting additional
resources, such that no process's request can be satisfied
from the available resources, (3) mutual exclusion, i.e.,
the property that,· of a given set of processes, at most
one is executing a given set of instructions ati any time,
and (4) synchronization, i.e., the property that a pro~
cess, whose progress past a given point depends on receiving a signal from another, is stopped at that point
until the signal arrives.
The area of memory management is important because every practical computer system incorporates a
hierarchy of storage media characterized by various
compromises among access time, capacity, and cost; a
set of policies and mechanisms is required to increase
system efficiency by arranging that the most frequently
accessed information resides in fast access memory.
The abstractions used here are those of "virtual memory'~: address space, memory space, and address map.
The common implementations of virtual memory (e.g.,
paging, segmentation) can be deduced from these abstractions by considering factors such as efficiency of
mapping operations and efficiency of storage utilization. Once the implementations have been studied, one
can study the policies for managing them. Finally, it is
straightforward to generalize the discussion to the implementations and policies of multiprogramming and of
auxiliary memory problems. The foregoing develop-
854
Spring Joint Computer Conference, 1972
ment will lead to a computational storage system (i.e.,
that part of the memory system in which references
are interpreted by the hardware) which presents to
each programmer a large, linear address space.
The area of name management is imp3rtant because
a linear address space such as provided by the preceding development has inherent limitations from the
standpoint of programmers and system users. It cannot
handle growing or shrinking objects, provide different
contexts in which processes may operate, allow for
sharing or protecting objects, or implement a long-term
storage system in which objects may reside independently of any context. In other words, linear address
space cannot support mpdular programming to the extent required by today's system objectives. These
limitations can be overcome by extending the memory
system to allow programmers to define objects of variable size, assign names and (variable) contexts to these
objects, allow shared access to objects, and specify
dynamically which subset of a universe of objects
should participate in a computation. That part of the
memory system which implements these new objectives
is called the "long-term storage system"; it may be
distinct from the computational storage system or it
may be one and the same. Computers implementing a
virtual memory and a file system are examples of the
former, computers implementing segmentation are examples of the latter. In either case, a global (systemwide) scheme for naming objects must be devised (in
order to allow sharing), the (directory) tree hierarchy
with "pathnames" being most common (in this case
the long-term storage system provides a tree-structured
space of objects in addition to the linear space or
spaces provided by the computational storage system).
The area of resource allocation is imp 3rt ant partly
because the complexities of the interactions among all
the processes in the system dictate that a central pJlicy
regulate resource usage to optimize performance,and
partly because one effect of implementing the previous
abstractions is to hide machine details from users,
placing the burden of allocation decisions squarely on
the system. One can distinguish long-term from shortterm policies, the latter being of primary concern here.
One can model a process (from a resource-allocation
view) as cycling among the "demand-states" ready,
running, blocked; correspondingly one finds a network
of queues with feedback in the computer system. Processes are distributed among the queues according to
demand-states, and change queues according to changes
in demand-state. In terms of this, one can study specific
queueing policies and overall network control policies;
one can study the meaning of concepts like "system
balance" and "thrashing"; and one can study what
evaluation techniques are applicable. Models of pro-
gram behavior and the use of statistical analysis are
important to an understanding of resource allocation
and are used throughout.
The area of protection is important in any system
where there may reside procedure and data belonging to
more than one individual. It must not be possible for
one process to disrupt or corrupt service to others, and
access to information (especially if confidential or proprietary) must be permitted only under appropriate
authorization. The abstract model of a protection system includes: (1) a set of "domains" or "protection
contexts," i.e., sets of constraints according to which a
process may access objects, (2) a set of "objects," i.e.,
everything to which access must be protected or controlled (including the domains), and (3) a mechanism
that both specifies and enforces access rules by processes
to objects, the type of access depending on the domain
with which the process is associated. The mechanism
can be specified in the form of an "access matrix" (e.g.,
if A is the access matrix, A[d, x] specifies the types of
access a process associated with domain d has to object
x). Most of the implementations of protection found in
practice can be deduced from this model.
There remain certain issues that have not been
treated definitively in the literature but which nonetheless are of central importance in computer system
operation and design. These include: reliability, performance evaluation, design methodologies, and implementation strategies. They must, unfortunately, be
relegated to a pedagogically inferior position at the end
of the course. I should emphasize that this reflects the
absence of teachable material, not the importance of
the issues. As viable abstractions in these areas are
evolved, they will be welcome additions to the course.
CONCLUSIONS
Operating systems principles can be regarded as the
study of complex algorithms comprising parallel activities. This paper has reviewed and analyzed the importance of a significant change in attitude: The assumption of computer operating systems principles into
the core of computer science. The analysis of this
change was done in the light of the evolution of the
"first principles" of computer science, of the need for
these principles to be applied in the computer industry,
and of the increasing need for systematic ways of dealing with complex, real-time information systems. An
outline for a course on operating systems· principles
was described, the concepts being chosen for inclusion
in the course on the basis both of demonstrated utility
in practice and of their being straightforward generalizations of widely accepted viewpoints.
Undergraduate Computer Science Curricula
The first twenty-five years of the computer industry,
years of remarkable achievement, have not been without their problems. Now that computer science education is maturing, we should be able to expect closer
cooperation between universities and industry in solving these problems.
REFERENCES
1 ACM Curriculum Committee on Computer Science (C 3S)
Curriculum 68: Recommendations for academic programs in
computer science
Comm ACM 11 3 March 1968 151-197
2 COSINE Task Force VIII
An undergraduate course on operating systems principles
(The members of the task force were: Peter J. Denning,
Jack B. Dennis, A. Nico Habermann, Butler W. Lampson,
Richard R. Muntz, and Dennis Tsichritzis.) June 1971.
Available free of charge from: Commission on Education
National Academy of Engineering 2101 Constitution
Avenue NW Washington DC 20418
3 S AMAREL
Computer science: a conceptual framework for curriculum
planning
Comm ACM 146 June 1971 391-401
4 G E FORSYTHE
A university's educational program in computer science
Comm ACM 10 1 Jan 19673-11
5 R WHAMMING
One man's view of computer science
JACM 10 1 Jan 1969 3-12
6 A L PERLIS
University education in computing science
Proc Stony Brook Conf Academic Press 1968 70ff
7 J E HOPCROFT J D ULLMAN
Formal languages and their relation to automata
Addison-Wesley 1969
855
8 M M MINSKY
Computation: Finite and infinite machines
Prentice-Hall 1967
9 I FLORES
Computer programming
Prentice-Hall 1966
10 D E KNUTH
The art of computer programming
Addison-Wesley Vol I 1968 Vol II 1969
11 E G COFFMAN JR P J DENNING
Operating systems theory
Prentice-Hall to appear
12 W M CARLSON
President's letter: reflections on Ljubljana
Comm ACM 14 10 Oct 1971
13 M V WILKES
Time sharing computer systems
American Elsevier 1968
14 A BENSOUSSAN C T CLINGEN R C DALEY
The MULTICS virtual memory
Proc 2nd ACM Symposium on Operating Systems
Principles Oct 1969 30-42
15 B W LAMPSON
Protection
Proc 5th Annual Princeton Conference on Information
Science and Systems Department of Electrical
Engineering Princeton University Princeton New Jersey
08540 March 1971
16 G S GRAHAM P J DENNING
Protection: principles and practice
Proc AFIPS Conf 40 Spring Joint Computer Conference
1972
17 M D SCHROEDER J H SALTZER
A hardware architecture for implementing protection rings
Comm ACM 15 3 March 1972
18 J W FORRESTER
Urban dynamics
MIT Press 1969
19 P J DENNING
Third generation computer systems
Computing Surveys 3 4 Dec 1971
Theory of computing in computer science education
by PATRICK C. FISCHER
University of Waterloo
Waterloo,. Ontario, Canada
INTRODUCTION
has a good balance between intuition and rigor. N evertheless, the 1968 descriptions for these courses are still
a very good approximation to current course offerings
in a number of university and college departments of
computer science.
Theory of computing means the abstract study of the
nature of computation and computing devices. By convention, the terminology is usually applied in a narrower sense to exclude numerical analysis. Thus, theory
of computing includes the theory of finite automata,
formal languages, computability, computational complexity, and some aspects of switching circuit theory
and logical design. The deviation from the literal meaning of the term may have occurred because numerical
analysis was already a well-established subject when
the other components of this area were in their infancy.
On the other hand, it may be a reflection of the emphasis on discrete mathematics by workers in theory of
computing, in contrast to the preponderance of continuous methods in numerical analysis.
In Curriculum 68, theory of computing was represented by the following courses. *
Formal languages
Turning now to the advanced-level courses, one finds
more updating needed. Developments in formal language theory have taken place in both the area of
parsing methods and the study of abstract families of
languages. An updated course Al would probably do
well to assimilate a greater proportion of the new
material in the former area, thus shifting the· overall
orientation of the course more toward the practical
side. In order to, make room for this recent material, a
few lectures worth of the most basic material, e.g., the
notion of a formal grammar as a generator of a language
and. some of the equivalent interpretations in terms of
abstract machines, could be introduced earlier as part
of the course I-X proposed below.
B3 Discrete Structures
16 Switching Theory
17 Sequential Machines (Automata Theory)
Al Formal Languages and Syntactic Analysis
A7 Theory of Computability
Theory of computability
CURRICULUM TRENDS
A considerable amount of activity has taken place
within the area covered by Course A7, and much of the
new material is already entering the computer science
course offerings of several universities. The new material1ies principally.in three areas:
Lower-level courses
The courses B3, 16 and 17 above have been remarkably stable, perhaps because of the relative distance of
their content from the frontiers of research. Perhaps
some minor changes might be considered: Course B3
could include some material on the first-order predicate
calculus rather than just the propositional calculus, and
Course 17 still lacks a textbook which is teachable and
* Comm. ACM 11, 3
1. computational complexity;
2; analysis of algorithms,
3. program schemata.
We will discuss these areas briefly in order to define
their scopes, but will not attempt a survey of the many
interesting results which have been obtained.
(March, 1968), pp. 151-197.
857
858
Spring Joint Computer Conference, 1972
CODlputational cODlplexity
The first of these areas dates back to 1960 when M.
Rabin suggested that one could study the classification
of computable functions according to the degree of
difficulty of computing them.B28 (Until then, the main
efforts in computability theory were, in fact, directed
toward understanding and classifying the uncomputable functions in order to gain insight into the foundations of mathematics.) Thus, this area is the oldest of
the three and was the first to split off from the traditional computability theory (often called recursive function theory), which began in the 1930's.
In computational complexity studies, the most common overall approach is to consider programs which
are "efficient" in the sense that they either do not exceed a bound on resources available at execution time
or do not exceed a bound on those available at compile
time. Thus, one either considers all programs which are
sufficiently "fast" or sufficiently "small" and determines which functions can be computed by such programs. The classes of functions obtained relative to a
given resource bound are called "complexity classes,"
and one principal aim of this area is to study their
mathematical properties. Examples of resources related
to execution of a program which have been studied are:
number of steps on a Turing machine, memory cycles
on a random-access machine, total memory space
/needed on a typical computer, number of bitwise operations on any computer. Examples of resources related
to compilation 9f a program are: program size (in bits) ,
depth of nesting of DO loops in a FORTRAN-like
language, number of blocks in a program.
In addition, the features of all computations with resource bounds have been axiomatized by M. Blum,
and a number of machine-independent results have
been proved. Thus, mathematical rigor has reinforced
the programmer's intuition in verifying that for any
computable function there are arbitrarily bad (e.g., slow
or huge) programs which do, in fact, compute the
function. On the other hand, the "best" programs for
a function cannot always be effectively found. Furthermore, some functions simply have no best programs.
The notion of "time-space trade off" is beginning to
be the object of study via the consideration of complexity of finite functions (i.e., functions which need to
be evaluated for only a finite number of inputs) . Until
recently, finite functions had been dismissed as trivial,
since all finite functions can be computed quickly via
programs with large tables built into them. By taking
program size into account, a rich enough structure is
available to permit the investigations of this subarea.
Another related concept is that of randomness, since a sequence can be considered to be essentially random
if a program to print it involves the equivalent of
storing the entire sequence in the program. Conversely,
a non-random sequence is one which can be predicted
and therefore computed by a relatively short program.
The techniques used to prove theorems in computational complexity theory tend to be closely related to
techniques used in automata theory and recursive
function theory. Thus, proofs may involve diagonal
constructions, counting arguments or analysis of rateof-growth of resource needs. The results in this area
, have had relatively little direct practical application in
the sense that the algorithms produced generally compute functions of only theoretical interest. However, a
great deal of understanding about the nature of computation and the relationship between machine organization and computational efficiency is being obtained.
Analysis of algorithDls
This area has evolved as a branch of computational
complexity but has recently acquired its own distinctive
character as well as a sizable group of converts. (It is
still new enough to have no standard name; other
names include "efficient algorithms," "optimal algo~
rithms," and "concrete computational complexity.")
Again, interest is in the degree of difficulty of computing
functions. However, one now tends to focus on a given
function (or a relatively small class of functions) and
to attempt to determine the complexity of the best algorithms for computing it, if such exist and can be found.
H optimal algorithms are not known, lower bounds
on complexity measures are investigated and nearoptimal algorithms sought. Examples of functions or
procedures considered include: sorting, determination
of the median of a sample, polynomial evaluation,
matrix multiplication, checking graph isomorphism.
In analysis of algorithms, the measures of complexity
are all oriented toward execution efficiency rather than
program structure. Examples of measures commonly
used are: the number of multiplications andlor divisions
executed, number of all arithmetic operations, number
of data references, number of data comparisons. The
measures thus involve quantities which are basic in
most programming systems. Furthermore, by considering only programs which compute a given function,
rather than studying all programs possessing a certain
degree of efficiency (regardless of what they compute
efficiently), one limits' himself to programs computing
functions of practical interest, and his search for an
algorithm which is both efficient and useful follows more
closely that of the programmer than the theoretician.
For these reasons, analysis of algorithms has a considerably more practical flavor than (other) computational complexity theory.
Theory of Computing in Computer Science Education
(Some of this aura of practicality is, of course illusory.
Minimizing the number of multiplications may not
minimize cost, when eliminating one multiplication
adds 10 addition operations. Furthermore, simply
counting the number of arithmetic operations tacitly
assumes, for example, that addition of very long numbers costs no more than addition of short numbers.
Such assumptions are just as idealistic as assuming
that minimizing steps on a multitape Turing machine
will minimize cost on a real computer, but they have
more popular appeal since they do not limit one to
hardware with a very low market penetration.)
The methods used in analysis of algorithms tend at
times to be ad hoc in nature, especially when searching
for new and better algorithms. The techniques for establishing lower bounds tend to come from combinatorics and numerical analysis, and a background in
these areas appears to be more important for the algorithm analyst than a background in other theory of
computing.
PrograIn scheInata
Research in program schemata is also on the upswing
although the total activity in this area is probably not
as high as in the other two. The main objects of study
are programs in which the particular domain of data
and the meanings of the primitive· operations on that
data are not specified. One example of a program schema
would be a flow chart in which the contents of the
various computation and decision boxes are left unspecified. One then studies the relationships between
the "uninterpreted schema" (e.g., the flow chart) and
the programs resulting when various functions are
"plugged in" to the uninterpreted portions of the
schema (e.g., the flow chart boxes).
In its purest form (most features of the model uninterpreted), the study of program schemata is closely
related to work in language definition and program
validation. As one builds more structure into the model,
allowing some features to have fixed interpretations
(e.g., a box which computes Ax[2xJ) and others to be
uninterpreted, this area tends to behave more like a
branch of computability theory. However, instead of
computable functions, one now considers computable
functionals, i.e., mappings from functions to functions
rather than from numbers to numbers. For example, a
flow chart with two boxes in which the output of tie
first box becomes the argument for the second might
be viewed as the functional producing composition of
two functions when the functions are given as inputs.
Thus, if the first box were to be interpreted as comput-
859
ing a function g and a second box as computing j, then
the whole program would compute AX[j(g(x))].
The techniques for proving theorems about program
schemata tend to be similar to those of classical computability theory, and the models used have their
roots in common programming languages.
SUGGESTED CURRICULUM
MODIFICATIONS
Basic computability theory
A few minor curriculum changes were suggested at
the beginI).ing of the previous section. However, for the
course offerings in computability theory, the modifications should be more extensive; It is proposed that the
more basic and machine-related material in the present
Course A7 be combined with a short introduction to
formal language theory and presented as a new intermediate level Course I-X. The choice of material to
put into I -X was based on an assessment of relevance
to computer science, estimated present development
and future stability, and availability of textbook
material. By teaching the material in Course I-X at the
undergraduate (or first-year graduate) level, one will
have more flexibility with respect to the advanced-level
Course A1 on formal languages and in new courses in
the previously described areas of computability theory.
Fairly detailed suggestions are made below for Course
I -X, following the format of Curriculum 68.
The remainder of the material in Course A7 included
both recursive function theory and computational complexity material. However, much of the new material
in analysis of algorithms and program schemata is more
relevant to computer science than that in recursive
function theory. To be sure, a student would still benefit
from the more traditional approach since understanding
the historical origins of a subject helps place the material in a proper perspective. Furthermore, the techniques traditionally used are applicable to problems in
computational complexity theory and often in theory
of program schemata. However, there is now much
more than enough material in computational complexity, analysis of algorithms and program schemata
to fill a term course, thus creating a pressure to displace
the less relevant material. Therefore, the recursive
function theory ought to leave the computer science
curriculum recommendations. (It will still be taught in
mathematics departments, of course.) It is encouraging
that so much good work has been done on problems
which have their roots in computer science in so short
a period of time.
860
Spring Joint Computer Conference, 1972
Course I-X: Introduction to computability theory and
formal languages
8. Unsolvability of the Post correspondence problem.
Applications to unsolvability problems in formal
languages.
Approach
This course is designed to introduce the advanced
undergraduate or first-year graduate to formal systems
of computation (including formal languages) and to
give him a basic understanding of the nature of the
unsolvability phenomena which pervade attempts to
deduce correctness of programs, equivalence of algorithms, etc.
Prerequisite: Course B3 or a course in logic or algebra.
Content
1. The intuitive notion of effective computability as
involving the existence of an algorithm. The Turing
machine as one precise formal model for the notion.
Equivalence of the computing power of the standard
class of Turing machines with classes obtained by varying the control structure of the machine (e.g., Wang's
single-address serial memory machines) and the data
structure of the machine (e.g., more than one tape,
multiheaded tapes, n-dimensional tapes, nonerasing
tapes, random-access storage, etc.).
2. Universal Turing machines, i.e., the construction
of an interpretive program to simulate other Turing
machine programs.
3. The unsolvability of the halting problem; the
effective production of counterexamples for alleged
halting problem solvers. Some other unsolvable problems (blank tape halting problem, printing problem,
etc.) . Some solvable problems (computations on
bounded space, etc.) .
4. Numerical approaches to computability. Primitive recursive and recursive functions. Encodings of
lists of integers into single integers (pairing functions)
and encodings of computations (arithmetization).
5. Other models for digital computation: program
machines, loop machines, machines with pushdown
stores, stacks, counters, etc. Simulation of Turing machines by machines with only two counters.
6. Post combinatorial systems and formal grammars
as a special case. Production notation for specifying
grammars. Recursively enumerable, context-sensitive,
context-free and finite-state gra~mars. Examples of
languages of varying complexity, e.g., anb n, anbncn;
Proof that anbncn is not context-free.
7. Grammars vs. abstract machines. Representations
of the above in terms .of Turing machines, linear
bounded .automata, one-pushdown machines, finitestate automata, respectively.
References-Course I-X
The richest sources of material for this course are
Minsky and Hopcroft-Ullman. A8 •A6 The former has
good, readable coverage of 1-5, above, and part of 6.
The latter has a more formal approach and covers 6-8
very well.
Al S AANDERAA P C FISCHER
The solvability of the halting problem for 2-state Post
machines
JACM 14 1967 pp 677-682
A2 M DAVIS
Computability and unsolvability
McGraw-Hill New York 1958210 pp
A3 P C FISCHER
On formalisms for Turing machines
JACM 12 1965 pp 570-580
A4 S GINSBURG
Mathematical theory of context-free languages
McGraw-Hill New York 1966243 pp
A5 H HERMES
Enumerability, decidability, computability
Academic Press New York 1965245 pp
A6 J E HOPCROFT J D ULLMAN
Formal languages and their relation to automata
Addison-Wesley Pub Co Inc 1969 242 pp
A7 S C KLEENE
Mathematical logic
Wiley N ew York 1967 398 pp
A8 M L MINSKY
Computation: Finite and infinite machines
Prentice-Hall Englewood Cliffs NJ 1967 317 pp
A9 J MYHILL
Linear bounded automata
WADD Tech Note 60-165 Wright-Patterson Air Force
Base Ohio 1960
AlO E L POST
Recursive unsolvability of a problem of Thue
J Symbol Logic 11 1947 pp 1-11
All H ROGERS JR
Theory of recursive functions and effective computability
McGraw-Hill New York 1967482 pp
A12 J C SHEPHERDSON H E STURGIS
Computability of recursive functions
JACM 10 1963 pp 217-255
A13 B A TRAKHTENBROT
Algorithms and automatic computing machines
Translation by J Kristian J D McCawley and S A Schmitt
D C Heath Boston 1963 101 pp
A14 A M TURING
On computable numbers, with an application to the
Entscheidungsproblem
Proc London Math Soc Ser 2 42 1936-1937 pp 230-265
Corr ibid 43 1937 pp 544-546
A15 HWANG
A variant to. Turing's theory of computing machines
JACM 4 1957 pp61-92
Theory of Computing in Computer Science Education
Advanced computability theory
No single solution is proposed for taking Course A7,
now bereft of both basic computability theory and recursive. function theory, and refurbishing it \vith more
relevant material while retaining the computational
complexity theory previously contained there. One
reasonable approach would be to convert the course
into a survey-in-depth of all three areas described
above. The most generous answer (for devotees of computability theory) would be to convert A7 into a course
on computational complexity theory and to establish
new courses in both algorithm analysis and program
schemata. This, in fact, is the current situation in the
graduate program at Waterloo. However, graduate
course offerings are obviously highly dependent upon
the interests and quantity of faculty members. CUntil
the current academic year Waterloo offered courses
equivalent to I-X and a single graduate term course in
computability theory. The latter course took the
survey-in-depth approach.)
Activity in analysis of algorithms has grown so
rapidly that the accretion of new results and interesting algorithms has far exceeded progress in determining
underlying principles. Thus, it will be difficult to keep
a course in this area from becoming a collection of
programming tricks. Nevertheless, courses in analysis
of algorithms have already sprung up at a number of
universities and are attracting respectable enrollment
figures. Furthermore, the potential value of such a
course for persons who think they like programming
and dislike all theory outweighs the difficulties due to
the roughness of the area and lack of adequate pedagogical material. Thus, it is quite likely that many
schools will choose to offer a course in analysis of algorithms regardless of whether or not the computational
complexity and program schemata theory are covered
as well. If this turns out to be the case, the best solution
for Course A 7 would be to embrace both of these latter
areas.
A list of topics and references in each of the three
areas is given below. In view of the discussion just
concluded, these are not to be interpreted as specific
recommendations for courses but only as a sample of
material in each of the areas.
ADVANCED TOPICS AND REFERENCES
As stated previously, the topics and references presented below are not all inclusive and are not suggestions
for three separate courses.
861
Computational complexity
Topics
1. Complexity classes defined in terms of Turing
machine time bounds, space bounds, and tape
reversals. BI4,BI8,B2I,BS4
2. Models for real-time computation, Turing machines with many tapes vs. one or two tapes, Turing
machines with many heads per tape vs. one head per
tape. BI3 ,B24,B29 ,B32
3. Random-access register machines, iterative arrays,
n-counter machines and real-time countability, other
computing devices. B2 ,B9 ,BI5 ,BI6 ,B36
4. Axiomatic approaches to machine structure,
bounded action and bounded activity machines. BIo ,B35
5. Complexity classification by functional definition,
primitive recursive functions, the Grzegorczyk classes,
honest functions, loop program machines. B8 ,B26,B3o,B31
6. Axioms for
machine-dependent complexity
theory, existence of arbitrarily bad programs and arbitrarily hard-to-compute functions, speed-up theorem. B3
7. Machine-independent complexity classes, uniform
hierarchy Ccompression) theorem, honesty theorem,
gap theorem, union theorem. B2o
8. Complexity of finite functions, expressive power
of programs, random sequences. B4,B7 ,B25
References-Contputational contplexity
In general, only· material appearing in standard
journals and written in English is given. Thus, a number of recent results and papers in foreign languages,
principally Russian, containing relevant material have
been omitted. Fairly comprehensive coverage of machine-independent complexity theory as well as some
additional references are found in the paper by Hartmanis and Hopcroft. B20 Two previous references are
also relevant to this area. A9 ,AI2
An extensive "Bibliography on computational complexity" was compiled by M. 1. Irland and the author
in October, 1970, but has not been published. A limited
number of copies are available as Research Report
CSRR 2028, Department of Computer Science, University of Waterloo.
B1 A V AHO J E HOPCROFT J D ULLMAN
Time and tape complexity of pushdown automaton
languages
Information and Control 13 pp 186-206
B2 A J ATRUBIN
A one-dimensional real-time iterative multiplier
JACM 14 1965 pp 394-399
B3 M BLUM
A machine-independent theory of the complexity of recursive
functions
JACM 14 1967 pp 322-337
862
Spring Joint Computer Conference, 1972
B4 M BLUM
On the size of machines
Information and Control111967 pp 257-65
B5 M BLUM
On effective procedures for speeding up algorithms
JACM 18 1971 pp 290-305
B6 R V BOOK S A GREIBACH
Quasi-realtime languages
Math Systems Theory 4 1970 pp 97-111
B7 G J CHAITIN
On the length of programs for computing finite binary
sequences
JACM 13 1966 pp 547-569
B8 A COBHAM
The intrinsic computational difficulty of functions
Proc 1964 Int'l Cong on Logic Methodology and
Philosophy of Science North Holland Amsterdam 1965
pp 24 30
B9 S N COLE
Deterministic pushdown store machines and real-time
computation
JACM 18 1971 pp 306-328
B10 S A COOK S 0 AANDERAA
On the minimum computation time of functions
Trans Amer Math Soc 142 1969 pp 291-314
B11 M J FISCHER A L ROSENBERG
Real-time solution of the origin-crossing problem
Math Systems Theory 21968 pp 257-63
B12 P C FISCHER
Generation of primes by a one-dimensional real-time
iterative array
JACM 12 1965 pp 388-394
B13 P C FISCHER
Turing machines with a schedule to keep
Information and Control 11 1967 pp 138-46
B14 P C FISCHER
The reduction of tape reversals for off-line one-tape Turing
machines
J Computer Syst Sci 2 1968 pp 136-47
B15 P C FISCHER A R MEYER A L ROSENBERG
Counter machines and counter languages
Math Systems Theory 2 1968 pp 256-83
B16 P C FISCHER A R' MEYER A L ROSENBERG
Time restricted sequence generation
J Computer Syst Sci 4 1970 pp 50-73
B17 J HARTMANIS
Computational complexity of one-tape Turing machine
computations
JACM 15 1968 pp 325-39
B18 J HARTMAN IS
Tape reversal bounded Turing machine computations
J Computer Syst Sci 2 1968 pp 117-35
B19 J HARTMAN IS
A note on one-way and two-way automata
Math Systems Theory 4 1970 pp 24-28
B20 J HARTMANIS J E HOPCROFT
An overview of the theory of computational complexity
JACM 18 1971 pp 444-475
B21 J HARTMANIS R E STEARNS
On the computational complexity of algorithms
Trans Amer Math Soc 117 1965 pp 285-306
B22 F C HENNIE
One-tape, off-line Turing machine computations
Information and Control 8 1965 pp 553-578
B23 F C HENNIE
On-line Turing machine computations
IEEE Trans on Electronic Computers EC-15 1966 pp
35-44
B24 F C HENNIE R E STEARNS
Two-tape simulation of multi-tape Turing machines
JACM 13 1966 pp 553-556
B25 P MARTIN-LOF
The definition of random sequences
Information and Control 9 1965 pp 602-19
B26 A R MEYER D M RITCHIE
The complexity of loop programs
22nd National Conference Association for Computing
Machinery 1967 pp 465-69
B27 D PAGER
On the problem of finding minimal programs for tables
Information and Control 14 1969 pp 550-54
B28 M 0 RABIN
Degree of difficulty of computing a function and a partial
ordering of recursive sets
Technical Report 2 Hebrew University Jerusalem Israel
1960
B29 M 0 RABIN
Real time computation
Israel J Math 1 1963 pp 203-11
B30 R W RITCHIE
Classes of predictably computable functions
Trans Amer Math Soc 106 1963 pp 139-73
B31 R W RITCHIE
Classes of recursive functions based on Ackermann's function
Pacific J Math 15 1965 pp 1027-44
B32 A L ROSENBERG"
Real-time definable languages
JACM 14 1967 pp 645-62
B33 W J SAVITCH
Relationships between nondeterministic and deterministic
tape complexities
J Computer Syst Sci 4 1970 pp 177-92
B34 R E STEARNS J HARTMAN IS P M LEWIS II
Hierarchies of memory limited computations
IEEE Conference Record on Switching Circuit Theory
and Logical Design 1965 pp 179-90
B35 E G WAGNER
Bounded action machines: Toward an abstract theory of
computer structure
J Computer Syst Sci 2 1968 pp 13-75
B36 H YAMADA
Real-time computation and recursive functions not real-time
computable
IRE Trans on Electronic Computers EC-11 Corr ibid
EC-12 1963 p 400
B37 P R YOUNG
Toward a theory of enumerations
JACM 16 1969 pp 328-348
A nalysis of algorithms
Topics
1. Matrix multiplication in fewer than n 3 steps.
Some lower bounds for matrix multiplication and inner
product. C3,C1O,CI3
Theory of Computing in Computer Science Education
2. Polynomial evaluation. Optimality of Horner's
rule in general case, preconditioning. Evaluation of a
polynomial at more than one point. C7
3. Lower bounds for addition and multiplication of
integers. Methods for multiplying in fewer than n 2 bitwise operations. Fast Fourier transforms and their
application to multiplication. C5 ,C8,C11 ,C12
4. Sorting and searching methods. Treesort, radix
sorts, polyphase sorts. Lower bounds on the number of
comparisons necessary. Finding the ith largest in a set
of elements. Evaluation of binary searching, AVL
trees. C2,C4,C6
5. Graph algorithms. Planarity testing, connected
components of a graph, transitive closure.
6. Miscellaneous algorithms. Matrix transposing in a
paging environment, garbage collection, g.c.d. of polynomials, power of an expression, etc. Cl
References-Analysis of algorithIlls
A considerable amount of current material is available only in the form of course notes or technical rep::>rts. Such items have been omitted here although
courses being taught in analysis of algorithms are drawing up to half of their material from such sources. Thus,
the references below serve more to give the flavor of
this area than to constitute any approximation to a
complete set of source material. Presumably much of
the current material will appear in standard journals
within a year.
Many informal working papers in this area can be
found in recent Proceedings of the ACM Symposia on
Theory of Computing (available from ACM) and
Proceedings of the IEEE Symposia on S"witching and
Automata Theory (available from the IEEE or the
IEEE Computer Group). Also, a "Bibliography on the
analysis of algorithms" has been compiled by Professor
E. M. Reingold, Department of Computer Science,
University of Illinois at Urbana. As of the time of
writing it has not been published.
C1 A BRAUER
On addition chains
Bull Amer Math Soc 45 1939 pp 736-739
C2 CAR HOARE
Quicksort
Computer J 5 1962 pp 10-15
C3 J E HOPCROFT L KERR
On minimizing the number of multiplications necessary for
matrix multiplication
SIAM J Appl Math 20 1971 pp 30-36
C4 R M KARP W L MIRANKER
Parallel search for a maximum
J Combinatorial Theory 4 1968 pp 19-35
863
C5 D E KNUTH
The art of computer programming, volume 2
Addison-Wesley Reading Massachusetts 1969 sections
4.3.3, 4.6.3, and 4.6.4
C6 D E KNUTH
The art of computer programming, volume 3
Addison-Wesley Reading Massachusetts to appear 1972
section 5.3
C7 V YA PAN
Methods of computing values of polynomials
Uspehi Mat Nauk 21 1966 pp 103-134 Russian English
translation in Russian Math Surveys 211966 pp 105-136
C8 A SCHONHAGE
Multiplication of large numbers
Computing 1 1966 pp 182-196 (German with English
summary) See Comput Rev 8 1967 review number 11544
C9 P M SPIRA
The time required for group multiplication
JACM 16 1969 pp 235-243
C10 V STRASSEN
Gaussian elimination is not optimial
Numer Math 13 1969 pp 354-356
Cll S WINOGRAD
On the time required to perform addition
JACM 12 1965 pp 277-285
C12 S WINOGRAD
On the time required to perform multiplication
JACM 14 1967 pp 793-802
C13 S WINOGRAD
On the number of multiplications necessary to compute
certain functions
Comm Pure Appl Math 23 1970 pp 165-179
Program schemata
Topics
1. Flowchart schemata. Interpretations of schemata.
Herbrand Interpretations. Undecidability of halting
and equivalence problems. Various notions of
equivalence. D4,DlO
2. Special classes of flowchart schemata: Ianov
schemata, two-location schemata, nested-loop ('while')
schemata. Translation of flowchart schemata to 'while'
schemata.
3. Recursive schemata. Translation of flowchart
schemata to recursive schemata. Recursive schemata
with no equivalent flowchart schemata. Decidable
properties of monadic recursive schemata. Equivalence
methods for recursive schemata; truncation induction. D5
4. Models of parallel computation. Determinancy;
deadlocks. Equivalence-preserving transformations; increasing and decreasing the 'parallelism'. D3
5. Correctness of programs, choice of predicates associated with locations in a program. D2,D6,D9
6. Formal definitions of program structure. Dl ,D12
864
Spring Joint Computer Conference, 1972
References-PrograIIl scheIIlata
Some papers concerned with program definition and
programming semantics are included as well as those
.dealing directly with program schemata. As before,
much current material has not made its way into the
accessible literature.
D1 E ENGELER
A 19orithmic approximations
J Computer Syst Sci 5 1971 pp 67-82
D2 R W FLOYD
Assigning meaning to programs
In Proc Symposia in Applied Mathematics 19 American
Mathematical Society 1967 pp 19-32
D3 R M KARP R E MILLER
Parallel program schemata
J Computer Syst Sci 3 1969 pp 147-195
D4 D C LUCKHAM D M R PARK
M S PATERSON
On formalised computer programs
J Computer Syst Sci 4 1970 pp 220-249
D5 J McCARTHY
A basis for a mathematical theory of computation
In Computer Programming and Formal Systems
North-Holland Amsterdam 1963 pp 33-70
D6 Z MANNA
The correctness of programs
J Computer Syst Sci 3 1969 pp 119-127
D7 Z MANNA R WALDINGER
Toward automatic program synthesis
Comm ACM 14 1971 pp 151-165
D8 R MILNER
Program schemes and recursive function theory
In Machine Intelligence 5 Edinburgh University Press
1970 pp 39-58
D9 D PARK
Fixpoint induction and proofs of program properties
Ibid pp 59-78
DlO M S PATERSON
Program schemata
In Machine Intelligence 3 Edinburgh University Press
1968 pp 18-31
D11 D SCOTT
Outline of a mathematical theory of computation
Tech Monograph PRG-2 Oxford University Computing
Laboratory Programming Research Group 197024 pp
D12 D SCOTT
The lattice of flow diagrams
Tech Monograph PRG-3 Oxford University Computing
Laboratory Programming Research Group 197057 pp
ACKNOWLEDGMENTS
The author gratefully acknowledges the material and
suggestions provided by E. A. Ashcroft, M. J. Fischer,
A. R. Meyer, J. 1. Munro and E. M. Reingold.
Social science computing-1967-1972
by HUGH F. CLINE
Russell Sage Foundation
New York, New York
Social science computing continues to grow both in
quantity and variety of problem applications. Increasing numbers of social scientists are using increasing
amounts of computer time on an increasi~g array of
machines. Social scientists have upgraded their competence in computing and produced a number of programming systems for use in their research and instructional
activities. Each year more social science graduate students are trained in the use of computers, and more
social science departments now have at least one faculty
member who is competent in computing. Of course, all
these developments did not occur in the past five years.
Important preliminary steps were taken as early as fifteen years ago. But during the period 1967-1972, social
science computing has made significant progress and is
now recognized as a member of the computing community.
In addition to increasing the amount of use, the number of programming systems, and the level of competence,. social scientists have also vastly improved the
exchange of information among computer users. Five
years ago most social scientists were completely ignorant of computing activities outside their own institution. Many graduate training centers had developed
a set of standardized, second-generation computer programs for social science research, but very few of these
were ever exported to other universities. This was partially due to the difficulties of producing machine-independent programs, but patriotic zeal for the "local
product" also created a reluctance to learn about other
programs or systems. Many of these locally developed
programs became obsolete with the distribution of thirdgeneration machines, and social scientists, who were
unwilling to make the effort to redesign and reprogram,
took their heads out of the sand and began to look elsewhere. The transition from the second to the third generation caused many problems for social scientists as
well as others, but it did lift the self-imposed intellectual
quarantine among social scientists and created the climate for effective exchange of information on computing
activities.
The most notable development in this regard has
been the establishment of the SIGSOC Bulletin, a
quarterly publication of the Special Interest Group for
Social and Behavioral Science Computing of the Association for Computing lVlachinery. Under the editorship of John Sonquist, University of California, Santa
Barbara, the SIGSOC Bulletin has become a major
source of communication among the 450 subscribers.
In addition, the activities of such organizations as the
Inter-University Consortium for Political Research at
the University of Michigan, the Roper Public Opinion
Research Center at Williams College, and the National
Program Library/Central Program Inventory Service
for the Social Sciences (NPL/CPIS) at the University
of Wisconsin have all contributed to the production of
the new social scientist computer cosmopolite.
Despite all these promising developments over the
past five years, it is not correct to state that social
science computing is problem free. There are a number
of very serious problem areas which require concerted
attention in the next five years. In order to highlight
these questions, I will present some findings from a study
of computer uses in the social sciences which I have
undertaken for Russell Sage Foundation. The study includes a description of current social science computing
activities and an examination of the influence of computing on substantive social science problems.
Before turning to the results of the study itself, it
should be useful to describe briefly in what ways social
scientists are using computers. I have found it convenient to distinguish among four general types of computing applications: data processing and statistical
analysis; simulation; computer-controlled experimentation; and large data file management. The most common application, data processing and statistical analy865
866
Spring Joint Computer Conference, 1972
sis, has often been referred to as the "bread and butter"
of social science computing; for it typically accounts for
the bulk of social science department computing budgets. Although most such applications involve numerical data, the analysis of textual materials is increasing.
Typically, the investigator first puts the raw data into
machine-readable form, i.e., on punched cards or magnetic tape; and then the computer is used for error detection, correction, and data reduction. Subsequently,
canned programs, i.e., previously written generalpurpose programs, are used to perform the more standard techniques of statistical analyses. For the most
part, these applications of computers involve procedures
which previously were accomplished on punched-card
equipment and desk calculators. Although other types
of computer applications in social science research will
undoubtedly increase in the near future, data processing
and statistical analyses will continue to be the modal
type of computer usage for some time to come.
Simulation, the second type of computer use 1 is considered by many to be the most promising. Social science
simulation is the construction and manipulation of an
abstract operating model of a social system or process.
Physical operating models such as wind tunnels and
flotation tanks are well-known in scientific research, but
all social science models of systems are abstractions
stated in mathematical equations. The investigator designs his model by breaking a system down into subunits and describing both the subunits and the relationships between subunits in quantitative terms in a simulation programming language. The computer is then
used to provide artificial blocks of time in which the
system operates and subunits interact and are modified
according to the model. The investigator usually compares initial and final values describing system subunits.
During the course of the research, different initial
values and relationships between subunits may be tried
in the model to produce a better fit to data observed
from the real world. Simulations have been done on
many different types of problems with varying degrees
of success including such things as racial integration in
suburban housing tracts, old age pension programs,
federal aid to state education programs, and international relations problems. Of course, the value of a
simulation depends upon the investigator's ability to
break a system into its subunits and realistically state
initial values and relationships between subsystems.
The third type of computer use in social science research, computer-controlled experimentation, is for the
most part still limited to the discipline of psychology.
Real-time computers are being used by a small number
of innovators to control, monitor, and change laboratory conditions. The feeding schedules for animals, the
timing and sequencing of presentation of stimuli to sub-
jects, and the monitoring and recording of communications between subjects in experimental settings are
all now being done with the assistance of computers. In
contrast to the other types of social science computer
use, computer-controlled experimentation usually requires a machine that is used exclusively for this purpose. These computers are usually smaller and slower,
but they require special-purpose input/output devices
which are often unique and expensive. Using computers
to monitor, modify, and in some cases to supervise
research certainly will open new areas for social science
research.
The use of computers for large data file management,
the fourth type of application, is a new phenomenon in
social science research. Many investigators are now using very large data files, such as the one-in-a-thousand
sample of the census which contains over 15 million data
items. It is virtually impossible to use these files for research without the aid of computers, and the problems
of manipulating large data sets in an efficient manner
ar~ gaining increasing attention. Alternate methods of
formatting and storing data files to match the input requirements of the standard analysis routines and new
programs for large data files are being developed. In
addition, social scientists are continuing to merge
copies of sample surveys for secondary analyses. The
problems of storing, searching, and retrieving subsets of
data from these archives are now being handled on
computers.
The survey of social science computing activities was
limited to academic settings. Although it is quite true
that important innovations in social science computing
have occurred in independent research institutes, such
as The Brookings Institution, the National Bureau of
Economic Research, and The RAND Corporation, as
well as in the research departments of large business
corporations, it was decided to restrict the study to
universities; because obtaining a comprehensive list of
non-academic research institutes would have been a
major research undertaking itself. The survey data were
collected at the midpoint of the half decade, May 1969,
with a four-page questionnaire mailed to the chairmen
of the 517 departments which have granted at least one
Ph.D. degree since 1960 in the following disciplines:
anthropology, economics, agricultural economics, political science, psychology, educational psychology, and
sociology. After two follow-up mailings and telephone
calls, 421 completed questionnaires were received, giving
an overall response rate of 81.4 percent. Table I presents the response rates for the disciplines, which range
from 75.0 percent to 92.6 percent.
The 517 departments are located on 134 campuses.
At least one department responded from 130 campuses;
and this means that we have some data on social science
Social Science Computing
TABLE I-Disciplines and Response Rates
Questionnaires Questionnaires Response
Returned
Rate
Mailed
Disciplines
Anthropology
Economics
Agricultural
Economics
Political Science
Psychology
Educational
Psychology
Sociology
47
99
27
36
78
25
76.6
78.8
92.6
95
121
36
80
97
27
84.2
80.2
75.0
92
78
84.8
517
421
81.4
computing from 97.0 percent of the universities included
in this study. Although the questionnaires were mailed
to the chairmen, the cover letter encouraged them to
seek the advice and assistance of their colleagues in
answering the questions. The data should therefore be
interpreted as organizational, i.e., department responses.
This is appropriate, for the items were designed to collect information on computing activities and not the
opinions or attitudes of any particular individual. The
questionnaire elicited information on hardware, software, instructional programs, and levels of computing
competence.
Turning first to hardware, Table II shows the proportions of departments reporting access to punchedcard equipment and desk calculators. The first column
headed "Department" reports the proportion of departments that had such equipment available for their
exclusive use, and the second column gives the proportion of departments which had access to the machines
in the central university computer center.
This data indicate that keypunches, sorters, reproducers, and card printers were more widely available
in university computing centers and that desk calculators and programmable calculators (Wang, Monroe,
Olivetti, and Marchang) were more frequently available
for exclusive departmental use. Despite the fact that
departments had somewhat limited punched-card facilTABLE II-EAM Equipment
Machines
Keypunches
Coun ter /Sorters
Reproducers
Card Printers
Desk Calculators
Programmable Calculators
Departments
Computer Center
41.6
24.7
9.7
3.6
87.4
15.9
85.0
82.7
75.1
67.5
35.8
1.2
867
ities, most did have access through their computer
centers.
A total of 358 computers were reported available for
social science research and instruction. This is an average of 2.8 computers per campus. (These figures on
number of computers are combined from department
responses for each campus, and machines reported by
several departments are counted only once.) Table III
presents the distribution of computers by manufacturers reported in the study.
IBM computers accounted for 66.5 percent of the
total. Approximately 50 percent of the IBlVf machines
were third-generation, i.e., System 360; and about half
of the third-generation machines were Models 50 or
larger. Digital Equipment Corporation computers were
TABLE III-Computers by Manufacturers
Manufacturer
Number of
Computers
Percent
International Business Machines
Digital Equipment Corporation
Control Data Corporation
UNIVAC
Honeywell
Burroughs
General Electric
Xerox Data Systems
RCA
Philco
238
59
28
6
5
4
4
2
1
66.5
16.4
7.8
3.1
1.7
1.4
1.1
1.1
0.6
0.3
Total
358
100.0
11
the second largest type available to social scientists, but
this manufacturer and all others were far below IBM
in social science computing. Of all reported computers,
16.4 percent were DEC machines; and about 60 percent
of these were PDP 8's. The Control Data Corporation
was the third largest manufacturer with 7.8 percent of
all the computers reported, and almost half of the CDC
machines were 6000 series computers. Finally, UNIVAC
was the fourth largest manufacturer with 3.1 percent,
and about half of these machines were UNIVAC 1108's.
All other manufacturers were under 2 percent, and these
included Honeywell, Burroughs, General Electric,
Xerox Data Systems, RCA, and Philco.
Dominance of IBM in social science computing is of
course no surprise. However, the fact that two-thirds
of the computers available to academic social scientists
were manufactured by one supplier should not be interpreted as ;widespread uniformity in social science
computing systems. Over 22 different types of IBM
868
Spring Joint Computer Conference, 1972
TABLE IV-IBM Computers
IBM Model
Number of
Computers
Percent
1130
1401
1500
1620
1710
1800
7040
7044
7072
7700
7094
360/20
360/25
360/30
360/40
360/44
360/50
360/65
360/67
360/75
360/91
25
35
2
22
1
8
6
3
2
1
16
16
1
8
22
5
27
15
9
11
3
10.5
14.8
0.8
9.2
0.4
3.4
2.5
1.3
0.8
0.4
6.7
6.7
0.4
3.4
9.2
2.1
11.4
6.3
3.8
4.6
1.3
Total
238
100.0
machines were reported. Table IV shows the distribution of IBM machines by model.
These machines vary widely in cost, instruction sets
speed of the central processing units, size of memories
and available inputj output devices. This variation
shows very clearly why it has been extremely difficult
to produce programs which can be widely used on many
different types of machines.
The average number of computers per campus was
2.8. This figure is somewhat misleading, for these computers were not evenly distributed across all universities
or departments. It is often the case that members of one
department have access to a computer; but due to funding or administrative restrictions, members of other departments on the same campus may not have access.
Table V lists the distribution of the number of computers reported available to the 421 departments.
Notice this distribution is quite uneven. The modal
category of one computer includes 35.9 percent of the
departments. A very small proportion, 3.8 percent, of
the departments were comparatively quite wealthy,
having access to six or more computers; and 28 departments, or 6.6 percent, reported they still did not
have access to any computer.
In addition to the type and number of computers
available, the location and administrative auspices of
the machines also influence their utility for research
and instruction. Almost 70 percent of the computers
were located in a central university computing center.
The remaining 30 percent were widely distributed
among other university computer centers, research
institutes, departments, commercial service bureaus,
and combined social science department computing
centers. Despite the many recent debates over the advisability of centralization or decentralization of university computing facilities, the data show that the
pattern of centralization had not changed very much;
and only in a very small proportion of cases, 5.3 percent, was there a computing facility for the exclusive
use of the social scientists.
University-based scholars in many disciplines have
recently expressed enthusiasm for the possible applications of time-sharing systems in their research and
instruction. Some type of time-sharing system was reported at 33, or 25.4 percent, of the universities included
in this study. Most of these were interactive compilers,
which can be used for finding ~rrors in programs but not
for data processing and analysis. Only ten universities
had fully operational time-sharing systems, which can
execute programs; and most of these had severe restric~
. tions on the size of the data files they can handle. In
addition, 29 universities reported using some type of
commercial time-sharing service. It is not surprising
that time-sharing has not been more widely used in the
social sciences, for very few of the existing systems are
capable of efficiently handling large input or output
files. Since many social scientists typically have mediumto large-sized data files, they find that most existing timesharing systems simply cannot be used.
Regardless of whether a computer is used in a timesharing or conventional manner, the hardware, including the central processing unit, the memory, and the
inputj output devices must be provided with the software or programs to execute the symbol manipulations
the scientist requires for his problem. Although software
usually refers to operating systems, compilers, assemblers, and applications programs, this study of comTABLE V-Number of Computers Available to Departments
Number
Percent
None
1
2
3
4
5
6+
6.6
35.9
29.0
13.8
6.2
4.7
3.8
100.0
Social Science Computing
puter uses in the social sciences has been limited to
higher-level languages and packages of programs. Table
VI presents the higher-level languages most commonly
reported by the departments.
FORTRAN IV comes close to being a universal
language, but the fact that 98 percent of the departments with access to computers reported the availability of FORTRAN IV does not automatically produce
uniformity and standardization, for there are many
variations of the language. Limited instruction sets and
maximum permissible program sizes are two of the
major sources of variability. The languages most commonly available are those which the major manufacturers support with continuous error correction, documentation, and further development. The fact that
FORTRAN and COBOL are so widely available to
social scientists is for the most part a result of IBM's
policy to support these two languages on most of their
computer systems.
TABLE VI-Languages Available
Language
FORTRAN IV
COBOL
ALGOL
PLjI
FORTRAN II
WATFOR
SNOBOL
BASIC
OTHER
Percent
98
77
62
51
49
44
38
28
55
Over ninety different languages were reported in this
study. Some of these have been developed locally at the
universities, and others have been produced by small,
commercial software companies. One can quite legitimately question the extent to which these languages are
thoroughly debugged and documented, for very few
universities or commercial software houses have the
manpower and expertise necessary for the adequate
support of languages.
The distribution of higher-level languages available
to social scientists is more easily understood by examining the number of languages reported by each department, as shown in Table VII.
The average number of languages reported by each
department was 5.9. The typical pattern for a department was to have two or three languages maintained by
the hardware supplier and several additional, special
purpose languages maintained locally. It should be
pointed out that these data refer to the number of languages reported available to social scientists. In a mail
869
TABLE VII-Number of Languages
Number
Percent
1-2
3-4
5-6
7-8
9+
10.5
23.6
29.9
18.9
17.1
100.0
questionnaire, it was not possible to assess the extent
to which these languages were used. However, on the
basis of personal visits to over a dozen major social
science graduate training centers, it is my clear impression that most social scientists use a subset of the available languages. Many social scientists adopt one and
only one computer language, and they sing praises to
this language with the same intense emotional commitment as the immigrant who extols the virtues of his
new country.
Departments were also asked to report on the data
processing and statistical analysis packages of programs
available to the members of their departments. The
distribution of the most commonly reported packages is
listed in Table VIII.
The BlVID Package, developed under the direction of
Professor W. J. Dixon at the Health Sciences Computing
Facility, University of California, Los Angeles, comes
closest to being the universal social science statistical
package. 1 Of the departments using computers, 76 percent report having access to the BMD Package. The
various computer programs included in this package
have proved useful in the past in many types of biomedical research projects at UCLA. Written in FORTRAN IV, and therefore relatively easy to export to
other computer systems, the programs in this package
include routines for data description and tabulation,
multivariate analyses, regression analyses, time-series
analyses, variance analyses, and a series of special programs for data transformation and scaling. Although
TABLE VIII-Packages Available
Package
BMD
SSP
SPSS
OSIRIS
Data-Text
Other
Percent
76
52
16
16
13
87
870
Spring Joint Computer Conference, 1972
created in response to the needs of biomedical researchers, this library of programs has been more widely
distributed to social scientists than any other package.
The second most widely available statistical package
was the Scientific Subroutine Package (SSP). 2 It is a
collection of over twenty different statistical routines
maintained and distributed by IBM. Because it is
written in FORTRAN IV, it is also easily exported.
However, the Scientific Subroutine Package is not easily
used by most social scientists. As the name implies, this
package is a collection of subroutines; and the user must
write a FORTRAN main or calling program for the subroutine he requires. Very few social scientists are able
to write a FORTRAN program with appropriate linkages to subroutines. Despite the fact that our data show
that 52 percent of the reporting departments had access
to the Scientific Subroutine Package, I seriously doubt
the extent to which this package is heavily used by social
scientists.
The remaining three packages most commonly reported by our respondents were the Statistical Package
for the Social Sciences (SPSS) developed by Norman H.
Nie of the National Opinion Research Center and University of Chicago,3 the statistical package OSIRIS developed at the Institute for Social Research at the University of Michigan, under the direction of Ralph Bisco, *
and Data-Text, developed by Arthur Couch and David
Armor at Harvard University. SPSS and OSIRIS are
both written in FORTRAN IV and are relatively easy
to export. The Data-Text Package was originally written in FAP, the assembly language of the IBM 7094,
and operates only on the few remaining 7094 installations. Under Armor's direction, Data-Text was being
reprogrammed in FORTRAN IV, and an expanded
version was distributed in 1971. 5 Both Data-Text and
SPSS implemented a user-oriented language in which
job parameters are specified in a format similar to the
natural language social scientists use in discussing data
processing and statistical analyses. For example, one
requests cross-tabulations by preparing a control card
which states: COMPUTE CROSSTABS SEX BY OCCUPATION. OSIRIS has recently substituted for
numerical job parameters a similar user-oriented language.
Eighty-seven percent of the departments reported
packages other than the five mentioned above, and there
were over 170 different packages. One can, of course,
question the extent to which these are completely different packages. In many cases, universities have made
* Documentation for OSIRIS is maintained in machine-readable
form for frequent updating and is available upon request from
the Institute for Social Research, The University of Michigan.
minor modifications in existing packages and merely
given them a local name. Nevertheless, it has become a
common practice for many universities, and in some
cases even for departments, to develop a set of programs
which have a common input/output format. These
packages are locally used and maintained. Typically the
documentation is exceedingly poor. Efforts to support
these programs are not well funded; and most of the
programs have never been thoroughly debugged.
Despite the fact that over 170 packages were reported
by the departments, the number of packages available
to each department was quite small. Table IX lists the
distribution of the number of packages.
'I;he average was 3.0 packages per department, and
the distribution was highly skewed in the direction of
one, two, and three packages per department. Given the
problems of importing, documenting, and maintaining
these packages, it is not surprising that the number is
quite small. Furthermore, since most of these packages
include similar routines, there is very little to be gained
by increasing the number of packages available.
Both the excess of localiy developed packages and the
small number of packages available to any given department point to some of the major problems in social
science computing. Firstly, many of the packages leave
a great deal to be desired in terms of accurate and efficient algorithms. Furthermore, a social scientists who
develops expertise in using only local packages typically
finds himself completely ignorant when he moves to
another university.
Finally, and most importantly, the distribution of
existing statistical packages has significant implications
for substantive social science research problems. Despite
the fact that most departments have access to more
than one package, it is my clear impression that social
scientists still prefer to use the locally developed package. Drawing from either a sense of comfort in using the
package developed by someone they personally know or
TABLE IX-Number of Packages
Number
1
2
3
4
5
6
7+
Percent
24.3
25.4
21.7
9.5
9.0
4.6
5.5
100.0
Social Science Computing
from some sense of pride in "our thing," most social
scientists avoid using the more widely distributed packages. This preference for the local package becomes a
more serious problem when it is limited in the number of
data analysis routines offered to the user. For example,
many of the local packages only have routines for crosstabulations. This means that both students and faculty
are indirectly encouraged to conceive all their substantive problems in a cross-tabulation research design.
Despite the excessive duplication of insufficient efforts in producing packages, there are still many universities that are attempting to design new packages for
data processing and statistical analysis. Clearly there
is a need for some duplication and competition; but
what seems more critical now is leadership in establishing some cooperation, uniformity, and standards in the
development of these packages.
Of course, the availability of adequate hardware and
software is not sufficient for solving the problems of effectively using computers in social science research and
instruction.lVIost social scientists have become painfully
aware of the fact that it is necessary to develop some
competence in computing to use these machines in pursuing substantive research problems. In order to assess
the extent to which social scientists are gaining some competence in computing, the respondents were asked to
indicate separately for undergraduates, graduates, and
faculty members the proportion who: (1) can write programs in higher-level languages; (2) can use statistical
package programs; and (3) use computers in research
problems. Table X lists the average proportions reported.
Among the undergraduates, only 15.2 percent could
write programs in higher-level languages; 18.8 percent
could use statistical packages; and 16.4 percent used
computers in research. For graduate students the figures
are slightly higher. Roughly one-quarter, 23.6 percent,
knew a higher-level language ; almost one-half, 41.3 per-
T ABLE X-Levels of Competence
Percent
Proportion of
Individuals Who
Can Write in High Level
Languages
Can Use Statistical
Packages
Use Computers in
Research
Undergraduate
Graduate Faculty
15.2
23.6
16.9
18.8
41.3
32.7
16.4
50.6
48.7
871
cent, could use statistical packages; and slightly over
one-half, 50.6 percent, used computers in their research.
On the other hand, faculty members really possessed no
more competence in writing programs than undergraduates, 16.9 percent. Fewer faculty, 32.7 percent,
than graduate students were able to use statistical
packages. Finally, just under half, 48.7 percent, of the
faculty members were reported as using computers in
their research.
Without getting into the old argument as to whether
or not the social science disciplines should be using
quantitative analyses in their research, it is still quite
interesting that in these disciplines, where at the most
basic level research involves symbol manipulation, only
one-half of the faculty members are currently using
computers in their research activities. In addition, the
graduate students are more competent than the faculty.
At the minimum, one can conclude from these data that
social scientists have been slow in building computer
competence in their disciplines.
It is often the case that effective use of computers in
social science research depends upon the availability of
at least one individual who can serve as a liaison between
his colleagues' substantive problems and the computer.
This individual can frequently be of great assistance in
preparing data and programs for computer processing.
In an effort to assess the extent to which such individuals
were available, the chairmen were asked a series of short
questions concerning the computing skills of the most
competent member of the department.
Only 26.1 percent of the departments report that they
have someone who is able to instruct himself on the use
of statistical packages; only 21.4 percent of the departments report the availability of anyone who is able to
·write computer programs; and only 18.1 percent of the
departments report one member who can interpret error
messages and memory dumps to determine the reasons
for unsuccessful runs. This very low report of computer
competent colleagues accounts for some of the difficulty
which many social scientists experience in trying to use
the computer in their research.
Given this low level of computer competence, one
could expect some evidence of concerted attempts to
introduce new instructional programs to produce scholars with some training in computing skills. The chairmen of the departments were asked to indicate separately for their undergraduates, graduate students, and
faculty members, the options available for obtaining
instruction in computing. The proportion of departments which reported the different ways in which members can learn about computing is listed in Table XI.
The data show clearly that most of the computer instruction given to social scientists at all levels· comes
872
Spring Joint Computer Conference, 1972
TABLE XI-Computer Instruction
Percent
Instruction Available
Undergraduate
Graduate Faculty
Department Computer
Course
7.9
12.6
7.6
Department Research
Course
4.6
19.8
4.9
Other Department
Computer Course
47.0
27.5
16.6
Non-credit Computer
Center Course
31.8
31.4
50.3
2.6
2.9
9.7
Self-instruction
either from other departments or the university computer centers. This is reminiscent of the debate popular
some years ago on the question of who should teach social scientists in statistics courses. The consensus on that
issue now seems to be that the instructors should be
individuals who know social science research. It seems
unlikely that the staff of other departments or computer
centers will have this knowledge. Yet, very few departments taught undergraduates any computing in courses
taught within the department. A slightly higher but still
disappointingly low proportion of the departments reported that their graduate students learned in either a
departmental computing course or a departmental research course, 12.6 percent and 19.8 percent respectively. Both the non-credit computer center courses and
courses taught in other departments were the most common options available to all social science students. The
most common option for faculty members, on the other
hand, was only the short non-credit course at the computer center. These courses are typically crash courses
which either teach one higher-level language, most
commonly FORTRAN, or the details of job submission
and operating system control languages for that particular computing facility.
Given the problems noted above concerning the availability of computer hardware and software for the social
sciences, it also appears that there is a critical shortage
of individuals who understand both substantive social
science problems and computing. A very low proportion
of departments reported that undergraduates, graduates, or faculty members are learning about computing
either within their own departments or elsewhere, and
apparently very little is being done to solve the manpower probJem. Graduate students are the most competent group of social scientists in computing, and even
they are severely limited to the use of packages in pursuing substantive problems.
Although much progress has been made in social
science computing in the past five years, the data from
this study indicate that there are a number of major
problems which severely restrict more effective computer-assisted research. These include providing more
equal access to adequate hardware, decreasing the number of packages under development, and providing better support for the documentation and debugging of the
more widely used packages. In conclusion I should like
to point to two additional problems, whose successful
solution I consider as critical.
Perhaps the most immediately pressing problem is the
low level of competence. Social scientists must insure
that adequate instructional programs are offered in all
graduate departments, and students should learn more
than simply how to use the locally developed software. I
would argue that it is irresponsible to produce professional social scientists today who will have an active
career in social science research for the next forty years
without at least some introduction to the basic design
and logic of computers.
A second very pressing problem which is still not
satisfactorily resolved is that of compatibility. It is still
true that most computer programs and data files cannot
easily be exchanged among social scientists using different computers. Very few of the early pioneers in
social science computing appreciated the need for preparing programs and data files for export to colleagues
using different computers. Today, the problem of exportability has reached staggering proportions. Individuals find that many programs and data prepared for
initial processing on one computer simply cannot be run
at another computer center which uses exactly the same
model and manufacturer. Local variations in peripheral
devices and programming procedures make it extremely
difficult and sometimes impossible to move· from one
computer to another.
Although one may place the blame upon the designers
of the early computing systems for not having the foresight to think in terms of standardized data files and
programming cOIwentions, or one may cite the commercial manufacturers for not establishing industry-wide
standards, the problem still remains; and social scientists cannot now realistically look to others for solutions.
They must among themselves agree upon common
standards for program design and data file preparation
which will minimize the problem of exportability.
Granting agencies, both public and private, which support the development of social science computing can be
of great assistance in insisting upon adherence to standards; but the original impetus for this movement must
come from the social science community.
Social Science Computing
REFERENCES
1 W J DIXON ed
BM D biomedical computer programs
Berkeley Cal University of California Press 1970
2 IBM Manual GH20 0166
Scientific subroutine package-Version I I I
3 N H NIE D H BENT C H HULL
Statistical package for the social sciences
New York McGraw-Hi1l1970
4 A S COUCH
T he data-text system
Unpublished user's manual Harvard University 1965
5 D J ARMOR A S COUCH
The data-text primer
N ew York Free Press 1972
873
Future developments in social science computing
by GEORGE SADOWSKY
The Urban Institute
Washington, D.C.
use them, and in government administrative processes
and policy evaluation functions. Statements regarding
social science computing generally are true of a subset
of these activities only. To the extent that there is a
commonality among activities in the field, it is that
they are a collection of processes centered upon observed
data relating to behavioral phenomena.
l\1any aspects of social science computing enjoy an
independent tradition. The methodologies of commercial data processing, information retrieval, source
data capture, statistical inference and digital system
simulation all apply to social science computing
activity, yet professional and methodological development in these fields generally occurs independently of it.
The dependence of social science computing upon a
variety of existing methodological traditions reduces
its cohesiveness as a discipline and complicates the
process of training social scientists for research careers
in which a knowledge of quantitative methodologies is
becoming increasingly important.
INTRODUCTION
The set of computer related activities characterized by
the term "social science computing" is both diverse and
extensive. During the past 15 years, such activities
have· grown substantially both in scope and in volume
and have become increasingly important both for basic
research in the social and behavioral sciences and for
public policy formation and evaluation.
In this paper I will present an overview of the
evolution and present status of social science computing
and examine several factors that are likely to have a
significant effect upon its development during the
next 10 years. Predicting the future is generally hazardous and is complicated in this instance by being dependent upon the development of future computing
technology. During the relatively short history of
automatic digital computing there have been many
predictions-both optimistic and pessimistic-that
have returned in short -order to plague those who made
them; Despite the high risk of error, attempts to
predict the future have some value in planning for that
future state. Attempts to forecast the future also can
often provide a more accurate assessment of the
present, a process from which social science computing
might benefit considerably.
The term "social science computing" is somewhat
misleading in that it implies a homogeneity of computing activities that does not now exist. Activities
as diverse as process control in computer controlled
experimentation laboratories, dynamic macroeconomic
simulation, large survey data collection and analysis,
simulation of alternative social policies, dissemination
of census results, multivariate statistical techniques,
and natural language text processing for content
analysis and concordance production are all included.
Social science computing activities may be observed as
a part of research activity in universities and research
institutions, in commercial organizations· that produce
social science computing products and in those that
HISTORICAL OVERVIEW
Social science automatic computing activity dates
from the introduction of automatic data processing
equipment in the 1880s by Herman Hollerith. Hollerith's machinery was initially used in 1887 by the City
of Baltimore to tabulate mortality statistics,17 and was
later used by other local governments for similar functions. However, its use in sorting and tabulating the
results of the 1890 U. S. Decennial Census of Population marks the beginning of large scale social science
computing. Hollerith's initial innovations led to the development of a family of "unit record" electromechanical accounting machinery for general data processing
applications. A primary use of these machines was to
collect, process, and disseminate statistics for public
purposes. The introduction of Hollerith's automatic
machinery in the census process was followed by a pe875
876
Spring Joint Computer Conference, 1972
riod of increasing use of automatic accounting machinery by government for processing social and economic
statistics. Shortly after the production of electronic
digital computers, the first computer produced commercially-a Remington Rand Univac I -was installed
at the U. S. Bureau of the Census in 1951 for processing
data collected during the 1950 U. S. Decennial Census
of Population. l9
The automation of statistical computing activities
began well before the invention of the automatic digital
computer. l\rlany statisticians made intensive use of the
commercial unit record equipment available prior to the
digital computer. Despite the fact that calculations
performed using this equipment were slow, required
extensive wiring of plug boards, and required repetitive
use of different specialized machines, the resulting
procedures were generally more accurate and faster than
the corresponding calculations performed by hand.
Thus statisticians quickly took advantage of the opportunities offered by automatic digital computation.
During the initial years of automatic digital· computer
use, social science computing tasks were similar to many
other computing tasks. Computers were programmed
almost exclusively in primitive assembly languages,
the programmer often operated the computing equipment himself, and computing activity was localized
around the few computer installations then available.
Survey research centers and individual social scientists
analyzing empirical data continued to rely heavily
upon unit record processing equipment, especially
specialized equipment such as the IBM 101 CounterSorter. The development of higher level programming
languages such as Fortran and Comtran allowed programmers to write programs that were more easily
understandable by non-programmers and more easily
exportable to colleagues using different computing
equipment. During this period the initial "general
purpose" statistical and data processing programs
were produced; such programs were often referred
to as "canned" programs or "program packages."
They were characterized by being machine dependent,
having numeric field control cards and fixed field
punched cards as input, and producing a limited range
of outputs, usually sparsely labelled. Substantial
emphasis was placed upon internal execution efficiency.
An initial milestone in the development of statistical
computing was achieved when VV. J. Dixon and his
colleagues at UCLA created the original set of biomedical statistical programs6 in 1962. This set, initially
known as the BIMD series, provided the user with an
integrated set of programs containing a large number
of statistical procedures; the series included such
features as a common vocabulary across programs, a
comprehensive method of specifying data transformations, adequate user documentation, and readable and
intelligible printed and graphic output. The BIMD
series surpassed previous products by its completeness,
increased user orientation, and emphasis upon exportability to other computer centers. While some aspects
of the original BIMD programs now appear primitive,
the initial impact of this set of programs upon statistical
computing was substantial. The BIMD programs were
developed during a time of intense batch program
construction activity; some of the batch systems
that followed BIJ\lID such as P-STAT2 and DATABANK-MASSAGERla were oriented specifically to
social science users.
Another milestone in the development of social
science computing was the creation and implementation
of higher level languages oriented specifically to tasks
in the field. Shortly after the concept of higher level
languages became generally accepted, a number of
social scientists began to develop languages oriented
specifically to social science computation. I believe
primary credit should go to Arthur Couch and David
Armor at Harvard University for their development of
the Data-Text language. 8 Although implemented originally in assembly language, Data-Text provided social
scientists with free form statement types linked directly
to behavioral science computing procedures.· Considerable effort was spent upon organizing printed
output to the user's specifications. The development of
Data-Text led to other efforts such as BEASTl and
SPSS16 which have been useful as system design
experiments and as applications programs for obtaining
statistical outputs and tabulations from rectangUlar
data files.
A third milestone in social science computing was the
successful exploitation of interactive computing systems
for research and instruction in the social sciences. Using
computer systems that support economical interactive
computing, a number of such programs have been
developed. These include IMPRESSl5 for on-line
instruction in social science computer based research
methods, BASIS20 for on-line statistical ~nalysis,
TROLLl2 for on.;.line time series analysis, equation
system estimation, and econometric simulation, and
others such as TRACE-IlI,a OPS-3,1 and ADMINS.14
These systems are examples of the manner in which
interactive environments have been used to support
powerful tools for social science computing tasks.
Most social science computing activity has depended
critically upon access to behavioral data in machine
readable form. Government agencies and survey research organizations pioneered in developing techniques
for recording survey data on punch cards and analyzing
Future Developments in Social Science Computing
these data mechanically. Universities and private
survey research centers today have substantial holdings
of sample survey data, and much of this material is
available for secondary analysis. Several specialized
data distribution networks have evolved; for example,
the Inter-University Consortium for Political Research
at the University of l\fichigan distributes political
data by mail from its archive to over 100 member
academic organizations, and the National Bureau of
Economic Research makes available its on-line data
bank of aggregate economic time series to its
subscribers.
Government statistical agencies have historically
been important sources of data for quantitative social
science research. The publications of these agencies
were an important source well before the widespread
availability of automatic computing machinery. The
U.S. Bureau of the Census provided a wide variety of
population, housing, labor force and manufacturing
data on an aggregated basis for many years; and after
the 1960 census the Bureau initiated a policy of disseminating population microdata on magnetic tape for
1/10000 and 1/1000 random samples of U.S. families.
Since 1969, microdata collected by the monthly Current
Population Survey have been available in machine
readable form to qualified researchers. Availability of
public data in machine readable form has increased
in recent years as government statistical operations
have become more mechanized and as social scientists
have learned to obtain and use the data eS'ectively.
CURRENT STATUS
Social scientists have available to them today a wide
variety of computer programs for their use. Batchoriented programs for statistical analysis of rectangular
file structures are most common; i:q, addition to the
better known and more reliable of these programs,
there exist many locally developed programs that
perform frequently used statistical procedures. The
quality, accuracy and documentation of these programs vary substantially, and recent evidence presented
by Longleyll and Wampler21 indicates that increased
quality control is needed in their production. Computing languages for the social sciences are relatively
new; however, there has been sufficient development to
indicate the power that such languages provide, and
their continued development seems warranted. More
recently, interactive programs have been developed that
give social scientists flexible control over their procedures and their data. Some very useful interactive
tools have already been produced, but much work will
877
be required to exploit current interactive computer
systems in a truly productive manner.
An increasingly copious flow of behavioral data is
now generated by individual researchers, private
firms, public organizations and governmental organizations, and much of it is in machine readable form.
The increase in complexity of the processing operations
now being used require the input data to be more error
free than was required in the past; present consumers of
micro data especially must be much more sensitive to
noise in their data. There is now increased demand for
government data by private researchers, and the
conflict between the use of individual data for legitimate public purposes and the confidentiality of such
data has yet to be resolved in a satisfactory manner.
Major problems currently exist within the field of
social science computing. Among the most serious
appear to be: (1) inadequate standards for data documentation and problems of data transfer; (2) the low
level of computational knowledge among social scientists
and the lack of adequate training available; (3) the
slow rate of diffusion of computing innovations into
social science computing, especially in government;
(4) problems of program inaccuracy, documentation
and transfer; (.5) lack of adequate software tools for
many types of complex processing operations; and (6)
the low level of professionalism in social science computing activities generally.
Some of the problems that exist in social science
computing are common to most areas of computing
and will be ameliorated by advances in computing
generally. Other problems have been aggravated by the
lack of resources allocated to the social sciences relative
to other disciplines. Still others can be traced to misallocation of those resources made available. Finally, it
appears that the current organization of the social
science computing industry has itself produced or
aggravated a number of present problems.
INDUSTRIAL ORGANIZATION
It seems both appropriate and relevant to employ
one of the social sciences, economics, to study the
industrial organization of the social science computing
industry. For the totality of social science computing
activity is an industry; it encompasses a variety of
products, their producers and consumers, the markets
in which they interact, the mechanisms for distributing
goods, the reward structure for producers, the rate of
investment in capital, incentives for investment, the
rate of technical progress, and other industry characteristics. The institutional structure of social science
878
Spring Joint Computer Conference, 1972
computing directly affects the manner in which individuals and organizations allocate resources to produce a wide variety of products. Solutions to current
problems in social science computing are as likely to
result from organizational change as from technical
advances or increased resource supplies.
1\10st products within the social science computing
industry fall into four general groups: (1) computer
programs; (2) numeric data files; (3) knowledge
regarding numerical methods, statistical procedures and
computing techniques; and (4) personal services. Within
each of these groups, the products produced are
heterogeneous, although there is some evidence of
product differentiation that is largely artificial.
Computer programs range in generality from specialized applications programs to general purpose
applications systems and translators for high level
programming languages. The former are final goods;
they represent unique products designed to satisfy
specific requirements. General purpose programs are
intermediate goods, or producer goods; once created,
they are then used repeatedly to produce a variety of
final goods specified by non-programming computer
users. Data files vary in size and complexity from those
having a rectangular structure with few observations
and variables to those resulting from the 1970 Decennial Census of Population and Housing.
The market for social science computing products
appears to have four important dimensions: (1) locality;
(2) computer type; (3) substantive focus; and (4)
profit/non-profit. Markets have a strong local component because computing installations serve as centers
of knowledge and expertise for their users, and rapid and
inexpensive access to assistance is often essential for the
success of computer related work. In addition, an
organization having a computer center within its
administrative jurisdiction frequently raises barriers
to use of other centers by their staff. Also, the market
is divided according to the manufacturer, model, and
configuration of computing equipment available because programs, data and technical information can
often be transferred at low cost between quite similar
computers but not between dissimilar computers. The
market is also stratified by substantive social science
discipline or research or policy focus, especially with
regard to machine readable data files and computer
programs and hardware configurations that perform
specialized processes within that discipline. Finally,
there is infrequent interchange of programs between commercial firms and academic and research
insti tutions.
There are a large number of producers of social
science computing products, many of whom are
individual social scientists and programmers. In addition, producers include social science computing groups
within research organizations and universi ties, survey
research centers, private firms, and various agencies of
federal, state, and local governments. lVlany of these
producers are also consumers; often production is initiated primarily or wholly for internal consumption.
IVlost producers are active primarily within one of the
above markets, although private firms can generally
respond quickly to changes in demand by acquiring and
reallocating resources.
With one outstanding exception, the subsets of the
industry corresponding to the above broad product
groups exhibit a low degree of industrial concentration,
i.e., no small number of producers comma.nd a major
share of these sub-markets. There currently exist a
large number of producers of social science software,
and except for large applications systems barriers to
entry into the industry are almost non-existent. The
number of producers (suppliers) of data is smaller, and
entry into this industry generally requires a higher
level of investment than entry into program production.
Several organizations have made an investment in
data banks containing economic time series, and competition to provide these data and associated computer
software is now vigorous. Government agencies enjoy a
natural monopoly position in collecting and disseminating data when the data must be made available to the
government by law and is unlikely to be disclosed'
otherwise; examples include population census information and individual and corporate tax return data. In
addition, government agencies enjoy substantial competitive advantages in collecting such data when it
results as a byproduct of on-going administrative
procedures or when the resources required to produce
the data are larger than most potential producers can
mobilize.
The performance of government in producing data in
such a quasi-monopoly position has not been without
fault. Under monopoly conditions, economic theory
would predict that prices would be higher than if
competition existed and the single producer would
earn monopoly profits because of it. Government agencies are generally prohibited from pricing their products
above average cost at most; but· instead the monopoly
position appears to encourage inefficient use of resources
and technology and a lack of responsiveness to consumer
demands. This results in higher prices for the consumer
than would have prevailed in a competitive environment, a sluggish rate of innovation and less consumer
choice.
The distribution mechanism for social science
computing products is in the process of substantial
Future Developments in Social Science Computing
change. Products have been generally recorded on physical storage media such as punch cards, printed paper,
and magnetic tape and these media were physically
distributed to consumers. In the past, high costs associated with this distribution technology were partially
responsible for product markets being segmented by
computer installations and by hardware type. lViore
recently, an increasing number of products are being
distributed by transmitting digital data over common
carrier telephone networks and specialized communications networks, and it appears that this growth will
continue both in relative and absolute terms for some
time.
Knowledge about social science computing products,
statistical procedures, and related computing techniques
reaches potential consumers in a number of ways.
Inter-personal communication now forms one of the
most important means of transmitting such knowledge.
Some dissemenation of this information is made in
publications of computer societies, social science
professional societies, research institutions, and various
related academic disciplines. Informal publications,
workshops and conferences also play an important part
in collecting and distributing knowledge. However, at
the present time there are no information centers or
professional societies focused primarily upon social
science computing.SIGSOC, the Special Interest Group
for Social and Behavioral Science Computing of the
Association for Computing lVlachinery, is a likely
candidate for this position, but its development into a
professional society will take at least 5 to 10 years.
Social science computing products are created in
accordance with the production processes available
to the industry at the time of production. A production
process or function is a set of technical rules that specify
how goods and services called inputs may be transformed into other goods and services called outputS. I9
The levels of knowledge and technology available
dictate what production functions are available for
obtaining specified outputs. If a production process
requires more than one input, there are usually a variety
of combinations of inputs that are capable of producing
the same set of outputs, i.e, the production function
may allow input substitution. In computing, a typical
example of input substitution is provided by the frequent tradeoff in program design between the use of
main memory and processor time; using more of one
generally provides savings in use of the other. Resource
constraints and the relative prices of the inputs enter
into the choice made by producers of which production
process to use for obtaining output.
For mttny social science computing products, the cost
of producing the first unit of a specific output is high
879
relative to the marginal cost of producing subsequent
duplicate units. The cost of duplicating a computer
program or a machine readable data file, once the product has been created, is low and requires only the use
of well-known duplication procedures. However, the
costs paid by social scientists to import programs and
data are generally much higher; the principal reason is
that the distribution technology for these products
is still rather primitive since the products often do not
adapt easily to computing environments other than
those very similar to the environment in which they
were created. The total costs of distribution are therefore often much higher than the costs of duplication.
If the marginal cost of a unit of production is low
relative to the initial investment required to produce
the first unit, then resources are allocated more efficiently if there exist a few large producers rather than
many small producers. Yet with the exception of the
production and distribution of large data files and a
few other products, it appears that the market is
dominated by small producers. There are a number of
factors that help to explain this phenomenon. First,
many of these products are differentiated slightly but
meaningfully for their consumers. Second, computing
products may be one of a number of outputs of a joint
production process; often another output is increased
education for the producer. Also, the very low barriers
to entry encourage new producers into these markets
at low cost to the new entrants.
The above factors help to explain the existence of
small producers of social science computing products,
but they do not explain the relative absence of larger
producers who are able to make substantial investments
in more general and more powerful products. Even
for the first unit of production, there appear to be
substantial economies of scale. That is, there are some
fixed costs in program preparation that must be
incurred regardless of program size. Examples of such
fixed costs in social science computing systems are code
to read the data file and interpret its values, code to
provide elementary output displays and code to
perform standard data transformations; they are almost
always included regardless of how the data are processed. To the extent that fixed costs influence the
production process, a more comprehensive and more
general program appears to be cheaper to construct
than the many smaller programs that duplicate its
functions.
A very important factor limiting substantial investment in computing products is that although the
return to such investment may be high for the industry
as a whole, most of the return cannot be captured by the
investor. Another factor is the segmentation of the
880
Spring Joint Computer Conference, 1972
market discussed previously; if individual markets are
limited in size, then the cost of sales increases and
potential returns are more limited.
Much social science computing activity occurs in
universities, research organizations, government agencies and other environments that often do not enter
the commercial marketplace to buy and sell these
products. Within these organizations, producers are
generally individuals, and the rewards sought are
primarily nonfinancial; rather they are prestige and
recognition for the producer's accomplishment. At the
present time, however, the technical activity associated
with producing computer products for social scientists
does not enjoy high prestige or substantial recognition
for the individual involved. "Tool using," or substantive activity, has higher status within social science
professions than "tool building," or technical activity.
Thus, although changes in the level and allocation of
investment in computing tools for social scientists would
lead to a more efficient allocation of individual skills
and technical resources and would be expected to
provide substantial externalities to social science as a
whole, the reward structure of academic social science
disciplines prevents the individual innovator from collecting his rewards. The lack of a satisfactory reward
structure for non-commercial producers of social science
computing tools is very unfortunate, since it discourages
innovative investment in production for those who are
often able to make substantial contributions to the
field. The inadequate reward structure contains
another unfortunate aspect; it perpetuates a lack of
interest and involvement in computer oriented training
by persons in the social science professions.
THE FUTURE
During the next ten years, continued substantial
growth in social science computing activity is likely to
occur. Social scientists currently being trained are
taught quantitative methods to a greater degree than
any of their predecessors. The amount of data in machine readable form is increasing rapidly. The decreasing cost of computation is shifting the balance in
favor of using computers rather than using manual
labor or not performing a task at all. Furthermore, as
inventories of data and quantitative methods grow
and as the number of practitioners in social science
computing increases, important issues in social and
economic policy become more tractable using the
computer. Although growth in social science computing
will not be uniform and will be unevenly divided
among disciplines and applications, there is little doubt
that it will occur.
Advances in computing hardware and software
during the past 15 years have been responsible for a
dramatic decline in the cost of computing. Current
evidence suggests that logic and memory costs will
continue to decline substantially during the next
decade. These declines in cost will benefit social science
computing activity by reducing the cost of those
computing inputs.
In addition to declines in computing cost, three
specific areas of development within the computer
industry are likely to benefit social science computing
substantially and should be assisted and encouraged.
These areas are: (1) communications terminal technology and interactive system development; (2)
digital data networks linking computers; and (3) data
storage technology. Developments in these three areas
will impact different aspects of the social science computing industry.
The development of reliable and responsive interactive computing systems has already had an impact
upon the manner in which social science computing
is performed. Previous reliance upon batch computing
systems forced social science programs into a mold in
which output decisions had to be made simultaneously
rather than sequentially, computations producing
large amounts of (often unread) output were the rule,
and errors in input preparation resulted in increased
computer costs and turnaround time delays that
were generally large relative to the magnitude of the
error. In general, batch systems have had the effect of
separating a non-programming investigator from his
procedures and his data.
Recent uses of interactive systems provide convincing evidence that it is possible to exploit such hardware in a manner that allows a user considerably more
freedom and flexibility with his data and the procedures he employs. The TROLL system12 provides an
example of such a use. Furthermore, in some general
interactive systems including the first, CTSS,4 batch
and interactive modes of computation are not antithetical but combine naturally to use common system
resources. The appropriate mode of computation may
be chosen according to the characteristics of the task
and the preferences of the user. Recent systems such
as Digital Equipment Corporation's PDP-10 include
interactive-batch compatibility as a basic design
feature; such a feature is not costly relative to the benefits it provides and should be more common in the
future.
The widespread availabilit,y of interactive systems
plus the development of faster and less expensive user
terminals should cause a shift of much social science
computing to these systems. Among the reasons are:
(1) the ability to specify tasks of analysis incrementally
Future Developments in Social Science Computing
rather than collectively; (2) the potential of on-line
interaction with data bases and the ability to browse
through them with flexible computer support functions;
(3) the generally lower cost of making a mistake in
procedure and the ability to detect it more rapidly; and
(4) the resynchronization of the user's processes of
hypothesis formulation, testing, and analysis and the
computer's use in supporting these functions. Batch
processing will not and should not disappear; it will
continue to be used for routine tasks in which interaction is not required or is inappropriate.
The computer terminal market has just begun a
period of rapid development. In the past the terminal
industry was dominated by two large firms, AT&T
and IBM, and the market for terminals grew slowly; the
rate of innovation in the industry was sluggish. As
interactive computing began to increase, the market for
terminals grew rapidly and many new firms entered the
industry. The results have been increased competition,
more product variety for consumers, lower costs, and
anincrease in the rate of innovation. If the growth in
interactive computing continues, the terminal market
should continue growing rapidly. Bigger markets should
lead to increased specialization, some of which will
benefit social science computing directly. For example,
a low cost interactive graphics terminal having moderate power is well within the scope of present technology.
Only a larger market is required for it to be introduced
commercially. Cheaper, faster and more powerful
terminals will make widespread use of terminals
economically feasible and will allow enchancement of
the quality and power of interaction.
The development and availability of general purpose
computer networks is important because they will
remove significant limitations on market size for social
science computing products. By a general purpose
network I refer to a network that can transmit digital
data between any two of its members without knowing
the content of the transmission. Such a network might
exist on a permanent basis, such as the ARPA network18
with its dedicated interface message processors and
reserved communications circuits, or it might consist
only of interface protocols between its members with
common carrier transmission initiated whenever any
member wants to activate a part of the network.
Social science computing product markets are now
segmented by locality and by machine type. One
of the major reasons for this segmentation is the high
cost of importing both programs and large files containing behavioral data. One of the major effects
of such segmentation is that investment in each market
is limited by its size. Thus, investments in special
products are made and replicated in many small
markets.
881
The existence of general purpose networks should
alter this resource allocation pattern. Suppliers of
programs and data bases will have access to a much
larger market for their products; the prospect of larger
returns should serve to increase both the degree of
specialization of those producers and the amount of
investment they are willing to make in their products.
For consumers of social science computing products,
such networks will increase substantially the number
and variety of products available to them. As an example, consider the problem of accessing data files
residing at a remote computer center. In the past,
data have generally been exported by moving the
data file from its initial computing environment to the
data requestor's computing environment; usually the
environments are technically and administratively
dissimilar. The technical problems involved in such
transfers are solvable, but they are generally time consuming and tedious. Computer networks offer viable
technical alternatives to this procedure. Using a
network, it would be possible to transmit a request for
processing and output to the computer environment
in which the data are stored and transmit the results
back to the requestor. If the cost of transmission is
low and there are few administrative barriers to access,
every user can regard any program or data file on the
network as being within his own facility and available
to him at only moderately higher cost. Alternatively,
the data could be transferred directly to the user's
computer, since the existence of the network implies
functional interfaces between each computer in the
network and the network circuit itself.
The availability of computer networks should
substantially reduce the inconvenience and costs of
accessing remote computers, provided that the institutional and administrative problems of interorganizational computer access can be solved. This
will create larger markets for social science computing
tools and will lead producers to raise their level of
investment in the products they offer. In addition,
there should take place a trend toward specialization
in the construction of tools for use, and collection and
maintenance of specialized data bases at various research-oriented computer centers. An example of this
process is provided by TROLL,12 an on-line system
for macroeconomic estimation and simulation. TROLL
is available to its customers on-line using the AT&T
telephone network. Partially as an outgrowth of the
development of TROLL, a Computer Center for
Economics and ]Hanagement Sciences has been established by the National Bureau of Economic Research
to continue and extend the production of quantitative
methodology and computing tools. I t is anticipated
that access to programs and data will be made on-line,
882
Spring Joint Computer Conference, 1972
using the telephone system to support network
communication.
Initially, the existence of network communication
links will be far more important than how the network
is implemented. The existence of some form of interprocessor communication will allow substantial changes
in how and where social science computing is accomplished. The configuration and the nature of implementation of the network is a matter of economics;
it depends upon such factors as anticipated pattern
and volume of traffic, number and location of subscribers, and required response characteristics. Until a
general purpose network becomes available, more
primitive network communication can be supported
using the existing telephone network. It seems unwise
to build a computing network dedicated to social science
compu ting traffic either now or in the near future. Such
an act would be comparable to allocating some of the
industry's limited resources to design special computer
architecture that would be dedicated to social science
computing.
Of all components of computer hardware, the current
status and use of data storage technology represents a
maj or constraint on the fashioning of better social
science computing programs. As social science programs
grow in scope, they grow in memory required alBo.
I t is now common for large social science applications
systems to use elaborate manual segmentation systems
to accommodate themselves to a small amount of
address space. Either the memory resources for ameliorating these restrictions do not exist, or the techniques
for accessing them are not known or available.
In the absence of a fundamental breakthrough in
providing substantially lower cost immediate access
memory, computers with virtual memory organization 5
appear to offer a solution to this problem. Virtual
memory machines provide both increased program
address space and data address space; the latter would
provide the ability to process more complex data
structures without making a substantial investment in
file manipulation software. Virtual memory environments for building and using social science computing
tools should obviate some of the ungraceful degradation
characteristics which many social science computing
programs exhibit upon reaching a capacity constraint.
Perhaps most important, the availability of virtual
memory would remove most memory management
concerns from programmers and allow them to concentrate upon producing more useful computing tools.
The opportunity cost of not using automatic memory
management techniques is measured in terms of
programmer time used in its place and investigator
time waiting longer for results. This cost is already
substantial in some cases, and it will increase as the
cost of hardware declines relative to the cost of labor.
If the technical developments described above
materialize, then their impact upon the social science
computing industry should have very beneficial effects
upon its performance. However, several problems
exist within the industry that detract from its performance and that are not likely to be altered by
changes in technology.
The first problem concerns access to data. While
there has been much progress in recent years by private
firms making data available in machine readable form,
most behavioral and economic data generated by
government agencies and private researchers is unknown to other potential users or underutilized by
them. The principal reasons appear to be that: (1)
within government agencies, quasi-monopoly positions
have discouraged efficiency in both production and
distribution; and (2) in academic and research institutions, the prevailing reward structure offers few
professional rewards for data production alone. As a
result, it is common to observe much duplication of
data collection activity, underutilization of existing
data sources, and lack of availability of existing timely
and detailed data for research and policy analysis.
Another problem is closely related. Social science
disciplines currently assign lower status to most
"technical" work and higher status to "substantive"
work. To the extent that this status difference is perceived, new entrants into social science professions
are more likely to elect to do substantive work. Those
entrants with strong preferences for the computational
aspects of the social sciences are more likely to gravitate
toward academic computer science rather than toward
involvement in a service role in which room for professional growth appears limited.
Within the present industry structure, academically
oriented producers of both programs and data find it
difficult to obtain academic rewards for their output.
The production of a useful, accurate and well-documented social science computer program or machine
readable data file may generate substantial externalities
for social science as a whole, yet there is no adequate
mechanism that allows its producer to capture these
externalities. The long run effect of this situation must
be to discourage production by those able to produce
successfully in other fields.
The problem of developing a reward structure for the
social science computing industry is not a new one.
Its solution could result in substantial benefits to
social scientists in terms of substantially more efficient
use of the computing and data resources available to
them.
Future Developments in Social Science Computing
CONCLUSION
During the next ten years there will be a substantial
increase in demand for social science computing prodducts from government, universities, research institutions and private businesses. A continued decli:le in the
cost of computing will benefit all these consumers. In
addition, the development of reliable general purpose
interactive systems and inexpensive terminals will
enhance the quality and power of social science computing activities; general purpose networks will enlarge traditional markets and lead to increased competition and better consumer choice; and the development
of quite large addressable memories should remove an
important existing constraint on the development of
large applications systems and complex file processing
tools. These developments should be supported by the
social science computing industry. Problems concerning
access to data and achieving a reward structure for
social science computing exist and are important,
but remain to be solved in a satisfactory manner.
ACKNOWLEDGMENTS
I would like to acknowledge helpful discussions with
and criticisms from lVIr. Ben A. Okner and Mr. Gregory
A. }\rlarks.
REFERENCES
1 J W BEAN ~ W KIDD G SADOWSKY
B D SHARP
The BEAST: A user oriented procedural language for social
science research
Processed; Washington The Brookings Institution June 13
1968
2 R BUHLER
P-STAT: An evolving user-oriented language for statistical
analysis of social science data
(Describes P-STAT tape version 42.) Processed; Princeton
Computer Center Princeton University 1966
3 A S COOPERBAND W H MOORE JR
R J MEEKER G H SHURE
TRACE-III: An implicit programming system for inductive
data analysis
Proceedings of the 1971 Annual Conference of the
Association for Computing Machinery New York
1971 pp 127-138
4 P A CRISMAN ed
The compatible time-sharing system: A programmer's guide
2nd ed Cambridge The MIT Press 1965
5 P J DENNING
Virtual memory
Computing Surveys Vol 2 September 1970 pp 153-189
883
6 W J DIXON ed
BM D biomedical computer programs
Berkeley and Los Angeles University of California Press
1967
7 M GREENBERGER M M JONES
J H MORRIS JR D N NESS
On-line computation and simulation: The OPS-8 system
Cambridge The MIT Press 1965
8 The data-text system: A computer language for social science
research designed for numerical analysis of data and content
analysis of text
Harvard University Department of Social Relations
(Preliminary Manual) Processed; Cambridge Harvard
University 1967
9 J M HENDERSON R E QUANDT
Microeconomic theory: A mathematical approach
New York McGraw-Hill Book Company 1958
10 C C HOLT
A system of information centers for research and decision
making
American Economic Review Vol 60 May 1970 pp 149-165
11 J W LONGLEY
An appraisal of least squares programs for the electronic
computer from the point of view of the user
Journal of the American Statistical Association Vol 62
September 1967 pp 819-841
12 W MALING
Preliminary version of the TROLL/1 reference manual
Processed; Cambridge Massachusetts Institute of
Technology 1971
13 M C McCRACKEN
A computer system for econometric research
Processed; Ottawa Economic Council of Canada 1966
14 S D McINTOSH D M GRIFFEL
The ADMINS primer-November 1968
Processed; Cambridge Massachusetts Institute of
Technology (Center for International Studies) 1968
15 E D MEYERS JR
Project IMPRESS: Time-sharing in the social sciences
AFIPS Conference Proceedings 1969 Spring Joint Computer
Conference Montvale New Jersey AFIPS Press Vol 34 1969
pp 673-680
16 N NIE D BENT C H HULL
SPSS: Statistical package for the social sciences
Hightstown New Jersey McGraw-Hill Book Company 1970
17 F J REX JR
H £rm'.1n Hollerith, the first statistical eng-incer
Computers and Automation Vol 10 August 1961 pp 10-13
18 L G ROBERTS B D WESSLER
Computer network development to achieve resource sharing
AFIPS Conference Proceedings 1970 Spring Joint Computer
Conference Montvale New Jersey AFIPS Press Vol 36 1970
pp 543-549
19 S ROSEN
Electronic computers: A historical survey
Computing Surveys Vol 1 March 1969 pp 7-36
20 D L ROSS
Burroughs Advanced Statistical Inquiry System (BASIS)
Processed; Detroit Burroughs Corporation 1969
21 R H WAMPLER
An evaluation of linear least squares computer programs
Journal of Research of the National Bureau of Standards
Vol 73B April-June 1969 pp 59-90
A computer model of simple forms of learning in infants
by THOMAS L. JONES
National Institutes of Health
Bethesda, Maryland
INTRODUCTION AND SUMMARY
computer program. Greene and Ruggles (1963) described a computer model of behavior in human infants.
In psychology, Piaget (1952) and Hull (1952), among
others, have studied the process of behavior acquisition.
The methodology used in the present report can be
considered an extension of Hull's method of formulating
assumptions in a precise, formal way, deducing the
consequences of the assumptions, and comparing the
results with observed behavior. The computer permits
us to evaluate a learning model by turning it on and
running it; the model's capabilities are there for all to
see, and its weaknesses are glaringly obvious. The
model may be made more like the real organism by
improving it in an engineering sense, since a dissimilarity is almost always something which the living organism can do and the model cannot.
This report describes a computer program called
INSIM (for "INfant SIMulator"), written in LISP
(McCarthy, 1960) for the PDP-I0 computer. The program operates by learning cause and effect relationships, such as "turn head" causes "mouth touch." A
cause-effect chain is formed; if A causes B, and B
causes C, and if C is pleasurable, the program will
work backward along the chain until it reaches something it can control directly (a muscle pull). The
simulated infant's behavior is under the control of a
so-called performance program. The performance program is, in turn, written, as learning proceeds, by a
section of the learning program called the "experiencedriven compiler."
A typical problem solved by INSIM involves a behavior pattern which is all too familiar to parents of
small children: That of sucking the thumb. (We will
soon see that this involves quite a virtuoso feat of information processing.) The problem can be described
in logical notation as follows:
Many workers have studied the problem of getting
machines to exhibit aspects of intelligent behavior. It
has become clear that a major limitation of the artificial intelligence field is the cost and difficulty of programming, which remains essentialJy a handicraft
technique. What we need in artificial intelligence research are methods for the machine to be self-programming in a much deeper sense than the compilation
process in use today. Briefly, we would like for the
machine to "learn" to solve a problem, rather than
being programmed in the usual laborious way. This
report presents a computer program, using what I will
call an "experience-driven compiler," which is able to
program itself to solve a restricted class of problems involving cause-and-effect relationships. Although the
program is not yet able to learn to solve problems of
practical significance, it is hoped that the technique
will be developed to the point where this can be done.
I am in agreement with Turing's suggestion (1950)
that the best way to achieve artificial intelligence is to
find out what an infant has in his brain that alJows him
to become intelligent, put this capability into a computer, then allow the machine to "grow up" in much
the same way as the baby does. (Of course, this is a
statement of the problem rather than an explanation
of how to solve it.) An additional purpose of the work
is in psychology: we would like to have computer
methods for testing theories of how learning might occur
in living creatures.
There have been many reports of techniques for
getting machines to exhibit various forms of learning
(Friedberg, 1958; Samuel, 1959; Waterman, 1970).
Usually they are concerned either with coefficient
learning, where some parameter given by the human
programmer is optimized, or with rote learning, involving the formation of some table or file of data. This report describes a different form of learning, program
learning, where the output of the learning process is a
(1) object touching mouth~pleasure
(2) (left cheek touch AND turn head
mouth touch
885
left)~
886
Spring Joint Computer Conference, 1972
ment and emitting properly timed and sequenced behavior. The performance program consists of a set of
PSIM statements arranged in a goal tree, each node of
which is a variable cluster. A variable cluster consists of a
basis variable such as "mouth touch," together with
variables which indicate the status of the goal defined
by the basis variable (e.g., achieving mouth touch).
These include:
(1) The PR of the goal. This is defined as the proba-
Figure 1
(3) (right cheek touch AND turn head right)~
mouth touch
(4) (left cheek touch OR right cheek touch) =
face touch
(5) face touch~mouth touch (sometimes)
(6) lift hand~face touch
(See Figure 1.)
After the program has learned these connections, it
will emit the behavior sequence, "lift hand, turn head
(left or right) ," resulting in pleasure.
Figure 2 is a block diagram of INSIM :
The performance program has the direct responsibility
for synthesizing behavior. It is written in an interpretive language called PSIM (parallel simulator). The
performance program receives stimuli from and sends
responses to a body and environment simulator. The display section provides monitoring on the cathode-ray
tube. The motivation section activates the main goal
(oral gratification or curiosity).
Relatively little of the performance program is innate.
Most of it is generated by an experience-driven compiler
which is the core of the learning part of the program.
Causality is detected by statistical correlation; if a
signal occurs on line A followed by one on line B, and
if this sequence is repeated sufficiently many times, the
program assumes that A causes B. The program is
equipped for the simplest type of pattern recognition
and concept formation: the formation of logical AND's
and OR's of previously known variables. The program
has an intellectual motivation system which causes it
to exhibit simple forms of curiosity, play, and exploratory behavior.
bility that the goal can be achieved "soon" (in a
sense to be defined precisely below), provided
that an attempt is made by the infant to achieve
it.
(2) The C (cost) of the goal. This is the program's
estimate of the time delay required to achieve
the goal.
(3) The WANT of the goal. This is TRUE or
FALSE depending on whether or not the program is trying to achieve the goal. A goal is defined to be active if its WANT variable is TRUE:
i.e., if the program is trying to achieve it.
In addition, the variable cluster associated with a goal
contains other variables as described below.
The performance program, then, consists of a set of
variable clusters for various goals, with connections between variable clusters for goals which are causally related. Thus, there will be a connection between the
variable clusters for "turn head left" and "mouth
touch." Figure 3 shows the goal tree for the thumbsucking problem, with the variable clusters shown
explicitly.
Psychologists will wish to compare this setup vvith
Guthrie's "connectionism" concept (1952). Note again
the resemblance to a nerve net. INSIM may be interpreted as a neurological model of how learning might
take place in the brain, although, of course, it is a very
Response
signals
Body and
envi ronmen t
fP.:~:::;;:::iI====~===~ simulator
Cue signals
THE PERFORMANCE PROGRAM
As described above, the performance program has the
direct responsibility for receiving cues from the environ-
I.... .
-tJl--ll-
Figure 2
M
Computer lVlodel of Simple Forms of Learning in Infants
imperfect model and one for which no direct neurological evidence exists.
The performance program operates by activating
various branches of the goal tree at the appropriate
times. Recall that the active nodes of the tree are the
nodes which define goals which the machine is trying
to achieve at the current time. In the thumb-sucking
problem, assume that the motivation section has activated the main goal "oral gratification." The performance program will activate the extreme left branch
of the goal tree (see Figure 1), ending in "lift hand."
The "lift hand" response will be emitted to the body
and environment simulator. After a delay of roughly
two simulated-time seconds, a cue, e.g., "left cheek
touch," comes back, indicating that the simulated
hand has been lifted to touch the (simulated) left
cheek. Next, the branch ending in "turn head left" is
activated. A "mouth touch" signal comes back from
the body and environment simulator, indicating that
this goal has been reached, and the motivation section
turns on the oral gratificatic n flag, "rewarding" the
program for its successful effort.
The basic problem is to decide which branch of the
goal tree to activate. (INSIM performance programs
allow only one branch to be active at a time; hence
there is no way to work on two goals simultaneously.)
In a given situation, the decision is made in two phases,
a feasibility study phase and a choice phase. In the
feasibility study phase, each branch of the tree is assessed, and an estimate is made of which branch is the
quickest and surest way to the main goal. In the choice
phase, this branch is activated. During the feasibility
study phase, the PR (probability) and C (cost) are
computed for each goal.
Pleasure
_To right
cheek, etc.
000/.
touch
c-------'
Figure 3
Turn
head
left
887
Figure 4
Computation of PR and C
This section is devoted to a detailed discussion of how
PR and C are computed. On a first reading, readers
may skip to the section on the choice phase.
PR is defined recursively as follows:
(1) For a "response" (directly controllable) variable, such as "lift hand" or "turn head left,"
PR=l.
(2) Suppose that A is one of several OR'ed subgoals
of B (see Figure 4).
If A is the "best" subgoal according to a criterion to be
presented
momentarily,
then
PR(B) =PR(A)
Pr(B I A), where Pr(B ! A) is the conditional probability of B given A (i.e., the probability of getting
from A to B) as estimated by the coefficient learning
program PRDLRN, discussed below.
The "best" subgoal is selected so as to maximize the
Slagle coefficient (1964)
PR(B)
C(B)
This subgoal may not really prove to be the best one,
if, say, the probability or cost estimates turn out to be
incorrect. The performance program is a heuristic program and is forced to make decisions based on imperfect
evidence.
A more sophisticated program would take into account the possibility of trying to achieve A, failing,
then trying to achieve A' and succeeding. Thus a goal
with several good subgoals would have a larger PR for
this reason. However, INSIM considers only the one
best subgoal.
(3) Suppose that Al and A2 are components of the
ordered-AND goal Al THA2 (AI then A2). Then
PR (A1THA2) =PR (AI) PR (A2).
(4) Notwithstanding any of the above, if a goal has
already· been achieved, its PR = 1. A goal is de,;,
fined as "already achieved" if the corresponding
signal has occurred within the last five seconds.
888
Spring Joint Computer Conference, 1972
Similarly, the C (cost) of a subgoal is defined recursively as follows:
(1) For a response variable, C = o.
(2) If A is the best of several OR'ed subgoals of B,
then C (B) =C (A) +PR (A) Delay (A~B).
(3) The C of an ordered-AND goal AlTHA2 (AI
then A2) is C (AlTHA2) =C (AI) +PR
(AI) C (A2)
(4) Notwithstanding any of the above, the C of a
goal is 0 if the goal is already achieved (in the
past five seconds).
PSIM will update only those tree branches which depend on some variable which has changed since the
last TCLOCK time.
Discussion
INSIM performance programs incorporate simple
heuristics which work well in cases where the assumptions on which they are based hold true.
Among the assumptions are:
(1) Success probabilities and time delays are assumed to be statistically independent. If this is
not true, the chaining formulas used in computing success probabilities and time delays will not
be accurate.
(2) It is assumed that goals do not conflict; i.e.,
that the achievement of one goal does not decrease the probability of achieving another goal.
To summarize, in the feasibility study phase, estiw
mates are made of the success probability and time
delay of each path to the main goal.
The choice phase
The next step is to activate the goal tree branch
which is estimated, according to simple heuristics, to be
the quickest and surest path to the main goal. A goal is
active if, and only if, its WANT variable has the value
TRUE.
(On a first reading, readers may skip to the section
on the inner loop.) The WANT variable of a goal A is
defined recursively as follows:
(1) If A is a main goal, WANT (A) is TRUE or
FALSE as set by the motivation system.
(2) If A is one of several OR'ed subgoals of B,
WANT (A) = (WANT (B» AND (A is not
already achieved) AND (A is the best subgoal
of B» OR
(A is a curiosity goal (see below».
(3) If Al THA2 is the ordered-AND subgoal "AI
then A2,"
WANT (AI) = WANT (AlTHA2) AND (AI
is not already achieved)
WANT (A2) = WANT (AI THA2) AND (AI
is achieved) AND (A2 is not achieved).
(4) If G is a response (directly controllable) variable, WANT ( G) causes the response to be
emitted.
Removing these performance limitations would require additional machinery beyond the scope of the
INSIM project, such as a look-ahead method of the
type used in chess programs.
THE EXPERIENCE-DRIVEN COMPILER
As mentioned previously, most of the performance
program is coded by an internal compiler which, instead of using as its input a source code prepared by a
human, is controlled by the experience acquired by the
program as it interacts with its (simulated) environment. In keeping with the dictum that in order to
learn something, one must know something already, the
compiler incorporates the probability and delay formulas described above, plus knowledge of basic aspects of
the physical world, including time and causality (see
Figure 5).
I
I
PI
,",ibto
move
generator
I
~
~
Causali ty
pattern
recognizer
~
Pattern
recognizer
Pattern
recognizer
B
The inner loop
B
fA
A A
Al
Since the computation of the PR, C, and WANT
variables is under control of PSIM, they will be recomputed in a wavefront-like manner, with the stimulus variable as the starting point of the wave. Thus the
PR and C and the program's decisions are constantly
being updated on the basis of changing conditions.
Code
genera tor
(goal-subgoaU
B
A2
Code
genera tor
(OR of
subgoals)
Figure 5
Al
Code
generator
(THEN of
subgoals)
A2
Computer 1\10del of Simple Forms of Learning in Infants
The plausible move generator is used instead of
testing for causality between an possible variables A, B.
The latter approach would involve on the order of n 2
tests, where n is the number of variables.
I t is the compiler which sets the upper limit on the
program's ability to learn. For example, INSIM could
never learn to play chess even with very long training,
because the necessary pattern recognizers and code
generators are not present.
The experience-driven compiler operates as follows:
The program starts out with an innate main goal which
is "oral gratification" in the thumb-sucking problem.
First, the plausible move generator is caned to generate
a list of variables which are likely to be "relevant" to
the oral gratification goal, and causality test links are
formed. (The plausible move generator is discussed
below.)
N ext, the causality pattern recognizer learns which
test links represent actual causal relationships. The
pattern it is looking for is shown in Figure 6.
If a pulse on variable A is followed by a pulse on
variable B sufficiently often, A is assumed to cause B.
More precisely, if Pr(B I A) >0.20 after at least 15
pulses on A and 15 pulses on B have occurred, A is assumed to cause B. The pulses on A and B must be less
than five simulated-time seconds apart. (If there are
any pulses at all on B, then a pulse on A will always be
"followed" by a pulse on B if we wait sufficiently long.)
Pr(B I A) is estimated by the probability-delay learner,
discussed below.
The simple heuristics will miss some actual causal
relationships when the delay is more than five seconds.
It would not be hard to make the program "adaptive"
to this arbitrary parameter, say by matching the time
delay to the recent density of pulses on the two lines.
-
t--
~
A
-
.-B
Figure 6
r--
889
Thus, if there were only one pulse on B about every 15
minutes, the allowable delay might be five minutes
rather than five seconds. Also, the heuristics will sometimes "identify" a causal relationship where none actually exists. E.g., if the allowable time delay were
long enough, the program would think that day causes
night. (Piaget has found that small children also think
that day causes night.)
In some cases, it is sufficient to wait passively for a
pulse on A. In other cases, the curiosity section of the
performance program sets WANT (A) to TRUE,
activating some goal tree branch ending in A and initiating behavior which hopefully will lead to a pulse on
A, in order to see if B follows (e.g., it activates "turn
head left" to see if "mouth touch" follows) : this is the
"play" or "exploratory behavior" mentioned above.
The curiosity section attempts to test links which are
new and have not been tested many times; links where
the initial variable, A, is reasonably easy to obtain;
and where the final variable, B, is "biologically useful"
in that ability to obtain B would contribute to the program's ability to obtain pleasure (primary reward).
Specifically, the curiosity section tests the link A~B
which maximizes
(PR(A)/C(A)) *Satfunc(A, B) *Need (B)
where Satfunc (A, B) (saturation function) decreases
linearly from 1 to 0 as the number of times when A~B
has been tested increases from 0 to 15. Need (B) is an
index of how much the ability of the program to obtain
primary reward would be improved by improvements
in its ability to obtajn B. See Jones (1970) for a description of the heuristics used to compute Need (B).
Only links which have been designated as "plausible"
by the plausible move generator are tested.
When the causality pattern recognizer detects that
two variables, A and B, are causally related, the corresponding code generator is called to compile the link
A~B in the goal tree, provided that the connection has
not already been made. This code generator is a LISP
function called MAKEORGOAL (A, B), so named because it also handles the case where A is one of several
logically OR'ed goals. In LISP, the code generator
turns out to be a straightforward and rather prosaic, if
slightly long, program. Separate sections are provided
for compiling the entries for WANT, PR, C, and each
variable associated with the curiosity system. Each
section looks up the names of the variables involved in
the formula in question and substitutes them in the
formula, using LISP's symbol-substituting capability.
In the thumb-sucking problem, the program first
learns the links shown in Figure 7.
890
Spring Joint Computer Conference, 1972
PSIM
Figure 7
Although this version of the performance program will
sometimes succeed in obtaining "mouth touch," it does
not yet know which way to turn the (simulated) head.
Next, the plausible move generator is called to provide
a list of variables to be THEN'ed with the partially
successful subgoals. Causality test links are compiled
for the ordered-AND variables. Among them are the
ones shown in Figure 8.
VI correlates very poorly with mouth touch; V2 correlates very well. Since Pr (mouth touch V2) is very
high, the performance program will activate this branch,
rather than the others, and the simulated infant will
emit "turn head left" in response to "left cheek touch."
Similarly, it learns to emit "turn headright" in response
to "right cheek touch." Finally, "face touch" is identified as a "biologically useful" variable, and the program
,learns to activate "lift hand"; when the (simulated)
hand touches the face, the previously learned program
takes over and completes the thumb-sucking operation.
One way of looking at the learning process is that
the program builds a subroutine hierarchy. Each node
on the goal tree defines a subroutine, the process of
achieving a stimulus on the variable defined by the
node; e.g., the "obtain mouth touch" subroutine. Each
link on the tree defines a subroutine call. Thus, the
"obtain face touch" subroutine calls the "lift hand"
subroutine.
See Jones ( 1970) for a fuller discussion of how
the experience-driven compiler is organized and
programmed.
It is interesting to note the similarity between the
learning sequence and Piaget's observations on the
learning of human infants. Although the real infant's
learning is much more complicated, it follows the same
gross sequence of stages; the real infant first learns to
search from left to right with its head; then it learns
which way to turn; then it learns to lift its hand and
suck its thumb. (Real infants also show considerable
variability in their learning; for example, some have
been observed to suck the thumb in the womb.)
Ir: order to simplify the experience-driven compiler,
an mterpreter called PSIM (parallel simulator) was
written. The experience-driven compiler "sees" a
pseudo-machine which is quite different from the actual
PDP-I0 for which the program is written. The pseudomachine is much like an analog computer in which
each component has the versatility of a digital computer, but where one does not need to worry about the
sequence of computations; instead, each component
"continuously" monitors its input lines and responds to
whatever signals it finds there. Thus PSIM is a
"stimulus-response" oriented interpreter which is convenient for writing programs which simulate actions in
the real world.
More precisely, a PSIM program consists of a network of variables whose values change with simulated
time and functional relationships which describe the
way the variables depend upon each other. There is a
simulated-time clock, TCLOCK, calibrated in seconds,
which is set to zero at the start of a simulation and advances as the simulation proceeds. There is an event file
which contains computations which are scheduled to
occur at a future TCLOCK time. Each PSIM entry is
of the form VAR = EXPR, where the EXPR is a LISP
expression which is evaluated to get the value of the
variable VAR.
If a variable V2 depends on another variable VI, and
VI changes, V2 is automatically updated. This process
occurs in an interesting way: In addition to the variable
TCLOCK, which records simulated time, there is
another "clock," called BTIME (base time) which
cycles from one up to some maximum value during
each TCLOCK time. Each variable has a base time at
which it is updated. The base time of a variable is set
as follows:
(1) If a variable depends on the other variables only
through a TCLOCK delay, its base time is l.
(2) Otherwise, its base time equals one plus the
maximum of the base times of the variables on
which it directly depends; i.e., the variables in
its EXPR.
Figure 8
Computer Model of Simple Forms of Learning in Infants
Variables with base time 1 are updated first, then
variables with base time 2, etc. This arrangement ensures that a variable is not updated until after the correct values of all variables in its EXPR are available.
During most TCLOCK events, only a few variables
change their values. PSIM ensures reasonable efficiency
by recomputing only those variables which depend on
a variable which has changed at the current TCLOCK
time. The updating proceeds in a "wave-front like"
manner, starting with a variable X which has been
changed through a TCLOCK delay, then updating the
variables Vi which depend on X, then the variables
which depend on some Vi, etc. (See Figure 9).
Note the resemblance to a hard-wired device or a
nerve net.
THE PROBABILITY-DELAY LEARNER
Conditional probabilities and time delays are estimated by a rather orthodox coefficient learning procedure (Samuel, 1959). Suppose there is a link between
A and B. Whenever A occurs, followed within five
seconds by B, Pr (B I A) is incremented by an amount
o (I-old value of Pr (B IA)), and Delay (A~B) is incremented by 0 (actual delay-old estimate of delay).
If A occurs, but not B, Pr (B I A) is decremented by
an amount 0 (old value of Pr (B I A)) and Delay
(A~B) is incremented by 0 (five seconds-old estimate
of delay). It can be shown that this procedure gives
unbiased estimates of Pr (B I A) and DeJay (A~B),
with an exponential weighting such that old occurrences
of A affect the estimates less than new ones. 0, the
decay coefficient, is currently 0.1. The initial estimate
of Pr (B I A) is obtained by observing the first 10 oc-
=4
=3
V6
=2
base time
=1
Variable changed through a TCLOCK delay
Figure 9
891
v,-v,
V,-V2 V,-V3 V,-V4
V2-V, V2-V 2 V2-V 3 V2-V 4
V3- V, V3-V 2 V3- V3 V3-V 4
V4-V, V4-V 2 V4-V 3 V4-V 4
Figure 10
currences of A. Pr (B I A) is set to
(Number of A's followed by B's)j(Number of A's)
The initial estimate of Delay (A~B) is the observed
average over the first 10 occurrences of A.
THE PLAUSIBLE MOVE GENERATOR
Recall that, mention was made of a not yet implemented plausible move generator which was to be called
to make hypotheses about which variables might be
causally related to some goal B. These variables are
defined as "relevant" to B; the causality pattern
recognizer will determine if an actual causal relationship exists. (At present, the program is running with
a patch which merely looks up plausible variables
in a manua1ly prepared table.) If we tested all possible
variable pairs, the machine time needed would increase
on the order of n 2 where n is the number of variables,
constituting an intolerably large CPU and core storage
load for large n. The plausible move generator wi1l use
three relevance heuristics:
(1) (implemented) Innately known relevance-A
variable A is innately known to be relevant to a
variable B if A appears under B in an innately
known file (i.e., a manually prepared file).
(2) The diagonal search-This will be used to associate variables which are very "important," such
as a "large moving visual stimulus" and "arm
motion," and will be used to make the initial
connections between sensory modalities (e.g.,
vision and hearing) and motor units such as the
arms or the head. The "important" variables
will be placed on an innate list in decreasing
order of importance. Let Vk be the kth most important variable. Make a square matrix as shown
892
Spring Joint Computer Conference, 1972
.,.,1
/
Left
Center
Figure 13
"
Figure 11
in Figure 10. Now let a dot represent a matrix
entry and search the matrix.in the order specified
by the arrows in Figure 11. Roughly, the concept
is that the most important variables are associated with each other first.
(3) The relevance chaineI' and the innate net-The
innately known relevance subroutine and diagonal search subroutine will be used to get the
learning process started. To continue it, the
relevance chainer section of the plausible move
generator will be used. The relevance chaineI'
will incorporate two heuristics: (1) If x is relevant to y, then y is relevant to x (symmetry).
(2) If x is relevant to y, and y is relevant to z,
then x is relevant to z (transitivity). A depth
cutoff will be used, so that all variables are not
relevant to each other.
The relevance chaineI' will be used with an innate net
which will incorporate innate knowledge about which
sensory modality a given signal belongs to and innate
information about space (which signals "belong to-
Face touch
gether"). For a simple example, assume a one-dimensional space of touch receptors. The receptors will be
arranged in an OR tree with a hierarchy of larger and
larger sectors (see Figure 12). (Do not confuse this
with a goal tree; the upper level variables are defined
as OR's of the lower level variables.)
EXPERIMENTAL RESULTS
INSIM was tested with a simple body-and-environment simulator, with a problem environment which is
a simplified version of that seen by a newborn human
infant. Let us follow the growth of the simulated infant
as it develops, starting from a state of passivity, then
learning gradually to distinguish right from left and
turn its head in the proper direction. Its ultimate
achievement is to suck its thumb.
The simulated infant has a head with three positions,
left, center, and right (see Figure 13). It has a blanket
(Figure 14) and a bottle (Figure 15). The blanket and
bottle are under the control of special manually prepared subroutines in the test package.
The simulated infant begins its life with an essentially blank performance program. At first it is completely helpless and does not move at all, since there
are no motor operators in the goal tree. When it gets
hungry, or, more precisely, wants pleasure, it must
wait passively until its bottle appears. Although it is
immobile, the infant is learning the connection "mouth
touch" yields "pleasure."
Input level variables
Figure 12
Right
Figure 14
Computer Model of Simple Forms of Learning in Infants
At age 605 seconds, the experience-driven compiler is
activated. The new performance program contains additional Jines of PSIM code which express the goal
tree link "mouth touch" yields "pleasure." The new
PSIM code is then fed to the assembler-scheduler,
which makes up, for each variable V, a list of variables
which depend on V and a list of variables which V depends upon. Next, the scheduler assigns a "btime"
(base time) to each variable, starting with btime = 1 for
input variables such as mouth touch. The new performance program contains the connection "mouth
touch" yields "pleasure." Mouth touch has become
"important" to the infant; hence the new performance
program is "curious" about things which are plausibly
related to mouth touch. Among these are the headturning responses. There are two head-turning operators, "turn head left" and "turn head right." After 10
seconds, the head automatically returns to the center
position. This version of the performance program
turns the head only out of curiosity; when it actually
activates the mouth touch goal, it is unable to turn the
head. Meanwhile, the connection "face touch" yields
"mouth touch" has been made, and the "lift hand"
response is enabled. Whenever the hand control subroutine receives a "lift hand" response, it computes a
pseudo-random number and uses it to determine the
outcome of the lift-hand operation; the hand winds up
at either the left, center, or right positions relative to
the infant's face.
At age 1405 seconds, the head-turning operators become subgoals of mouth touch. In this stage, the program exhibits for the first time a simple form of what
psychologists call "operant conditioning" (Skinner,
1953). In the past, the program has been rewarded by a
mouth touch for turning its head. Now, when it wants
mouth touch, it turns its head. The program is still
not very successful. It exhibits a stereotyped behavior
pattern, first turning right, then left, without regard to
where the object is, or, indeed, whether there is an object present or not. During this phase, the program is
keeping records of the conditions under which "turn
head left" and "turn head right" succeed in achieving
Figure 15
893
mouth touch, laying the groundwork for the next phase
of development.
At age 2405 seconds, the sixth and final version of the
performance program is compiled. When an object is
present, the program can reliably turn the head in the
proper direction. Thus the program exhibits a simple
form of what psychologists call "discrimination learning"; it responds appropriately to the stimuli "left
cheek touch" and "right cheek touch." The program's
most advanced behavior involves providing its own
stimulus object: its hand. This exhibits what psychologists call "chaining." Let us review the operating
principles of the program by tracing in some detail what
happens when, say, a "left cheek touch" pulse is received from the body-and-environment simulator.
Variables which depend on "left cheek touch" are recomputed in a "wave-like" fashion, starting with variables which depend djrectly on "left cheek touch,"
then variables which depend on the latter class of
variables, etc. Before the "left cheek touch" signal is
received, the program assigns a low PR to achieving
"left cheek touch." After the signal is received, the PR
is set to one. Now the program assigns a high success
probability to the composite goal "left cheek touch
then turn head left"; previously, the composite goal
also had a low success probability. This composite goal
now has a higher success probability and figure of merit
than the other subgoals of mouth touch; hence it is
activated. Since the first half of the composite goal
(left cheek touch) has already been achieved, the goal
(and response) "turn head left" is activated.
ANALYSIS
The fundamental scientific issues to which the
INSIM work addresses itself are:
(1) Can one make use of a relatively small amount
of very general innate knowledge in order to
obtain a much larger amount of specialized
knowledge, and, if so, how?
(2) What should the innate knowledge be?
(3) How should the innate knowledge be incorporated into an information-processing system?
These issues are as old as epistemology itself, but the
first really careful analyses were by Hume (1777) and
Kant (1781). Hume took the position that the human
mind was a "tabula rasa" (blank tablet) at birth and
that all knowledge was acquired through the forming
of associations (compare Hebb's [1949] synaptic connections). Kant, on the other hand, believed that the
infant had a store of innate (categorical, or "a priori")
894
Spring Joint Computer Conference, 1972
knowledge at birth and that this was necessary to make
the learning process work properly. The INSIM research supports Kant's viewpoint, based on practical
engineering experience with information processing systems of this type. INSIM is associationist ("turn head
left" is associated with "mouth touch"); however, in
order to make the association proceed properly, innate
knowledge had to be incorporated into the learning
program, knowledge that there are such things as
causality and time, and that causaJly related events are
likely to occur in close temporal sequence.
A question immediately arises as to Just what is
meant by statements such as "INSIM knows that
there is such a thing as causality." The word "know"
can be used in several senses. Obviously INSIM does
not know about causality in the same sense that an
adult knows about causality; the program cannot explain causality, cite examples, or answer questions
about causes and effects; it has no verbal behavior at
all. Instead, to say that INSIM knows about a certain
type of causality is to say that the INSIM program is
optimized to a universe in which certain types of causal
relationships exist. Thus, in a universe where there
were no such things as causality or time, or where
cause and effect were always separated by hours or
days, INSIM would not work properly. In other words,
the innate knowledge of INSIM is incorporated in the
form of algorithms rather than as facts.
The learned knowledge is also incorporated into the
system in the form of algorithms rather than facts.
Thus the final version of the performance program
knows right from left in the sense that it can turn its
head in the proper direction if stimulated; yet it has no
verbal knowledge of space at all. Expressing knowledge
as algorithms, as in program learning, is meritorious in
that it is algorithms which we know best how to combine into complex integrated systems. Thus INSIM
learns a nursing subroutine, then adds additional code
to form a thumb-sucking subroutine. By contrast, for
a machine to learn facts is at present often" like adding
more books to a library; the machine cannot do much
with them. Many of the theorem-proving efforts suffer
from this problem. Expressing knowledge as facts has
its complementary merits, as discussed by Hewitt
(1969) and the present author (1966).
Given the concept of using a base of very general
innate knowledge to obtain a much larger repertoire of
learned knowledge, what can we say about what the
innate knowledge (innate algorithm) should be; in
particular, how much innate knowledge is needed and
how problem-specific should it be. Why was the innate
knowledge basis of INSIM chosen the way it was? For
several reasons:
(1) The INSIM program has a high "bootstrapping
leverage" ratio:
(learned problem solving ability)
(innate knowledge)
where the "amount" is to be indexed by some
criterion or other. Although this is not a fact
which can be easily demonstrated now, since the
learning is severely limited by the body-andenvironment simulator, INSIM is capable in
principle of synthesizing very large trees of
OR'ed and THEN'ed goals (limited by core
storage), implementing long chains of behavior.
(2) INSIM is based upon a strong general theory of
problem-solving, means-end analysis (N ewell,
Shaw, and Simon, 1959), and one can be confident of the program's ability to be extended to
other goal types and to solve harder problems.
(3) INSIM performance programs are free to some
extent from the "exponential explosion" problem which plagues many problem-solving systems. The simulated time to learn a tree grows
only linearly with the length of the tree; the
CPU time per simulated time second grows a
little worse than linearly with the number of
branches on the tree, and the number of branches
is limited by the causality pattern recognizer.
(4) Lastly, the INSIM setup was chosen because it
works; i.e., it constitutes an integrated learning-behaving system. This requirement is
harder to meet than appears on the surface; I
have 1100 pages of notes on setups which did not
work, developed before arriving at INSIM. The
incompletely successful efforts of Pavlov and
Hull are also testimony to the difficulty of
getting anything which will work at all.
Among the additional capabilities \vhich are being
considered for inclusion in INSIM are the ability to
handle binary (non-pulse) goals, goals involving continuous valued variables, goal conft.ict situations, goals
stated in terms of objects with property lists one-trial
learning, and a look-ahead system of the type used in
chess programs. An important lesson to be learned
from a program of this type is that learning, rather than
being a single process, actually involves a variety of
ways for improving behavior based on experience.
A future objective of this work is to make it easier,
in certain cases, for the machine to learn for itself how
to do something than to write a program in the usual
way. The learning program would need to be equipped
for more advanced types of learning, including one-
Computer J\ilodel of Simple Forms of Learning in Infants
trial learning, and it would be restricted to problems
involving long chains of cause and effect, such as robot
control problems. In psychology, the objective is to use
computer modeling, in conjunction with research on
living creatures, to gain insight into that fascinating
enigma-the human mind.
ACKNOWLEDGMENTS
This report is based in part on a Ph.D. thesis submitted
to M.LT. in September, 1970. I would like to thank
l\1arvin Minsky and Seymour Papert for their support
and encouragement, and for several ideas expressed in
this paper.
REFERENCES
1 R M FRIEDBERG
A learning machine, Part I
IBM J Res and Dev Vol 2 pp 2-13 January 1958
2 P H GREENE T L RUGGLES
Child and Spock
IEEE Trans on Military Electronics Vol M17 No 2 and 3
April-July 1963
3 E R GUTHRIE
The psychology of learning
rev ed New York Harper 1952
4 D 0 HEBB
The organization of behavior
New York John Wiley and Sons Inc 1949
5 C HEWITT
PLANNER: A language for proving theorems in robots
Proc 1969 IJCAI pp 295-301
6 C L HULL
A behavior system
Yale University Press 1952
895
7 D HUME
Enquiry concerning human understanding
Oxford The Clarendon Press 1936
8 T L JONES
A computer model of simple forms of learning
MIT PhD thesis 1970
9 T L JONES
The advice-taker as a means of symbolic computation
MIT EE thesis 1966
10 I KANT
Critique of pure reason
Macmillan and Co Ltd 1934
11 J McCARTHY
Recursive functions of symbolic expressions
Comm ACM Vol 3 April 1960
12 A NEWELL J C SHAW H A SIMON
Report on a general problem-solving program
Proc Internatl Conf on Information Processing Paris
UNESCO House 1959
13 J PIAGET
The origins of intelligence in children
New York International Universities Press 1952
14 A L SAMUEL
Some studies in machine learning using the game of checkers
IBM J Res and Dev Vol 3 pp 211-219 July 1959
15 B F SKINNER
Science and human behavior
New York Macmillan and Co 1953
16 J R SLAGLE
An efficient algorithm for finding certain minimum-cost
procedures for making binary decisions
JACM Vol 11 No 3 pp 253-254
17 A M TURING
Computing machinery and intelligence
in Computers and Thought pp 11-35 N ew York
McGraw-Hill Book Company 1963
18 D A WATERMAN
Generalization learning techniques for automating the learning
of heuristics
Artificial Intelligence Vol 1 Nos 1 and 2 Spring 1970
An information management system for scientific
gaming in the social sciences
by ROBERT C. NOEL and THOMAS JACKSON
University of California
Santa Barbara, California
puter support for gaming has been far less common.
Bloomfield has experimented with computer-based information retrieval as an aid to decision-makers in an
all-man international strategic exercise, a so-called
"free-form game," in which expert judgment performs
functions analogous to the computer model in a manmodel simulation (Beattie and Bloomfield, 1969).1
Gerald Shure developed a system for team-to-team
written communications on a time shared computer.2
But, to our knowledge, no comprehensive computerbased system has yet been developed for the overall
administration of gaming exercises.
The purpose of this paper is to describe such a system.
It is under development at the POLIS Laboratory at
the University of California, Santa Barbara. * Its first
version is operational on a dedicated PDP-II. It is cur"'"
rently undergoing major revision; an expanded version
should be completed within a year. Part 1 will give a
non-technical description of the system, and Part 2
will provide technical information about the architecture of the system.
INTRODUCTION
During the past decade, the use of gaming techniques
has spread among social scientists. Beginning primarily
in the fields of international strategic studies and business management, gaming is now used in such areas as
urban studies, general economics, political science, environmental studies, educational administration, and
sociology. The purposes to which gaming techniques
have been put are varied. Education and training applications have been by far the most numerous, and
these continue to be the areas of broadest consensus
about the value of gaming. Second most common are
policy-analytic applications wherein present and future
problems of policy choice are examined through gaming
by expert analysts and policymakers. Finally, there
have been basic research applications in which gaming
exercises are used as settings for more or less controlled
experimentation dealing with social psychological, sociological, and political variables.
The computer has played a role throughout most of
the history of gaming. Computer support has usually
taken the form of discrete, man-model simulation. That
is, a computer-based model of some object system is
solved reiteratively, taking the decisions of human
participants as inputs and reporting changes in system
states as stimuli for subsequent human decisions.
Another kind of computer supported gaming differs
from simple man-model simulation in that it involves
two or more participating entities (teams) who, while
interacting with each other directly in writing and/or
face-to-face, also interact with each other indirectly
through their interactions with a common computerbased model (for example, a multi-firm business game or
an n-player international political game). Various names
have been applied to such games, including "gamesimulati ons."
Beyond performing these simulation functions, com-
GENERAL DESCRIPTION OF THE POLIS
SYSTElVI FOR THE ADIVIINISTRATION OF
GAMING EXERCISES
The system performs a variety of information management functions for gaming. First, it provides chan-
* The acronym "POLIS" stands for "Political Institutions
Simulation." The POLIS Lab is a state-of-the-art facility for
social gaming and simulation (see Robert C. Noel, "The POLIS
Laboratory," AMERICAN BEHAVIORAL SCIENTIST, vol.
XII, no. 6, (1969), pp. 30-35). The Lab was established under
funding from the Regents of the University of California, the
National Science Foundation (GY-6345), and the Chancellor's
special funds at UC Santa Barbara. This support is gratefully
acknowledged.
897
898
Spring Joint Computer Conference, 1972
INBASKET may be left to his discretion or scheduled
as part of a game's operating procedures. Straightthrough, real-time communications will also be possible as a result of scheduled system revisions;
The message handler has capabilities for three modes
of operation: the manual-intercept mode, the automatic
mode, and a mixed mode. In addition, it embodies flexible addressing capabilities.
Message-handling: Manual-intercept mode
Diagram I-Message-handling: Manual intercept mode
nels for written communications among player teams.
Physically, the teams may all be at one site, or they may
be dispersed at remote locations. In this sense, the system is essentially the same as a computer controlled
teletype network. Second, the system provides control
capabilities for the game director(s), including the
capability to define specific communications networks,
the capability to monitor communications content, and
the capability to maintain complete game data files.
Third, the system interfaces both game players and
control staff interactively to man-model simulation programs.
In the following sections, the component programs of
the system are briefly described. These descrip~ions are
organized around two perspectives, that of the player
and that of the game control staff.
Player oriented programs
The program modules described in this section perform a variety of functions for the players in a gaming
exercise. They include a message handler, a text editor,
and a simulation program interface module.
Diagram 1 depicts two player terminals interacting
within the framework of the message handler. The routing of a message, say, from terminal A to terminal B is
as follows. The message is input via A's OUTBASKET, which, in effect, stores it in a "pending file." It
will remain in the "pending file" until it is acted upon by
a control terminal. The system permits two or more
control terminals to have this function; one or more
might serve as an umpire terminal and another as an
observer terminal. As will be discussed below, an operator at a control terminal can do three things to a message. First, he can reject it as is; that is, the message
will be returned to A by way of A's INBASKET.
Second, he can forward the message as is. Third, he can
forward or reject the message after making editorial
comments and changes on it.
Diagram 1 also depicts the fact that each message is
entered into a permanent game file automatically as it
is handled.
The idea of having control terminals as part of the
communications channels stems primarily from the requirements of free-form games in which judgments by
the game control staff (umpire) play an important role
in the game. It also pertains to messages and documents
sent from player teams to the game control staff, for
example, position papers and moves.
Message-handling
MESSAGE HANDLING SOFTWARE
The message-handling programs in the system are
designed according to an "inbasket/outbasket" principle. The system accepts a message from a user terminal
when a user request is made for "OUTBASKET."
The message is routed to an intervening file structure
where it stays until its recipient makes an "INBASKET" request; at that time the message is printed on
his terminal. These input and output events may occur
at any time; they may be nearly simultaneous or hours
or even days apart. How often a player interrogates his
CONTROL TERMINAL (S)
Diagram 2-Message-handling: Automatic mode
Information Management System for Scientific Gaming in Social Sciences
Message-handling: Automatic mode
When the message handler is set for automatic mode,
all messages are routed to their destinations without
being intercepted by control terminals (Diagram 2).
As with the manual-intercept mode, each message is
entered into a permanent game file automatically as it
is routed through the system.
Message-handling: Mixed mode
The system provides the capability of having some
sets of teams linked together in the automatic mode
and other sets of teams linked in the manual-intercept
mode, all within the same gaming exercise.
899
zulu time on all incoming and outgoing messages. The
clock may be set to print actual times or any past or
future times desired by the game control staff.
User text editing
A second set of player oriented capabilities complements the message-handling programs. A text editor
will be made available to player terminals in the future
revision of the system. It will serve as an aid in the online composition of messages. It allows the user to delete
and rewrite all or part of the line of text on which he is
currently working and to delete and rewrite the entire
message so long as it has not become input to the system
through an "END" command.
With the scheduled revisions, the system will also accept paper tape input of messages composed off-line.
Message-handling: Addressing options
Player interaction with simulation models
The message-handling software also provides the user
with several addressing options. Of course, he may address a message to any other team in an exercise and to
the control terminal(s). Additionally, he may input
messages with multiple addresses; the system will route
them accordingly. At the discretion of the primary control terminal, a particular exercise may include collective actors with group names. For example, the address
"Security-Council" may include all members of the
Council who are represented by teams in the game; each
member of this group will receive the message accordingly. A special case of a group name is "ALL," in
which case all active terminals will receive the message.
The system is able to accept player team names in
natural language ; it does not require numerical designations for the teams.
Message-handling: formatting
The system also embodies a few features which are
designed to assist the participants in exercises in maintaining their own records. One such feature is the
"paginator." At the present time it has been implemented only for messages being retrieved from one's
inbasket. It prints each message on a separate page,
which it measures to eleven inches in length and numbers in serial order. Anyone who has attempted to
maintain order among the myriad scraps of paper which
accumulate in a busy game will appreciate this feature.
Another aid to the participants and to one who is
trying to reconstruct game events after the game is over
is the "date/time clock." It prints a calendar date and
A third set of player oriented capabilities allows the
user to call a particular simulation program from a
simulation program library. The user's request is
"LIBR." The system responds with an interactive
version of the particular man-model simulation called
from the library. The player is given data upon which to
base his decisions and the simulation program leads him
conversationally through the decision sequence ending
with a printed report of the results of his decisions.
From each team's point of view, this capability is very
much like having access to a time-shared system which
computes only its portion of the simulation model.
Game procedures determine the timing of these interactions. The model itself is initialized and updated by the
game control staff.
Control-oriented programs
A more extensive set of control capabilities have been
programmed into the POLIS game-administration system. They include programs for defining and modifying
particular gaming communication structures, programs
for monitoring and editing player interactions, and
programs which assist in the reconstruction and analysis
of games after they have been completed. These capabilities are described briefly in the following sub-sections.
Creating a game
Both logically and temporally, the primary control
oriented capabilities of the system have to do with the
900
Spring Joint Computer Conference, 1972
creation of a game. These capabilities are embodied in
the system's "CREATE" functions. These CREATE
functions are the only control functions that cannot be
delegated to any participating entity other than
"POLCON," (POLIS Control), the primary control
terminal.
The CREATE function enables POLCON to do the
following.
(a) Set the date/time clock for the game.
(b) Specify up to forty-eight participating entities
(player-teams, control teams, etc.) in a game by
proper name and user code. These names may
include group names, including specification of
which teams belong in which groups.
(c) Restart from a previous game (the same game, in
case of system failure), which eliminates the
need to recreate the game.
(d) Assign functions to participating terminals, including delegating control functions. For each
entity in the game, including both player terminals and control terminals, POLCON may designate:
(1) whether it is to be able to send messages
(outbasket function) and/or to receive messages (inbasket function);
(2) whether its messages will be handled in the
automatic or the manual-intercept mode;
(3) whether it is to be able to "CALL" Control
in real-time, bypassing the outbasket/inbasket message-handler;
(4) whether it is to be able to call "LIBR" in
order to interact with a particular manmodel simulation program; and
(5) whether it is to have such control functions
as: "STATUS," "RETRIEVE," and "UMPIRE" (described below).
Updating a gaIne
Another control oriented program complements the
CREATE functions. It is an UPDATE program. It
permits the dynamic modification of most CREATE
functions, including the addition of new participating
entities (by proper name), resetting the date/time clock
(forward or backward), and the reassignment of message-handling functions.
"Con trol's" Inessage InanageInen t functions
When the system is in manual intercept mode, several
message management capabilities are at the disposal of
the game control staff.
(a) A "STATUS" request enables the game control
staff to determine the contents of the game file
for any time period and any set of participating
teams. All messages are listed by time, parties,
and subject matter. Their status is noted, that is,
whether they are pending or whether and at
what time they were forwarded or rejected.
(b) A "RETRIEVE" function is also available to
the control staff. It extends monitoring capabilities to enable complete messages to be examined
after they have been identified via a STATUS
check.
(c) Control terminal(s) can also perform "UMPIRE" functions. These pertain to any message
in the pending file. They include "EDIT" and
"FORWARD /REJECT" options. That is, messages may be forwarded without alteration; they
may be commented upon and edited (deletions,
insertions); and messages and papers may be
returned to their points of origin.
"Control" interface to siInulation
library prograInS
From a control point of view, simulation interface
primarily involves calling up the appropriate simulation
model from the program library, initializing the model's
variables and parameters (analogous to, but different
from the CREATE function), and establishing files for
recording time-series data on the model in operation.
"Control's" data-Inaking functions
The system also provides some textual analysis capabilities for the game control staff. Supplementary control
terminal(s) may be established from which observer(s)
may engage in real-time content analysis and commentary. This is done through a part of the umpire
function. The request, "CODE," elicits a system response providing the observer with up to six empty
coding categories which he may use to define content
dimensions (for example, a threat) and to assign numerical rating for a particular message on that dimension.
The request "COMMENT" enables the observer to
Information Management System for Scientific Gaming in Social Sciences
append open-ended commentary to a message-perhaps
an explanation of his coding judgments, or perhaps some
information about the context surrounding the particular message. Neither observer coding nor observer commentary information is seen by the players; both kinds
of information become part of the game file.
SYSTEM ARCHITECTURE
Hardware configuration
The POLIS system for the administration of gaming
exercises was designed and programmed to execute in a
hardware environment consisting of the following:
(a) PDP 11/20 CPU (with 60 Hz Clock Interrupt)
901
I/O, a teletype driver and a magnetic tape driver. Both
drivers operate in conjunction with a TASK SWITCHING PROGRA:\l (discussed below) to initiate an I/O
transfer, to set the appropriate interrupt status bits,
and to relinquish control to some other user. When the
I/O transfer is complete, a hardware interrupt returns
control to the particular driver which then processes
errors if necessary, sets the "I/O Done" bit associated
with this user and returns control to the TASK
SWITCHING PROGRA:\I. Both drivers can manage
I/O transfers simultaneously for any number of users.
Initialization and systelll restart
These programs operate together to initialize the following information for the system after either an initial
start-up or a start-over from a system or power failure.
(b) 8K (16 Bit) Words Core lVlemory
(c) 2 Magnetic Tape Drives (Dual "Dectape")*
(d) Primary Teletype Console
(e) Alphanumeric Television Display
(f) 2 Acoustic Couplers with telephone answerers
and associated control and interface logic.
Although the current system executes in the above
configuration, extensive modifications are under way to
take advantage of a recently acquired 64K word fixed
head disc. This will result in a revised version of the
system which will have features identical to the present
version, but will eliminate some long interaction delays
(up to 30 seconds) currently caused by frequent accesses
to magnetic tape.
There is no limit to the number of acoustic couplers
which can be simultaneously accommodated by the
software. The number specified above reflects a core
memory limitation only,that is, each additional 4K
words of core above the basic 8K would allow eight
more couplers to be accommodated. This is a result of
the fact that 512 contiguous words of core memory are
required for each coupler.
System-management software
Hardware drivers
Two peripheral-device drivers are employed by the
system to manage asynchronous, interrupt-controlled
* Copyright Digital Equipment Corporation.
(a) An entity called "POLCON" (POLIS Control)
is specified and allocated all of the available system functions.
(b) A Task Control Block (TCB) is created for the
primary teletype console and each acoustic
coupler.
(c) A Master Reset is executed to remove all interrupts pending, and control is passed to the
USER REQUEST DISPATCHER.
This minimum system state is sufficient to allow
POLIS Control (POLCON) to log-in and create a new
game environment or reestablish the environment that
existed before a system failure.
Tasli switching progralll
This program "time-shares" the use of the system
among all of the I/O drivers. Control is relinquished to
the TASK SWITCHING PROGRAlVI, \vhich then
checks sequentially the "Done" bit in each Task Control Block (TCB) and transfers control (back) to the
first user it encounters whose "Done" bit is set. Thus,
the following sequence of activity occurs (assuming, for
example, that only two consoles are active).
(a) The program being executed by User "A" requests an I/O transfer.
(b) Control is transferred to the appropriate driver
which clears the "Done" bit in the TCB associated with User "A's" console and the I/O
transfer is initiated.
902
Spring Joint Computer Conference, 1972
(c) Control is transferred to the TASK SWITCHING PROGRAM which then checks the "Done"
bit in each TCB until it finds one that is set. If
the "Done" bit in the TCB associated with
User "B's" console is set, control is then returned to the program being executed by
User "B."
(d) While User "B" is executing, the I/O transfer
requested by User "A" is terminated under interrupt control and the "Done" bit in his associated
TCB is set. When the program being executed
by User "B" requests an I/O transfer, steps 1-3
again take place and User "A's" program will
again gain control.
Since the system is inherently I/O-bound, this
method permits each user to consider the system to be
dedicated to him alone.
Clock interrupt handler
This program maintains an internal calendar/clock
which is initialized and updated via "CREATE" and
"UPDATE" functions.
User-interactive software
User request dispatcher
This program permits a user to log-in and execute
those system functions which he requires.
The user initially gains access to the system by typing
in "CTRL/P". This program then requests that the
user enter his game name and two-character protection
code. After validity-checking this information, the program then asks the user for the system function he
wishes to execute and, if this user has been allocated
this function by POLIS CONTROL, control is passed
to the requested program.
All of the user-interactive programs discussed immediately below are executed as subroutines of the
USER REQUEST DISPATCHER.
Message switching prograDls
The primary function of the POLIS system is to
route messages from one user to another. Each message
entered into the system is recorded on magnetic tape
before being routed to its destination.
(a) Send Message Program. This program allows a
user to enter a message into the system to be
delivered at a later time to another user. The
program first asks for the address of the message.
This may be a single name, a group of names, a
special name which represents a group of names,
or all players in the game. Next, the user is asked
to enter the text of the message.
The program then records on magnetic tape the
addressing information, the text, and the time
that the message was input.
A particular user may operate in one of two
modes: manual or automatic. In the former, any
message input by the user will be given a pending status and will not be made available to its
recipients until POLIS CONTROL has taken a
specific forwarding action. In the later mode,
any message input by the user will be made immediately available to its recipients.
(b) Receive Message Program. This program allows a
user to receive all non-pending messages addressed to him since the last time he executed
this program. The program prints out the body
of the text as well as the time it was received.
(c) Console-to-Console Communication. This function
is not implemented in the present version, but it
will be made available in a revised version. The
purpose of the program is to link POLIS Control's (POLCON) console with that of some other
user in order either to carryon a telephone-like
conversation or to monitor the user's inputs to
the system.
Control prograDls
(a) Create Game. This program allows POLIS Control initially to specify the entire environment
for a game. The environment includes the following information.
(1) the date and time
(2) the simulation names of all users in the game
(3) the two-character protection code associated
with each name
(4) any special group names (i.e., names which
represent groups of users)
(5) the system functions which each of the users
will be allowed to execute during the course
of the game
Information Management System for Scientific Gaming in Social Sciences
This information is stored in the system tables
discussed below. The program also makes a copy
of this information on magnetic tape to permit a
recovery in case of a system failure or to run an
identical g;ame at some later time. This function
cannot be allocated to any user except POLIS
CONTROL.
(b ) Update Game. This program allows a (control)
user to make dynamic changes in the game environment (such as the date-time). The game
environment may be changed in any way, with
the exception that names may not be deleted.
(c) Message Tape Status. This program allows a user
to get a report of the messages stored on the
magnetic tape. The report may be requested for
any time period from the beginning of the game
to the present, for any subset of senders, and/or
for any subset of recipients. The report consists
of the following information about each message.
(1)
(2)
(3)
(4)
the sender
the recipients
the time sent
the status of the message (i.e., pending, forwarded, or rejected)
(5) the sequential number assigned to the message by the SEND program
(6) the capsule summary of message content
(d) Retrieve lVI essages Program. The execution of this
program is identical to that of the message Tape
Status program except that, in addition to the
information reported, the entire text of the messages is printed. This function is used in conjunction with the program discussed next to allow a controller to effectively monitor the course
of a game.
(e) Umpiring Program. This program provides the
means for a controller (such as POLIS CONTROL) to monitor the course of a game and to
make significant modifications to the messages
that are routed between the participants in the
game. Specifically, the controller is allowed:
(1) to forward a message to its recipients or, if
the message is deemed to be inappropriate,
reject it back to its originator;
(2) to delete and/or insert text in the body of a
message;
903
(3) to encode a group of categories pertaining to
the content of a message; and
(4) to append an opaque comment about the
message to be used in a post-game analysis
of the game.
Whenever a message is modified in any way, a
copy of the original is retained in order to maintain the continuity of the game for subsequent
analysis.
POLIS network explanation
This program allows a user to interrogate the system
to get a brief description of any or all aspects of the
system.
N on-system software
The POLIS system is designed to allow execution of
non-communication system programs in either of two
modes; stand-alone or interactive.
Stand-alone (Library) programs
In this mode, man-model simulation programs which
require the facilities of the entire computer are stored
on a library tape and, when requested, preempt the
execution of the system. A core image of the system is
saved and the requested program is swapped into core.
After completion of the program the system is restored
and any game which was in progress can continue as
though no break had occurred.
Interactive programs
In this mode, simulation models may interact with an
on-going game in much the same way as a live participant. That is, inputs to and outputs from the model will
be stored on the message tape as though they were actual
messages. This function will be implemented in the 1972
revisions of the system.
Data-base structures
Task control block (TeD)
The TCB is a table of 512 core words which contains
all of the information associated with a particular user
904
Spring Joint Computer Conference, 1972
console. In the current configuration there are three
TCB's, one for the primary teletype console and one for
each of the acoustic couplers.
The TCB contains the following information.
(a) a pointer to the next TCB
(b) the contents of the stack pointer (relative to this
user's stack) at the time this TCB last lost control due to an I/O request
(c) this user's stack (64 words)
(d) the program restart address for this user
(e) the device number associated with this TCB
(f) the status of the I/O device associated with this
TCB
(g) an input buffer (72 bytes)
(h) items for the address of a message to be output
and the length of the message
(i) Dectape status
(j) Dectape block number to be input/output
(k) Dectape buffer (512 bytes)
(1) the entry· number in the name table of the user
currently using this TCB
(m) work space for the various programs which this
user may execute (139 words)
SysteIll tables
The system tables contain all of the information
about the current game which was initialized by the
Create Game program.
(a) Permanent Bit-Map, which maintains an account
of the currently available blocks on the message
tape. There are 576 blocks of 512 bytes on a
Dectape. A zero bit indicates that the associated
block is available. A one bit indicates that the
associated block has been used.
(b) Date and Time calendar/ clock, consisting of
twelve numerical ASCII characters which represent the date/time (formatted as: 11/1/7109:30:30).
(c) Name Table, consisting of a packed table of
ASCII characters which comprise the names of
all of the users in the game. The names may be
composed of any ASCII characters and may be
of any length.
(d) Protection Codes (two characters), associated
with each name in the Name Table.
(e) Privilege Table, consisting of a table of 16-bit bitmaps indicating the system functions which have
been allocated to the associated name in the
Name Table.
(f) Subordinate Name Table, which links the entry
numbers of group names with the entry numbers
of the participant names which they represent.
Magnetic tape files
Files on the magnetic message tape are composed of
linked blocks. The first word in each block is a pointer
to the next block in sequence. Files may be of any
length, and a block-pointer of Zero indicates the last
block in the file. Consecutive blocks in a file are physically at least four blocks apart. Each file contains the
image of one message.
The Tape File Directory consists of ten blocks on
the tape and is composed of 226 entries of eleven words
each. Each entry contains the following information
about the message contained in the file.
(a) the number of the first tape block in the associated file
(b) the status of the message (e.g., PENDING)
(c) the Name Table entry number of the sender
(d) the date/time that the message was sent (coded
as twelve 4-bit segments)
(e) a bit-map indicating which of the original recipients have not yet received the message
SUMlVIARY
In this paper we have tried to identify the main characteristics that should be incorporated into a comprehensive, computer-based system for the administration
of social gaming exercises. We have described, first
functionally and then technically, the game administration system developed at the POLIS Laboratory.
Our system design combines information management,
simulation, and data structuring and analysis capabilities into an integrated, user-oriented package. A limited,
first version of the system is currently operational on
the Lab's PDP-II system. Realization of the full design
is our development goal for 1972.
ACKNOWLEDGMENTS
The authors would like to thank Messrs. Robert Dolan
and Carl lVIagagnosc for their invaluable contributions
to the programming effort described in this paper. In
addition, we gratefully acknowledge the assistance of
Information Management System for Scientific Gaming in Social Sciences
Mr. Michael Spafford, the POLIS Lab's engineer, who
kept the computer hardware operational when needed.
The senior author wishes to acknowledge his indebtedness to Gerald H. Shure and his associates at the
Center for Computer-Based Behavioral Studies at
UCLA. His association with that group, which included
Drs. Robert Meeker, Harvey DeWeerd and Richard A.
Brody, led to the development of the work described
in this paper.
905
REFERENCES
1 R R BEATTIE L BLOOMFIELD
Cascon: Computer-aided system for handling information on
local conflicts
ACDA-WEC-141 Center for International Studies MIT
fI, C /70-8 December 1969
2 Shure's gaming communications system was operational in
1968, on the System Development Corporation's Q-32
computer, which has subsequently been phased out of
service
The development of process control software
by JAMES D. SCHOEFFLER
Case Western Reserve University
Cleveland, Ohio
INTRODUCTION
tures, pressures, flows, thickness, speed) or discrete in
time (concentrations of a stream as measured by an
on-line chromatograph from periodic samples from the
stream, average cross machine basis weight as measured
by a scanning beta gauge, quality variables which are
measured off-line in a laboratory). Process control involves the use of these measurements in order to help
the human operator more economically run the process.
This objective may take one of several specific forms.
For example, regulation or direct control has as its objectives the maintenance of critical process variables at
prescribed values called operating or setpoints. The
need for regulation of pressures, temperatures, speeds
and the like, are obvious. Quality variables too may be
regulated as for example maximum moisture in a sheet
of paper or thickness of sheet steel. Regulation involves
the basic feedback process: the comparison of measured
and desired values (set points) to produce an error and
the use of that error signal via a control algorithm to
change some manipulated variable by a physical actuator. For example, the regulation of tank liquid level
might be carried out by manipulating the position of a
valve in an input stream. Such control is relatively fast,
involving sampling of hundreds of variables several
times per second, and outputting to actuators at the
same rate. The periodic nature of this task is one of the
dominant features of industrial process control in that
the time sharing of the computer among many such
tasks results in critical response requirements on the
hardware and software.
Control is a tool rather than the end in itself and
necessarily is modified from time to time as the process
needs or physical structure change. The application,
however, does not permit the taking of the computer
off-line for program preparation but rather demands
that the software be capable of modification while the
process is running on-line with attendant guarantees
and assurances of safe reliable bug-free operation.
Hence, an essential ingredient in process control applications is operator integration which takes place
The use of on-line, real-time computers for control of
industrial processes has been increasing rapidly during
the past ten years. That the cost of the software necessary to implement such systems exceeds even the hardware costs became clear in the initial installations. As a
consequence, much effort was devoted to the development of efficient, economical software and software approaches for use in industrial process control applications. During the past five years, there has emerged
from these efforts the realization that process control
software is different from software for large scale batch
processing, time-sharing, message switching, or any
other computer applications. It contains its own requirements and problems and leads to a distinct set of solutions. Moreover, this difference is due to more than the
size of the computers involved in industrial process
control. The objective of this paper is not to catalog the
significant features of various software systems in
existence today for this has been done very well in a
number of recent survey papers. Rather, the objective
is to describe the basic structure of current industrial
process control software, emphasizing the unique structure of that software, how it evolved, and its current
points of controversy and problems.
THE PROCESS CONTROL APPLICATION
The source of the uniqueness of process control software is due to the nature of the application, environment, vendors, and users. There is a large variety of
processes in the paper, rubber, chemica], petroleum
primary metals industries. Control of such processes
generally involves a set of plant instrumentation including sensors, transmitters, and special instruments
which provide measurements of physical and quality
variables important in the process application. Such
measurements may be continuous in time (tempera907
908
Spring Joint Computer Conference, 1972
through special purpose consoles oriented toward the
particular application. From these consoles, an operator
may examine any variable in the system, produce summary logs of the operation of the process, demand
changes in parameters being used for control of the
process (setpoints for example), and may even call for
changes in the structure of the control system: adding
variables to be scanned, adding control calculations for
regulatory purposes, or deleting control loops. This implies that all of the parameters and data associated with
the process control regulafon program must be in a
form which can be mnemonically referenced and modified by an operator. Thus, the data base associated with
regulatory control cannot be imbedded in the programs.
This leads to the special structure of this software.
Supervisory control differs from regulatory control
in that the objectives are not the maintenance of process variables at particular values but rather the determination of those operating or set points. For example, operating guides are operating conditions which
have been deduced during previous successful operations of the process. When similar conditions hold, the
computer directs the operator to use these operating
points or else justify any deviations. This takes away
the option of operating the process in a safe but uneconomical manner.
Optimization of operating conditions may be the
goal of the supervisory control system. Optimizing control is the determination of set points from an analytical
performance criterion plus a mathematical model of the
process. Successful optimal control has been carried out
in the petroleum, steel, and electrical power industries
among others. Supervisory control is characterized by
much more complex programs than regulatory control
but carries with it the same demands on reliabi1ity,
centralized data base, and operator communication.
That is, mathematical models of the process imply
knowledge of the process state which in turn implies
knowledge of all the variables, scale factors, offsets,
calibration factors and other parameters which make
up the process data base. The operation or status of
every instrument, actuator, and control in the process
is needed to determine the current state of the process.
All of this information must be made available to the
operator on demand and so it too must be organized in
a central, accessible data base.
Many special purpose programs are necessary to support the basic application including caJibration, hardware checkout, special logging and data reduction programs, startup and restart routines, and general programs to maintain and update the data base, including
tables of mnemonics. In addition, the functions which
are not automatically scheduled according to time or
event information must be available on demand of the
operator, implying an on-line, interactive command interpretive program. All of these many programs must
co-exist, interact through the data base and executive
control programs and hence lead to a far from trivial
implementation problem. The result is the current process control software organization described in the following sections.
PROCESS CONTROL SOFTWARE
For a very brief interval, it was thought that process
control software would, after initial debugging, run
without change for a long period of time. If this were
true, many of the problems of the initial systems would
not have existed and the current structure of process
control software might be radically different. The process changes often, necessitating similar changes to
the software. The chief characteristic of modern process
control software is its ease of change, permitting on-line
modification of control algorithms and even addition
and checkout of programs while the system is running.
The typical computer used for industria1 process control
during the last five years is what today would be considered a medium-sized machine, significantly larger
than today's minicomputer in the sense of attached
peripherals. As a consequence, it was necessary to provide an executive control program to oversee the multiple interacting programs operating in a real-time, concurrent manner. This need, plus a desire for ease of
modification and the demand for a flexible, general
process data base leads to the structure shown in Figure
1.
That figure shows a conventional real-time executive
control program (a monitor) along with a process data
base and application programs. The distinctive part
which makes it uniquely process control software is the
set of application packages which are designed to carry
out specific tasks in a very efficient manner while at the
same time permitting easy communication among themselves, the executive, and the application programs.
Process control executive
Successful process control involves the implementation of many concurrent tasks. Process control programs
doing data acquisition, control calculations, analog and
digital output, operator communication and the like
call for some multiprogramming capability. Executive
control programs recognized this and incorporated the
multiprogramming in one form or another. Early executives organized core into two partitions, one containing
Development of Process Control Software
Background
Processing
Realtime Application
Programs often written
-~
in realtime Fortran
""---=----'1 \
Scheduler
Shared Process
Data Base
1I1emory ""1aintenance
I/O Request Subs.
I/O Drivers and
Interrupt Handler
~~
Special Application
Packages for
Data Acquisition
Direct Digital Contr 1
Sequencing Control
Operator
Communication
Fill-in-blanks
\
Algorithmic Langs.
Output to Process
Data Base and
Application Packages
\
\
\
H
Slower, shared
I/O
Dedicated. large
volume I/O
(analog and digital)
Special
Translators
for Process
Oriented
Languages:
Block Diagrams
\
With Data
Base and
Application
Packages
909
Realtime Fortran
Compiler
Assembler
Link Editor
Utility Programs
Process Operators
Console
Figure I-Structure of process control software
permanent resident programs (those requring fast response or maintaining control system integrity in case
of failure of the bulk storage system) and the second
being used to swap program modules called coreloads in
and out of core. A coreload consists of one or more mainline application programs plus subroutines used by these
programs and not contained in the permanent resident
software. Coreloads may have different priorities in
which case the executive often interrupts execution,
swaps the coreload out (saving it on bulk storage),
swaps in and executes the higher priority coreload and
later restores execution of the interrupted core load.
Multiprogramming based on coreload swaps proved
too slow for many applications. This led, of course, to a
need for large and larger core storage so that critical
programs could be permanently core resident. This
motivated a change toward a more dynamic allocation
of memory. The most common system is a multipartition system in which all programs assigned to a partition run with the same priority. This implies that a program, once loaded into a given partition and execution
begun remains in that partition until its task is com-
pleted. Then the next scheduled task for that partition
is swapped in to replace the completed program.
The partition system recognized a perhaps nonobvious fact of life of process control systems: the critical
resource is not main memory but rather the bulk storage channel (usually the disk). This is especially true of
systems based on moving head disks of course. Running
tasks to completion minimizes the number of bulk
storage swaps while maintaining the priority levels of
tasks.
The multipartition system requires the allocation of a
progra,m or task to a partition and the assurance that
all such programs fit in a given partition and have the
same priority. This requires a careful analysis of the
application but results in a smooth, controllable realtime implementation.
Most machines today are of the 16 or 24 bit word
length variety. The 16 bit machines in particular take
advantage of the partition system because there is no
need for dynamic. relocation of programs. The 24 bit
machines can relatively address ±8K of core, a value
sufficient to permit dynamic relocation of most process
910
Spring Joint Computer Conference, 1972
control programs (but not of the data base). In some
executives, core is divided into partitions with some of
the partitions being used as indicated above but with
one dynamically allocated by the executive. The latter
facilitates background Fortran-level processing.
Process control executives contain extensive error recovery capability because of the difficulty of restarting
the system in case of a crash with critical data in core.
Error recovery includes backup of I/O devices where
feasible, specification of alternative devices, multiple
tries at attempting reading of bulk storage, automatic
power fail program backup, and automatic maintenance
of copies of critical files like the process data base.
Such executives permit m~ltitasking in one form or
another but not usually in the completely general case.
That is, tasks in a partition are permitted to schedule
(turn on, turn off, delay, or queue) other tasks in that
and other partitions. However, the allocation of the task
to core is predetermined and its priority is not dynamic,
but rather pre-assigned. This has proved necessary not
only because of the difficulty of dynamic relocation but
also because of the need to guarantee a maximum response time for critical real-time programs.
I/O in these executives is handled in the straightforward manner, using I/O drivers and I/O request
subroutines. Drivers are responsible for the maintenance
of the interrupt driven I/O with the actual device, outputting or inputting one character or word at a time
usually with one interrupt per data item transferred.
Little I/O is done through direct memory channels
except in the case of bulk storage devices. The I/O request subroutine is used to control the competition
among many tasks at different priority levels from interfering with one another. Such routines queue requests, notify routines (reschedule them) when a requested I/O operation is complete, test device status,
etc.
As long as the volume of I/O is low or the response
time of tasks not critical, such an organization is quite
sufficient and essentially like any other application.
That is, none of this software is unique to process control.
Two situations arise, however, which call for unique
process control software. They are: the need for high
volume, very flexibly organized process I/O; and the
need for mnemonically oriented operator communication. These require special packages for their implementation and are discussed below.
only is it desirable to be able to change the parameters
of the data acquisition loop or the status of a sensor from
active to inactive, but also to be able to add and delete
from the list of points in a flexible fashion. Thus, if a
sensor is added to the system, it is desirable that the
operator be able to add the point to the list of converted
values, including all the appropriate parameters necessary for the conversion and all the linkages to control
programs associated with the variable out of limits,
bad data, and so on. This, of course, can be done by reprogramming the routine, but is undesirable and not
necessary. The basic operations involved in converting a
point are similar from point to point. The scan routine
uses the address of the point, values for the amplifier
gain, limits, etc., and in effect, applies similar sequences
of algorithms to each of the points to be converted. A
data acquisition package takes advantage of this as
shown in Figure 2 which shows an interpretive scan
program and a set of data structures called loop records,
with one loop record associated with each point to be
converted. All the data and parameters associated with
a particular point is stored in the record, including the
Table of Loop Records (part of process data base)
kth loop record
containing all data
and parameters for
data acquisition and
control loop
Data Acquisition and Direct Digital
Control Package
Interpreter Program
Scan each loop record
periodically
Carry out appropriate
actions by calling
corrunon routines
using data and
--0
--0
--0
&..------0
parameters from the
loop record
Special packages for data acquisition and control
The need for generality and flexibility in the typical
industrial data acquisition system is paramount. Not
--0
Analog input
~1odule
Scan Alana Module
Engineering Units Conv.
Control Algorithms
Filtering Algorithms
and others
Corrunon Routines
Figure
2~Example
of data acquisition and direct digital control
package
Development of Process Control Software
period or time between conversions, status of the point,
external names, etc. The interpretive program scans the
records in some sequence until it finds one which is
scheduled for conversion. It then examines the loop
record to determine the appropriate dat.a and algorithms
to be carried out on that data point. Pointers to the
individual algorithms to be carried out on the point,
followed by the parameters to be used by that algorithm,
are stored in the loop record. If any error is detected in
the conversion, an error recovery routine is entered and
executed. This might include an attempt to reconvert
the point or to estimate the current value in terms of the
previous value (which is stored in the loop record), or
preparation or notification of either a program or the
operator. The interpretive program then continues
through the loop records, is offset and scaled. After
conversion to engineering units, the data is limit
checked for validity, alarm checked, and perhaps digitally filtered by a moving average filter involving the
current value and the previous several values. The set of
loop records is a very well organized process data base.
The loop record concept is a very flexible one in that the
actual algorithms carried out on any particular data
point may vary considerably by simply changing the
parameters and pointers in the loop record.
The only portion of the program particular to a
specific set of data points to be read is the information
stored in the loop records. It follows that the interpretive scan program can be written and debugged without actual knowledge of a particular application except
that all algorithms which might be needed in the application must, of course, be provided. Individual points
can be added or deleted by creating or deleting one of
the loop records. Because of the fixed format of the system, it is possible to organize the various loops so that
not all points with the same conversion period need be
carried out at exactly the same instant of time. That is,
points with the same conversion frequency can be subdivided into smaller groups which are converted at the
correct frequency but offset or phased with respect to
one another in time.
The efficiency of such a system must be considered.
The interpreter scans through items in a loop record and
in effect calls small modules or sub-routines to carry
out the desired operations. There is a certain amount of
overhead associated with scanning through the loop
record, determining which routine is to be carried out,
transferring to this module or routine, as well as extracting from the loop record the parameters and data needed
by that algorithm. If the module or algorithm is too
small, it follows that this overhead involved in scanning,
transferring and extracting parameters, may be comparable to or even large compared to the time to carry
911
out the algorithm. The result would be excessive overhead, for inline code to carry out the same task would
be more efficient. The objective is, of course, to use
modules whose execution time is large compared to the
overhead or scan time so that no real overhead penalty
is incurred. The overhead associated with interpreting
the loop records is offset by the flexibility of the system.
Most important is the ease of operator communication
with the data base.
If this can be done, of course, the generality and flexibility of the interpretive loop record organization can
be achieved without discernible overhead penalties.
Whether or not this can be done is dependent upon the
organization of the loop record, the instruction set of
the computer, and the addressing modes available in the
computer.
Control loops lend themselves to a simi1ar loop record
organization. Additional functions (filtering, control
algorithms, error checking, outputting, etc.) are listed
in loop records often along with the data acquisition
information and interpreted by the same or a similar
routine. The result is a separate data base and data acquisition and control package which may be interrupt
driven independent of the executive or possibly assigned a high priority level and controlled by the executive.
The special purpose packagi:\ relieves the application
programs from considering the data acquisition and
direct control task in great detail including error checking, organization of operator communication, and
startup. Other applications are similarly best handled
by special purpose packages. These include sequencing
control-monitoring the state of the process and causing events to occur (turn on burners, valves, etc.), in
the correct sequence and when prescribed conditions
are met. Examples include batch processing of chemical
processes, control of annealing lines, and the like.
Operator communication becomes a straightforward
task with a data base arranged as described above.
Interface routines to the data base provide application
programs the ability to read or write any particular
item in any record (including a full complement of error
checking). Copies for backup and restart are available
because of the centralized location of data as opposed to
its distribution throughout application software.
Operator interaction through a console limits the
amount of error checking necessary and makes a very
acceptable system for use in an on-line situation with
operators who are not trained computer operators.
Function keys are the most common communication
scheme with labeling in industry-sensible terms. Functions limit the complexity of the operator console support routines but nonetheless are nontrivial in size.
912
Spring Joint Computer Conference, 1972
In larger systems, it is convenient to separate the
data base into two parts, that which is essential to incore reliable operation in case of disk failure and the
remainder which is then swapped in and out of core
(perhaps on a single record basis) as needed.
In addition to special packages which are unique to
process control, other application programs are provided
which may interface to the executive and the special
purpose packages. Optimization is an example, permitting optimal control of a process unit provided a
mathematical model and sufficient measurements are
available. These differ from other application programs
only in that they are "canned" rather than written
by the user in a higher level language. Typically, they
interact considerably with the data base and its support
routines.
SOFTWARE PREPARATION FOR PROCESS
CONTROL
Current medium-sized and larger systems universally
provide the ability to write application programs in
higher level languages, most notably, extended Fortran.
This is both to limit the level of expertise of programmers but also to permit control engineers to produce
application software. With intelligent use of data acquisition and control data base packages provided by
the vendor and the general process control real-time
executive control program (including all its entries for
scheduling, error checking, I/O control, etc.), higher
level language programming becomes quite feasible,
especially in applications which involve significant computation. Other applications are developed more efficiently via packages like the data acquisition or direct
digital control packages described above. These are
usually programmed in assembly languages and linked
tightly with the executive. In some cases, they are assembled as part of the executive.
The net result in Figure 1 is an executive which does
not control all I/O but only that which is shared among
application programs. Special purpose packages maintain a centralized data base and perform specialized
control functions. Application programs perform tasks
on a somewhat slower basis, but interface extensively
to these packages through normal system subroutines.
Because of the need for flexibility and change, on-line
program preparation is needed in most process control
systems. This takes the form of a background command
processor, compilers and assemblers and library maintenance routines as well as link edit routines. Program
preparation including debugging can be done in a controlled manner in one of the partitions, without upsetting the remainder of the software system.
In recent systems, macro assemblers have become
available, even including libraries of system macros
which permit a user to custom tailor the operating system software to his particular application (at least in
the minicomputer process control systems). At present,
few cross assemblers are available and even fewer cross
compilers for software preparation on time-sharing or
batch data processing systems.
Much more significant is the preparation of data inputs for the dedicated application packages. The data
base contains all the information needed for the carrying out of these dedicated tasks. The operator console,
with its function keys, provides on-line data entry,
program change, control application modification, and
the carrying out of operator commands. Off-line program preparation is through translators of one form or
another. The natural language for the application might
be a block diagram indicating the interconnection of the
measurements, setpoints, filtering, control and feedforward algorithms. Specified this way, they must be
translated to data to be stored in the internal data base
for interpretation.
lVlany such communication languages have been developed in order to provide a means for process engineers who are not trained programmers to set up and
maintain an application involving hundreds and even
thousands of variables. Such systems specify the application in an English language fashion which is then
translated to internal data storage. Others are of the
"fill in the blanks" form which is a questionnaire which
is completely self documenting (and 100% of the documentation) and which, when punched line for line on
cards, provides input to a translator which generates
interval entries in the tables of the various packages.
With these programs, an application can be put onstream very rapidly since the essential programming is
done and debugged independently of the particular application. l\10reover, the change from one control
structure to another (one startup procedure to another,
etc.) is very straightforward, amounting only to change
of data but no essential reprogramming. There is little
penalty incurred in changing the control software, even
less than in the case of Fortran programming of application programs. As mentioned in the next section, this
package concept is less economical today because of the
introduction of minicomputers.
The other trend today is toward the use of "realtime languages" for process control, even involving an
attempt at a worldwide standard. There is a difference
of opinion as to the economics of standard process controllanguages. As noted in Figure 1, the bulk of process
control software lies in the executive and the application
packages. Application programs tend to be written to
use these programs and hence are less expensive (the
Development of Process Control Software
complexity of the real-time application is imbedded in
the application packages and the executive). One school
of thought advocates the need fpr a higher level system
programming language for the economic and efficient
production of the executive and the application package
or at least the tailoring of these standard packages to a
given configuration and application. The other school
of thought argues that these should not be specialized
or customized but be standard so that they can be supplied by any vendor (and at reasonable cost since they
can be written off over a large number of installations). This school of thought then argues that the
remaining cost is in the application programs and
that a language ought to be adopted for this purpose
(extended Fortran, or some modification of PL/1 or
Algol are among the suggestions).
It appears that no economic study has actually been
carried out to determine the savings which might result
from either of these approaches. The latter case already
provides extended Fortran so that only incremental
gains can be expected. The former case is difficult to
assess because it depends upon the need for changing of
standardized software packages or adaptation of these
to various configurations of computers. If it were not
for the minicomputer, data could eventually be
gathered. However, as indicated in the next section, the
minicomputer is changing the economics of process control software significantly.
CURRENT PROBLEMS IN PROCESS CONTROL
SOFTWARE
The development of process control software over
the past five years or so was directed toward the organization of Figure 1. Recently, packages for data
acquisition and direct digital control, sequencing control, batch processing, process optimization, model
identification, graphic operator communication, and
others were developed. If the use of medium-sized
machines continued, this software would have resulted
in significant decreases in costs of process control software implementation. Several problems, however, indicate that further development is necessary.
First, the use of a medium-sized machine is difficult to
justify economically in many applications. The capability of such machines is such that many tasks can be
carried out by a single machine. This, in turn, places
severe demands on the executive and application software in order that the installation can be carried out
smoothly. Moreover, the process itself must be large
. enough to justify such a machine and such extensive
software costs.
The advent of the minicomputer with its low cost has
913
changed the picture considerably. The lower cost of
small configurations implies that several tasks need not
be implemented in a single machine in order to justify
the use of a computer for control. This, in turn, implies
that perhaps the extensive software developments of
Figure 1 are not necessary for any smaller applications.
The result has been the use of minicomputers for many
small applications which in previous years had used
larger machines. This, in turn, implies that the number
of systems to write off software package development
has decreased considerably. Hence, larger systems with
very sophisticated software packages have recently
been more difficult to economically justify.
The minicomputer poses a set of problems which are
considerably different. First, the varied configurations
and applications do not always require complex executive or monitor systems. Consequently, there is less
justification for the development of extensive executives
on the part of vendors. The result is sometimes more
software development for the minicomputer system
than for a larger installation, robbing the system of its
apparent economic advantage over the larger system.
A second source of difficulty is the multicomputer configuration. The use of minicomputers for dedicated applications still requires the coordination of the systems
to achieve overall process control including scheduling
and higher levels of control. Hooking together a number
of small machines each implementing a portion of the
application is far from trivial for there is still a need for
'a coordinated data base and operator communication
even if the application is distributed over a number of
machines.
A related problem affecting the development of software for smaller machines is the rather commonplace
prediction that the bulk of sales for systems will lie in
discrete parts manufacturing rather than process control. The software necessary for this application has not
been widely developed and agreed upon but will certainly affect the organization and structure of future
minicomputer process control software.
The current question in process control software is
how to economically produce the special purpose realtime programs necessary for a low cost but efficient
implementation in a stand-alone minicomputer. In addition, how can the advantages of packages for specific
applications be gained since it is difficult to develop
them such that they are compatible with the varied
configurations and computer systems arising today?
Perhaps the answer is a higher level systems programming language with program preparation on a host
machine. Perhaps the answer lies in generalized software preparation schemes such as are used to generate
execution programs for large data processing machines.
Perhaps the answer lies in the use of sophisticated
914
Spring Joint Computer Conference, 1972
template macro assembly languages. Whatever the
answer, the well developed process control software
concept is today facing a period of rapid change similar
to that of five years ago.
REFERENCES
1 H E PIKE
Process control software
Proc IEEE Vol 58 No 1 Jan 1970 pp 87-97
2 J C MECKLENBURGH P A MAY
An engineering comparison of process control languages
Dept of Electrical Engineering Univ of Nottingham
3 Special issue on computer languages for process control
IEEE Transactions on Industrial Electrons and Control
Instrumentation IECI-15 Dec 1969
4 P R WETHERALL
Corall 66-A language for the control of real time processes
ibid 2 p TI73 1969
5 D G BATES
PROSPRO 1800
IEEE Trans Indust Electronics and Control
Instrumentation IECI-15 No 2 p 70 1968
6 S J BAILEY
Pushbutton programming for on line control
Control Engineering 15 No 8 p 76 1968
7 G W MARKHAM
Fill-in-the form programming
Control Engineering 15 No 5 p 87 1968
8 T G GASPAR V V DOBROHOTOFF
D R BURGESS
New process language uses English terms
Control Engineering 15 No 10 p 118 1968
9 R E HOHMEYER
CDC 1700 fortran for process control
IEEE Trans Indust Electronics & Cont Instmn
IECI-15 No 2 p 67 1968
10 T L WILLMOTT
A survey of software for direct digital control
ISA Paper 68-834 October 1968
Future trends in software development
for real-time industrial automation
by H. E. PIKE
General Electric Manufacturing & Process Automation Advanced Development Operation
Lynn, Massachusetts
more encompassing possibility of all real-time applications. Not included in our considerations are the applications typically called command and control, teleprocessing and interactive management information
systems (certain portions of our discussions will, of
course, apply to these areas).
Typical real-time industrial automation applications
span a range from direct numerical control to load flow
control and economic dispatch in the electric uti1ity
industry. Also included are direct digital control of
chemical processes, supervisory control of chemical
processes, sequencing control on assembly lines, control
of batch chemical processes and computerized numerical
control (see References 3-13).
In direct numerical control a small, fast, dedicated
computer is used to control a machine tool directly.
Typical required response times are on the order of
milliseconds. Load flow control calculations on the
other hand involve large data-handling requirements
because of large matrix inversions, and involve response times of minutes. 14
In direct digital control the computer directly manipulates the positions of control elements such as valves
without an intermediate mechanical control device.
Direct digital control requires response times on the
order of seconds to disturbances in the controlled
variable.15.16.17
In supervisory control the computer is used to provide set points which are then actually controlled by
hard-wired analog equipment. In this case the real.
'
tIme response capability of the control system is on the
order of minutes.
We could go on, but the point is clear: there exists a
tremendous range of application requirements in this
area which we have labeled industrial automation.
INTRODUCTION
"The
is a desk-size, stored program computer. It has a medium-scale capacity and uses a single
add~ess system. The
has all the advantages
of hIgh component reliability, automatic operation, and
ease of programming." 1
. These words are from the introduction of the operatIOns manual for one of the first minicomputers-the
"LGP 30 Royal Precision Electronic Digital Computer." The manual was written in 1959. In twelve
years we have just barely begun to understand the
impact of this size computer upon the industrial
automation.
In this paper we will examine future trends for programming for process control and real-time applications
of industrial automation. Although blind forecasting is
exciting, we will take the more conservative approach
of examining past history and our current environment
for factors which will lead to future developments. A
short definition of the scope of applications considered
will be followed by examination of current technological
and economic trends. A brief recap of the companion
survey paper by Schoeffier2 will serve to establish the
current state-of-the-art and a survey of current active
development and/or standardization activities will be
followed by predictions for the future. These predictions will be made from the fundamental viewpoint
that future developments are determined by three factors: the current state-of-the-art, current problem
areas, and new technological tools available for reduction to practical use. An underlying assumption is that
there is or will be sufficient economic motivation to
undertake the developments required, with timing
being the only uncertainty.
RANGE OF APPLICATIONS
PRESENT STATE-OF-THE-ART
I t is necessary to be more specific about the range of
applications to be discussed. Future trends in real-time
industrial automation will be discussed, rather than the
Schoeffier2 has assessed the current available tools
for software development. To summarize, in practical
915
916
Spring Joint Computer Conference, 1972
cause of the inherent restrictions due to programming architectures of current computers (References 39-47).
AVERAGE
PRICE
PER
FUNCTION
CURRENT TRENDS
Two current trends will combine to motivate future
development of improved programming techniques:
microelectronics, and recognition of the cost and complexity of the software production process.
(il
60
50
Microelectronics
40
30
20
10
1968
1970
1972
1974
1976
YEAR
Figure 1-'-Digital integrated circuit cost trends
use today we have as wide a range of software approaches as there are applications,18,19 about which the
following statements seem to hold.
• Most of the real-time programming is still done in
assembly language.
• Various dialects of Fortran have been tried, with
mixed results. They have been most successful
where a high content of engineering calculations is
included (References 20 through 27).
• Initial experiences with problem-oriented programming systems appear very promising, particularly when two conditions are met:
-functional similarity between installations, allowing a reasonable match between programming system and control problem (References
28 through 38) .
-sufficient economic base to merit development of
general purpose packages.
• Various attempts at general purpose real-time languages have shown the concept to be feasible, but
have remained as academic exercises, in part be-
The dramatic downward trend in price/function in
microelectronics is widely recognized. Figure 1 is typical
of the current extrapolations of this trend. An easily
customized MOS/LSI desk calculator chip has been
recently announced at a reported volume price of less
than $20.48. Our colleagues in the hardware design area
confirm that this device is comparable in logic power
(in terms of gate equivalents) to the LGP/30 of ten
years ago discussed above.
If this isn't enough, a major manufacturer has announced a CPU on a chip, of perhaps five times the
complexity of the LGP /30, and our R&D associates
advise us that such devices with electrically alterable
ROM's are feasible, for the ultimate in flexibility.
The message is clear-Software functions will disappear into hardware (or firmware) and modest investments in increased hardware capability (if made correctly) will reap outstanding software cost savings.
The software development process
Another important trend is increasing recognition of
the difference between "programming" and "software
development." Examining the following breakdown of
the software production process makes this distinction
clear:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Problem analysis
System structure design
Logic design
Program coding
Language processing
Unit test and debug
System test and debug
Installation
Maintenance
Although we all agree that the cost of software development exceeds the cost of hardware, we cannot
find any common agreement as to particular areas of
Future Trends in Software Development
concentration of cost within this breakdown of the
software development process.
CURRENT ACTIVE DEVELOPMENT AND
STANDARDIZATION ACTIVITIES
A number of industry-wide and university related
standardization and development activities are taking
place which will influence trends for process control
programming. Among these are the Purdue Workshop
on Standardization of Industrial Computer Languages,49
the American National Standards Institute's PL/I
Standardization and Development effort, and several
university programs in industrial automation.
917
3. Subsets
4. Development for Industrial Computers
The scope of Committee X3J1.4, PL/I Development
for Industrial Computers, is the development of a version
of PL/I suitable for application to process control and
manufacturing automation by defining and fulfilling
the functional requirements of this application area. A
basic rule governing this activity is that any string of
characters which has validity in the language being
developed and the PL/I that X3J1 proposes as a
standard must have the same semantics.
X3J1.4 and the Long Term Procedural Language
Committee of the Purdue Workshop are currently cooperating to determine if the production of a single
result is feasible.
Purdue workshop
UNIVERSITY AND OTHER ACTIVITIES
The Purdue Workshop on Standardization of industrial computer languages has stated as its objectives:
1. To make procurement, programming, installation and maintenance of industrial computer
systems more efficient and economical through
the development and standardization of industria] computer languages.
2. To minimize educational and training requirements for the use of industrial computer
languages.
3. To promote program interchangeability of application programs between different computer
systems.
The standing committees of the workshop include:
1.
2.
3.
4.
5.
Long Term Procedural Language Committee
Problem Oriented Language Committee
Glossary Committee
Fortran Committee
Steering Committee
The workshop met first in the spring of 1969 and
approximately every six months thereafter.
AMERICAN NATIONAL STANDARDS
INSTITUTE SUB-COMMITTEE X3J1
X3Jl is a sub-committee of Committee X3 of the
American National Standards Institute whose scope is
the proposal of a draft American N ationaljISO Standard Composite Programming Language based on PL/I.
X3J1 is organized into four working subcommittees
which are responsible for:
1. Standardization
2. Development
Various university laboratories both within the
United States and abroad are active in the development of real-time languages and/or programming techniques for industrial computers.
Some of the germinal early real-time language work
in the United States was done at Case-Western Reserve
University in their Systems Research Center. The
Purdue Laboratory for Applied Industrial control continues as sponsor of the Purdue Workshop. Results of
significant interest have appeared from the University
of Toronto, and German, French and British working
groups.
FUTURE TRENDS IN SOFTWARE
DEVELOPMENT FOR REAL-TIME
INDUSTRIAL AUTOMATION
We have noted above a number of forces which are
currently at work to influence future trends:
1. Microelectronics-a capability to produce very
powerful central processors at reduced cost.
2. A complex software development problem for
real-time application.
3. A current proliferation of programming techniques which are more or less satisfactory,
depending upon their match to the application
for which they are used.
4. A number of currently active development and
standardization activities working in areas
which range from customized problem-oriented
languages to development of real-time version
of PL/I.
Consideration of these forces leads us to believe that
the following trends will become evident in the future.
918
Spring Joint Computer Conference, 1972
1. Computers with architectures more oriented to
the use of special purpose real-time programming languages.
2. Hidden computers.
3. High-level real-time languages.
4. Problem-oriented languages.
5. Software factories combining sophisticated languages and debugging tools for the more effective
and efficient production of software on host
computers.
New real-time computer architectures
Because real-time computers are special purpose
rather than "general purpose" machines, a trend will
occur toward more customized architectures, particularly from a programming point of view. Characteristics
of these new architectures are likely to include:
1. Bit addressability
Arrangement of data in a real-time computer
in quanta of 8 bits is not very meaningful in
the real-time environment. Character oriented
data is manipulated relatively seldom in a realtime environment. Convenient methods of accessing data fields of varying widths will be
required for convenient implementation of data
structures, for example.
2. Direct implementation of real-time features
Real-time features such as semaphores, more
powerful interrupt structures with less inertia,
and direct hardware support of event data will
ultimately be implemented directly in the
hardware.
3. Control structures
Because sequencing problems represent a high
percentage of real time calculations, the instruction repertoire of real-time computers will become more oriented to the easy implementation
of more sophisticated control structures.
4. More sophisticated addressing techniques
Although recursion is not high on the list of
requirements for real-time applications, the
ability to handle reentrancy in a concise manner
is important. This and other requirements such
as the manipulation of inhomogeneous data
aggregates will dictate more sophisticated addressing modes.
When these more powerful architectures will occur is
not entirely evident at this time. It seems that an
orderly approach would be to pursue a more consistent
definition and understanding of the true real-time language requirements and then let these architectures be
designed to support such languages (Refs. 50 through
60).
Hidden computers
The capability to build special purpose hardware
will, in the future, increase the trend toward distributed digital systems. The computational capability
of real-time process control systems will not be concentrated in one central processor as is typical now but
will appear both in the central processor and a number
of remote dedicated processors which function to gather
intelligence about the process under control, execute
direct control functions and communicate to the central
processor for supervisory control functions. The major
force which will cause this to occur is what is sometimes
called "the cost of copper." This expression refers to
the fact that in many installations it is possible to
spend as much installing the wiring to carry signals
from sensors and control devices back to the computer
as on the computer itself. The impact of this trend
upon programming techniques is that these devices
will, to all intents and purposes, be hidden from the
user. They will perform their functions in a manner
analogous to hardwired hardware devices in current
use, and the programming problems associated with
direct control will frequently be segregated from the
rest of the system. As an example of the importance of
this, it has been found that in the development of
large systems for both supervisory and direct digital
control that such major differences in operating systems
are required to support these two control techniques
as to make organization of a system with a combination of them rather difficult and costly. The use of
hidden computers will reduce this problem significantly.
Problem oriented languages
For those users who have applications of some generality, problem oriented languages and systems seem
to be unquestionably the best long term solution to their
software development problems. There is no question
but that a truly general package incurs a penalty in
overhead and excess hardware requirements, but with
the cost trends in hardware which we have discussed,
it will become more and more apparent that this is the
most economical solution. As an example, our
experiences with certain problem oriented packages
have been that they can reduce the programming requirements by a factor of 10 and allow personnel whose
major area of specialty is the application rather than
software to do the programming. This usually results
in a much better control system. Thus, on the belief
Future Trends in Software Development
that what is best for the user will eventually ensue, we predict that for many of them, their problems
will be solved by problem oriented systems which will
very much minimize their requirements for a professional programming staff.
Real-time procedural languages
As we have seen, the major real-time languages in
current use are variants of Fortran. Table I shows
some of the typical extensions which have been made
in Fortran for this application area. It is clear from
examining the length and breadth of these extensions
that if an all-encompassing procedural language based
on Fortran were to be implemented, the base language
would disappear. For this reason, current development
activities are now turning in a different direction.
The general goals of real-time procedural language
TABLE I-Typical FORTRAN Extensions
1 Program & Data Structure
(a) Data types
Fixed point
Bit
Status
Byte
Binary
Boolean (vector)
Octal
Hexadecimal
Alphanumeric
(b) Data manipulation
Shifts
Logical operators
Bit and byte replacement
Character manipulation
String manipulation
Bit testing
2 Communications
(a) Between programs
Global common
External data
Static file system
Dynamic file system
(b) Input/Output
Unformatted input/output
Read write bulk
3 Program control
Schedule another program
Link with interrupt
Delay
Look at clock
Terminate execution
Decision tables
4 Compiler features
Diagnostic trace
Conditional compilation
Reserved words
Code optimization directives
919
development activities under way today are to develop
a language which leads to:
1. Lucidity-the clear expression of what is to
occur when a program is executed, providing a
higher level of self documentation.
2. Freedom from side effects-in a real-time environment a predictable system behavior is ex~
tremely important and real-time programming
languages must be free from side effects.
3. Enforcement of programming discipline-in the
business of producing software, it is clear that
programming discipline is increasingly important. A well designed language will help maintain this discipline.
4. Natural modularity-the language must be constructed so as to make easy increased modularization of real-time systems.
5. Ease of learning and use-it must not require a
major investment in training to put a new language into use, if possible.
Also of particular interest to the designer of a realtime procedural language is the maintenance of a
proper balance between run time efficiency, integrity
TABLE II-Some Functional Requirements for a Real-Time
Language
1. INTERRUPT HANDLING & SYNCHRONIZATION
A. Interrupts
1. Ability to indicate that some program segment is to
be executed upon the occurrence of some particular
interrupt.
B. Events
1. Ability to retain the flow of control at a point in a
computational process until some event has occurred.
2. Ability to cause the occurrence of an event at some
point in a computational process.
C. Synchronization
1. Ability to synchronize parallel computational processes
with security.
II. TASKING
A. By a task on itself.
1. Schedule Execution
2. Find Status
3. Exit
4. Kill
5. Delay
6. Wait
B. On another task
1. Execute
2. Schedule
3. Suspend
4. Delay
5. Terminate
6. Set Priority
7. Find Status
920
Spring Joint Computer Conference, 1972
,- - - - - - -- - - - - - - - --I
r
SOURCE PGM
I
I
I
I
I
I
~I----------.I
~
facilities which it makes available for software debugging. The well designed debugging system for the
software factory will attack three problem areas:
1. Observability-to make more visible the actions
of the program being tested.
2. Controllability-to allow the programmer to
control the flow of control within his program to
suspect control paths.
3. Repeatability-to insure that the same response
occurs from given stimuli, aiding problem
diagnosis.
I
______
r
S£FIY'~RE F~C::!:.o~Y _ _ _ _ _ _ --1
OBJECT PROGRAM
(TARGET MACHINE LANG.)
TI)I
TARGET
COMPUTER
Figure 2-Software factory
of the system and ease of programming. A general set
of functional requirements for a real-time language is
shown in Table II. Whether these languages will be
general purpose6! or dedicated to particular architectures62 remains to be seen.
Software factories
Just as the ultimate elimination of the requirements
do a great deal of custom programming by the use of
special purpose application packages is the ultimate
answer in reducing software costs for the users of realtime automation systems, the development of a unified,
well-designed software will provide the mechanisms for
more economical development of such systems. Figure
2 shows the general nature of such a software factory.
It consists of four major elements; a compiler for a highlevel language for systems software development, a
utility library of building block software modules,
a well organized approach to debugging software produced in the software factory, and a powerful host
computer upon which the system is run.
The general-purpose real-time language described
above will be used with the debugging system to develop the utility library and various application
packages.
Debugging system
One of the major motivations for using a large host
computer for .software production is the more powerful
Table III lists the features generally used in such
a system to achieve these goals.
There is still some disagreement between the use of
source language debugging through compilation to host
machine executable programs, and direct instruction
simulation of the target computer. Each point of view
has merit. The source language execution approach
allows speedier execution and provides for quick
elimination of gross structural errors in the program.
Simulation of the target computer at the instruction
level is generally more expensive because of increased
execution requirements on the host computer, but
allows one to locate more subtle errors, particularly
those with respect to behavior of the target machine
hardware in unusual timing circumstances. (The latter
requires, of course, an extremely sophisticated simulation of the target computer system.) In the future both
techniques will play an important role (References
63-68). (It is interesting to note, however, that the
ultimate distinction may be moot as target machines
come closer and closer to executing high level languages
directly.)
Utility library development
Perhaps the most significant aspect of t his overall
software factory· will be the availability of software
modules for use in building real-time systems. The
TABLE III-Features Required in Debugging Systems
1. Breakpoint removal and insertion
2.
3.
4.
5.
6.
7.
8.
9.
10.
Online variable revision
Insertion and removal of snapshot dumps
Execution initiation or transfer of control to any point
Fault trapping
Incremental addition of new instruction
Variable searches by value
Subroutine call and operating system linkage tracing
Input/output and interrupt simulation
Control of internal timing
Future Trends in Software Development
modules required may be grouped in four categories:
1. System building modules
These modules will form the components of
various language processing systems desired by
the user. With the use of these modules, the
development of special purpose language processors for various applications areas will be
made much more economical.
2. Application modules
Modules of on-line application software will
be available for combination into applicationoriented control software packages. Examples
of these modules will be software for direct
digital control, supervisory control, and realtime data base management.
3. Systems operating modules
Operating systems as we know them today
may very well disappear in the future. Instead,
the various operating system components like
interrupt handlers, generalized input/ output
systems, priority schedulers and executives will
be available for combination as required.
4. User interface modules
Customized user interface modules will be
available for each application area. These
modules will actually include the linkages necessary to combine the library modules and any
specially developed software into a functioning
control system.
SUMMARY AND DISCUSSION
We have examined a number of interesting trends in
real-time software development. Of particular interest
is the three-way interaction foreseen between the
development of new, more powerful architectures for
real-time computers, more powerful high-level programming languages, and the integration of these
programming languages into a more efficient software
production system.
The most interesting technical challenge in this situation is the opportunity to develop languages and
architectures in a unified manner. In the past the designer of computer architectures has been far removed
from consideration of the application requirements,
and his products have been extremely difficult to apply.
The designer of real-time programming languages now
has the opportunity to act as a coordinator in this overall process while insuring that the language fulfills the
functional requirements of the application area hand,
he will coordinate with the compiler developer and
computer architecture designer to insure that the
resultant combination of languages, software factory,
921
and computer form an integrated system for the efficient solution of real-time automation problems.
Exact timing of these trends is very hard to forecast.
Working prototypes of most of the items discussed
exist today. When the economics of the marketplace
are satisfactory, these prototypes will be turned into
smoothly functioning systems for general use. Development of languages and architectures are already under
way. As this work matures the software factory concept
will provide the unifying factor which knits this all
together.
REFERENCES
L6P-30 Royal Precision Electronic digital computer
operations manual
Royal McBee Corp 1959
2 J C SCHOEFFLER
The development of process control software
Proceedings of the 1972 Spring Joint Computer Conference
3
Proceedings of the IEEE-special issue on computers in
industrial process control
Vol 58 No 1 January 1970
4 C L SMITH
Digital control of industrial processes computing survey
Vol 2 No 3 September 1970
5 A S BROWER
Digital control computers for the metals industry
ISA J Vol 12 pp 51-63 February 1965
6 B 0 JENDER
Problems in computer control of bleach plants
Paper Trade J pp 48-50 May 26 1969
7 D S HOAG
Computer control of a Kamyr digester
Presented at the 2nd Ann Workshop on the Use of Digital
Computers in Process Control Louisiana State University
Baton Rouge La March 1967
8 M R HURLBUT et al
A pplications of digital computer control to the cement
manufacturing process
International Seminar on Autom Control in Lime Cement
and Connected Industries Brussels Belgium September 1968
9 T H LEE G E ADAMS W M GAINES
Computer process control: Modeling and optimization
Wiley New York 1968
10 T M STOUT
Where are process computers justified?
Presented at the International Symposium on Pulp and
Paper Process Control Vancouver Canada April 1969
11 T M STOUT
Process control
Datamation 12 2 Feb 1966 pp 22-27
12 T J WILLIAMS
Economics and the future of process control
Automatica 3 1 October 1965 pp 1-13
13 T J WILLIAMS
Computer systems for industrial process control, A review of
progress, needs and expected developments
Proc 1968 IFIP Congress
922
Spring Joint Computer Conference, 1972
14 N COHN et al
On-line computer applications in the electric power industry
Proceedings of the IEEE Jan 1970 Vol 58 No 1 pp 78-87
15
Guidelines and General Information on User Requirements
Concerning Direct Digital Control
Control Instrument Society of America Pittsburgh 1969
pp 251-258 and 259-278
16 H E PIKE
Direct digital control-A survey
23rd Annual ISA Conf and Exhibit N ew York October
1968 Preprint 68-840
17 T J WILLIAMS E M RYAN Eds
Progress in direct digital control
Instrument Society of America Pittsburgh Pa 1969
18 H E PIKE
Process control software
Proceedings of the IEEE Jan 1970
19 H E PIKE
Real-time software for industrial control
In International Computer State of the Art Report RealTime Infotech Ltd Maidenhead Berkshire England 1971
20 R E HOHMEYER
CDC 1700 Fortran for process control
IEEE Trans Indus Electronics & Cont Instmn IECI-15
No 2 p 671968
21 D R FROST
FORTRAN for process control
Instr Technol April 1969
22 J C MECKLENBURGH P A MAY
Protran, a fortran based computer language for process control
Automatica 6 No 4 p 565 1970
23 M MENSCH M DIEHL
Extended fortran for process control
IEEE Trans Indus Electronics and Control Instrm
IECI-15 No 2 p 75 1968
24 M MENSCH W DIEHL
Extended FORTRAN for process control
Presented at the Joint Automatic Control Conf 1968
25 W DIEHL
An integrated hardware/software approach for process
control
Presented at the ISA Conf New York New York 1968
26 W DIEHL M MENSCH
Programming industrial control systems in fortran
IFAP /IFIP Symposium Toronto 1968
27 B C ROBERTS
FORTRAN IV in a process control environment
Presented at the Joint Automatic Control Conf 1968
28
Special issue on computer languages for process control
IEEE Transactions on Industrial Electrons and Control
Instrumentation IECI-15 Dec 1969
29 G W MARKHAM
Fill-in-the-form Programming
Control Engineering May 1968
30
Digital Equipment Corporation Indac 8 DEC Maynard
Mass 1969
31 T G GASPAR V V DORBROHOTOFF
DR BURGESS
New process language uses English terms
Control Eng 15 No 10 p 1181968
32
A UTRAN training manual
Control Data Corp La Jolla Calif 1968
33
1800 process supervisory program (PROSPRO/1800)
(1800-CC-02X) language specifications manual
IBM Corp No H20-0473-11968
34 S M FISCH S J WHITMAN
An application of a process control language to industrial
digital control
Presented at the ISA Ann Conf New York NY 1968
35
Control Data 1700 A UTRAN process control computer
system
Control Data Corp La Jolla Calif 1968
36
BICEPS summary manual/BICEPS supervisory control
GE Process Computer Dept Phoenix Ariz A GET-3539
1969
37
BATCH sequencing system
Foxboro Co Foxboro Mass TIM-R-97400A-504 1968
38 J BRANDES et al
The concept of a process-and-experiment-orientated
programming language
Electronishe Datenverarb'eitung 10 429 1970
39 P A MAY J C MECKLENBURGH
Protol, an Algol based programming language for process
control
Chern Eng J 2 No 3 p 60 1971
40 R TEMPLE J D SCHOEFFLER
A real-time language for computer control software
Systems Research Center Report Case Western Reserve
University Cleveland Ohio 1969
41 R TEMPLE
RTL-A real-time language for computer control software
PhD Thesis Case Western Reserve University
Cleveland Ohio 1969
42 J D SCHOEFFLER T L WILLMOTT
J DEDOUREK
Programming languages for industrial process control
IFAC/IFIP Congress Menton France 1967
43 T L WILLMOTT
A programming lang~age for process control computers
MS Thesis Case Institute of Technology Cleveland Ohio
1967
44 P A MAY
Development of software for real-time computer systems
PhD Thesis University of Nottingham UK 1971
45 J GERTLER
Some concepts on the programming of direct digital process
control systems
Acki Technica Hung 61 No (1-2) p 55 1968
46 J GERTLER
High level programming for process control
Comp J 13 No 1 p 70 1970
47 BCS Specialist Group
A language for real-time systems
Comp Bulletin No 3 p 202 1967
48
T I calculator chip bids to make a wave
Electronics Sept 27 1971 P 24
Future Trends in Software Development
49
50
51
52
53
Workshop on standardization of industrial computer
languages
Purdue University Lafayette Indiana Feb Sept 1969
March Nov 1970 May 1971
L CONSTANTINE
Integral hardware/software design
A multi-part series that appeared in Modern Data from
April 68 through February 69
F S KEELER et al
Computer architecture study
SAMSO report TR-70-420 available from NTIS as
AD720798
C C CHURCH
Computer instruction repertoire-Time for a change
Proceedings of the 1970 Spring Joint Computer
Conference
H WEBER
A microprogrammed implementation of Euler on the
IBM 360/30
CACM 10 1967 549-558
54
55
56
57
58
B6500 information processing system reference manual
Burroughs Corporation Manual #1043676
R RICE W R SMITH
SYMBOL-A major departure from classic software
dominated von Neumann computing system
Proceedings of the SJCC 1971 3, 8 AFIPS Press pp 575-587
C McFARLAND
A language-oriented computer design
Proceedings of the FJCC 197037 AFIPS Press pp 629-640
P S ABRAMS
An APL machine
Stanford Electronics Laboratory-Technical Report
No 3 Feb 1970
T F SIGNISKI
Design of an algol machine
Computer Science Center Report 70-131 University of
Maryland Sept 1970
923
59 G W PATTERSON et al
Interactions of computer language and machine design
Moore School of Electrical Engineering Report No 63-09
University of Pennsylvania Oct 1962
60 R W DORAN
Machine organization for algorithmic languages
Proceedings of the International Computing Symposium
Bonn Germany May 1970 pp 364-376
61 F J CORBATO
PL/I as a tool for system programming
Datamation 15 1969 pp 68-76
62 N WIRTH
PL/360-A programming language for the 360 computers
Journal of the Association for Computing Machinery
Vol 15 #1 Jan 1968
63 D T ROSS
The AED approach to generalized computer-aided design
Proceedings of the 1967 ACM National Meeting
pp 367-385
64 D T ROSS
Fourth generation software: A building-block science replaces
hand-crafted art
Computer Decisions April 1970
65 R M SUPNIK
Debugging under simulation
Applied Data Research Inc Princeton N J
66
MIMIC user's guide-PDP-ll
Manual CSD 03-70411M-00 Applied Data Research Inc
Princeton N J
67 M L GREENBERG
DDT: Interactive machine language debugging system
reference manual
NTIS Report AD707406
68 W KOCHER
A survey of current debugging concepts
NASA report CR-1397 available from NTIS as N69-35613
Scheduling of time critical processes
by OMRI SERLIN
SYSTEMS Engineering Laboratories
Fort Lauderdale, Florida
INTRODUCTION
allocation policies that satisfy the requirements of
multiple time-critical processes (TCPs) .'These processes,
arising naturally in real-time environments, are computational procedures bound by hard deadlines. A process bound by a deadline must, once initiated, complete
its computation on or before the specified deadline. A
hard deadline implies that a failure to meet it results
in an irreparable damage to the computation. Such
deadlines are typically due to stability and accuracy
considerations in the process being controlled (e.g., the
analog computation portion of a hybrid system).
An efficient CPU allocation algorithm is one that
guarantees to each TCP sufficient processor time to
complete its task before its deadline, while minimizing
forced idle CPU time. By "forced idle time" is meant
the time during which the CPU must remain idle in
order to accommodate the occasional worst-case condition. This constraint is essential if the problem is to be
non-trivial.
A basic assumption underlying this study is that all
TCPs are preemptible.
Time-critical processes are most commonly initiated
by the occurrence of external events (interrupt signals).
Time-of-day or elapsed-time prompting of these processes may be regarded as special cases of the general
class of external events. These events, and the associated TCPs, may be further classified as periodic or
In real-time applications, the computer is often required
to service programs in response to external signals, and
to guarantee that each such program is completely
processed within a specified interval following the occurrence of the initiating signal. Such programs are
referred to in this paper as time-critical processes, or
TCPs.
A problem of considerable practical significance in
connection with such applications is that of devising
scheduling algorithms for servicing multiple time-critical
processes. The primary objective of any such algorithm
is to guarantee that each TCP can be processed within
its allowed interval, taking into account the possible
activities of other TCPs. It is clear that, assuming an
upper limit can be placed on the repetition rate of the
prompting signals, this objective can always be met if,
for example, each TCP executes in a separate, sufficiently fast CPU; or, if a single CPU of some high, but
finite, execution speed is furnished. Either approach is
wasteful in the sense that the CPU (or CPU's) must
sometimes remain idle in order to allow for some
"worst-case" condition that occasionally may obtain;
for example, when all interrupts occur simultaneously.
Thus the scheduling problem becomes non-trivial only
if additional constraints are imposed. Two such practical
constraints are that only one CPU is available, and
that the processor idle time is to be minimized.
This paper examines four specific scheduling policies,
subject to these constraints, and outlines some of the
more interesting properties of each.
asynchronous.
The TCPs to be serviced are assumed to form an
unordered set, that is, they are not interrelated by
precedence rules. This assumption is consistent with
the premise that the TCPs are initiated by unrelated
external signals. If a TCP calls on other tasks, then
such secondary tasks can be regarded simply as chronological extensions of the calling TCP, either because
the called task is private to the calling TCP, or because
all shared tasks are reentrant. In fact, the concept of
precedence rules is relevant only in the case of scheduling for multiprocessor systems (Ref. 3). Multiprocessor
configurations, however, seem to offer no advantages in
DEFINITIONS
Time critical processes
In the context of computing systems, time critical
scheduling is the problem of devising efficient CPU
925
926
Spring Joint Computer Conference, 1972
,-- -
•
I
C
..
INTERRUPTS
4-
C
I
I
d
T
-
-
-
-
I
+
I
~
Figure I-A model of a time critical process (TCP). The
parameters associated with the TCP are the deadline (d),
repetition period (T), and required CPU time (C)
the implementation of time critical schedules of the
type discussed here. This subject is discussed later.
Note, incidentally, that the grouping of interruptdriven processes into entities called jobs is primarily a
bookkeeping measure. Such groupings carry certain
implications as to the sequence of events before and
after the time critical phase of the operation; they are
of interest to the loader and accounting mechanisms.
From the scheduling viewpoint, however, TCPs are
independent entities; it does not matter whether all belong to a single user ("job") or whether sets of one or
more TCPs each belong to one of several users.
TOP models
Figure 1 is a model of a simple TCP, depicting its
repetition period (T), deadline (d), and required compute time (0). The required compute time is the maximum time required to completely process the given
TCP on a given CPU, assuming no interruptions. That
is, 0 is the amount of CPU service, in terms of CPUseconds, required by the TCP. Evidently, 0 depends
on the number and type of executable instructions in
the TCP and the speed of the processor. The required
compute time may be obtained empirically by timing
the process running alone, or it could be predicted by
deriving, through such procedure as the Gibson mix, an
average instruction execution time for the processor
and multiplying this figure by the instruction count of
the given process.
A basic assumption underlying the study of TCP
scheduling is that the external world is insensitive to
the actual time at which the process is executed, so
long as the process receives 0 CPU-seconds somewhere
between the occurrence of the associated interrupt and
the deadline. This is typically achieved by incorporating
in the process predictive algorithms that extrapolate
the results computed from data obtained at time ti to
ti+d, when these results are actually transferred out of
the computer.
T is the repetition period, i.e., the period between
successive occurrences of the interrupt signal associated
with the process. In practice, TCPs often are periodic
and have d = T = constant; i.e., the constant repetition
period and the deadline are identical. The repetition
period is often called the frame time. Typical asynchronous TCPs have d < T, and T is variable. N evertheless, these processes may still be represented by the
model of Figure 1, as the following considerations show.
I t must be possible to define for an asynchronous TCP
a minimum T; for if this cannot be done, then either
the process cannot be time-critical-namely, it cannot
be bound by a hard deadline-or else a processor of infinite execution speed is required. Hence, in the discussions to follow, T is taken to mean either the constant
repetition period of a periodic TCP, or the minimum
time between interrupts for an asynchronous process.
It is generally necessary to assume that TCPs can
become active, either periodically or asynchronously,
at unpredictable times. Furthermore, it is necessary to
assume that no special relationships exist between or
may be imposed on the frame times and compute times
of the various processes. In practical situations, however, the resolution of the system's timing mechanisms
may dictate that all Ts and Os be integer multiples of
some basic time unit, so that all Os and Ts are mutually
commensurable. This property can be quite significant
in devising realistic schedulers.
As a rule, time-critical processes require the input of
external data before they may proceed, and must allow
some time after their completion and before the occurrence of their next interrupt for computed date to be
output to external devices. Figure 2 is a model of a
TCP of this type. A simple re-definition of the repetition period and deadline (T' and d' in Figure 2) transforms this type to the basic model of Figure 1. This
transformation notwithstanding, consideration of I/O
requirements complicate the scheduling problem, as
will be pointed out later. It is assumed that, apart
from an initial input and a final output operations,
TCPs do not perform I/O.
I- - - - -
•
bc=
I
,
--,
I
_INTERR.UPTS_ -
•
•
c
d'
II
I 10 I
T'
~
c
J
Figure 2-A TCP with I/O. By transforming the deadline into
d' and the repetition period into T' this TCP is made to conform
to the basic TCP shown in Figure 1
Scheduling of Time Critical Processes
927
Load factor
The load factor (L) of a given process is equal to
CIT, the ratio of the required CPU time to the repetition period. The load factor is a measure of the CPU
load represented by the given TCP. Because the load
factor can be readily defined in terms of quantities
that are private to a given TCP and are easily obtained, it is natural to seek to establish a clear relationship between the individual load factors and the total
CPU load. For instance, it is clear that in the global
sense-i.e., over a very long period compared to all the
frame times-the sum of the load factors approximates
the total CPU load; hence, the condition
L> 1 is
sufficient to guarantee the failure of all scheduling
policies. On the other hand, the condition
L:::; 1 is
not sufficient to guarantee success, as will be demonstrated shortly. An efficient scheduler will maximize the
sum of the load factors without violating any deadlines.
L:
L:
Overhead
Overhead is the time required to switch the processor
state from one TCP to another. In the following discussions, overhead is assumed to be zero. For that
reason a more detailed definition of overhead, which
takes into account the variety of possible hardware and
software configurations affecting it, is unnecessary. In
many practical cases the assumption of zero overhead
is a good first approximation, since the state switching
time is indeed small compared to the frame times.
THE INTELLIGENT FIXED PRIORITY
(IFP) ALGORITHM
In the most commonly used scheduling technique,
each TCP is assigned a fixed priority at the time it
enters its time-critical phase-that is, when its associated interrupt is armed and enabled. If the priority
levels are such that processes having shorter deadline
intervals receive higher priorities, the algorithm is termed
"intelligent" fixed priority, to distinguish it from other
fixed-priority systems in which the allocation of priority
levels is based on other criteria. This should not be
taken to mean that the choice of such other criteria is
unintelligent; for example, a scheduling policy based on
no priorities ("round robin"), or one in which "CPU
hogs" receive low priorities, can be quite effective in
time sharing environments or in multiprogrammed
batch systems. For the time-critical environment relevant to this discussion, the allocation of priorities based
on the relative lengths of deadlines is most appropriate.
Priorities under IFP need not be truly fixed. In a
TCP1
TCP2
TCP3
TCP4
~
•
I
r•
~
If
T1~1
~
T2
(C;l
I•
T3
C
4
T4
I
•
C2
~
•
~
•
Figure 3-Assumed worst case under IFP. Four TCPs are shown,
satisfying the conditions that are considered "worst-case" :
(a) all interrupts occur simultaneously; (b) the frame times are
so related that the CPU must process all TCPs completely
within the shortest frame time
multi programmed real-time system, groups of TCPs
("jobs") may enter and leave the system at arbitrary
times; the priority structure must be adjusted occasionally in response to such changes in the relative
deadlines. Also, real-time processes often go through
pre- and post-time-critical phases, during which their
priorities may be much lower than the ones they assume
in their time-critical phase, again suggesting a dynamic
readjustment.
An important property of IFP, which has been
alluded to in References 1 and 2 but heretofore not
substantiated, is that the permissible sum of the load
factors must be considerably less than 1 in order to
guarantee that each TCP meets its deadline. The higher
the number of TCPs to be scheduled, the closer this
permissible sum gets to loge 2=0.693. In other words,
under IFP, more than 30 percent of the CPU power
must remain idle. The following is a sketch of the proof.
Assume there are n TCPs, all with constant frame
times, and that, at one instant, all of their interrupts
occur simultaneously. The CPU at that time is required
to provide maximum service in minimum time, so that
this condition represents the worst possible case. Furthermore, assume that the frame time of each TCP is
related to the next shorter one by T i = T i-1 + Ci-1
where T i - 1 < T i <2Ti- 1
(See Figure 3) .
~nd
di = Ti or d i =
t
j=1
Cj
928
Spring Joint Computer Conference, 1972
These conditions assure that the CPU will be 100
percent busy during the longest frame time Tn following the simultaneous occurrence of the interrupt signals.
We wish to establish the set of T i , Ci that lead to the
smallest possible sum of the load factors, i.e., the
largest possible forced CPU idle time.
Normalize the frame times by letting Tl = 1. Designate the sum of the load factors by z. Then
rhis represents both the required compute time and
load factor for TCP 1 under the "worst case" condition
of Figure 3 with the side constraint of worst (minimum) load-factor sum. The other TCPs have
Ci = Si-I/ Si_2 2- Si-l
Z=C1+C2/(I+C 1) +C3/(I+C 1+C2) + ... +Cn/
The load factor Li of each TCP i is Ci/ T i where T = Si-l;
so
Li= [(8 i_12/ Si-2) - Si-IJ/ Si-l = C1
By continual substitution, we have
Si= (I+C 1)i
(I+C1+C2+··· +Cn- 1)
Because of the assumptions (see Figure 3),
so all the load factors equal C1• Thus the sum of the
load factors is
z=n(21/n-l)
n
L: C =1
j
j=1
Note, incidentally, that the frame times for this worstcase core given by
Let
Ti = Si-l = (1 +C1) i-I = 2 (i-1) In
The table below summarizes the worst-case situation
for two, three and four TCPs.
where L is a Lagrange multiplier used for convenience
to obtain symmetry in the following equations. Also let
n
1+
L: Cj=Si.
j=1
We wish to find the conditions leading to the minimum z. Hence:
aj/ac1= 1-C2/ SI2-C3/ 8 22 - ••• -Cn/Sn_12+ L =0
aj/ac2=
aj/ac3=
1/ SI-C3/ 8
2
2 -
1/82 -
1/ Sn_l-Cn/ Sn_l+L=O
aj/acn=
I/S n_1+L=0
By subtracting each of these equations from the one
above it we obtain
Sn = 8 n_12/ 8 n- 2
z (max. L)
2
3
4
2 ( V2 -1 ) "'82.8 percent
3 ( ~2 -1) "'78.0 percent
4( {l2-1) "'75.7 percent
T relationships
I:V2
1:~2:~4
1 :{l2: {l4:{l8
To establish the trend as the number of TCPs increases, we take the limit of z as n approaches infinity:
2
••• -Cn/Sn_1 +L=0
••• -Cn/Sn_12+L=0
aj/acn- 1=
n
lim n(21/n-l) =lim n[1 + In2/n+ (In2/n)2/2!
n-+oo
n-+oo
+ (In2/n)3/3!+··· -lJ
= loge2 = .69315
thereby substantiating the original assertion. Figure 4
l: L
Sn-l = Sn_22/ 8 n- 3
In 2
where the last equation is obtained from
aj/acl -aj/aC2= 1-C2/(1+C 1)2_1/(1+C1 ) =0
Continual upward substitution in the above set leads to
I+C1+C2+··· +Cn= (1+C)2(n-1) / (1 +C)n-2
The left hand side of the equation above equals 2 since
Sn=l; hence
so that
2
3
fIIO.O
Figure 4-Load factor sum as a function of the number of TCPs
under IFP. As the number of TCPs increases, the CPU must
remain idle a larger percent of the time (i.e., the permissible sum
of the load factors must be reduced). In the case of many TCPs,
about 30 percent of the total CPU power must be held in reserve
to accommodate the worst-case ccndition
Scheduling of Time Critical Processes
TCP1
bu
+ - - T1
TCP2
..I
b
b bu
-.-..
C
2
C
C
2
2
T2
I
•
Figure 5-Worst case situation for two TCPs under IFP when
the condition Tl 1 and is an integer. Also,
C2=m(TI-Cl )
hence the sum of the load factors is
z = CI/Tl +m( T l - C1 ) /kTI
=k-m+m(l-k+m)/k
For a minimum z we require
929
drops to its minima always when Tl and T2 are mutually
incommensurate.
EFFECT OF I/O
It was pointed out earlier that TCPs with nonzero
I/O times can be transformed to the model of Figure 1.
Such a transformation does not, however, remove a
basic difficulty associated with I/O: during the input
or output phases of a given TCP, the CPU may not be
allocated to it. During the time that the I/O operations of all TCPs overlap, the CPU may not be allocated to any. For example, with two TCPs of identical
repetition periods T and equal input-output phases I,
the maximum permissible sum of the load factors is
(T - 21) /T. This difficulty may be further complicated
by the need to schedule the I/O operations that use
the same I/O facilities.
Assuming, however, that all I/O operations can be
performed simultaneously, one possible approach to incorporating the effect of I/O in CPU scheduling policies
may be as follows. Regard I/O as a TCP with d i =
Ti= Ci, which is always executed on a second, "dummy"
CPU. Furthermore, introduce precedence rules enforcing the sequence Ii T I , the deadline of TCP 2, d 2, can
occur in the frame TI at most once. Now d2 cannot
occur in the interval tlt2 since this means that the CPU
is idle for some time in that interval; the only exception
occurs if d2 = T 2, (since then the CPU can work for
TCP2 in the remainder of tl t2 ) ; or if d2 always coincides
with either tl or t2, or if d2 always falls in the interval
totl' To maintain these restrictions it is necessary that
any two occurrences of d2 must be separated by mTI ;
therefore T 2 =mTI •
I t is tempting to conclude that this condition can be
extended to the case of more than two TCPs by requiring di = Ti for all i or Ti=miT I . A proof is not yet
available, however.
Note that the scheduling property just derived is not
responsible for the failure of IFP to schedule more than
about 69 percent of the CPU (Figure 3) ; the development of that case remains unchanged if in Figure 3 we
let all di = T i. Thus this failure is peculiar to IFP and,
in fact, we will show later th~t for d i = T i , the relative
urgency (RU) and other algorithms do not suffer
from this restriction.
THE MINIMAL TIME SLICING (MTS)
ALGORITHM
In implementing ITS, AT is assumed to be infinitely
small. For any given set of TCPs, a time slicing algorithm which retains most features of ITS with a finite
AT can be developed. This is the minimal time slicing
(MTS) policy. It is based on the realization that, for
a given set of TCPs, the smallest time unit of interest
Scheduling of Time Critical Processes
d
n
...-t
~t---
Figure ~- ?-,he MTS policy in a scheduling intervaL In every
schedulmg mterval At, the CPU is allocated in some arbitrary
order to all TCPs, such that each receives LiAt CPU-seconds
from the scheduling viewpoint, called a scheduling
interval, is the time between the occurrence of two successive "scheduling events." By "scheduling events"
;ve mean events that affect the CPU loading; namely,
Interrupt instances and deadlines. The scheduler can
guarantee that each TCP meets its de aline by allocating
the CPU, in each scheduling interval, in some arbitrary
order, according to the load factors. Figure 8 is a
graphic illustration of this policy. The practical implementation of MTS requires all TCPs to be periodic so
their interrupt instances are predictable.
MTS suffers from the same weakness as ITS in
scheduling processes for which diT1) with di=T i, whose interrupts coincide at t = O. Construct an MTS for this
case, taking care to, in each scheduling interval, assign
the CPU to the TCP whose deadline is nearest. No
generality is lost since the order is immaterial under
MTS. ~et an RU be constructed, and assume that up to
scheduling event L, RU and MTS are indeed identical.
Consider the event at L and the one following it. There
are only three possibilities (see Figure 9) : a) at L we
have II (interrupt due to TCP 1) and the next event
i~ also t1, b) L = t1, then t2; c) L = t2, then t1. Note that,
SInce T2> T 1, it is impossible to have two consecutive
t2 without an intervening t1. Now, for the case (a),
under RU we would allocate the CPU at L to TCP 1
(its deadline is nearest); it would execute for L1T1
seconds, since the interval M1 is T 1• Since the CPU is
assumed 100 percent scheduled, the remainder of t1t1,
namely T (1- L 1 ) would be allocated to TCP 2. Since
L 1+L2=1, L2=I-L1' so this remainder equals L 2T 1.
(a)
L
t ........- -
THE RELATIVE URGENCY (RU)
ALGORITHM
The Relative Urgency (RU) policy, developed by
M. S. Fineberg and first reported in Reference 1, is
similar to MTS in that it requires the scheduler to reevaluate the scheduling environment on every interrupt. RU differs from MTS in that during the period
between two successive interrupts, RU is priorityoriented: the highest priority TCP is given control at
the start of that period, and allowed to continue until
it completes its computation or until the next interrupt.
Priorities are re-allocated on every interrupt and are
proportional to deadlines as they exist at the interrupt
instance (i.e., not simply to their relative lengths) ; the
931
~t
1
(b)
-4--
~t
----+
(c)
Figure 9-Nomenclature for the proof that MTS and RU are
equivalent for two TCPs. The proof is by induction, assuming
that up to scheduling event L, RU and MTS are identical, and
showing that based on this assumption, RU and MTS must also
be identical in the interval At
932
Spring Joint Computer Conference, 1972
This is precisely the division of tlt l, under MTS. For
case (b), TCP 2 will receive the CPU, and is short
exactly L21lt CPU-seconds, since by the assumption it
received L 2 (T2 -IlT) CPU-seconds up to event L. This
leaves Ilt (1- L 2) for TCP 1 in Ilt, which is equal to
Lillt, again showing the equivalence of RU and MTS
in Ilt. Similar conditions apply in case (c). Finally, at
t = 0 we have case (a) (with L = tl = t2) but for this
case we already showed that RU =MTS. Hence the
assertion is proved by induction.
There is considerable empirical evidence that RU is
capable of scheduling the CPU at 100 percent efficiency
for all Ti/T i - l ratios when all di = T i ; in this case, RU
is at least as efficient as MTS or ITS (more efficient in
fact, due to lower switching overhead) ; when the Ti are
not integer multiples of TI (the shortest frame time),
IFP is known to be less efficient than either MTS, ITS
or RU. When di < T i , RU is capable of scheduling more
of the CPU than MTS or ITS, i.e., more TCPs can be
accommodated under RU.
number of TCPs n is not a multiple .of the number of
CPUs m, there will remain one TCP that cannot be
accommodated within Ilt using m processors, whereas
the fast processor accommodates all TCPs within Ilt.
Furthermore, if Grosch's Law holds, the faster CPU
should cost less than the m slower units, so that even
from the economic standpoint, multiprocessor systems
do not appear desirable.
CONCLUSION
This paper presented primarily heuristic extensions and
generalizations of concepts that were for the most part
first sketched in Reference 1. Much work remains to be
done in strengthening and extending the proofs and in
discovering the properties of scheduling with I/O constraints. The relation between RU and MTS is particularly intriguing. A consistent theory of scheduling of
time-critical processes is within reach.
ACKNOWLEDGMENT
REGARDING MULTIPROCESSING
Considerable effort has been expended on timecritical scheduling techniques for multiprocessor systems (e.g., References 3 and 4). For TCPs of the type
considered in this paper, multiprocessor systems do not
offer any advantages (if one excludes redundancy or
backup requirements). In fact, it appears that in some
cases, multiprocessor systems are definitely less desirable than an "equivalent" single processor. By "equivalent" is meant that each of m CPUs execute at a rate
l/m as fast as the single CPU.
Given m processors and n TCPs (m < n) with equal
Ci and such that all n TCPs can be executed serially
on the single, fast processor in time Ilt. Then each of the
m processor can completely process at most p TCPs,
where p is an integer that satisfies p (Ilt/ n) m <: Ilt. In
other words, mp <: n, which means that whenever the
I am indebted to the referees for their excellent, constructive critiques of the original version of this paper.
REFERENCES
1 M S FINEBERG 0 SERLIN
Multiprogramming for hybrid computation
Proc AFIPS FJCC 1967
2 0 SERLIN
CPU scheduling in a time critical environment
Operating Systems Review June 1970 (pub by ACM
SIGOPS)
3 R R MUNTZ E G COFFMAN
Preemptive scheduling of real time tasks on multiprocessor
systems
JACM Vol 17 No 2 April 1970 pp324-338
4 G K MANACHER
Production and stabil izaUon of real time task schedules
JACM Vol 14 No 3 July 1967 pp 439-465
A class of allocation strategies inducing hounded
delays only
by EDSGER W. DIJKSTRA
Technological University
Eindhoven, The Netherlands
We consider a finite set of persons, say numbered
from 1 through M, whose never ending life consists of
an alternation of eating and thinking, i.e., (in the first
instance) they all behave according to the program
basis of "first come, first served"-and we shall
not mention these local delays any further,
because they are now irrelevant for the remainder of our considerations.)
(2) as a result of such an inspection the person
invoking it may be put to sleep (i.e., prevented,
for the time being, from proceeding with his life
as prescribed by the program) .
(3) as a result of such an inspection, one or more
sleeping persons may be woken up (i.e., induced
to proceed with their life as described by the
program).
cycle begin eat;
think
end.
The persons are living in parallel and their common
accommodations are such that not all combinations of
simultaneous eaters are permitted. As a result: when a
person has finished thinking, some inspection has to
take place in order to decide whether he can (and shall)
be granted access to the table or not. Similarly, when a
person leaves the table, some inspection has to take
place in order to discover whether on account of the
changed occupancy of the table one or mQre hungry
persons could (and should) be admitted to the table.
This situation is reflected by writing their program
We restrict ourselves to such exclusion rules for
simultaneous eaters that
condition 1: if V is a permissible set of simultaneous
eaters, so is any subset of V
condition 2: each person occurs in at least one permissible set of simultaneous eaters. (Note:
if a person occurs in exactly one permissible set of simultaneous eaters, this set
contains-on account of condition I-only
himself and no one else.)
cycle begin ENTRY;
eat;
EXIT;
think
From condition 1 it follows that there is no restriction
on the set of simultaneous thinkers; as a result the
inspection EXIT will never have the consequence that
the person invoking it will be put to sleep. As a result,
persons can only be sleeping on account of having
invoked the inspection ENTRY and the act of admitting person i to the table can be associated with the
waking up of person i. (A little bit more precise: if
during the inspection ENTRY as invoked by person i
the decision to admit him to the table is not taken, he is
put to sleep, otherwise he is allowed to proceed. If in
any other inspection the decision to admit person i to
the table is taken (person i must be sleeping and)
person i will be woken up) .
end
with the understanding that
( 1) all inspection processes' 'ENTRY" and "EXIT"
take only a finite period of time and exclude
each other in time. (As a result of the postulated
mutual exclusion of the inspections "ENTRY"
and "EXIT," a "local delay" of person i,
wanting to invoke such an inspection, may be
needed. We postulate that such a "local delay"
will only last a finite period of time-the requests
for these inspections could be dealt with on the
933
934
Spring Joint Computer Conference, 1972
Furthermore we restrict ourselves to the case that
condition 3: for each person the action "eat" will take
a finite period of time (larger than some
positive lower bound and smaller than
some finite upper bound) ; this in contrast
to the action "think" that may take an
infinite period of time.
In the simplest strategy no inspection will leave a
person sleeping whose admittance to the table is allowed
as far as the occupancy of the table is concerned. Alas,
such a strategy may have the so-called "danger of
individual starvation," i.e., although all individual
eating actions take only a finite period of time, a person
may be kept hungry for the rest of his days. (The
classical configuration showing this phenomenon is the
Problem of the Dinig Quintuple. Here five places are
arranged cyclically around a round table and each of
five persons has his own place at the table. The restriction is that no two neighbors may be eating simultaneously. The rule will then be that every person is
admitted to the table as soon as he is hungry and none
of his two neighbors is eating. In this particular
example this rule leaves no choice, i.e., when I leave the
table the decisions whether my lefthand neighbor and
my righthand neighbor have to be admitted to the
table are independent of each other. In this example my
two neighbors can starve me to death, viz., when my
eating lefthand neighbor never leaves the table before
my righthand neighbor is eating and vice versa. If the
remaining two persons remain thinking, access to the
table will never be denied to my neighbors and with me
hungry the process can continue forever.) The moral of
the story is that if we are looking for strategies without
the danger of individual starvation, we must in general
be willing to consider allocation strategies in which
hungry persons will be denied access to the table in
spite of the circumstance that the occupancy of the
table is such that they could be admitted to the table
without causing violation of the given simultaneity
restrictions. Our interest in strategies without the
danger of· individual starvation was aroused by the
sobering experience that quite a few intuitive efforts to
exorcize this danger led to algorithms that turned out
to be quite ineffective because they could lead to
deadlock situations. The remaining part of this paper
deals with a general characterization of strategies that
do not contain the danger of individual starvation. We
shall restrict ourselves to strategies where the decision
to admit persons to the table will be taken for one person
at a time; from our analysis it will follow then that our
characterization can be given independent of the
specific simultaneity restrictions (provided of course
they satisfy our stated conditions 1 and 2).
We start by proving a theorem, in which we consider
the following (possible) properties of a strategy.
property A: the existence of at least one sleeping person
implies at least one person who is eating
or leaving the table
property B: for any person i it can be guaranteed that
during a period of his hungriness the
decision to admit someone else to the table
will not be taken more than N i times,
where N i is a given, finite upper bound
for person i.
Our theorem asserts that when conditions 1, 2 and 3
are fulfilled, properties A and B are the neceseary and
sufficient conditions for any strategy in order not to
contain the danger of individual starvation.
The necessity of property A follows from the inadmissibility of the situation in which one or more
persons are sleeping while all remaining ones (if any)
are thinking. The thinking ones may go on thinking
forever, as a result no new inspections will be evoked
and the sleeping ones remain hungry for an infinite
period of time.
We say that the danger of individual starvation is
absent when the hungriness of any person will never
last longer than a given, finite period of time. The
minimum time taken by the act of eating imposes an
upper bound on the personal frequency with which
any given person can be admitted to the table; the total
number of persons is M and therefore there is an upper
bound on the total frequency with which someone is
admitted to the table. Therefore the number of admissions during a period of hungriness of person i must
always be less than a fixed, finite value: property B is
necessary in the sense that a set of fixed, finite N/s
exists such that it is satisfied.
N ext we show that the conditions are sufficient.
When person i becomes hungry-by invoking
ENTRY-we have to show that his hungriness will
only last a finite period of time. If in the course of that
very inspection he is admitted to the table, it is true
(for inspections take only a finite period of time),
otherwise he goes to sleep. At the end of that inspection
at least one person is eating (on account of property
A). From the fact that the action "eat" takes only a
finite period of time, the persons now eating will have
finished doing so and will have left the table within a
finite period of time. From this and property A it
follows that within a finite period of time a new person
will have been admitted to the table. The assumption
A Class of Allocation Strategies
that person i remains hungry forever implies that the
lucky person must have been someone else, i.e., within a
finite period of time the number of times it has been
decided during hungriness of person i that someone
else is admitted to the table is increased by one. Then
the argument can be repeated and within a finite period
of time the number of times someone else is admitted
to the table would exceed N i , contrary to our property
B. Therefore person i will not remain hungry forever.
Having established that properties A and Bare
necessary and sufficient for the absence of the danger
of individual starvation, we are now in a position to
characterize all strategies satisfying them with a priori
given bounds N i • For this purpose we associate with
each hungry person a counter called "ac" (short for
"allowance count"). Whenever person i becomes
hungry, his ac is added to the set of ac's with the initial
value=Ni ; whenever it is decided that a person is
admitted to the table, his ac is taken away from the set
of ac's and all remaining ac's are decreased by one.
Property B is guaranteed to hold when no ac becomes
negative.
We call the set of ac's "safe" when for all k 2:: 0 holds
that at most k ac's have a valuem2.
The importance of such a policy is twofold: not only
does it imply each program operates in a known range
of processing efficiency, but it allows a system designer
to determine bounds on the paging traffic generated
by a given statistical mix of active programs. The
policy determines a sequence of times tOtlt2 ... ti ...
such that Ti=ti-ti-l is the ith value of window size
and (t i- l , ti) is the ith "sampling interval." During the
ith sampling interval the program is run under a working set policy with window size T i , the number Pi of
pages entering the working set during that interval is
counted, and PilTi serves as an estimate for the missing
page rate m(Ti) during that interval. If PilTi exceeds
ml then Ti was too small and Ti+l is set to a value larger
than T i ; if PilTi is in the range ml to m2, Ti+l is the
same as T i ; and if PilTi is smaller than m2 then Ti is
too large and T i+1 is set to a value smaller than T i .
By virtue of the relation between the working set
model and LRU paging, one can approximate the foregoing procedure using LR U paging in a memory space
seT)
k
+-------------~
941
whose size is varied from time to time. In this case,
T is taken as a fixed sampling interval (e.g., a time
slice), P the number of page faults in the previous
sampling interval, and piT the estimate of page fault
rate. If piT exceeds ml, the program is allocated one
additional page of memory during the next sampling
interval (this page being filled on demand at the next
fault); if piT is in the range ml to m2, the memory
allocation is unchanged; and if piT is smaller than m2,
the memory allocation is reduced one page during the
next sampling interval (the least-recently-used page
being removed). This process is repeated for each
sampling interval. During each interval the memory
space allocation is fixed and LRU paging is employed.
At any time the contents of memory serve as an estimate
of the working set.
It is important to note that, if the LRU approximation to the working set principle is used in a multiprogrammed memory, a page fault generated by a
program causes a page to be replaced from that program's own working set but never from another program's working set. Put another way, the LRU
algorithm is applied on a "local" basis but not on a
"global" one. Thus a program's missing-page rate
depends only on its own behavior and never on that of
another program: its working set survives intact despite
the paging activities of other programs with which it
shares main memory.
DISTRIBUTION OF WORKING SET SIZE
It can be shown17 that whenever the third property
L3 of locality holds-reference substrings tend to
become uncorrelated as the interval between them
becomes large-the working set size is approximately
normally distributed about its mean s (T). Suppose
w (t, T) is a working set size process with mean sand
variance 0-2• The normal approximation for the distribution of w (t, T) asserts that, for large t,
(x-s)
(9)
e-u2 / 2 du
(10)
Pr[w(t, T) ::;x] = «P ----;-
where
cp (x) =
meT)
Figure 5-Estimating LRU paging rate
1
-----
(211") 1/2
jX
-00
is the cumulative distribution of a normally distributed
random variable with zero mean and unit variance.
The ability to consider w (t, T) as a normally distributed random process is of key importance, in view
of the enormous literature and theory extant about
such processes. 8
942
Spring Joint Computer Conference, 1972
Safeness
o L---t_ _ _ _ _ _ _ _ _ _ _ _ _
---I~
(J
Figure 6-Safeness of fixed and variable partitioning
Two deviations are inherent in the use of the normal
approximation to the distribution of working set size:
the normal distribution is continuous whereas working
set size is discrete, and the normal distribution is
defined for negative values. The first deviation is not
significant for programs whose working set size varies
over a wide enough range of values] and the second is
not significant for most parameter values (s and (]')
of interest.
The normal approximation has been found remarkably accurate when the correlation property (L3) of
locality holds. 8 If this property fails to hold (e.g., the
program contains a global loop), it will be possible to
predict arbitrarily distant future reference patterns on
the basis of present ones and significant deviations from
the normal approximation win be observed. 25
menting variable partitioning is more than adequately
compensated by the saving in memory requirement. 8
Under the assumption that n programs whose memory
demands are normally distributed working set processes
with the same mean s and variance (]'2, Coffman and
Ryan compared a fixed partition and a variable partition strategy with respect to a "safeness factor" as a
performance measure (the safeness factor is related to
the volume of paging and overall efficiency). In both
cases the total mount of main memory was M pages.
In the fixed partition case, each program is allocated a
block of b pages and the total memory capacity is
M =nb; a block is considered safe (unsaturated)
whenever the instantaneous value of working set size
for the program using that block does not exceed b,
and the multiprogrammed memory is considered safe
whenever all the blocks are safe at the same time. In
the variable partition case, each program is allocated an
amount of space equal to its working set size; this
system is considered safe if the sum of the working set
sizes does not exceed the memory capacity M. The
values of S" the safeness factor for fixed partitioning,
and Sv, the safeness factor for variable partitioning, are
readily determined under the assumption of normally
distributed working set size. The results are suggested
in Figure 6. Whenever the variance 0"2 of working set
size is small enough so that the block size b is at least
s+20" [equivalently, 0" is less than (b-s)/2J, the two
strategies are competitive; but when 0" becomes large,
the variable partition strategy is considerably safer
than the fixed partition strategy.
Under the assumption of variable partitioning and a
working set memory management policy, it is possible
to specify the equipment configuration (relative
amounts of processor and memory resources) of a
computer system. 14
CONCLUSIONS
FIXED VERSUS VARIABLE PARTITIONING
OF MElVIORY
The strategies for allocating main memory, under
multiprogramming, usually lie near one of two extremes.
According to the fixed partition strategy, each of the
programs sharing the memory is allocated a fixed
amount of memory for its private use. According to the
variable partition strategy, the amount of space allocated
to each program depends on its working set size. The
principal argument advanced for fixed partitioning is
simplicity of implementation; a recent study by Coffman
and Ryan, however, suggests that the cost of imple-
Originally introduced as a means of understanding the
vagaries of multi programmed memory management,
the working set model has proved useful both as an aid
for guiding one's intuition in understanding program
behavior, and as a basis for analyses and simulations of
memory problems. To summarize: it has led to a
sharpening of the notions "working information" and
"locality of reference" ; it has aided in the development
of multiprogrammed memory management strategies
which guarantee each program a given level of efficiency
and which prevent thrashing; it has quantified the
relationship between memory demand and paging rate;
it has led to better understanding of paging algorithm
On Modeling Program Behavior
behavior in both demand and prepaging modes; and it
has enabled preliminary analysis of fixed v. variable
partitioning of multiprogrammed memories and of
system equipment configurations. Approximations to
the working set principle have been used successfully
in many contemporary systems both large and small,
demonstrating the viability of the model: systems reporting success include the RCA Spectra 70/46,9,23,27
certain TSS/360 installations,18 the TENEX system
for the PDP-IO,4 and MULTICS. Many systems have
used, successfully, approximations to the working set
model, and at least one is including hardware capable
of implementing the moving-window definition of
working set. 22
Many extensions to the model are possible and worthy
of future investigation. For example, the working set
can be defined as the set of most recently used blocks of
program code, the assumption of fixed sizes pages being
eliminated. Or, it may be useful in some situations to
partition the working set into two disjoint subsets, the
instruction working set and the data working set, and
to implement the working set principle separately for
both these working subsets. Or, none of the foregoing
considerations has allowed for the possibility of
sharing-overlapping working sets-in certain cases the
effects of sharing have been quantified, a notable reduction in total memory demand being observed. 12
REFERENCES
1 Proceedings of a Symposium on Storage Allocation
ACM Comm ACM 4 10 October 1961
2 L A BELADY
A study of replacement algorithms for virtual storage computers
IBM Sys J 5 2 1966 pp 78-101
3 L A BELADY C J KUEHNER
Dynamic space sharing in computer systems
Comm ACM 12 5 May 1969 pp 282-288
4 D G BOBROW J D BURCHFIEL D L MURPHY
R S TOMLINSON
TENEX-A paged time sharing system for the PDP-to
Comm ACM 153 March 1972
5 B BRAWN F GUSTAVSON
Program behavior in a paging environment
AFIPS Conference Proceedings Vol 33 Fall Joint Computer
Conference 1968 pp 1019-1032
6 B BRAWN F GUSTAVSON
Sorting in a paging environment
Comm ACM 13 8 August 1970 pp 483-494
7 E G COFFMAN JR A C McKELLAR
Organizing matrices and matrix operations for paged memory
systems
Comm ACM 123 March 1969 p 153ff
943
8 E G COFFMAN JR T A RYAN
A study of storage partitioning using a mathematical model
of locality
Comm ACM 15 3 March 1972
9 W M DEMEIS N WEIZER
Measurement and analysis of a demand paging time sharing
system
Proc 24th National Conference ACM August 1969
pp 201-216
10 P J DENNING
Memory allocation in multiprogrammed computer systems
MIT Project MAC Computation Structures Group Memo
No 24 March 1966
11 P J DENNING
The working set model for program behavior
Comm ACM 11 5 May 1968 pp 323-333
12 P J DENNING
Resource allocation in multiprocess computer systems
MIT Project MAC Technical Report MAC-TR-50 PhD
Thesis May 1968
13 P J DENNING
Thrashing-Its causes and prevention
AFIPS Conference Proceedings Vol 33 Fall Joint Computer
Conference 1968 pp 915-922
14 P J DENNING
Equipment configuration in balanced computer systems
IEEE Trans Comp C-18 11 November 1969 pp 1008-1012
15 P J DENNING
Virtual memory
Computing Surveys 2 3 September 1970 pp 153-189
16 P J DENNING
Third generation computer systems
Computing Surveys 3 4 December 1971
17 P J DENNING S C SCHWARTZ
Properties of the working set model
Comm ACM 153 March 1972
18 W DOHERTY
Scheduling TSS/360 for responsiveness
AFIPS Conference Proceedings Vol 37 Fall Joint Computer
Conference 1970 pp 97-112
19 E L GLASER J F COULEUR G A OLIVER
System design for a computer for time sharing application
AFIPS Conference Proceedings Vol 27 Fall Joint Computer
Conference 1965 pp 197-202
20 M L GREENBERG
A n algorithm for drum storage management in time sharing
systems
Proceedings 3rd ACM Symposium on Operating Systems
Principles October 1971
21 J S LIPTAY
The cache
IBM Sys J 7 11968 pp 15-21
22 J B MORRIS
Demand paging through utilization of working sets on the
Maniac II
Los Almos Scientific Labs Los Alamos New Mexico 1971
23 G OPPENHEIMER N WEIZER
Resource management for a medium scale time sharing
operating system
Comm ACM 11 5 May 1968 pp 313-322
944
Spring Joint Computer Conference, 1972
24 B RANDELL C J KUEHNER
Demand paging in perspective
AFIPS Conference Proceedings Vol 33 Fall Joint Computer
Conference 1968 pp 1011-1018
25 J RODRIGUEZ-ROSELL
Experimental data on how program behavior affects the choice
of schedular parameters
Proceedings 3rd ACM Symposium on Operating Systems
Principles October 1971
26 D SAYRE
Is automatic folding of programs efficient enough to displace
manual?
Comm ACM 13 12 December 1969 pp 656-660
27 N WEIZER G OPPENHEIMER
Virtual memory management in a paging environment
AFIPS Conference Proceedings Vol 34 Spring Joint
Computer Conference 1969 pp 234££
Magnetic disks for bulk storage-Past and future
by JOHN M. HARKER and HSU CHANG
IBM Systems Development Division
San Jose, California
INTRODUCTION
edge of the device characteristics or programming
requirements. Last, remotely operated time-sharing
networks and the evolving capability of both hardware
and systems programs to handle multiple jobs efficiently
put a high premium on having direct access to a large
data bank. Not to be overlooked, the operating systems
themselves required an increasing amount of on-line
storage capacity, typically 25 megabytes at a large
installatio n.
In this systems-oriented environment, the disk pack
still performs a vital function in system reliability by
assuring that data availability is not jeopardized by the
failure of a single drive. However, the use of disk packs
as a way of loading and unloading user jobs can be
expected to diminish at installations with extensive
operating systems since these systems view the
peripheral hardware as a resource which is allocated
and scheduled without operator intervention. For
efficient system usage, a single user's data sets are
frequently spread among several packs (or "volumes")
of storage and may be interspersed with data associated with other user jobs.
The gradual shift in data management from user to
system began with the increase in disk pack capacity
from approximately 7 megabytes in the IBl\1 2311 disk
drive to 30 megabytes in an IBlVl 2314 drive. This
trend will accelerate as users move to ne,,, disk devices
with considerably larger capacity such as the 100megabyte disk pack in the IBM 3330 drive (Figure 1).
Still another important development over the past
few years is an increase in the number of disk device
manufacturers whose resources and competition can
stimulate further advances.
To see where these trends will lead, it is necessary to
understand what key technology developments can be
expected, and then put them in the context of future
system requirements. Since present disk storage devices
rest on a technology base of magnetic recording,
primary emphasis will be placed on this technology and
its potential for further progress. Alternative tech-
In the early days of electronic data processing, new
application requirements arose that could not be met
adequately by batch processing, a mode dictated by the
sequential nature of card and tape input-output equipment. Users needed a device to store and directly
access relatively large amounts of data on-line. The first
such products, IBM's RAMAC disk file and Sperry
Rand's Randex drum, partially answered these needs.
However, their use could be justified only for storage of
highly active data due to their limited capacity and
high cost compared to off-line tape storage.
The subsequent introduction of the interchangeable
disk pack lowered disk storage costs and offered a
means of supplementing on-line disk capacity with shelf
storage of infrequently used data. Systems designed
with this component, in combination with programming
support for skip sequential processing and other new
features, made disk-oriented data processing commonplace by the middle of the 1960s. During the past five
years, the acceptance of the disk pack has continued to
be a major factor in the explosive growth of disk
storage. While important developments have also taken
place in fixed media disk devices, the total on-line
capacity of disk pack devices today is more than
several hundred times that of fixed media files and
drums.
A compounding of four other factors had a substantial influence on the success of the disk pack and the
rapid growth of disk storage during this period. First,
the total data processing base expanded at a very high
rate following delivery of the IBM System/360 in
1965. Second, the introduction of IBM's multidrive
2314 disk facility made hundreds of megabytes of
on-line storage practical at a cost per byte significantly
below that of previous disk pack devices. Third, large
programming operating systems became widespread,
permitting a user to conveniently incorporate disk
processing in his system configuration without knowl945
946
Spring Joint Computer Conference, 1972
Figure I-For computer installations in the '70s, the central
processor will perform arithmetic and logic operations at speeds
measured in billionths of a second, and it must draw upon vast
amounts of data stored in magnetic disk units. The IBM 3330
disk storage holds 200,000,000 bytes of information and through
its associated control unit, the IBM 3830, feeds data to a processor
at a rate of 806,000 bytes per second
nologies now emerging will be briefly assessed. The
resulting predictions are, of course, individual and not
corporate, but hopefully the ideas have been drawn
more from objective observations and published fact
than from personal bias.
HARDWARE CAPABILITIES
While a disk file is an intricate piece of machinery,
its basic capability rests upon a few key components in
addition to the storage disk. The magnetic transducers
record and read magnetic patterns representing the
information. An actuator moves the transducers over a
large number of tracks of recorded information, permitting the economy of access to a large volume of
information. The switching circuits enable many
transducers to share drivers and sense amplifiers for
write and read operations and to share a control unit
for processing signals and interfacing the disk file with
a data processing system.
In analyzing the cost and performance of a disk file,
areal storage density is the key parameter to consider.
This stems from the fact that disk files have an inexpensive storage medium but expensive auxiliary
components, and only yield a low cost per bit when the
auxiliary components are shared by as many bits as
possible. Higher areal density also improves performance parameters such as the data rate, access time
and amount of data per access.
Along with capacity increase, disk storage devices
have improved steadily in reliability and versatility.
The successive generations of disk files and their control
units have acquired capabilities such as on-line diagnostics, independent device servicing, rotational position sensing and command retry.
Nonetheless, the trend toward a lower and lower
cost (e.g., a decrease in rental from $23/megabyte/
month for the 2314 facility in 1967 to $8/megabyte/
month for the 3330 disk facility in 1971) continues
unimpeded because the advantages of density improvements far offset the costs associated with better component and device performance. However, density
improvements will not readily enable us to produce
small capacity files at significantly lower cost per byte
because the cost of auxiliary hardware cannot be
spread over a large enough volume of data.
To understand what is desirable and possible for
future disk development, we must examine the critical
parameters that control areal density-the product of
linear density (bits per inch along a track) and track
density.
Let us turn first to linear density which, in magnetic
terms, is the number of flux changes per inch. This
factor is primarily controlled by geometrically related
parameters. That is, the head gap determines the
minimum bit dimension that can be resolved, and the
storage medium thickness and head width determine the
maximum available flux. Also, our ability to keep the
head gap in close proximity with the medium determines the efficiency of magnetic coupling between the
two and insures better resolution by minimizing the
interaction of magnetic fields from adj acent flux
transitions.
In track density the limiting factor is our ability to
accurately position the read-write head within a fraction
of the track width. An error in positioning can cause
either erasure of an adjacent track or failure to erase
completely a previously written record. On readback,
either case will reduce the maximum possible signal-tonoise ratio (S/N).
The common design practice is to maintain a position
tolerance within 20 percent of the track width. * Early
systems used mechanical detents. In the newer machines,
the recording head is positioned either by a signal read
from one of the recording surfaces as in the IBM 3330
drive or from an external servo reference as in the
Information Storage Systems 715 drive and similar
disk devices. These techniques have permitted the use
of densities reaching 200 tracks per inch.
To improve the positioning tolerance in future
systems will probably require servo techniques that
actually use the data track itself to provide an appropriate error signal. This perhaps could be accomplished
by including appropriate servo data in the basic
recording code or by interspersed patterns along the
track, at the price of a sacrifice in linear density.
* Because of the many individual tolerances, the actual allowable
misregistrations for a particular machine is normally expressed in
statistical terms.
Magnetic Disks for Bulk Storage
On balance, linear density appears to be more
amenable to improvement than track density. Increased
linear density when compensated by reduced head-tomedium spacing could maintain the same signal, while
increased track density would always be accompanied
by a loss of signal for a given number of turns. Moreover, as the track is decreased below the present
.005-inch width, significant problems in the accuracy of
both static and dynamic mechanical positioning of the
head 'will be encountered because of limitations in
servo bandwidth, spindle bearing noise, thermal
gradients, and similar mechanical factors.
Now, let us examine in more detail the components
affecting linear density.
Recording medium
A particulate coating is commonly used for the
recording medium. Magnetic particles dispersed in a
binder have proved to be tolerant to impact and wear.
This system allows us to separate the problem of
obtaining the desired magnetic particle characteristics
from the problem of obtaining the desired mechanical
durability, smoothness, and uniformity in the binder.
Consistent with the improved resolution of the recording system, the storage medium thickness has been
reduced in successive improvements from 1000 microinches in the earliest disk files to below 100 microinches
at present.
While some further improvement is possible, we
appear to be reaching the limit of our ability to form a
uniform thin coating with adequate loading and dispersion of particles of the proper magnetic materials.
Further density increase may require a medium thickness below 20 microinches. The simultaneous requirements of such a thin medium for efficient magnetic
coupling and of high magnetization for maintaining an
adequate signal seem to be better answered by continuous magnetic films.l However, in such media the
problems of producing desirable magnetic properties
and a durable physical surface must be solved simultaneously. Magnetically, they must provide stable
storage, adequate signal and low surface noise. Mechanically, they must withstand the wear from intermittent
contact between the disk and the head. From evidence
to date, a considerable development effort will be
required to achieve a technology as consistent and
reliable as current particulate coatings.
Read-write transducers
With write and read transducers, the current practice
is to use a ferrite ring head with a glass gap. We- can
947
obtain an accurate and well-defined gap with a 40 to
80-microinch length, a 400 to 1000-microinch height,
and magnetic pole pieces infinitely long relative to the
gap length. Long pole pieces are a consequence of
fabrication techniques to obtain flatness economically.
Accurate control of gap height is essential since it
provides a shunt path for the magneto motive force and
sense flux, respectively, during write and read.
When compared to gap, spacing, and track width,
the head as a whole is a bulky structure. While smaller
ferrite structures can be produced, current machining
practices are a serious limitation to significant size
reduction.
One of the fallouts from magnetic film memory
technology is a fabrication technique which could be
used to form miniaturized magnetic read-write heads. 2
The technique allows us to deposit magnetic-conductorinsulator multilayers and to shape miniaturized structures by photolithography and various etching processes, making it possible to produce narrow gaps for
higher linear resolution and narrow width for high track
resolution. Also inherent in the fabrication process is
the ability to produce economically a multiplicity of
elements. They could either be sliced from a large wafer
into many chips for individual use or used as a group to
provide an array of heads for fixed head files.
Structures of greater complexity than that required
for head arrays have been deposited directly onto a
silicon wafer in the fabrication of thin film magnetic
memories. 3 This suggests the possibility of an array of
magnetic heads optimally packaged with the semiconductor selection matrix and sense amplifiers on the
same silicon chip. Such heads have quiescent magnetization parallel to the disk surface to avoid undesirable disturbance, high magnetization for an
efficient write field, and high permeability at high
frequency for efficient coupling during reading.
H ead-to-medium spacing
The mechanical access device in the most recent disk
files consists of a servo-regulated actuator which moves
an air-bearing slider that, in turn, carries the readwrite heads. The key design consideration here is the
control of head-to-medium spacing.
Smooth, flat surfaces for the head carrier and the
medium are essential to the control of head-to-medium
spacing. Machining, polishing, and buffing techniques
have been developed to consistently produce surfaces
with roughness within an arithmetic average ofa few
microinches. Smooth surfaces prevent contact and
ensure operation in a state where there is hydrodynamic
lubrication by the air film carried at the boundary layer
of the disk.
948
Spring Joint Computer Conference, 1972
u
«
:2:
«
a:
=
u
«
«a:
:2:
5::::
MMM
.-.-N
L!)O
OM
MM
NM
"="
M
N
C Media thickness
o Head-to-medium spacing
A Head gap
1000
C
C
o
0
8
88
'"oc:
'iii
c:
100
Q)
E
is
"0
:::c'"
Q)
(250
ft.)
10
(A)
T
~s~mi/i;ct?r
,,~//
10
_
1
~is~
~
10 2
',po
Id-:
"OFF,-UNE" -
/
11/ /,
I
I---
Ultra Large Memo~/I
~
.-
10-6
* It is important to note that storage density should always be
specified together with data accuracy, and access times and data
rates, because of the substantial tradeoffs which occur between
these factors. Sometimes high density storage is specified, and the
low realizable data accuracy may not be mentioned or even
understood.
10
Disc
Tape
UL
3
10
4
10
5
10
6
10
7
10
8
10 9
10 10
lOll
10 12 10 13
Storage Capacity (bits)
Figure 2-Storage capacity vs. cost per bit for memories
in the computer system hierarchy
Ultra-Large Storage Systems
several necessary conditions imposed by physics,
engineering hardware and software, architecture,
economics, and the market (e.g., timing). Each of
these factors is reviewed in this section identifying its
function in the development process. Understanding
them is a prerequisite to either making or reviewing
predictions.
1. Physics: The fundamentals of physics, and
materials, including the imperfections attainable
in practice, must be such that the desired
properties are achievable with substantial margin.
For memory systems, a first step is commonly
to demonstrate that sample bits of data can be
recorded and their existence determined by some
convenient means; tec~niques for practical
readout being speculated. I call this step physical
feasibility. The specific demonstration may cost
from $5000 to $50,000.
2. Engineering, Hardware and Software: Design
and repeatable production of reliable devices or
systems must be economically achievable in
large numbers. Operation must be economical,
and occur in commonly available environments
without unplanned downtime. There are many
engineering implications, a few of which are
worth noting.
I
a. First, we must often develop processes for
producing improved materials and improved
fabrication methods. Different processes and
methods are likely to have to be developed
for each order of magnitude increase in final
production.
b. Second, both materials and designs must be
such that required performance, economy,
reliability and lifetime are possible. In the
case of memory systems, three performance
criteria must simultaneously be achieved with
substantial margin to allow for production
and usage variations: data packing density,
write/readout error rate, and time considerations (data rate, access time, write/
readout cycle time). Most physics feasibility
demonstrations (1) involve techniques and
materials in which only two of the above three
criteria can be met. Unless there is likelihood
that techniques for meeting the third criterion
can be met, the study should be promptly
dropped.
c. Third, the design should approach elegance as
closely as possible. By elegance is meant a sort
of canonical (optimum in the sense that
necessary functions are well met and superfluities are absent) design in which the
d.
e.
f.
g.
h.
959
machine or system is well adapted -to people
(the users) and in which there are the fewest
number of parts, the least amount of material
used, and the least amount of power required
for operation.
Fourth, the design should minimize both
initial cost and long-term operating costs.
Wide tolerances on mechanical parts made of
durable materials not subject to fatigue or
state change failures are desirable. There
should be little, if any, contact between
parts to minimize wear. Strip files have had
difficulties with objectives (c) and (d). All
models produced have had reliability ,problems; none is now being produced.
An engineering model, costing perhaps ten to
one hundred times the cost of the physics
feasibility model (1) has to be built to give
confidence that the engineering considerations
such as (a)-(d) can be achieved.
If satisfactory performance is demonstrated
an engineering prototype needs to be built.
It may cost from one hundred to one thousand
times the cost of the physics feasibility model.
The engineering prototype will probably
include hardware, firmware, and software
development as well as system studies relating
to potential applications.
Software studies and development, and systems
planning need to be part of the engineering
effort from the inception so that timely,
canonical and least expensive development
can be approached. Otherwise, major redesign will be required as a minimum, and
more likely, too much of the design will be
frozen and an optimum configuration not
possible.
Finally, a manufacturing prototype, costing
approximately the same as the engineering
prototype, and documentation, costing as
much as the entire technical effort, is required
to prepare for production. It has been my
experience, during fifteen years in the data
proce8sing industry, that seven to ten years
and seven to ten million dollars is a ballpark
estimate of the cost required to move a system, such as an ultra-large storage system
from conception to completion and delivery
of the first production system.
3. Architecture: Computer architecture has changed
substantially in the last fifteen years. There has
been a continual growth, in computer systems,
of software size, complexity, hierarchies of
960
Spring Joint Computer Conference, 1972
memories, communications, peripherals, and
corresponding decreases in many unit costs.
The evolution both toward being easier to use
(better adapted· to people), toward greater
variety, and toward increasing maximum on-line
size appears likely to continue for more than the
next fifteen years. It is this latter growth which
establishes the growing market for ultra-large
memory storage systems. To use such big
memory systems, however, requires that they
fit into users' information systems. Computer
architecture is presently provided by OEM's.
lVlore sophisticated users are beginning to
develop their own architecture, and increasingly
more will in the future. Both general and special
architectures will evolve during the next decade.
Many of them will include ultra-large storage
systems.
Design of an ultra-large storage system should
be such that evolution to larger sizes over the
next decade or so is possible without significant
impact upon the users' operating systems:
There should be negligible changes in software
or system organization required. Specifically,
any ultra-large storage system produced today
should be such that more than order-of-magnitude increases in storage size can be accomplished through the next 5-, 10-, and 15- year
intervals without requiring significant software
and system changes.
4. Economics: The admission price for a new
product has to be paid. It has been observed
that this price for ultra-large storage systems is
likely to run to 10 million dollars. Systems worth
many times the admission price have to be sold to
justify the time value of the money invested.
The market estimate of those funding the
development is part of the economic gate. Other
parts are estimates of production costs and
sales price.
For a new ultra-large storage system to be
produced by 1976, a good part of the admission
price must have already been paid, and the rest
of it assured.
5. Timing. Timing ofa new product is always
critical. The optimum time is bounded by too
early (applicable technology not sufficiently
developed, market need not yet developed) and
by too late (market established and being
supplied, and price reductions under way).
Expecting development of an ultra-large storage
system to take more than five years, a new
system can be expected in 1976 only if an engineering model has already been built.
TECHNOLOGY CONSIDERATIONS LIKELY
TO IMPACT THE NEXT DECADE
l\1aterial, electrical, mechanical, and magnetic technologies both permit construction of ultra-large storage
systems, and limit their performance. The last section
discussed some of the process of memory system
innovation. This section lists some of the more significant technological considerations required in making
predictions.
1. Materials: New recording technologies usually
require novel storage media. In fact, invention
of a new medium often triggers the first feasibility demonstration of a potential new storage
process. Unfortunately, though, the quality of
existing memory storage media is so good, as a
result of thousands of man years of development,
that it is extremely difficult for any new approach
to achieve the cost/performance improvement
required for the resulting system to be successful.
The only practical ultra-large memory storage
media now in use are silver halide film and
magnetic particle tape. They are comparatively
reliable, defect-free, and low in production cost.
Other media appropriate for ultra-large storage
systems have not yet proved themselves.
Evolutionary improvements in both silver halide
and magnetic tape will continue to be made.
Both silver halide and magnetic tape, upon
analysis, show substantial life as affirmed by
National Bureau of Standards tests. After a
hundred years we will be in a better position to
tell how the mylar backing, which appears to be
the controlling factor, holds up. There is good
reason to believe that, since 10 year life has been
shown, much more life than that can be expected.
No storage medium has been certified to have
permanent life.
Silver halide tape used in microfilm applications has the advantage that it does not require
much positional accuracy for data retrieval;
both silver halide and magnetic tape, used for
digital bit-by-bit storage, do. The National
Archives finds that it must rewind s~red computer tapes using longitudinal track recording
every two years. The reason is that temperature
variations of even ±5°F lead to tension changes,
particularly in the inner one-third of stored tape
on reels. The problem with 800 bpi tape is that
the transports do not have self-clocking and can
cope with very little tape stretching. (The 1600
bpi transports do have self-clocking and can
cope with more stretching.)
Ultra-Large Storage Systems
Experience with transverse recorded magnetic·
tape is completely different. Transports seem
easily able to servo to the two-inch long tracks
even after substantial abuse including years of
storage in wide temperature ranging environments. In fact, some of the earliest video tapes
recorded 15 years ago can be played back with
no recognizable loss in signal quality.
The National Bureau of Standards has
investigated samples of storage media supplied
for the hole-burning Unicon* (which will be
described later). Their study revealed that
resolution has been accomplished and that holes
were produced without apparently damaging the
mylar substrate. So long as nothing happens to
the plating during the passage of time, the life,
like that of silver halide and magnetic tape
should be at least 10 years, and probably much
more.
2. Electrical: Continuing improvements in costperformance-life-complexity of integrated circuits is leading to increasing use of IC's replacing
engineer-designed circuits. Furthermore, built in
mini-computers permit use of soft wiring (internal computer control), instead of hard wiring
(conventional circuits using conventional circuit
elements), and firmware (use of ROM's within
soft wired systems). The consequence is increasingly sophisticated final systems providing
improvements in performance, cost, and flexibility of use. (Ironically, improvements in IC
cost/performance result in corresponding improvements in all hierarchy levels of memories,
including that of cores, which IC's are attempting to surpass by cost/performance
improvements. )
3. Mechanical: Reliability problems and breakdowns seem invariably to be due to mechanical
and/ or material failure. Comparatively few
seem to have recognized this. As has been
implied, getting out information is vastly more
difficult than putting it into most storage
systems. In fact, my experience has led me
to observe that the development cost to prove
readout capability is likely· to be two orders of
magnitude greater than the cost to demonstrate
recording. Most searches for funding for new
storage techniques have to take place between
these phases.
Practical reproducibility of production parts,
and most importantly, accurate positioning of
the readout transducer limit the performance of
* Trademark
961
-,
/
/
I /
~
-
!/'
,
I
/
/
/
/
/
/
J
L
/
/
1960
/
/
1970
1980
1990
Year
Figure 3-Area packing density, past experience and estimate of
what is realizable in commercial products in the future
electro-mechanical storage. systems to much
lower storage capacity than physical and
material considerations would permit with
perfect mechanical parts and positional control.
In fact, it is well-known, but sometimes ignored,
that laboratory performance predicted or even
achieved in feasibility demonstrations is often
more than an order of magnitude better than
can be reliably achieved in an operating system.
Conventional, longitudinally tracked magnetic tape transports are a case in point. For
economic reasons, and because of the byteacross convention, tape skew has limited linear
packing density to 1600 bits per inch. Instrumentation transports, however, not limited by
byte requirements, record and reproduce over
25,000 bits per inch. The ultimate achievable in
practice appears to be about 40,000 bpi, although
the magnetic limit is about 100,000 bpi.
Packing density is limited by mechanical
position reproducibility for readout, machine to
machine. The limits are comparable for both
flexible and rigid storage media. The storage
density, attainable in mechanically accessed
systems whether with rigid or flexible substrates,
and regardless of the recording medium, appears
to be fundamentally limited by mechanical and
material considerations. Figure 3 illustrates how
962
Spring Joint Computer Conference, 1972
this density has improved over the last decade,
and how I believe it will level off. The figure
applies to both bit-by-bit and holographic
techniques.
Some 2,3,4,5,6 have used, or proposed, electron
beam and laser beam systems with extremely
high packing densities to overcome mechanical
limitations. Figure 3 still seems to apply, but for
different reasons. These will be discussed later
in the section on beam access.
4. Magnetic: Magneto-electric effects as in core
memories, and magneto-electromechanical effects
as in disc files and tape transports are used for
large memories today. It appears that magnetoelectromechanical effects will be used for large
and ultra-large storage systems for the foreseeable future. It has already been observed that
magnetic tape can store information at vastly
greater packing density than we will ever be
able to deposit and retrieve it. The other magnetic limitation is in the transducer, the magnetic head. The inductor heads now used become
lossy at high frequencies and are generally
impractical for use above 15 MHz. This places
an upper bound upon single channel data rates.
There have been many efforts, such as the
magneto-resistive head,7 to produce practical
non-inductive, monolithic heads. None, however,
has proven to be practical to date. The appearance of a monolithic head stack which can write
and read with equivalent performance, but at
one-tenth the cost, would result in substantial
changes in the design of large and ultra-large
storage system memory elements. In the meanwhile, inductor heads will increasingly be made
of hot-pressed ferrites for three reasons: superior
wear, yield in production, and magnetic performance.
REVIEW AND PREDICTION OF SYSTEM
PERFORMANCE
Assessing possible developments in memory technology is of major interest to many groups in addition
to the technologists and marketers. Among these are the
system designers, senior corporate managements, and
venture capitalists. Eshenfelder,5 Weil,6 Hoagland,8
and Best9 have written papers containing useful survey
assessments for ultra-large storage systems which have
appeared in the last five years. The technologies and
systems I will review fall into two classes: discrete bit
and holographic. Discrete bit systems have been, are,
and may be:
1. Magnetic-oxide magnetic tape, erasable.
2. Plated tape for magneto-optic read, erasable.
3. Photographic, silver halide tape, using electron
or laser beam write and read, permanent.
4. Metallized tape, electron, or laser beam holeburning write, and readout, permanent.
Holographic systems may be:
1. Photographic, silver halide tape, laser beam
write and read, permanent.
2. Plated tape for magneto-optic read, erasable.
Each of the preceding will be reviewed, necessarily
in a limited fashion. It is important to note that the
predictions for 5 and 10 years from now are not predictions of what will exist, but of what is possible
physically, engineering-wise, and system-wise. Whether
they are developed, produced, and offered for sale
depends upon whether developments are funded.
A. Discrete Bit Systems
1. Magnetic-Oxide Magnetic Tape, Erasable
Magnetic tape storage fundamentals have
been so thoroughly reviewed in the literature8,lo
and somewhat here, that I will focus upon
storage systems. Performance data are listed
in Table 1.
a. 1966. The IBM 2321 11 Data Cell was introduced in April, 1964. It was the first significant
ultra-large storage system to be placed on the
market. Like preceding strip-file memories,
it suffered from reliability problems. Competing disc files have superseded it. Error
rate is not specified; errors are detected by the
system and reported to the CPU. Access
time is an approximate average.
b. 1971. The only available magnetic-oxide
ultra-large storage system in 1971 is the
Ampex TBM,* or Terabit Memory.12 (Tera
is the standard designation for 1012 .) The
system uses the transverse recording technique developed 15 years ago for video
recorders, and widely used since then.
Innovations include system design permitting
easy growth to both larger size and to new
generations without changing software, graceful degradation, and parallel channels for
* Trademark
Ultra-Large Storage Systems
963
TABLE I
Discrete Bit
per Station
Holographic, per Station
Mag particle tape,
electromagnetic
(erasable)
Plated tape,
Magneto- optic
(erasable)
(1)
12
a - Size
10
b - Raw Packing Density
10 6 bits! in
2
.098
1.4
3
7.5
.44
6
16
20
.45
d - Access Time
e - Error Rate
10- 1 Obits ,uncorrectable
f - Cost per Bit on Line
10- 4 cents
45
g - Cost per Bit Off Line
10- 6 cents
160
IBM 2321 Data Cell, (f is estimated at 50 time~
(2)
TBM TM
(3)
IBM 1360 (Electron Beam); W=write, R=read
(4)
Laser Bearn., estirn.ated
(5)
UNICON
(2)
Metallized tape,
laser
vaporization
(permanent)
(3)
(4)
Photographic,
laser beam,
silver halide fihn
(permanent)
Plated tape
Magneto - optic
(erasable)
(5)
-6-
bits
c - Data Rate
(1)
Photographic Electron
or laser beam, silver
halide film
(permanent)
NA
NA
15
25
15
50
10
15
15
10
15
.7
.5
.1
60
5-1
5-1
3-.3
.5
.2
1
2.-.5
NA
2.8
6
2.5R 200
.55W
7
15
10
8.3
25
25
25
6
15
10
100
2-.5
NA
300
1
.2
1
.5
600
60
5-1
5-1
5-.5
30
50-500
NA
NA
25
50-50
b
c
15
15
.1
.5
e
1-.1
1-.1
f
.2
.5
g
d
. 9(lO-4)¢ rental per month
™
simultaneous reading, writing, and 1000 ips
search. This appears to be the only system
available in the next few years which meets
all of the specifications listed at the beginning
of the paper. Most parts of the first system
have been delivered, and customer acceptance
tests are scheduled for March, 1972.
A storage system meeting some of the
specifications13 is said to be under development in IBM. It is a three-inch wide multitape loop. In the absence of specific information, I can only speculate that the
system will aim to produce automated tape
libraries having up to, say 1011 bit storage
capacity. Tape loops can be stored in chambers, accessed pneumatically, then rotated at
high speed for writing, reading, and erasing.
Reliability problems associated with the
extremely large number of rotational cycles
requires, i.e., tape edge damage, and splices
(if used) will have to be solved. If produced,
and reliability is demonstrated, this large
storage system would impact the lower bound
of the ultra-large storage market. It remains
to be seen whether achievement of the
projected performance is possible with a
reliable system.
c. 1976. Packing density, and, therefore, total
capacity of the TBM* can be doubled in five
years, and the data rate increased to match
increasing capability of central processors.
The tape loop, if successful, should also
double capacity by about 1977. If tape loops
become established, any competitive large-
storage systems will have to leapfrog in
cost/performance in order to be used. Ultralarge storage systems will continue to be
required for larger files.
d. 1981. By 1981 the TBM* cost/performance
can increase as shown in Table I. If tape
loops are successful, they would continue to
meet needs at the low end of the ultra-large
storage system market. Tape loop packing
density is likely to remain under one million
bits per square inch because of registration
difficulties.
2. Plated Tape, Laser Record, Magneto-Optic
Readout, Erasable
At this point it is useful to refer to Table II
which was prepared mostly by Irving Wolf.
The table shows that one material, cobaltphosphorous is practical to be plated upon a
flexible substrate. That material, and three
others, manganese bismuth, manganese antimony, and manganese aluminum germanium are
candidates for plating on rigid substrates and
may impact the lower end of the ultra-large
storage market. It appears unlikely that the
europium· oxide media, though it requires less
power for switching, can be produced which can
operate practically at room temperature; the
market is not likely to accept a system requiring
cryogenic operating temperatures. These technologies have been widely discussed. For example, Eshenfelder 5 has prepared a useful
* Trademark
964
Spring Joint Computer Conference, 1972
TABLE II
POTENTIAL MEDIA FOR MAGNETOOPTIC MEMORIES
ADVANTAGES
MATERIAL
Iron Silicide
(1)
(2)
Curie Point-llOoC
Large Magnetooptic rotation(F)
Europium Oxide
(1)
(3)
(4)
Good 2F /" (figure of merit," is
absorption coefficient)
Can be prepared on variety of
substitutes
Low a T
Low power requirement
(1)
Similar to EuO mag netooptically
(2)
Iron Doped
Europium Oxide
DISADVANTAGES
(1)
(2)
(1)
(2)
(3)
Stability
Ease of fabrication
Large M. O. rotation
':' Manganese
Bismuth
(1)
(2)
(3)
Good2F/"
High coercivity
Anisotropy perpendicular
(4)
~e~~::trated
(5)
2
10Sbit/in
density in material
Can be used in either Kerr or
Faraday modes.
Low trans ition temperature
0
(40 C)
Manganese
Arsenide
Further materials
work required.
Low operating temperature
o
(77 K) due to low Curie Point
Feasibility of Technique
demonstrated
Practicality yet to be
demonstrated, further
materials work required
Operating temperature (-lSOoK)
low
Low coercivity
Exploratory
Practicality yet to be
demonstrated .. further
materials work required
Very low operating temperature
0
«
50 K)
Exploratory
Needs further work
Development of feasibility
machine
(7)
Phase transition near Curie
0
Point,
360 C
Fabrication complicated for
mas s production
0
a T = 350 c
Impractical for flexible media
Performance function of substrate
Requires high peak power
Efficiency about 0.01%.
Useful for high modulus
substrate storage, card,
disc, etc. Practicality
yet to be demonstrated.
Possible use in holographic mode, though
10KW instantaneous
power required for
10 4 bit page.
(1)
(2)
(3)
2F / "
lower than MnBi.
Recording properties unreported
Complicated preparation required.
Exploratory
Further materials
work required.
2F/"
Very early. Exploratory.
Films yet to be developed.
Further materials
work required.
Practical media
techniques yet to be
developed. Could b~
put on discs.
(1)
(1)
(2)
(3)
(4)
(5)
(6)
':'Manganese
Antimony
(1)
(2)
Good range of write temperature
Better media reliability than MnBi.
Gadolinium Iron
Garnet
(1)
(2)
Low aT
Low power requirement
(1)
(2)
(3)
Single crystal material.
Relatively high media cost
Optical absorption < MnBi
EuO.
Early exploratory
,~ Cobalt''':'
Phosphorous
(1)
Simple plating process
capable of mass production
Only material shown feasible
for flexible substrate.
(l)
Low M. O. rotation
Special readout technique
required.
Write, read in engineering
model demonstrated.
(2)
POTENTIAL
Exploratory
(2)
Europium Sulfide
CURRENT STATUS
Anisotropy in Plane of Film
Room temperature coercivity
(95 Oe)is low for high density
storage
(2)
less than 50% of MnBi.
Manganese Aluminum (1) Curie Point _ 450 0 C
Germanium (2) May be feasible for
flexible substrate.
Exploratory
13
10
bit mass memories
on tape or 10 10 _lOll
bit disc menlOries.
Possible use in holographic mode.
Needs further work.
Appears to be practical for discs.
'. p;:>ear s to be practical for tape systems.
review. Treves,14 Smith,15 Stoffel and Schneider,16
Fan and Grenier,17 Aagard, et al.,11! Wider et al.,19
and Sherwood et al.20 provide additional information.
a. 1966-1971. No magneto-optic systems available.
b. 1976. Since engineering feasibility of 91
magneto-optic system using cobalt-phosphorous on mylar, has been demonstrated,
it seems evident that a system can be made
available to the market if further development is funded. Performance, as indicated in
Table I would be comparable or superior to
that of the magnetic tape system available
then. A significant advantage of magnetooptic systems is that it appears to be practical
to achieve packing densities about ten times
higher than is now practical with magnetic
tape systems. Secondly, there is no contact
between the write/read transducer and the
medium. Major disadvantages are the handling of the media, the reliable positioning of
the write and read photon (laser) beams, and
availability of reliable lasers of the required
power at appropriate costs. The demands
placed upon mechanical positioning controls
to take advantage of the higher packing
density potential are severe particularly with
respect to long failure-'free life. There is a
fundamental limit to storage density imposed
by the diffraction limit of the wavelength of
light used. If all elements were perfect, in-
Ultra-Large Storage Systems
cluding hundreds of square feet of defect-free
storage surface, and f /1 lenses used, one bit
per wavelength stored with no gap between
bits would achieve about 2 (109 ) bits per
square inch. Practical considerations, exclusive of the errors imposed by the storage
surface, limit achievable storage densities to
about 3 (107 ) bits per square inch. This
pradicallimit applies to all of the light actuated
memory systems. Electron beam systems, yet
to be described can ideally achieve higher
packing densities because the wavelength of
the electron beam is about 1/5000 that of
light beams. Here, too, practical considerations limit packing density to about the
same level.
c. 1981. If magneto-optic systems are developed
for 1976 availability, and they prove to be
practical in use, then enough improvements
are possible that, if funded, a system having
the performance indicated in Table I is
possible by 1981.
3. Photographic, Silver Halide Tape, Using Electron
or Laser Beam Write and Read, Permanent
The technology required for electron and
photon beam write/read systems for recording
on silver halide media has been developed.
Kuehler and Kerby 21 reported on the IBM 1360,
flying spot scanner read system. Bousky and
Diermann2 and Pass and W ood22 reported on
electron and laser beam analog recorders for
instrumentation purposes. Generally, electron
beam systems permit the highest data rate.
Although, electron beams can record at the
highest packing density, engineering limitations
associated with accurately positioning the readout beam onto a flexible medium dictate much
lower packing densities; they become comparable to those of magnetic recording systems.
Electron beam systems require operating in
vacuum, and laser beam systems require complex
light deflection components. Nevertheless, there
has been substantial user experience with both
kinds of systems for storing analog information.
a. 1966. No electron or laser beam systems were
available.
b. 1971. In 1965 the IBM 136023 was contracted
to be built. From 1967 to date five units have
been· delivered. Penny et al.24 described the
use of such a system, and Burnham25 the
medium. IBM produced systems under
contract, but is not offering them for sale,
965
presumably because of profit (production
cost, market, reliability) considerations.
Times are different for write, which is by
an electron beam in a vacuum, and read,
which is by a flying spot scanner . Wet development is automatic. Data is stored on
chips which are accessed in pneumatic tubes
and stored in cells, which in turn, are stored
in trays. Costs shown are estimated.
c. 1976, 1981. Data given in Table I for these
years reflect the performance characteristics
achievable by laser systems if their development is funded. Since the media is not
erasable, and off-line processing is required,
it seems unlikely that such digital systems will
be produced. Analog systems, however, will
probably continue to be produced.
4. Metallized Tape, Electron or Laser Beam H oleBurning Write, and Readout, Permanent.
Dove described a hole-burning storage system
in 1964, obtained a patent in 1965, and described
the technology recently. 4 He predicted physical
feasibility of 109 bits per square inch storage
capacity, and identified the problems of (1)
plated media cracking due to differential coefficients of expansion of the plating and substrate,
and (2) preferential expansion due to fabrication.
Engineering considerations limit packing density
to not much more than 107 bits per square inch.
a. 1966. No system available.
b. 1971. Precision Instruments announced the
U nicon, * a metallized tape hole-burning
system in 1969. Dell26 most recently described
the laser beam system which accesses strips of
tape from a file and wraps them around
either of two rotating drums. The system,
though data is not erasable, does permit
adding data in spaces not previously written
upon. It does not permit graceful degradation.
Customer acceptance tests are scheduled for
November, 1971. Although the recording
material is much more expensive than magnetic tape, the higher packing density yields
per bit costs comparable to conventional
tapes. Microinch level position accuracy,
mechanical part upon mechanical part, is
required to achieve the stated error rate.
Table I lists the announced performance.
c. 1976-1981. If Unicon* systems are delivered,
have sufficient reliability, and are able to
* Trademark
* Trademark
966
Spring Joint Computer Conference, 1972
achieve satisfactory error rates (there are
drop-in problems in which dust, or imperfections lead the readout system to read ones
rather than zeros), improvements are likely
to be made. Since the announced system
contains packing density near to the practical
optical limit, packing density is unlikely to be
improved, and, in fact, may have to be
reduced in order to improve error rate.
Improvements are most likely to occur in
data rates, error rates, and in larger file
storage. Performances that seem· possible are
shown in Table I.
B. Holographic Systems
1. Photographic, Silver Halide Tape, Laser Beam
Write and Read, Permanent.
Anderson27 presented the most comprehensive
review of holographic digital storage, erasable
and permanent, on surfaces and in volumes. He
observed that, though densities exceeding 106
bits per square inch can be written, and readout
occurs without critical alignment and tight
mechanical tolerances, in situ read and write,
but not erase is presently practical. It appears
to be practical to develop 108bit data blocks with
throughput exceeding 500 (106 ) bits per second
and random access less than 2 microseconds to
photo diode readout arrays. In the distant
future, it may be possible to write and read out
1011 bits in a volume, though selective erasure
may not be attainable. Readers are referred also
to Briggs,28 Chen and Tufte,3 Eshenfelder,6
and Raj chman. 29
Problems remaining to be solved relate to
developing capability for maintaining mechanical and dimensional stability on a flexible
medium or adapting optical or electronic circuits
to compensate· for imperfections, and inventing
and developing suitable light valves, page
composers, lasers, deflectors, and photodetectors.
Because of the first of these, it appears likely
that holographic storage will first be achieved
on plates. If developed, it is likely the dimensional stability and alignment problems will
probably dictate somewhat lower packing density
than is achievable on rigid surfaces. Estimates
of what is achievable in a system most likely to
become available in 1977/1978, if development
is funded, are shown in Table 1. If the problems
can be solved so that performance comparable to
storage on rigid surfaces is achievable, then
systems with 25. times the storage capacity
and correspondingly larger sizes and lower costs
will be achieved. The highest packing density of
any system should be achievable, and this
would then be the most practical nonerasable
store.
2. Plated Tape, Magneto-optic, Erasable.
If present applied research efforts continue,
it is possible that a satisfactory medium which
permits in situ write, read, and erase may be
developed within 5 to 10 years. If so, if problems
listed above are solved, and if funded, a system
with performance described in Table I might be
ready by 1981. Again, first applications are more
likely to be large memories on rigid surfaces.
If the dimensional stability problems are solved
to permit storage comparable to that on rigid
surfaces, a storage system such as this would
probably be the most satisfactory of all proposed.
However, there are too many ifs to believe this
will happen much before 1981; it may not occur
until a few years later.
CONCLUSIONS
Ultra-large digital storage systems will probably continue to be predominantly magnetic tape, inductorhead write/read systems through the next ten years.
System improvements are practical and should serve
to make it impractical for competing technologies to be
developed to the point where they can provide significant competition. For example, electron beam systems
with extremely high packing densities are likely to be
impractical and not developed because of beam control
problems. Holographic storage systems, while practical
for fiche-like permanent storage systems, are limited by
dimensional and positioning problems, and by the
likelihood that an appropriate erasable medium may
not be developed soon enough within this time period
for such a system to become available. The erasable
holographic storage system appears to have the greatest
potential for the second 10 year period.
Two ultra-large storage systems have been produced,
one erasable (TBM*) the other a permanent store
(Unicon*). Time will tell the practicality of these
systems.
REFERENCES
1 J HARKER
Large storage systems using rigid media, past, present and
future
SJCC 1972
* Trademark
Ultra-Large Storage Systems
2 S BOUSKY J DIERMANN
Characteristics of scanning laser and electron beams in bulk
data storage
IEEE Intermag Conference 1971 Paper 19.2
3 D CHEN 0 N TUFTE
Optical memories, now and in the future
Electronics World V 84 No 4 pp 56-60 Oct 1970
4 J F DOVE
Electron and laser beam storage and retrieval
AGARD Opto-Electronics Signal Processing Techniques pp
10-1 to 10-7 Feb 1970
5 A H ESCHENFELDER
Promise of magneto-optic storage systems compared to
conventional magnetic technology
J App Phys V 41 pp 1372-1383 1970
6 J W WElL
An introduction to massive stores
Honeywell Computer Journal V 5 pp 88-92 1971
7 R P HUNT
A magnetoresistive readout transudcer
IEEE Trans Magnetics V Mag 6 pp 602-603 1970
8 A S HOAGLAND
Mass storage revisited
AFIPS FJCC Proceedings V 31 pp 255-260 1967
9 D T BEST
The present and future of moving media memories
IEEE International Convention Digest pp 270-271 1971
10 V E RAGOSINE J C MALLINSON
Bulk storage technology magnetic recording
IEEE Intermag Conference Paper 19.3 1971
11 A F SHUGART Y H TONG
IBM 2321 data cell drive
SJCC Proceedings V 28 pp 335-345 1966 See also
IBM System/360 component descriptions-2841 and
associated DASD
IBM Systems Reference Library San Jose California
12 R B GENTILE J R LUCAS JR
The T ABLON mass storage network
AFIPS SJCC pp 345-356 1971
13 Editor
Datamation p 18 Sept 1 1971
14 D TREVES
Magneto-optic detection of high density recording
J Appl Phys V 38 pp 1192-1196 March 1967
15 D 0 SMITH
Proposal for a magnetic film memory accessed by combined
photon and electron beams
IEEE Trans on Magnetics V Mag 3 pp 593-599 1967
967
16 A M STOFFEL J SCHNEIDER
Magneto-optic properties of Mn-As films
J Appl Phys V 41 pp 1405-1407 1970
17 G FAN J H GRENIER
Low temperature storage using Ga as lasers and EuO as
storage medium
J Appl Phys V 41 pp 1401-1403 1970
18 R L AAGARD D CHEN et al
Optical mass memory experiments on thin films of M n Bi
IEEE Trans Magnetics V Mag 4 pp 412-416 1968
19 H WIEDER S S LAVENBERG G J FAN
R A BURN
A study of thermomagnetic remanence writing on EuO
J Appl Phys V 42 pp 3458-3462 1971
20 R C SHERWOOD et al
M n Al Ge films for magneto-optic application
J Appl Physics Vol 42 pp 1704-1705 1971
21 J D KUEHLER H R KERBY
A photodigital mass storage system
AFIPS F JCC Proceedings V 29 pp 735-742 1966
22 H W PASS J WOOD
100 MHz and 100 MBIT recording and read01.d
instrumentation systems for electromagnetic field perturbations
IEEE Trans on Nuclear Science V NS-18 pp 118-123 1971
23 R M FURMAN
IBM 1360 photo-digital storage system
TR02.427 IBM SDD San Jose California May 15 1968
24 S J PENNY R FINK M ALSTON-GARNJST
Design of a very large stO'fage system
AFIPS FJCC Proceedings pp 45-51 1970
25 D C BURNHAM
Microfilm as computer memory
Computer Handling of Graphic Information Proceedings
pp 137-142 1970
26 H R DELL
Design of a high density optical mass memory system
Computer Design V 10 No 8 pp 49-53 Aug 1971
27 L K ANDERSON
Application of holographic optical techniques to bulk memory
IEEE Intermag Conference Paper 19.4 1971
28 D A BRIGGS P WATERWORTH
Holographic data recording systems
Electro-Optics International Conf Proceedings pp 179-189
1971
29 J A RAJCHMAN
Promise of optical memories
J Appl Phys V 41 pp 1376-1383 1970
New devices for sequential access memory
by F. H. BLECHER
Bell Telephone Laboratories, Incorporated
Murray Hill, New Jersey
Rare earth garnet magnetic materials are now
available in very thin layers (2 to 5 J,Lm) with the
necessary anisotropy and magnetization to produce
extremely small bubble domains (4 to 10 J,Lm diameter),
and with very few defects to impede domain motion
('"'-'2 cm-2). These materials should make possible
storage densities of the order of several million bits per
square inch. In this talk, the design of bubble circuits
using single conductor current propagation is discussed
with particular application to a multi-megabit bubble
file.
Two semiconductor devices are available which serve
as dynamic-shift registers. One is of a functional nature
and is called charge-coupled device (CCD). This device
operates on the principle of charge transfer along the
interface between a semiconductor and an insulating
layer. The charges are moved by appropriately controlling the potential of metal electrodes placed on the
surface of the insulator. The other semiconductor device
is an integrated version of the IGFET bucket-brigade
shift register. Recent developments in both of these
technologies are discussed with application to large
sequential access memories.
ABSTRACT
Two classes of devices are seriously challenging the
electromechanical disk file for bulk storage applications-magnetic bubble and charge-transfer. These
devices can be used for sequential access memory and
feature solid-state reliability, small size and potential
low costs.
Magnetic bubble devices consist of a thin layer of
uniaxial magnetic material imbedded in a bias magnetic
field. The easy direction of magnetization is perpendicular to the surface of the thin layer and is in the same
direction as the bias field. There is a range of bias fields
for which regions of magnetization exist in the uniaxial
material with a magnetic polarity opposite to that of
the bias field. These regions of reverse magnetization
have the form of right circular cylinders and are known
as magnetic bubble domains or simply bubbles. The
bubble is a stable entity that can be propagated by use
of current carrying conductors on the surface of the thin
magnetic layer or by the application of an in-plane
rotating magnetic field which is used to magnetize small
permalloy features on the surface of the magnetic layer
(field access).
969
Two direct methods for reconstructing pictures
from their projections-A comparative study
by GABOR T. HERMAN
State University of New York
Buffalo, New York
INTRODUCTION
discovered by a number of people, but the most detailed
previous study of which has been given by Vainshtein
(1971a, b).
Both these techniques are direct techniques in the
sense that the reconstruction is being done entirely in
real space (density space), without the use of Fourier
transforms. This is worth pointing out, since the first
applicable method for reconstructing pictures from
their projections (discovered independently by DeRosier
& Klug [1968J and Tretiak, Eden & Simon [1969J)
depended on the fact that the Fourier transform of a
projection is a section of the Fourier transform of the
picture. Thus, reconstruction was achieved by taking
Fourier transforms of the projections, interpolating in
Fourier space to get an approximation of the Fourier
transform of the picture, and then taking an inverse
Fourier transform to get an approximation of the
picture itself. Detailed descriptions of such techniques
were given by Crowther, DeRosier & Klug (1970) and
Ramachandran (1971).
Crowther, DeRosier & Klug (1970) state that "for
general particles and methods of data collection, the
method of density space reconstruction is computationally impracticable on presently available computers." However, they appear to be wrong on this
point. Both the methods discussed in this paper have
been implemented, and precise timings will be given on
a number of examples to show that they are not computationally impracticable. Even more interestingly,
expanding the mathematics on which the Fourier techniques are based, Ramachandran & Lakshminarayanan
(1971a, b) succeeded to produce another direct method,
called the convolution method, for the reconstruction of
pictures from their projections. They demonstrate on a
number of idealized pictures that their technique is
faster than the Fourier techniques and that it also
gives a better reconstruction. Detailed comparative
There are situations in the natural sciences and medicine
(e.g., in electron microscopy or X-ray photography) in
which it is desirable to estimate the gray levels of a
picture at individual points from. the sums of the gray
levels along straight lines (projections) at a few angles.
Usually, in such situations, the picture is far from
determined and the problem is to find the "most
representative" picture of the class of pictures which
have the given projections.
In recent years, there has been a very active interest
in this problem. A number of algorithms have been
proposed for solving it. The algorithms are applicable in
a large and varied number of fields. This is perhaps best
demonstrated by the reference list, where we see that
such algorithms have been published or discussed in
ijournals on computer science, theoretical biology,
molecular biology, cellular biology, biophysics, medical
and biological engineering, roentgenology, radiology,
chemistry, optics, crystallography, physics, electrical
engineering, as well as in general science journals. The
most important use of the algorithms is the reconstruction of objects (e.g., biological macromolecules, viruses,
protein crystals or parts of the human body) from
electronmicrographs or X-ray photographs.
Most of the effort in this area has so far been concentrated in developing algorithms and in applying these
algorithms for actual reconstructions. So far, there has
been only limited attention paid to the relative merits
of the algorithms. The present paper is a report on the
first of a series of comparative studies of various
algorithms for reconstructing pictures from their
projections. The two techniques that we shall compare
are one of the algebraic reconstruction techniques
(ART) of Gordon, Bender & Herman (1970) and a
summation technique, which has been independently
971
972
Spring Joint Computer Conference, 1972
studies between ART, the convolution method and the
Fourier techniques are presently under way, and will be
reported on in later publications.
In the next section, we shall briefly describe the
problem of reconstruction of objects from their projections and discuss the criteria we shall use for evaluating algorithms for solving this problem. This is the
first exhaustive discussion of such criteria, it will form
the basis of later comparative studies as well. The
following two sections will give brief descriptions of
ART and the summation method, respectively. In
particular, we shall give a version of the summation
method which is superior to previously published
versions. In the final section, we shall give a report on
the results of our experiments.
A basic difference between the two techniques is that
the summation method takes a fixed length of time to
run, while ARTis an iterative technique such that its
result can be improved by repeated iterations. One
iteration of ART costs about the same as the summation
technique. In rough terms, the results of our experiments indicate the following.
If the number of projections is small, one iteration of
ART seems to perform somewhat worse than the
summation method. As the number of projections
increases, the relative performance of one iteration of
ART as opposed to the summation method improves,
and eventually it produces superior results. The break
even point seems to be at eight projections. However,
by repeated iterations, the performance of ART can be
improved and it eventually surpasses the summation
method in all our experiments. The improvement in
ART is especially impressive with eight or more projections. In such cases, we obtain, with five iterations of
ART, results which are far superior to the results of
the summation method.
Suppose, further, that l is divided into equal line
segments and that we draw lines perpendicular to l
from the points separating these segments. Thus, we
get a number of infinite bands, partitioning the (x, y)plane. We shall refer to these bands as the rays of the
projection associated with O. Suppose there are ro rays
which actually intersect the rectangle. For 1 ~ k ~ ro,
let Rf,k,O denote the integral of f(x, y) in the k'th band
which intersects the rectangle. (The integral need only
be carried out in the shaded region in Figure 1, since
f(x, y) =0 elsewhere.) We shall refer to R f ,1,O, ••• ,
Rf,TO,O as the ray-sums of the projection associated
withO.
The problem of reconstructing pictures from their
projections can now be stated as follows.
Give an algorithm which, given
( 1) the position of the square region within which
f(x, y) ~O;
(2) angles 01 , O2 , ••• ,Om, together with the widths
and position of rays of the projections associated
with these·angles;
(3) the ray-sums of the projections associated with
01 ,82, ••• , Om;
will produce a functionf' which is a good approximation
off·
One can only hope for an approximation, since it has
been proved, even for the limiting case when the ray
METHOD OF COMPARISON
First we wish to describe briefly the problem of
reconstructing pictures from their projections. A more
detailed description of the problem can be found, for
example, in Frieder & Herman (1971).
We assume that f is a function of two real variables
such that f (x, y) = 0 outside a square region in the first
quadrant of a rectangular coordinate system (see
Figure 1). Further, we assume O~f(x, y) ~ 1, everywhere. Following Rosenfeld (1969), we shall call a
function with such properties a picture function.
(f(x, y) = 0 means white, f(x, y) = 1 means black, with
other gray levels in between.)
Let 0 be an angle, - 90° < 0 ~ 90°, and suppose that
l is a line making an angle 0 with the positive x axis.
o
x
Figure 1
Two Direct Methods for Reconstructing Pictures
widths tend to zero, that a non-trivial picture cannot be
uniquely determined from its projections (Frieder &
Herman [1971J, Theorem 1). The algoritlnn ought to
be such that for pictures that we are likely to be
interested in, they will provide a good enough approximation. This idea is discussed in some detail by Frieder
& Herman (1971). For the purpose of the present paper,
the following should suffice.
As will be seen in the next two sections, reconstruction algorithms tend to be somewhat heuristic. Hence,
an analytical estimate of their performance is somewhat
difficult to obtain. Even if there was a method to do it,
we would be faced with the problem that the functions
j, to which the algorithms may be applied in practice,
form a small but not clearly defined subset of the set of
all picture functions f. Hence, analytical methods,
which give equal weight to all picture functions, may
give much worse estimates than what one would obtain
in practice. Therefore, it appears reasonable to evaluate
and compare reconstruction techniques on the basis of
their performance on selected typical pictures and test
patterns. This is, indeed, what we are going to do in
this paper.
Since our algorithms are to be implemented on a
digital computer, it is reasonable to demand that the
output l' be a digitized quantized picture function
(Rosenfeld [1969J, Section 1.1). Indeed, in all our
examples, l' will be defined on a 64 X 64 matrix, and can
assume as many values between 0' and 1 as the accuracy
of the computer allows. In pictorial representation, we
shall use only 16 equally spaced gray levels between 0'
and 1, inclusive.
For convenience, we shall use as test data only
picture functions which are of the same kind, i.e.,
64X64 digitized pictures with 16 equally spaced quantized gray levels. When working out the ray-sums, we
shall sum the values of j(x, y) at those points which lie
within the ray. At first sight, it may appear that this
may change the problem in an essential way, but we
shall show in the Appendix that this is not so.
In all our experiments, the rays are defined in such a
way, that it is true for at least one edge of the 64X64
matrix that each of the points on that edge is a midpoint
of a ray. The reasons for this are discussed in Frieder &
Herman (1971) and, more briefly, in the Appendix.
We have decided to use four test patterns (Plate A) .
The first two of these are binary valued picture functions (black and white) which have been used by
Vainshtein in his demonstrations of the summation
method. (AI comes from Vainshtein [1971aJ and A2
from Vainshtein [1971b].) We are not aware of any
other previously published test patterns on which the
summation method was demonstrated. The situation is
better concerning ART, Gordon, Bender & Herman
973
Plate A
(1970'), Herman & Rowland (1971) and Bellman,
Bender, Gordon & Rowe (1971), all contain a number of
test patterns showing the operation of ART. We have
decided to use two of these for the present comparative
study, both half-tone (i.e., all 16 gray levels occur in
them). One is the face of a little girl, Judy (A3), the
other is the photograph of some stomata (A4). The
first of these has been used by Gordon, Bender &
Herman (1970') and Gordon & Herman (1971), the
second has been used by Herman & Rowland (1971).
Since in previous studies these pictures were not
digitized at 64X64 points, we kept the previous
digitization (49 X 49 and 50X 50' points) and inserted
them into a white frame. This makes comparison with
previously published tests concerning these patterns
easier.
974
Spring Joint Computer Conference, 1972
For each of the four pictures, we have carried out
reconstruction operations using four different sets of
projection angles. The first three sets have been used by
Vainshtein in his demonstration of the summation
method. In all three sets the projection angles are
equally spaced between -90° and +90° (with 90° being
one of the angles), and there are 4, 8 and 30 angles,
respectively. We used these sets of angles, so that our
results can be directly compared with the results of
Vainshtein (1971a, b).
The fourth set of projection angles comes from a
small range. This is particularly important in electronmicroscopic applications, because of the restricted
range of the tilting stage. We have, in fact, used the
same set of projection angles that have been used by
Bender, Bellman & Gordon (1970) in their reconstruction (using ART) of ribosomes from electronmicrographs. We have rotated these angles so that none of
them is near 0° or 90°. The reason for this is that both
ART and the summation technique would tend to give
unusually good results if the edges in a test pattern
(like AI) are parallel to one of the projection angles.
The fourth set of projection angles which we used was
actually 35°, 44°, 62°, 80°, 98° (= -82°) and
116° (= -64°). Thus, all these views come from a
range of 81° as opposed to a full range of 180°.
Four pictures, with four sets of projections each,
provide us with 16 reconstructions to be carried out
with each of the techniques we are investigating. Then
we are faced with the problem of evaluating the success
of the reconstructions. There is no standard way of
doing this. We have decided to use four different sets of
criteria: overall nearness of the original and reconstructed pictures, resolution of fine detail, visual
evaluation, and cost of reconstruction. We shall now
discuss these criteria in some detail.
Overall nearness
(1) Gordon, Bender & Herman (1970) and Gordon
& Herman (1971) used the root mean square distance
o as a measure of the overall nearness of the original
and reconstructed pictures.
where Xi,j and Yi,j are the X and Y coordinates of the
(i, j) 'th point in the n X n matrix. The validity of such
a measure has been questioned by Crowther & Klug
(1971), but the discussion by Frieder & Herman
(1971, especially Theorem 2) shows that 0 is a very
reasonable measure for the overall performance of a
reconstruction technique.
(2) Ramachandran & Lakshminarayanan (1971a, b)
use another measure R of overall nearness in their
comparison of the Fourier techniques with their convolution method. This is adopted from X-ray crystallography, and we shall work it out as well as the 0
measure for all our experiments.
n
n
L L I f(Xi,j, Yi,j)
i=l j=l
-1' (xu, Yi,j) I
R= - - - - - - - - - - - - n
n
L Lf(Xi,j, Yi,j)
i=l j=l
Thus, R is the mean relative error of the reconstruction.
(3) For a number of applications one wants to make
the assumption that f' is a binary valued picture
function. This is obviously so if we know that· f is
binary valued. Even if f is not binary valued, we may
wish to contour l' to get some idea of the overall shape
of the object which is in the picture f. Let
_ {I,
iff(x,y)~0.5,
0,
iff(x,y) <0.5,
f(x, y) =
and let l' be similarly defined. We shall refer to J and
J' as the contoured versions of f and f'. (Naturally, for
a binary valued picture function f, f = J.) We shall also
work out the mean relative error,
versions off and 1'.
n
R, for the contoured
n
I
R= - - - - - - - - - - - - L
i=l
L IJ(Xi,j, Yi,j) -J' (Xi,j, Yi,j)
j=l
n
n
L LJ(Xi,j, Yi,j)
i=l j=l
The measure R has also been used by Chang &
Shelton (1971) in comparing two algorithms for binary
pattern reconstructions.
(4) A property of the output of a reconstruction
should be that it is consistent with the information
available to the algorithm. In other words, the raysums of the reconstructed picture should be the same
as the ray-sums of the original. Even though there are
algorithms which achieve this (Gordon & Herman
[1971J, and, for binary valued pictures only, Chang
[1970J, Chang & Shelton [1971J), they usually tend
to be slow for practical applications. Both ART and
the summation technique will produce pictures where
the ray-sums will only approximate the given data.
One appropriate measure of the overall nearness of the
reconstruction is the root mean square distance p
Two Direct Methods for Reconstructing Pictures
between the ray-sums on which the reconstruction is
based and the ray-sums of the reconstructed picture.
1 m r8z
p=
-m
[
L: r8Z
L: L: (R f ,k,8Z-R!',k,8Z)2
For 0~l~6, let
e(l) =
]1/2
,
975
max
09::; (64/2 l )-1
[~I
22l
L:
l::;m::;2l,l::;n=:;2'
[f(Xi'2 l+m, Yi.2 '+n)
09::; (64/2l)-1
l=1 k=1
l=1
where m is the number of projections and R f , ,k,8z
denotes the ray-sum in the k'th ray of the l'th projection
for the reconstructed picture 1'.
(5) A simple way of deciding the overall success of a
reconstruction is to ask whether the reconstructed
pattern resolves the original. Based on a suggestion of
Harris (1964), Frieder & Herman (1971) used the
following criterion for answering this question. A
reconstruction resolves a picture, if the output is
nearer (in the sense of 0) to the original than to uniform
gray. Since the mean gray level of input and output is
the same both for ART and for the summation technique, the distance from uniform gray of the output is
nothing but the standard deviation of the output. In
our experiments, we shall say that the output of the
reconstruction resolves the original if, and only if, the
standard deviation of the output is greater than o.
Resolution in fine detail
The major objection of Crowther & Klug (1971) to
oas a measure of difference between the reconstruction
and the original is that "it reaches a low value once the
large scale features are correct and is relatively insensitive to errors in the fine details." As it was pointed
out by Frieder & Herman (1971), this objection is not
quite valid. However, it is reasonable to ask what is
the guaranteed maximum error in the average grayness
of a region of certain size in the reconstructed picture.
With this idea in mind, Frieder & Herman (1971)
introduced the notion of (a, l, e) -resolution. They said
that two picture functions f and g with 4a2 non-zero
area (a, l, e)-resolve each other if, for every square
region of size l2, the mean grayness of the pictures in
that region differs by less than e.
The problem with (a, l, e)-resolution is that it is
difficult to calculate. For example, if we wanted to find
the minimal e such that an original and a reconstructed
64X64 picture (32,8, e)-resolve each other, we would
have to work out the mean gray value of nearly 6000
regions, each with 64 points. We have therefore devised
another method, which is a good approximation to
(a, l, e) -resolution, but which is computationally much
simpler.
In other words, e(l) is the maximum difference betweenf
andf', when they are both digitized as (64/2l) X (64/2l)
pictures. Thus, e(O) is the maximum difference between
the values at any point of f and 1', while e(6) is the
difference between the mean gray values of f and f'.
For every l, e(l) indicates the point by point reliability
of the reconstruction when both the original and the
reconstructed picture are digitized as (64/2 l ) X (64/2l)
pictures. For example, if e(2) = .01, and the gray level
in the 16 X 16 digitized version of the reconstructed
picture is .253 at a certain point, then we know that the
gray level in the 16X 16 digitized version of the original
is between .243 and .263.
The notion expressed above is easily generalized for
test patterns which are digitized as 2k X 2k matrices,
for .any k. Also, e(l) is computationally easy to calculate, it only requires a repeated increase of the
roughness of digitization by a factor of two.
For each of our experiments, we shall give the values
of e(O), e(l), ... , e(5). e(6) is always zero.
An alternative way of representing our results
regarding resolution in fine detail is to state the size of
detail which is reliable within a certain error. For any
e>O, l(e) will denote the maximum number n, such
that n is a power of two and the nXn digitization of
the original and the reconstructed pictures differ by
less than e at all points. Thus, l(O.l) =32 will mean
that the original and the reconstructed pictures
digitized at 32 X 32 points will differ at each point by
less than 0.1, but if they are digitized at 64X64 points,
then they differ by more than 0.1 at least at one point.
So, l(e) is roughly the resolution of the reconstruction
if the error tolerance is e. For each of our experiments,
we shall work out l(O.Ol), l(0.02), l(0.05), l(0.10),
l(0.25) and l(0.50). Clearly, there is no point in calculating l(e) for e>0.5.
Visual evaluation
The methods mentioned in (a) and (b) above include
all computationally possible ways of measuring the
success of reconstructions which are known to us. We
left out measuring resolution by the use of Fourier
transforms (see (a, l, e)-resolution in Fourier space in
the paper by Frieder & Herman (1971», because of
976
Spring Joint Computer Conference, 1972
its computational difficulty, and its inappropriateness
for comparing two direct methods. Even though the
mathematical measures we used should provide quite
conclusive evidence of the relative merits of two
reconstruction techniques, there has not yet been
enough experience with them to know the correlation
between the values of the measures and visual acceptability of the reconstruction. For this reason, we shall
give for each of our experiments the reconstructed
picture, which can then be compared with 'the original.
When the test-pattern is a binary valued picture
function, we shall also give the contoured version of the
reconstructed picture.
Cost oj reconstruction
This is obviously an important measure. In practical
applications, especially three-dimensional reconstruction, one has to carry out a large number of reconstructions, and cost can be a prohibitive factor.
To insure that our cost comparisons are valid, we
have incorporated both ART and the summation
method in the same general program written in
FORTRAN. They make use of the same set of service
subroutines, e.g. , the one for finding out which points
lie in a particular ray.
Time, rather than cost is given, since it is easier to
obtain. However, cost appears to be a more stable
measure between installations. Since all experiments
have been run on a CDC 6400, at a cost of $475 per
hour, the reader can easily work out the actual cost of
the runs. (Rate may vary from installation to installation.) Run time is given in seconds.
DESCRIPTION OF ART
The method we shall describe now is one of the
algebraic reconstruction techniques of Gordon, Bender
& Herman (1970), the one which was called in that
paper the direct additive method. Other papers relevant
to this method are Bender, Bellman & Gordon (1970),
Crowther & Klug (1971), Bellman, Bender, Gordon &
Rowe (1971), Frieder & Herman (1971) and Herman
& Rowland (1971).
The basic idea of the method is the following.
Starting from a blank picture, the ray-sums of all the
projections are satisfied one after the other by distributing the difference between the desired ray-sum
and the actual ray-sum equally amongst all the points
in the ray. While satisfying the ray-sums of a particular
projection, the process usually disturbs the ray-sums of
previously satisfied projections. However, as we
repeatedly go through satisfying all the projections,
the d;isturbances get smaller and smaller, and eventually
the method converges to a picture which satisfies all
the projections. Because we start with a uniform blank,
and while satisfying each of the projections we make as
uniform changes as possible, the final product tends to
be as smooth as a picture satisfying the given projections can possibly be. For practical applications,
this seems to be a desirable property of a reconstruction
algorithm. Roughly speaking, our reconstructed picture
will show only features which are forced upon it by the
projections, rather than features which are introduced
by the reconstruction process.
Mathematically, let f' be the partially reconstructed
picture just before we wish to satisfy the projection
associated with the angle 0. Let (Xi,j, Yi,j) lie on the
k'th ray of that projection, and let N k ,8 be the number
of points on that ray. Then f' is changed into J" by
the rule
J" (xu, Yi,j) = f' (Xi,j, Yi,j) + (R"k,8- Rf' ,k,8) / N k ,8.
If the value of J" obtained in this way is negative, it is
rounded to zero, if its value is greater than one, it is
rounded to one.
The process of satisfying all proj ections one after the
other exactly once is referred to as one iteration. The
accuracy of ART increases with the number of iterations, and we report on the results of experiments after
1, 5 and 25 iterations.
DESCRIPTION OF THE SUMMATION
METHOD
This method has been described by Vainshtein
(1971a, b), Gordon, Bender & Herman (1970),
Gaarder & Herman (1971), Ramachandran &
Lakshminarayanan ( 1971 b). The most detailed discussion of its properties is contained in the work of
Vainshtein (1971a, b).
Roughly speaking, the idea is to distribute each of
the ray-sums equally amongst all the points in the
corresponding ray. If there are m projections, this will
result in a picture whose total density is m times what
it should be. We therefore subtract from the value at
each point (m-l)d, where d is the mean density of the
picture. (The mean density can be worked out from the
ray-sums.) Rounding negative values to zero and values
greater than one to one, we get our first approximation
to the input.
This procedure has a lot to recommend it. It is
conceptually and computationally simple. It can be
implemented by a photo-summation device without the
use of a digital computer. It seems to provide us with a
smooth picture. In fact, if the projections and rays
Two Direct Methods for Reconstructing Pictures
satisfy certain conditions, the result of the algorithm
will be a picture which satisfies the projections and for
which the variance of gray levels is smaller than for any
other picture satisfying the projections (see Gaarder &
Herman [1971J).
However, the algorithm has some rather peculiar
properties which make it often useless in practice. It
appears that as a result of rounding to zero and one,
the average density of the picture increases. Hence, we
get, with 30 projections, the picture in A5 corresponding
to the test pattern in AI. Vainshtein (1971a) recommends that the output should be contoured at a level
so that the total density of input and output are the
same. However, this advice can only be followed for
binary-valued picture functions. To improve the
quality of the output for arbitrary picture functions,
we carried out the following process.
First of all, if a ray-sum is zero, we know that the
value of the function at all points on that ray is zero.
The first step in our modified algorithm is to mark all
points which lie on rays with ray-sums equal to zero.
Then we carry out the process described above, but
equally distributing the ray-sums only amongst the
unmarked points in the ray. After subtracting (m-l)d
from the value at each point, we round all negative
values to zero.
At this stage, the mean density d of the reconstructed
picture will usually be greater than d. So we multiply
the value of the reconstructed function at each point by
d/ d, making the mean density of the reconstruction
equal to that of the original. We should at this point
round all values greater than 1 to 1, but there was no
need for this in any of the 16 experiments that we tried.
We found that this modified summation method gave
much better results than the simpler technique described
at the beginning of the section. For example, for the
test-pattern Al and 30 projections, we get the following
comparisons.
0
e(O)
e(2)
e( 4)
time
simple method
0.32
1.0
1.0
0.44
11.25
modified method
0.18 0.75 0.57 0.09
12.92
Clearly, the large improvement is well worth the
small additional cost. In all the experiments reported
on in the next section, we used the modified summation
method.
A final comment. ART and the summation method
have been referred to (Crowther & Klug [1971J) as
"very similar." The descriptions above clearly indicate
977
that this is not so, and, as can be seen from the next
section, the power of the two methods is quite different.
It is therefore invalid to draw conclusions about the
behavior of one of these methods from the observed
behavior of the other one. The two methods could be
combined in an iterative summation method, where
after each iteration the difference between the desired
ray-sums and actual ray-sums is simultaneously equally
distributed amongst the points on the rays. This method
should give similar results to ART, but it requires a
considerably larger memory in a digital computer
implementation.
RESULTS OF THE EXPERIMENTS
We summarize the results of our experiments in the
following tables. Table I contains results on 0, R, Il, p,
whether the reconstruction resolves the original, and
time, t. Table II contains e(O), e(I), e(2), e(3), e( 4)
and e(5). Table III contains l(O.OI), l(0.02), l(0.05),
l(0.10), l(0.25) and l(0.50). These are marked as
1 percent, 2 percent, 5 percent, 10 percent, 25 percent,
and 50 percent in the table.
In all the tables, the numbers 4, 8, 30 and 6 on the
top refer to the number of projections. The first three
sets are equally spaced, while the last set consists of
the angles 35°, 44°, 62°, 80°, 98° and 116°.
The vertical arrangement of the four numbers in
each of the entries of the table refer to the result by the
summation method, followed by the results by ART
after 1, 5 and 25 iterations.
As can be seen from these tables, if the number of
projections is small, one iteration of ART seems to
perform somewhat worse than the summation method.
As the number of projections increases, the relative
performance of one iteration of ART as opposed to the
summation method improves, and eventually it produces superior results. The break-even point seems to be
at eight projections. However, by repeated iterations,
the performance of ART can be improved and it eventually surpasses the summation method in all our
experiments. The improvement in ART is especially
impressive with eight or more projections. In such
cases, we obtain, with five iterations of ART, results
which are far superior to the results of the summation
method. These conclusions are clearly demonstrated on
the plates showing the reconstructed pictures.
Plate B contains reconstructions of the wrench (AI),
Plate C contains reconstructions of peR) (A2), Plate D
contains reconstructions of Judy (A3), and Plate E
contains reconstructions of the stomata (A4). Plates
F and G contain the contoured versions of the reconstructions of the wrench and p(R).
978
Spring Joint Computer Conference, 1972
TABLE I
WRENCH (AI)
4
8
30
p
6
4
(R) (A2)
8
30
JUDY (A3)
6
4
STOMATA (A4)
8
30
6
4
8
30
6
o.
lj
R
11
p
.21
.22
.17
.11
.19
.15
.07
.03
.18
.13
.02
.00
.26
.27
.21
.15
.24
.24
.21
.19
.23
.21
.15
.10
.21
.13
.03
.00
.24
.24
.19
.15
.16
.17
.14
.13
.15
.13
.10
.10
.14
.10
.03
.03
.23
.22
.20
.19
.19
.20
.18
.18
.18
.17
.13
.12
.17
.11
.03
.03
.26
.26
.23
.22
.60
.82
.49
.26
.50
.52
.16
.05
.48
.35
.03
.00
.91
1.1
.69
.41
1.1
1.2
.91
.67
.99
1.0
.56
.29
.87
.54
.08
.00
1.1
1.2
.79
.49
.32
.41
.29
.27
.30
.32
.20
.19
.28
.23
.07
.06
.54
.54
.45
.42
.42
.48
.40
.38
.40
.40
.28
.25
.37
.25
.06
.05
.62
.63
.55
.51
.03
.06
.02
.01
.05
.01
.00
.00
.05
.01
.00
.00
.08
.09
.05
.02
.08
.08
.05
.04
.07
.05
.02
.01
.04
.01
.00
.00
.09
.09
.04
.02
.11
.16
.12
.11
.10
.10
.08
.07
.10
.06
.03
.02
.20
.19
.19
.19
.17
.17
.16
.16
.15
.13
.10
.10
.15
.05
.01
.01
.22
.21
.18
.19
24
19
7.3
2.8
24
17
3.6
.92
23
15
1.2
.01
25
20
8.3
2.8
22
15
5.9
1.8
22
15
5.0
1.8
21
12
1.5
.03
23
17
6.3
2.0
15
15
2.9
.54
17
12
1.6
.35
17
13
.87
.16
18
14
3.1
.94
14
13
2.5
.42
17
13
2.2
.52
20
14
.88
.12
19
18
4.0
1.0
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
Ye~
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes
Yes
Ym
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
1.8
1.6
8.0
40
3.4
3.4
17
86
13
14
68
340
3.4
3.3
17
83
1.7
1.6
8.0
40
3.4
3.4
17
86
13
14
68
340
3.4
3.3
17
83
1.7
1.6
8.0
4C
3.6
3.4
17
86
14
14
68
340
3.5
3.3
17
83
1.8
1.6
8.0
40
3.6
3.4
17
86
14
3.5
3.3
17
83
r
e
s
0
1
v
e
?
t
In all plates, the first row gives the reconstructions
based on 4 equally spaced projections, the second row
gives the reconstructions based on 8 equally spaced
projections, the third row gives the reconstructions
based on 30 equally spaced projections and the fourth
row gives the reconstructions based on the 6 projections
from the 81 0 range. Within each row, the first picture is
the result obtained by the summation method, which is
followed by the results obtained by ART after 1, 5 and
25 iterations, respectively.
There are a number of observations worth making
regarding the results of our experiments.
First of all, the basic measures 0 and R give, with
hardly any exceptions, the same ordering between
different experiments for the same picture. There
seems to be little reason to use the one rather than the
other. The orderings based on these measures are also
14
68
340
Yes
Yes
in very strong correspondence with the orderings based
on any of the resolution measures.
Another interesting point is that there is no instance
when a picture reconstructed by ART does not resolve
the original after five iterations.
The third observation is in reference to Table III.
Very little information can be gained from a digitization
with fewer than 8 X 8 points. In all our experiments the
summation method produced a picture whose 8X8
version differs from the 8 X 8 original at some point by
at least 0.1. In fact, for the wrench (AI), even 30
projections can only produce a picture, where the
difference between the 8X8 pictures is more than .25,
at least at one point.
It has been claimed for ART (Frieder & Herman
[1971J) that for an nXn resolution it requires approximately n equally spaced projections. Table III bears
Two Direct Methods for Reconstructing Pictures
979
TABLE II
WRENCH (AI)
E
(0)
E
(1)
E
(2)
E
(3)
E
(4)
E
(5)
p
(R) (A2)
STOMATA (A4)
4
8
30
6
.83
.94
.97
.99
.55
.58
.56
.58
.48
.61
.46
.46
.48
.65
.20
.17
.75
.79
.62
.53
.51
.51
.53
.43
.54
.38
.37
.50
.24
.03
.00
.65
.58
.49
.41
.41
.43
.44
.47
.24
.21
.10
.05
.20
.11
.01
.00
.25
.26
.15
.09
.08
.06
.03
.02
. .09
.06
. .02
.01
.09
.05
.00
.00
.02
.02
.01
.01
.02
. .03
.01
.00
.02
.02
.00
.00
4
8
30
JUDY (A3)
4
8
30
6
.84
.75
.81
.85
.79
.67
.54
.35
.75
.90
.21
.00
.81
.98
.95
.80
.82
.99
1.0
1.0
.68
.99
.97
.93
.62
.77
.25
.01
.66
.68
.57
.50
.61
.55
.26
.12
.64
.64
.08
.00
.74
.87
.74
.65
.72
.90
.87
.92
.59
.80
.53
.39
.55
.56
.08
.00
.60
.62
.50
.36
.55
.42
.14
.05
.57
.35
.03
.00
.67
.75
.64
.45
.54
.52
.40
.42
.53
.43
.26
.15
.33
.41
.23
.09
.26
.24
.05
.01
.27
.18
.01
.00
.50
.53
.42
.23
.23
.29
.19
.12
.15
.12
.07
.03
.10
.09
.01
.00
.09
.08
.01
.00
.31
.33
.21
.09
.04
.07
.03
.01
.03
.05
.01
.00
.02
.04
.00
.00
.02
.05
.04
.02
6
4
8
30
6
.75
.78
.69
.64
.75
.74
.71
.71
.57
.65
.55
.54
.55
.65
.15
.13
.93
.91
.83
.87
.42
.50
.08
.07
.70
.58
.64
.64
.58
.68
.63
.59
.52
.53
.46
.47
.48
.46
.08
.06
.73
.69
.64
.65
.36
.40
.24
.20
.34
.31
.02
.01
.57
.51
.50
.50
.50
.55
.48
.45
.44
.42
.29
.27
.42
.30
.02
.01
.64
.56
.48
.45
.25
.25
.13
.13
.25
.19
.89
.08
.23
.14
.01
.00
.42
.40
.30
.29
.19
.22
.13
.12
.21
.20
.10
.08
.21
.16
.01
.00
.38
.36
.25
.17
.16
.15
.08
.03
.10
..07
.03
.02
.11
.04
.01
.01
.10
.07
.01
.00
.11
.10
.06
.08
.06
.06
.04
.03
.05
.05
.02
.02
.07
.07
.01
.00
.15
.17
.06
.03
.03
.03
.01
.00
.00
.01
.00
.00
.01
.02
.00
.00
.02
.02
.00
.00
.05
.02
.01
.01
.01
.02
.01
.00
.01
.01
.00
.00
.02
.01
.00
.00
.07
.06
.01
.01
.71
p(r)
per) per)
Plate B
Plate C
980
Spring Joint Computer Conference, 1972
TABLE III
WRENCH(Al)
1%"
2%
5%
10%
25%
50%
p
(A2)
(R)
JUDY (A3)
STOMATA (A4)
4
8
30
6
4
8
30
6
4
8
30
6
4
8
'30
6
1
1
1
1
1
1
2
4
1
1
4
64
1
1
1
1
1
1
2
2
1
1
1
4
1
1
4
32
1
1
1
2
2
1
2
2
1
1
2
4
1
1
4
8
1
1
2
2
1
1
2
2
2
1
2
2
1
1
8
8
1
1
2
2
1
1
1
2
1
1
4
8
1
1
8
64
1
1
1
2
1
1
2
2
2
1
2
4
2
1
8
64
1
1
2
2
2
2
2
4
2
2
4
4
2
1
16
16
1
1
2
2
2
1
2
2
2
2
4
4
2
2
16
16
1
1
2
2
2
1
2
4
2
2
8
8
2
2
16
64
2
1
2
2
2
2
4
4
2
2
4
8
2
4
16
64
2
2
2
4
2
2
4
4
2
4
4
4
2
2
16
16
1
2
2
2
2
2
4
4
2
2
4
4
2
2
16
16
1
1
2
4
2
2
4
8
2
4
8
16
4
4
32
64
2
2
2
4
4
4
4
4
4
4
8
8
4
4
32
64
2
2
4
8
2
4
4
4
2
4
8
8
2
4
32
32
2
4
4
4
4
4
4
8
4
4
4
8
4
4
32
32
2
2
4
4
4
4
8
8
4
8
16
32
4
8
64
64
2
2
4
8
8
4
8
8
8
8
8
16
8
16
32
64
4
4
8
8
8
4
8
8
4
8
16
16
8
8
64
64
4
4
4
4
8
8
8
8
8
8
8
8
S
8
64
64
4
4
4
8
8
8
16
32
8
16
32
64
8
16
64
64
4
4
8
16
8
8
16
16
8
16
16
32
]6
16
64
64
8
8
16
16
16
16
16
16
64
16
64
64
64
16
64
64
8
8
8
16
16
8
16
16
16
16
32
32
32
32
64
64
8
8
16
16
Plate D
Plate E
Two Direct Methods for Reconstructing Pictures
this out. For the binary valued pictures with n equally
spaced projections the error at nXn resolution is less
than 0.05 at all points, while for the half-tone pictures
it is less than 0.1. (This is after 25 iterations, sometimes
sooner.)
For the case of 30 projections, for all four test
patterns, the error at each point in the 64 X 64 reconstructed picture after 25 iterations of ART is less than
.175, and in the case of the binary valued pictures it is
actually less than .015 (see Table II).
For perfect contouring we need an error which is
less than .5 at each point. Thus, we see that contoured
16 X 16 reconstructions of all the pictures are perfect,
with all four sets of angles, when ART is used with 25
iterations. For the summation method, the same
statement holds only for 4 X 4 reconstructions.
At two points, our results do not strictly correspond
to results in earlier publications.
The first of these is the bad quality of the contoured
output of the summation method (Plates F and G).
The contoured output obtained by Vainshtein (1971a)
in the same experiment appears to be superior. The
reason for this difference is that Vainshtein contoured
at a level which will make the contoured input and
output to have the same density, while we made the
half-tone output to have the same density as the input,
and then contoured at .5. The reader can easily judge
for himself, from Plates Band C, what the effect of
contouring at different levels would have been.
The other point concerns the performance of ART
on the half-tone pictures using 6 projections from the
Plate F
_... . If III
J•.'
,.'f\ I:.,.·~,
~ ,.
t,.
981
.. +
~
p~.r;·
III
per)
p(r) p(r) p(r)
,.f
\
.J
Plate G
81 0 range. The results appear to be much worse than
what have previously been obtained either for Judy
(Gordon, Bender & Herman [1970J) or the stomata
(Herman & Rowland [1971J). There are two reasons
for this. One is that we are putting a fairly wide white
frame around the picture. This frame does not contribute to the total density, but the fact that it goes all
the way around the picture cannot possibly be detected
from projections taken in a small range. Since ART is
intended to produce a picture as smooth as possible
while satisfying the projections, it will smooth out the
picture into that part of the original white frame which
is not uniquely determined from the projections. This
will also bring with itself a general lowering of density
in the middle portion of the picture, causing some
distortions in trying to satisfy some of the projections.
The second reason for the bad quality of the reconstructions of the stomata, as opposed to earlier experiments
with angles within the same range, is that previously
all the projection angles clustered around the horizontal,
while due to the rotation discussed in Section two, now
they cluster around the vertical. The stomata seem to
have many horizontal bands, thus, reconstructions from
projections from a small horizontal range produce
better results, than from a small vertical range. (This
is not the case with Judy.) The countermeasure to
being a victim of the orientation of the object relative to
the small range of views is to average a number of
independent reconstructions (see Herman & Rowland
[1971J). The following table gives the value of 0 when
the Judy and the stomata test patterns are recon-
982
Spring Joint Computer Conference, 1972
structed, with and without a white band around them,
with six views from two small ranges, as well as the
average in each case. All results are based on ART
after 25 iterations.
Angles
Angles
-45°, -36°,
-18°,0°,
35°, 44°, 62°,
80°, 98°, 1160 Average
18°,360
Judy
~9 X 49 version
.14
.16
.13
~4 X 64 version
.19
.19
.16
stomata
50 X 50 version
.16
.23
.17
stomata
64X64 version
.17
.22
.17
Judy
As can be seen from this table, averaging considerably
improves the quality of the reconstruction, for the
64 X 64 pictures. Using a smaller frame can also be
helpful in this respect. Thus, the bad results we obtained for half-tone pictures with six projections from a
small range can be avoided by a careful choice of the
square in which I(x, y) is assumed to be possibly
non-zero (it should be as small as possible), or by
averaging. Naturally, the same comments apply to the
summation method as well.
ACKNOWLEDGMENTS
This research has been supported by NSF Grant
GJ998. The author is most grateful to Mr. Stuart
Rowland for his constant help with programming and in
other matters. The following colleagues have also been
helpful both by enlightening discussions and in producing the actual pictures: R. Bender, G. Frieder,
R. Gordon and J. Rowe. The pictures have been
produced by the courtesy of Optronics International,
Chelmsford, Massachusetts.
REFERENCES AND BIBLIOGRAPHY
S H BELLMAN R BENDER R GORDON
J E ROWE JR
ART is science, being a defense of algebraic
reconstruction techniques for three-dimensional electron
microscopy
J Theor BioI 32 pp 205-216 1971
R BENDER S H BELLMAN R GORDON
ART and the ribosome: a preliminary report on the
three-dimensional structure of individual ribosomes
determined by an algebraic reconstruction technique
J Theor BioI 29 pp 483-487 1970
S K CHANG
The reconstruction of binary patterns from their projections
Comm ACM 14 pp 21-25 1971
S K CHANG G L SHELTON
Two algorithms for multiple-view binary pattern
reconstruction
IEEE Transactions on Systems Man and Cybernetics
1 pp 90-94 1971
R A CROWTHER
Procedures for three-dimensional reconstruction of spherical
viruses by Fourier synthesis from electron micrographs
Phil Trans Roy Soc Lond B 261 pp 221-230 1971
R A CROWTHER L A AMOS J T FINCH
D J DEROSIER A KLUG
Three dimensional reconstructions of spherical viruses from
electron micrographs
Nature 226 pp 421-425 1970
R A CROWTHER D J DEROSIER A KLUG
The reconstruction of a three-dimensional structure from
projections and its application to electron microscopy
Proc Roy Soc Lond. A 317 pp 319-340 1970
R A CROWTHER A KLUG
ART and science, or, conditions for 3-D reconstruction from
electron microscope images
J Theor BioI 32 199-203 1971
D J DEROSIER
Three dimensional image reconstruction of helical structures
Berichte der Bunsen-Gesellschaft 74 pp 1127-1128 1970
D J DEROSIER
Three-dimensional image reconstruction of helical structures
Phil Trans Roy Soc Lond B 261 pp 209-210 1971
D J DEROSIER
Reconstruction of three-dimensional images from electron
micrographs
Biophysical Society Abstracts Fifteenth Annual Meeting
February 15-18 New Orleans p 218a 1971
D IJ DEROSIER A KLUG
Reconstruction of three dimensional structures from electron
micrographs
Nature 217 pp 130-134 1968
D J DEROSIER P B MOORE
Reconstruction of three-dimensional images from electron
micrographs of structures with helical symmetry
J Mol BioI 52 pp 355-369 1970
J T FINCH A KLUG
Three-dimensional reconstruction of the stacked-disk
aggregate of tobacco mosaic virus protein from electron
micrographs
Phil Trans Roy Soc Lond B 261 pp 211-219 1971
G FRIEDER G T HERMAN
Resolution in reconstructing objects from electron micrographs
J Theor BioI 33 pp 189-211
N T GAARDER G T HERMAN
Algorithms for reproducing objects from their x-rays
Conferencia Internacional IEEE Mexico 1971 Oaxtepec
Mexico January 19-211971 also to appear in
Computer Graphics and Image Processing 1972
Two Direct Methods for Reconstructing Pictures
J B GARRISON D G GRANT W H GUIER
R J JOHNS
Three dimensional roentgenography
American J of Roentgenology Radium Therapy and
Nuclear Medicine 105 pp 903-906 1969
R GORDON R BENDER G T HERMAN
Algebraic reconstruction techniques (ART) for
three-dimensional electron microscopy and x-ray
photography
J Theor BioI 29 pp 471-481 1970
R GORDON G T HERMAN
Reconstruction of pictures from their projections
Comm ACM 14 pp 759-768 1971
E G GRAY R A WILLIS
Problems of electron stereoscopy of biological tissues
J Cell Sci 3 pp 309-326 1968
J L HARRIS
Resolving power and decision theory
J of the Optical Society of America 54 pp 606-6111964
R G HART
Electron microscopy of unstained biological material:
The polytropic montage
Science 159 pp 1464-1467 1968
G T HERMAN S ROWLAND
Resolution in ART: An experimental investigation of the
resolving power of an algebraic picture reconstruction
technique
J Theor Bioi 33 pp 213-223 1971
W HOPPE
The finity postulate and the sampling theorem of the three
dimensional electron microscopical analysis of aperiodic
structures
Optik 29 pp 617-6211969
H E HUXLEY J A SPUDICH
Application of 3-D reconstruction to problems of muscle
structure
Biophysical Society Abstracts Fifteenth Annual Meeting
February 15-18 New Orelans p 220a 1971
A KLUG
Optical diffraction and filtering and three-dimensional
reconstruction from electron micrographs
Phil Trans Roy Soc Lond B 261 pp 173-179 1971
J A LAKE H S SLAYTER
Three dimensional structure of the chromatoid body of
Entamoeba invadens
Nature 227 pp 1032-1037 1970
E R MILLER E M McCURRY B HRUSKA
An infinite number of laminagrams from a finite number oj,
radiographs
Radiology 98 pp 249-255 1971
P B MOORE H E HUXLEY D J DEROSIER
Three-dimensional reconstruction of F-actin, thin filaments
and decorated thin filaments
J Mol BioI 50 pp 279-295 1970
R S MORGAN
Structure of ribosomes of chromatoid bodies:
three-dimensional Fourier synthesis at low resolution
Science 162 pp 670-671 1968
G N RAMACHANDRAN
Reconstruction of substance from shadow I. mathematical
theory with application to three-dimensional radiography
and electron microscopy
Proc Indian Acad Sci in press 1971
983
G N RAMACHANDRAN
A V LAKSHMINARAYANAN
Three-dimensional reconstruction from radiographs and
electron micrographs I I. application of convolutions instead
of Fourier transforms
Proc Natl Acad Sci US 68 pp 2236-2240 1971a
G N RAMACHANDRAN
A V LAKSHMINARAYANAN
Three-dimensional reconstruction from radiographs and
electron micrographs III. description and appli:Jation of
the convolution method
Indian J Pure & Applied Phys Raman Memorial Issue
in press 1971b
A ROSENFELD
Picture processing by computer
Academic Press Inc New York N ew York 1969
o J TRETIAK M EDEN W SIMON
I nternal structure from x-ray images
8th International Conference on Medical and Biological
Engineering Chicago 20-25 July 1969 Session 12-11969
B K VAINSHTEIN
Finding the structure of objects from projections
Soviet Physics-Crystallography 15 pp 781-787
Translated from Kristallografiya 15 pp 894-902 1970
1971a
B K VAINSHTEIN
The synthesis of projecting functions
Doklady Akademii Nauk SSSR 196 pp 1072-1075 1971b
M WATANABE S SASAKI N ANASAWA
I mage analysis of electron micrographs by computer
JOEL News 9E1 pp 9-11 1971
APPENDIX
Justification of the use of digitized rather than continuous
test patterns
A basic assumption of any picture reconstruction
process is that the picture is reasonably smooth relative
to the size of the ray widths. It is clearly unreasonable
to expect an algorithm to reconstruct detail which ~s
much finer than the width of the rays.
Since our digitization was done approximately on
the same scale as the ray width (i.e., the distance
between two adjacent points in the matrix on which the
digitized picture is defined is of the same order of
magnitude as the ray-widths), we may conclude that
values of the digitized picture at neighboring points are
highly correlated. Furthermore, by our smoothness
assumption, if we divide the continuous picture into
squares with centers at the points of digitization, at all
points in the squares the gray value of the picture will
be near to the digitized value at the center.
The way we have chosen the position and width of
the rays is such that relative positioning of the squares
and the rays will be as shown in Figure 2.
In the digitized version, the contribution to the
indicated ray in Figure 2 will come from the value at
984
Spring Joint Computer Conference, 1972
and continuous versions of the picture are approximately the same.
To demonstrate that this argument works in practice,
we took ray-sums of a continuous version of the test
pattern in AI, with a genuinely circular boundary. The
following shows the order of differences in our measurements when we used the continuous and discrete test
patterns. The discrete pattern is not binary valued,
rather it is the 64 X 64 digitization of the continuous
pattern with 16 gray levels. All results refer to the
experiments with four projections, ART and five
iterations.
0
Figure 2
the center of the square, which is supposed to equal the
total grayness in the square. In the continuous version,
however, regions a and b in the square do not contribute to this ray, while regions a' and b', which are
outside the square, do contribute. However, the area
of a is the same as that of a' and area of b is the same
as that of b'. Hence, if the picture function is smooth
relative to the ray widths, the ray-sums of the digitized
R
p
e(l)
e(3)
e(5)
pontinuous
test pattern .1642 .4461 7.515 .5755 .2315 .0168
digitized
test pattern .1633 .4429 7.230 .5658 .2303 .0161
It appears that there is no essential difference between
the results of the two experiments. Other tests gave
similar results (see, e.g., Herman & Rowland [1971J).
Since the use of digitized test patterns makes experimentation considerably simpler, it seems advisable to
use them, rather than continuous test' patterns.
PRADIS-An advanced programming system for
3-D-display
by J. ENCARNACAO
H einrich-H ertz-Institute
Berlin/Germany
and
W. GILOI
University oj Minnesota
Minneapolis, Minnesota
SUMMARY
system has only 16 K of 24-bit words). Each module of
the programming package is a functional entity,
linked to other modules by an overlay technique. In the
paper, the construction of the programming system and
its modules, the different input modes, and the various
hidden-line detection procedures are described. Representative pictures illustrate the performance of the
system and its intrinsic procedures.
The development of PRADIS was started in early
1968 as a vehicle to implement and evaluate new
schemes of man-machine-interaction, data base organization, and hidden-line detection which were being
de,veloped in our laboratory. With time it evolved into
a rather elaborate programming system for generation,
construction, manipulation, and perspective display of
arbitrary three-dimensional objects. All relevant object
types such as polyhedrons or groups of polyhedrons
with convex or concave structure, objects that are
described by analytical expression, as well as the most
general case of objects that are bounded by arbitrarily
curved surfaces can be handled. Diffe:rent modes of
defining and inputting objects and different-hidden-line
suppression algorithms have been individually developed
and implemented for these various types. Man-machinecommunication has been facilitated by defining a
simple command language for the user. The execution
of any command can be initiated by pointing to the
respective instruction in a command menu. Additionally, a keyboard (or the console typewriter) can be
used for specification of parameters or the description
of objects by analytical equations. Subroutines for
scaling, translation, and rotation are part of the system
as well as program modules which enable the user to
construct three-dimensional objects by drawing twodimensional views of them.
PRADIS is a modular system designed for implementation on a small to medium scale computer (our
INTRODUCTION
PRADIS is a programming package written in
FORTRAN II for the .SDS 930 computer. As our
configuration has only 16 K of core memory, the whole
system has been divided into 16 segments (links).
Each segment is a self-sustained entity that takes care
of a certain complex of the total set of functions. The
various subsystems exchange data via a shared common
area.!
The first module is a control module that interprets
the command language by which a user defines what
class of objects he is going to deal with and what input
mode he will use. The control module then calls the
respective link which provides a data input in the
required mode, generates objects, and executes instructions in an interactive mode. By setting certain sense
switches, the user finally terminates the job or calls the
control module again for further execution of other
jobs. Figure 1 gives a simplified block diagram of the
entire system which we will discuss more in detail in
the following sections.
985
986
Spring Joint Computer Conference, 1972
PRADIS
OBJECT
SET
TYPE
A
COMMAND
NO
PROGRAM
PLANE BOUNDARIES
CONVEX STRUCTURE
PLANE BOUNDARIES
CONCAVE STRUCTURE
SURFACES GIVEN
BY EQUATIONS
LINK FOR
OBJECT
ANALYSIS
LINK FOR
FLAKA
(N)
Figure la-Block diagram of the system PRADIS
PRADIS
987
NO
NO
NO
LINK
INPUT OF EQUATIONS
BY TELETYPE
FOR ZIDDI
INPUT OF KEY-WORD
BY TELETYPE
LINK FOR FL AVI
LINK
FOR
BAUKAS
YES
LINK
FOR FLAVER
Figure Ib-Block diagram of the system PRADIS
CLASSES OF OBJECTS
LINK FOR NINE
POINTS'
METHOD
Figure Ie-Block diagram of the system PRADIS
The classes of objects that can be selected are:
• Groups of polyhedrons of convex structure
(KOVSTR)
• Groups of polyhedrons of concave structure
(KOKSTR)
• Groups of objects that are defined by functions of
two variables which have to be given in analytical
(FUNGLE)
form
• Groups of objects described by functions of two
variables which are "primitive functions" (i.e.,
they are stored under a function name in the
library)
(FUNAME)
• Groups of objects that are neither polyhedrons
nor defined by analytical functions but that are
composed by "surface patches" as defined by
COONS'theory
(FLADAR)
988
Spring Joint Computer Conference, 1972
procedure consists in typing in either the defining equation (FUNGLE) or the functions name (FUNAME).
For the fourth class of objects (i.e., general threedimensional objects composed by surface patches)
we have two optional modes of object definition and
input: FLEIN 1 and FLEIN 2. FLEIN 1 provides the
definition of general three-dimensional objects following COONS' method; i.e., by putting in the characteristic nodes and slope vectors.
FLEIN 2 is based on the input of nine points for a
surface patch definition, providing a much easier way
of defining objects. This technique will be described in
a later section.
Figure 2-PROTYP-Menu
(In the present version of PRADIS 'FUNGLE' and
'FUN AME' are intrinsically the same module. However, in an extended version they have to be distinguished. )
Figure 2 shows the "menu" or "light-button field"
which enables the user to select the required module by
pointing first to the PROTYP command and then to a
selection instruction. The selected problem type (and
the respective module) is indicated by an arrow. An
erroneous selection can be corrected by a delete instruction (LOESCH). Otherwise, the next instruction menu
is called, depending on the object class the user wants
to deal with.
CONSTRUCTION AND DRAWING OF
THREE-DIMENSIONAL OBJECTS
To our knowledge, the first program which served
that purpose was developed by T. JOHNSON2 of
M.LT. in connection with the SKETCHPAD project.
In this program, an object is represented by three views
TABLE I -Input Modes for the Generation and
Manipulation of Objects
object
type
input
commands
visibility
procedure
KOVSTR
ZIDDI
BAUKAS
BASTRU
FLAVER Display of
objects bounded
by plane
surfaces with
convex
structure
MODES OF INPUT
Each module provides several input modes for the
generation and manipulation of objects as shown in
Table 1.
Some comments shall be given. ZIDDI and BAUKAS
are able to call each other to facilitate the interactive
procedure of constructing objects of convex structure.
ANKOR, so to speak, is a sort of preprocessor which
calls automatically LIDREI after the analysis of the
inputted objects has been performed (of ~ourse, this
step can be skipped by entering LIDREI directly).
LIDREI includes as well as BASTRU the 4X4matrix operation that takes care of scaling, perspective
display, and rotation of objects or groups of objects.
In either case the hidden lines are evaluated and
suppressed. Naturally, the employed hidden-line detection strategies have to be different.
In the case of objects defined by equations the input
comment
KOKSTR ANKOR
DRELIS
LID REI
FLAK A
Display of
objects bounded
by plane
surfaces with
concave
structure
FUNGLE
FUNAME
FLAVI
Display of
objects defined
by functions of
z variables or
by libraryfunctions
FLADAR
PURAKU
FLEIN 1
FLAVI
TANECK
FLEIN 2
Display of
objects that are
composed by
'surface patches'
(Coons)
,PRADIS
989
Figure 4-Examples of objects constructed with the aid of ZIDDI
Figure 3-Examples of objects constructed with the aid of ZIDDI
and one section which have to be drawn by light-pen.
Recently, two more programs have been reported,3,4
but they do not offer the generality and flexibility of
ZIDDI and BAUKAS.5
ZIDDI takes advantage of the man-machine-
990
Spring Joint Computer Conference, 1972
may constitute surfaces which, again, bound bodies.
Dots and lines can be arbitrarily added or erased. All
coordinate transform procedures (scaling, translation,
rotation) can be called by pointing to the respective
command in the command menu, and they may be
arbitrarily used to generate and modify figures and
objects. In space, a point is defined by three Cartesian
coordinates x, y, z. However, on the two-dimensional
screen of the scope we have only two coordinates. This
discrepancy is overcome by defining two areas on the
screen: the xy-plane and the xz-plane. Both planes
are automatically connected by linking related coordinates (for better accuracy the user can ask the
system to display only one of the two planes in double
size and to draw an auxiliary grid).
Concave structures are not always uniquely defined
by two views, but by rotating them into an appropriate
position a unique object definition can be obtained.
Some simpler examples of objects that have been constructed with the aid of ZIDDI are shown in Figures
3 and 4.
BAUKAS (from German "Baukasten" = building
block) provides the possibility to call primitives which
are stored in a font and use them as components of a
more complex object. The primitives have been constructed at an earlier time by the aid of ZIDDI. Figure
5 illustrates the way BAUKAS works. A table is going
Figure 5-Illustration of BAUKAS
communication by which a display system with lightpen facilitates the task of constructing three-dimensional objects by drawing two-dimensional views.
Additionally, the user has a set of powerful commands
at hand for executing coordinate transforms and other
operations. Using the light-pen, the user marks dots
which are subsequently connected by lines. These lines
Figure 5 (cont'd)
PRADIS
to be constructed by using cubes as primitives. By
deforming the cubes in one way, we get the table-top;
by deforming it in a different way, we get the legs. On
top of the table we put two other primitives: the
pyramids and the cube on top of them. The flexibility
Figure 6-Examples of objects constructed with the
aid of BAUKAS
of BAUKAS
in Figure 6.
IS
991
illustrated by some examples given
ANALYSIS OF POLYHEDRONS WITH
CONCAVE STRUCTURE
Concave objects are those which are bounded by
one or more concave surfaces or which have cavities.
A group of disconnected objects (with empty space in
between) is-as a group-concave, too. It is evident,
that in contrast to convex structures some difficulties
may arise with respect to establishing unique relations
between all points, lines, surfaces, and objects of a
structure. However, these difficulties are overcome by
the following procedure. 6 Prerequisite for it is, that a
list is available which gives the three spatial coordinates
of all points, and which marks all connections between
them. Such a list may have been put in by the user or
it will be generated by the program.
The most general case is that the user has three
drawings which show three different (two-dimensional)
views of the object. In that case the user has only to
provide for each drawing a list of the two coordinate
values of all relevant points, together with a second list
of all visible connections. The order in which the points
are numbered is arbitrary. From these lists the program
generates a list of all points in space in the following
way: the y-coordinate of a point in the xy-list, for
example, is taken, and the yz-list is searched for the
same y-coordinate. If the search is successful, the
xz-list is searched for a point, whose x- and z-coordinates
correspond respectively with the x-coordinate of the
point taken from the xy-list and the z-coordinate of the
point taken from the yz-list. Triples of x-, y-, and
z-values obtained in such a way constitute the coordinates of a (spatial) point of the three-dimensional
object. Eventually, the list of all spatial points is sorted
with respect to increasing values of x and a running
index is assigned to each triple.
The second task is to generate a list of all lines of the
three-dimensional objects from the input of their
two-dimensional views. A similar search procedure as
in the case of the generation of the lists of spatial points
is used, i.e., the three lists which belong to the twodimensional views are searched for certain equivalences.
The difference is that now an equivalence is not given
by the coordinate values but by their running index.
The point is that first of all the arbitrary numbering in
the list of all points of the two-dimensional views has to
be replaced by the corresponding running index taken
from the ordered list of spatial points. In order to make
that feasible, the lists of the points of the two-dimen-
992
Spring Joint Computer Conference, 1972
show some of the results we obtained with this procedure
(Figures 7 to 9).
DEFINITION OF OBJECTS BY ANALYTICAL
FUNCTIONS
There are three different ways of defining threedimensional objects by analytical expressions:
(1) the implicit form
(2) the explicit form
(3) the parametric form
Z=ja(u, v).
F(x, y, z) =0
z=j(x, y)
x=fr(u, v), y=j2(U, v),
Though the implicit form is the most simple one, it
does not lead to an efficient computer algorithm. The
explicit form, on the other hand, does not provide a
unique description (e.g., for z=o we have j(x, y) =0
which does not only define all the points of a plane but
all the points on a cylinder). So we have to rely on the
parametric form.
In order to facilitate the input procedure, the system
enables the user to key-in his equations on the display
keyboard (or console typewriter, respectively). After
having the equations analyzed and transformed, the
system calls an appropriate algorithm for function
evaluation. Furthermore, the user will be asked to
specify all necessary reference coordinates, scaling
factors, and other parameters. Syntactical errors will be
detected, and error messages will be output. The
respective language which we use is simple; its syntax
has been described elsewhere. 7 ,8
The typed-in equations are processed in the following
steps:
(1) loading into a buffer storage area
(2) equation analysis and coding
(3) assignment of values to the parameteric variables (u, v)
(4) assignment of values to the coordinate variables
(x, y, z)
(5) calculation of the right-hand expressions and
storage of the obtained results.
Figure 7-Examples for the results of the object analysis
sional views must at first be augmented by all connections which are existing in the three-dimensional case
but not visible in all the two-dimensional views. This
procedure is fairly complicated so that it would lead
too far afield to explain it in detail. The next figures
In the second step the equations are converted into
polish notation, and a push-down stack is set up. An
operation matrix defines whether or not an actual
operation can be immediately performed on two
subsequent variables. The first row denotes the actual
operators and the first column their predeces·sors. The
meaning of the numbers in the matrix is
1: Operation cannot be executed. Bring operator
into the operator stack.
PRADIS
993
2: Both operators have same priority. Execute
operations.
3: Actual operator has higher priority than predecessor. Execute operation.
4: Erase parentheses (or brackets). If the expres-
Figure 9-Examples for the results of the object analysis
sion between parentheses (brackets) is a subroutine for function evaluation, it is executed.
5: Recognition of a terminal operator.
6: Invalid combination of operators. Output error
message.
OPERATION MATRIX
+
*
/
(
[
A
Blank
Figure 8-Examples for the results of the object analysis
t
+
2
2
3
3
1
1
6
1
3
*
2
2
3
3
1
1
6
1
3
1
1
2
2
1
1
6
1
3
/
1
1
2
2
1
1
6
1
3
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
)
]
A
3
3
3
3
4
4
6
6
3
3
3
3
3
4
4
6
6
3
1
1
1
1
1
1
6
1
1
63
3
3
3
6
6
6
5
3
t
1
1
1
1
1
1
6
1
2
994
Spring Joint Computer Conference, 1972
Figure lO-Surfaces generated and displayed with FLAVI
The above outlined analysis program has been written
in FORTRAN II which, however, had to be supplemented by bit and character manipulation subroutines.
The submodule FLAVI can be applied for hidden line
detection and suppression to the thus calculated
functions. Figure 10 shows some objects generated in
that way.
GENERAL OBJECTS
According to COONS' theory and the nine point
modification we have three main modes of defining
bounding surfaces of general three-dimensional objects:
(1) The boundary contours have to be specified;
blending functions (functions that define how
the boundaries are connected by curved surfaces) are defined once and for all.
(2) Four corner points and eight corresponding
slope vectors have to be specified for each
surface patch; fixed blending functions are given,
as in the first method.
(3) For each surface patch nine characteristic
points have to be specified. No blending functions are required.
Generation of boundaries by polynomial approximation
(FLEIN 1, PURAKU)
The first approach offers the advantage of dealing
with larger entities than the "surface patches" in the
second and third approach. Each boundary is approximated as an entity by a polynomial approximation.
For each contour n+ 1 quintuples have to be specified;
n being the degree of the approximation polynomial.
PRADIS
995
The five values of each quintuple give the three coordinates of a point through which- the polynomial
passes as well as two parameters for the specification of
the two degrees of freedom of the surface. Thus, the
degree of partitioning the objects can be lower.
However, the method shows some deficiencies. (One
serious deficiency is, for example, that it is not very well
suited for an interactive use of the display system but
requires rather elaborate preliminary work.) It is left
to the user to define the degree of each approximation
polynomial; if he is not very familiar with the performance of polynomial approximations, large errors
may occur. Of course, the best performance is obtained
if the boundaries are conic sections.
Figure 12-Example for the nine point method of
defining a surface patch
Figure ll-Object defined by COONS' method
COONS'method (PLEIN 1, TANECK)
on the boundaries (one point on each one), and one
point in the center of the surface. 1l Figure 12 gives an
example: the surface element is a quadrilateral, the
center point is on the same level (has the same z-coordinate) as the four corner points, and the points on
the boundaries are on a higher level. In Figure 13, in
contrast, the center point has been raised to the level
of the boundary points.
The nine point method works better the more
information about the objects one has (points of
inflexion, boundary, etc.). Boundaries are approximated in an optimum way if they are parabolic. Any time
a break point or a point of inflexion occurs, a new surface
patch has to be defined. Hence, the nine point method
leads to a finer partitioning than COONS' method.
Another disadvantage is that it does not guarantee
As mentioned before, for each construction element
called "surface patch" of a curved surface we have to
specify four corner points and eight corresponding slope
vectors, two for each boundary contour. These vectors,
of course, are defined in space by specifying their
components.lO In FLEIN 1, the intrinsic blending
functions are of third order. Figure 11 shows an example
for an object defined in such a way. In order to obtain a
smooth representation of an object, it is necessary that
the user develops a good feeling of how to specify slope
vectors in an optimum way. Hence, the application of
this method requires a lot of experience and preliminary
work with pencil and paper.
The nine point method (FLEIN 2)
Here, a surface patch is defined by specifying nine
characteristic points: the four corner points, four points
Figure 13-Another example for the nine point method
996
Spring Joint Computer Conference, 1972
expecting very much from the user with respect to
his power of imagination.
Additionally, the nine point method requires much
less time for preparation and execution of a problem. It is particularly suited for plotters or displays
that work incrementally. The man-machine-interaction
is excellent. Figure 14 shows as an example the body
of a well-known automobile.
COORDINATE TRANSFORMS
PRADIS uses homogeneous coordinates. A coordinate
transform is performed by multiplying the matrix of
homogeneous point coordinates by the transform
matrix TM-as indicated in Figure 15. The transform
parameters have to be specified by the user.
VISIBILITY CRITERIA
Visibility criteria enable the program to detect (and
erase) hidden lines. For a satisfactory display of threeSx
0
Sy
0
RM
Sz
0
4X4Transformation
matrix
1
1
0 0 0
Scale
Rotation
1
1
0
1
1
0
1
1
Translation
Figure 14-Automobile as an object generated by aid
of surface patches
a continuous transition between surface patches. A
big advantage, on the other hand, is given by the fact
that no blending functions have to be defined and no
spatial vectors have to be specified, both requirements
Perspective
[x y z 1}[TM]= [x' y' 0 p]
p= 1-z'/c z
cz • •• Centrum of projection
Picture coordinates
X=x'/p
Y=y'/p
Figure 15-The 4X4-Transformation matrix
PRADIS
dimensional objects, the hidden line suppression is
mandatory. We distinguish between three types of
criteria: point tests, surface tests, and combined
point/surface tests. In the case of surface tests the
primitive which is tested is a surface element as the
name indicates. The surface test indicates only, whether
or not a line is visible as an entity; i.e., a possible
mutual hiding of two surface elements cannot be taken
into account. Hence, it is not applicable to concave
structures.
Points test partition a line into small segments that
are only considered to be visible if none of the arbitrarily
selected points on this segment is hidden by a surface
element. The point test procedure is generally applicable, however, it requires a prohibitive amount of
execution time. Combined point/surface tests try to
combine the advantages and avoid the disadvantages
of point tests and surface tests.
In PRADIS, we use some new schemes which we
developed. 12 The implementation of our hidden line
detection algorithms are called FLAVER, FLAKA,
and FLAVI. The gist of these three algorithms shall be
summarized in the following.
(1) FLAVER-FLAVER uses a hidden line algorithm that is applicable to convex structures.
The procedure consists of three main steps. In
the first step, the angle between the line-of-sight
and the normal line on the surface is calculated
resulting in a criterium for totally hidden surfaces. In the second step, a priority is assigned
to each one of the remaining surfaces. Thus, the
sequence is defined in which the mutual hiding
will be determined. This is done in the third
step by investigating whether or not the terminating points of a line fall into a surface with
higher priority than that of the surface the line
belongs to. If only one of the terminating points
is hidden, the point of intersection between this
line and the surface boundary is determined.
This point terminates the visible part of the
line. The point is that only surfaces with higher
priority than that of the surface the respective
line belongs to are to be taken into account,
thus saving considerably computation time. 12 ,13
(2) FLAKA-FLAKA works on concave structures;
i.e., it works in the more general case where the
polyhedrons may have cavities and/or a group
of disconnected polyhedrons occurs. In this
case, the angle between the line-of-sight and the
normal line, unfortunately, does not provide a
simple criterium for determining whether a
surface is visible. This difficulty is overcome by
997
dividing in a preliminary step all the surfaces
of a structure into triangles. On these triangles
the last two steps of FLAVER can be applied.
The partitioning of all surfaces of the structure
results in additional lines (if a rectangle is
partitioned into two triangles, an additional line
is generated which is the rectangle diagonal).
Special care has to be taken to suppress these
additional lines (therefore, the triangles are
of course not visible) .
(3) FLAVI-The intrinsic hidden line detection
algorithm of FLAVI takes care of objects that
are defined by analytical expressions-be these
expressions defined by the user in form of
equations or generated by the program according to COONS' theory. The procedure works
as follows: First of all a Cartesian coordinate
grid of 11 by 11 lines is superposed. If the
visibility of the point of intersection between
2(~U-Llv)-segments has to be determined,
only the surface patches have to be considered
that have no empty intersection with the
respective grid area. Subsequently, surface
patches to be taken into account are partitioned
into triangles, and the z-coordinates of these
triangles are calculated at values of x and y
given by the coordinates of the intersection
point. If a triangle has a z-coordinate which is
greater than that of the intersection point, it
hides that point. If no such triangle exists, the
point of intersection is visible. All points of
intersection of all linesu = constant and v =
constant have to be tested in that way. If one
of two connected points is visible and the other
one hidden, more points located on the connecting contour have to be examined.
ACKNOWLEDGMENTS
The authors are gratefully indebted to Mssrs. Grosskopf, Schulz, Castro, lVlahramzadeh, Hunger, Burmeister, Eckert, and Kniepen who contributed by
their thesis work under our supervision to the successful
implementation of the PRADIS system.
REFERENCES
1 H J BEISTER
Zur Technik der Segmentierung von Programmen bei
Rechenanlagen mit kleinem
Speicher edv 7/69
998
Spring Joint Computer Conference, 1972
2 T JOHNSON
SKETCHPAD III-A computer program for drawing in
three dimensions
Proc SJCC 1963
3 DEWING D TEDD
A display technique for manipulating engineering drawing in
3 dimensions
CG 70-London
4 R J HVBBOLD
TDD-A 3 D drawing program
CG 70-London
5 J ENCARNACAO J HUNGER
Das interaktive Zeichnen und Entwerfen in drei Dimensionen
Elektronische Rechenanlagen 1 February 1971
6 J CASTRO H MAHRAMZADEH
Beschreibung, Untersuchung und Erprobung der Zerlegung
beliebiger Koerper mit konkaver Struktur in konvexen Eben-en
Studienarbeit TU Berlin 1969
7 J ENCARNACAO
Untersuchungen zum Problem der raumlichen Darstellungen
aUf ebenen Bildschirmen
Doktorarbeit TV Berlin 1970
8 R ECKERT
Untersuchung und Verallgemeinerung von F LA V I
Studienarbeit
TV Berlin 1970
9 J ENCARNACAO
A solution to the problem of reconstructing objects from three
views and displaying them using a new hidden-line algorithm
DATAFAI71 March 1971 Nottingham
10 S A COONS
Surfaces for computer aided design of space forms
MAC~TR-41 Clearinghouse for Federal Scientific and
Technical Information Springfield Virginia 1967
11 G SCHULZ
Fliicheneingabe durch Eckpunkte und Tangentenvektoren und
durch ncun spezielle Punkte
Diplomarbeit TV Berlin 1970
12 J ENCARNACAO
A survey of and new solutions for the hidden-line problem
CG-Symposium Delft 1970
13 G GROSSKOPF
Beschreibung, Untersuchung und Erprobung der Visibilitaetsverfahren FLA V E R und F LAKA Diplomarbeit
TU Berlin 1970
MARS-Missouri Automated Radiology System
by J. L. LEHR, G. S. LODWICK, L. J. GARROTTO, D. J. MANSON and B. F. NICHOLSON
University of Missouri
Columbia, Missouri
The primary role of the radiologist is to examine
patients, usually with the help of ionizing radiation, in
order to provide information of use in patient care. The
radiologist functions as a consultant that is, patients
are referred to him by many other physicians, and he
delivers information obtained from his special methods
of examination back to each patient's referring physician. As a result the radiologist deals with greater
numbers of patients than most physicians. Also, he
needs to move a great deal of data quickly and accurately.
Radiology is a relatively young field of medicine,
and the variety and complexity of examination techniques in the radiologist's aramentarium continue to
multiply. Because of this and because he examines more
patients each year, the annual increase in demand
upon a radiologist's time has been estimated from 15 to
25 percent. Fortunately, however, radiologists are used
to living with complicated electronic gear, and the
specialty as a whole has shown considerable interest in
employing data processing techniques to streamline
patient care delivery.
Our own efforts began in 1965 as project RADIATE
(Radiologic Diagnoses Instantaneously Accessed and
Transmitted Electronically), continued as ODARS
(On-line Diagnostic and Reporting System), and have
finally been renamed MARS (Missouri Automated
Radiology System). It was apparent initially that
straightforward computer programs could· carry out a
variety of business functions such as patient billing or
inventory control. However, the most important
information flowing through a radiology department is
the medical information, i.e., what the radiologist has
to say about the patients he examined. The processing
of this basic information was the problem we tackled.
Traditionally the radiologist has dictated his consultation after reviewing a patient's films. This dictation
is then transcribed, proofread, and finally returned to
the referring physician. The problem of capturing this
data for a computer can be solved in a variety of ways
ranging from keypunching the reports to utilizing
typewriters which produce magnetic tape along with
typed copy. Such approaches do provide the computer
with data to process. Indeed, they provide a large
amount of natural language data which requires very
sophisticated processing to interpret. Although processing of dictated reports has the superficial advantage
of not interfering with traditional methods, it tends to
complicate the flow of information rather than facilitating it.
We have chosen a more radical approach for MARS.
Instead of dictating his report, the radiologist interacts
with the computer via an on-line terminal. He constructs his report by retrieving terms from several
large lists, each containing a particular category of
term, and stored in direct access files. The retrieval
technique is a modified keyword in context approach.
The radiologist types in one letter denoting the particular type of term followed by the first four letters of any
word in the term. The computer displays a list of all
terms associated with this keyword, and the radiologist
selects one of these. Three categories of terms are
available; examination types, anatomic sites, and
diagnoses.
In addition to incorporating phrases retrieved by
keyword, the radiologist has additional options in
preparing his report. He may select any of a list of
commonly employed phrases such as "there has been
essentially no change in findings since the previous
examination." This particular phrase being the fourth
in the list, the radiologist may simply type "P4" to add
it to the report. Or, if he does not remember the number,
he may simply type "P" to request display of the entire
list from which he then makes his selection. Another
option available is the incorporation of a pre-coded
sequence of statements which are retrieved by typing a
three letter abbreviation, or mnemonic. For example, if
the radiologist types "CAD," the computer will incorporate into the report a series of statements describing a geriatric chest with calcification in the aortic
999
1000'
Spring Joint Computer Conference, 1972
arch, tortuosity of the descending aorta, and degenerative changes in the thoracic spine. These pre-coded
statements frequently make it possible, to complete an
entire report by typing only a few letters. The approach
is obviously quite similar to the use of "canned" reports
generated by semi-automatic typewriters. However,
the computer system does have the advantage that the
radiologist reviews the report on his terminal immediately and, if he wishes, he may easily edit it. For
example, if the changes in the spine are unusually
marked, he might add an appropriate modifier to the
report. Finally, if the radiologist is unable to express
himself fully by the options provided, he may type as
many additional remarks as he feels are needed.
This method was aimed at solving the basic problem
of capturing the radiologist's report in a form which the
computer could comprehend. The technique met with
criticism for two reasons. First, it altered the traditional
form of the radiological consultation. Instead of
paragraphs of prose, the referring physician would
receive a somewhat terse list of observations and
impressions. Second, it required that the radiologist
operate a keyboard. Added to the very real problem
which would arise if the radiologist were slowed down by
using a terminal there is a largely emotional problem
which stems from the idea that it is somehow "sissy"
for an M.D. to type.
The only way we could see to answer these objections
was to put the System to work. Our immediate goal was
not to automate all the functions of the department,
but to test the hypothesis that the medical information
flow could be handled by an on-line system as described.
Accordingly we wrote, tested, and rewrote programs.
Finally, on April 1, 1970, we locked up the radiologists'
dictaphones and began using MARS to process all
consult at jon in our department. Clinical use required
not only that the radiologist be able to interact with the
computer to define individual reports but also that
there be a system for handling the flow of patients
through the department. The system we have used can
best be described by following the progress of a typical
consultation through the department.
A patient presents for examination in the department
at a reception area accompanied by a request form
filled out and signed by the referring physician. The
receptionist informs the computer of the patient's
arrival by entering the patient's unit number via
a terminal. The computer searches the hospital master
disk file for this number and responds by displaying
information found there, including the patient's name,
date of birth, sex, race and· hospital ward or outpatient
clinic code. If the information is not on file (as, for
example, in the case of a patient not previously seen at
the hospital who requires emergency care), it is entered
by the receptionist manually. The receptionist then
types in the clinical history provided by the referring
physician, along with his name. Finally, the examination requested is entered, and the computer stores all
of this information in a temporary holding file. A three
digit number indicating the location of the record within
this file is displayed to the receptionist who writes it on
the request form.
The patient is examined and the roentgenograms,
along with the patient's previous X-rays and reports
and the request form are brought to a radiologist at
one of several terminals for interpretation. The radiologist begins by entering the three digit address of the
information entered by the receptionist. The computer
retrieves the preprocessed patient identification data
and displays it on the screen. The radiologist corrects
any errors in this data and then completes the report
by the method outlined above. Finally the radiologist
proofreads the entire report, makes any corrections
and then signals the computer that the report is complete. The computer immediately types out a copy of
the report on an output terminal located on the patient's
ward and, simultaneously, three copies are produced in
the department of radiology. One of'these copies is
affixed to the jacket containing the patient's radiographs;
the second is mailed to the referring physician for his
convenience; and the third is attached to the request
form, presented to the radiologist for signature and
returned to the patient's medical record.
All the reports transmitted during the day are kept
on a random access disk file and any of them can be
reviewed instantly by entering any patient's unit
number on a terminal. At night, each report transmitted is permanently stored in a numerically coded
form on a large direct access file. From this file any
report for any patient can be retrieved for review
within a matter of seconds. Also categorical searches
can be performed on-line.
In our two years of experience with this system we
have learned many things. Primarily we have shown
that it is possible to operate a department with an
on-line information system. In evaluating MARS we
did measure some parameters such as the time spent by
patients in the department and the time a radiologist
spends reporting a case. We found these to be essentially
unchanged from data accumulated before the System
went into operation. MARS did, however make a great
reduction in the delay between arrival of a patient in
the department for examination and delivery of a
written consultation. Before MARS this delay averaged
23 hours with about 75 percent of all reports being sent
out on the day following the examination. With MARS
this delay has been reduced to an average of 10 hours,
and 75 percent of all reports are transmitted on the day
MARS
of the examination. We regard this as a significant
improvement in patient care.
Our experience operating MARS has not been
uniformly pleasant, however. We have been plagued by
unreliable computer services. We have been operating
on an IBM 360-50 under O.S. using the Baylor Message
Handler for terminal I/O. The system is a busy one
with two million bytes of "slow" core, multiple tapes,
disks, and a data cell. In addition to a couple of batch
partitions, the system handles a variety of on-line
applications for other departments in the Medical
Center, as well as a good deal of developmental work.
With all of this, the time during which MARS has not
been available to radiology has averaged slightly over
10 percent of our working day. For the most part,
failures are due to system software. The system simply
dissolves. Generally it can be restarted in from fifteen
to twenty minutes providing our radiologists with an
unscheduled coffee break. More serious failures of
hardware or software have not been uncommon,
however, and when the system is down for an hour or
longer we revert to dictation of reports.
We should emphasize that our computer center has a
staff of good systems programmers and is headed by an
able Director. However, we see certain disadvantages in
the very concept of a large central computer. If a
radiologist is going to build his practice around an
information system, then he will be responsible for the
effect that system has on patient care. This responsibility is very difficult to assume unless it is coupled
with clearly defined administrative control over the
operation of that system. It is difficult to see how this
is possible if the radiologist is only one user of a large
time sharing computer.
Our experience with MARS on the 360 has convinced
us that the concept of on-line management of information flow is valid for a department of radiology.
We have been reluctant, however, to fully exploit .the
possibilities for a more completely automated department on a computer system with the disadvantages
outlined above. Finally, we have become quite interested in building a system which can be exported easily
to other departments. For these reasons we are in the
process of implementing a stand-alone version of MARS
on a smaller computer, the PDP-15, using MUMPS,
the Massachusetts General Hospital Multi-Programming System.
'
The basic reporting function of MARS on the PDP-15
is still quite similar to that discussed previously and
consists of retrieving from standardized tables those
terms to be incorporated into the reports. We have
been able to make the retrieval of terms a bit more
sophisticated, however. After examining the frequency
with which terms were used in some 50,000 reports we
1001
found that a relatively small number of terms were
used quite frequently. These terms have been assigned
unique three-letter mnemonics so that they can be
retrieved without bothering to look at other terms
which would be retrieved under the keyword search.
In addition, the keywords are no longer restricted to
four letters. The modifying terms have been expanded,
separated into exam, site, and diagnosis categories, and
assigned mnemonic codes for retrieval. Also, the
definition of "canned" reports has been left to the
discretion of the individual radiologist, so that these
can be tailored to suit his needs. Finally, the program
has been altered so that the radiologist can specify
multiple terms with one input string. This frequently
makes it possible for him to define an entire report with
one turn-around at his terminal.
In addition to these relatively minor changes at the
radiologist-computer interface, we are expanding
MARS to automate several other departmental functions. For the most part these are the fairly straightforward business-like applications which we ignored
previously, and they come as rather natural spin-offs
from the medical information system. These applications are, however, extremely important from a costeffectiveness viewpoint. One application is patient
billing. Since the MARS report contains the name of
the patient, the examination performed, and the
consulting radiologist's name all the information needed
to specify the charge is available to the System. It is
only necessary to associate with each examination in the
table the appropriate fee. The System displays these
charges to the radiologist who verifies and/or corrects
them just prior to transmitting his report.
In many departments patient billing is handled by
another agency, usually a hospital. Under these circumstances the department's responsibility ends at correctly
specifying the charge for each patient. If billing is done
by hand, a daily listing of charge should suffice. At our
hospital, patient billing is done by computer, so that
we will provide the charges on magnetic tape. We do
expect to develop a more complete billing and accounting system for those departments which elect to
handle this function. Our basic concept is to keep
computerized ledger sheets on direct access files. For
active accounts, this record will contain both itemized
charges and a record of payments made. Inactive
accounts will be transferred to tape and/or paper files.
The goal is to provide a billing system which is responsive to human direction and can make any patient's
bill accessible for review and, if necessary, correction
on-line.
Another type of information which MARS can pro:,
vide automatically is a statistical analysis of the
department's work load. The rapid growth of services
1002
Spring Joint Computer Conference, 1972
delivered by radiologists means that additional equipment and personnel must be acquired almost continuously. In deciding just what piece of equipment
should be purchased next it is obviously valuable to
know what types of examinations are being performed
most often. We assign a statistical code to each entry
in the exam table which defines for the System how we
want our utilization counts broken down. When a
report is transmitted the appropriate counts are
incremented. These figures are stored by the day during
any month. At the end of the month totals are printed
out, and at the end of the year a monthly breakdown
is produced.
Another operation in the department which is
amenable to automation is management of the X-ray
files. Currently roentgenographic images are stored on
large films. All films for a patient are usually stored
together in one or more large jackets which in turn are
filed according to patient number. Films are pulled
from the files either for use within the department or to
be loaned to referring physicians for use outside the
department, for use in conferences, clinics or in the
operating suite. Since the X-rays themselves form a
part of the medical record, the radiologist being legally
responsible for them, it is obviously essential to have a
system for keeping track of who has checked out what
films. It is also necessary at times, to send out "overdue"
notices. Current films are also pulled for review by
referring physicians within the department viewing
area. Since these films do not leave the department, it
is not necessary to check them out. However, it is not
uncommon for a doctor to request films which have been
checked out. Under any of these circumstances a
harried search through the department, and through
multiple scraps of paper ensues. Some tracking of the
films within the department is accomplished by logging
the patient in and reporting the case. It would be
possible to create additional check points to further
ameliorate this problem.
Finally, any time a patient is examined in radiology,
all of the patient's previous X-rays are pulled for review
so that the radiologist may detect for changes in the
a.rea examined, or so that he may correlate the findings
from examinations of other areas. In order to reduce the
delay caused by pulling the old films, MARS transmits
a request to the file area as soon as the patient is logged
in at the reception area.
One of the ways in which radiologists attempt to
meet increasing patient loads is by keeping existing
facilities busy through scheduling of examinations. In
our department only those examinations which require
the participation of a radiologist have been scheduled.
In particular, nearly all patients have been simply sent
from the clinics to the department without any prior
warning. To alleviate this problem we have developed
an on-line appointment book. A referrjng physician, or
his secretary, may call the radiology reception area and
request that a given exam be scheduled for his patient
at a particular time. The System opens the appointment
book to the appropriate day, and checks to see what
has already been scheduled. If the schedule is tight, the
System warns the receptionist who can then attempt to
get another time which is more convenient for the
patient, his physician, and the department. Each
morning the schedule is printed out allowing our
personnel to plan how they will meet the projected
patient load. A longer range goal for this MARS module
is to provide for a constant on-line reevaluation of the
work load by the System, which might then make
specific recommendations such as assigning individual
patients to specific examination rooms.
A potentially great advantage of having a radiologist
interacting with a computer is that the machine may be
able to assist them interpret the films. There are several
possible techniques for this. Perhaps the simplest of
these is retrieval of useful medical data. We have a
growing file of radiological information arranged
hierarchically by organ system, and subdivided by
diseases or roentgen findings. This film may be examined
on-line by the radiologist while he is reporting. A
slightly more complicated method of assisting the
radiologist is to provide him. with a logical tree for the
analysis of certain diagnostic problems. The radiologist
is asked a series of questions about the findings on the
films and depending upon his answer to each question
another appropriate question is asked until he reaches a
leaf on the tree. Typically this will be a list of diagnostic
possibilities. Another technique which may be employed
is that of Bayesian analysis. The radiologist is asked to
specify whether certain findings are present on the films,
and the System then uses estimates of the frequencies
with which these findings occur in various diseases to
estimate probabilities for the diagnoses. Such programs
are available for the diagnosis of pulmonary nodules,
heart disease, and thyroid dysfunctions. The tree
branching and Bayes techniques have been combined
into a program for the analysis of solitary bone tumors.
Many investigators are becoming interested in collecting
the type of data required to attack diagnostic problems by means of these techniques.
There is great pressure on the medical profession to
produce more patient care with no loss in quality and
without further increasing the cost to society. Computer technology holds the promise of helping us to
reach that goal. Our efforts in developing MARS have
been to automate the practice of radiology. In doing
this we have made changes from the traditional practice
of our specialty; we feel that we have improved it.
MARS
Certainly there is need for further work. The use of
computers for training radiologists and radiological
technologists has not been thoroughly investigated.
Technological advances on the horizon such as high
quality microfilm systems for storage of roentgenograms,
or electronic equipment to transmit images will both
augment the possibilities for automation, and may
well require sophisticated data processing systems to
have their full impact. Finally, we are beginning to see
some practical possibilities for direct computer analysis
of the X-rays themselves. The task of demonstrating the
feasibility of automated systems, of developing costeffective systems, and of educating the medical profession to use them effectively should provide a challenge for many years to come.
BIBLIOGRAPHY
W J WILSON A W TEMPLETON A H TURNER
G S LODWICK
The computer analysis and diagnosis of gastric ulcers
Presented at 13th Association of University Radiologist
Meeting Seattle Washington May 14-15 1965 Radiology
Vol 85 No 6 pp 1064-1073 December 1965
1003
G S LODWICK P L REICHERTZ
Computer assisted diagnosis of tumors and tumor-like
lesions of bone
The Limited Bayes' Concept Proceedings of Symposium
Osseum London April 1968
A W TEMPLETON G S LODWICK S D SIDES
J L LEHR
RADIATE: A project for the synthesis, storage and retrieval
of radiologic consultations
Digest of the 7th International Conference on Medical
and Biological Engineering 1967 Stockholm, Sweden
A W TEMPLETON P L REICHERTZ
E PAQUET J L LEHR G S LODWICK
F I SCOTT
RADIATE-UPDATED and redesigned for multiple
cathode-ray tube terminals
Radiology Vol 92 No 1 pp 30-36 January 1969
P L REICHERTZ A W TEMPLETON J L LEHR
E PAQUET F B BIRZNIEKS
Design and implementation of ODARS, an on-line
diagnosis and reporting system
Presented by Dr Peter Reichertz at the 12th International
Congress of Radiology Tokyo Japan October 1969
J L LEHR R W PARKEY L J GARROTTO
C A HARLOW G S LODWICK
computer algorithms for the detection of brain
scintigram abnormalities
RADIOLOGY November 1970
"Sailing"-An example of computer animation
and iconic communication
by STEPHEN M. ZWARG
National Security Agency
Ft. George Meade, Maryland
INTRODUCTION
abstract symbol manipulative, computational power of
the computer and the concrete world of visual imagery
(in an animated movie in this case) it was hoped to
study the problem of idea expression and perception
through images. The motivation for producing a computer animated film was simple-it was a course requirement for a graduate seminar led by Prof. William
Huggins at Johns Hopkins University. Titled Iconic
Communications, the intent of the course was to produce a movie, and thereby develop 'and learn the computer related techniques, as well as develop the potential of iconic modes of communication by research in
the related areas of: computer graphic systems and devices and data structures; machine perception, pattern
recognition, and syntax of pictures; memory, perception, and cognitive psychology; education, geometry,
and visual syntax.
The use of the visual process for the perception and
assimilation of ideas is well recognized by educators,
psychologists, as well as computer scientists. The popularity of movies and television and the concomitant
growth in visual literacy of the viewers of these media
are two factors exploited by those who wish to communicate ideas using these media. The world which
comes across on the movie or TV screen is the camera's
eye view of the visual world (as opposed to our visual
field, that which our eyesight and brain perceive of the
visual world, or "reality," see Gibson6) ; and as such it
is an image of reality. This can include images of
beautiful scenery, complex human interactions, or of a
printed page illustrating a lecture. Any ideas which are
communicated by these devices, while relying upon
imagery, tend to inform the viewer by creating the
illusion that he is there, so how and why would he act,
or they inform him by straightforward strings from
some generally accepted language (as in the case of a
screen full of text). Bruner, a cognitive theorist, feels
that information acquisition proceeds through three
stages:5
1. Enactive-using personal action
2. Iconic-perceptual organization and integration
of images
3. Symbolic-using a language or accepted set of
representations
As a child develops he progresses through these three
stages. Most of the things we learn in school or from
books are by symbolic means. Imagery can back up
symbolic and enactive paths of learning with varying
degrees of success.
Iconic communication itself, using pictures, figures,
or visual images in combination with motion in the
cases of movies, cartoons, and TV, is not so well understood as an idea transporter. With the fusion of the
Iconic Communications
This sort of interdisciplinary study was interesting
as well as very fruitful for those of us in technical fields,
such as electrical engineering or computer science, who
were looking for new applications or who only vaguely
1005
1006
Spring Joint Computer Conference, 1972
understood present applications of advanced computer
graphic technology.
OTHER COMPUTER ANIMATION SYSTEMS
The use of computers for the production of animated
movies is not new. Several on-line and off-line methods
exist with varying. degrees of interactive capability.
Baecker3.4 at M.LT. produced the GENESYS system,
making use of the TX-2 computer and graphics system,
which permitted the animator/operator to specify on
the graphic screen (1) images to be moved about as
well as (2) schedules by which they were to be moved.
All of this was done on-line and little or no programming was necessary by the animator. The images used
were anything that the user could draw, alleviating
him from tediously specifying coordinate input. The
feedback of results was immediate. One result of taking
programming away from the user was that the computer spent its time keeping track of the animator's
on-line doodlings instead of offering computational or
problem solving power directly toward what to do with
these doodlings. The specification of pictures and their
driving functions was very good for simple and fast
cases but not really suitable for an extended animated
effort. Spending a short amount of time to produce a
short sequence tended to make the effect of the image
short-lived.
Others, including Anderson1 •2 and Knowlton8 •9 spent
their time developing elaborate list processing languages
and stacking data structures (as in CAMP and
BEFLIX). These specialized languages required much
understanding on the part of the. animator but his
facility for taking advantage of the computer's computational power rose correspondingly. The usual technique was to write the program in the specialized movie
language, run it on a computer graphics terminal, film
it, and then postprocess the film to add color or special
effects. Some strikingly beautiful films were produced
by Knowlton at Bell Labs and are available on loan
from there. Not much attention was paid in these
efforts to what images were used or what ideas should
be communicated. Visual effects were sufficient to prove
the technology.
More recently, at the University of Pennsylvania's
Moore School, Talbot, et al.,9 have attempted to fuse
the on-line interactive approach to movie specification
with the remote computational p::>wer of a large computer for the final movie production. They also developed a specialized hierarchical language (with a
formal Backus N aur syntax specification) for the animator to specify his pictures, motion, scenes, and movie
segments. The on-line activity consisted of drawing on
the DEC-338 scope, working in one of the picture
definition modes mentioned above, and then reviewing
the rough construction of the movie immediately. When
the animator was satisfied with his rough draft he
entered transmission mode and the outline of the movie
was sent to a remote IBM 360/65. There the draft of
the movie was translated into the final movie generation
commands to drive a SC-4020 microfilm plotter. The
main point was to be able to review movie production
at any stage as well as to specify everything on-line.
Data entry was again a problem, figure manipulation
awkward, and no concentration was made on types of
images, what thejr effects and relationships should be
and how to get ideas across. The preoccupation with
hardware and syntax specification has obfuscated idea
communication.
THE MOGUL SYSTEM
Our animation system at Johns Hopkins possesses all
the so-called drawbacks. It is not on-line, no expensive
graphics equipment is available, only a second generation IBM 7094 computer. Turn around for the finished
movie is slow since no SC-4020 plotter is owned either.
Tapes must be sent someplace that has one, delaying
things by several weeks. Short term feedback of a coarse
nature is available from the computer's line printer, and
outputs can be had within an hour or so, typical of a
batch operation. The draw package used by animators,
entitled MOGUL-Movie Oriented Graphical Utility
Language7 and developed by Prof. Huggins, Tom
Hoffman, and Jerry Yochelson, is a FORTRAN based
system and requires that the user understand that
widely known language. As such, though, the user has
at his command all the computational routines he can
program. Data input for animator specified images in
two or three dimensions is as easy as FORTRAN allows.
The time invested in learning how to program and
working out movie scenes on graph paper is well invested, however, and may even overcome all the previously mentioned handicaps, or at least show that lack
of equipment is not always a handicap. Those of us
with programming experience enjoyed the 'ability to
work with an animation system in a familiar language.
The preciseness of a computer language (but not the
restriction of a special purpose language) and the slight
delay in feedback of results made us be more sure of
what we wanted to see, and eliminated the draw it and
play it right back looseness of on-line systems. We
found that for at least 75 percent of the movie's preparation the immediate feedback is not necessary if we
"Sailing"
had a good idea (through time spent on a storyboard
and basic visual techniques) of how the movie should
go. Admittedly the final polishing up would have been
easier with immediate checks, but costs prohibited this.
1007
mum position of trim-that point at which the forward
driving arrow is longest.
Arrows disappear. Boat shrinks back to normal size
and continues on its second lap around the now appearing racecourse. After reaching leg three it slowly shrinks
to nothing and heads toward the edge of its world.
THE IDEA OF THE SAILING MOVIE
Since all of my spare time during the summer is
spent on the water, when asked to make a film about
an idea, the one which naturally occurred to me was
that of a sailboat making its way around a race course,
thereby demonstrating basic sailboat aerodynamics.
The first step in my animation effort was to layout a
storyboard. This is the sequence of key scenes in the
movie along with a brief explanation of what is happening. Briefly the storyboard of the "Sailing" movie goes
like this (see Figures 4-9, also an intermediate version
16mm film of "Sailing" and several other students'
works is available),u An outline of a boat with mast
and sail appears, centered on the screen. The boat
representation is similar to those found in sailing text
and rulebooks, reinforcing its familiarity. The boat then
shrinks as a race course appears. The course consists of
three flag buoys and wind arrow, pointing from left to
right. The boat shrinks to normal size and begins sailing
around the course. The boat tacks up the first leg,
illustrating the relative position of boat and sail necessary for movement against the wind. The boat reaches
down the second leg, jibes, and reaches down the third
leg, with the sail farther out moving faster than on
the first leg. Midway up the first leg again the boat
grows, buoys disappear but wind arrow remains. The
next sequence attempts to demonstrate the aerodynamic principles of a sail in terms of force vectors and
parallelograms of forces. Three arrows grow out of the
center of the sail representing forces acting on the sail.
One is parallel to the wind arrow, the sum of forces
developed by the wind; the other two are perpendicular
and parallel to the surface of the sail, the components.
The component perpendicular to the surface of the sail
in turn has components parallel and perpendicular to
the axis of the boat. The first of these will drive the
boat forward while the latter will drive it sideways.
With a keel or centerboard the sideways force is largely
resisted. The forward driving force acting on the boat
then results. Arrows in the forward and sideways
directions are drawn. Two, force rectangles are now on
the screen. They grow and shrink simultaneously with
the wind arrow to illustrate that forces developed are
proportional to wind velocity. The various component
arrows grow and shrink and change direction as the
sail is overtrimmed and overeased, illustrating the opti-
DEVELOPMENT OF GENERAL ANIMATION
TECHNIQUES
One of the goals of the movie experience was to develop some general rules, heuristics, or theories upon
which future work could be based. At least we could
find out some things not to do. One of the greatest
difficulties concerned the use of symbols or images to
express ideas. Which are "correct," "good," or "effective," etc? What is the criterion (or grammar) for
judging visual images? How does one even make graphic
an idea without moving from the iconic to the symbolic
level of communication? The medium is hard line black
and white to start with. Using any sort of standardized
symbols or representations immediately brings on a
whole set of preconceptions (or ignorances) and prejudices on the part of the viewer, and if these are not
complementary to the idea being shown they can sidetrack the communication process. In the case of the
sailboat, I felt that anyone who thought of sailing rulebooks when he saw my sailboat would be thinking of
rules and principles, and that was what I was trying to
show so it was a useful image.
The use of text or ma.thematical languages was also
discussed. We felt that any reliance upon text should
be minimized. Words or letters only detracted from the
intent to stay at the iconic level. When used for emphasis, reinforcement, or clarification, however, text has a
place. Similarly, mathematical symbols or any other
formal symbolic language more often than not gets in
the way of the showing, if not also the conceptualizing
of visual explanations. Languages are useful here only
in the knowledge that they can be called upon sometimes to write down the process being shown. The
literacy of the audience with respect to the language
being shown (or not shown) must also be considered.
One thing that had to be well worked out in advance
and which was a continual cause of surprise after finally
viewing the movie was the layout of images or occupancy of the screen. Given a full, two dimensional
square or three by four rectangle for a screen we were
acutely aware of empty spaces. The full screen has to be
used for motion and action for full spatial effect, but
by no means should it be filled with clutter. One of the
main advantages of the medium is that it is completely
1008
Spring Joint Computer Conference, 1972
~~l~
D
Production Cycle
~
1
StrombergCarlson
SC-4020 Plotter
Magnetic Tape
Figure l-Steps to produce an animated movie
bare bones, stripped of all extraneous detail, and this
should be used to best advantage by retaining a simplicity of imagery bordering on paucity. The center of
the screen is the key spot for any important activity or
attention getting. Split screen or simultaneous occurrences divide attention and effectiveness.
Abstractions and relationships are difficult to portray.
The choice of images, their size, relative position, order
of appearance and movement all can suggest functions,
relationships, and dependencies. There is the difficulty
of avoiding coincjdental though erroneous suggestions
of relations versus the valid suggestions of intended
relations. Does the fact that one object precedes another
on the screen or that it is larger than another indicate
that it is more important? If one event happens before
another does it imply cause and effect or time sequence?
Questions like this have to be considered for individual
cases to be sure that the animator's intentions are being
realized. Importance is often indicated by size, positioning at the center, illumination (blinking), and
motion. The relationship of cause and effect was never
satisfactorily protrayed. In one film the anthropomorphic symbol of a detached hand had to be introduced to cause a switch to be thrown.
The obvious capability of a movie for showing motion
cannot be too strongly stressed. Without background
sensory cues, however, some sort of frame of reference
has to be established to inform the viewer of his or an
object's motion. A world of lines, edges, and boundaries
is being dealt with, not one of textures and surfaces.
Motion of objects within the screen boundaries can
mean all sorts of things. The capability of the computer
to calculate regular paths also adds to the possibilities.
If two objects move simultaneously, or in some synchronized fashion, or with the same pattern an obvious
relationship suggestion is being put forward. One problem engendered by the capability of (and the expectation of) motion in the movie is that of' bringing images
on and off the screen. Should they just appear, pop on,
or should they grow or should they come on from the
left (or right)? For the illustration of static concepts
this is more of a worry than for cases where motion on
and off the screen can seem natural.
Timing is the other major tool the animator has to
work with, but it is also the most difficult to handle
properly. Difficulties in the proper use of the screen
area can be resolved using the line printer output, but
timing problems never are fully resolved until the completed movie is seen. This is one instance where a preliminary viewing of the movie on a graphics terminal
would be useful so that timing could be improved
without making a whole other movie. Slowing down the
action is one way to illustrate importance, up to the
point where things become painfully obvious. Speeding
up activity moves the" viewer over less important or
intermediate material. Judging what fast and slow are
is difficult, though, and we really had to see a boring
thing happening for an interminable time to understand
what too slow was. One rule of thumb we started with
to judge how long a sequence should take was to equate
the timing with how long a verbal explanation would
take. Motion of an object relative to stationary objects
or at a faster speed than other objects is one way to
command attention. Repetition of action, even with
slight variations, is important for facilitation understanding of difficult material. The redundancy of presentation should increase with the complexity of the
visual material. It is in the production of repetitive
sequences of highly redundant though complex material
that the computer comes into its own. Hand animation
requires each intermediate frame of a cartoon to be
drawn while a computer can painlessly calculate endless
Length
Index
Char.
I
n
t
e
n
s.
or
Width
0
p
c
0
d
e
Figure 2-Block descriptor format
"Sailing"
numbers of slightly varying scenes. Pauses in activity
are very useful as punctuation, giving the viewer time
to digest what he has just seen rather than overwhelming him with too much action in too short a time.
Fades, holds in action, and jumps to new scenes also
serve useful punctuation purposes, each with different
effects.
THE MOGUL DRAW PACKAGE
The sequence of steps we followed to produce animated movies is illustrated in Figure 1. The basic tools
the animator has are his skills as aFaR TRAN programmer, the ability to draw points and lines between
them furnished by the MOGUL system, the computer,
IPFREE
Director~
variables:
IPFREE---pointer to list ot tree descriptor pairs
nc not occupied by block points
nc not occupied by block points
IE
---highest index ot
JE
---lowest index ot
JAMAX ---maximum diaension ot XYC
Figure 3-Storage of block information
and the final film medium. The MOGUL system was
developed mostly out of our experience in Dr. Huggins'
seminar and contains those elements of programming
which were always needed for film production, hopefully freeing the animator to deal with image entities
and motions rather than coordinate details. It is a
structured set of functions built of the compiler level
FORTRAN programming language. Those interested
in the complete system should refer to Tom Hoffman's
paper.7 Only the salient features of it will be presented.
MOGUL actually consists of three sections. The first
and largest is the set of drawing functions, the DRAW
package, which enables the animator to create images,
manipulate them, and set up operation codes to be
interpreted when the images are to be drawn. The
second section is the executive portion, MaGI, which
keeps track of frame numbers and screen dimensions.
w
1009
>
Figure 4-Boat sailing up first leg of racecourse
The user defines the dimensions of the two dimensional
real plane in which he is going to draw things, e.g., a
square grid of 1024 points running from 0.0 to 1023.0
in both x and y directions; then MaGI windows any
coordinates outside of this area. When output on some
sort of device is called for, MaGI normalizes coordinates and then calls on some device driving program.
MaGI also administers the mode of movie generation,
debugging or production. The third section, the Device
Driver section of MOGUL contains the device dependent output code to translate from the normalized coordinates of MaGI and command a printer, microfilm
plotter, or scope to produce visual images. The animator's program is actually a subroutine called MOVIE
which is called from MAIND, the first program entered.
MAIND initializes the system, calls MOVIE, then
finalizes the system and returns to the IBSYS Monitor.
The user must return himself (via a RETURN statement) to MAIND to terminate his job properly.
Figure 5-Decomposition of first force vector
1010
Spring Joint Computer Conference, 1972
.,.,.
,
--------4 ..
..
.,
'I
it • • •
*
*t- ••••• _.
Figure 6-All force vectors depicted
Figure 8-Line printer output showing racecourse
The screen is a partition of the two dimensional real
plane with the limits of the partition defined by user
specified parameters. The routine is:
of x and y coordinate points with lines drawn between
them. An object is then a 2 XN real array or block,
with the first row being the x coordinates and the second
row being the y coordinates, or a 1 XN complex array
with the real part equal to the x coordinate and the
complex part equal to the y coordinate of a point.
Blocks have associated with them names, e.g., Boat,
Sail, etc., somewhat indicative of what the coordinate
points represent. This name of the block contains a
pointer to the location of directory information describing the block. The "value" of the real FORTRAN
variable Block is the index of the array XYC where the
directory information for Block resides. Included in the
directory is the length of the block; its index (a pointer
to the location of the block's coordinates in the array
XYC); the opcode which specifies whether no lines,
CALL SETAX (ZLL, ZUR)
or
CALL SETAX (XLL, YLL, XUR, YUR)
where (XLL, YLL) and (XUR, YUR) are the coordinates of the lower left and upper right corners of the
window enclosing the usable screen area. The screen
can also be considered a complex plane with points
whose coordinates are given by a real (x) part and a
complex (y) part. Thus ZLL represents the lower left
and ZUR the upper right points just mentioned, and
ZLL=CMPLX(XLL, YLL)
ZUR=CMPLX(XUR, YUR)
Any object which appears on the plane is a collection
* *
**
****..
.. .. ** *
Figure 7-Force vectors and wind arrow enlarged
*
**
.. *
" "*
Figure 9-Line printer output, closeup of boat and buoy
"Sailing"
disconnected lines, or connected lines should be drawn
between points, or where characters should go; the
width of lines; and the intensity of plotting. Everything
on the screen is specified by a block, facilitating the use
of general manipulation routines which always operate
on blocks. Only by the opcode of a block is the interpretation of its contents determined.
Storage is considered to be a one dimensional contiguous complex array, and all blocks and descriptors
are stored in this array. The array has three equivalent
names: XYC, XYP, and IP, depending on whether one
likes to work with complex numbers, real numbers, or
integers, respectively, as coordinates. In the lower end
of XYC go the block contents. In the upper end go the
block descriptors. Creations, length adjustments, and
deletions of blocks are administered using the index
variables of XYC. XYC is declared in a COMMON
statement, making it available to any subroutine of
the animator.
Figure 2 shows the contents of the directory for a
block. Figure 3 depicts the allocation of storage for
block information.
Storage for blocks is allocated and all housekeeping
of pointers is taken care of by the following functions:
where both are useful, though consistency in calls is to
be preferred to avoid errors. Primitive functions are
available to set or return the value of block directory
information if this is necessary.
Objects to be drawn can be specified in two ways.
Either the animator plots his drawing on graph paper
and then enters the point coordinates, or he specifies
some function to calculate the points. The "Sailing"
movie uses both methods. For example the boat and
sail were entered as points from a drawing on graph
paper, while the mast and buoy were calculated from
an equation for the points on a circle .. Thus, blocks
must be prepared to receive data in several ways. Data
can be loaded point by point into a block with the
following sequence:
CALL BUILD (BLK)
-initializes the function COORD to begin placing
data into BLK beginning at the first column of
BLK.
CALL COORD (Z)
or
CALL COORD (X, Y)
CALL CREATE (N, BLK)
-places the complex coordinate Z or the real coordinates X, Y into the next column of BLK.
or
BLK=CREATE
(N,
BLK)
-makes space for a block of size N and sets BLK
equal to the pointer to the block directory. The
value equals the returned pointer.
BLK=SETUP (N, TYPE)
-creates a block big enough to contain N things of
type TYPE, where TYPE can be connected lines
(N -1 points needed), disconnected lines (2N
points), or characters. Other directory information
is set and the value of the function equals the
pointer to the block.
CALL COpy (FROM, TO)
or
TO=COPY (FROM, 0)
-copies the block FROM into the block TO, adjusting the length of TO if necessary. Directory information is copied also.
Blocks are erased and their space returned to free
storage by:
CALL DELETE (BLK1, BLK2, ... , BLKn)
As can be seen block functions can be effected either by
subroutine calls or by function calls which return a
value. There are cases in writing a movie program
1011
A whole array of coordinates can be loaded into a block
using:
CALL LOAD (I, N, XY, BLK)
or
BLK=LOAD (I, N, XY, BLK)
-loads N coordinates from the complex array XY
into BLK beginning at the I column. The second
usage returns the pointer to BLK as its value.
Once objects to be displayed have been created and
assigned to blocks, the animator must decide what to
do with them. Scaling and translation are the two main
manipulations he may perform, and these are done by
applying arithmetic operations to blocks (which in fact
contain complex, real, or integer numbers, depending
upon interpretation). Complex variables and complex
arithmetic permit handling of two dimensional data
with one statement. Scaling is done by a series of complex multiplications of block points by a complex scale
factor. Translation is done by adding a complex translation factor to every block point.
CALL SCALE (SFACT, FROM, TO)
or
TO=SCALE (SFACT, FROM, 0)
1012
Spring Joint Computer Conference, 1972
-scales the block FROM by the complex scale
factor SFACT and places the results in TO
CALL TRANS (TFACT, FROM, TO)
or
TO=TRANS (TFACT, FROM, 0)
-translates the block FROM by the complex translation factor TFACT and places the results in TO
CALL SCLTRN (SFACT, TFACT, FROM, TO)
or
TO=SCLTRN (SFACT, TFACT, FROM, 0)
-scales and translates
With the use of a scale factor defined as follows:
SFACT=CMPLX(FACTR, 0.0)
ASSEMBLING A MOVIE
Working from his storyboard, the animator knows
what objects he wants to display when. Once he has
entered or calculated the point coordinates of an object
in his program he must specify the dynamics of the
object. The usual method for doing this in FORTRAN
based MOGUL is with DO loops, where the scale and
translation factors change incrementally with the iterations in the loop. This is fine if only one object is being
displayed or if all the objects are scaled and translated
with the same factors. When different sized objects or
different motions are required there must be nested
loops or different factors for each. A movie is then a
series of DO loops where each loop describes some sequence of frames and contains the following basic
elements:
*CMPLX(COS(ANGLE) , SIN(ANGLE»
=MAG (FACTR)*ROTD(ANGLE)
an object will be FACTR times larger and rotated by
ANGLE degrees from its former position. MAG and
ROTD are defined as above in M OGUL. Neither scaling
and translating operations change the data in the block
FROM. Scaling of an object occurs about the origin
about which the object was defined. If the origin is the
origin of the screen coordinates rotations and magnifications will be with respect to this point. A more useful
convention is to define all objects with an origin within
them so regular rotation and scaling will result. Translation occurs with respect to the object's previous
position.
Objects are drawn using the following routines:
CALL DRAW (BLKl, BLK2, ... , BLKn)
-causes the output of the n blocks to the Device
Driver program where they are'drawn according
to their directory information.
CALL DRAWST (SFl, TFl, BLKl, SF2, TF2,
BLK2, ... , SFn, TFn, BLKn)
-causes the scaling by SFi, translation by TFi, and
drawing of a copy of BLKi. The copy is then
deleted leaving BLKi intact. Argument list is one
or more triplets.
To roll the film between frames, one logically calls:
CALL ROLL
-advances film 1 frame.
or
CALL ROLL (NFRMS)
-advances film NFRMS frames.
DO 10 1=1, NFRMS
SFACT (1)=TFACT (1)=CALL DRAWST (SFACT(I), TFACT(I) ,
BLOCK)
CALL ROLL
10 CONTINUE
The computer is doing the job of interpolating and
specifying all the intermediate frames here, where in
conventional animation each frame has to be specified
individually. Even commercial animation studios are
getting away from this frame by frame drudgery,
though, by using over and over certain stock positions,
motions, and expressions for characters. The result is
somewhat crude and jerky animation. One should
really see the old Walt Disney full length animations to
appreciate the Ro1ls Royce versus the Chevrolet approach to animation which is apparent now. Of course
no one can pay 750 artists fifty cents an hour anymore
either.
DO loops progress at a linear rate and all motjons are
not necessarily linear. Variable increments in translation factors must then be calculated. Another difficulty
arises in the drawing of an object composed of various
smaller objects. Other than by nesting subroutine ca1ls
or drawing each component separately in its assembled
position, the big object cannot be drawn all at once
as one large block. There is no hierarchy for nesting
blocks composed of other blocks. In the "Sailing"
movie the boat consisted of a hull, a mast, and a sail all
of which had to move and rotate as an entity. A sub-
"Sailing"
routine was defined which in turn called all these component blocks and then drew them with the specified
parameters.
All of the objects which appear in the film are defined
as prototypes. Some I drew myself, such as the boat,
arrows, and basic sail. Others, such as the wind modified
sail and the mast (a circle) result from calculations.
The prototype blocks all have an origin within them.
For manipulations either the implicit scaled and translated copy produced in DRAWST or an explicit scaled
and translated copy of the prototypes is used to retain
the original models.
CONCLUSIONS
The final movie which I produced for the seminar was
really only an intermediate version, since the MOGUL
system was not complete then. However, it illustrates
all the points I wished to make, and only a few bugs
and the inconvenience of not having all the DRAW
functions sets it apart from the latest version. After
watching it and watching others' reactions to it I am
satisfied that it is getting some of the ideas across I
wanted. The film did reveal to me that I must have
had an audience in mind which had some sailing knowledge. Many more of the little points were picked up by
these people than by those with no sailing background.
The latter saw an interesting little boat move about the
screen, but without any sympathy for the problems of
sailing they missed the basic points of tacking into the
wind and correct sail trimming. The strongest point of
the film (and possibly, the medium) is its absolute
attention getting capability as well as the elimination
of all extraneous background material.
There are limitations to this method of communication. Computer animation has many of the strengths
of a computer directed system but the artist as animator is farther removed from his final product. Though
he is spared the necessity of drawing many slightly
varying drawings and though he can calculate, modify,
and display phenomena not observable or feasible in
the natural world, he cannot express the artistic technique or capability that would be evident if he were
holding the pen. Rather than an artist, an artistprogrammer-psychologist-computer scientist is required. The attempts mentioned earlier to provide online animation facilities to those uninitiated in the ways
of computers only debilit~tes the capabilities of both
parties. Advantage should be taken of the r~quirement
that the animator have some technical knowledge of
the system as well as some awareness of the problems
involved in iconic communications. Perhaps a simple
1013
enough language or computer will be developed some
day which will enable an animator to think out and
then immediately create his cartoon sequence. At the
moment I think this is not true, nor is it necessarily
a bad thing either. The preciseness of computers actually aids in formalizing the images to be used in a
communications process.
The results for iconic communications I think are
just beginning. The visual medium is good, but it
takes too long to get thoughts displayed just right.
Other than generalized heuristics there is no formal
syntax or set of models which can help a potential
image communicator. Measurement of the effectiveness
of idea transmission, validity of images used, relationships portrayed, all these subjects still pose many
questions. Thoughts have been entertained to match
up the computer with a TV screen and dump digital
information in a video format onto black and white or
color monitors. Technically feasible (and marketed)
the concept may lower the cost and time involved in
producing animations, as well as bring the manifestation of computer generated images closer to home.
REFERENCES
1 S E ANDERSON
A list processing system for effectively storing computer
animated pictures
Technical Report TR-67-6 Electrical Engineering
Department Syracuse University Syracuse NY 1967
2 S E ANDERSON D D WEINER
A computer animation movie language for educational motion
pictures
Proc AFIPS 1968 FJCC Vol 33 Pt 2 AFIPS Press Montvale
NJ pp 1317-1320
3 R M BAECKER
Interactive computer-mediated animation
PhD Diss Dept of Electrical Engineering MIT Cambridge
Mass March 1969
4 R M BAECKER
Picture driven animation
Proc AFIPS 1969 SJCC Vol 34 AFIPS Press Montvale NJ
pp 273-288
5 J S BRUNER
Toward a theory of instruction
Harvard Univ Press Cambridge Mass 1967
6 J J GIBSON
The perception of the visual world
Riverside Press Cambridge Mass 1950
7 T V HOFFMAN
MOGUL: Movie Oriented Graphical Utility Language
Manual for Iconic Communications Seminar Dept of Elec
Eng The Johns Hopkins University Baltimore Md Sept
1971
8 K C KNOWLTON
A computer technique for producing animated movies
Proc AFIPS 1964 SJCC Vol 25 Spartan Books NYpp 67-87
1014
Spring Joint Computer Conference, 1972
9 K C KNOWLTON
Computer produced movies
Science 150 Nov 1965 pp 1116-1120
10 P A TALBOT J W CARR R R COULTER
R C HWANG
Animator:
An on-line two-dimensional film animation
system
Comm ACM 14 4 Apri11971 pp 251-259
11 S M ZWARG D KASIK I SMITH
Sailing, make-break switch, and station break
16mm black and white silent film available from author or
Iconic Communications Seminar Dept of Elec Eng The
Johns Hopkins Univ Baltimore Md
BIBLIOGRAPHY
1 W H HUGGINS D R ENTWISLE
Computer animation for the academic community
Proc AFIPS 1969 SJCC Vol 34 AFIPS Press Montvale NJ
pp 623-627
2 W H HUGGINS D R ENTWISLE
Exploratory studies of films for electrical engineering
Report to US Office of Education Sept 1968 Dept of Elec
Eng The Johns Hopkins University Baltimore Md
3 W H HUGGINS
Film animation by computer
Mechanical Engineering Feb 1967 p 26
Computer description and recognition of printed Chinese
characters
by WILLIAM STALLINGS
Honeywell Information Systems Inc.
Waltham, Massachusetts
INTRODUCTION
The methodology of pattern recognition still lacks
any solid theoretical foundation. The author feels that
progress in this area requires building up a body of
effective pattern recognition techniques. It is hoped
that the methods and techniques developed in this
project on a specific class of patterns will be applicable
to other pattern recognition problems.
Specifically, this project deals with a class of patterns
which displays a rich structure developed from a small
number of basic elements, all of which are relatively
simple. The patterns are characterized by the fact that
these elements may be combined in many complex
ways. Other classes of patterns which fit this description
will hopefully benefit from knowledge gained here.
A n approach to pattern recognition
An increasingly important aspect of computer pattern
recognition research is automatic pattern description.
Investigators have emphasized that pattern analysis
should be basic to any pattern recognition scheme. 4 ,l1
Pattern analysis may be defined as the identification of
elements of a structure and the description of the
relationship among those elements. Chinese characters,
by virtue of their regular structure, seem well suited for
pattern recognition based upon pattern analysis.
With this point of view, a scheme for automatic
pattern recognition has been developed which includes
the following tasks:
A Chinese reading machine
(1) Description. A systematic scheme for the
description of the pictorial structure of the
patterns to be recognized is developed.
(2) Analysis. An algorithm is designed which
analyzes the structure of the patterns, producing
a representation of the structure conforming to
the descriptive scheme.
(3) Encoding. From the structural representation of
a pattern, a code is generated which uniquely
identifies the pattern.
Two obstacles have hindered the access of interested
non-Chinese groups to the vast body of written Chinese
produced each year. The first is the difficulty of the
language itself. Chinese is very complex and takes so
long to master that few Westerners ever learn it well.
And second, of course, is the size of the printed output in
Chinese. Manual translation is slow and tedious, and
can never be relied on to handle more than a tiny
fraction of the material.
To make available to Westerners the culture and
technology of one-quarter of the human race, some form
of automation must be introducpd. A Chinese reading
machine, which could scan printed Chinese and produce
English output, would provide the most desirable
means of improvement. Such a machine is a long
way down the road, but individual steps which advance
toward that goal are to be encouraged.
Considerable work has been done in the area of
automatic translation of Chinese. 7 ,12 These efforts have
been only partially successful. Even if a good translation
This method has been applied to the recognition of
Chinese characters. A program has been written which
analyzes Chinese characters; the program produces a
data structure which describes a character in terms of
basic picture elements and the relationship among
them. A procedure has been developed for generating a
numeric code from the structural representation.
Recognition is achieved by building up a dictionary
matching characters with their codes; the code for any
new instance of a character can then be looked up in
the dictionary.
1015
1016
Spring Joint Computer Conference, 1972
device were available, however, the formidable problem
of encoding Chinese characters for input would remain.
One answer to the problem would be the development
of a practical Chinese character recognition machine,
toward which the effort of this project is directed. *
It is hoped that advances in this area would provide
additional incentive for work in translation devices.
On a more modest scale, a Chinese character recognition device could be used as a type of on-line dictionary
to speed up the process of human translation. Even this
limited application would be a welcome advance.
THE STRUCTURE OF CHINESE CHARACTERS
Chinese is a pictorial and symbolic language which
differs markedly from written Western languages. The
characters are of uniform dimension; they are generally
square; they are not alphabetic.
The characters possess a great deal of structure and
hence are well suited to the method of recognition
outlined above. Many regularities of stroke configuration occur. Quite frequently, a character is simply a
two-dimensional arrangement of two or more simpler
characters. Nevertheless, the system is rich; strokes and
collections of strokes are combined in many different
ways to produce thousands of different character
patterns.
Chinese characters consist of sets of connected
strokes. Each stroke is roughly a vertical, horizontal, or
diagonal straight line segment. Sets of connected strokes
form units hereafter referred to as components. Each
character consists of an arrangement of disjoint components. Figure 1 shows a character having three
components.
The structure of a Chinese character may therefore
be specified on two levels:
(2) What sort of structure should be used to describe
the relationship between elements?
Three criteria were used in answering these questions:
(1) The structure should be easy to generate from
the original pattern.
(2) It should be easy to generate a unique numeric
code from the structure.
(3) The structure should represent the pattern in a
natural manner.
A natural method of representing the internal
structure of a component would be in terms of strokes.
This indeed is the approach taken by several previous
recognition schemes. 5 ,8 These schemes make use of
on-line input, in which strokes are drawn one at a time.
The difficulty with this approach for printed characters
is that strokes do overlap and are not easily isolated.
Also, the description of the relationship between strokes
•
becomes complex. *
.:'
II
* The author is aware of one previous attempt at the recognition
of printed Chinese characters.l
•
•
'1···"'"
I'
,
:11 iJ:!:::::::u::I.I::~ldl·
:UI"'U
'
I'
•••••••
::::::::::::
.
::m::m::::
:::::::::::::
"UiiiWW
::!:!::I::
mnj!llI~
I IIIIs
I·nn·ttll
j
nd :
I.,,,.
Jtl"1
.., :I,.,m:.::::::.
I.: .....
:U •• ,IU.
I
(1) What class of objects should be considered as
the basic picture element?
II
11111..111111111111111111
II
Two questions needed to be answered when deciding
how to describe the internal structure of a component:
:::::::::::'
'1"-:"'1
:::.1:' •• :'..... u.. ·Uii:::!U
Ji!!S!',
(1) A description of the internal structure of each
component, and
(2) A description of the arrangement of components
in two dimensions.
Components
::!:::::::...........::::::::::::::
:::1':::1':
I:: 'III:
•••
~W~::·
.1
.....
.......
............
............
............
......
......., .... .
II
•••••••
II
•••••••••
............. ..........
.... ... .
iii:::::::
.., ......
·s,HUP!!!H"
.. •..,.... ··
.....
:.....
......
.....
..........
.........
...........
,'
..,.........
",.,.",
.
...........
..·.........
...........
, ...... .
..
• It' •••••••
:::::::::::.
:mnmH:
• It ••••••••
Figure I-Character with three components
* For a discussion of a system for the description of Chinese characters in terms of strokes, see Fujimura and Kagaya. 3 The authors
are primarily interested in computer generation of Chinese characters.
Computer Description and Recognition of Printed Chinese Characters
/
1017
thetical square. The segmentation of a character into
components segments its square accordingly. The
square, or frame 0, may be segmented in one of three
ways: (a) East-West []], (b) North-South B, (c)
Border-Interior [g. Each of these segmentations
corresponds to a two-component character. For
example, ~ I would be represented by (a), which decomposes the character into "5 and I . 15 would be represented by (b). Finally, either partial or complete
enclosure, such as 9J and ~ would be represented by
(c). Frames for characters eomposed of more than two
components are obtained by embedding (a), (b), or
(c) in one of the sub-frames of (a), (b), or (c). The
process of embedding is recursive, in that any sub-frame
of a derived frame may be used for further embedding.
For example, the four-component character of Figure 3
can be described by the frame arrangement of Figure
4a. The frame description can be conveniently represented by a tree, as indicated in Figure 4b.
This description of the arrangement of components
is based on the work of Rankin,lo who introduced the
concept of frame-embedding. The definition of component used here is slightly different from that of
Rankin. Despite this, Rankin's claim that the three
relations used in his scheme are sufficient to describe
accurately virtually all characters seems to apply .
...
.......
.........
............
............
.............
..............
.................
............
..............
...............
.................
................
~
Figure 2-Component and graph
It is more promising to describe components in terms
of stroke segments. This can best be understood with
reference to Figure 2. As can be seen, a component can
be depicted as a graph. The branches of the graph
correspond to segments of strokes. These segments are
bounded by stroke intersections and ends of strokes.
It will be shown later that this representation satisfies
criteria (1) and (2). That it satisfies criterion (3) is
fairly clear.
Characters
The arrangement of components in two dimensions
to form characters can be described using the concept of
frame. Each character is viewed as occupying a hypo-
................
................
•:::::::::::=:
.::::::::::=:.
............
........
............
..........
...-:::::::::::...............
:::::::::::.
...............
.........
.......
.................
.... ..
..................
..............
.
.•............
............
...........
..........
........
. ..
.............
..............
.
.............
·:ggm::
..
...........
.............
............
..........
..
........
.........
::::::::::::
............
..............
..............
.
............
..::::::::::::::
................
...........
::::::::::::
::::::::::::::: ..
............
..............
................
iii::::::::
.:. .................
.•
......
......
...
...
....
....
....
....
......
......
......
......
.......
.......
.......
........
.........
.........
..........
..........
..:~H~m~~~~~
...............
1IIIIIIlil/lli'
!l lil l ! :!~Ii;
..............
........ .
.....................................
:::::::::::::::::.:::::::::::::=:::::
......................................
::
:::::: ::::::: ::: :::: :::::::: ::::::::
......................................
......................................
.....................................
...................................
Figure 3-Chinese character
IIIIIIIIII'III/i
1018
. Spring Joint Computer Conference, 1972
(a)
inside a small area or "window" on the sheet. If the
intensity reflected relative to the incident intensity at
a point is below a certain threshold, the value one is
transmitted for that point (BLACK), otherwise a zero
is transmitted. (WHITE). The effect is that of placing
a grid over the picture and making each square either
all black or all white.
A program has been written which operates the
scanner and stores the resulting matrix in core. The
size of the matrix is 80 X 80 for a single character.
However, both the window size and the sampling rate
(the fineness of the grid) may be varied so that characters of varying size can be processed. Additionally, the
threshold may be adjusted to achieve the best quality.
Certain functions of the program depend on the fact
that there are no gaps or holes in any of the strokes.
This is not always the case due to the quality of the
printed input. Accordingly, a smoothing operation is
performed to fill in the gaps. The resulting matrix is
used as the data base for the program.
The digitized form of a character can be displayed on
a CRT. Figures 1, 3, 5 and 6 are photographs of such
displays.
Frame Descr1pt1on
,
ANALYSIS OF COMPONENTS
\
(b)
Tree Representat10n
Figure 4-Frame description and tree representation
INPUT
The program operates on a representation of one
character at a time. The representation is in the form of
a matrix whose entries have value zero or one corresponding to white or black on the original printed
picture.
The device used to obtain the matrix is a flying spot
scanner which measures the intensity of light reflected
from an opaque sheet of paper at a number of points
A program has been written to perform the analysis of
components. For a given component, the output of the
program is a connected graph in which branches
correspond to stroke segments and nodes correspond to
the endpoints of stroke segments.
The program is quite complex, and will be described
in detail in a future paper. A brief outline of the procedure is given here.
The procedure begins by finding an arbitrary stroke
segment of a component. This is done by scanning
along various rows and columns of the matrix until a
stroke is encountered (See Figure 5). This initial stroke
segment is the first branch of the graph. Next, the two
endpoints of this initial segment are found. This is done
by crawling along the stroke in both directions. Crawling
is accomplished by following along the boundary points
of the stroke using a standard contour-tracing algorithm.
The crawling halts either at an intersection of strokes,
characterized by encountering a large black area, or at
the end of a stroke. Both of these two conditions for
halting correspond to a node of the graph being encountered.
Thus, one initial branch and its two nodes are found.
The procedure continues in the same manner. For each
of the two nodes, all segments leading from it are
investigated (by crawling), finding more nodes. Seg-
Computer Description and Recognition of Printed Chinese Characters
ments leading from each new node are similarly investigated until the entire component has been covered.
During the execution of this recursive procedure, the
graph of the component is developed as each new node
is encountered.
ANALYSIS OF CHARACTERS
The algorithm for analyzing the pictorial structure
of a character is in two parts:
1. A collection of connected graphs is produced,
one for each component.
2. The relationship among components is determined.
on a separate pattern. That is, the contour points of a
component are filled in on a new pattern as they are
encountered during analysis. The auxiliary pattern
contains, at any time, the outline of all the components
of a character which have been processed.
After a component has been processed, a search is
made for a stroke of a new component. If a stroke is
found, its boundary points are checked against the
auxiliary pattern to determine whether or not this
stroke belongs to an already-analyzed component. In
this way, new components may be found and analyzed.
The procedure halts when no new strokes can be found.
The result is to produce a collection of connected graphs.
Figure 6 shows the result of applying the algorithm
to the character of Figure 3.
Constructing the frame
Finding all components
The program described in the previous section must
be applied to all the components of a character. Some
method must be used for finding each of the components
and keeping track of those which have been analyzed.
To do this, the following procedure is employed.
As a component is being analyzed, its outline is drawn
......
.....
..... ...
...........
...........
.::::::::::'
..........
1019
Representation of the frame description of a character is done conveniently by means of a tree. The root
node of the tree has as its value one of the three relations indicating how the overall frame is broken into
two sub-frames. The two sons represent the structure of
the two sub-frames. Terminal elements correspond to
components (see Figure 4b).
The method of obtaining such a tree will be briefly
described. First, each component in the character is
inscribed in a rectangle. This is easy to do since the
coordinates of each node are known. The relationship
between all possible pairs of components is determined
by determining the relationship between their rectangles. The one of the three permitted relationships
(East-West, North-South, Border-Interior) which most
nearly approximates the true relationship is chosen.
Then it is determined if one of the components has the
same relation to all other components. This will usually
be the case. If so, that component becomes one son of
the root node of the tree; the value of the node is the
appropriate relation; the other son is a tree representation developed for the remaining components. This
sub-tree is determined in the same way.
If no single component is found, a more complicated
procedure is used to determine if any two components
have the same relation to all others, and so on.
ENCODING OF COMPONENTS
~mg:::·
Figure 5-Finding a stroke
For recognition purposes, a procedure has been
developed for generating a numeric code for each
character. The first step in this procedure is the generation of a code for each component in a character.
Spring Joint Computer Conference, 1972
1020
••
••
••
••
••
••• •••
• •
••• •••
• •
••• •••
••
••
•
•
••
•
•
••
••
•••
...".,
,,
•o
o
........
0
•••
•
••
•
••
•••
····••
•
•
........
•
•••
e
-
••-
••
.•.
E.:.
.... .t. .... ...
··· ....
·:
.:
o.
· ....
.
·
..
.
..
.
:::
" ........
t
•••
•
•••
••
••
••
•
••
••
•
•
•
:
•
-.
" •
•
•
•
••
•
•
"' .
••
•
::
I:
,t
••
•
_
It
.:.i .i.:
i.
•• ••
•
••-.
••••
...
••
•
•• •
•
•••
.
.•
.
•
••
••
•
•
••
•
•
••
•
•:•
••
•
• ............. •
.
···
I I
.:
.......
e
e'
e
•
6c
•.,
••
e
.
.
o
....................................
·•
I••
t.I .
'"
t
:•
0
,.
L .......
:
..
!
,
"
:
':
00
•••• ••• ••
••
••• •
·
,j
00
•
I:
6a
••
,••
•
•••
:
t.
•
•••
•
:
. ..
·· ....
···· ...
....
.:-.
:.
..
..
:- :
.t ....... ..
•
• •
••
••
•
•
'
••••••••
••
••
••
••
••• •••
• •
••• •••
• •
••• •••
.... ......
t·
I .....
I
••
•
•
·
"
,
,
•
•
•••
•
•••
••
.!I
",
.i..,!. i ./
. . :, :I
...··· ..... : I:I
.
..
.
··.. .... .
t
.
.
·· .. .
i':
.••
.'
..," ,.,.,'"
..
·
•...•.•••..••••.••.••..•........•... ·:
6b
Figure 6-0utline of a character
The code for a component is generated from its graph.
To this end, the branches of a graph are labeled at each
end. The label on a branch at a node indicates the
direction or slope of that branch quantized into eight
::
••• It
0
:
It.
•
........
It
:
::
~
:
.
•
•
,
Io.. ... ..
",:
. ..
I
o
I
o
•
•
./ II'!
:....: i: J i:
.. .
:::
:'
I
I
I
•
..,...., .··
., ., ·:
:
.'
.
:'
f
:.
:
..
o
o
o
•
00
0,
.~
'~'.
to
.~
..............
o
":.i
.
'.
o
•
•
•
.
.:,,,
•
.:
• It •••••••••
........................................
6d
directions. An algorithm can then be specified for start-ing at a particular node of a graph and traversing all of
its branches. The sequence of branch numbers encountered is the code produced. An example appears in
Figure 7.
The algorithm obeys the following rules:
1. Start at the node in the upper left-hand corner
of the graph. Exit by the branch with .the
lowest-valued label. Mark the exiting branch to
indicate its having been taken, and write down
the branch label.
Computer Description and Recognition of Printed Chinese Characters
1021
2. Upon entering a node, check to see if it is being
visited for the first time. If so, mark the entering
branch to indicate this.
3. Upon leaving a node, if there are available
unused directions other than along the first
entering branch, choose the one among these
with the lowest-valued label. Leave by the first
entering branch only as a last resort. Mark the
exiting branch to indicate its having been taken
and write down the label on the branch.
Since at each node there are just as many exiting
branches as entering branches, the procedure can only
halt at the starting node. At the starting node, all
exiting branches have been used (otherwise the procedure could have been continued), hence all entering
branches have been used since there are just as many of
these. The same reasoning can be applied to the second
node that is visited. The first entering branch is from
4
6--~~-- 2
7
o
6
o0
246 206 7 J 4 4 2 6
Figure 7-Encoding a graph
Figure 8-Two characters with same graph
the starting node and this branch has been covered
both ways. But this branch would only have been used
for exit from the second node if all other exits had been
exhausted. Therefore all branches at the second node
have been covered both ways. In this manner, we find
that the branches of all nodes visited have been traversed
both ways. Since the graph is connected, this means
that the whole graph has been covered.
All branches are traversed exactly once in each
direction by this procedure, so all labels are picked up.
The code consists of the branch labels in the graph
written down in the order in which they are encountered.
This algorithm is based on a procedure for traversing
graphs described in Ore. 9
While it is true that this scheme will always generate
identical codes for identical (isomorphic with the same
labels) graphs, the goal of generating a unique code for
each character is not achieved. Two types of difficulties
are encountered.
1022
Spring Joint Computer Conference, 1972
terminal elements correspond to components. Considering the relations as binary operators, the tree can
easily be flattened to prefix form. This is done by
walking around the tree counterclockwise, starting from
the root node, and picking up nodes and terminals the
first time they are encountered. As is well-known, the
string generated in such a fashion is unique; the tree
can readily be reconstructed from it. To generate a
numeric string, the following code can be used:
6
2
o
o
4
4
O~terminals
(components)
node
2~above node
3~surround node.
1~left
6
2
2
6
o
o
Figure 10 shows the generation of code from the tree
of Figure 4.
We can consider that the code so generated defines a
class of Chinese characters all of which have the same
frame description. Therefore, a Chinese character may
be specified by first giving its frame description code
and then giving the code for each of the components
*
4
4
6
2
Figure 9-Two graphs with same code
The first is that two characters might generate the
same graph, hence the same code. Figure 8 gives an
example of such a situation. This situation appears to
be very rare, however, and it seems to be no great
hindrance to make special cases of these characters.
The second difficulty is that two different graphs
might generate the same code. Figure 9 illustrates this
situation. The author has been unable to find any pair of
characters whose graphs exhibit such a property.
Again, this appears to present no great problem.
The method, then, will generate different codes for
different characters with only a few exceptions. The
algorithm is simple and its execution is quite rapid.
ENCODING OF CHARACTERS
The representation of a character is in the form of a
tree. The nodes of the tree are binary relations; the
1012000
Figure 10-Flattening a tree
Computer Description and Recognition of Printed Chinese Characters
that fits into one of the sub-frames. A character having
n components will have a code consisting of the concatenation of n+ 1 numbers:
JIB
•
•
•
•
•
•
•
•
•
•
•
•
1023
•
•
•
•
where No is the code generated from the tree and N 1
through N n are the codes of the components listed
according to the order in which the components were
encountered in the tree flattening.
RESULTS
The algorithms discussed in this paper have been
implemented as a computer program which recognizes
printed Chinese characters.
Most of the program is written in FORTRAN. A
considerable fraction, however, is written in assembly
language. The assembly language routines augment the
power of FORTRAN to permit list-processing operations and also to permit FORTRAN subroutines to be
called recursively. The combination, while less than
ideal, provides for the creation and manipulation of
complex data structures in a fairly natural manner.
The program runs on a PDP-9 computer with a core
memory of 32K words of 18 bits. The computer also has
a large auxiliary disk and magnetic tape storage
facilities.
The program has been tested with a number of characters from several different sources. The tests were
designed to consider four questions:
1. How successful is the program in analyzing the
structure of Chinese characters?
2. Does the program generate consistent codes for
characters of the same font? That is, will two
instances of the same character from the same
source yield the same code?
3. Does the program work for characters from
different sources?
4. Do factors such as character size and character
complexity affect program performance?
Initial results were obtained from a set of characters obtained from a Taiwan printer. A sample of this
set appears in Figure 11. To start, 225 different characters were processed. This was to provide a dictio:q.ary
for later tests, and to test the pattern analysis capabilities of the program.
The results show a reasonable structural representation produced for about 94 percent of the characters.
The failures were all due to a particular component not
being analyzed; for all characters the relationship
among components was correctly determined. The
Figure ll-Example of character set
problems all occurred in the part of the component
analysis algorithm concerned with analyzing nodes;
i.e., the part which is to find a node and locate all
stroke segments leading from it. The routine would
sometimes make mistakes if, for example, two nodes
were very close together or one node covered a large
area. The characters involved were typically quite
complex.
From the characters that were successfully analyzed,
25 were chosen for additional testing. Four additional
instances of each character from the same source were
processed, for a total of 100 new characters.
All new instances of the 25 characters produced
reasonable structural representations. For five of the
characters, one of the new instances produced a slightly
different representation, hence a different code. No
character generated more than two codes. In all cases,
the discrepancy was caused by the fact that two strokes
which were very close in one instance touched in another
instance of the same character.
Additional testing was done using two other sources.
Characters from issues of a Chinese magazine were
used. These were approximately half the size of the
characters in the original set. Also, some computer-
1024
Spring Joint Computer Conference, 1972
generated characters 6 were used. These were about
double the size of the originals. Both were of about the
same style. Fifty instances were taken from each
source. The percentage of instances generating the same
code as the corresponding character from the original
set was 89 percent for the magazine source and 95
percent for the computer source. Discrepancies mostly
had to do with stroke segments appearing at somewhat
different angles and with strokes touching in one case
but not the other.
CONCLUSIONS
Pattern description
A descriptive scheme for the structure of Chinese
characters has been proposed and a program for computer analysis conforming to the scheme has been
written. The description is on two levels: The internal
structure of components, and the relationship among
components.
The first level of description is straightforward: a
connected part of a character is represented by a graph.
This representation is adequate for the description of
components; it is reasonable for the human percipient
to think of components as graphs.
Analysis on this level works fairly well; difficulty is
encountered with some complex characters. Some work
has been done on modifying the described approach.
The modification consists of "shrinking" a component
to a skeleton and obtaining the graph from the skeleton.
This procedure is sensitive to contour noise, and it
seems that use of this method would result in many
components generating several different graphs from
different instances.
The second level of description is based on the work
of Rankin. With the exception of a very few characters whose components do not fit neatly into the frame
description, it is an effective means of describing the
structure of Chinese characters in terms of components.
The analysis program for this level has been successful
for all characters tested.
Pattern recognition
It would be overly optimistic to claim that the results
of this thesis prove the feasibility of a hardware Chinese
character recognition device. The development of
such a device would be an impressive accomplishment.
Nevertheless, the author feels that this thesis points the
way to such a device by providing a good method for
encoding Chinese characters.
There are two separate, but related, problems
associated with Chinese character recognition. The
first is that complex characters may fail to be encoded,
or may generate several codes. The second is that there
would need to be a quite large dictionary of characters'
to handle most material. A college graduate in China is
supposed to know about 5000 characters, which gives
some indication of what would be needed. The problem
of handling a large dictionary arises. This is especially
true if many of the characters require more than one
code.*
It is likely that a recognition device would be used to
process material from mainland China. If this is true,
several developments make things look brighter. They
result from the desire of the Communist Government
to simplify the language. 2 The first is that the Government has recommended the general use of only 2000
characters. A list of these characters has been published.
Publishers, being Government-controlled, are under
instructions to stay within the total of 2000 as far as
possible. Secondly, the Government has simplified a
large number of characters. In 1956, a list of 515
simplified characters to be used in lieu of the original
complex forms in all publications was released. The
average number of strokes per character for the 515 was
reduced from 16 to 8. Overall, since 1952 the average
number of strokes per character has been reduced from
around 13 to around 10 for the 6000 most frequently
used characters. The continuing Communist policy of
language simplification contributes to the author's
opinion that a Chinese character recognition device
is a realistic objective.
ACKNOWLEDGMENTS
The author would like to thank Professor Francis Lee
of M.LT., whose guidance and advice were invaluable
to this project. The author is also grateful to Professor
Thomas Huang of M.L T. and Professor Herbert Teager
of Boston University for their help. This paper is based
on a thesis submitted in partial fulfillment of the
requirements for the degree of Doctor of Philosophy in
the Department of Electrical Engineering at the
Massachusetts Institute of Technology on August 15,
1971.
* One way to reduce the number of characters requiring more
than one code would be to use a stylized font especially designed
for use with a character recognition device.
Computer Description and Recognition of Printed Chinese Characters
REFERENCES
1 CASEY NAGY
Recognition of printed Chinese characters
IEEE Transactions on Electronic Computers
February 1966 pp 91-101
2 Y CHU
A comparative study of language reforms in China and Japan
Skidmore College Faculty Research Lecture
Skidmore College Bulletin December 1969
3 FUJIMURA KAGAYA
Structural patterns of Chinese characters
Research Institute of Logopedics and Phoniatrics
U of Tokyo Annual Bulletin ~ 3 April 1968-July 1969
pp 131-148
4 U GRENANDER
A unified approach to pattern analysis
Advances in Computers Volume 10 Academic Press 1970
pp 1.75-216
5 GRONER HEAFNER ROBINSON
On-line computer classification of handprinted Chinese
characters as a translation aid
IEEE Transactions on Electronic Computers
December 1966 pp 856-860
1025
6 A V HERSHEY
Calligraphy for computers
US Naval Weapons Laboratory 1 August 1967
AD 622 398
7 KING CHANG
Machine translation of Chinese
Scientific American June 1963 pp 124-135
8 J H LIU
Real time Chinese handwriting recognition machine
EE Thesis M. 1. T. September 1966
90 ORE
Theory of graphs
American Mathematical Society 1962
10 RANKIN TAN
Component combination and frame-embedding in Chinese
character grammers
NBS Technical Note 492
February 1970
11 K M SAYRE
Recognition: A study in the philosophy of artificial
intelligence
U of Notre Dame Press 1965
12 L YUTANG
Final report on Chinese-English machine translation
research
IBM RADC-TDR-63-303 10 June 1963
Computer diagnosis of radiographic images*
by S. J. DWYER, III, C. A. HARLOW, D. A. AUSHERMAN and G. S. LODWICK
University of Missouri-Columbia
Columbia, Missouri
INTRODUCTION
is employed by the radiologist to ascertain diseases
such as lung disease, rheumatic heart disease, congenital and acquired heart disease, skeletal anomalies,
and radiation-induced diseases. In addition to the
conventional plain films of the chest, other radiant
images are employed in radiographic diagnostic techniques, such as a cardiac series, fluoroscopy, image
amplification, video tape, and cine radiography. This
paper presents the results of an automatic visual system
for the diagnosis of heart disease from the conventional
radiographic technique employed to form the plain
film of the chest.
The basic technique involves the conversion of the
chest film to a two-dimensional array of numbers, each
number in the array representing the transmittance
of light through the film at a particular point on the
film. Analysis is then carried out by pattern recognition methods on the digitized image as implemented
by the digital computer. Four steps comprise the automatic visual system for diagnosis of heart disease from
the chest film.
The first step is the digization of the X-ray image. A
specialized camera scans the film which is illuminated
from the back, producing an output voltage whose
average value is proportional to the amount of light
transmitted through a particular point on the X-ray.
Each such point is selected by the computer directly
controlling the scanner camera. The optical image is
thus converted point by point into a two-dimensional
array of numbers, each of which represents the "grayness" of the image-that is, the gradation of light and
dark on the film-at a particular point.
The second step in the process is that of preprocessing.
These techniques are designed to enhance the extraction of selected features and to eliminate irrelevant
data in an image. A number of these techniques have
proven useful. Gray level histograms are employed
to determine if a distribution transformation should
be employed. Spatial digital filtering methods utilizing
the fast Fourier transform or recursive partial dif-
The potential of optical scanning equipment and
digital computers for assisting or replacing human
judgment in medical diagnosis has been recognized
by investigators for some time. 1 A number of efforts
have been made, with varying degrees of success, in
developing automatic techniques for recognizing and
classifying blood cells, 2 chromosome analysis and
karyotyping, 3 identifying leucocytes, 4 and processing
scintigram images5 obtained in nuclear medicine. These
image analysis techniques are now being extended to
the clinical specialty of diagnostic radiology where
there is an urgent need to provide assistance in handling
the several million radiographs read by radiologists
each year. The need for computer-aided diagnosis in
radiology is becoming increasingly urgent because of
the expanding population and the continuing demand
for improved quality of medical care. The use of computers in radiology can free the diagnostic radiologist
from routine tasks while providing more accurate
measurements that lead to consistent and reliable
diagnoses.
The most common radiological examination is the
conventional chest film. The resultant film is a complex
image consisting of a two-dimensional projection of a
three-dimensional object, whose structure reflects
the absorption of X-rays as recorded on film. Such
films commonly offer photographic resolution of 40
line pairs. per millimeter. Chest films are commonly
called for in routine medical examinations and are
used by physicians to determine the health status of
the patient. In the case of coal workers' pneumoconiosis
("black lung disease"), chest films are even employed
as the basis for determining federal compensation to
the individual workers. The chest film examination
* This
work was partially supported by USPHS Grant GM
17729.
1027
1028
Spring Joint Computer Conference, 1972
ference equations may be useful. Contrast enhancement is often employed, especially if the digital
processed images are to be displayed. Finally, image
subtraction is often used to remove irrelevant image
information.
The third step is that of feature extraction. The
actual selection of an image feature set is a significant
problem in itself for which no general theoretical
solution exists. One reason for this difficulty is that a
set of features required for classification-normal or
abnormal samples for a particular disease-is relative
not only to the class of images but also to the diagnostic
problem under consideration. Also, features needed for
one diagnostic problem are useless for another problem.
The most difficult portion of an automated image
analysis system is that of feature extraction. Techniques which are useful in the feature extraction portion
of the process are directional signatures, contour
tracing, Fourier transform frequency signatures, template matching, region enumeration techniques, and
linguistic methods.
The fourth, and final, step in the process is that of
automatic classification. Successful use of pattern
recognition techniques requires that all four steps in
the process be carefully designed, depending upon the
specific problem to be automated. In the case of chest
films, classification schemes that have proved useful
consist of discrimination functions, both for the normal-abnormal two class problem and for the differential diagnosis-the further division of the abnormal class into subclasses of diseases.
DIGITIZATION OF THE CHEST X-RAY FILMS
Chest films are scanned with a computer-controlled
specialized camera that produces an output voltage
whose average value is proportional to the amount of
light transmitted through a particular point on the
X-ray.
The system as depicted in Figure 1 performs three
categories of operations: (1) the conversion of images
in the form of film transparencies into digital arrays of
numbers; (2) the storing of these arrays in an orderly
fashion to facilitate retrieval for use by researchers;
and (3) the redisplay of these and other picture arrays
either to produce a photographic copy or for direct
viewing. The conversion of film to numbers is accomplished either by a flying spot scanner (FSS) or
an image dissector scanner (IDS) which utilize an
image dissector camera in the digitization. Both of
these devices operate under the control of a digital
computer which also handles the flow of data from
scanner to magnetic tape unit.
The digital images are recorded on 800 BPI magnetic
tape during the scanning process, becoming permanent
entries in the image library. The library consists of
digital images stored on IBl\l-compatible magnetic
tape in a special library format that facilitates locating
and using every entry in the library. An identification
record containing scanning parameters and content
information is written at the beginning of each image
on a library tape. A library index in punched card form
contains identical information and is updated as new
images are recorded.
The third function which the system performs is the
reconstruction of real images from digital form. Three
separate devices accomplish this. The first device is a
Hewlett Packard 1300A X-Y display scope with a
x-axis input. Second is a Dicomed/30 Image Display,
manufactured by Dicomed Corporation of Minneapolis.
The third device is a digital image display utilizing a
high speed disc memory which is filled at slow data
rates, and then dumped at high data rates as video
information to a high resolution, high tonal television
monitor display. Another distinguishing feature of
this device is its interactive capabilities. Through the
use of a joystick the operator may extract certain
features of the displayed image and enter these into
the computer.
Central to the operation of both scanning and display
devices, the SEL 840A digital computer acts as controller and information channel for the system. The
SEL 840A is a small scale computer with a memory
cycle time of 1.75 microseconds and 16K of word
memory. A minicomputer could also perform the
necessary tasks. An IBlYI compatible tape drive is
necessary for library creation.
FlYING
0
DIGITAl
DICOI£D / 30
IMAGE DISPLAY
COMPUTER
SCANNER
0
DATA ACQUISITION
RADIANT
IMAGE
INPUT
IMAG~
SCANNER
CRT DISPLAY
SYSTEM
01 GIT Al/ ANAlOG
ANAlOG/DIGITAL
01 GITAL/DI GI TAL
INTERACTIVE
JOYSTICK
HIGH RESOLUTION
TV DISPLAY
Figure I-Digital image scanning, storage and display system
Computer Diagnosis of Radiographic Images
1029
Digitization devices
VIll:O
Two digitization devices have been employed in the
digitization of chest films-the flying spot scanner
(FSS) and the ima~e dissector scanner (IDS).
NOISE REf>I:lVAL
SYSTEM
VIDISSECTOR
CAMERA
SEL 840A
DIGITAL COMPUTER
ANALOG/DIGITAL
X&YDEFLECTION
AMPLIFIERS
CONVERTER
Flying spot scanner
FILM
~---
The flying spot scanner has seen wide use as an
image digitizer. Serving as two devices in one, the FSS
can also reconstruct hard copy photographic images
from digital form. For this reason the FSS is sometimes
chosen as both the digitizing and reconstruction instrument in many image analysis applications.
The basic components of an FSS system are shown
in Figure 2. When the transmittance at a pair of particular coordinates on the film is to be measured, a dot
is illuminated on the CRT at a corresponding location.
The position of the dot is controlled by X and Y deflection voltages which are usually generated by digitalto-analog converters. These converters are an integral
part of the SEL Computer Data Acquisition System
which operates as a peripheral device to the SEL 840A.
An image of the computer-positioned dot of light is
focused upon the film by the lens. The amount of light
passing through the film is measured by a photomultiplier tube positioned behind the film. This signal
contains some error due to the fact that the brightness
of the dot is not entirely uniform over the surface of
the CRT. To account for this error the beam is interrupted by a beam splitter and the intensity of the dot
is measured by a second photomultiplier. Both signals
from the photomultiplier tubes contain a good deal of
electron shot noise. This must be removed by extensive
filtering prior to analog-to-digital conversion of the
signals. The ration of transmitted signal to reference
signal, calculated either digitally or by analog tech-
'--_ _-----<
DIGITAL/ANALOG
CONVERTER
X&Y OCFLECTION
SI~ALS
Figure 3-Image dissector scanner system (IDS)
niques, is the the quantity of interest. This measurement is repeated rapidly for all of the locations in the
picture raster.
To reconstruct photographs from digital images
unexposed film is placed in the FSS and the dot intensity and position are controlled so as to expose the
film. The reference photomultiplier measures the
amount of exposure that the film is receiving.
Factors affecting the resolution or ability to delineate
fine detail of a flying-spot scanner system include CRT
spot size, lens resolution, film image contrast and
sharpness, and phototube signal-to-noise ratio (SNR).
The resolution obtained in an FSS system seems to be
proportional to the cost spent in constructing the
device. An inexpensive, low resolution FSS has been
implemented and will scan 3" X 3" film size at a
limiting resolution of 256 samples across the film. This
has proven quite sufficient for low-resolution image
analysis applications. Very high resolution has been
attained elsewhere but at a tremendous increase in
cost. A disadvantage of the FSS system is that it is
difficult to scan large format films such as full size
medical radiographs.
I mage dissector scanner
SPOT
COORDINATE SIGNALS
FROM SEL DAS
Figure 2-Flying spot scanner (FSS)
The image dissector scanner is the second digi tization device utilized. The distinguishing component
of the IDS system as depicted in Figure 3 is the vidissector camera, manufactured by International Telephone and Telegraph Industrial Laboratories. The
camera employs an image dissector tube to sample the
input image.
The image dissector has been described as a photomultiplier with a small electronically movable photocathode area,. thus acting as an all-electronic lowinertia microphotometer. The image to be scanned is
focused by the camera lens onto a 1.75 inch circular
photocathode. Electrons are emitted from the back of
1030
Spring Joint Computer Conference, 1972
the photocathode, forming an electronic image with
current density modulated according to the image
input. The electron image, focused by magnetic deflection, falls upon an aperture plane, at the other end
of the drift tube. The aperture "samples" the image
by allowing only a small, well defined area of the electron image to pass through. The sampled photoelectrons
are then multiplied by an electron multiplier by a factor
of approximately 5 X 105• The entire electron image is
deflected allowing the aperture to sample different
points in the picture.
The input image is a chest radiograph measuring
13Y2 by 13Y2 inches and illuminated from behind by a
DC powered, high intensity light source. The camera
deflection signals are generated by the SEL computer
and converted to analog in the SEL data acquisition
system. Deflection buffer amplifiers are used to adjust
the amplitude and offset of the deflection signals.
Eleven bit DAC's are used to allow for scanning rasters
of 2048 X 2048 points, although this actually exceeds
the resolution of the camera.
The noise current present in the video output of an
image dissector camera system can be attributed to
random fluctuations of photo-electrons entering the
aperture, modified by the statistical noise properties
of the electron multiplication process. It is necessary
to remove this noise prior to analog-to-digital conversion. This is accomplished by integrating the video
signal for a suitable length of time. The resulting
signal-to-noise ratio becomes a function of tube construction, input image brightness, and integration
time. The integrate time can be selected, but 800 microseconds is a common time. This relatively long integrate
time gives a SIN ratio of over 40 DB for a relatively
bright input image. This has been verified by digital
frequency analysis of the video signal.
The resolving capabilities of an image dissector are
determined by the shape and size of the dissecting
aperture, usually a circular aperture of diameter 1 mil.
This configuration gives a resolution modulation
amplitude of 39 percent at 1000/TV lines per inch on
the photocathode. The usable diameter of the photocathode is 1.4 inches, given a resolution of 1400 TV
lines across the image diagonal.
Logarithmic conversion via a logarithmic video
amplifier allows recording of the optical density of a
film, rather than transmittance. This is an optional
feature, allowing better gray shade condition in the
darker areas of a film. An 11 bit analog-to-digital
converter is used for the video signal, a more than
sufficient number for gray-shade rendition. However,
this allows less critical adjustment of the video signal
amplitude to insure sufficient quantization levels.
A definite advantage of the IDS system over the
PSS system is its ability to scan large format films,
such as 14 inch by 14 inch radiographs. With proper
optics the IDS can scan small format also. A disadvantage of the IDS system is the inherent nonuniformities in the illuminating light source. Cathode
non-uniformity can be typically ± 15 percent over the
usable surface, while light source non-uniformity depends upon construction of the source. In the PSS
non-uniform CRT response could be compensated for
in real time by the reference photomultiplier. For the
IDS the correction had to be made by scanning a blank
film and then subtracting or dividing each subsequent
scan, point by point, by the reference image array.
Subtraction was used for density scans, while division
must be used for transmittance scans. Figure 4 shows
the IDS.
Display devices
Two digital display devices are utilized to examine
the processed image-a dark trace storage tube display
and a disc memory-TV display.
DICOMED 30 image display
A display device used for examining the processed
chest X-ray images is one that is designed and manufactured specifically for displaying digital images
(Figure 5).
Figure 4-The image dissector scanner system
Computer Diagnosis of Radiographic Images
The DICOMED/30 Image Display is a product of
the DICOlVIED Corporation of Minneapolis, Minnesota. The device interface with the computer is purely
digital and is operated like a computer peripheral. The
display utilizes a unique type of CRT called a dark
trace storage tube which uses a scotophor instead of a
phosphor to produce the image. The scotophor is
deposited upon the 8 inch viewing surface of the tube.
When struck by the electron beam it becomes more
opaque and remains so until it is erased by thermal
neutralization. This is in contrast with a phosphor CRT
which glows only momentarily when it is struck by
an electron beam. This almost infinite persistence
characteristic of the dark trace storage tube makes it
ideal for converting digital images into a usable form.
Under program control the DICOlVIED display
"paints" an entire image, one raster point at a time,
upon the CRT viewing surface. When illuminated
from behind by a viewing light, the CRT face portrays
the reconstructed image which remains in full view
vvithout need for refreshing by the computer. Thus,
with this device, the user can either view the reconstructed image directly or he may desire to make a
photograph of it.
The DIC01VIED display has a set 1024 by 1024
square raster superimposed on the 8 inch circular
\ viewing surface. With digital pictorial data that consists of fewer raster points only a portion of the viewing
also need be utilized or, if one wishes, the smaller
rasters can be interpolated at display time up to the
set 1024 point raster of the display.
SEL 840A
ACQUISITION
DIGITAl
SYSTEM
DIGITAl
PICTURE
INFORMATION
HIGH SPEED
72 BITS
BUFFER
24 BITS
COMPUTER
1031
72 TRACK
DISC
UNIT
DIGITAl.
iO
ANALOG
CONVERTER
OD
~AGNETIC
TAPE
Figure 6-High speed disc image display system
The display and its associated control program can
reconstruct an image from magnetic tape in approximately 100 seconds, the time being nearly the same
regardless of raster size. The image that is produced
has high resolution and can contain up to 64 distinct
shades of gray. The contrast ratio of the display is a
maximum of 3 to 1 but this can be improved upon when
producing "hard copy" by using high contrast film
and high contrast paper to print the resulting pictures
on. The erasure of images is automatic and takes about
15 seconds to complete one erasure. This is accomplished
by heating the scotophor until the scotophor returns
to its neutral state. The storage property of the DICOMED Image Display makes it ideal for converting
digitally coded pictorial data into a useful form.
Disc memory-TV display*
Data transfer rates of conventional magnetic tape
drives and digital I/O channels are much too slow for
flicker-free CRT or TV display of high resolution
digital pictures. In the high speed disc-display system
digital picture information is fed to a disc memory a~
these slow rates, then dumped repeatedly to a television monitor at rates high enough to produce a flickerfree image. The system operates as shown in Figure 6.
The image data is read from magnetic tape at interface
rates, then dumped via the SEL DAS digital I/O
channel into a 72 X 16 bit buffer array. When full,
the array is dumped to the disc. The disc is a Data
Disc which has parallel read/write capabilities on 72
tracks of 100,000 bits per track. The disc will hold up
to three 525 line pictures or one 945 line picture at a
time. Once the disc has been filled with the desired
picture information, the computer is free to perform
other tasks, as the display then acts as a stand-alone
facility. The image information is read in parallel by
72 heads, converted to analog form by high speed
Figure 5-The DICOMED model 30 digital display
* Development supported in part by NSF
Grant 20401.
1032
Spring Jojnt Computer Conference, 1972
or disc. Another use would be to take measurements of
objects in the image. Figure 7 shows the display.
COMPUTER ANALYSIS
Figure 7-Disc memory-TV display
DAC's, and displayed as an image on the the television
monitor at 30 frames per second with interlaced alternate frames, producing a flicker-free image. A control
s'witch determines which of the three 525 line images
on the disc is to be displayed.
The television monitor itself has a resolution of 1800
TV lines per picture width, adequate for many applications. The monitor also has a contrast ration of 10 to
1, a substantial improvement over the DICOMED
display. Also, picture fill time for a 525 line image is
less than 20 seconds compared to 100 seconds for the
DICOMED /30 display.
One of the most distinguishing features of this
image display system is its interactive capabilities.
Although interactive displays are quite common in
graphics applications, an interactive high tonal, high
resolution image display is a rarity.
This interactive mode is accomplished by using an
interactive module which employs a joystick to position
a dot of light on the television monitor. The joystick
generates X and Y analog voltages which are digitized
and compared with the X and Y coordinates being
displayed on the monitor. When a match occurs, the
image information at the location is ignored and a
white dot displayed instead. The X and Y coordinates
of the dot may be displayed on a digital readout panel
or they may be sent upon command into SEL memory
via the digital channel on the data acquisition system.
In this manner objects in the image field may be outlined and that outline recorded in computer memory
Once the image has been converted into an array
whose values represent the gray shades in the image,
the data are processed on a digital computer for the
purpose of identifying and extracting the relevant
features of the image. We presently use an IBM
360/50 computer in this processing. It is helpful to
consider the structure given in Figure 8 while discussing
an image processing system. Stage 1 in this figure has
been discussed in the previous section.
In the preprocessing stage, stage 2, one can usually
devise methods, such as filtering routines and other
preprocessing routines, that are adequate, but not
optimal, for the later stages of processing. In some of
our studies on chest X-rays we have found that we
need no preprocessing. In some of the studies in nuclear
medicine a simple averaging technique suffices, which
reduces the data to a resolution of 32 X 32 approximating the resolutions of the input camera. Some of
the more useful preprocessing techniques will now be
discussed.
Distribution linearization
Because image digitization requires that each gray
level value be quantized over a finite range (e.g., 6 bits/
Digital
Conversion
Equipment
Feature
Extraction
Automatic
Recogni tion
1. Digital conversion equipment - The camera and associated
analogue to digital conversion equipment required to convert
the image into an n x n array of points whose entries give
the brightness value of the image.
2. Preprocessing - Programs used to suppress the noise put
into the image data by the digital conversion equipment and
also programs used to emphasize certain properties in the
image that are more important than others for the later
stages of analys is.
3. Feature Extraction - The extraction from the image data
of information to be used in the automatic recognition of
objects in the image. The data emitted from stage 3 of
processing should be greatly reduced from that of stage 2
of the processing.
4. Automatic Recognition - The automatic recognition of the
important objects in the image by the computer.
5. Human Observation - A human interpretation of an improved
image.
Figure 8-Image processing system
Computer Diagnosis of Radiographic Images
picture element), a histogram of the gray level distribution values may be computed.
The gray level histogram (first order probability
density function) of most images exhibits a brightness
peak which is heavily biased to the dark side of the
histogram. 6 ,7 The digital representation of the radiograph has 256 X 256 brightness values over a 33 X 33
centimeter face, with a sampling frequency in either
dimension of .78 lines/mm. The effect of having a
large percentage of the 65,536 picture elements (pixels)
concentrated into such a narrow portion of the histogram is an image with little visible detail. Many contrast ratios that define edges are simply not displayable.
One technique frequently used to correct this is the
application of logarithmic conversion of the brightness
pixels. This yields pixels which are proportional to
image film density rather than brightness. 8 The log
operation has the effect of expanding the gray range
of the lower brightness pixels while compressing that
of the higher brightness pixels. However, because of
the shape of the brightness histogram, there is much
more contrast expansion than compression.
Because a more rectangular histogram is advantageous, a position invariant, nonlinear histogram
equalization technique, similar to the distribution
transform in statistics9 , is useful. Since the distribution
transformation is only true for continuous variables,
some care must be taken to obtain the desired result
for the discrete approximation.
Linear filtering
Several techniques for spatial and frequency domain
design of spatial digital filters will now be considered.
Digital smoothing is designed to remove noise from
images so that later processing will be made easier.
Smoothing is usually done by either spatial or frequency
domain operations.
One method is to average over a neighborhood in the
spatial domain. The basic idea is simply to assign a
neighborhood to a point and then change the intensity
value of the point by performing an average of all its
neighbors. 10 In addition, gradient functions may be
set up in various directions in order to test whether or
not the averaging process should be performed. An
attempt is made to prevent blurring edges or points
where significant pictorial information occurs. Noise
removal depends intimately upon the nature of the
pictures which are being processed. That is, what
appears to be noise may be a significant feature in a
particular picture.
These averaging methods can also be performed in
the frequency domain. One takes the input picture in
1033
digitized form and performs the discrete Fourier transform or equivalent methods. The smoothing operations
that have been discussed can be performed by removing
the high frequencies in the frequency domain. This
operation is called low pass filtering. Instead of merely
deleting the high frequencies of a picture in order to
remove noise, often a selected band of frequencies will
be deleted while enough of the high frequencies are
left to keep the edges clear.
When an image is low pass filtered, the image contrast
is generally unaffected. However, edge detail is effectively removed.ll Other types of filters can be developed based on a low pass prototype.
Enhancement techniques have an obvious potential
for assisting roentgenographic diagnosis. The ability
to sharpen detail, for example, and to employ nonisotropic filters to make a hairline fracture more evident, could :result in more correct diagnoses, especially
when combined with high resolution display equipment
for human viewing.
The effect of high pass filtering on an image is to remove the contrast information of the image while outlining edges. The edge outlining effect can be seen most
obviously at sharp, high contrast ratio edges. A maj or
application of high pass filters is in the visualization
of small, low contrast features superimposed onto
uniform backgrounds. 12 ,13
A filter which partially suppresses the lower frequency
components while enhancing those higher is the high
emphasis filter. It should be noted that both the high
emphasis and high pass filters create negative brightness pixels. These usually appear as dark bands surrounding the sharper, high contrast ratio edges in an
image.
Feature extraction
Feature extraction consists. of the extraction of
significant features from a background of irrelevant
detail. lVlethods for the enhancement of selected features
and elimination of irrelevant detail have just been
discussed. In this section, several techniques for the
extraction of significant features from an image function w.ill be described.
The selection of an image feature set is a significant
problem in itself, and no general theoretical solution
exists. One reason for this difficulty is that the set of
features required for classification of normal or abnormal samples for a particular disease is relative not only
to the class of images but also to the diagnostic problem
under consideration. Also, information which is pertinent to one diagnostic problem may be irrelevant to
the solution of another problem.
1034
Spring Joint Computer Conference, 1972
would correspond to energy at a given radial distance
in the transform space.
I
Template matching
I
I
I
Suppose that an image function of known form
which is non-zero only over a finite rectangular region
is perturbed by additive noise. The filter which maximizes the ratio of signal power to average noise power
at the filter output at some spatial position is called
a matched filter.15 A detection decision may be made
by sampling the matched filter output at the position
and comparing this value to a threshold. A matched
filter detection is not affected by a translation of the
signal; however, it is sensitive to rotation. The matched
filter is also sensitive to magnification changes. If only
a small size variation in the desired signal is expected,
then a search through several sizes may be reasonable.
~
I
I
I
HORIZONAL
SIGNATURE
Directional signatures
LG
Figure 9-Directional signatures for chest radiograph
Fourier transform frequency signatures
The utility of spatial frequency power-spectrum
sampling for automatically classifying patterns in
images was demonstrated by Lendaris and Stanley,14
with particular applications to detecting targets in
aerial photographs. The purpose of this section is to
consider the applications to biomedical images.
The usefulness of frequency sampling is based on
the fact that certain features of an image function may
be more distinguishable in the frequency domain than
in the spatial domain. Also, a large data reduction may
be affected and the features still distinguished.
The frequency signature consists of a set of n samples,
where n is the number of sampling areas for a given
sampling geometry. Several sampling geometries may
be used. An annular ring sampling geometry is suited
to the detection of circular objects. A wedge shaped
geometry can be used to detect periodic line structures
in an image. A horizontal or vertical slit may be used
to detect an axis feature. A well-known property of the
two-dimensional Fourier transform is that the transform of a circularly symmetric object is also circularly
symmetric. Thus, if one is trying to detect circular
objects, an annular ring sampling geometry is appropriate. Peaks in this circular sampled signature
A simple but powerful technique for locating objects
in fixed frame images consists of gray level directional
signatures (e.g., Meyers, et al.).16 A fixed frame image
set consists of images of similar objects; for example,
chest, head, or leg X-rays. Normalization is a significant
but solvable problem. The directional signature consists of a function which is the sum of the gray level
pixel values along a line normal to a reference line. The
x and y direction signatures for a chest X-ray are shown
in Figure 9. Note that major objects such as the clavicle,
the lungs, the heart, and the diaphragm, may be located
from the signatures. The signature information allows
one to "zoom" in on a particular object. After an object has been located, measurements such as size or
texture may be made.
Contour tracing
Edge structure is a significant feature in many
radiographic images, and motivates the development
of computer algorithms for extracting edge information. These programs are often called contour trace
programs. A position in a picture where two objects
meet will be characterized by a change in the gray
shades in the picture array. This has suggested a
search for points where the rates of change (deviations)
of the picture array PIC (I, J) are large. Once these
points are found, some form of logic is then used to
connect these points together to form the boundary
of the object. There are variations in these techniques
including level slicing and contour tracing, but the
Computer Diagnosis of Radiographic Images
results tend to remain much the same. This method
has several problems. First, due to the noise that will
invariably be present in the picture atray, contour
trace algorithm will tend to give gaps and false spurs.
If there are touching and overlapping objects, a contour
trace program will tend to switch from one object to
another before a boundary of an object is completely
traced. Contour trace programs are local algorithms
and as such have the following problems: If mistakes
are made, such as gaps, they must be corrected later.
If there are several objects in the scene, a contour
trace algorithm has no way of knowing that it is following a particular object and must be careful not to
stray from it. Therefore this technique suffers from
the problem of making mistakes which are passed on
to the later stages of corrections,namely the pattern
recognition stage. Thus, there is the very real problem
of errors accumulating through the various processing
stages.
Another method that has shown some utility is often
called region enumeration. This method tends to be
the inverse of contour tracing. In this method a point
x = (i ,j) in the picture array is located, perhaps by
a raster scan, and one desires to identify the points
that lie in the same region with x. There will be a
property P(y) that one uses to determine if a point y
is in the region. First, one finds x; then one examines
the 8 neighbors of x. Let y be one of these points. If y
has the property P, then y is placed in the region with
x, otherwise it is not placed in the region. The process
is repeated spreading out from x until all the contiguous
points with the property P are placed in the same region.
Often the property P will relate to the gray level of
the point. For example, does point y have the same
picture value as x? Or an average gray value of the
region may be kept and y is tested to see if its picture
value PIC(y) is close to the average value. Other P's
can also be used. There are variations of these techniques in which one uses thresholding with region
enumeration. Thus, we see that region enumeration
seeks to identify all the points in a region, not the
boundary points, and to do this it places points in the
region if it is not on the edge of the object, while contour tracing looks for edge points.
1035
method to the analysis of AP chest X-ray with the goal
of diagnosing abnormality in the heart and lungs. Since
that time, the same program has been applied to AP
X-ray of the knee and nuclear medicine images. There
are several basic assumptions behind this method.
(1) The analysis of a scene should be top down.
(2)
(3)
(4)
(5)
(6)
That is, one should first analyze the large objects in the scene at the lowest possible resolution
and later analyze the finer objects in the scene
as details of the large objects.
Feature extraction and pattern recognition must
be combined into a reinforcing system, i.e., a
system with feedback. That is, feature extraction is not a separate process from pattern
recognition; pattern recognition is an integral
part of feature extraction and must be included
from the beginning.
One must have within the program a comprehensive description of the class of scenes to be
analyzed. This description must guide the scene
analysis system from beginning to end. The
description should be in the form of data to a
scene analysis supervisor so that one can readily
analyze different scene classes without extensive
reprogramming.
Regions enumeration rather than some form of
contour trace program should be used in primitive objective identification.
All parameters in the program must be selfadjusting.
The concept of field of vision is important in
locating the true boundaries of objects. In many
applications one must not only recognize the
objects but must also determine the exact
boundary of the object. An example is chest
X-rays where one needs an accurate contour of
the heart in order to diagnose heart disease. We
believe that there are advantages in recognizing
the fact that a scene is composed of objects
that completely fill the area of a scene, i.e., every
point in the picture is in some region and one
always sees something even though it may be
lumped into a catch-all category of background.
These objects all fit together in jigsaw fashion
to completely fill the space of the scene.
The descriptive approach to image analysis
An approach to feature extraction that we usually
refer to as the descriptive approach will now be briefly
described. Other authors have described related work
but have not applied it to radiographs. 17 ,18,19 ,20 It is
possible that this method can be applied to a number of
medical picture classes. Thus far we have applied the
A graphical description seems natural in implementing assumptions 1 and 3. In particular a tree
structure very naturally gives a top down description
of the scene class. See Figures 10 and 11 for examples.
In the program described in Reference 21 each node of
the tree represents an object in the picture. The graph
is data to the program. Thus when one changes picture
1036
Spring Joint Computer Conference, 1972
expressed in PL/I notation
Clavicle
(L(7)IB(7)I(R(7) & (B(6)IL(6))))1
(U(7) & (B(4)IB(6)IL(6))))1
(L(7) & R(7)))I(U(7) & B(7))
stem
Figure lO-Anteroposterior view of chest
classes, one changes the data which describe the scene
class. Attached to each node is a list of attributes for
that object and a predicate that describes the objects
relation to the other objects in the picture. The attributes might include such facts as:
(a) average gray level
(b) average number of points
(c) shape description such as higher order moments.
An important point to note is that using a top down
search for the objects can be located with widely different resolutions. For example, our current version for
the chest searches for the level one objects (diaphragm,
mediastinum, right lung region, left lung region) at a
16 X 16 resolution.
One does not have to analyze the entire X-ray at
once; one should first distinguish these objects from
each other. If one desires very accurate descriptions
of the borders, one can switch resolutions easily, retaining the information found at the lowest level. When
our present program switches resolutions, it merely
declassifies the boundary points between objects, then
switches resolution and reenters the point classification program which decides to which object the point
belongs. Thus, in moving to higher resolutions one
merely reshapes the boundary to get an accurate description of the object.
The predicates attached to each node can be very
valuable in identifying the objects. Many times an
object in a picture has a border that has wide variations in the intensity of the picture function at the
border. In places the border may not be visible at all.
The predicates are a way to define the boundary of an
object when the boundary may not be visible. For
example, in Figure 11 consider node 7 and the predicate
This says that a point x can be put in a region associated
with the left arm region only if one of the following
conditions holds for the initial regions linked to the
node which represents the left arm, Node 7.
(a) Region (7) is to the left of the point. This lets
the region 7 grow without hindrance to the edge
of the picture.
(b) Region 7 is below the point. Hence, the arm
region can move toward the top of the picture
without hindrance.
(c) Region 7 is to the right of the point and region
6 is either below or to the left of the point.
The other parts of the predicate are interpreted similarly.
Observe that the left arm region is thus controlled
by the left lung region and points cannot be added to
the region unless the left lung region lies to its left.
Hence, the border is controlled by the predicate which
reflects what the picture is of as well as the gray level
characteristics of the picture. Figure 12 gives an
example output for a program that we have implemented.
A program for the automatic computer diagnosis of
rheumatic heart disease has been recently developed
at the University of Missouri. 22
The goal for this study was classification of the
heart size from the standard PA chest radiograph into
normal or abnormal category. If the cardiac size was
judged abnormal, a further sub-classification was
Node 5
Medi as ti num
Area
Figure ll-Partial vertical ordering of AP chest X-ray picture
Computer Diagnosis of Radiographic Images
1037
Figure 12a-Node 4-Diaphragm area
Figure 12c-Node 9-Right lung
accomplished into four separate categories of rheumatic
valvular involvement. To test the basic normalabnormal classification further, some non-rheumatic
cardiac abnormalities in adults were also used as test
cases. A test set of 279 cases was used. This set in-
cluded 191 cases of rheumatic heart disease representing all combinations of rheumatic valvular involvement.
All patients in the abnormal group have had right
and left heart catheterization and appropriate cine an-
Figure 12b-Node 6-Left lung
Figure 12d-Node 5-Mediastinum
1038
Spring Joint Computer Conference, 1972
Figure 13c
Figure 13a
Figure 13d
Figure 13b
Figure 13-Cardiac contours outlined by computer
Computer Diagnosis of Radiographic Images
giography to establish the correct diagnosis; 88 normal
chest examinations were also selected from patients
with no history of cardiac disease, no murmurs, and
no cardiac symptoms. These were obtained from routine
psychiatric admission chest X-rays and preoperative
and employee chest examinations. The normals were
selected generally from the age group of 20 to 45 in an
attempt to match the age group range of the rheumatic
heart disease patients included in the set of abnormals.
The first 135 cases selected as the computer testing
and training set were set aside as the radiologist test
set library. This separate library includes normals and
all categories of rheumatic heart disease, and comprises the basis of comparing the diagnostic accuracy
of the computer and the radiologist.
The first step in the feature extraction process was
to extract size, contour, and shape of the heart from
the standard PA film. This was accomplished by an
algorithm that constructs a cardiac rectangle around
the heart. The cardiac rectangle is variable in size
which is dependent upon the heart size. This cardiac
rectangle is obtained by spatial signature analysis.
Onc.e the cardiac rectangle was located, a technique
for obtaining the closed cardiac surface was developed.
The technique involved thresholding a gray level
1039
histogram to produce a one-bit (two level) representation of the chest image within the cardiac rectangle.
The algorithm, using a gray level histogram, determines
the threshold for converting the extracted cardiac
rectangle into a two-bit representation (black and
white) image of the heart.
The next step was to outline the cardiac contour
from this black and white representation. With the
left and right outlines determined, the intersection of
the right cardiac edge and the diaphragm was determined and a line was drawn from this point across to
the intersection of the left cardiac edge with the
diaphragm. A line was also drawn to connect the right
and left top of heart (TOH) outlines so that the entire
heart and portions of the pulmonary arteries are
enclosed. A typical example is shown in Figure 13 a-d.
Area and extent measurements are now easily made
from this closed contour. At this point, nearly all information from the standard P A chest radiograph
needed for the diagnosis and classification of heart
disease had been extracted, and the next step was
measurement of the heart. The measurements taken
are shown in Figure 14.
All cardiac measurements were normalized so that
a ratio figure was obtained. The linear measurements
were divided by Thr, the thoracic width, and the area
measurements were divided by T A, the thoracic area.
This allows correction for variation in heart sizes related to the patient's overall size. The same algorithm
can also be used for different film input sizes, i.e."
standard 14 X 17 inch, 35mm reduction, or chest photofiuorograms.
Once these series of heart measurements have been
extracted from the cardiac rectangle, this information
was used as the basis for first classifying the case as
normal or abnormal. If a particular case was abnormal, the classification went further by placing the
case into the correct group of rheumatic heart disease.
The diagnoses were divided into 5 classes and the
16 possible combinations of aortic and mitral valve
disease were divided into 4 separate groups. The
classes considered by the classification scheme were:
Class 1 : Normal
Class 2: Mitral Stenosis only
Class 3: Other mitral valve lesions-MSMI; MI
only
Class 4: Aortic and mitral involvement
Class 5: Aortic involvement-ASAI, AS only, AI
only.
Figure 14-This shows the measurements and two polynomials
extracted by the algorithm after the feature extraction phase
has been accomplished
Computer classification was accomplished through
the use of linear and quadratic discriminant function. 23
This classification method was selected because of its
1040
Spring Joint Computer Conference, 1972
Testing
Number
Radiologist
Image Analysis
Laboratory
Training
Image Analysis
Laboratory
Class 1, Normal
88
83%
88%
94%
94%
Class 2, MS
33
50%
21%
33%
33%
Class 3, MI, MS-MI
21
54%
10%
14%
29%
Class 4, Bivalvular
87
29%
72%
75%
70%
50
76%
48%
62%
60%
62%
62%
69%
68%
Class 5, Aortic
Total
Overall Percent
Correct Classification
279
Figure 15-Rheumatic heart disease classification results
relative simplicity and speed. Initially each part of the
classification was processed using both the linear and
quadratic discriminant functions. The selection for
using a quadratic or linear discriminant function for
each group in the final classification scheme was determined by the results: that discriminant function
was chosen which gave the best results. If the accuracy
was equal for both discriminant functions, the linear
discriminant function was selected for the final classification scheme because it required less computer
processing time.
In order to estimate the unbiased capabilities of the
computer diagnostic classification scheme for the
evaluation of new samples, the "jackknifing" test
procedure was instituted. This procedure consists of
first withdrawing ten percent of the cases from each
of the five classes. The remaining ninety percent of the
cases in each class with their measurement parameters
and polynomials are then used to train the classification scheme. Each case in the withdrawn group is
subsequently tested and classified into one of the five
diagnostic classes. The withdrawn ten percent of the
cases are then replaced into their respective classes,
whereupon a different ten percent is withdrawn, tested,
and replaced in an identical manner until all the cases
have been tested. No case was tested more than once.
This is a fair test, since in each case the algorithm had
not "seen" the withdrawn test set until asked to make
a diagnostic classification. A better test would probably
have been to remove one case at a time and test each
using the jackknifing procedure until all of the cases
had been classified. However, this was not practical
because of the large amount of computer time involved.
It would be difficult to judge the value of this automated feature extraction and classification algorithm
unless its accuracy could be compared to the diagnostic
accuracy of radiologists. For this reason, the following
study was instituted.
Ten radiologists were asked to individually diagnose
135 representative cases of the cases evaluated by the
computer. This group of radiologists consisted of 7
board certified academic radiologists and three third
year residents whose training was nearly completed.
Each radiologist was given the P A and lateral views
and told that each case was either normal or rheumatic
heart disease. He was asked to make a complete
radiological diagnosis and record his answers on a form
designed for the study. Each case diagnosed was counted
as one physician's observation. Information on the
forms was then transferred to punched cards and
computer programs were written to separate the 639
physician observations collected. Not all of the physicians completed the task of reading all 135 films. A
comparison of the physicians' results with the computer
results is shown in Figure 15. The Image Analysis
Laboratory results are those obtained using the pattern
classification method just described. The BMD results
are included for comparison. 24
Overall accuracy was 62 percent for the computer
and 62 percent for the group of radiologists. The
overall accuracy was computed from the following
equation:
Overa11 accuracy =
Total number correct diagnoses
.
Total number of cases III test group
This example illustrates that although automatic
computer diagnosis is quite different from the other
methods, it is competitive and may out-perform them.
REFERENCES
1 L H GARLAND
Studies on the accuracy of diagnostic procedures
American Journal of Roentgenology and Radiation Therapy
Vol 82 No 1 July 1959 pp 25-37
2 I T YOUNG
A utomated leukocyte recognition
PhD Dissertation Department of Electrical Engineering
MIT Cambridge Massachusetts June 1969
3 R S LEDLEY
A utomated pattern recognition for clinical medicine
Proceedings of IEEE Vol 57 No 11 November 1969
pp 2017-2035
4 M MENDELSOHN J PREWITT
Analysis of cell images
Annals of the N ew York Academy of Sciences Vol 128
Article 3 1966 pp 1035-1053
5 J L LEHR R W PARKEY C A HARLOW
L J GARROTTO G S LODWICK
Computer algorithms for the detection of brain scintigram
abnormalities
Radiology Vol 97 No 2 November 1970 pp 269-276
6 G NAGY
State of the art in pattern recognition
Proceedings IEEE Volume 56 May 1968 pp 836-864
7 DOl KUNIO
Optical transfer function of the focal spot of X-ray tubes
American Journal Radiation Therapy and Nuclear Medicine
October 1965
Computer Diagnosis of Radiographic Images
8 R H MORGAN
A n analysis of the physical factors controlling the diagnostic
quality of roentgen images
American Journal Radiation Therapy and Nuclear Medicine
December 1965
9 R P KRUGER S J DWYER E C MAHEN
S J DWYER A J CARLSON G S LODWICK
Image analysis of radiographs
SWIEECO Record of Technical Papers Dallas Texas April
1970 pp 147-149
10 R SELZER
Improving biomedical image quality with computers
JPL Technical Report 32-1336 October 1968
11 A ROSENFELD
Picture processing by computer
Academic Press New York 1969
12 E L HALL S J DWYER
Frequency domain design of spatial digital filters
IEEE Information Theory Conference June 1970-Also
University of Missouri-Columbia Image Analysis
Laboratory Technical Report 101 June 1970
13 T G STOCKHAM et al
Nonlinear filtering of multiplied and convolved signals
IEEE Proceedings August 1968 pp 1264-1291
14 G G LENDARIS G L STANLEY
Diffraction-pattern sampling for automatic pattern recognition
Proceedings IEEE Volume 58 February 1970 pp 198-216
15 H C ANDREWS
A utomated interpretation and classification of images by use
of the fourier domain
Automatic Interpretation and Classification of Images
Academic Press New York 1969 pp 187-198
16 P H MEYERS C M NICE H C BECKER
N J NETTLETON J W SWEENEY
G R MECKSTROTH
A utomated computer analysis of radiographic images
Radiology Volume 83 December 1964 pp 1029-1034
1041
17 PREPARATA FRANCO SYLVIAN RAY
An approach to artificial non-symbolic cognition
UILC-ENG 70-223 University of Illinois Urbana Illinois
July 1970
18 I MACLEOD
On finding structure in pictures
Picture Language Machines S Kaneff ed Academic Press
Inc London-Ltd 1970
19 H G BARROWR J POPPLESTONE
Relational descriptions in picture processing
Machine Intelligence 6 American Elsevier Publishing
Company 1971
20 C R BRICE C L FENNEMA
Scene analysis using regions
Technical Note 17 Stanford Research Institute April 1970
21 C A HARLOW J LOTTO D L HALL
G S LODWICK
Feature extraction in images
Technical Report Image Analysis Laboratory Electrical
Engineering and Radiology Departments University of
Missouri-Columbia Columbia Missouri July 1971
22 R P KRUGER D L HALL G S LODWICK
S J DWYER III
Computer-aided diagnosis of radiographic cardiac size and
shape descriptors
Technical Report University of Missouri March 1971
23 J R TOWNES
The Gaussian mixture decomposition of estimated probability
density functions
PhD dissertation University of Missouri-Columbia August
1971
24 W J DIXON ed
BMD Biomedical computer programs
Second edition University of California Press Berkeley and
Los Angeles 1968
The impact of computing on the teaching of mathematics
by WALTER KOETKE
Lexington High School
Lexington, Massachussetts
A discussion of the impact of computing on the
teaching of secondary school mathematics must begin
with an examination of how modern computing facilities have entered and are entering the schools. The
manner in which facilities are obtajned often influences the way in which a mathematics program is
implemented.
Most secondary schools with computing facilities
used by the mathematics department have acquired
their facilities in one of two ways. The key to both
methods, however, is a motivated, aggressive member
of the mathematics department. The reasons for this
motivation vary dramatically, but without such an
"inside agitator" many schools would yet be without
computing facilities.
The first of the two ways by which facilities are
initially acquired centers around the manner in which
the school conducts its administrative data processing.
Several service bureaus that specialize in educational
applications have agreed to run a limited number of
student programs with very little or no cost to the
school. Local industries have been remarkably cooperative in providing limited computer time for the running
of student programs. Many schools have had their own
computing facilities used for administrative processing
for the past 10 to 12 years. These facilities are usually
capable of running student programs in a batch processing mode. The second way of acquiring computing
facilities for mathematics requires that the school
budget additional funds. Although these facilities are
more desirable from an educational point of view, the
add on cost makes them understandably harder to initiate. Such facilities include purchasing time from either
a large commercial time sharing system or from one of
several smaller time sharing services dedicated exclusively to serving the educational community. In fact,
several secondary schools and small colleges have obtained small time-sharing computers that not only
serve their own needs, but also permit them to sell
computer time to nearby shcools-usual1y at a very
reasonable rate. Mini-computers supporting multi-user,
one language systems are being purchased at an increasing rate. Mini-computer systems that support
from one to seven users are now being marketed not
only by the major computer corporations, but by many
smaller companies who claim to tailor the software
and hardware to suit the needs of education. Several
batch processing minis are also available with such op~
tions as optjcal card readers that purport to provide
the speed of batch processing without the inconvenience
of key punching all input.
Having outlined the manner in which computing
facilities are obtained, a discussion of the way in which
the mathematics department uses these facilities is appropriate. During the past six to eight years many
schools have experienced an evolutionary sequence of
four distinct applications. Unfortunately, most school
systems with newly acquired facilities seem to be beginning the same four step process-without deriving
much benefit from the prior experiences of others.
The first of the four steps is to teach programming
for its own sake. The main objective of a course is to
"learn to program." No specific attempt is made .to
explore mathematical topics not required to understand
the programming language. This first step was a very
natural one several years ago when batch processing
FORTRAN was the most widely available language
in schools, but this step should no longer be necessary
with the more user-oriented languages and facilities
available today.
The second of the four steps is to teach a course
most appropriately titled "computer science." The
tcpics of this course usually include a programming
language, an introduction to the "insides" of a computer
and how it works, and some computer related mathematics. This course is almost always offered as an
elective for capable, interested students. The depth of
this course is usually directly related to the computer
1043
1044
Spring Joint Computer Conference, 1972
related experience of the teacher. Several acceptable
textbooks for secondary school students have been recently published for "computer science" courses.
The third step is that of using the computer as a
supplement to the existing mathematics program. Occasional computer related assignments are given that
complement the "traditional" mathematics being
studied. Students generally have not volunteered for a
special elective, but have simply enrolled in a mathematics course that happens to use the computer. This
application is often thrust upon a teacher who is only
half convinced of the computer's usefulness. This leads
to the puzzling dilemma of the teacher's excusing an
occasional student who "doesn't like the computer,"
but the many students who "don't like word problems,
or factoring, or solving a series of three or more equations, or ... " are told that the choice of curriculum is
not theirs. The creative teacher, however, has found
this supplementary work to provide an excellent opportunity to experiment with many different ideas. The
results of such experimentation is one of the factors
leading to the now emerging fourth step of this evolutionary process.
The fOllrth step is that of using the computing
facilities as an integral part of the mathematics curriculum. Computer use does not occur only as a supplementary topic or in an elective course, but is an accepted
part of the regular mathematics program. This step is
just beginning to be achieved in a few school systems.
Although this step is the goal of many mathematics
departments, supporting textbooks are not yet widely
available. This use will, however, develop as the major
application in most secondary schools. In this step the
computer is used as one of several tools available to the
student of mathematics. The computer is used when its
application is appropriate and ignored when it is not.
Let's look more closely at how the computer is used
as a problem solving tool in this fourth step. The problem solving application is not a drill and practice program used to review rote facts, it is not a computerassisted instruction application in which the computer
presents a pre-programmed lesson, and it is not an
application of computer-managed instruction in which
the computer is used to log the progress of individual
students. Rather, the student is given a mathematics
"assignment" just as he is given an assignment if no
computing facilities are available. The difference, however, is that the solution to some of the problems may
require the use of the computer. In many instances, the
student himself must select the problems appropriate
for computer solution. When computer use is required,
the student must write his own program, enter it into
the computer, and complete all required debugging
until a solution is obtained. The only "canned program"
the student uses is the programming language itself
which is the vehicle utilized to solve the mathematical
problems. Students in such a course are likely to average
writing one or more programs per week. They are, of
course, free to write more, but one per week is the number they are required to complete. This type of application is best implemented using some type of interactive terminal. Although batch processing is an acceptable alternative, some important benefits are lost
without on-line interaction.
Implementation of the problem solving application
seems most successful if terminals are available in a
mathematical laboratory rather than a classroom situation. Since a single interactive terminal is most effective
when used by one or possibly two students, classroom
use is not very efficient unless the terminal is being
used as part of a demonstration in connection with
some type of projection device. Although some schools
have unfortunately experienced occasional incidents of
vandalism, an open laboratory in which students are
free to schedule their own use of the computer has
proved very successful in many installations. Although
some type of control is necessary so that many different
students can use the facilities, this control should be
only that which is absolutely necessary. Ideally the only
enforced regulation is one that limits the total time a
student is permitted to use the facility. Such a limit
not only increases the number of students who can be
served, but also forces the student to be "better prepared" when he does use the computer.
How do students using the computer as part of the
regular mathematics program learn to program? They
should be able to learn the required programming as
part of the mathematics course. The programming
language used must, therefore, permit the implementation of sophisticated algorithms yet also be very easy
for the beginner.
The past 12 to 18 months have reflected school systems acquiring computer facilities at a continuously
increasing rate. I suggest that this rate will continue to
increase until it "soars" in another 12 to 24 months.
There are several reasons for the presently increasing
growth rate and the projected increase in this rate. The
importance of these reasons varies among school systems, so the order in which these reasons are listed in
this paper is not significant.
First is the simple fact that the cost of acquiring
computer facilities has been reduced to an acceptable
level. More than one school committee has noted that
computer facilities can now be acquired for less than
the average salary of a teacher, and that's not very
much. The reduced cost has been evidenced in the purchase price of mini-computers, the rental of time-shared
terminals, and leasing agreements of many batch
Impact of Computing on Teaching of Mathematics
processing systems. If there is a single most important
reason for the increased growth rate, the reduction in
price is the most likely suggestion.
A second reason is an increased awareness by both
teachers and administrators that computing facilities
have become a necessary part of the mathematics program. Although controlled experiments with significant
quantitative results demonstrating the value of using
the computer are almost non-existent, overwhelming
qualitative evaluations ardently support the acquisition
of computer facilities. In one of the few quantitative
studies seen by the author, students using computer
facilities and a control group were given a pre- and
post-test in abstract reasoning. The increase in the
group mean of the group using the computer was four
times that of the control group.
The wider availability of BASIC· is the third reason
for the increasing growth rate. BASIC is not here defended as the "best" programming language. It is,
however, offered as the most appropriate language for
present secondary school requirements. Remember that
the primary application of the computing facilities is
problem solving, not computer science. The computer
is to be used as a problem solving tool, thus the programming language itself should not be a problem for
the students. Languages such as FORTRAN and APL
are themselves problems for most students. The language used must also be well documented, not just in
vendor's operating manuals but in the wider literature
of .mathematics. Languages like FOCAL, CAL and
TELCOMP are certainly easy to learn, but they are
not often referenced in the literature. BASIC, however,
satisfies both of these requirements-it is very easy to
learn and commonly referenced in the literature.
A fourth reason for the increasing growth rate is the
also increasing number of teachers who want to and are
qualified to utilize computing facilities with their
mathematics classes. This is partially due to the growing
number of good inservice courses being offered in many
schools of education. Many new inservice courses are,
however, strictly "how to program" classes that do not
help teachers implement their new skill in the classroom.
Local school board pressure to "keep up with the
competition" who have already acquired computer
facilities is the fifth reason. Although this is not a very
defensible reason for action, the movement is in the
direction of improving education so we should accept
rather than condemn it. Such action, however, occasionally results in disastrous experiences when computing facilities are thrust upon unprepared or uninterested teachers.
The sixth and final reason to be listed has not yet
happened, but will soon be responsible for giving additional impetus to the growth rate. The fourth and most
1045
desirable application of computing facilities was as a
tool in the regular curriculum courses. Although this is
now being done in some school systems, it is done without the benefit of a single textbook for the students.
Such textbooks are, however, now being prepared by
several major publishers. When these textbooks are
actually marketed in another 12 to 18 months, large
numbers of already capable teachers wiH have the
materials for which they've been waiting. This should
result in an even greater demand for computing facilities in secondary schools-including those schools that
already have modest facilities that are not yet required
to serve the majority of mathematics students.
Having examined the manner in which secondary
schools acquire computing facilities, the way in which
these facilities are used, and the reasons for the continually increasing interest in acquiring such facilities, we
will now partially answer the most important question-"Why use the computer in the study of
mathematics?"
The history of mathematics shows that the major
emphasis of mathematics has shifted from geometry, to
algebra, to calculus, to non-Euclidian geometry, and
now to algorithms and computation. As the emphasis of
mathematics shifts to best serve the needs of society, so
also should mathematics education. Topics related to
algorithms and computation can no longer be treated
as supplementary; they have become a very necessary
and important part of the mathematics curriculum.
The history of mathematics also reveals that mathematicians have spent a great deal of time creating ingenious ways to avoid computation. Modern computing
facilities have, however, eliminated the need for many
of these clever computational aids. Once difficult topics
have become quite easy, and many new topics have become very important. Quite simply, the computer has
rearranged the priorities of modern mathematics and
these new priorities should be reflected in the mathematics classroom. Consider, for example, the "traditional" student of first year algebra and his accrued
ability to find the zeroes of a function. He can probably
find the zero of any linear function he encounters. If he
was in a fast moving class he can even solve quadratic
functions-especially those that are factorable. Can he
solve other polynomial functions of higher degree? No.
Can he solve any other~type of function? No-he may
not even know that other types o.f functions exist. If
the student is persistent for an additional two to three
years, he will eventually learn Newton's method or a
similar algorithm that can be used to find the zero of
almost any function. The path to this general algorithm
is littered with "useful" techniques such as factoring a
quartic or even higher degree polynomial to obtain the
zeroes. The student in a first year algebra class that
1046
Spring Joint Computer Conference, 1972
has access to computer facilities can study functions
and their zeroes in a very different manner. For example, he can locate zeroes of almost any function by
searching the domain for a change in either the sign or
the slope of the function. This technique will not only
reveal the zeroes, but also permit the student to explore
maximum and minimum values of a function in an informal yet precise manner. There are of course, many
similar examples of now important topics that can only
be taught very superficially if at all without access to
computing facilities. Listing these topics is not, however, the purpose of this paper. Topics that fall under
the general heading of Monte Carlo Methods are fascinating to almost an students. Computing facilities permit the inclusion of some of these now important topics.
Probability and statistics cannot only receive increased
emphasis with computer use, but realistic problems can
be approached rather than superficial models that
don't really communicate the meaning of or need for
the ideas being studied.
In addition to reflecting some of the priorities of
today's mathematics, use of the computer as a problem
solving tool helps teach that which is the real purpose of
all education-how to think. Although teaching students how to think is the goal of education, there is no
course at any grade level in which that is the prime
topic, nor is there any methods course in related teaching techniques offered to prospective teachers. Computer facilities will not immediately change this dilemma, but the analytic and algorithmic thought processes are so much a part of programming and related
problem solving that students cannot avoid learning
them in a well presented course. As one would hope,
there is a great deal of qualitative evidence indicating
that students do transfer these processes to other disciplines as well. Fortunately, a growing number of
mathematics educators have begun to realize that a
student's mathematics education should be judged by
how he reacts to problems rather than by a list of
courses and grades. Computer assisted problem solving
and accompanying algorithmic thought help students
develop a very sound approach to many types of problem solving in many different disciplines.
Some of the ways in which computer use helps develop analytic and algorithmic thought processes might
be clarified by an example. Consider the problem of
describing the solution set of a quadratic inequality. A
traditional text presents this topic by first listing several
specific examples, then asking the student to solve
several other specific examples. In a subsequent class,
the student is told which of his answers are wrong. A
presentation of the same topic with computing facilities
available might well begin in the same manner-but it
would go further. Students would first be asked to solve
a few specific examples using pencil and paper, then
asked to write a program that would permit a user to
enter any set of values for A, Band C, then print the
solution set of the inequality Ax2 +Bx+C>0. To write
the algorithm for such a program the student would
likely have to create and solve many specific examples.
He would not bother with the arithmetic exercise of
solving examples he knows how to complete. Instead,
he could concentrate exclusively on the cases for which
he is unsure of the solution set. When testing this program, as with many other programs, the student must
"debug" his algorithm. He is not faced with a simple
right or wrong situation, but one in which he is likely
to be partially right. He must then determine which
portion is not correct and the required procedure for
correcting it. The entire process of debugging a partially
correct algorithm is a realistic valuable experience that
is rarely encountered in more traditional courses. Few
problems the student will face in any areas of his life
will be countered with a solution that is all right or all
wrong. The solution will be partially correct and will
require repeated debugging.
As computing facilities become available in the large
majority of secondary schools, the students, the
teachers, and the computing industry itself will feel the
effects. The remainder of this paper is devoted to an
examination of these effects. Note that some of these
effects are already a reality while others are the predictions of the author.
The most immediate and obvious effect upon students
is their high degree of motivation. The reason for this
motivation changes from student to student. In fact
most students seem to sustain their motivation for a
shifting set of personal reasons. Skeptics point out that
use of computing facilities in a mathematics class does
not motivate all students. That is certainly true, but it
does motivate most of them. Unfortunately, the same
cannot be said for either the content or presentation of
most traditional classes. Skeptics also profess that most
of the student motivation is simply fascination with a
new type of hardware. Although this might well be
true at first, the source of student motivation soon
shifts to many diverse, more personal reasons. I suggest,
however, that even if new hardware were the one and
only motivating factor, that's fine. Most teachers are
well aware of the fact that motivating· students is at
least half of their job, and they would be delighted to
find any proven method or "machine" that will develop
sustained motivation in their classes.
Another effect upon students is that the present
"ability grouping" of classes will have to be restructured. Since these groupings often represent present
motivation or the results of past motivation, any factor
that significantly alters motivation will also alter the
Impact of Computing on Teaching of Mathematics
groupings. Preliminary evaluations of computer use in
mathematics classes indicate that the gap between the
"good" and "bad" students is significantly reduced.
There are many possible reasons for this. For example,
the "good" students are already highly motivated so
they do not benefit from that aspect of using the computing facilities.
The study of algorithms and computation permits
students to make genuine discoveries. They are able to
develop significant new computing algorithms and improve upon those that already exist. Students cannot
improve upon the proof of a theorem in plane geometry
nor uncover an unknown property of the real numbers.
These are unlikely occurrences at any level of mathematical sophistication, and those suggesting that secondary students often make such discoveries kid only
themselves. Although a skillful teacher could lead some
students to the belief that they have made a discoveryand indeed they often do make personal ones-the discoveries themselves are only contrived and the results
are already well-known. In the area of algorithms and
modern computation, however, the secondary student
is participating in a discipline that is about 20 rather
than 2,000 years old. Many students soon learn that
they can indeed uncover. flaws in existing algorithms,
as well as create new and better ones.
Computing facilities provide many students with a
means for exploring previously unexecutable ideas.
This benefit of computer use has evidenced itself not
only in mathematics but in several other disciplines as
well. A favorite student question, "What if ... ?" must
go unanswered fewer times when computing facilities
are available. More significant than the answer to this
question is the fact that the student has the means to
answer it himself. In 1970 a high school student discovered the 21st, 22nd, and 23rd perfect numbers.
(Perfect numbers are those positive integers that equal
the sum of all their divisors excluding the number
itself-such as 6 l:\nd 28.) Was this student "above
average?" Sure he was-so were Pythagoras, Euclid,
Fermat, Descartes, Euler, and many other brilliant
mathematicians who unsuccessfully sought perfect
numbers during the last 2000 years. Is this student the
greatest mathematician the world has known? Probably
not! He was, however, a creative high school student
with access to computing facilities. I feel that the three
numbers he discovered and the theorems he created
are of less importance than the simple fact that the
entire refining process of idea to theory to algorithm to
execution to proof to announced results was carried out
by a high school student with access to computing
facilities. I contend further that such significant work
will become an accepted if not expected product of
secondary school mathematics during the next decade.
1047
Computing facilities have made and will continue to
make secondary school mathematics more relevant and
more interesting for students. Pinpointing a single
reason for increased interest and relevance cannot be
done as these vary widely between students. The simple
fact that execution of a program provides the student
with immediate reinforcement does much to heighten
and sustain his interest. He quickly learns the extent of
his success, and if he is well prepared with appropriate
test cases, he also receives an immediate, impartial
evaluation of his algorithm. Interest is also supported
by the student's ability to solve a problem in his own
way. No longer will he be told he is wrong because the
first few steps of his procedure are not what his teacher
expected to find. The student can now complete the
entire procedure in his own way, then immediately
confirm the validity of his work.
Students find computer related mathematics relevant
because they are using what they know is modern
technology. They are also able to solve much more
complicated -problems than the usual oversimplified
tasks they are given. In our society of space flight, push
button wars, ecological crises, widespread famine, and
widespread excess-we cannot afford the luxury of
oversimplification. We must be as precise as possible,
and where approximation occurs it must be clearly
identified and its implications understood. Even the
simple concept of percent error is foreign to many
traditional mathematics classrooms, yet students want
to know and should know about approximation. This
is yet another example of the fact that a solution to a
real problem is rarely all right or all wrong. An almost
right solution, however, may not be of much value
unless the "amount of wrongness" can be clearly
evaluated. The relevancy of the activity in mathematics
classes is also heightened by the fact that students can
utilize the computer in other disciplines. Although there
is often little application of mathematics when students
create simulations for use in science or history, tutorial
programs for use in English or foreign language classes,
or any of a host of other applications, there is an increased interest in both disciplines. Although the direct
application of mathematics may be slight, the application of the algorithmic thought process and the application of problem solving techniques are indeed interdisciplinary. Such student projects are not only very
valuable to the student, but quite often the teachers
will also become involved in a meaningful interdisciplinary study.
Having examined some of the ways that computing
facilities have affected and will affect students, let's
now examine the corresponding effects upon teachers.
The role of the teacher is altered in several important
ways. Most apparent is that the time spent reminding
1048
Spring Joint Computer Conference, 1972
students that they must pursue other studies in addition to mathematics far exceeds the time spent in pursuit of students who are not attempting to complete
their work. Quite simpJy, teachers spend more time
convincing students to go home than they do coercjng
them to do the assigned work.
The teacher's role will become much more that of an
advisor rather than that of a lecturer. This new role
will place much greater demands upon the teacher, and
may be one reason that some teachers have resisted
using available computing facilities. The role of advisor
means that the teacher must maintain a working
knowledge of more mathematics than he is now required
to do. Many secondary school mathematics teachers
have taught only a single subject-geometry or first
year algebra or ... -for several years. Even though
this restricted teaching load may continue, students'
pursuit of their own interests and many incidental
student questions resulting from assigned programs
will not be so restricted. The teacher's knowledge will be
inadequate unless it extends well into many areas of
mathematics.
Can teachers be expected to know all of the answers?
Certainly not, yet this response is not a source of comfort but of discomfort for many teachers. Students
using computing facilities remove the security of the
teacher who, with his answer key, does indeed have an
answer to almost all questions. This artificial security
will be undermined even further because of the newness
of many computing algorithms. Few teachers believe
they are smarter than all of their students-but they
have the decided edge of experience. However, when
computing facilities are introduced, the edge of experience is removed. There are clearly many teachers who
are very uncomfortable in this unfamiliar situation.
A teacher's mathematical background is likely to require some refreshment. One of the reasons for adoption
of computing facilities is to reflect the changing emphasis of today's mathematics. The experienced teacher
may well find himself in need of several inservice
courses to update his own background in mathematics.
Topics such as Monte Carlo Methods, Probability and
Statistics, Approximations and Error Analysis, as well
as Programming itself are some of those that may require additional study. Certainly an extensive, nationwide effort to renew support for inexpensive, convenient inservice education is in order. The positive effects
of such an effort were clearly evidenced when similar
support was given to the various SMSG mathematics
programs. Although an effort of that great a magnitude
may not be required, the majority of mathematics
teachers do require some type of inservice education
and that is no small undertaking. The benefits of these
courses' should, however, far exceed the possible inconvenience and certain expense of conducting them.
The teacher must also become familiar with a new
structure in the courses he is teaching. Of course programming is new and the topics themselves will be
somewhat changed and rearranged. Teachers will be
able to concentrate on problem solving rather than
arithmetic. Any experienced teacher can relate many
stories of students becoming so "hung-up" in the arithmetic of a problem that they lose track of what the
problem is all about. A traditional course in first year
algebra examines polynomials that can be factored as
the product of two binomials. The next topic is likely
to be algebraic fractions and various techniques for
their manipulation. Unfortunately, much of the topic
of algebraic fractions is likely to be completely obscured
because students approach almost all problems as additional exercises in factoring. Adoption of computing
facilities reduces the likelihood of students getting
"hung up" on the arithmetic of a problem. One can't
resist the observation that problems will no longer have
to have answers of 1, 10 or 100 so that the arithmetic
can be more readily done by hand.
The teacher will also shift the emphasis of a mathematics course somewhat away from the 'current stress
on structure. The structure of mathematics is indeed
important, but that does not mean that the best way
to teach the subject is to proceed in an orderly step by
step path through this structure. After all, this certainly wasn't the order in which the mathematics was
created. The structure will not, of course, be totally
ignored, but it will not be emphasized until more advanced courses.
Teachers will also find themselves in a delightful new
situation-they will be able to get genuinely excited
about the work of their students. Students in mathematics classes using computing facilities can indeed
create an exciting algorithm just as an art student can
create an exciting sculpture. Clever teachers have appeared enthusiastic when a student solves a problem
correctly, just as they have generated a sincere enthusiasm when a particularly "slow" student finally
learns a certain technique. They have not, however,
often experienced the exhilarating feeling of sharing a
student's enthusiasm for something he alone has
created. The strongest advocate of an idea is the person
who creates it. As the computer permits the student
and teacher to share in the development of new ideas,
a completely new and very desirable student-teacher
relationship will emerge.
Finally, let's examine some of the effects that secondary school computing facilities might have upon the
computing industry. Clearly secondary schools repre-
Impact of Computing on Teaching of Mathematics
sent a new and growing market and thus a new and
growing source of profit. The nature of this market,
however, is different from most others. The most important single factor in education is cost. Contrary to
your feelings as taxpayers, schools do attempt to save
money whenever possible. The continuing emphasis on
minimizing cost permeates all phases of computer related activities. Although this concern for economy is
often very desirable, it often becomes dictatorial. Many
competent and valid studies of needed computing
facilities have been prepared. The educational pros and
cons of several systems are evaluated and closely
scrutinized by several diverse committees. And then
the decision is made-the school system accepts the
least expensive of the proposals.
If a school system adopts computing facilities and
has a bad experience with them, this experience is
communicated to many, many other schools. Vendors
should, therefore, make a special effort to see that the
staff of a school is well prepared to utilize the facilities
they are marketing. The educational customers of today
are surprisingly unsophisticated in comparison to their
counterparts in industry. They require a larger than
usual amount of "hand-holding" both before and after
a sale, and require very solid software and hardware.
Although the situation will eventually change, most
schools can today only use the software provided by the
manufacturer. They do not have the internal capability
of tailoring that software to better suit their individual
needs.
1049
Other characteristics of the educational market include the fact that the "state of the art" is not an important consideration when hardware is selected. The
very latest equipment is a luxury that very few school
systems can afford and even fewer systems require.
Reliability and durability are far more important than
extra speed or exotic features. Most school systems will
acquire their computing facilities gradually over a
period of several years. Thus vendors must provide
very flexible systems that can be expanded with little
or no "wasted" expense, yet remain an effective system
at each stage of expansion. As has been evidenced
previously in this paper, schools are expected to increase
their demand for interactive terminals on which students can implement their BASIC programs. The interactive requirement may be altered in some situations,
but it is unlikely that BASIC will be replaced during
the next few years.
Finally, I hope that one effect upon industry is that
more of you get involved in secondary schools. I intend
no disrespect for my profession when I state that we
need all the help we can get. Offer to teach a special
course in your local school system to students, to
teachers or both. Assist your school administration and
school committee in evaluating various facilities and
the benefits they offer. The educational process you
support now will repay all of us in the future-and
while providing this support you too may have the
opportunity to share the real joy of working with
today's young people.
Computing in the high school-Past, present and
future-And its unreasonable effectiveness in the
teaching of mathematics
by WARREN STENBERG
University oj Minnesota
Minneapolis, Minnesota
Five years ago computing was trickling into the
secondary school scene, but today it's a torrent. Various hardware and software developments over the last
two decades have made the computer ever more appropriate for this environment. These developments were:
the shared program; the replacement of vacuum tubes
by cores; compilers and procedural languages and
finally-time sharing. The latest development has been
the great reduction in the price of time sharing over
the last year.
Six or seven years ago the pattern of computer use in
the schools was very different from today. Some schools
purchased table top computers with memory too small
to contain a compiler so that students programmed in
assembler language. (This had some disadvantages
which I'll comment on later.) A second pattern saw
the teacher carrying the student's program decks to a
friendly college or industry to be run in batch mode
during off hours. This method had the disadvantage
that it took several days to get the three or four runs
usually necessary for debugging.
But today we have an entirely different scene. Today
it's all time sharing. I illustrate by describing the situation in Minnesota where I have my best access to information. For the last three years we have had time
sharing in a few schools in the Twin Cities area on an
individual port rental basis. Today every Junior and
Senior High School in Minneapolis and St. Paul has
at least one console. This also holds true of most of the
suburbs. In the outlying areas of the state, time sharing
has not as yet made a very strong showing.
After this glimpse at the hardware trends in the
schools, it's time to see what the computer is doing
there. The types of computer use fall generally into
four categories:
1st
2nd Student use of canned programs including
simulation
3rd Student programming
4th Computing courses
(The first three categories involve use of the computer
in courses in the traditional curriculum.)
CAl is essentially a programmed textbook with the
computer turning the pages. My personal prejudice
(shared by many people I have talked to) is to be very
skeptical of CAl as a substitute for the teacher in the
classroom. But I see a great future for it in the areas of
drill, review and remedial work. So far CAl is nonexistent in Minnesota secondary schools. At present
the main deterrent to CAl is cost. If the cost factor were
eliminated there would still be the impediment of the
scarcity of CAl materials. At the University of Minnesota, CAl is extensively used in the beginning German
course. The cost per student hour at the console is
about one dollar; each student spends about five hours
per week at the console. This totals up to $50 per
student per 10 week quarter. In addition the hardware
(CR T terminals) is exorbitantly expensive. Also the
development of the software for this course was about
$20,000 not counting the overhead of maintenance of
the CAl center at the University of Minnesota. This
program would have been impossible without generous
foundation support. According to experts of the University of Minnesota, economically feasible CAl depends on two developments: first dramatic hardware
improvements-probably replacement of cores by integrated circuits; second, increasing the amount of activity at the terminal end of the system-computer
controlled slide projectors, film clips and audio cassette
players. Even assuming that the necessary hardware
developments will be forthcoming, the development of
the course materials will require national dedication to
Computer Assisted Instruction (CAl)
1051
1052
Spring Joint Computer Conference, 1972
the project and many millions of dollars of financial support. Even in this era of electrifying change, a decade
would seem a conservative estimate for the realization
of the potential of CAL
Computer science courses have not as yet played a
major role in the computer use in the secondary scene
but they now seem to be coming up fast. In Minneapolis
three high schools currently have such courses. Next
year six schools will have such courses and in two years
it is estimated that all the city's high schools will have
them. Representatives of the University of Minnesota
computer science department believe that within a few
years the content of their present first course will be so
widely offered in high schools that it will no longer be
offered at the University except as a remedial no credit
course.
But we are confronted with a very definite problem
in connection with this movement of shoving the first
computer science course back into the high school. The
problem is that no standard curriculum has as yet been
developed for these courses. Each teacher is "doing his
own thing." A great deal of highly creative course development is taking place with bits and pieces being
assembled from various sources; textbooks are generally not used. This is actually a very healthy development but still it creates a problem for the colleges. For
they cannot know just what the students passing
through these courses know about computing. So there
is an urgent need for state departments of education to
establish guide-lines or syllabi for computing courses.
These should be worked out in collaboration with high
school teachers and college computer science departments. These guide-lines should be sufficiently flexible
as to encourage the creativity and originality of the
individual teachers but they are altogether necessary
lest the high school programs go to waste. First steps
in this direction are now being taken in Minnesota.
Actually we can foresee three kinds of computing
courses in the high school:
(1) The College Preparatory Course. This emphasizes
algorithms and programming probably with the
major stress on mathematical algorithms. It includes subscripted variables,functions and procedures. This course could be an alternative for
one semester of mathematics.
(2) The Engineering Course. This course would include some algorithms, but the stress would be
placed on computer logic and circuitry, binary
arithmetic etc. In a lab associated with the
course students would construct models of computer components. The course might include a
quick pass over some elementary principles of
electronics. The course could be used as a substitute for a semester of science.
(3) The Vocational Course. This course would consist of data processing techniques, the COBOL
language, and an experience with operating a
computer. Though primarily conceived for the
non-college bound student, the course could be
useful for the potential student of business.
The latter two courses are still in the category of pipe
dreams since the teaching personnel just does not exist.
So far we have been discussing computing courses in
the secondary schools. It's time that we should. turn
our attention to the other face of the coin-the use of
the computer in the conventional curriculum. This
category makes up the great bulk of computer use in
the schools at the present time. It is first necessary to
recognize the sharp dichotomy between the use of the
computer in mathematics courses and the use in other
curricular areas. In mathematics courses virtually all
computer applications involve the student in constructing his own algorithms and writing his own programs.
Outside mathematics the situation is completely reversed. Here the student does no programming himself
but works with canned programs where he supplies
data or changes the values of parameters and observes
the effect on the resulting output. These applications
fall generally into the category of simulation or computer games. The programs involved are long and complicated. They will not be worked out by the individual
teachers-they will be developed by experts. A teacher
using them won't have to know anything about the
actual programming-he merely has to be confident
that they do what they are supposed to. In other words,
the teacher using the computer in non-mathematics
courses needs to know next to nothing about computing-only how to call up the program and plug in
numbers. Contrariwise, the mathematics teacher has to
know enough programming to teach it to his students
and to help debug their programs.
On the basis of these observations one might suppose
that the non-mathematical use of computers, since it is
so much less demanding on the teachers, would be much
more widespread than the mathema~ical use. The
exact opposite is actually the case .. Why? The reasons
for this phenomenon are easily identified. They are:
(1) the non-mathematics teacher assumes that any
use of the computer involved vast technical
knowledge and this inspires him with fear
bordering on terror;
Computing in the High School
(2) he receives no training in computer use in his
college training mainly because the education
faculty adopts the same attitude toward computing as he does;
(3) the availability of computer oriented materials
outside mathematics is still comparatively
sparce;
(4) information about existing materials is not
readily accessible to teachers;
(5) the importance of computing is nowhere near
as great in other areas as it is in mathematics.
To rectify this situation four measures are necessary:
(1) faculties in schools of education must themselves
be educated in the use of the computer in their
fields;
(2) teachers' institutes featuring the application of
computers outside of mathematics must be
promoted;
(3) city school systems must hire specialists in nonmathematical uses of computing who can indoctrinate teachers and keep them informed of
current developments;
(4) computer oriented student texts and supplements must be produced.
Basically, developments in this area involve a twostage process-training the education faculty to train
the teachers. For this reason developments will be relatively slow in· coming unless the National Science
Foundation and the U.S. Office of Education decide to
initiate a crash program.
The situation is much brighter in the area of mathematics-the reasons being that the effectiveness of
computing in mathematics is quite obvious; a large
amount of material is available; and the technological
aspects of computing hold relatively less terror for the
math teacher. The way in which the math teacher has
obtained his training may come as something of a surprise. Up to now it has been almost all in-service
rather than pre-service training. NSF summer institutes
have played a major role here. But in Minnesota, University sponsored summer institutes and academic year
seminars have been even more important. Last summer,
60 Minnesota high school teachers participated in a
university sponsored summer seminar. Currently 77
Minneapolis math teachers are participating in an institute jointly sponsored by the Minneapolis school system
and the University of Minnesota. Better than half the
junior and senior high school math teachers in Minneapolis schools have now had computer training. All
1053
math students in this school system will have some exposure to the computer.
In outlying areas of the state as might be expected,
we see a much bleaker picture. Where the teachers and
schools are widely dispersed, teacher training becomes
more difficult and the acquisition of hardware presents
a formidable obstacle. These problems can only be
solved if the state department of education assumes the
initiative in forming cooperative regional networks.
Such a regional network has been set up in the junior
college system. All of Minnesota's junior colleges now
have consoles, a development which came to fruition
during the current academic year. (As a footnote it is
interesting that Minnesota's junior colleges are exhibiting an interesting counter-trend; the chief customers for
computing here are the physics courses-the result of a
particularly effective training program for junior college
physics teachers. )
In spite of this counter trend, the computer in the
high school is closely associated with the mathematics
program. One reason for this is that elementary mathematical algorithms involve much less extensive knowledge of programming than non-mathematical algorithms and so provide a convenient vehicle for initiating
the student in computing. But this· is of relatively
minor importance. The more fundamental aspect of
this interaction is found in the impact of the algorithmic
approach in the clarification of mathematical concepts.
In college mathematics this impact seems likely to
completely revolutionize the teaching of calculus, linear
algebra, ordinary differential equations and numerical
analysis. And the impact of the algorithmic approach
looms no less dramatically on the secondary mathematics scene, so dramatically in fact that there is the
temptation to try to use it everywhere, even in those
places where it is inappropriate. The great scientist
Eugene Wigner has spoken of the "unreasonable effectiveness of mathematics in the physical sciences." In
the title of this talk I have paraphrased Wigner's
words to "the unreasonable effectiveness of computing
in mathematical pedagogy." And indeed this effectiveness is so great as to seem almost mysterious. Now I
will try to uncover some of the clues to this mystery
which I catalog below.
PRINCIPAL WAYS IN WHICH COMPUTING
AFFECTS MATHEMATICAL PEDAGOGY
• Dynamic vs. Static Approach
• Computing Attitude toward Variables
• Development of Problem Solving Technique
1054
Spring Joint Computer Conference, 1972
• Affinity between Algorithm Construction and
Theorem Proving
• Mathematical Topics which are Algorithmic in
Nature
• The "Teaching Effect"
• The Stimulation to do Independent Work
• The Excitement of Being Involved in Modern
Technology.
Now let's examine and explain the items In this
catalog.
Dynamic vs. static approach
In computer oriented mathematics the emphasis is on
"what you do to find it" rather than on "what it is."
This particularly applies to definitions and existence
theorems which can often be put into an algorithmic
setting. I believe that the vast majority of students
tend to think dynamically and be stimulated by this
more active approach.
The computer attitude toward variables
There is a subtle but important difference between
the computer attitude toward variables and the traditional mathematical attitude. Traditionally, a variable
is a symbol for which values may be substituted from
a certain set called the domain of the variable. In computing a variable is a symbol which at any time has a
definite value although this value may change from
time to time. In the computing approach the student
feels that variables stand for something concrete and
definite and thus feels more at home with variables and
arithmetic expressions.
The profound importance of this subtle distinction
was first brought home to me when I was observing a
seventh grade class trying out some SMSG text materials on flow charting. The teacher was quite pessimistic about the prospects for success. He said that
seventh grade students could understand arithmetic
expressions to the extent of being able to substitute
values for the variables to evaluate the expression, but
that they could not manipulate with the expressions to
find other equivalent forms. It turned out that the
students had no difficulty with the material but in fact
assimilated it at a prodigious rate. I remember particularly vividly the reaction to the simple over-time algorithm in Figure 1 where the variables stand for wage,
rate and time. One student commented that the expression RX40+1.5XRX(T-40) could be simplified
Figure 1-0ver-time
to RX (40+1.5X (T-40)) which would be more efficient as it would require one less arithmetic operation
Another student observed that the expression could be
still further simplified to RX (1.5XT-20). The class
agreed with these simplifications and appreciated the
reasons for them. The teacher and I were both quite
dazzled by the easy familiarity with arithmetic expressions on the part of these seventh graders with no
experience in algebra. And this was on the first day of
flow charting with numerical algorithms.
One difficulty some students seem to have with
mathematics is that arithmetic expressions when they
become too complicated have no meaning for them.
They see these expressions only as strings of symbols.
This applies already to such an expression as the quadratic formula
-B+VB2_4·A·C
2·A
In the computing approach they tend to see the expression as being in itself an algorithm for calculating a
particular numerical value.
Computing in the High School
This motivates a remark I'd like to make on. computer languages. I have long felt that in more advanced
courses applying the computer, such as computer calculus, it is absolutely necessary to use procedural languages like FORTRAN or BASIC. The difficulty with
assembler languages is that students get involved in so
much detail that they lose sight of the original mathematical ideas. Experiments with teaching computer
calculus using assembler languages have borne this out.
However, in earlier grade levels where the problem consists of appreciating the meaning of arithmetic expressions the situation is entirely reversed. Here in programming with a prototype assembler language such as
SAMOS the student plays the role of a compiler as it
were and breaks the expression into its component
parts, thus getting a real feeling for the meaning of
arithmetic expressions. I hope some experiments will
be made to test this pedagogical technique in the seventh
or even the sixth grade.
Development of problem solving technique
Most teachers have had the frustrating experience
that many students faced with a problem where they
can't see the path from beginning to end just can't
be made to do anything at all. We just can't seem to
get them to pick up a pencil and start writing something.
Experience with algorithm construction changes all
that. Here students learn to find the heart of the algorithm-the fundamental idea-and then to work both
ways from the heart. They soon appreciate the futility
of trying to start at the beginning and work toward
the end. They learn to have patience with their abortive
efforts.
Once the student· finds a solution, any solution, he
stands back and looks for simplifications and improvements. He looks for improvements in the efficiency, the
elegance, the clarity of his algorithm. He also looks for
additional features he can add to the algorithm, making
it do more.
All this is the essence of problem solving and theorem
proving in mathematics. The difference is that in the
computing setting students take to these activities like
a duck to water. The ability to handle hard problems is
not confined to the gifted. Many students learn to
tackle really difficult algorithms requiring weeks of
work, breaking them down into their component parts
and putting the pieces back together. As one by-product
of teaching computer oriented mathematics we hope to
tap this problem solving power and direct it toward
solving mathematics problems.
1055
Affinity between algorithm construction and theorem
proving
We have already seen in the discussion of problem
solving how the mental attitudes necessary for theorem
proving are stimulated by the computer viewpoint.
But the relation between computing and theorem proving is more than just an analogy. In the computer approach to calculus and linear algebra most of the existence theorems are nothing more than algorithms. "If
you can show how to find it you know it exists." This
suggests a constructive approach to mathematics as in
fact is the case. Although we do not accept all the goals
of the intuitionists, we travel a long way down the road
with them.
One result of presenting mathematics from a computer approach is that the entire course is reorganized.
Although we arrive at essentially the same destination
we get there by an entirely different route. The advantage is that the average student will understand
more of the theory and the top student will understand
it better. There are very definite levels of understanding. It is one thing to follow the steps in a proof. It is
another thing to feel it with a sense of inevitability.
These remarks may help to dispel a popular misconception relating to computer oriented math courses. It
is widely supposed that in such courses we use calculations as a substitute for theory. In actuality the main
function of computing in these courses is to reinforce
and promote the understanding of theory.
Mathematical topics which are algorithmic in nature
There are a large number of mathematical topics
which are intrinsically of an algorithmic nature. In
college mathematics some of these topics are: convergence of sequences, the definite integral, ordinary differential equations, numerical analysis, and practically all
of linear algebra. There are· also many topics in high
school mathematics which lend themselves to algorithmic treatment. Among them are: solutions of systems of equations, the Euclidean algorithm and the
fundamental theorem of arithmetic, a wealth of material
connected with factoring and primes, area under curves,
mathematical induction, sigma notation, square roots
by the "divide and average" (Newton's) method. In
the traditional ways of teaching these subjects, the
algorithmic approach has not been stressed. Most of
these subjects have been very poorly understood by
students. The algorithmic approach should produce a
high level of comprehension. A couple of examples are
in order to show why.
1056
Spring Joint Computer Conference, 1972
depicted in Figure 2. Students traditionally have a
great deal of difficulty with this notation. If you don't
believe it, ask your students to find
100
L:l
k=l
Using the algorithmic approach the student can be
asked to trace the flow chart of Figure 2 by hand (with
11k replaced by 1) until he sees what it does.
We see here that our very definition of the sigma
notation is as an instruction to perform a calculation
rather than as the result of this calculation. This is an
example of the dynamic as opp3sed to the static treatment. Another important point illustrated by the sigma
notation algorithm is the concept of a bound or
"dummy" variable. The student sees clearly that the
final answer has nothing to do with the variable, k.
Bound variables as encountered here and as the variable x in the expression
N
2.
SUM4-0
f
b
f(x) dx
a
K.-I(+1
4
........ SUM·4-· SUM +
11K
s
SUM
Figure 2-Sigma notation
The sigma notation, as exemplified in
n
1
L:-k
k=l
is nothing but a shorthand notation for the algorithm
have always been a stumbling block for students which
the .a1gorithmic approach goes a long way toward
removing.
For another example of how the algorithmic approach
affects the presentation of a mathematical concept we
will look at mathematical induction-a disaster area in
the math curriculum. Suppose we have a statement
with an integer variable n in it. Let's call the statement
pen). Suppose we wish to find the first positive integer
n for which the statement is false. This search can be
represented by the flow chart of Figure 3. Now further
suppose that we know somehow that whenever the
statement holds true for one value of n, it will hold
true for the next one as well. If this is the case, then
once we have passed through the True exit in flow
chart box two of Figure 3 we will go through it the next
time as well and the next and the next ad infinitum.
Now is there any way that we could ever leave by the
False exit so asto get out of this loop? When this question is asked in class some student will always answer
that this could only happen the first time, that is when
n = 1. Thus if we add the hypothesis that the statement
is true when n = 1 we see that we can never branch to a
stop; we are in a tight loop; the statement P (n) is
true for all positive integer values of n. And this is the
principle of mathematical induction.
In the latter example we see a use of a flow chart
that will never be converted to a program and run on
a computer. We see then that flow charts can have uses
quite apart from programming. A recent experiment
Computing in the High School
was performed in Minnesota teaching a mathematics
unit to three groups of junior high school students, one
with flow charts but no computing, a second with flow
charts and computing and a control group taught in the
traditional manner. It was found that the flow-charting
group showed enormous gains over the control group
1057
but that the computing group was not significantly
better than the flow-charting group. The scale of this
experiment was not large enough to be in any sense
definitive. However, the results point out that the main
benefit to mathematics lies in the algorithmic approach
rather than in having an easy way to get numerical
answers. In more advanced courses like calculus and
linear algebra the computer is indispensible as we don't
feel the necessary conviction until we see the numerical
results.
Computing experience will be of lasting benefit to
mathematics students in that they will always have a
better understanding of iterative techniques. For example, I have had far better results in teaching Picard's
existence theorem in ordinary differential equations
(using the successive approximation technique) to
students who have been through a computer calculus
course.
The "teaching effect"
F
peN)
T
3
N4f-N+1
Every teacher has probably said at some time or
another, "You never really learn a subject until you
teach it." There is a lot of truth in this. In the computer approach to mathematics the students get the
benefit of this sort of experience. For, when he develops
an algorithm and writes the program he is essentially
teaching the computer to perform the calculation.
Actually the student learns much more from this experience than by doing the calculation himself. For his
concentration is on the ideas involved in the calculation, where it belongs, and he avoids the tedious arithmetic which is largely counter-productive.
Independent work
4
N
Figure 3-Induction
Aside from computing I have seen no field of study
in which so many students become inspired to invent problems, learn on their own and tackle major
projects. This phenomenon has been encapsulized in the
phrase "computer bum." Many educators worry lest
these students will spend too much time on computing
to the neglect of their other studies. However, as I see
it, the whole purpose of education is to bring students
to the level where they can learn and create independently. We are achieving this desideratum in computing as nowhere else; it should be encouraged and not
denigrated. Experts in other disciplines might try to
find out why computing is so successful in this respect
and try to develop methods of encouraging this sort of
resourcefulness in other fields.
1058
Spring Joint Computer Conference, 1972
The excitement of being involved with modern technology
This item hardly needs any comment except to observe that many educators suppose that it is the only
reason for the effectiveness of computing in mathematical pedagogy. Actually it is of relatively minor
importance though it is of course a source of stimulation
to most (but not all) students and it would be a mistake
not to exploit it.
I hope my remarks have shed some light on the
present status of the computer in the secondary schoolon where it has been and where it is going-and on the
reasons for its continuing close association with mathematics in this environment.
Computer-aided design of MOS/LSI circuits
by H. W.
VAN
BEEK
Texas Instruments, Inc.
Houston, Texas
INTRODUCTION
quires as input a wiring node list that describes the
interconnection between devices. Process parameters
as well as geometrical details of the transistors are
data inputs. The designer can also describe particular
signal wave-shapes to the program for driving the
inputs as well the details of clock signals used for
propagating information through his circuit.
The functional complexity of MOS/LSI packages has
increased exponentially during the past seven yearsfrom a 20-bit shift register with about 130 transistors
in 1964 to a one-chip calculator with over 3500 transistors in 1971. This evolution has been realized primarily
because of process and engineering advancement in
the state of the art. Computer-aided design and layout
has played a much smaller part in this development .... Why?
The main reason is that most of the CAD systems
developed to date do not provide a viable and economical approach for implementing MOS/LSI designs.
Systems currently in use are either too wasteful in
silicon "real estate" or require too many error-prone
manual operations. In order to achieve greater functional complexities in an MOS/LSI circuit, further
development is required in both the simulation and
layout of MOS systems. In this paper I will review the
current use of CAD tools in both the circuit-analysis
and the chip-layout areas. Challenges that must be
faced in the future by the programmer in the CAD
area will be presented.
~ONSATURATEO REGION I
•
SATURATEO REGION
7
I
V-I CURVE FOR Mas
LOCUS OF POINTS WHERE
t - - - - + - - - - - - - - V G G - VT= Voo
LOAD WITH
IVGG - vTI ;'Voo
lOS
VOS
NONSATURATED REGION
SATURATED REGION
IJ.EoEox W
~=--
toxL
COMPONENT LEVEL SIMULATION
Figure I-MOS I-V characteristics and basic equations
The predictability of the MOS transistor in integrated form by means of device equations leads to uncomplicated yet very effective transient-analysis programs.
At Texas Instruments the design engineer uses a
parametric circuit analysis program for evaluating cell
or gate design based on the standard device equations
shown in Figure 1.
It is interesting to note that factors such as speed
and power dissipation are directly related to the width
and length of the M OS transistor. The program re-
Transient analysis is performed on the data by
generating differential nodal equations, which assume
charge balance at each node, and solving these numerically. Prediction and correction techniques are
used to select the proper time constants for solving
each set of equations.
The program is strictly an analysis tool as opposed
to a synthesis medium. Correlation of the computed
results compares very favorably with actual results.
1059
1060
Spring Joint Computer Conference, 1972
The user can specify a tabular listing of absolute and
differential node voltages and device currents in addition to a printer plot of voltage versus time.
What is the challenge for software development in
this area? I think it is basically that of staying up with
the new processes that are coming out of the R&D
laboratories and ensuring that the models used for
computation remain accurate. The other requirement
is to reduce the cost/computer run. Even though the
current program executes relatively fast-about 1
minute task time on a 360/65 for a typical problemit is used so extensively that a 10 percent reduction in
run time would represent a sizable monetary savings.
Another aspect is the time required for data preparation by the designer; this, economically speaking,
is possibly even more important. With the reduction
0~
G3S~A2
Understanding the problem to be solved for the
design engineer is even more important in the area of
MOS/LSI chip layout.
COMPUTER AIDS FOR THE LAYOUT OF
MOS/LSI CIRCUITS
One of the challenges facing the MOS designer in
this area can best be exemplified by discussing a simple
but accurate example of a partial system implementation. Logic in the form shown in Figure 2 had been
implemented in standard TTL logic; it represented a
portion of a larger logic system which was to be converted to MOS.
0~
~
","
G35
"
I
A2
I
L_2'______ ..J
~;~'
,,"
G4
86
G5
G6
86
~;
86
81
~~o
C5
~;:
cs
81
MOSPARTCOUNT
(FIRSIREOUCTIONI
2S'GATES"+1071ICPINS
Figure 2-Signal select control logic
Figure 3-First reduction, signal select control logic
in cost of simple alphameric CRT display terminals,
it becomes feasible to provide each engineering office
with such a terminal. The value in this approach, as
with other interactive CRT systems, is that during the
session at the console you (the programmer) can extract
from the engineer his best effort. Input data checking
is performed instantly and answers provided· when the
engineer is most irrvolved with solving his problem.
This is an extremely important point to keep in mindsoftware development in this area must be perfectly
synchronized with the modus operandi of the design
engineer. You must anticipate his requirements before
he has a change to vocalize them. This implies that
you, the programmer, be very conversant in the
problem area.
The designer has available to him an automatic
P & R (Placement and Routing) program with a
substantial number of cells. If he chose this approach
he would initially try a one-for-one replacement of the
TTL logic diagram with 51 MOS cells. These "library"
cells have a standard height of say 12 mils. Assuming
an average of three I/O pins per cell and 1.2-mil
centerline spacing, we can arrive at an area requirement
of 12 mils X 2 pins/cell X 51 cells X 1.2 mils/pin =
12 X 184 mils. This is the area required for the gate
(or cells) only, not the intraconnect. For the intraconnect we can assume, for a random logic circuit
implemented by rooans of standard cells, that roughly
20 percent of the area will be occupied by cells and
the remaining by intra connections and bonding pads.
Computer-Aided Deisgn of MOS/LSI Circuits
In this particular case the circuit size would be roughly
12 X 184
20
X 100 = 11040
square mils or about 100 X 110 mils. The first comment that comes to mind is that the routing algorithm
or the designer was not very good at the task. Let's
see, however, what the designer can do from this point.
By combining gates that have a fan-out of 1, he can
arrive at an arrangement as shown in Figure 3. This
approach leads to 28 "standard" cells with a total of
107 I/O pins, resulting in an area requirement of
~7704 square mils or a 31 percent reduction over the
first implementation. The designer can continue the
"customizing" of cells and maybe achieve a layout
1061
uses the same real estate for active devices as well as
for the passive intraconnections to these devices.
The PLA technique is an approach in which system
logic equations are broken down into sets of Sum-ofProduct terms. Implementation follows by generating
110-.....- -......- - - - - - - . _ - -
120--.....:----+-.....--+--+---
NAND
Matrix
NAND
Matrix
ACTUAL IMPLEMENTATION
11 O-.....- -......----~-
12o-...----+-.......- - - I - - + _ -
"AND"
Matrix
Figure 4-Arithmetic unit
"OR"
Matrix
equally divided between active and passive area of
about 60 X 60mils.2
The designer reduced his dependence on the automatic placement and routing program because of the
custom design performed, but he now apparently has a
small layout. However, this is a false assumption since
he only implemented a small percentge of the overall
system as shown in Figure 4. Just one small triangle
represents all of Figure 3!
Sophisticated system implementation demands a
better technique. The designer must be forced to look
at the overall logic requirements of the system and
break it down into functional blocks. He also must
try to make maximum use of the PLA (Programmable
Logic Array) or matrix technique since this approach
LOGICAL EQUIVALENT
CA27484
Figure 5-PLA logical equivalents
Product terms in an AND matrix, and summing thes(3
in an OR matrix to produce the desired output (see
Figure 5). Memory elements can be added outside the
matrices to satisfy time delays and/or storage requirements. Almost all random logic circuits generated at
TI contain one or morePLA's for control functions.
1062
Spring Joint Computer Conference, 1972
What is the future then for CAD if we suddenly
discard the standard gate or cell approach in favor of a
technique th~t doesn't lend itself to the nicely organized world of fixed-height cell layouts? Is automated
placement of cells by means of a program obsolete?
I believe that current versions are obsolete for most
implementation requirements because of the poor area
utilization. The human skill at conceiving an essentially
infinite number of possibilities for placing arbitrary
size polygons in a minimum area is one that is too costly
to implement automatically. For an equivalent logic
function the skilled draftsman can always generate a
smaller layout than can an automatic placement and
routing program.
,
Let's take a look, however, at the other side of the
coin. Future demands on the functional complexity of
packaged M OS circuits will increase by leaps and
bounds if the past few years are any indication. These
pressures will lead to circuit complexities that cannot
be handled by only one or two designers, but will require teams of engineers. Even so, the chance for error
during the design and layout process will be so great
as to make the end product too expensive for the market
place. One missed connection or contact on a circuit
can cost thousands of dollars in lost time and effort to
correct and recycle. An effective means of minimizing
errors during the design and layout of a circuit is therefore mandatory.
It is this aspect of CAD that is currently undergoing
the greatest evolution. Interactive-graphic systems are
now becoming available that allow the designer to lay
out his circuit under control of the computer. Data are
input to the system by means of a digitizer, graphic
tablet, joystick or light-pen. This is an effective manner
of reducing the errors that occur in cases where layouts
are implemented entirely by hand, because a complex
circuit can contain over a quarter million coordinate
points!
An interactive-graphic system in use at Texas Instruments lets the user perform his cell placement and the
intraconnect between cells, by means of a light-pencontrolled CRT. Major program functions such as
signal routing and placing cells are called up by means
of a function keyboard. The program has automatic
layout rule verification and demands an override command from the operator in order to proceed with the
layout. Automatic conductor-spacing routines facilitate
the layout of large groups of bused conductors. Only
cell outlines are displayed to keep the data handling
problem to a minimum.
This system allows the operator a great degree of
freedom in doing the work he is most qualified to do,
namely the placement of arbitrary-sized cells and their
intraconnection. The system meanwhile performs a
clerical function-that of encoding the light-pen and
function-keyboard commands. The encoded data is in
a form suitable for driving digital plotters, and maskgeneration equipment.
DATA VERIFICATION
The question that now arises is: "Can we trust that
no errors are made in the layout?" The answer is NO,
because the user can usually override the system error
diagnostics. How do we check his work? A special
layout verification program was written to check the
final layout just prior to the mask-generation step. It
will check all circuit elements against each other for
layout rule violations. This task was previously performed by a visual inspection of a digital composite
plot of the circuit but the amount of data was becoming
so large that errors could and did slip by.
The Critical Clearance program checks both the
dimensional consistency of the data input as well as
the spacing between figures. This check is performed
on data of a particular mask level only. An extension
of this program performs a level-to-Ievel check and
verifies proper layout rule overlap requirements.
Continuity checks are also made to detect open lines
or incomplete transistors that might exist in the data
deck. A trace-back to the circuit schematic and the
original logic description completes the feedback cycle.
FUTURE DIRECTIONS IN MOS/LSI
IMPLEMENTATION
Respectable advancements have been achieved in
the area of CAD and layout of MOS circuits during
the past 5 years, but even so they will not be able to
effectively help in our future designs. There still exists
a large gap between the abstract aspect of a logic diagram and the concrete point of a circuit layout that is
currently filled in with manual and error-prone procedures. To be more specific we must devise a system
that accepts logic equations in an existing or new format
and provides us with an optimum topological layout.
This requires that a component or circuit data base be
established with which the designer can interact.
Note that I mentioned a component or circuit data
base as opposed to a circuit or logic system data base.
I propose that effort he directed toward developing
such a data base and that placement and routing
algorithms be developed for it. The availability of
Computer-Aided Deisgn of MaS/LSI Circuits
such a system would allow the MaS designer to bypass
the generation of cells for his circuit layout and consequently permit him to generate a circuit directly from
his verified logic.
Additional programs that would complement such a
system will accomplish the following:
1. Full-circuit parametric evaluation.
2. IVlinor adjustments to circuit layouts by means
of an interactive graphic terminal to accommodate process changes, and
1063
3. Generation of documentation pertaining to the
circuit such as bonding diagrams, process flow,
parametric test criteria, packaging information,
etc.
The above steps currently occupy a sizable portion
of the cycle time for completion of a prototype design.
The variety of circuits that will be designed during the
next few years will bury the component manufacturer
unless he takes decisive steps in the aforementioned
direction.
The role of simulation in LSI design
by J. J. TEETS
IBM Systems Development Division
Endicott, N ew York
INTRODUCTION
evaluated include: (1) replacing third generation systems with LSI, (2) enhancing architectural approaches
with LSI scratch pads and main store, (3) microprogramming techniques (both read-only and writable
control stores), and (4) considering hardware-software
tradeoffs.
An example of an available capability for such
high-level studies is the General Purpose Systems
Simulator (GPSS).4 GPSS provides for modelling
systems and can collect various statistical measurement
quantities such as throughput, resource utilization,
queue lengths, busy times, system bottlenecks, etc.
The collection of such data is very valuable in evaluating high-level architectures, both hardware and
software, in all phases of design.
On the other end of the simulation spectrum is the
very detailed low-level (i.e., circuit analysis) simulator.
This analysis is at the component junction/resistor
level; here the differential equations are solved by
numerical methods.
Forecasts for Large Scale Integration (LSI) indicate
that logic gate densities of 1000 gates per chipl could
possibly be obtained during the next decade. Supposedly, device and circuit innovations could be used
to achieve even higher densities. There are, of course,
a number of reasons why the industry is not yet manufacturing major LSI hardware on a large scale. One
• of these reasons is the lack of superior software support
for computer-aided design, particularly simulation
aids. For LSI, a major increase in logic design verification simulation will be required at the chip level to
ensure correctness of design and to minimize the need
for chip redesign.
The purpose of this paper is to review what has
happened in the last five years, particularly in design
verification, and to project what must be accomplished
in the next five to ten years in the area of simulation
in order to implement the promise of LSI.
REVIEW OF THE LAST FIVE YEARS
Design verification at the logic level
This section briefly describes high-level (architectural) and low-level (circuit component) simulators,
and then closely examines recent logic level simulators.
Logic simulation employs much more detail than
high-level simulators and much less detail than circuit
simulators. The purpose here is not to demonstrate
that these simulators are inadequate for LSI technologies, but to show that each still has a place. The
intent is to display a need for multi-mode simulation
at the logic level in one user interface.
The requirements of pre-LSI technologies such as
RTL, DTL, TTL and recently ECL have led to the
development and enhancement of co:nputer-aided
design support for simulation, wiring, testing, and
packaging of designs. The concept of a central design
file, used. by all these applications and massaged to
satisfaction, is well-known. 3 In this section, the simulation techniques used for technologies leading to LSI
are reviewed in some detail to provide a basis for discussing later improvements and extensions required
for today and tomorrow.
The techniques used by early logic design verification simulators were of relatively narrow purpose, i.e.,
they attacked a small set of design problems by using
techniques specifically designed for these problems.
There were basically three early types or modes of
High-level and low-level simulation
Predictably, there has been and will be high-level
simulation studies on various approaches to implementing LSI. Some of the major aspects and tradeoffs
1065
1066
Spring Joint Computer Conference, 1972
IN
-1
INVERTER
~ OUT
IN
0----...1
OUT
I
o
I
I
I
I
~
I-- FALL TIME
----l
I
RISETIME--l
Figure A-2VND simulation
logic simulation that became popular and were implemented (2VND, 2VUD, and 3VZD). All were similar
(table driven, handling both sequential and combinationallogic) but each was valuable to the designer in a
different way.
1. 2-Valued, Nominal Delay Simulation (2VND)3.9
This mode of simulation assumed that the state
at any point in the logic at any given time was
either "0" or "1". The nominal delay was a
gross approximation of the circuit delay (including loading and line delay where appropriate) in the form of a "rise" or "fall" delay,
which corresponded to the amount of time
taken for the circuit to respond to an input
change and change the output state from 0 to 1,
or 1 to 0, respectively (see Figure A). When primary inputs to the logic are stimulated, the simulator performs the Boolean function of the
blocks driven by the primary inputs. The basic
functions performed are shown in Figure D
(ignore the "X" and "U" values). For each
block whose value is to change, the proper
delay is selected and the new block value is
propagated after that delay. Propagation continues through the logic until a steady state is
reached. When a block's value does not change
as a result of an input change, propagation does
n
1 ns
IN
0
OUT
0
i
I
I
I
I
I
I
1
1
I-
15ns
W
11 ns
-!
Figure B-2VND prediction of TTL inverter response
not occur. This is known as "significant event"
simulation and is common to all three simulation techniques being discussed. This mode of
simulation, although somewhat gross in timing
analysis detail, was very useful in gaining some
engineering confidence in the behavior of the
early design. This mode was more economical
than the "three-valued zero delay simulation
(3VZD)."
One area where this mode fell short, even to
the point of misleading the user, can be demonstrated by the following example: the 2VND
technique (as used in early simulators) predicted
that the response of a TTL inverter whose rise
and fall delays were 15 nanoseconds (ns) to an
input pulse of width 1 ns, is an output pulse 1 ns
wide and 15ns later than the input (Figure B).
In fact, however, a TTL gate requires a minimum input width of about 12ns to achieve any
output response and would, therefore, completely ignore an input pulse of 1 ns or even
1 ns
IN
OUT
O----...In~------------------o
Figure C-Actual response of TTL inverter
IOns wide (Figure C). Moreover, the technique
is not pessimistic as a simulator should be. It
allows the user to think that he can count on
a narrow pulse to get through a logic gate that
is sure, in fact, to ignore it. The point here is
that simulators should not tell lies. Pessimism
may produce conclusions from simulators which
may never exist in real hardware and hence
cloud the issue; however, the designers must be
alerted to potential problem areas, and then
decide for themselves when a real problem
exists.
2. 2-Valued, Unit Delay Simulation (2VUD)5
This mode is very similar to the 2VND mode,
except that the delay of each circuit i~ the same
(one unit), independent of the type of circuit and
the direction of change. The contention of this
mode is that if one unit of delay is assigned to
each logic block (with some exceptions which
are assigned a delay of zero) , the results of
simulation will be sufficiently accurate to serve
Role of Simulation in LSI Design
a very useful purpose. Furthermore, if a convenient facility is available to add or reduce
delays by units, the simulator will be able to
closely represent the operation of the actual
machine. The applicability of this approximation is dependent on the manner in which the
machine was designed. Due to the variation of
delays in logic circuits from manufacturing, the
designer must allow sufficient tolerance so that
all of the manufactured machines can operate
identically to the prototype within certain
limits of delay variations. Thus, one can consider the unit delay machine merely as one of
those variations.
The most important advantage for this simplified timing simulation mode is its speed. It is
faster than the other modes and does not require
knowledge of nominal delays nor does it require
storage for those delays in the simulator. It is
subject to shortcomings similar to 2VND in
'" that both modes fail to detect most hazards
(subtle timing problems).
3. 3-Valued, Zero Delay Simulation (3VZD)2,9
This mode, the most pessimistic of the three
presented, was implemented primarily to detect
hazards and races, * as well as to investigate
Boolean behavior. All possible timing problems
of a design are identified to the designer. This
was realized by the introduction of a third
value, "X". Any time an input (beginning of
course with the primary inputs) changes state,
it is forced to pass through X, signifying that
the signal is "in transition" or "unknown" .
When this technique is used, first every primary
input that is changing state goes to X, the
driven blocks are simulated, and propagation
of all blocks to a steady state occurs. The rules
for simulating X in a Boolean function are a
subset of Figure D, ignoring the "U" for n,ow.
After a steady state is reached, the changing
inputs go to their final values and again propagation takes place to a steady state (if possible).
If a timing problem is a possibility, the value remains X on a block. This indicates a potential
hazard involving that block. The possible steady
state effects of propagating the hazard are also
shown by X values. A facility exists to allow the
designer to eliminate some of the simulator's
* If it is possible for the output signals to behave in a manner
different than predicted, the circuit is said to contain a hazard.
When two or more signals are changing together a race is said to
exist (Eichelberger).
1067
Outputs
Inputs
EXCLUSIVE- INVERT
OR
OR.
A
U
U
U
U
X
U
U
U
U
U
0
0
U
U
U
U
1
U
1
U
U
X
U
U
U
U
X
X
X
X
X
X
X
X
0
0
X
X
X
X
1
X
1
X
X
0
U
0
U
U
1
0
X
0
X
X
1
0
0
0
0
0
1
0
1
0
1
1
1
1
U
U
1
U
0
1
X
X
1
X
0
1
0
0
1
1
0
1
1
1
1
0
0
A
B
U
U
U
AND
Figure D-Example of simulator rules
(for all modes, 4-valued)
pessimism where races detected by the simulator
are known to be noncritical. When used properly,
this mode will allow the designer to be confident
that all potential timing problems have been
identified. However, eliminating pessimism in
one part of a design often has unexpected effects
on other parts.
Because of the two-pass operation described
above, this mode of simulation is a little more expensive to use because of the additional computer
running time; however, this must be evaluated
as a tradeoff against extensive hazard detection
capability not available with the other modes.
4. Extensions
Combinations and other variations of the previous three techniques have been used;6 one of
the more useful perhaps was the introduction of
a fourth value, "U", which signifies "uninitialized". When a U appears on the input of a block
1068
Spring Joint Computer Conference, 1972
being simulated, it is propagated according to the
rules of the simulator (Figure D). At any given
steady state condition, the appearance of U's in
the logic indicates the absence of initialization
data, and therefore, identifies the importance of
initial values. This can be very useful when
evaluating system reset operations or the effect
of incompletely specified input patterns. Two
forms of the output from these simulators include: (1) timing charts, which show the reaction
(in simulated time) of inputs and outputs of
selected blocks, and (2) "snapshots", which display the value of all points in the model at
selected times.
Other improvements include extension of 2VND
and 2VUD to include both the X and U concepts. Thus, the nominal delay and unit delay
modes can be made more useful in the area of
hazard detection.
5. The Unfortunate User
Irrespective of the merits of these simulators
individually, they had the collective disadvantage of not being mutually compatible. To
simulate for more than one purpose (using more
than one mode) required considerable, if not total
duplication of effort. The problem was compounded because each program had a unique user
interface. Thus, the user had to learn several incompatible systems before he could simulate at
any desired point in his design cycle. The cost of
this additional training and duplication of effort
is no longer tolerable, particularly for LSI. It is
now essential for different simulation efforts to
have maximum commonality in all respects,
particularly the user interface. This resulted in
the requirement for multi-mode simulation and
leads us into present simulator technology.
3. Partition the system into units (subsystems) and
establish unit specifications.
4. Model the units and compare to specification by
simulation.
5. Design units at the implementation level, modelling them for design verification simulation.
6. Compare models from different stages by simulation to ensure the detailed design meets unit and
system specifications.
7. Build the system.
8. Check the system against simulation results.
At stages 2, 4, and 6, simulation is employed; however, it is obvious that the level of system being modelled is different at each stage. Moreover, stage 6 simulates several levels together. Hence, multi-level simulation is required for a fully integrated simulation
capability.
Another major simulation problem that can and must
be solved is that of getting very large models into relatively small computer storages. Previously, users had
no option (other than not simulating) except to eliminate bits of their model until it was small enough to fit.
This usually caused distress by ending up with functionally awkward pieces and unchecked interfaces between pieces. The solution for this is to partition a
model, from the start, into a set of coherent regions
(units), each having a well-defined interface with its
neighbors (Figure E). These regions may then be simulated together as a system with the simulator automatically handling inter-region transactions by connecting together signals with identical names. An
incomplete (or not yet designed) region can be simulated
by using manually generated data or higher level models
SYSTEM
MODEL
TODAY AND TOMORROW
Current simulation techniques in the design process
Whatever the size of a design project, there is a general design procedure to be followed. Several stages in
that procedure involve simulation and these and other
stages may be iterated to feed back information to improve the design. For purposes of discussion, these key
stages in design are:
1. Establish system objectives and specifications.
2. Model the system and evaluate it by high-level
simulation.
MAIN
MEMORY
SCRATCHPAD
CPU
1----------1
SYSTEM
Figure E-System partitioned into regions
I/O
Role of Simulation in LSI Design
in place of missing parts which influence the regions
modelled at the logic level.
This multi-region concept readily lends itself to techniques for solving the storage problem previously mentioned. One solution is to use a roll-in, roll-out technique to make storage available for active regions.
Another solution is to compress the storage requirement
(and execution time) of those regions that are being
used only to generate interface activity for the benefit
of simulating other regions in detail. This compression
takes the form of higher level models for the other
regions so that the functions can be reproduced at the
interface. With this technique, a "multi-level simulation" capability is defined. Merged with a multi-mode
capability for those regions modelled at the logic level,
an overall capability for system simulation can be provided where the detailed simulation takes place in the
area of user interest.
These concepts lead toward the idea of "top-down"
design using simulation. In stage 4 of the design, highlevel models for the different units may be used to compare specifications of the units against system level
specifications by simulation. As stage 5's logic level
model becomes available for a given unit, the simulation
at stage 6 may take advantage of the higher level
models of other units not yet designed in detail. The
stimulus (i.e., the input patterns) for the detailed model
can be provided by the high-level models surrounding it
and can operate concurrently with the high-level models.
The high-level model for the region being simulated in
detail may be simulated at the same time, and the outputs of both can be fed into a comparator to ensure that
the implementation design meets unit and system
specifications. This use of the "high-level environment"
provides the user a pseudo system simulation at all
times, regardless of which unit is being investigated and
designed in detail. It also eliminates much of the problem of providing adequate stimulus to the low-level
design, which is otherwise a very tedious task.
Thus, the initial and unavoidable need to partition a
model can be turned to an advantage. It leads to orderly
design, region by region, with thorough checking and
evaluation of each unit. In addition, very important
advantages, particularly in the LSI design environments, can be addressed in the area of design verification; these include:
1. verify the correctness of design (including comparing high-level to low-level models and comparing different versions of a unit).
2. detect hazards and races which would not be
detected by building a hardware model.
1069
3. speed up the design process by using top-down
design techniques (which also provide good communication between unit design groups).
4. reduce the overall cost of the design process.
All of the above, particularly the cost factor, are imperative in the LSI design environment.
It has been stated that for LSI, a major increase in
logic simulation at the chip level will b~ required to insure correctness of design and to minimize the need for
chip redesign. The engineering change problem is particularly perplexing and still lacks good proposals for
its solution. If a chip change is required sufficiently early
in an LSI machine project, redesign costs will be incurred although slippage may not occur. During machine
test, however, where in the past the practice was to
install an immediate fix If possible, slippage as well as
redesign costs will accrue; a repeated string of such
change cycles·is obviously intolerable. Thus, LSI ideally
requires error-free design which necessitates simulation
aids and capability at a level never required or achieved
in the past. Such ultimate goals as self-diagnosing and
repairing machines in LSI cannot possibly be achieved
without significant advances in design verification and
fault simulation capability.
Thus, because of the cost factors and the related problems of system prototype "bring up" (engineering
change activity), it appears that the LSI technology is
insisting upon much more extensive simulation and
paper design before manufacture, and at the same time,
a reduction in the overall machine development cycle
and cost.
Another salient point that must be made is that it is
imperative for fault simulation to be integrated more
into the design verification process. If a machine design does not lend itself to system fault diagnosis and
component fault detection, then many problems arise.
For this reason, the requirements of testing the machine
must be fed back into the design process as early as
possible. One approach is to use the same stimulus used
by the design verification simulators as test patterns for
fault simulation. If the patterns detect only a small percentage of faults, then an incomplete job of design verification or an untestable design may be indicated.
Quite possibly the answers to testability and diagnosis
reside in performing fault simulation as soon as possible
after a logic level design is firm, or even during the
comparison of alternative design approaches.
The change in engineering design philosophy is largely
due to the inadequacies of past diagnostic capability.
Tests were derived in the past, in some cases, after the
1070
Spring Joint Computer Conference, 1972
machine had been built. They were, as a consequence,
not fully effective in their coverage. The obvious solution is to constrain the initial system and engineering
designs by the diagnosis requirements.
An open-ended list of future goals can now be stated
for implementation of LSI in the next decade; they include:
1. techniques and software for verifying that system and architectural specifications have in fact
been implemented in a machine.
2. highly interactive, terminal oriented, and integrated computer aids for design to reduce user
training and turnaround, resulting in usability.
3. advanced and enhanced simulation techniques
for verification of designs; particularly multilevel simulation, logic-level simulation, and more
effective techniques for timing analysis, at reduced cost.
4. advanced testing capability.
5. a "paper design" capability using software which
provides very high engineering confidence and
paves the way for the reduction or elimination of
engineering change activity, at reduced cost and
on a shorter design cycle.
6. Automatic input generation (particularly test
pattern generation) and automatic output analysis facilities to relieve the burden of the designer.
REFERENCES
1 M E CONWAY L M SPANDORFER
A computer system designer's view of large-scale integration
Proc AFIPS Vol 33 pp 835-845 1968
2 E B EICHELBERGER
Hazard detection in combinational and sequential switching
circuits
IBM Journal of Research and Development Vol 9 No 2
March 1965
3 P W CASE H H GRAFF L E GRIFFITH
A R LECLERCQ W B MURLEY T M SPENCE
Solid logic design automation
IBM Journal of Research and Development Vol 8 No 2
April 1964
4 GPSS V User's Manual
Prog No 5734-XS2 (OS)
5 L H TUNG
A unit delay logic timing simulator
IBM Systems Development Division Technical Document
TD 01.509
6 M J KELLY
Variable mesh simulator
Digest of the Second Conference on Application of
Simulation pp 294-296 December 2-4 1968
7 M A BREUER
General survey of design automation of digital computers
Proceedings IEEE Vol 54 No 12 December 1966
8 K A DUKE H D SCHNURMANN T I WILSON
System validation by three-level modelling synthesis
IBM Journal of Research and Development Vol 15 No 2
March 1971
9 S A SZYGENDA D M ROUSE E W THOMPSON
A model and implementation of a universal time delay
simulator for large digital nets
Proc AFIPS Vol 36 pp 207-216 1970
10 Proceedings of Hawaii Conference of System Science and
Cybernetics 1969-1970
Implementation of a transient macro-model in
large logic systems
by N. B. RABBAT and W. D. RYAN
Queen's University
Belfast, U. K.
INTRODUCTION
the inputs are. At high speeds, interconnections introduce significant delays and act as transmission lines;
these effects, which cause functional errors and hazards
in sequential circuits particularly, are included in the
process of simulation.
In large circuits, we are confronted with two problems.
First, the modelling of integrated circuit modules using
the normal methods of considering each element such
as the general circuit analysis program-precise though
it may be-can be excessively lengthy and tedious because of the computation time involved and the large
storage required. 1 •2 On the other hand, since most very
large 'circuits are likely to be active, and therefore nonlinear, and since the processes of non-linear analysis
are more time-consuming than the corresponding processes of linear analysis, the time required for the inversion of these large matrices would become an even
smaller proportion of the total. Though suitable for
discrete circuit analysis, this method applied to integrated circuit configurations3 such as modified TTL
and DTL gates leads to complex forms of modelling
rendering it inappropriate for use in large systems consisting of hundreds of logic gates. Also, since the models
of the elements constituting integrated circuits are more
complex in nature than their discrete counterparts, a
model leading to accurate predictions of performance
will tend to give an excessively lengthy analysis. The
choice of models becomes even more critical as the
complexity of integrated circuits becomes larger. Even
with the recent advances in sparse matrix, adjoint and
implicit integration techniques, these methods are not
powerful enough to solve the problems associated with
large complex logic systems.
Secondly, computer-aided analysis in digital systems
commonly involves logic simulation6.7 and an assessment of propagation delay which is made through the
time diagrams for each module available from the
manufacturers. However, propagation delay tpd obtained by algebraic methods,6.7 is imprecise since some
important factors governing tpd are not considered.
Further, in a logic system the outputs of the modules
are delayed and may not be simultaneous even though
MACRO-MODELLING
As medium and large scale integration (MSI and
LSI) become commercially feasible, the transient
simulation and accurate evaluation of tpd in large systems become increasingly important. The need for the
accurate prediction of the delays, where complex factors are generally ignored, results from the inability to
specify exactly when a given signal will actually make a
transition from one state to the other. These delays
may also introduce functional errors in the system.
Apart from the elemental components and considerations of fan-out, the important factors governing tpd are
the rise and fall times of the input function, multiple
inputs, short input pulse width, multiple paths, feedback loops and the characteristics of the interconnecting paths. However, to obtain a precise value for tpd and
to predict the transient waveform at a given point in a
system with multiple interconnecting and feedback
paths, a transient Macro-Model is necessary. If the
transient behavior of each module under the operating
conditions is not precisely known, the actual output
logic function obtained may be unrealistic. A novel
approach-Macro-Modelling3 •4-which takes into account all the considerations outlined above and enables
a good prediction of waveforms and propagation delays
in large integrated digital systems, is based on an analytical formulation of the input-output relationships
in transient of the logic module, using the piecewise
linear transient device model introduced by N arud
et al. 8 Examples of such piecewise linear analytical
expressions can be found in References (3) and (8) for
a large variety of bipolar and MOST gates.
1071
1072
Spring Joint Computer Conference, 1972
Koehler5 alludes to macro-modelling while investigating the effect on propagation delays using quantized
tables and taking into consideration the effect of fanout for the two values of propagation delay for rising
and falling edges. He points out the possibility of using
empirically-derived expressions for specifying the
input-output relationship. N arud, Dertouzous and
Jessel 2 have made a good attempt to model an ECL
gate by using non-linear input and output current
generators and capacitances but their approach has
some limitations: the number of gates in the system is
restricted to 12 and it is not suitable to analyze systems
with saturating bipolar gates or MOST gates as well as
interfacing with different kinds of gates. The effect of
feedback paths and interconnections causing multiple
reflections could not be readily simulated by their
method. Macro-modelling in Large Scale Integration
(LSI) of digital systems makes use of the periodic
nature of a large number of subnetworks. Integrated
digital circuits consist normally of a large number of
internal nodes-hence variables-whose values need
not be known for the evaluation of the overall integrated circuit provided, of course, that their effect is
taken into account. Obviously, there are two main
aspects of the analysis:
(a) the modelling of different kinds of modules
which the system may comprise and
(b) the actual simulation of the whole system.
MACRO-MODELLING IN SIMULATED TIME
The input function is first determined by establishing
the dominant input in relation to the other inputs. 4 The
dominant input, in the case of saturating multi-input
gates, is defined as being the latest arriving and first
decaying, or vice versa, dependent on the kind of logic
operation performed. For non-saturating gates, a separate integral is solved for each input and the appropriate
value is used as the argument in the output function.
The dominant input is then subdivided into a given
number of fixed time intervals At and the output response is computed by successive iteration for each
time interval using the analytical input-output relationship for the particular module. The quantized
values for the input and output functions at the beginning and end of each interval provide the initial
values and slopes (which together form the initial
conditions) and must be included in the computation.
The simulation is performed by successive iteration of
the set of mathematical expressions describing the type
of module under consideration. The type of logic
module is simulated accurately by an analytical tran-
sient input-output relationship-an expression which is
analytically derived2 ,3,4 and stored for reference. It includes the transfer function of the module as well as a
function defining the propagation time. These transient
expressions3 ,8 are not difficult to obtain using the piecewise linear device model. Each such iteration determines the value of the output for each corresponding
equation as a function of the values of the composite
inputs. This is illustrated by considering points on the
input and output curves (Figure 1) corresponding to
time ti; the time at the beginning of the previous interval is t i - I and ti = t i - I + At. The value of the output
function Vi at ti is calculated from the corresponding
value of the input function Ii and the entire response is
obtained by iterated computation. It is important that
the current input and output function values (Ii and
Vi) as well as the values corresponding to the previous
interval (I i - I and Vi-I) are made available at the beginning of each interval, since these determine the initial
conditions-the initial values and the slopes for
each At.
Given V TI and V T2, the threshold points associated
with the rising and falling input edges, the output response of logic gates may be looked upon as consisting
of three main regions:
(i) the region before V Tl,
(ii) the region between V TI and VT2 and
(iii) the region after V T2.
Each main region may consist of one or more subregions. Logic gates normally require one or more
subregional expressions3 to specify their transient response. While each subregion may be considered as a
continuous function, the interface point where a subregion begins is defined as a discontinuity. Because of
FUNCTION Ii
Figure I-Macro-modelling and waveshaping of continuous
expressions for the rise and fall times with discontinuities
Implementation of a Transient Macro-Model
the discontinuities associated with the output of these
gates, they may be referred to as multiregional gates.
Examples of multiregional responses are the modified
bipolar and MOST gates. 3 The input-output conditions
and transient relationships for each region are different
and are considered separately in the simulation. This is
consistent with the principle of piecewise linear
analysis. s
For the output region preceding V TI, an important
consideration is the comparison of the slope of the input
function at each time interval ~t with the slope of a
curve Y i, which is governed by the internal time constant associated with the gate input.
In general the region between V TI and V T2 is governed
by T D, a delay time elapsing after V TI, and by the
relevant transient relationship of the gate. TD depends
on the relationship in time between the rate of rise of
the input Ii and the inherent time constant Y i associated with the gate input. For similar gates, the variation in TD is of little concern, but in a system employing interfacing with different gates, the changes in the
value of TD and in the position of V TI must be taken
into consideration. Given that Ii is much faster than
the internal time constant Y i , TD is determined by Y i ;
whereas, if Ii is slower than Y i , TD is governed by the
input. The required input relationship at interface
points is established and the required TD computed.
This region is also governed by an intrinsic curve Xi
derived from the internal switching characteristics of
the gate. 2 ,S,9 A comparison of the current values (Xi
and Vi) at each ~t detects the presence of a discontinuity in the response. The value and slope at the point
where a discontinuity occurs are stored as new initial
conditions for the next continuous subregion.
The region after V T2 which may also be multiregional
is governed by TDD, the storage time elapsing after
V T2, and the appropriate input-output transient relationship. TDD is an important parameter and governs
INVERTED
OUTPUT Vi
NORMAL INPUT
SHORT IN:U: _ _ _ _ _"-- _ _
\
\
\
\
\
\
\
\
\
INPUT Ii
Figure 2-Effect of a short pulse width on the rising response
1073
DOMINANT INPUT Ii
INVERTED OUTPUT Vi
Vi
I·
TOO> Ip
Figure 3-Effect of a short pulse width on the storage time
the output response of tpd. An appraisal of T DD is
therefore included in the macro-model.
Assuming that the input waveform consists of
reasonably wide pulses, the corresponding output \vaveform Viis predicted in a normal manner by considering
the parameters T D and T DD for the logic module. If,
however, the duration of the input pulse Ii is short
and comparable with TD and TDD, then prediction of
V i must be based on the consideration whether the
input levels turn the output stage O~ or drive it into
saturation. It may be seen that this consideration determines whether the output is a pulse waveform or
consists of partial pulses or humps. This assessment is
made with accuracy by the simulation method, which
computes the initial conditions (V i-I and V i-2) at the
beginning of each output interval ~t subsequent to an
enquiry of the conditions at the input. This is further
explained through the waveforms shown in Figures
(2), (3) and (4). Figure 2 shows the case when tp , the
pulse width of the dominant input I i to a gate as
measured between the two threshold points V Tl and
V T2, is small and V T2 follows V Tl before the output
waveform Vi reaches the '0' level. As no storage time
(TDD) considerations are involved, it may be seen that
the response Viis only a partial pulse; the settling time
at the lower level of the output Vi (before the output
starts to rise) is only due to the intrinsic charge in the
switching circuit. Figure 3 shows the negative edge of
the input Ii and the output Vi of a saturating gate at
the '0' level initially. If the transition of the input
from V T2 to V Tl has duration less than TDD, then the
output does not change until a time TDD has elapsed
after the point V T2. A third case is illustrated by Figure
4 where the time from V T2 to V TI (at the lcwer level
of the input Ii) is larger than TDD. In this case the
output rises at the end of TDD. If, however, the time
1074
Spring Joint Computer Conference, 1972
DOMINANT INPUT Ii
lNVERTED
OUTPUT Vi
forms a feedback loop with module 7. The scanning is
started by giving an enabling initial condition to the
feedback input of module 7. This may be done by considering~ the . loop open at the beginning of the first
time interval ti; this provides an output for module 7
and hence for module 8. At the beginning of the next
time interval, ti+l, the feedback input is then made to
take the value of the module 8 output thus giving the
corresponding output value for module 7, and the entire
output response is obtained by the usual iteration
Figure 4-Effect of a short pulse width on the falling response
from V Tl to V T2 (at the higher level of the input I i) is
short such that the output Vi does not reach the '1'
level, then the output continues to rise for a time TD
from the point V T1 and then starts to fall.
These cases are obviously for inverting gates but the
argument applies equally to gates without inversion at
the output.
MARK AS
CALCULATED
FEEDBACK LOOPS AND FLIP-FLOPS
A sequential circuit can be thought of as a combination of two simple NOR gates connected in a closed
loop. The output of each NOR gate drives the input of
the other. Actual sequential circuits do not in general
behave ideally. Changes in voltages at the outputs of
secondaries may not be simultaneous even though their
inputs are; at high speeds even short interconnections
may introduce significant delays. Unfortunately these
various delays do not simply slow down the operation
of the circuit, they may introduce functional errors and
give rise to hazards. As a result of the inability to specify
exactly when a given signal will actually make a transition from one state to the other, Szygenda, Rouse and
Thompson7 associate an ambiguity interval with each
.signal. The requirement of an ambiguity interval is due
to the fact that gates of the same type could have
different propagation times; hence the time delay of a
gate is represented as a minimum value plus an ambiguity region. The approach in this paper, however,
does not require the postulation of ambiguity intervals,
since the propagation delays are accurately represented
in the Macro-Model developed for each particular
gate considered.
The simulation of feedback paths in a system is
illustrated by considering Figure 7 in which module 8
NO
SET INITIAL
VALUE IN ALL
STACK STORES
AND RESULT
SET RESULT
EQUAL TO TOP
OF STACK
HOVE VALUES
IN STACK UP
ONE STEP
ADD LATEST
INPUT TO BOTTOM
OF STACK
Figure 5-Algorithm illustrating pure delay and unit-step delay
Implementation of a Transient Macro-Model
1075
principle. This in effect may be interpreted as including
a delay At in the feedback loop. It may be seen that
the overall error in propagation time depends upon the
ratio Atlntpd where tpd is the individual delay of n
modules constituting the feedback. This principle is
easily extended to the simulation of sequential circuits
e.g., flip-flops which can be considered as two crosscoupled inverting NOR gates. For inputs originating
from a source with a pure delay, the values are those
obtained during the previous iterations ti-d determined
from the respective values of the actual delay d as a
function of time steps. This principle is illustrated in
the flow chart of subroutine DELAY as shown in
Figure 5.
MODEL IMPLEMENTATION
From the two different modes of handling time and
processing events, i.e.,
(i) the next event formulation of a simulation model
which is time variable and dependent on the
events to be considered subsequently and
(ii) the fixed time step model,
the latter mode approach was chosen. A fixed time
step model requires the user to specify a size for the
time increment At to be used when the model is employed for simulation. In fixed time step simulation all
response values are treated as if they all happened
simultaneously at the upper end of the interval. Because of this, merely changing the size of the time increment to a large arbitrary value can radically alter the
interrelationship of event occurrences.
It is noted that although a time step of any positive
magnitude At allows the simulation to be executed, the
meaning and validity of the results is related to the
value of At. A very large arbitrary value of At may
lead to inappropriate initial conditions. The conditions
corresponding to a discontinuity or subregion may be
left unscanned and the resulting response may have an
incorrect subregional waveshape. At is chosen to be less
than TD and TDD and is for example 1 or 2 ns for gates
with switching times of the order of 10 ns. On the other
hand, a fundamental problem associated with simulation is the time synchronization of model elements.
This problem exists because the real network may perform certain phenomena simultaneously while the model
must perform these phenomena in a sequential manner.
The simulator MILS (Macro-modelling of Integrated
Logic Systems) is based on a "fixed-step" time-increment concept,l1 where a search is done for the next
event after the current event has been met and passed.
Figure 6-Algorithm illustrating the scanning procedure
in simulated time
The actual simulation mechanism used, however, is a
special case of this concept; in fact this mechanism can
be considered as a special case of the "next-event" 11
principle, since all events do occur simultaneously at
the ends of the time intervals and will be processed together until the next time is looked for. There is, however, a definite order in which events occur. This order
is proceduraF2 and is related to the logical interconnection and physical layout of the system. It is obvious
that the card order in the simulation program may not
be the same as the order of events occurring and in
this respect the program description is non-procedural.
In the simulation, each gate or circuit is treated as a
box with a sequential number N as well as a type identification number. The description of the modules which
may be of different kinds, are previously stored. Input
functions, which may occur anywhere in the system,
are designated "input-boxes" and included in the simulation with a sequential number. Each unit (or box)
has response states at times ti and ti-I, the latter corresponding to the initial condition and, in general, the
response states of boxes of similar or different type
numbers need not have the same quantized value. To
obtain the response of the system at a certain node, the
corresponding discrete value of the input function is
obtained and, while time stands still, the output of all
the modules are evaluated by scanning in a sequential
order. Owing to the topological configuration of a sys-
1076
Spring Joint Computer Conference; 1972
SYSTEM IMPLEMENTATION
Figure 7-A circuit configuration which has DTL modules and
includes a feedback loop; f30 and F t were taken as 10 and 500
MHZ respectively
tem, the outputs of some modules may not be available
in a sequential scanning in which case the scanning of
these modules is repeated with the help of pointers,
until all the modules have functioned once. The operation then moves to the next interval, a new value of the
input function is introduced, and the corresponding
output value evaluated. The entire response is thus
obtained by similar scanning. This procedure is illustrated in Figure 6.
Assuming identical box types, the output function
Vn,ti of the box n considered at time ti is dependent
on the status J n,ti-l of the output function. This status
is determined from a knowledge of the position of the
scanning time ti with respect to the input function;
and J n, ti-l has different values above V Tl and below
V T2. The m inputs of box n are first searched-not
necessarily in a sequential order-to determine which
input is dominant. This depends on the logic operation
being performed. This resultant dominant input associated with input k is then designated Ik,ti at ti and then
compared with the previous value Ik,ti-l to determine
the slope of the rising and falling input functions. If the
j input to a box n is connected directly to an input-box,
then the input value will be obtained from the appropriate specified input waveform at time ti by asimple
interpolation technique, but if the j input to box n is
not from an input-box then the input value Ik,ti will be
extracted from the· outputs of the m connecting boxes.
If an input is from the output of the same box, this
means that there is a feedback loop (seesection 4).
The previous value of the output function V n,ti-l is
compared with the current value Vn,ti to determine the
initial conditions at each time interval. An analysis of
the configuration shown in Figure 7 which has DTL
modules and includes a feedback loop (i.e., between
modules 7 and 8) was carried out by the simulation
technique discussed, and the responses at nodes A, B,
C, D, E, F are shown in Figure 8. The response at G
remains as expected, high. A list of the symbols used
in this section is given at the end of the paper.
Speed of simulation is an important requirement but
may be sacrificed if more accurate results are required
through a reduction in ~t. Although an assembler language would result in' a little faster execution and less
storage requirement, FORTRAN was chosen since it
would be easier to implement and is considerably more
machine independent. 7 Its use is justified because the
method itself is so efficient. The efficiency of this approach is illustrated in the storage and computing time
required on Queen's University ICL 1907; 9 K for 300
logic modules, 40 types of logic gates, 10 input waveforms; and 21 mill seconds for the 8 gates configuration
of Figure 7. FORTRAN is more compatible when dealing with numerical values in large arithmetic statements-as would be the case when computing the time
response in numerical form. PLAN (ICL MachineCoded Language) or PL/l has desirable features which
could be easily added to support the FORTRAN IV
system only in the part of the program not dealing
~
w
o
~
2.0
~
~
0,0
4r~-\
~2.0
.r~"\
Iii'
\
!:i
~
4.[-,
//
L
x
:I'
\
~---~--~-'"
0.0
~
\
I
"-"'~X-lC
1
r1'
____X~\
"-".
11.
I '
V
~
ao~ ______________________________________________________ _
o:/,
!w
o
4,0[_"_\
1v+'/~
~
o
~2.0
4.0
0.0
"
"
--><-~
~-
/'1'
~w
/
x,
x
--><--1'
10
20
x
,
*
/
~o
~
-w-.x-,c-~-~-)(_~x_.._ x _ x - X - ) ( _ > c _ w - J (
~
§2 0.0
/
:¥
\/
-------------------_________________________________ _
4.0
~
en
!:i
1I
'i<
!:i
~o~
/~_,.--..-_lC_-"--,
t-lC-_X-.c-
30
40
50
TIME IN NANOSECONDS
Figure 8
60
70
80·
~
90
Implementation of a Transient Macro-Model
with numerical values especially in the STORE part,
hence increasing the efficiency.
However, FORTRAN programs can grow excessively
large for two reasons: firstly that they contain a large
number of instructions, and secondly that they require
a large amount of storage, usually for arrays. Programs
which are large for the first reason can usually be overlaid. MILS provides a way of treating the storage in a
similar fashion. An area in core can be used to hold the
part of a larger storage area that is required at a given
time, selected from the larger area held on disc storage.
When the part is no longer required it can be written
away to the disc storage and the next part can be
brought down into core store previously occupied by
the first segment. There is no restriction on the order
in which sections of storage are accessed. The storage
described in this paper is scratched space, i.e. ,any information stored on it is lost when MILS is terminated.
The system uses files on magnetic disc devices to store
the information. Files can be on either EDS or FDS
(exchangeable disc storage or fixed disc storage)
scratch files. A maximum of eight files can be declared
at anyone time. A file must be declared by a CALL to
a subroutine which declares a scratch file of length K
elements. One element is required for each real or integer array element. Two elements are required for
each complex or double-precision array element;
another parameter is for the channel number by which
the file is to be referred and must be an integer; a third
parameter is for EDS or FDS. The area on the disc is
treated as a string of elements numbered from one upwards. It is required to keep track of the start positions
of each of its arrays on the disc by means of pointers.
This is illustrated by the two subroutines:
sisting of hundreds of logic gates, with complex situations and allows a more accurate prediction of transient
performance and propagation delay. The method can
be used for studying statistical variations of delays and
switching times without employing regressional analysis. The individual elements of the logic module could
also be modified for worst case analysis without affecting its macro-appearance. Further, the approach lends
itself to predicting the effects of multiple reflections and
crosstalk in a system with a given number of interconnecting paths and tap-offs. An analysis of these effects
forms an important and interesting part of the overall
system simulation. While a large amount of work has
been done3 to simulate these effects, in view of the
space and time available, a discussion of this aspect
will be outside the scope of this paper.
LIST OF SYMBOLS
m
N
n
CONCLUSIONS
This formulation technique of an integrated logic
module permits the analysis of large networks, con-
Dominant input function to a box n at time
ti determined from previous boxes' outputs
I i for simplicity
Dominant input function to a box n at time
ti-l (ti':""l = t i - Llt) determined from previous boxes' outputs
I i-I for simplicity
Status of the output function at time ti-I
Input number considered
Dominant input box number
Maximum number of inputs to a box
The sequential number given to a box
The box number being considered excluding
all the preceding input boxes I x I
IN-xl
CALL STACK (C, K, A)
CALL ACCESS (C, K, A)
where C in the channel number, K is the element
number of the first element to be transferred and must
be a variable as the value of K will be altered by any
of the routines and A is the array name.
X and Yare array elements declared as A (I, J - - - -) ,
A (L, M - - - -). The values given to all dimensions of the
array element Y must be greater than or equal to those
ofX.
Each of these subroutines writes to or reads from
the file with channel number C starting at element K.
K must be a variable and have a value greater than or
equal to 1.
1077
TD
TDD
Vn,ti
Current time considered
Previous time considered (ti-I = ti- Llt)
Previous iteration time determined from the
respective values of the actual delay d as
a function of time steps (ti-d = ti - d)
Delay time above V T1
Storage time below V T2
Output function at ti for the box considered n
V i for simplicity
Output function at ti-I for the box considered n
V i-I for simplicity
Threshold point for a leading input edge
Threshold point for a trailing input edge
ACKNOWLEDGMENTS
The author wishes to record his thanks to Professor
W. D. Ryan for his inspiration in the development of
the macro-modelling technique, to Mr. S. Q. Hossain
for his initiation to the interconnection problem, to
1078
Spring Joint Computer Conference, 1972
Mr. Sam Hogg and the Staff of the University's Computer Laboratory for useful discussions in the design
implementation of the simulator and to my wife,
Elfriede, who typed the manuscript.
REFERENCES
1 J A NARUD
Computer-aided analysis and artwork generation for integrated
circuits
IEEE International Convention New York 1970
2 J A NARUD M L DERTOUZOS G P JESSEL
Computer-aided design for integrated circuits
IEEE International Symposium on Circuit Theory Florida
December 1968
3 N B RABBAT
M acro-Modelling and transient simulation in large integrated
digital systems
PhD thesis The Queen's University of Belfast October 1971
4 N B RABBAT W D RYAN S Q HOSSAIN
Computer modelling of bipolar logic gates
Electronics Letters Vol 7 pp 8-tO 1971
5 D KOEHLER
Computer modelling of logic modules under consideration of
delay and waveshaping
Proceedings of the IEEE Letters Vol 57 pp 1294-1296 1969
6 G G HAYS
Computer aided design: simulation of digital design logic
IEEE Transactions on Computers Vol C-18 pp I-tO 1969
7 S A SZYGENDA D M ROUSE
E W THOMPSON
A model and implementation of a universal time delay
simulator for large digital nets
Spring Joint Computer Conference AFIPS Proceedings
Vol 36 pp 207-216 1970
8 D K LYNN C S MEYER D J HAMILTON
A nalysis and design of integrated circuits
McGraw-Hill Book Co Inc New York 1967
9 N B RABBAT W D RYAN S Q HOSSAIN
Transient analysis of modified TTL gate
Electronics Letters Vol 7 pp 22-24 1971
to N B RABBAT W D RYAN S Q HOSSAIN
Macro-modelling and transient simulation in integrated
digital systems
To be published International Computer-aided design
Conference University of Southampton England April 1972
11 G W EVANS G F WALLACE G L SUTHERLAND
Simulation using digital computers
Prentice-Hall 1967
12 B J KARAFIN
The new block diagram compiler for simulation of sampled
data systems
Spring Joint Computer Conference AFIPS Proceedings
Vol 27 pp 53-62 1965
Functions for improving diagnostic resolution
in an LSI environment*
by MADHUKUMAR A. MEHTA
GTE A utomatic Electric Laboratories Incorporated
Northlake, Illinois
and
HENRY P. lVIESSINGER
Illinois Institute of Technology
Chicago, Illinois
and
WILLIAM B. SMITH
Bell Telephone Laboratories Incorporated
Holmdel, New Jersey
test circuit that will identify, by observation of the
output alone, any stuck at "0" or "1" input failures to
the particular input involved. Such a test circuit is
termed an "Ambiguity Resolver" CAR) function, and
proof of its existence for any number of inputs ,vill be
presented. The identification of a failure to a particular
input in general actually only isolates the failure to the
bus that is connected to that input because of the
propagating tendency of failures on a bus. Thus, all
LRU's connected to the bus implicated are equal
candidates to have failures on their bus connections.
A capability such as provided by AR functions would
obviously be of little use in a situation in which buses
tend to be common to a group of LRU's. However,
when the observable points are restricted to the functional outputs, conventional methods usually do not
provide resolution of input/output faults to a unique
bus. This feature is conveniently provided by the usage
of AR functions.
Let us define some of the terms and clarify the notations used in this article.
INTRODUCTION
LSI implementation of digital circuitry opens the door
to the consideration of dramatically new approaches to
the design of system fault diagnosis. 1 New constraints
have been added, such as the difficulty of inserting test
access points internal to large pieces of circuitry. At
the same time, failure modes seem to be changing with
bonding lead failures increasing in importance. 2 •3 This
paper presents an approach that leans heavily on the
assumption that adding additional logic to a circuit is
of little consequence, whereas it is important to reduce
the access provided for testing capability. As the practicality of the proposed approach has not been examined
in detail, the concept is primiarly presented to stimulate
further study into the special problems and opportunities involved in diagnosis of LSI systems.
The approach discussed here is to incorporate on each
least replaceable unit CLRU) a special combinational
* Parts of this paper are excerpts from Dr. Mehta's Ph.D. Thesis.
Dr. Messinger of Illinois Institute of Technology served as an
academic adviser during the course of the thesis, while Dr. Smith
of Bell Telephone Laboratories acted as a thesis adviser. Dr.
Mehta is with GTE Automatic Electric Laboratories which also
supported the thesis.
DEFINITIONS AND NOTATIONS
Observable Points: points at which the outcome of an
applied test procedure can be observed.
1079
1080
Spring Joint Computer Conference, 1972
the inputs or the outputs. A distinction is made between
the inputs to the circuit (Ai) and the leads which carry
these inputs to the circuit. Small letters with identical
subscripts (ai) designate the corresponding leads for
any input. Similar notations are used to distinguish
the outputs and the output leads. A fault at the input
lead is fed back to the input (output of the driving
gate) only if it is a propagating fault (i.e., if it affects
the entire bus). A lead ai with a s-a-O fault, in tables
and figures, is denoted by symbol aP; ail similarly
denotes the same lead with a s-a-1 fault.
BONDING LEADS
Z SPECIAL
F1 : THE BASIC FUNCTION
Fll : THE DUPLICATED FUNCTION
F2 : A COMPARE FUNCTION
Figure I-One way to use redundancy
Failure Exclusive Points: a set of points only one of
which is affected by anyone assumed failure.
Independent Inputs: two inputs are independent iff
(if and only if) the logic state of either can be changed
without affecting the logic state of the other.
Sensitized Path: a path between a point in a combinational circuit and the output is sensitized if a change
of logic conditions at that point results in a change of
logic conditions at the output while other inputs are
not changed.
Output Vector: the ordered set of (binary) outputs
that result from the application of a test procedure (a
sequence of tests). The output vector corresponding to
no-fault conditions is called the normal output vector
and is denoted by ~n; also ~f denotes the output vector
for the same test procedure when fault f is present.
Complementary Failures: Stuck-at-O (s-a-O) and
Stuck-at-1 (s-a-1) failures at a particular point (input
or output) are called complementary.
Least Replaceable Unit (LRU): the smallest subsystem which will be completely replaced if a fault is
located at the terminals of, or inside, the subsystem.
Capital letters of the English alphabet are used to
denote the inputs and the outputs of a circuit. Usually
the early letters (A, B, C) are used for the inputs
while the later letters are reserved for the outputs
(Z, Y, X, W). Exceptions in these notations are made
when dealing with networks to avoid duplicate labeling
for connections (buses). Subscripts are used to identify
AMBIGUITY RESOLVER (AR) FUNCTION
Since LSI implementation makes redundant logic
economic to use, we examine the possible ways of using
redundancy (internal to a LSI circuit) to simplify fault
diagnosis of digital systems.
One of the ways to use the redundancy is the conventional approach of duplicate and compare (Figure
1). Two disadvantages prevent this scheme from being
attractive. First, the required redundancy is excessive;
it takes more than double the circuitry to implement
this approach. Second, the approach simplifies the
diagnosis of only the internal faults. For the diagnosis
of the faults at the bonding leads one has to still resort
to other approaches. Unfortunately, a predominant
failure mode in systems composed of LSI, that have
been in systems which are in operation for awhile, is
due to bond failures. 2 •3 Therefore, the approach of
BONDING LEADS
METALLIZATIONS
Zm
F....r---_A
ZSPECIAL
AMBIGUITY
RESOLVER (AR)
FUNCTION
Figure 2-Another way. to use redundancy
Functions for Improving Diagnostic Resolution
Figure 1 does not represent an efficient usage of redundancy.
The proposed approach (Figure 2) consists of a
specialized single output test function (F) for simplifying the diagnosis of input faults. These Ambiguity
Resolver (AR) functions are combinational logic
functions which have the property that input/output
faults can be resolved to a unique bus through the
observation of the output alone. We will show that such
functions exist and that they are simple in comparison
to the normal function (FI). AR functions simplify the
fault diagnosis of digital systems implemented with
LSI circuits because:
T ABLE I-Outcomes of a Test for Complementary Failures at
the Input ak and their Implications
Test Input Conditions Normal
A1- - - - -An
Output
ako
ak 1
CTi
CTi
= 0 or 1
fault insensitive
2
CTi
iii
CXki
=
3
Ui
CTi
(Xki
=1
4
Ui
iii
Not realizable
Possibility
(1) A predominant failure mode in operating IC's is
bond failures which result in input/ output
faults. The AR functions simplify the diagnosis
of only the input faults; however, the output
faults will become input faults of the driven
LRU's and therefore will be diagnosed by their
AR functions. It is reasonable to assume that
the faults of the unused outputs do not affect
the system performance.
(2) AR functions permit resolution of input/output
faults to a unique bus. Such resolution is not
always available by the use of conventional test
procedures when the observable points are
restricted to the functional outputs.
(3) Only one point need be observed for diagnosis.
(4) Since the AR function (F) is unrelated to the
basic function F I , its design is completely
independent; for example, FI may be a sequential
function, yet F can be a simple combinational
function. Due to this independence, often
diagnosis using AR functions requires fewer
tests in comparison to a conventional test
procedure.
Although the AR approach simplifies fault diagnosis
of LSI implemented systems, it is certainly not the
complete answer. For example, the AR approach
requires testing, and thus does not provide an on-line
detection of faults. Also AR function provides neither
fault detection nor diagnosis of faults within an LRU.
Therefore, in any practical application, the AR approach would probably be augmented with other, more
conventional methods.
Since the AR function can be independently designed,
in the following sections, we will disregard the basic
function. We will concern ourselves only with single
output combinational functions which have the AR
IORI
Implications for
the test
CXki
0
property. We will assume:
1.
2.
3.
4.
Only input/output faults.
Only s-a-I, s-a-O faults.
One fault at a time.
Access to only the inputs of the function. That
is, only the inputs can be controlled externally.
5. Output is the only observable p:::>int, i.e., the
performance of the function, during the test
procedure, can be observed only at the output.
In order to clarify some of the concepts presented
here, Section 8 presents an example of the use of AR
functions along with a conventional scheme for comparison.
COMPLEMENTARY FAILURES
Understanding the constraints that are imposed on
circuits being tested is required before we can gointo a
discussion of the existence of AR functions. An important constraint is on the allowable outputs for complementary input failures.
Consider a test ti that applies the input aIia2i . . . ani
to a circuit, and consider a particular input lead ak (see
Table I). If the output of the circuit is (Ji under the
test ti, then the output can be either (J i or a- i for ak s-a-O
and similarly for ak s-a-l. If the output is (Ji for ak both
s-a-O and s-a-l, then the output is fault insensitive to
ak. If the output is a-i for ak s-a-O and (Ji for ak s-a-I,
then it is clear that ak must have a "I" input for this
test ti. A similar story is true for output (J i for ak s-a-O
and a-i for ak s-a-l (ak has a "0" input). However, it is
not possible to have an output a- i for both kinds of
failures because this would imply that a- i is always the
1082
Spring Joint Computer Conference, 1972
output for ak with either 0 or 1 input, which contradicts
the original assumption. Theorems 1 and 2 state the
results just given, which are proved elsewhere in detaiL7
They are given below because the results will be used
later.
Theorem 1:
The outcome of a test ti cannot be different from
normal case under both a s-a-O and a s-a-1 failure at
the same input.
normal output vectors. Finally, each input fault must
yield a unique, non-zero and non-all l's output vector.
Theorem 3:
If the permissible failure modes include complementary faults at the inputs and at the outputs, then
the complement of the normal output vector for an AR
function is different from the resulting output vectors
for all permissible failures.
Proof:
Theorem 2:
If the outcome of the test ti is different from the
normal case for the fault ii, then the outcome of the
test ti for the complementary failure is identical to the
normal case.
Finally, each detectable failure must produce a
non-normal output for at least one of the tests. For that
test, by Theorem 2, the complementary failure must
have normal output. Therefore" the resulting output
vectors for complementary failures cannot be the same.
Thus, although this is not necessary for localization of
input faults to a unique bus, complementary failures of
AR function will always be distinguishable. Having
established this, we are now in a position to formally
define the AR function.
DEFINITION AND PROPERTIES OF AR
FUNCTIONS
Definition: An n-input AR function is a combinational
function of n variables with a single output with the
following properties:
1. All faults are detectable, i.e., there exists a test
procedure T containing p tests such that 1 ~ p ~ 2n
and ~n~ ~fi for any fault fi.
2. All faults produce unique output vectors for the
test procedure T, i.e., ~fi= ~fi iff fi=fj.
Any such set of p tests will be referred to as Test
Pattern of the AR function (under the fault assumptions
made earlier) .
Some elementary properties are easily derived from
the basic definition of the AR function. Clearly, the
output faults yield either an all D's (s-a-O) or an all
l's (s-a-1) output vector. Also, the normal output
vector for the test pattern has to be non-zero and
non-all l's since output faults are to produce non-
Since the normal output vector is non-zero, non-all
l's, the complement of the normal output vector (~ii)
is also non-zero, non-all l's. Thus ~ii is different from
the resulting output vectors for the output faults.
N ext assume that the resulting output vector for an
input fault fi is identical to ~ii. This implies that the
outcome for each test tj (1 ~j ~ p) for the fault fi is
different from the normal case. Now consider the
complementary failure Ji. By Theorem 1, for any test
tj the outcome for both failures at the same input
cannot have different performance from the normaL
Therefore (by Theorem 2), the outcome for each test
tj (1 ~j ~ p) for the fault Ji must be identical to the
normal case. Thus the resulting output vector for the
fault Ji for the test pattern T will be identical to the
normal case. But this is a contradiction since the fault
Ji during the test pattern T must produce a unique
output vector different from the normal case. Thus the
resulting output vector of an input fault of an AR
function also cannot be identical to ~ii. (Q.E.D.)
N ext we examine other properties of AR functions
which will permit synthesis of new AR functions from
A1
A2
A3
a1
a2
Zi
Zi
a3
Figure 3a-Not conformal because faults at aa violate condition 1
Functions for Improving Diagnostic Resolution
a1
a2
a3 -a4
Fl
F2
~
z
J
"0"
A2
A3
Figure 3b-Not conformal because faults at a2 violate condition 1
the available AR functions. It will be shown that the
resulting functions have the AR property when certain
structural constraints are observed. The concept of
conformal structure, introduced next, provides one
convenient way to produce new AR functions. It should
be noted, however, that although conformal structures,
as defined below, have the AR property, structures
having the AR property need not be conformal.
Definition:
When a one output combinational function is
generated by the use of AR functions and logic gates,
the resulting structure is conformal iff
1. Each input failure of the resulting function
results in a permissible input failure at one,
and only one, of the AR functions,
2. No two input failures of the resulting function
result in an identical input failure condition at
any AR function,
Fl
F2
z
Z
A4
A5
°1
°1
°2
°3
z
°2
°3
Figure 3c-Not conformal because s-a-O faults at a2 and a3
violate condition 2
z
°4
°5
1083
Z
Fl
Figure 3d-Not conformal because the test pattern for F2 may
not be possible (condition 3)
3. Application of the test pattern for each AR
function is possible by control of the inputs of
the resulting function, and
4. For the output of each AR function, a sensitized
path to the output of the resulting function
exists.
Figure 3, where Fl and F2 are AR functions, illustrates
a number of structures which are not conformal for one
or more reasons.
The motivation for the use of various conditions in
the above definition can be intuitively explained at this
point. Condition 1 insures that each input fault can be
made distinguishable from the other faults by the test
pattern of one of the AR functions. The second part of
the condition ("only one") prevents one input fault
°1
°2
Fl -Z1
°3
°4
°5
F2
Z2
1\
z
Ll
Figure 3e--Not conformal because the output Zl violates
condition 4
z
1084
Spring Joint Computer Conference, 1972
from affecting more than one AR function. The resulting
output vectors of each AR function need a sensitized
path to the final output to be observable under normal,
as well as under various failure conditions. One of the
ways to provide such a path is to maintain a unique
combination of the inputs at the remaining AR functions (which provides a sensitized path) during the
testing of each AR function. Following this procedure,
in addition, permits distinguishability of the input
faults of one AR function from the input faults of other
AR functions as we will see. If an input fault of the
resulting structure affected more than one AR function,
this procedure may not be possible in all cases. Condition 2 prevents multiple input failures from having
identical output vectors, thereby permitting the
required localization. Condition 3 assures the ability to
apply test patterns to various AR functions, and the
condition 4 makes the resulting output vector available
at the final output of the resulting structure.
Having established some structural constraints and
some intuitive basis for them, we proceed to prove the
AR property of conformal structures.
Theorem 4:
A conformal structure implemented with AR functions and logic gates results in an AR function.
Proof:
Let F 1, F2 , • • • Fn be the n AR functions used in
the conformal structure. We will refer to these functions
as component AR functions. Let Zi be the output of
the function F i and let Z be the output of the resulting
function F with conformal structure.
To prove the AR property of the resulting conformal
structure, we will show the existence of a test procedure
which provides the distinguishability of the input/output faults of F.
As the structure is conformal, each input fault of the
resulting structure results in a permissible input fault
at one (and only one) AR function. Thus the set of
input faults of the resulting structure is a subset of the
input faults of the component AR functions. Also due
to the second condition of conformality, these input
faults of F produce unique input faults at the component AR functions. Thus if the input faults of the
component AR functions are distinguishable, then the
input faults of the resulting function are also distinguishable.
Consider a test procedure wherein we apply the test
pattern to each component AR function, one after
another, by control of some of the inputs while maintaining the remaining inputs at some logic conditions
so as to provide a sensitized path to the output Z
throughout the test pattern. The conformality of the
structure accounts for the feasibility of such a test
procedure. We will show that this test procedure
provides the required distinguishability.
To show the distinguishability, we will follow these
steps. First we will show that input faults of any F i are
distinguishable from the other input faults of the same
AR function. Next we will show that these faults are
distinguishable from the faults at the output Z. Then
we will show the distinguishability of these faults from
the input faults of the other AR functions. Note that
the distinguishability is symmetric, i.e., if a is distinguishable from b, then b is distinguishable from a.
Therefore, the distinguishability of the output (Z)
faults from the input faults of the resulting structure is
easily established. Finally, we will show the distinguishability of the output faults from each other.
During the test procedure, the test pattern Ti is
applied to F i, and a sensitized path to the final output
for the output Z i is provided. As F i is an AR function,
its input faults produce unique non-normal output
vectors at Zi for the test pattern Ti which due to the
availability of the sensitized path are transmitted to
the output Z. (The normal output at Z may be the
same as, or could be the complement of, the output at
Zi during the test pattern Ti as sensitization does not
guarantee the polarity of the output. But as the uniqueness is what we are concerned with, and as uniqueness
is preserved under complementation, we do not worry
about the polarity.) Note that due to the conformality
of the structure during the test pattern T i only permissible faults (s-a-O or s-a-l) exist at the inputs of
the function F i . Further, as we consider only a single
failure, when we are considering the distinguishability
of the two input faults of F i, the path sensitization can
be assumed to be failure free. Thus the input faults of
Fi produce unique output vectors at the output Zi,
which in turn, produce unique output vectors at the
output Z. Therefore, the input faults of Fi are distinguishable from the other input faults of the same
AR function F i, when test pattern T i is applied as a
part of the proposed test procedure by observing Z.
Also, as the resulting output vector at the output Z for
each input fault is different from normal, the input
faults are detectable.
N ow consider the distinguishability of the input faults
of the function F i from the output faults at the output
Z. Observe that when the test pattern Ti is applied,
as a part of the test procedure, the observed output
vector for the faults at the output Z will be either all
Functions for Improving Diagnostic Resolution
O's or all l's. While the input fault of the function Fi
results in a non-normal, non-zero, non all l's output
vector at the output Zi, and will be transmitted to the
output Z due to availability of a sensitized path. Also
as all the properties (non-normal, non-zero, non all1's)
of the output vector are preserved even under complementation, the resulting output vectors at the output Z,
for the input faults of the AR function F i, are nonnormal, non-zero and non all l's. Therefore, the input
faults of F i are distinguishable from the faults at the
output Z when the test pattern T i is applied.
N ow consider the distinguishability of the input faults
of one AR function, say F i, from those at the inputs of
the other AR functions, say F j where i~j. The two AR
functions, Fi and Fj, do have independent inputs* due
to condition 1 of the conformal structure. Therefore,
during the testing of F i by the test pattern T i, to
provide a sensitized path a single combination of the
inputs of F j can be used throughout the test pattern
T i . The input faults of the function F j would result in
one of four cases during the test pattern T i •
1. It does not affect the final output.
2. It makes the final output a complement of what
should be (changes the polarity of sensitization),
i.e., fails all tests in T i .
3. Makes the final output a logic 0 for all tests.
4. Makes the final output a logic 1 for all tests.
In the first case, the resulting output is normal; in
the second case, it is always the complement of the
normal; in the third and the fourth cases it is at a
permanent logic condition for the test pattern T i .
Since the input faults of F i, on the other hand, result
in unique, non-normal, non-zero, non all l's output
vectors, they are distinguishable from the input faults
of F j in cases 1, 3, and 4. Further, by Theorem 3, the
complement of the normal output vector cannot be the
same as any output vector for the input faults. Therefore, the input faults of the functions Fi and F j are
distinguishable.
As we repeat the procedure for each AR function,
each input fault of every component AR function will
be distinguishable from other input faults and from
the output faults at Z.
Finally, as the property of distinguishability is
symmetric, the output faults are distinguishable from
the input faults. Also as the output faults produce an
all O's or all l's output vector and as normal output
vector has a logic 0 and a logic 1 element, the output
* An input fault of F only affects one of the F /s.
1085
faults are detectable and distinguishable from one
another.
Therefore, as the test procedure considered, provides
unique, non-normal, output vectors for various faults,
the resulting conformal structure has the AR property
and the test procedure is its test pattern. (Q.E.D.)
It becomes apparent that the formulation of conformal structure provides us with a great flexibility in
generating new AR functions. Of these, three are
worthy of specific mention.
Corollary 1: The complement of an AR function is an
AR function.
Corollary 2: The AND function of AR functions is an
AR function if the resulting structure is conformal.
Corollary 3: The OR function of AR functions is an
AR function if the resulting structure is conformal.
EXISTENCE OF A GENERAL N-INPUT
AR FUNCTION
There are a number of ways by which we can prove
the existence of an n-input AR function, for any n. For
instance, it is easy to show that a parity network* with
any number of inputs has the AR property. However,
for three or more inputs other functions, apparently
less complex, also exhibit the AR property. We, therefore, will create simple two- and three-input AR functions and use them in a constructional proof for proving
the existence of a general AR function. This proof is
preferred because it also provides a scheme for generating relatively simple AR functions.
Existence of a 2-input AR function
Figure 4 shows a two input exclusive OR function.
Also shown are the resulting functions for various
faults. Note the uniqueness of the resulting function
for each fault. As the resulting function for each fault
is unique and non-normal the exclusive OR function is
an AR function. Table II shows a test pattern for the
AR function. That this is a test pattern can be shown
by generating the resulting output vectors for various
conditions and showing their uniqueness.
Existence of a 3-input AR function
Figure 5 shows a three input function. Also shown are
the resulting functions for various faults. As the result-
* A single output network using exclusive OR gates.
1086
Spring Joint Computer Conference, 1972
fa
BONDING LEAD
aI
\
;
{METALLIZATION
BONDING LEAD
r
METALLIZATION
01
Zt (NORMAL) = 01 02
Zt (ZtO)
=
Z1 (z 11 )
Zt (a to)
+
°
1
=
02
01 02
Zt (olt)
=
02
Z1 (020 )
Zt ( 02 1)
=
01
= at
Figure 4-A 2-Input AR function
Zl (NORMAL)
=01 0 2+'01 0 3
Zl (Z10)
= °
Z1 (Z11)
1
Z1 (021) = 01 +°1 0 3 = 01 +03.
Zl(010)
03
Zl (all)
= 02
Zl (030) =01 0 2
Z1 (03 1) = 01 0 2+°1 =02+01
Zl (02°) = 01 03
Figure 5-A 3-Input AR function
Proof:
ing function for each fault is unique and non-normal the
function has the AR property. Note that the function
of Figure 5 is simple compared to a three input parity
network. Table III shows a test pattern for the AR
function of Figure 5. That this is a test pattern can be
shown by generating the resulting output vectors for
various conditions.
Having shown the existence of 2- and 3-input AR
functions we now show the existence of a general
n-input AR function for n ~ 2.
We have already shown the existence of 2-input and
3-input AR functions. Consider any integer n>3, then
it is always possible to find integers q and r (25:. q 5:. n/2
and 05:.r5:.1) such that n=2q+3r. In other words, for
all even integers, we have r=O, and q= (n/2) while
for odd integers r=l and q=[(n-3)/2J.
Since the OR function of AR functions is an AR
function by Theorem 4 (Corollary 3), we can generate
an n-input AR function for n > 3 by generating an OR
function of q 2-input AR functions and r 3-input AR
functions with conformal structure. Therefore, n-input
AR function exists for any finite n~2. (Q.E.D.)
Theorem 5:
THE CONVERGENCE PROPERTY
There exists an n-input AR function for any finite
n~2.
In the previous sections, we examined few techniques
to generate new AR functions. The functions, thus
TABLE III-A Test Pattern for the 3-Input AR
Function of Figure 5
TABLE II-A Test Pattern for the 2-Input AR
Function of Figure 4
Inputs
Inputs
Normal Output
Test No.
1
2
3
Normal Output
Test No.
Al
A2
0
0
1
0
1
0
0
1
1
1
2
3
4
Al
A2
A3
0
0
1
1
1
0
0
1
0
1
1
0
0
1
0
1
Functions for Improving Diagnostic Resolution
generated, had the property of failure localization to a
single bus for the input/output faults of the resulting
function. To that extent, these new functions can be
used internal to the LRU to provide the failure localization capability. If we provide an AR function in each
LRU, the special output (the output of the AR function) of each LRU must be made observable. Does the
possibility of reducing the total number of observable
points exist? To answer this, we consider if convergence
of AR functions by an AR function preserves the failure
localization property.
First, let us illustrate what we mean by a converging
connection. Let F I , F2 , ' • " Fn be n AR functions.
Further, let each Fi have mi inputs and one output.
Also let Fe be an AR function with n inputs. Now consider a configuration, shown in Figure 6, where the
output Zi of each Fi is connected to the ith input of Fe.
Let Z be the output of Fe. The resulting structure will
be termed a converging connection.
It can be shown7 that when the inputs to a converging connection are independent and failure exclusive, the input/output faults of each component
AR function (F/s or Fe) are locatable by observing Z
alone. Thus a test procedure exists which produces
unique output vectors at the final output Z for each of
the faults at the inputs (aij; 1:::; i:::; n, l:::;j:::; mi) or at
the outputs (Z/s or Zc). Further, it can be shown that
° it
°12
°lm1
1
°21
°22
°2m2
2
Ant
An2
Anm n
Zl
Fl Oct
-
F2
Z2 °c2
Fc
°cn
--=.:...:.-
I
I
I
ant
°n2
°nmn
I
Fn
Zc
Z
1087
Zi = A1A2 A 3
Z2= Al+A2+A3
Figure 7-A simple LRU for example subsystem
the length of such a test procedure does not exceed the
sum of the tests in the test patterns of the component
AR functions. The detailed proof of this result, which
follows a similar line of reasoning as that of Theorem 4,
is rather lengthy and is, therefore, not included.
N ext we demonstrate the application of converging
connections in reducing the number of points which
must be observable. Note that in Figure 6 if all AR
functions Fi were used in different LRU, all of the
n outputs Z/s must be made observable. In that case,
the test pattern Ti however, can be applied simultaneously to each AR function F i. Thus the number of
tests would be equal to the maximum of the number of
tests in the test patterns T/s. On the other hand, by the
use of a converging connection we are able to reduce
the number of points which must be made observable
to one (from n). But the length of the test procedure to
obtain the same degree of diagnostic resolution· is now
equal to (or less than) the sum of the number of tests
in all the test patterns T i (1:::; i:::; n) and the number of
tests in the test pattern Tc for the AR function Fc.
AN ILLUSTRATIVE EXAMPLE
-Zn
F
Figure 6-A convergent structure
To illustrate the application of AR functions, a very
elemental LRU (Figure 7) is selected as a building
block of a simple subsystem (Figure 8). Realistic
systems, of course, would be considerably more complex.
A comparison is made of the AR approach with present
day techniques in terms of the required number of
1088
Spring Joint Computer Conference, 1972
A
Zl1
B
C
0
a 11
a
12
a13
zll
Fll
Z12
a32
Z21
E
a 21
F
a22
G
a23
z31
a 31
z12
* Z31
F13
a33
z32
Z32
The proposed approach
z21
F12
fully chosen input combination at the inputs of F12 to·
simultaneously provide the required test combinations
if the output Z2l was observable. Finally test 13 is
necessary to provide the remaining test combination
for F12 when output Z2l is made observable. Thus we see
that a total of thirteen tests and four observable points
are required for localization of all faults.
Z22
z22
Z31 = A+BCD+E+F+G
Z32= ABCD (E+F+G)
Figure 8-An illustrative subsystem
* The points which are to be observable are identified
by the arrowhead
observable points and the length of the required test
procedure.
A conventional approach
As can be easily inferred from the functions for Z31
and ZS2, if the observable points are restricted to the
final outputs (Z31 and ZS2) , all faults cannot be localized.
For instance, the s-a-O faults at all, a12 and alS and s-a-1
fault at Zl1 are indistinguishable. Similarly, the s-a-1
faults at a2l, a22, and a2S and s-a-O fault at Z22 are indistinguishable. The distinguishability of these faults
can be obtained if the outputs Z12 and Z2l are made
observable. Thus to obtain a complete localization we
need four observable points.
Table IV shows a conventional test procedure for the
subsystem generated by the use of well-known techniques. (4,5,6) The first four tests provide the testing of
the faults at the inputs of F H • The conditions at the
other inputs are maintained as prescribed to provide a
sensitized path to the output ZSl. One of these tests also
provides an all zero test for F 12. The next three tests
similarly provide the testing of the faults at the inputs
of F 12 . Note that the input combinations for F H , to
provide a sensitized path for the output Z22 during
these tests, are carefully chosen to simultaneously
provide the tests for FH when the output Z12 is observable. The eighth test provides partly for the testing
of the input aSl. Observe that so far only a subset of the
total tests required is applied (indirectly) to F IS • The
conditions corresponding to the remaining tests are
applied by the tests 9 through 12. Note the use of care-
N ext, consider the use of a three-input AR function
(FAR) as shown in Figure 9, which is the function
discussed in Section 6. One output is to be added to
the LRU to make the output of the AR function
observable.
Consider the implementation of the subsystem using
LRU's with AR functions as shown in Figure 10. Table
V shows the required test procedure to locate all faults,
except the ones at the outputs ZSl and ZS2, by observing
only the outputs of the three AR functions (ZlS, Z2S, Zss).
Outputs ZSl and ZS2 will be inputs to some other LRU's
and therefore their faults will be localized by the AR
function of those LRU's. Recall that for each AR
function four tests are required (Table III). If the
TABLE IV-A Test Procedure for the Subsystem of Figure 8
(Without AR Functions)
Test
No.
Test Procedure
Inputs to F13
A
B
C
D
E
F
G
A
Zll Z22
1
2
3
4
1
1
1
1
0
1
1
1
1
0
1
1
1
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
0
1
1
1
1
5
6
0
0
1
0
1
0
1
0
0
0
0
1
0
1
0
1
0
0
1
1
1
1
7
1
1
1
1
1
0
0
0
8
0
0
0
0
0
0
0
0
1
1
9
10
0
0
1
0
1
1
1
1
1
1
0
1
1
0
0
1
1
0
1
0
1
0
1
1
0
0
0
1
0
0
1
0
0
1
0
0
0
1
1
11
12
13
1
1
0
Functions for Improving Diagnostic Resolution
1089
TABLE V-A Test Procedure for the Subsystem of
Figure 10 with AR Functions
01
-
Zl
r--
z2
~
F2
1'0- .......
a ....
"-
--
2
Zl
-
r"""_
-
1--- _ _ _ _
"-
FAR
z3
Z3
03
Zl=
A1A2 A 3
Z2=
Al +A2 + A3
Inputs to F 23
Test Procedure
A
B
1
2
0
0
0
0
3
4
1
1
1
1
5
6
0
1
1
1
C
D
E
0
0
F
G
A
Zll
Z22
1
0
0
0
1
1
0
0
1
1
1
0
0
0
0
0
0
0
1
1
Z2
....
~-
Test
No.
Figure 9-The LRU with AR function
conditions corresponding to this test pattern are
applied to each of the AR functions, then the fault
localization will be achieved. The first four tests provide
the conditions for the test pattern of the AR functions
in F21 and F 22 • In so doing, by applying appropriate
conditions at the input A we also manage to provide
the conditions corresponding to two of the four tests
for F23 • The last two tests provide the remaining tests
for F 23 . Note that we use the results at the output Z33
only if we have determined that no input fault exists
at F21 and F22 i.e., when Z13 and Z23 do not show a
1
0
0
0
1
1
1
0
1
1
1
1
0
0
0
0
0
0
0
failure. Thus the output Z33 is used only to detect and
locate the input faults of F 23 •
Thus a test procedure with six tests and three
observable points is sufficient to localize the failures. If
we would like to reduce the number of observable
points further, we can use a converging (Section 7)
AR function Fa such as the 2-input AR function of
an earlier section (Figure 11). 3 The points \vhich must
be observed are the outputs Z33 and Z41. But \vhen we
reduce the number of observable points by converging
we pay a penalty in the length of test sequence. Recall
that, as per upper bound it would take 11 tests to test
the convergent structure (as a two input AR function
requires three tests). Two additional tests will be required to provide the remaining tests for the AR
function F 23 as before. And thus a total of 13 tests may
be necessary. However, as shown in the test procedure
of Table VI, the actual number of tests required for the
converging connection is only eight, and therefore, a
total of nine tests are required (Tests 1 and 5 are
identical). Note that the required test pattern for the
A
A
Zll
B
Zll
B
C
D
E
F
G
zll
°Il
°12
°13
F21
z12
z13
C
Z12
Z13
Z21
° 21
°22
°23
F22
D
° 31
°32
°33
F23
z31
z32
z33
Z31
Z32
Z33
z21
Z22
z22
Z23
z23
Figure IO-Implementation of the subsystem using LRU's
with AR functions
E
F
G
°11
°12
°13
z11
F21
°21
°22
023
F22
°31
°32
z12
z13
z21
z22
z23
F23
°33
Z21
°41
F3 z41
Z22
Z23
z31
z32
z33
Z31
Z32
Z33
Z41
°42
Figure ll-Use of a converging connection to reduce the points
which must be made observable
1090
Spring Joint Computer Conference, 1972
TABLE VI-A Test Procedure for the Configuration of Figure 11
Inputs to F23
Test Procedure
Test
No.
-+1
2
3
4
-+5
6
7
8
9
10
A
B
C
D
E
F
G
A
Zn
Z22
Z13
Z23
0
0
0
0
1
1
1
0
0
1
0
1
0
0
0
0
0
1
1
1
1
0
0
0
0
0
0
1
1
1
1
1
1
0
0
0
0
0
1
0
1
0
0
0
0
0
1
1
0
0
0
0
1
1
1
1
0
0
0
0
0
0
1
1
1
0
0
1
0
1
1
0
0
0
1
1
1
1
1
0
0
0
0
0
0
0
0
0
1
0
1
0
1
1
1
1
1
1
1
0
0
0
0
0
0
0
1
0
0
1
1
1
1
0
0
1
0
converging AR function Fa is applied in the process of
applying test patterns for the AR functions of F21 and
F22 • Table VII summarizes these results for the subsystem considered in the illustration.
It iEl important to note that the AR function design is
unrelated to the function actually performed on an
LRU, but is only dependent on the number of inputs.
Thus in practical LSI applications, as the level of
integration goes up and as the gate/pin ratio increases,
the percentage redundant logic required for AR function will decrease.
TABLE VII-Comparisons of the Different Approaches to
Implement a Subsystem (Figures 8, 10, and 11)
No.
Case
No. of Points Length of the Test
Which Must be Sequence for Fault
Localization
Made Observable
LRU's without
AR functions
(Figure 8)
4
2
LRU's with AR
functions
(Figure 10)
3
6
3
2
LRU's with AR
functions and a
converging AR function
(Figure 11)
9
1
Inputs to F3
13
CONCLUSIONS
In this paper we have introduced the notion of adding
special Ambiguity Resolver functions to Least Replaceable Units in order to provide localization of
input/ output failures. We have demonstrated the
existence of these functions for any number of inputs
and shown how they can be synthesized by means of a
conformal approach. For those cases in which it is
important to further reduce the number of pJints that
must be made observable, a convergent structure is
discussed, along with an upper bound on the length of
the required test sequence.
The Ambiguity Resolver approach is certainly not
the complete answer to the fault localization problem
in Large Scale Integrated circuitry, but it is a step in
the direction of tailoring the diagnostic technique to
the characteristics of the environment.
REFERENCES
1 H Y CHANG E G MANNING G METZE
Fault diagnosis of digital systems
Wiley-Interscience New York 1970 Chapter II
2 G L SCHN ABLE R SKEEN JR
Failure mechanisms in large-scale integrated circuits
IEEE Trans on Electron Devices Vol ED-16 No 4 April
1969 pp 322-332
3 J E McCORMICK
On the reliability of microconnections
Electronic Packaging and Production Vol 8 No 6 June 1968
pp 187-189
Functions for Improving Diagnostic Resolution
4 D B ARMSTRONG
On finding a nearly minimal set of fault detection tests for
combinational logic nets
IEEE Trans on Electronic Computers EC-15 February
1966 pp 66-73
5 J P ROTH
Diagnois of automata failures-A calculus and a method
IBM Journal of Research and Development 10 1966
pp 278-291
1091
6 W H KAUTZ
Fault testing and diagnosis in combinational digital
circuits
IEEE Trans on Computers EC-17 pp 352-366
7 M A MEHTA
A method for optimizing the diagnostic resolution of
input-output faults in digital circuits
PhD Thesis Illinois Institute of Technology 1971
Computer-aided drug dosage*
by LEWIS B. SHEINER, BARR ROSENBERG and KENNETH L. MELMON
University of California Medical Center
San Francisco, California
and
University of California
Berkeley, California
can be used to determine optimal dosage regimens.
We have described a conceptual scheme and associated
statistical methodology to accomplish this objective. 1
In this paper, we summarize the scheme and methods,
provide justification for our approach, report early
results, and describe some future plans.
INTRODUCTION
Major efforts have been devoted to the application of
computational techniques to medical diagnosis, a difficult computational task. The amount of information
necessary to perform an exhaustive diagnostic search
is' formidably large. The "costs" associated with making certain diagnoses or eliminating others often affect
a tentative diagnosis as much as the probabilities of
the conditions being considered. These "costs" are
usually intuitively considered by the physician and
usually are not available as numerical quantities to
use in a linear programming algorithm. Lastly, diagnosis is done both rapidly and well by most physicians.
In contrast stands therapeutics, specifically the
administration of medicines. After deciding what and
how much effect is desired (choosing the drug and the
therapeutic objective) the problem is how much to
give and in what temporal pattern. Drug-dosing is
inherently quantitative and is presently done suboptimally. Accordingly, we have approached the construction of algorithmic techniques for determination
of drug dosage.
Since drug effects correlate far better with drug
levels in the body than with doses administered, a
Target Blood Level (TBL) approach to drug administration seems reasonable. In order to implement
such an approach, estimates of appropriate pharmacokinetic parameters for individual patients must be
obtained so that pharmacokinetic models, providing
the mathematical framework for drug level predictions,
BACKGROUND
Eighteen to thirty percent of all hospitalized patients
sustain one or more adverse drug Teactions2,3 and the
duration of their hospital stay is nearly doubled as a
result. In addition, 3 to 5 percent of all admissions to
hospitals are primarily for a drug reaction2,4 and 30
percent of these patients have another drug reaction
during their hospital stay. The economic consequences
of these reactions are staggering: one-seventh of all
hospital days is devoted to the care of drug toxicity,
at an estimated annual cost of 3 billion dollars.5 The
same amount would cover the cost of all prescription
drugs used in this country per year.
An encouraging aspect of the .large adverse reaction
rate is that 70-80 percent of them are direct extensions
of the pharmacologic actions of the drugs involved, 6
and therefore should be predictable and preventable.
The maj ority of the pharmacologic adverse reactions
are probably not the result of extraordinary individual
sensitivity to the actions of the agent, but rather of
dosage regimens leading to inordinately high blood
levels.
The evidence which associates drug levels in blood
or tissues with their effects is striking. It is particularly clear-cut for those drugs responsible for more
* Supported
in part by United States Public Health Service
Grants GM 16496 and GM 10791.
1093
1094
Spring Joint Computer Conference, 1972
than 50 percent of dose-related adverse reactions: 6
digitalis preparations, 7 anti-arrhythmic drugs, 8, 9 and
antimicrobials. 10 As an example, consider digoxin, a
drug which, in clinical practice, is both highly useful
and formidably toxic. About 20 percent of all patients
receiving the drug demonstrate pharmacologic toxicity
and as many as 30 percent of those demonstrating
such toxicity may die of it.n A three-or-more-fold
variation in the blood levels of digoxin is seen in different individuals given the same doses of the agent,
but toxicity is highly correlated with blood levels: in
one study, 90 percent of individuals with levels less
than 2 nanograms/ml of plasma were nontoxic and
87 percent of those with levels greater than this amount
were toxic. 12 For digoxin, then, individual sensitivity
differences may account for as little as 10 percent of
clinical toxicity.
That levels of drugs in body fluids should bear a
more constant relationship to effects than doses administered is readily understandable. Drugs act on
receptors and elicit effects which are proportional to
the fraction of occupied receptors. The concentration
of a drug at its receptor is a major determinant of drug
effect. The utility of blood levels stems from the observation that although few drugs act on receptors in
the blood itself, after drug distribution, tissue concentrations of drugs (p~esumably at their sites of action)
bear a reasonably linear and constant relationship to
blood levels. Individual variation in absorption, distribution, metabolism and elimination of drugs, however, causes widely varying blood levels to be found
in different individuals, despite standard doses.
It seems clear, then, that a TBL approach to drug
dosage design is theoretically sound and likely to be
beneficial. Pharmacokinetic models can represent and
quantify variations in absorption, distribution, metabolism and elimination of drugs. In order to utilize
a pharmacokinetic model for the purpose of drug
dosage design, some way of predicting individual
variation in the parameters of the model must be
available. An obvious approach is to measure blood
levels of agents at varying time intervals after administration of a standard regimen and to adjust the
parameters of the model to yield a best fit to the observed levels. This is analogous to the way in which
most physicians administer drugs today: a standard
regimen is begun, effects are observed (presumably
proportional to levels) and dosage adjustments are
made based upon these observations. The quantitative
adjustments are more intuitive than optimal. We can
do better than merely improve the quantitative aspects
of the feedback process described above, although
doing only this can lead to excellent results. 13
The factors responsible for pharmacokinetic variation can be related to the physiological determinants
of pharmacokinetic processes. For example, digoxin is
primarily eliminated by renal excretion. The elimination rate of the drug should be, and is, proportional to
renal function. 14 Tests designed to assess renal function
[such as measuring the serum creatinine or Blood Urea
Nitrogen (BUN)] are routine. These measurements
can be used to modify the dosage regimen of digoxin
in accord with the excretory ability of the individual
patient.
The combination of prior clinical information with
quantitative feedback adjustment should produce a
system for optimal drug dosage design. In order to do
this we require a black box with the following characteristics: the inputs are clinical data, commonly and
easily available (such as height, weight, age, sex, and
the results of standard laboratory tests, e.g., tests of
renal function); the outputs are a set of predicted
values for the parameters of a pharmacokinetic model.
On the basis of these predicted parameter values, the
initial dosage of a drug can be set to produce the TBL.
As additional data in the form of blood level measurements or changes in the laboratory tests become available, estimates of the parameters can be optimally
modified (by the black box) to improve dosage suggestions.
THE DOSE-BLOOD LEVEL RESPONSE MODEL
The first task in the design of the black box is to
formulate a model for the relationship between the
TABLE I-The Conceptual Scheme
I.
Observations (0) ---+Physiologic Variables (P)
type: usually non-linear
data source: general population
example: Body Surface Area (BSA) = F (height, weight)
II. P ---+ Pharmacokinetic Variables (Q)
type: linear
data source: patients receiving drug
example: Volume of Distribution (Vd) = F (BSA)
III. Q ---+ Pharmacokinetic Parameters (K)
type: usually non-linear
data source: theoretical
example: Rate Constant of Elimination (Kel) =
Clearance IVd
IV. K ---+ Blood Level Predictions
type: non-linear pharmacokinetic model
data source: theoretical
example: one compartment model with first order
absorption
Computer-Aided Drug Dosage
clinical data and the pharmacokinetic parameters.
Our model is outlined in Table 1. Clinical observations
(0) are used to predict physiological variables (P).
These predictions can be defined through study of the
general population and need not be restricted to those
individuals who have received the drug of interest.
The relationships are not restricted as to type; they
may be linear, non-linear, discontinuous, etc. The
example given in Table I, Body Surface Area (BSA) ,
is a quantity estimated from a non-linear function of
height and weight and is expected to be more linearly
related to metabolic capacity and body "compartment" sizes than either height or weight. In Table I,
the pharmacokinetic model itself is a simple one: the
one-compartment open model with first order absorption. Its parameters (K) are: Kel, the first-order rate
constant of elimination of the drug; Vd, the volume
of distribution of the drug; and a series of Ka's and
f's, each pair representing the rate constant of absorption and the fraction of dose absorbed for a specified
route of administration. The K may be linearly related
to the P. For example, the Vd of a drug might be
predictable from a patient's body surface area, as
shown in Table 1. A non-linear function of a K might
bear a linear relationship to one or more of the P. An
example is the clearance of a drug (the product of Kel
and Vd) which would be linearly related to a P describing renal function (the Glomerular Filtration
Rate, GFR) if the drug were eliminated by the kidneys. To keep the scheme general, a set of pharmacokinetic variables, Q (distinct from the K) are defined
as functions, again of any variety, of the K. The Q
are defined wholly from theoretical considerations.
Finally, having defined the P and Q so that we expect
linear relationships to hold between them, we assert
that they are related linearly. The first data-fitting
task is that of estimating the coefficients of the linear
P to Q transformation. This can be done utilizing data
from individuals whose clinical observations are known
and whose blood levels of drug have been measured.
The full model allows utilization of general population data and prior information in the form of both
theoretical relationships and constraints on the coefficients to be estimated for the P to Q transformations.
The use of an extremely simple pharmacokinetic
model is justified on two grounds. First, for clinical
medicine, our scheme must be responsive to shifts in
patient characteristics and inexpensive to operate.
]\tIore parameters imply more data-fitting, degrading
responsiveness, and increasing cost. Second, most
drugs with clinical utility do not cause significant
toxicity until their blood levels are at least twice those
at which significant efficacy is achieved. Therefore,
1095
there is no need for great precision; prediction errors
of 50 percent should have little clinical import.
Before discussion of the problem of merging feedback
(blood-level) information with initial estimates, some
preliminary tests of the appropriateness of the conceptual scheme and of the ability to estimate coefficients for the P to Q relationship will be presented.
TEST OF THE MODEL
Dr. Thomas Smith of the Massachusetts General
Hospital kindly supplied us with clinical data, dosage
history, measured blood levels (one per patient) and
determinations of the presence or absence of toxicity
in a group of 99 patients who received digoxin. The
clinical data for each patient consisted of age, weight
and BUN. Fifteen patients were questionably toxic
and 18 definitely toxic by published criteria. ll •12 The
model was adapted to digoxin from the available clinical data, by using weight as a predictor of BSA, and
age, weight and BUN as predictors of renal function.
Vd was assumed proportional to BSA. Digoxin clearance
was assumed proportional to G FR and BSA since the
non-renal losses of digoxin are presumably metabolic
and should therefore be related to BSA. All digoxin
had been administered orally so that Ka and f values
for the oral route only were needed. Digoxin has an
absorption value (f) of .85. 15 While the precise rate of
oral absorption is not known, it is sufficiently rapid
relative to rates of elimination14 that an arbitrary large
value could be assigned to the oral-rate constant of
absorption without expected loss in accuracy. Data
was adequate to establish an expected value for Kel
for normal individuals, and to support the assumption
that digoxin clearance should be linearly related to
GFR.16 Data on the rate of non-renal loss of the drug
is scanty, and no clear data exist for estimating the
relationship between BSA and Vd. Accordingly, the
patient data were first used to estimate these values
using standard non-linear data fitting techniques.
The blood levels were weighted by the inverse of the
observed values plus the measurement error in their
determination because, on the one hand, with unweighted measurements, fitting to absolute errors
inappropriately magnifies the importance of those
patients with large measured blood level values, and,
on the other hand, data fitting by pure relative error
(corresponding to weighting by the inverse of the
square of the measured value plus the measurement
error variance) remove all bias toward greater predictive accuracy for higher values, which are the more
clinically important ones, being indicative of toxicity.
1096
Spring Joint Computer Conference, 1972
TABLE II-Relation Between Program-Predicted and Actual
Blood Levels of Digoxin in a Sample of 99 Patients
Information
Used
Correlation
Coefficient (r)
r2
crr2
.08
1. Daily dose
.29
2. 1 + model
.31
.10
+.02
3. 2 + weight
.42
.18
+.08
4. 3 + age
.47
.23
+.05
5. 4 + BUN
.73
.54
+.31
We arrived at a value of 9 percent per day non-renal
loss (as opposed to an estimate of 14.4 percent per
day16) and a Vd value of 351 liters/square meter of
BSA. It is noteworthy that these estimates could be
easily obtained from the crude clinical data at our
disposal. The use of our scheme permits estimation
of population values for pharmacokinetic quantities
from usual clinical data and does not demand separate
and elaborate experiments. This point is crucial, since
an individual blood level determination obtained from
clinical usage of the feedback portion of the system
will not only serve to improve the estimates of that
individual's responses, but also add to the data base,
making improved population estimates possible.
With the scheme set for digoxin and necessary
values obtained from the literature, or as noted above,
from the data itself, the ability of the scheme to predict blood levels of the patients, using various amounts
of prior clinical information, was examined. Table II
shows the resultant correlations. The only upward
bias in utilizing the correlation coefficients to describe
the predictive capacity of the system stems from the
use of one degree of freedom for the estimation of the
non-renal losses, since Vd operates in thepharmacokinetic model as a scale factor only. The fraction of
total variance in the actual levels which is explained
by the computed levels is expressed by r2; in the absence of any clinical data save the dose administered,
only 8 percent of the level variance is explained, while
use of all the clinical data allows explanation of 54
percent of the variance. Knowledge of renal function
makes the major contribution to accurate predictions,
but the patient's weight, the sole predictor of size
used, explains as much of the variation in levels as
does the dose. In order to exclude the possibility that
the few very high values present in the data were
responsible for the high correlation we obtained, despite
our weighting scheme, predictions were examined when
weighted by the inverse of the square of the measured
value plus the measurement error variance. Under
these conditions, the correlation coefficient for predictions made with full information fell only to .71.
l\{ore important, however, than the ability to predict the measured values with a modest degree of
accuracy, is the potential clinical implication of the
predictions. As has been mentioned, digoxin levels
greater than 2 ng/ml are associated with a significant
incidence of toxicity. Table III compares the toxicity
predictions of the actual measured levels, using this
cut-off point, with those of the predicted levels. Although the predicted values are not quite as good at
predicting toxicity as are the measured values (there
are, however, no significant differences in the columns
of Table III by x2 analysis), use of the scheme might
have prevented 10 of the 18 toxicities in this group
of patients. Clearly the potentially prospective availability of the predictions and the non-toxic dosage
schemes they would engender outweigh the slight
(retrospective) diagnostic advantage of the actually
measured levels.
THE FEEDBACK PROCESS
The requirement for feedback adjustment of the
model parameters is that it make an orderly transition
from estimates of an individual's pharmacokinetic
parameters based solely upon population data to ones
based to a greater extent upon measured blood levels
of the drug. Our approach is based upon an estimation
scheme valid in circumstances where an individual
parameter vector characterizing responses (in our
case, the Q vector "characterizes" the blood level
"response") is dispersed about a population mean
(that is, individual vectors are similar, but not identical) Y This regression method allows efficient estimation of the mean value of the parameter vectors in the
population, of the extent of dispersion of ind.v.dual
parameters about the population mean, and of the
TABLE III-Comparison of Predictions of Digoxin Toxicity by
Actual and Program-Predicted Blood Levels
Levels Used
Predictions of Toxicity
False Total Correct
False +
Actual
10/66
3/18
71/84
Program-predicted
11/66
8/18
65/84
Computer-Aided Drug Dosage
values of the parameter vectors characterizing each
individual. In our case, population data is used to
estimate a mean population Q vector, the appropriate
adjustments to be made in this vector for the values of
clinical observations, a population variance matrix of
parameter prediction error, A, and the variance of
prediction error associated with individual blood
levels, (7"2. An individual's Q vector is assumed to be
the sum of the population mean vector adjusted for
his set of clinical observations, plus an individual
shift vector, originally unknown, with mean value,
zero. For initial dosage suggestions, the shift vector is
assumed to be zero. For the feedback portion of the
system, given A and (7"2 and the actual versus predicted
blood level for the individual, a non-zero value is assigned to the individual shift vector so as to maximize
the prediction likelihood function (an empirical Bayes
estimator). A more complete description of the statistical methods underlying this approach can be found
in References 1 and 18. What occurs, in effect, is that
the information content of a blood level measurement
is used to decrease the uncertainty of our knowledge
of the components of an individual's Q vector (and
hence his K vector) so as to minimize the mean square
error in the resulting blood level predictions.
TEST OF THE ESTIlVIATION SCHElVIE
Examination of the problems attendant upon estimation of a population dispersion matrix has begun. The
simpler case of an underlying response model linear in
the explanatory variables (the P) was studied first.
Despite the linearity of the underlying model, an
analytic solution is not apparent for the dispersion
matrix; thus, even in the linear case, one is forced to
use non-linear techniques to maximize the likelihood
function. For this reason the linear and non-linear
cases share many characteristics. If efficient estimation
of a ,dispersion matrix could not be .accomplished in
the linear case, we would be pessimistic about the
ability to do so in the non-linear case. The problem
can be reduced to a search over the space of triangular
matrices, T, such that TT' = A. The number of parameters to be estimated by non-linear methods is
therefore p=k(k+l)/2, where k is the dimension of
A. The Fletcher-Powel1 algorithm has been used to
seek a maximum of the likelihood function over this
space. The results of similations to date have been
uniformly encouraging. The likelihood function is
smooth and well behaved, and is well described by
analytical derivatives. Regardless of the initial esti-
1097
mate chosen for T, the search algorithm converges to
the same maximum and the same estimate for [2,
indicating that the likelihood function has a unique
extremum. Convergence appears to require fewer than
3p iterations in all but a few cases, and 4p iterations
has been the maximum. Thus the non-linearity of the
problem appears to pose no difficulties.
lVlore important, a relatively small amount of data
appears sufficient to generate a satisfactory estimate
of A. With four simulated observations on each of
forty individuals, the estimates have consistently approximated the relative magnitudes of the diagonal
elements of A, and the signs and magnitudes of the
off-diagonal elements.
CURRENT WORK
The preliminary results obtained in the development
of both the conceptual and estimation schemes has
been encouraging. For the initial prediction portion,
it was a simple matter to write an interactive program
to run in a time-shared mode (for use via a remote
access terminal) which would accept clinical observations on a patient as well as the (physician determined) TBL and deliver a dosage scheme (at present,
for digoxin only) adjusted for the individual, and
designed to produce the TBL. We note that although
it is possible to provide information on the usual range
of therapeutic blood levels for a drug through the
program, the actual TBL for an individual patient
should not be pre-programmed. It is precisely in the
choice of this value that the physician is called upon
to exercise his judgment as to the severity of the condition being treated, the therapeutic objectives sought
and the projected sensitivity of his patient.
The interactive program and the initial dosage suggestions are being tested in a prospective fashion.
Out-patients in need of digitalis or in need of adjustment of digitalis therapy are being studied. Both the
primary physician and the program are suggesting
regimens and predicting blood levels for these patients.
The program output is made available to the physician
for a randomly selected portion of the patients, and the
physicians administer the drug as they see fit. Comparisons will be made in the accuracy of blood level
predictions by the physicians and the program, and
in the results of treatment (both for efficacy and
toxicity) obtained by administration of programsuggested regimens.
The estimation scheme is being further tested by
Monte Carlo studies. Multiple blood level data is being
1098
Spring Joint Computer Conference, 1972
obtained on patients reCeIvmg digoxin so that the
procedures for estimation of A can be tested. The
questions of major interest are: (1) How much data
is necessary to estimate A and how valuable is knowledge of the population dispersion in predicting individual blood levels? (2) What is the "trade-off"
between clinical observations and subsequent blood
level determinations; e.g., how many blood level
determinations does it take to make up for lack of
knowledge of renal function? (3) Do blood levels drawn
early in the course of therapy, when maximum blood
levels are not yet attained and toxicity is highly improbable, contribute substantially to the ability to
predict future (maximum) blood levels? (4) At what
point is the further determination of blood levels
unnecessary; that is, when do they cease to contribute
new information? We expect to have partial answers
to these questions for digoxin at the time of the Spring
J oint Computer Conference, and will devote the major
portion of our presentation to discussing them.
SUMMARY AND CONCLUSION
We have devised a conceptual scheme which successively relates routinely available clinical observations
to measures of underlying physiologic and pharmacokinetic factors and, ultimately, to pharmacokinetic
parameters. These parameters can be used in a pharmacokinetic model to produce optimal initial dosage
suggestions tailored to individual needs. We have also
proposed a statistical methodology for adjustment
and improvement of individual estimates in the light
of subsequent response data. Preliminary tests of the
various portions of the system have been uniformly
encouraging. The scheme is highly general; most of
the definable influences on drug absorption, distribution, metabolism and elimination can be represented,
quantified, merged with others and tested in relation
to blood level data. As a consequence of the statistical
techniques used and the degree to which extensive
exploitation of prior information is possible, determination of even a single blood level for an individual
should markedly improve the system's predictive
accuracy for him. Drug levels determined in order to
improve treatment for an individual also contribute
to the underlying data base used to update the various
estimated population coefficients. Thus, the system
can learn. A broad definition of what constitutes clinical observation will allow us to use the pharmacokinetic
variables determined for one drug, for one patient, in
. the estimation of the pharmacokinetic parameters for
another drug for him, if a meaningful relationship
holds between them. Hence, the system is a research
tool.
REFERENCES
1 L B SHEINER B ROSENBERG K L MELMON
Pharmacokinetic modelling for individual patients: A practical
basis for computer-aided therapeusis
Comp and Biomed Res submitted 1971
2 L G SEIDL G F THORNTON J W SMITH et al
Studies on the epidemiology of adverse drug reactions III.
Reactions in patients on a general medical service
Bull Johns Hopkins Hosp 119: pp 299-315 1966
3 B C HODDINOTT C W GOWDEY
W K COULTER et al
Drug reactions and errors in administration on a medical ward
Can Med Assoe J 97: pp 1001-1006 1967
4 N HURWITZ
Admissions to hospital due to drugs
Br Med J 1: pp 539-540 1969
5 K L MELMON
Preventable drug reactions-causes and cures
New Eng J Med 284: pp 1361-68 1971
6 R I OGILVIE J RUEDY
Adverse drug reactions during hospitalization
Can Med Assoe J 97: pp 1450-1457 1967
7 T W SMITH V P BUTLER E HABER
Determination of therapeutic and toxic digoxin concentrations
by radioimmunoassay
New Eng J Med 281: pp 1212-1216 1969
8 J T BIGGER D H SCHMIDT H KUTT
Relationship between the plasma level of diphenylhydantoin
sodium and its cardiac antiarrhythmic effects
Cire 38: pp 363-374 1968
9 J KOCH-WESER S W KLEIN
Procainamide dosage schedules, plasma concentrations, and
clinical effects
JAMA 215: pp 1454-1460 1971
10 C M KUNIN
A guide to use of antibiotics in patients with renal disease-A
table of recommended doses and factors governing serum levels
Ann Int Med 67: pp 151-1581967
11 G A BELLER T W SMITH
W H ABELMANN et al
Digitalis intoxication-A prospective clinical study with
serum level correlations
New Eng J Med 284: pp 989-997 1971
12 T W SMITH E HABER
Digoxin intoxication: The relationship of clinical
presentation to serum digoxin concentration
J Clin Invest 49: pp 2377-2386 1970
13 L B SHEINER
Computer-aided long-term anticoagulation therapy
Comp and Biomed Res 2: pp 507-518 1969
14 J E DOHERTY W H PERKINS
M C WILSON et al
Studies with tritiated digoxin in renal failure
Am J Med 37: pp ,536-544 1964
Computer-Aided Drug Dosage
15 J E DOHERTY
The clinical pharmacology of digitalis glycosides: A review
Am J Med Sci 255: pp 382-414 1968
16 R W JELLIFFE
A mathematical analysis of digitalis kinetics in patients with
normal and reduced renal function
Math Biosciences 1: pp 305-325 1967
1099
17 C R RAO
The theory of least squares when the parameters are stochastic
Biometrika 52: pp 447-458 1965
18 B ROSENBERG
Linear regression with stochastically dispersed parameters·
Biometrika submitted 1971
Automated therapy for nonspeaking autistic children*
by DAVID CANFIELD SMITH, MALCOLM C. NEWEY and KENNETH MARK COLBY
Stanford University
Stanford, California
CHARACTERISTICS OF AUTISTIC CHILDREN
But the most characteristic attribute is his inability
to acquire language. An autistic child has great difficulty understanding the relation between human
vocal sounds and meaning. Those that do develop
some speech have trouble advancing beyond nouns
designating concrete objects to pronouns and verbs
with their inherent abstractions. All studies agree that
the prognosis for an autistic child is closely correlated
with speech development; an autistic child who has
not developed speech by the age of five has in the
past almost invariably been institutionalized for the
rest of his life. If a child has speech, therapy for his
other disorders has a far greater chance of success;
indeed, absence of language may in itself account for
many of his other shortcomings. Having speech, he
may begin to play with other children, to go to school,
and to build a model of the world that is no longer
devoid of concepts transmitted through language.
Though autism is admittedly an imprecise category,
the best estimates currently available indicate the
incidence of autism to be 4-5 per 10,000 children,
about the same incidence as deafness and blindness in
children.
The main thrust of our effort, then, is to stimulate
language development using a method which is acceptable to an autistic child on his own terms. We
give him a chance to play with a machine which happens to be a linguistic entity.
Earlier publications described our computer method
for stimulating language development in nonspeaking
children, sketched several case histories (Colby 19684),
and gave statistical evidence that our high rate of
success (71 percent) was due to our treatment method
(Colby and Smith 19706). This paper presents some proposals for making the method more widely available.
The term "Childhood autism" refers to a psychiatric
category of mental disorders occurring in children.
Though the category is somewhat unreliable, there is
a set of characteristics generally associated with autism.
Some of the characteristics of autistic children that
influenced our approach and our choice of them as
subjects are described briefly. More complete descriptions are provided by (Rimland 19644), (Wing 196614),
(Ornitz and Ritvo 196810), (Colby 19684, Colby and
Smith 1970 6).
An autistic infant's early disinterest in play or being
picked up develops into a clear unresponsiveness to
people during his second and third years. He avoids
contact with other people, sometimes running and
hiding from strangers. He does not respond when
spoken to, and may be diagnosed as deaf. He may be
fascinated by spinning objects and machines, such as
phonographs, washing machines, light switches, etc.
Far from being mentally retarded, an autistic child
may be more adept than normal children at music
and mathematics, and may have a better memory.
A COMPUTER METHOD FOR TREATING
AUTISTIC CHILDREN
* This research is supported by Grant PHS MH 06645-10 from
the National Institute of Mental Health, by (in part) Research
Scientist Award (No. 1-K05-K14, 433) from the National
Institute of Mental Health to the third author and by (in part)
the Advanced Research Projects Agency of the Office of the
Secretary of Defense (SD-183).
While our eventual goal is to implement our method
on a system with modest or no computer support, our
initial approach was dictated by the resources available to us and by our need for flexibility and modifiability. For these reasons we used the large computer
system at the Stanford Artificial Intelligence Project,
Stanford University. That system is a time-shared
The views and conclusions contained in this document are those
of the authors and should not be interpreted as necessarily
representing the official policies, either expressed or implied, of the
Advanced Research Projects Agency or the U.S. Government.
1101
1102
Spring Joint Computer Conference, 1972
DEC PDP-6/PDP-10 combination (DEC 19688).
The PDP-6 is primarily used as an I/O driver at Stanford; it controls digital-analogue and analogue-digital
converters, among other input/output devices. The
faster PDP-10 serves as the central processor. Actually
a time-sharing system is not particularly suited to our
method, because the need for rapid responses of long
duration imposes real-time constraints which are
incompatible with the philosophy of time-sharing. In
fact, our need to output continuous sound of up to
three seconds duration has not yet been implemented
to our complete satisfaction.
Our goals of a flexible, easily-modifiable system with
a minimum of programming effort initially led us to
choose a high-level programming language MLISP
(Smith 197012), a dialect of LISP. Admittedly this was
like using a sledge hammer to kill a fly, but MLISP
enabled us to concentrate most of our early effort on
the program itself and not on developing a programming system. Subsequently, our entire system was
rewritten (by Malcolm C. Newey) in machine language. It was decided to invest the additional programming effort to gain the greater efficiency of machine language because the developmental phase of
many of the games had been completed, and they are
no longer being modified. In addition to the basic
program itself, we and others at Stanford have developed a set of programs and program modules that
facilitate the construction and modification of games.
Among these utility programs are a drawing program,
with which figures and animation can be easily drawn
on a display using a light pen, and a sound recording
program with which sound of up to three seconds
duration may be recorded, digitized, and stored on the
disk.
For hardware we use a computer-controlled Information International Inc. (III) graphics display with
a screen about 2/X2' in size that is refreshed 30 times
per second. The need for rapid response, including
animation, argued against the economy of a storagetube display. At present, input is by an alphanumeric
keyboard resembling a typewriter keyboard; the
child presses a key, and a response is generated. We
are currently investigating the possibility of light-pen
interaction, so that the child can draw his own figures,
and of microphone interaction, so that the computer
would be activated by a voice signal rather than a
keyboard signal. An associated, rapid-response auditory display is generated by randomly accessed, digitized records of voice, animal and mechanical sounds.
The sounds are recorded using one of the utility programs, digitized at 20KC, and stored on secondary
storage (IBM 2314 disk). About 1000 audio-visual
experiences are available in the currently used set of
games, requiring nearly 5 million words of disk storage.
When a sound is to be played, it is retrieved from the
disk, passed through a digital-to-analogue converter,
and output through a speaker system. The high recording rate (20KC) was arbitrary; we wanted good
clear fidelity, but a lower frequency (10KC or 5KC)
could be used since we tend to favor low, vibrant
sounds.
Thus we utilize at Stanford a PDP-10. a III display with keyboard, an IBM 2314 disk drive with 5
million words of secondary storage, and a D / A converter with a speaker system. Clearly these heavy
requirements make the widespread replication of our
total system impossible. However, we have anticipated eventual implementations of the method on
small machines, and even on non-computer-controlled
devices (as discussed below), by a modular construction of our programs. The sound and display files are
organized into separate and distinct "games". Each
game emphasizes a particular aspect of linguistic
development. In most cases they do not share files;
each game may be separately loaded into the computer much the same (conceptually) as tape cassettes
may be loaded into a tape recorder. (In fact, that is one
possible implementation of a non-computer device.)
The different game modules may be summoned by
the sitter, a non-professional adult who is present at
all therapy sessions. The following descriptions of the
games are from an earlier paper (Colby and Smith
1970 6). The descriptions are still valid because, as was
mentioned earlier, these games are in their final form.
Many games continue to be developed, but their
philosophy is similar to that of the games presented
here. These games are better described by the slides
and recordings which will accompany presentation of
this paper.
Game 4 is especially worth noting in view of the
autistic child's impaired affective relationships with
other people. Elements of compassion are introduced
obliquely in several of the frames. For example, in one
series a cartoon of a large ice cream cone is accompanied
by sounds of loud, happy slurping, and the word
SLURP! Then the top scoop falls off (PLOP!), and
there is a groan of dismay. The sad faces of many
children viewing this reveal clear communication of a
shared emotional experience.
Game 1 : Letters and numbers. The letter, number
or symbol of the pressed key is displayed accompanied
by a male or female voice pronouncing the appropriate
sound. Many of the letters are shown in different sizes
and shapes, and a few are drawn in motion automatically on the video screen.
Game 2: Words. Single words appear on the screen
in response to pressing a key. The words consist of
Automated Therapy for Non-Speaking Autistic Children
verbs and adjectives involving affect and motion, e.g.,
'laugh', 'jump', and 'angry.' The affect terms are not
only stated but enacted, i.e., the voice laughs while
saying 'laugh.' All the major positive and negative
affects are referred to in an attempt to exercise the
child's affective repertoire. For example, the word
'kill' is spoken very belligerently, and the combination
'XYZ' is accompanied by a contemptuous Bronx
cheer.
Game 3: Phrases. A letter or number is displayed
in response to the corresponding key being pushed.
Following the symbol appears a word or a phrase
containing it one or more times, with arrows pointing
to these occurrences. A male or female voice states the
word or phrase. The words and phrases are selected
on the basis of common occurrences in the child's life
(e.g., 'funny', 'upstairs') and because of their absurdity
(e.g., 'fried filet from Farnsworth', 'lambs go baaaaaa I').
Game 4: Cartoon pictures. This game consists of
displayed phrases and pictures along with human,
animal, machine and other sounds such as music. The
figures consist mainly of animals and machines, with
very few humans. Crude motion is achieved by moving
the animals' legs or moving a vehicle across the screen.
The pictures and sounds are intended to be ludicrous,
absurd and amusing to children.
Game 5: Phrase completion. A phrase or sentence
consisting of several words appears on the screen in
response to a key; e.g., pressing 'J' produces 'the cow
jumps over the moon.' A male voice expresses the
sentence over and over until the child stops it by
pressing any other key. When 'J' is pressed again the
same thing happens, but on the third occurrence,
while the full sentence appears, the voice omits part
of it, saying e.g., 'the cow jumps over the - - - . ' The
intent is for the child to fill in the omitted word or
phrase, which is omitted one of three times.
Game 6: Word construction. Here the letters of the
alphabet appear in a square around the edge of the
video display. On pressing a key, a trumpet sounds
with the Los Angeles Rams 'Charge!' call, a female
voice says, 'Here comes the word,' a male voice states
the word, e.g., 'cat,' and another male voice pronounces
the letters, which one by one light up and move to
the center of the screen to form the word. The word
is again stated when the spelling is completed. The
game demonstrates how words are put together letter
by letter.
Game 7: Phrase construction. The alphabet is displayed at the bottom of the screen. In response to
pressing a key, letters move to the top of the screen,
following individual paths, to form a phrase, one word
at a time. The effect is of chaotic motion resolving
itself at the end into a coherent word.
1103
Game 8: Typewriter. The video portion of this
game consists of the symbols of the keys pressed appearing in lines from left to right until the screen fills
up, whence they are all erased and a new sequence
begun. The audio portion involves a male voice offering
comments, requests and questions regarding the displayed symbols-e.g., 'Is this really eight?', 'where is
O?', 'see the four?', 'now find 1.'
Game 9: Spelling. The child types freely. If, by
chance or design, he spells any of the words which
occur in any of the games, the rest of the screen is
erased temporarily leaving the word he has spelled
centered in the screen. The appropriate sound is then
played.
We are continuing to experiment with new games
in an effort to build a library of the most successful
approaches to stimulating language.
THE RATIONALE FOR AUTOMATED THERAPY
Colby has already expressed our initial motivation
for using a computer in automated therapy (Colby
1968, p. 6424):
My group's interest in a computer-based
method for developing language in nonspeaking disturbed children derived from
several sources. First, we were interested in
the general problem of using computers in the
problems of psychiatry, as for example
through computer simulation of belief systems
(Colby 1967a2) (additional references: (Colby
and Smith 1969 5), (Colby et al. 19717» and
man-machine dialogues (Colby and Enea
1967b3). Second, the work of Suppes (Suppes
196613 ) and Moore (Moore 19639) indicates
that normal children learn reading, writing,
set theory, and arithmetic rapidly and enjoyably by means of computer-controlled
keyboards and displays. Third, the observation of many workers regarding the great
preoccupation of some disturbed children
with mechanical objects which they can
manipulate and control is impressive. Since
language acquisition in a normal child results
from interactions with people (relations which
disturbed children find difficult), perhaps
nonspeaking disturbed children would find a
machine such as a computer-controlled keyboard and display a more acceptable source
for linguistic interaction. Hence, an effort
was made to take advantage of a child's
fascination with machines by providing him
1104
Spring Joint Computer Conference, 1972
with a speaking and writing machine to play
with. Instead of a person controlling a child,
the child can control the machine, making it
talk and display symbols at his will.
Language is often described as used for
expression and as an instrument for social
influence. But during normal language acquisition, it is also used by children as a toy. The
method used in the present studies offered
each child a means of playing with language.
The hunch that children might enjoy this
activity was further supported by some preliminary experience with normal children who
delighted in the play and whose speech was
greatly excited by it during and after the
sessions. If a nonspeaking disturbed child
could become interested in this sort of play
and begin to enjoy developing language as
play rather than work, the hope was that
he would transfer his use of language from a
computer context to other social contexts. If
a disturbed child talks, a greater chance
exists for understanding what troubles him
and for helping him.
In addition to eliminating the fear of interpersonal
relationships possessed by many autistic children, the
computer has other intrinsic advantages over a human
therapist. Some children's linguistic difficulties stem
from an inability to abstract from complex and changing situations. They are baffled by vocal sounds coming
from people. Even the most well-intentioned human
therapist will inject variety into the learning situation,
thereby including one more variable with which the
child must deal. The response of the machine is an
absolute constant which forms a firm base for the child
to build upon. We frequently observe children striking
the same key over and over, and listening intently to
the sound. "Adults do not tolerate repetition well,
and when a child strikes the same key for twenty
minutes, it takes great control not to interfere. We
know from experience that if a sitter tries to stop
repetitions, the child will resist the interference and
refuse to play further. And he is right." (Colby and
Smith 1970 6)
Has a nonspeaking autistic child lost hope
of understanding and using language? Has he
given up so that nothing seems worth the
effort or risk? If so, we get him to try again,
to rekindle the hope by providing him a linguistic experience requiring little effort and
at which he cannot fail. For a small amount
of effort in pressing a key, he produces a large
effect; and there is no risk of failure because
something always happens, and he is never
corrected for being wrong about what happens. He is free to select those symbols he
wishes to manipulate. He is free to exercise
his curiosity, to explore, to try to make sense
out of the games. The experience is designed
to be fun, non-serious, not like school
(BLEAGGH!). The program is full of foolishness, nonsense and absurdities intended to
delight a child and to elicit glee and exuberance. Only personal observation of the children playing with the display can convince
adults of how pleasurable it can be. (Colby
and Smith 19706)
The strongest argument, though, for our method is
the favorable results we have achieved. Other treatment methods for nonspeaking autistic children report
an improvement rate of 3 percent-57 percent (Bettelheim
19671). To date (Nov. 1971) we have treated 21 cases
over the past four years. We have estimated 15 (71
percen t) to have improved in language development. We
classify a child as nonspeaking if he is mute or utters
only a word or two per month or year. He will also
generally utter other sounds that are unintelligible.
(However, all but one of our children have shown some
language comprehension.) We rate a child improved if he
moves from this state to volunteering appropriate intelligible words and phrases in social communication. The
speech must be non-echolalic and be initiated by the
child with the intention of communicating information.
Though the enunciation need not be perfect, it must
be sufficiently good so that the child can make practical
use of language in interpersonal relations. Sometimes
the children offer quite well-constructed sentences,
but more often they utter short, primitive sentences
or phrases.
AN ECONOMICAL THERAPY MACHINE (ETM)
Our implementation of an automated therapy laboratory on the PDP-I0 is clearly not feasible for most
clinics, schools or even hospitals around the country.
The computer requirements described above would
cost well over a million dollars if duplicated faithfully.
But this approach is not even desirable. Our goal was
to use whatever resources were available to experiment
with automated therapy techniques, bypassing as many
developmental problems as possible. N ow that we
have had several years of experience with this type
of treatment, we can begin to specify the characteristics of an economical therapy machine (ETM). By
Automated Therapy for Non-Speaking Autistic Children
this we mean a machine suitable for use in a large
number and variety of institutions dealing with language problems.
First and foremost is effectiveness; the machine
must be at least as effective as our system in treating
language disorders. Thus it must have many of our
system's features which we have found to be important: (1) a video screen and provisions for showing
still pictures and (at least crude) motion. (2) An audio
device capable of producing continuous sound in synchronization with the pictures. (3) A keyboard or similar device with which the child may select a picture/
sound, plus the appropriate logic for selecting his
choice from the storage. (4) Storage devices for pictures and sounds; they could use the same device (e.g.,
movie film with sound track) or separate ones. The
storage devices and their accessing logic must have at
most a one second delay Oi second is optimal) between the time the child requests a picture/sound and
the time it is played for him. The child's attention
span will not tolerate a longer delay.
Next in importance is low cost. The machine must
be economically feasible for a wide range of institutions; individual machines can and should cost no
more than $1000-$5000. It may be possible to group
several terminals together under one system, in which
case a small computer (e.g., a PDP-8) could be used
for the logic. A system with five terminals should cost
around $15,000. These are only rough estimates; they
might be improved upon.
Other essential characteristics are that the machine
be reliable, rugged (the keyboard, at least, must be
able to withstand rough handling by children), easily
and cheaply repairable (hopefully using stock, readilyavailable parts), portable, self-contained and requiring
no special environmental controls (such as air conditioning or humidity control).
This is admittedly a formidable list of requirements,
but one which we believe to be well within the capabilities of current technology. Some suggested implementations are presented below.
'1;here are other characteristics that are desirable
but not essential in a therapy machine: (1) Color in
the pictures. (2) Better motion than the 2-4 frame
motion we use; also more professional cartoon characters. (3) Longer sound than our current three-second
time limit. (4) Flashing lights and changing geometric
patterns, accompanied by music; the children are
fascinated by orderly motion. (5) More physical involvement while participating in the games. Many
children are hyperactive and squirm and fidgit when
required to sit in a chair to play the games. If they
could run around the room punching buttons or jumping on pedals to activate the machine, it would not
1105
only be more enjoyable to these children but would
probably increase their attention span as well. (6)
Finally, custom tailoring is important. It should be
easy to construct a new game specifically for an individual child. Frequently a child will show interest
in a particular sound or word or phrase; it should be
possible to construct a new game exploiting this sound
for the child's next therapy session.
All of these features are designed to hold the child's
interest and to stimulate his involvement with the
machine. Variety and novelty are the key characteristics. Any suggestions the machine designer would
have would, of course, be welcome.
POSSIBLE IMPLEMENTATIONS OF AN ETM
The following are some rough ideas we have had on
the form an economical therapy machine might take.
The video screen could be most simply realized as a
standard slide-projector screen. This would exclude
some versatility, such as permitting the child to draw
on a display screen with a light pen, but the cost
would be very low.
The pictures could be generated using a standard
film strip driven by a high-speed stepping motor. The
motor would have to be fast enough to advance over
several frames of the film to get to the desired frame
within the }i-I second time constraints. It should also
be able to stop, so that a single frame remains shown,
and to proceed at a slow rate suitable for showing
motion. Alternatively, a plate of fiche with the pictures
imprinted on it would be used together with a scanning
head. Both of these approaches require the design of
logic circuitry to control and count the stepping of the
motor or the positioning of the scanning head. This
circuitry constitutes the main non-standard aspect of
the ETM. It has to be designed from scratch; but
presumably, once the design costs have been met, it
could be constructed inexpensively using low-cost
integrated circuit chips.
The sound could perhaps most easily be recorded
on a sound track on the film strip. This requires that
the film strip be constantly moving, even for still
pictures. The advantage is that each game could be
packaged in a self-contained and easily-changeable
cassette. The problem of constructing new games
tailored to individual children reduces to the problem
of making new cassettes; there is much inexpensive
movie-with-sound recording equipment available today. Alternatively, a separate sound tape could be
used in conjunction with the picture producing device.
This would complicate the controlling circuitry, since
two tapes would have to be coordinated (one for the
1106
Spring Joint Computer Conference, 1972
pictures, one for the sound). A small computer might
become feasible with this approach, particularly if
several terminals were to be used. Another approach
is to have a rapidly rotating drum on which the sound,
and possibly the pictures, is recorded. Movable or
fixed read/write heads would be used to access the
sound; a high RPM would insure that latency is sufficiently small. This arrangement is particularly suited
to time-sharing several terminals using a small computer; one copy of the sounds could be used by all
the terminals connected to the drum.
We envision a very wide market for a machine designed along these lines. Many hospitals, clinics and
schools are becoming increasingly concerned with
correcting language disorders. Furthermore, normal
children thoroughly enjoy our system. If used in the
schools, it could provide a powerful stimulus for their
early interest in language, leading perhaps to increased
reading efficiency at an early age.
REFERENCES
1 B BETTELHEIM
The empty fortress
The Free Press New York 1967
2 K M COLBY
Computer simulation of change in personal belief systems
Behavioral Science 12 248-253 1967h
, 3 K M COLBY H ENEA
Heuristic methods for computer understanding· of natural
language in context-restricted on-line dialogues
Mathematical Biosciences 1 1-25 1967b
4 K M COLBY
Computer-aided language development in nonspeaking
children
Archives of General Psychiatry 19 pp 641-651 1968
5 K M COLBY D C SMITH
Dialogues between humans and an artificial belief system
Proceedings of the International Joint Conference on
Artificial Intelligence The MITRE Corporation Bedford
Massachusetts 1969
6 K M COLBY D C SMITH
Computer as catalyst in the treatment of nonspeaking autistic
children
Computer 4 47-531971
7 K M COLBY S WEBER F D HILF
A rtificial paranoia
Artificial Intelligence 2 1-75 1971
8 PDP-10 system reference manual
Digital Equipment Corporation Maynard Mass 1968
90 K MOORE
A utotelic responsive environments and exceptional children
Responsive Environments Foundation 1963
10 E M ORNITZ E R RITVO
Perceptual inconstancy in early infantile autism
Archives of General Psychiatry 18 pp 76-98 1968
11 B RIMLAND
Infantile autism
Appleton-Century-Crofts New York 1964
12 D C SMITH
MLISP
Stanford Artificial Intelligence Project Memo AIM-135
Stanford University 1970
13 P SUPPES
The uses of computers in education
Scientific American 215 pp 206-220 1966
14 J K WING
Early childhood autism
Pergamon Press New York 1966
An inferential processor for interacting with biomedical
data using restricted natural language*
by DALE W. ISNER
University oj Pittsburgh
Pittsburgh, Pennsylvania
the query language into programs or subroutine
calls to search the internal data structures.
INTRODUCTION
This paper describes the design and implementation of
a natural language system (hereafter referred to as
EN GOLISH) which was developed to support and
enrich the utilization of computer models of physiological systems. In addition to providing capabilities
for interrogating data bases using a subset of English,
ENGOLISH also provides capabilities for defining and
structuring data bases using this subset of English. In
particular, this facility has been used to encode relevant information from documents concerning these
models to enrich their utility. ENGOLISH is structured around GOL (Goal Oriented Language) which is
a programming language developed by H. Pople to
provide a means in which to express algorithms involving heuristic search and problem solving. GOL provides not only the basis for organizing and searching
ENGOLISH data structures but also provides the
basis for ENGOLISH's heuristic parsing algorithms.
For a description of GOL, see Pople. 13
The development of retrieval systems, using subsets
of English to interrogate structured files of data, has
received considerable attention. Simmons 23 summarizes
much of this work. In general those retrieval systems
referred to as "fact-retrieval systems" or "questionanswering systems" consist of the following basic
components:
In addition to the above basic components, the
following are regarded as features which are desirable
in such systems:
(1) A general internal representation (ability to add
new and perhaps differently structured data to
the system without major modifications).
(2) Ability to build and expand the data base using
the query language.
(3) Ability to alter or extend the query language.
(4) Inferential capability, including the ability to
handle quantifiers.
(5) Capability for dealing with modalities and state
spaces.
In regards to such systems, Schwarcz et aP7 have
identified the need for solving the following three major
interrelated problems.
1. The development of a formalized data representation language in which the aspects of
meaning that are relevant to the system's uses
are explicitly and unambiguously represented;
2. The development of algorithms for translating
inputs in the English subset into appropriate
storage and retrieval commands for operation on
the data base, making appropriate use of contextual information to resolve both syntactic
and· semantic ambiguity, and for translating
structures retrieved from the data base into
well-formed English answers;
3. The development of algorithmic and/or heuristic
methods for determining what subset of the
data base is relevant to filling a given retrieval
request and, using the logical relationships
(1) A query language (in this context a subset of
natural language ) .
(2) An internal language or data structure in which
facts may be represented or encoded.
(3) A translator for translating questions posed in
* The
work incorporated in this report was carried out under
NIH Contract 70-4121 and also supported in part by NIH grant
PM 00049-02.
1107
1108
Spring Joint Computer Conference, 1972
represented in the data base, for deducing answers from this subset to meet the request.
SEMANTIC ORGANIZATION AND EXAMPLES
The primary consideration in the development of a
question-answering system is the definition of the data
DELTA
"0810
00820
00038
"0040
00058
00"61
00870
"0880
00090
e0100
00110
00120
00130
08.<48
00150
0016.
00170
00180
"0190
00200
00210
00221
00238
08240
88258
00260
00278
00288
"0298
80300
00310
00320
00330
803'"035'
08360
0837.
00388
08410
00428
"0430
80448
•
01-SEP-71
structures which are to be used for its semantic basis.
Currently most such query systems use one of two
approaches. The first (hereafter referred to as a "logicbased system") uses a logic as its basis, usually a first
order theory, and employs a theorem prover as its
means for searching and inferring facts from the data
base. (For examples see References 6 and 16.) The
20.16
a
=
= 0
=
a
a ( )
a
= (DELTA cVARIABLES> eDELTA-ENTRIES»
eVARIABLES>
=(
(eFREE-VARIABLES»
eSTRING-VARIABLES»
= 0
•
•
-
eSTRING-VARIABLES> a 1
•
=
~
- eDELTA-ENTRY>
•
= ( eN-TUPLE> )
eTRUTH-VALUE>
=T
.,.
a ( cATOM-LIST> )
• cLISP-ATOM>
=
= eGOL-EXPRESSION>
Figure 1
An Inferential Processor
second approach utilizes networks for representing the
primary relations concerning its data base. Higher level
relations as :well as searching and inferential capabilities
are normally encoded as special purpose programs. For
future reference, we shall refer to these as "programbased systems." (For examples see References 7, 14, 17,
21, 24 or 25.) In general, logic-based systems offer
more powerful inferential capabilities and permit input
data using variables and containing quantifiers. N ormally the addition of such deduction rules in a programbased system entails modifying existing programs or
adding new routines to the system. However, logicbased systems currently lack capabilities for handling
higher order logics (thus making it difficult to handle
many features such as a "How many" type question),
and in general their inability to deal with relevance
makes them impractical for other than very small
data bases consisting of a limited number of deduction
rules. On the other hand, program based systems, by
their nature, allow some degree of relevance to be incorporated into the data structures as well as the routines for searching these structures, at the expense of
some degree of generality, and hence can be made to
operate more efficiently on larger data bases. Furthermore it is difficult in either of these approaches to
incorporate linguistic data into their data structures to
provide a natural language capability with the system.
As a result a natural language capability is usually
provided by a separate component in the system which
makes it difficult to allow the development and expansion of the subset of natural language in conjunction
with the data base.
We feel that use of a heuristic problem solving language such as GOL as a basis for the semantic organization will permit the incorporation of the advantages
of each of the above systems. The semantic representation used in ENGOLISH is a data structure (hereafter
referred to as the DELTA notation) which is an extension of the GOL extensional and intensional data
structures. The extensional data structures in GOL
enable the definition of n-ary relations by an explicit
encoding of the appropriate n-tuples. Alternatively,
patterns containing free variables may be used to describe classes of n-tuples in compact form. The intensional data structures are ~-expressions which provide
for the definition of one relation in terms of others;
such definitions may be recursive. (For further details
see Reference 13.) The DELTA notation combines
these two into a single data structure also allowing provisions for representing negative data. In addition, it
provides the capability for having string variables, as
well as free variables; this makes the DELTA notation
ideal for expressing grammars as well. The syntax for
the DELTA notation is given in Figure 1 below.
1109
As an example, in GOL one might code a maze solving
routine by defining a GOL intensional data structure
such as SOLVE-MAZE given below.
SOLVE-MAZE
(SOOOO (LAMBDA (X Y)
(OR (CONNECTED X Y)
(EXISTS (Z) (AND
(CONNECTED X Z)
(SOLVE-MAZE Z Y))))))
Then a maze such as the trivial example below
B
D
END
may be encoded with a GOL extensional data structure
CONNECTED such as follows.
CONNECTED
(SOOOO (EXT
(NIL)
(START A)
(A B)
(A
C)
(B D)
(D END)))
Alternatively, one could combine the two and use the
single DELTA definition MAZE given below.
MAZE
(SOOOO (DELTA
((X Y))
(T (START A) T)
(T
(A B
T)
(T (A C)
(T
(B D)
T)
T)
(T (D END) T)
(T (X Y) (EXISTS (Z)
(AND (MAZE X Z)
(MAZE Z Y))))))
Here X and Y are defined as free variables and the
first five "delta entries" encode the extension of MAZE
(equivalent to CONNECTED defined above) and the
last delta entry its intension (equivalent to SOLVE-
1110
Spring Joint Computer Conference, 1972
MAZE given above). The first delta entry
(T (START A) T)
encodes the fact that MAZE is true of the 2-tuple
(START A) under all conditions, and the last delta
entry
would result in a value of T. Similarly the GOL
expression
(LAMBDA (A) (UNCLE A (QUOTE BILL»)
could represent the question
(T
(X Y)
(EXISTS
(Z)
(AND (MAZE X Z)
(MAZE Z Y»»
encodes the fact that MAZE is true of any 2-tuple
under the condition that there is a path connecting
them.
Thus with respect to defining the "meaning" of natural
language concepts, DELTA allows one to have an extensional as well as an intensional part as proposed by
Carnap 3 in his method of extension and intension.
Thus
UNCLE
(SOOOO (DELTA ((X Y»
(T
(HARRY BILL) T)
(F
(JOHN SALLY) T)
(T
(X Y) (EXISTS (Z)
(AND (PARENT Z Y)
(OR (BROTHER X Z)
(BROTHER-IN-LAW X Z»»)
(T
(X)
(EXISTS (Z)
(UNCLE X Z»»)
would encode
(1) Harry is an uncle of Bill.
(2) John is not an uncle of Sally.
(3) X is an uncle of Y if X is a brother or brotherin-law of a parent of Y.
(4) X is an uncle if X is an uncle of someone.
with (1) and (2) being extensional and (3) and (4)
expressing the intension of the binary relation "uncle"
and unary relation "uncle" respectively.
GOL data structures such as above may subsequently be used to evaluate GOL-expressions which
contain them. This evaluation may consist of testing
the truth value for atomic arguments or generating
values for arguments consisting of unbound variables.
Thus
(LAMBDA ( ) (UNCLE (QUOTE HARRY»)
could represent the question
"Is Harry an uncle?"
and if applied to the above data structure UNCLE
"Who is an uncle of BILL?"
and if applied, to the data structure UNCLE would
generate instances for the lambda-variable A.
To briefly illustrate the representation of a grammar,
consider the following trivial example which defines the
positive binary integers and which is equivalent to the
context free grammar given in BNF below.
(positive-binary-integer> : : =
o 11 I (positive-binary-integer> 0 I
I (positive-binary-integer> 1
POSITIVE-BINARY-INTEGER
(SOOOO (DELTA(
(T
(T
()
$X)
(0)
(1)
T)
T)
(T
($X 0)
(POSITIVE-BINARY-INTEGER (QUOTE ($X»
(T
($X 1)
(POSITIVE-BINARY-INTEGER (QUOTE ($X»
(T
($X)
T)
$X is defined as a string variable and the last entry
above may be thought of as a completeness statement
i.e., no other strings are positive binary integers.
DISCUSSION AND EXAMPLES
Although ENGOLISH is applicable to defining and
interrogating various types of data bases, its development was guided by the desirability of building an
interrogation system around physiological models, in
particular a neural model which is under development
as a means of representing facts concerning pharmacological data.
The first problem in this development was the choosing of some subset of English which was felt to be adequate for expressing questions concerning the information represented in such models. Because of the structural similarities between these models and pictures of
simple objects, we began with a subset of English
similar to that given in Kochen9 and pioneered by the
work of Kirsch, 7 concerning grammars for talking about
pictures. Since any grammar for a collection of ques-
An Inferential Processor
GAMMA
RAPHE'
1111
Since ENGOLISH requires no prior knowledge
concerning the given data base, i.e., the basic vocabulary of objects and names of relations, the model builder
should enrich the vocabulary of the system for relations
requiring more than one English word by using the
SUBSTITUTE statement as illustrated in lines 00001
and 00003 above or by using a hyphen in the first appearance of the phrase as with "connected-inhibitory"
in line 00005.
Using the small data base created by Figure 3, Figure
4 below illustrates types of questions which could be
asked of it using ENGOLISH. (Lines preceded by *
illustrate questions asked and the line (s) following the
response from ENGOLISH.)
Note in the preceding that following "whatquestions" the command "ANOTHER" may be used
to elicit further instances for the "what-question" from
ENGOLISH. Similarly, "REST" may be used for all
remaining answers.
NUCLEUS
BULBOSPINAL NEURON
Figure 2
tions also entails as a subset a grammar for statements,
it was decided that the defining of relations using such
statements would also be a useful feature, thus allowing
the construction of the data base itself using natural
language. Since the language into which we translate
such questions, i.e., GOL expressions is the same language in which the data base is structured, this was
possible.
Illustrative example
As an illustrative example assume we wish to define
and interrogate the prototype of a simple neural model
given in Figure 2. The statements given in Figure 3
were used to define this data base in hNGOLISH.
Schema of Neural Structures and Their Transmitter
Mechanisms for Figure 2.
VOP:
Nucleus Ventralis Oralis Posterior
VOA:
Nucleus Ventralis Oralis Anterior
ALPHA MNs and GAMMA MNs represent their
respective motorneurons
AREA 4 and AREA 6 are the cytoarchitectural
divisions of Motor Cortex
CHOL: cholinergic transmitter mechanism
DOP:
dopaminergic transmitter mechanism
5-HT : serotonergic transmitter mechanism
Encoding of literature
In addition to the information encoded within models ,
another important source of information is from literature which is relevant to such models. These could be
used not only to cite justification for the structure of a
given model by the model builder but also to contain
published laboratory data which may corroborate or
contradict results obtained when using such models.
To accommodate this type of data we decided that
it should be encoded within the same data structures so
that the same processors which search for answers to
questions within a model, could also be used to answer
such questions from the literature. Furthermore, the
user should have the option of deciding to which source
he wishes his interrogations directed-to a model, the
literature or both.
As ·a result, we currently envision the top level
structure of this data base as a hierarchic state space.
This is feasible because of GOL's existing capability
for dealing with state-spaces in heuristic problem
solving. The user then focuses attention on some node
of this state spage by the statement (LETS DISCUSS
-) or by including the phrase ( ... ACCORDING
TO X ... ) within a statement. Having done so, he
then restricts the context to that state and any states
accessible from it.
The indexing of data by states also provides the user
a means of indexing his data base so that questions
may be directed to specific parts of the data base, thus
saving substantial searching time.
1112
Spring Joint Computer Conference, 1972
88881
SUBSTITUTE NEURAL-STRUCTURE FOR NEURAL STRUCTUR€.
.......
88883
SUBSTITUTE NEURAL-STRUCTURES FOR NEURAL STRUCTURES,,'
• 8 •• 5
SUBSTANTIA-NIGRA AND RAPHE-NUCLEUS ARE CONNECTED-INHIBITORY
TO PALLIDUM.
••8.e
....,
8 ••• ,
8••• 8
188.9
e".1
18111
88.12
PALLIDUM AND
NEOSTRI~TUM
ARE CONNECTED-EXCITATORY TO VQA.
DENTATE-NUCLEUS IS CONNECTED EXCITATORY TO VOP.
VOP IS CONNECTED EXCITATORY TO AREA-....
8 ••• 3
.1814
"8815
.8.16
8"'11
••• 18
.8819
8882a
••• 21
81122
18823
08"24
""825
.""26
88821
8e828
8.829
8813.
"'31
8 •• 32
••133
88834
88835
81836
8.131
••• 38
8.139
VOA IS CONNECTED EXCITATORY TO AREA-6.
AREA-6 IS CONNECTED EXCITATORY TO ALPHA-MOTORNEURONS.
AREA-'" IS CONNECTED EXCITATORY TO GAMMA-MOTORNEURONS •
SUBSTANTIA-NIGRA IS CONNECTED INHIBITORY TO
BULBOSPINAL-NEURONS AND NEOSTRIATUM.
X IS MONOSYNAPTICALLY-CONNECTED TO Y MEANS X IS CONNECTED
EXCITATORY TO Y OR X IS CONNECTED INHIBITORY TO Y.
IS A NEURAL STRUCTURE IF X IS MONOSYNAPTICALLY CONNECTED
TO SOMETHING OR SOMETHING IS MONOSYNAPTICALLY CONNECTED
TO x.
X
X IS ON-A-PATHWAY TO Y MEANS EITHER X IS MONOSYNAPTICALLY
CONNECTED TO Y OR X IS ON A PATHWAY TO SOME NEURAL STRUCTURE
WHICH IS MONOSYNAPTICALLY CONNECT·ED TO Y.
ACETYLCHOLINE. SEROTONIN.
AND DOPAMINE ARE TRANSMITTERS.
,
LIBERATE IS A VERB.
SUBSTANTIA-NIGRA LIBERATES DOPAMINE.
""48
RAPHE-NUCLEUS LIBERATES SEROTONIN.
" . . 42
NEOSTRIATUM. DENTATE-NUCLEUS. PALLIDUM.
LIBERATE ACETYLCHOLINE •
08841
• 0 .... 3
".4~
8.145
X
vop"
AND VelA
IS SEROTONERGIC MEANS X LIBERATES SEROTONIN.
8e8 ... ,
".047
X IS CHOLINERGIC MEANS X LIBERATES ACETYLCHOLINE.
08848
e.'49
81150
00051
80852
•
X IS DOPAMINERGIC MEANS X LIBERATES DOPAMINE.
X
IS BLOCKED-BY-ATROPINE MEANS SOME NEURAL STRUCTURE WHICH
IS CHOLINERGIC")S ON A PATHWAY TO X.
Figure 3
An Inferential Processor
*LIST ALL NEURAL STRUCTURES.
AREA-6 VOA VOP DENTATE-NUCLEUS PALLIDUM SUBSTANTIA-NIGRA
RAPHE-NUCLEUS GAMMA-MOTORNEURON ALPHA-MOTORNEURON NEOSTRIATUM
8ULBOSPlNAL-NEURON.
AREA-~
*IS AREA-~ CONNECTED EXCITATORY TO GAMMA MOTORNEURONS?
YES •
• WHAT IS CONNECTED INHIBITORY TO PALLIDUM?
RAPHE-NUCLEUS •
• ANOTHER.
SUBSTANTIA-NIGRA •
• ANOTHER.
THAT'S ALL •
• WHAT IS ON A PATHWAY TO AREA-6?
VOA •
• ANOTHER.
PALLIDUM.
-ANOTHER.
RAPHE-NUCLEUS •
• ANOTHER.
SUBSTANTIA-NIGRA •
• IS VOA CHOLINERGIC?
YES.
*IS IT TRUE THAT AREA-6 IS CHOLINERGIC?
NOT TO MY KNOWLEDGE •
• WHAT LIBERATES ACETYLCHOLINE?
DENTATE-NUCLEUS •
• ANOTHER.
NEOSTRIATUM •
• ANOTHER.
PALLIDUM •
• "·HAT IS THE MEANING OF BLOCKED BY ATROPINE?
X IS BLOCKED-BY-ATROPINE MEANS SOME NEURAL-STRUCTURE WHICH IS
CHOLINERGIC IS ON-A-PATHWAY-TO x•
• ARE THE ALPHA MOTORN£URONS BLOCKED BY ATROPINE?
YES.
Figure 4
1113
1114
Spring Joint Computer Conference, 1972
*IS AREA-6 BLOCKED BY ATROPINE?
YES.
-HOW MANY NEURAL STRUCTURES ARE BLOCKED BY ATROPINE?
6•
• LIST ALL NEURAL STRUCTURES WHICH ARE BLOCKED BY ATROPINE.
AREA-6 VOA VOP GAMMA·MOTORNEURON ALPHA-MOTORNEURON •
AR[A-~
• IS IT TRUE THAT SOME NEURAL STRUCTURE WHICH IS DOPAMINERGIC IS
CONNECTED INHIBITORY TO SOME NEURAL STRUCTURE WHICH IS CHOLINERGIC?
YES.
Figure 4 (Cont'd)
A complete example
Within the framework of the previous section one
may include facts from the literature into such a data
base by expressing them as EN GOLISH statements as
represented by the example in Figure 5.
In a similar manner, the model builder may encode
comments about his model. Such data is useful not only
for future reference by the model builder but also by
future users of such models to explain and justify as'
pects of them.
Having encoded such data for a neural model and
several documents relevant to it, one may then interrogate this data base with queries such as illustrated in
Figure 6.
ENGOLISH IMPLEMENTATION
The current version of ENGOLISH is implemented
in GOL enriched LISP. The translator consists of a
top-to-bottom parser utilizing heuristics on syntactical
patterns as well as the data base itself to aid in the
recognition of sentences, questions, names, etc. These
patterns are defined by GOL DELTA data structures
and the parser and heuristics by GOL intensional data
structures and LISP subroutines. As a result it resembles the conceptual parser described by Shank19 ,20
as opposed to totally grammar based systems. The
parsing algorithm places stress on "function words"
such as articles, prepositions, quantifiers etc., and as a
consequence is capable of parsing sentences containing
nouns, verbs, and adjectives which were not previously
defined within the data base and for which no syntactic
information is available. Such words which are defined
in the data base are used to aid in the parsing and
disambiguating of sentences.
Having parsed an English statement or query, the
phrase marker generated is used to generate the equiva-
lent GOL expression. This expression is then evaluated,
and if a statement, it will result in the approprjate data
structure being defined or modified, and if a question,
in the appropriate value being generated or retrieved,
to provide an answer to the question.
DISCUSSION AND FUTURE DEVELOPMENTS
The preceding sections described the current status of
ENGOLISH. Even though it has convinced us of the
feasibility of translating from a subset of English to
GOL and of its desirability as a basis for a query system, there still remains much to be done.
Currently, steps are being taken to expand the conversational capabilities of ENGOLISH. In addition to
expanding the syntax, there is need for more interaction
between man and machine. In addition to utilizing its
own data base to answer questions, ENGOLISH's
utility would be increased by adding capabilities for it
to generate sub-questions to the user, i.e., to also make
use of the users knowledge in answering his questions.
For example, consider a true-false question such as
IS
SUBSTANTIA-NIGRA
BLOCKED
BY
ATROPINE? This question would currently result in a
"YES," "NO," or "NOT TO MY KNOWLEDGE"
response from ENGOLISH, depending on the success
of searching out pathways to Substantia-Nigra for a
neural structure which is cholinergic (see Figure 3). If
none were found, but neural structures were tested for
which no transmitter was known, it would be desirable
to have the system query the user with
IS
CHOLINERGIC?
or
LIBERATE?
WHAT DOES
as opposed to merely responding "NOT TO MY
KNOWLEDGE."
An Inferential Processor
NEURAL.EX.
8""'1
88882
31-AUG-ll
15154
THE CONTEXT IS NEURAL.
"""03
LETS DISCUSS NEURAL-DOCUMENTS.
10185
10086
18".7
'.808
""009
8.818
MOUNTCASTLE-BARD IS A SUB-WORLD OF NEURAL-DOCUMENTS.
"0'1~
1115
"BARD. PH"
IS THE AUTHOR 0' MOUNTCASTLE-BARD.
THE CEREBRAL CORTEX
IS THE TITLE OF MOUNTCASTLE-BARD.
"MOTOR FUNCTIONS OF
AND
BASAL-GANGLIA"
80811
80112
• 8813
"MEDICAL PHYSIOLOGY VOL I J EDITED BY MOUNTCASTLE
PP 119. I 88S" IS THE SOURCE OF MOUNTCASTLE-BARD •
08814
01815
LETS DISCUSS MOUNTCASTLE-BARD.
80816
".817
•• 818
"".19
'''.2''
NUCLEUS-VENTRALIS-CAUDALIS. NUCLEUS-VENTRALIS-INTERMEDIUS.
NUCLEUS-VENTRALJS-ORALIS-POSTERIOR. AND
NUCLEUS-VENTRALIS-ORALIS-ANTERIOR ARE PART OF THE
VENTR08ASAL-THALAMIC-NUCLEI.
8.121
81822
STIMULATION OF SKIN EXCITES NUCLEUS-VENTRALIS-CAUDALIS •
••• 23
••
" ••es
'2~
8e826
STIMULATION OF JOINTS EXCITES NUCL£US-VENTRALIS-CAUDALIS
AND NUCLEUS-VENTRALIS-INTERMEDIUS.
••821
8.,.28
80029
"883.
STIMULATION or MUSCLE-AFFERENTS EXCITES
NUCLEUS-VENTRALIS-ORALIS-POSTERIOR.
88832
8"833
•• '34
••"35
88836
8.831
••• 38
.8039
STIMULATION OF NUCLEUS-VENTRALIS-ORALIS-ANTERIOR INCREASES
"".31
STIMULATION
or
NUCLEUS-VENTRALIS-CAUDALlS CAUSES PARESTHESIA.
MUSCL.E TONE •
STIMULATION OF NUCL£US-VENTRALIS-ORALIS-ANTERIOR SLOWS
VOLUNTARY MOVEMENT.
STIMULATION OF NUCLEUS-VENTRALIS-ORAL~S-POSTERIOR ACCELERATES
VOLUNTARY MOVEMENT.
88.~'
.,841
""~2
" •• 43
8"8~~
"''''''-5
•
KILLING NUCLEUS-VEHTRALIS-ORALIS-ANTERIOR ALLEVIATES
PARKINSON-DYSTONIA.
KILLING NUCLEUS-VENTRALIS-QftALIS-POSTERIOR ALLEVIATES
PARKINSON-TREMOR •
Figure 5
1116
Spring Joint Computer Conference, 1972
*LIST ALL NEURAL STRUCTURES.
ACCORDING TO BRODAL WHICH IS A SUB-WORLD OF NEURAL-DOCUMENT
LARGE-NEURON IN DEITERS-NUCLEUS SMALL-NEURON IN DEITERS-NUCLEUS
ALPHA-MOTORNEURON GAMMAt-MOTORNEURON
ACCORDING TO HASSLER WHICH IS A SUB-WORLD OF NEURAL-DOCUMENT
NUCLEUS-VENTRALIS-LATERALIS DENTATE-NUCLEUS
NUCLEUS-VENTRALIS-ANTERIOR PAL..LIDUM MOTOR-CORTEX-" MOTOR-CORTEX-6
ACCORDING TO GR ILLNER-ET-AL-1969 WHICH IS A SUB-WORLD OF
NEURAL-DOCUMENT PONTINE-RETICULAR-FORMATION GROUP-ONE-AFFERENT
ALPHA-MOTORNEURONGAMMA-MOTORNEURON
ACCORDING TO POMPEIANO-ET-AL-t967 WHICH IS A SUB-WORLD OF
NEURAL-DOCUMENT EXTENSOR-GAMMA! -MOTORNEURON NUCLEAR-BAG
DEITERS-NUCLEUS NUCLEAR-BAG-AFFERENT
ACCORDING TO NEURAL-MODEL EXTENSOR-INTERN FLEXOR-INTERN
GAMMA2-SPINAL-JNTERN INHIBI'LEX-INTERN VESTIBULO-SPINAL-INTERN
DEITERS-NUCLEUS RAS·INTERN SUBSTANTIA-NIGRA RAS RAS-PONTINE
RAS-MEDULLARY CORTICAL-INTERN NUCLEUS-RUBRA RUBRA-INTERN
MOTOR-CORTEX-4 MOTOR-CORTEX-6 NUCLEUS-VENTRALIS-ANTERIOR
BASAL-GANGLIA INTRALAMINAR-NUCLEUS NUCLEUS-VENTRALIS-LATERALIS
EXTENSOR-DEEP-CEREBELLAR-NUCLEUS DEEP-CEREBELLAR-NUCLEUS
EXTENSOR-CEREBELLAR-INTERN CEREBELLAR-INTERN EXTENSOR-INTERN-.
INTERN-l CORTIRU8E-INTERN BASAL-GANGLIA-INTERN
E)(TENSOR-CEREBELLAR-CORTEX CEREBELLAR-CORTEX
EXT£NSOR-ALPHA-MOTORNEUROH FLEXOR-ALPHA-MOTORNEURON
EXTENSOR-GAMMA2-MOTORN£URON GAMMA2-MOTORNEURON AFFERENT2-INTERN
£XTENSOR-GAMMA1-MOTORNEURON GAMMAI-MOTORNEURON CORTICAL-'INTERNEURON
ACCORDING TO MODEL-BUILDER WHICH IS A SUB-WORLD OF NEURAL-MODEL
PONTINE-RETICULAR-FORMATION DEITERS-NUCLEUS GROUP-ONE-AFFERENT
EXTENSOR-ALPMA-MOTORNEURON EXTENSOR-GAMMA1-MOTORNEURON
GAMMA1-MOTORNEURON.
*WHAT IS THE ANTAGONIST OF THE FLEXOR-MUSCLE?
EXTENSOR-MUSCLE.
*WHAT IS PART OF DEITERS-NUCLEUS?
SMALL-NEURON •
• ANOTHER.
LARGE-NEURON.
*ACCORDING TO THE LITERATURE WHAT REDUCES FLEXOR-MUSCLE-TONE?
ACCORDING TO LUND-POMPEIANO-196S STIMULATE DEITERS-NUCLEUS.
Figure 6
An Inferential Processor
*LETS DISCUSS NEURAL-MODEL.
OK.
*IS DEITERS-NUCLEUS CONNECTED TO SOME MOTQRNEURON?
*WHAT IS DEITERS-NUCLEUS CONNECTED EXCITATORY TO?
VESTIBULO-SPINAL-INTERN.
*ANOTH&:R.
GAMMA2-SPI~L-INTERN.
*WHAT JUSTIFIES DEITERS-NUCLEUS BEING CONNECTED EXCITATORY TO
EXTENSOR-GAMMA1-MOTORNEURON?
BECAUSE ACCORDING TO MODEL-BUILDER POMPEIANO-ET-AL-1967
DEMONSTRATED THIS CONNECT'ION.
*LETS DISCUSS POMPEIANO-ET-AL-1967.
*IS DEITERS-NUCLEUS CONNECTED EXCITATORY TO
EXTENSOR-GAMMAI-MOTORNEURON?
YES •
• WHAT DOES
STIMULATI0N
OF
DEITERS-NUCLEUS DO.
AUGMENT AFFERENT-DISCHARGE FROM MUSCLE-SPINDLE •
• WHAT IS CONNECTED-EXCITATORY TO NUCLEAR-BAG-AFFERENTS?
NUCLEAR-BAG.
*WHAT IS CONNECTED-EXCITATORY TO NUCLEAR-BAGS?
EXTENSOR-GAHMAI-MOTORNEURON.
Figure 6 (Cont'd)
1117
1118
Spring Joint Computer Conference, 1972
.WHAT JUSTIFIES DEITERS-NUCLEUS MONOSYNAPTICALLY-EXCITING THE
EXTENSOR-GAMMA1-MOTORN£URONS?
BECAUSE POMPEIANO SAYS THAT THIS EFFECT IS RESISTANT TO BLOCK BY
ANESTHETICS.
*LETS DISCUSS THE NEURAL-MODEL.
OK •
• WHAT JUSTIFIES GROlP-ONE AFFERENTS BEING CONNECTED INHIBITORY TO
GAMMA1-MOTORNEURONS?
BECAUSE ACCORDING TO MODEL-BUILDER GRILLNER-ET-AL-1969 ELLICITED
IPSPS IN GAMMA-MOTORNEURONS BY STIMULATION OF MUSCLE NERVES •
• WHAT IS CONNECTED EXCITATORY TO BASAL-GANGLIA?
NUCLEUS-VENTRALIS-LATERALIS.
*ANOTHER.
THAT'S ALL •
• WHAT IS BASAL-GANGLIA CONNECTED EXCITATORY TO?
GAMMA2-SPINAL-INTERN •
• ANOTHER.
NUCLEUS-VENTRALIS-ANTERIOR.
*ANOTHER.
THAT'S ALL.
*WHAT IS ON A PATHWAY TO BASAL-GANGLIA?
NUCLEUS-VENTRALIS-LATERALIS.
*ANOTHER.
SUBSTANTIA-NIGRA.
Figure 6 (Cont'd)
An Inferential Processor
*ANOTHER.
BASAL-GANGLIA-INTERN.
*ANOTHER.
INTRALAMINAR-NUCLEUS.
*IS IT TRUE THAT RAS IS ON A PATHWAY TO FLEXOR-ALPHA-MOTORNEURON?
YES.
*ACCORDING TO NEURAL-DOCUMENTS WHAT IS PART
V£NTROBASAL-THALAMIC-NUCLEI?
or THE
ACCORDING TO MOUNTCASTLE-BARD' NUCLEUS-VENTRALIS-INTERMEDIUS.
*ANOTHER.
NUCLEUS-VENTRALIS-CAUDALIS.
-LETS DISCUSS THE LITERATURE.
OK •
• WHO IS THE AUTHOR OF MOUNTCASTLE-BARD?
BARD. PH.
-WHAT IS THE TITLE OF MOUNTCASTLE-BARD?
MOTOR FUNCTIONS OF THE CEREBRAL CORTEX AND BASAL-GANGLIA •
• WHAT IS THE SOURCE OF MOUNTCASTLE-BARD?
MEDICAL PHYSIOLOGY VOL II EDITED BY MOUNTCASTLE PP 1198 1808 •
• WHAT ALLEVIATES PARKINSON?
.ACCORDING TO HASSLER KILL PALLIDUM.
*WHAT SUPRESSES DECEREBRATION RIGIDITY?
Figure 6 (Cont'd)
1119
1120
Spring Joint Computer Conference, 1972
ACCORDING TO HENATSCH-INGVAR-1956 ADMINISTRATE CHLORPROMAZINE.
*WHAT DOES ADMINISTRATION OF CHLORPROMAZINE DO?
ACCORDING TO
DASGUPTA-WERNER-1953-195~
BLOCK SPINAL-REFLEX.
*ANOTHER.
ABOLISH DECEREBRATION-RIGIDITY.
*WHAT AFFECTS DECEREBRATION RIGIDITY?
ACCORDING TO DASGUPTA-WERNER-1953-1954 ADMINISTRATE CHLORPROMAZINE
ABOLISH DECEREBRATION-RIGIDITY.
*IS IT TRUE THAT ADMINISTRATION OF CHLORPROMAZINE BLOCKS
SPINAL-REFLEXES?
NOT TO MY KNOWLEDGE.
*WHAT FACILITATES TREMOR?
ACCORDING TO HASSLER STIMULATE NUCLEUS-VENTRALIS-ANTERIOR.
*WHAT DOES STIMULATION OF SKIN DO?
ACCORDING TO MOUNTCASTLE-BARD EXCITE NUCLEUS-VENTRALIS-CAUDALIS.
*WHAT AFFECTS MUSCLE TONE?
ACCORDING TO HASSLER KILL INTRALAMINAR-NUCLEUS DECREASES
MUSCLE-TONE.
*ANOTHER.
STIMULATE NUCLEUS-VENTRALIS-ANTERIOR INCREASES MUSCLE-TONE.
*ANOTHER.
ACCORDING TO MOUNTCASTLE-BARD STIMULATE
NUCLEUS-VENTRALIS-ORALIS-ANTERIOR INCREASES MUSCLE-TONE.
*ANOTHER.
THAT'S ALL.
Figure 6 (Cont'd)
An Inferential Processor
.WHAT DOES ADMINISTRATION OF RESERPINE DO?
ACCORDING TO STE6-1964 MIMIC ANEMIC-DECEREBRATION.
*ANOTHER.
ABOLISH ACTIVITY GAMMA1-MOTORNEURON.
*ANOTHER.
AUGMENT STRETCH-REFLEX.
*ANOTHER.
THAT'S ALL.
*WHAT DOES ANEMIC DECEREBRATION DO?
ACCORDING TO STEG-1964 SELECTIVE-ACTIVATE ALPHA-MOTORNEURON •
• WHAT REDUCES FLEXOR-MUSCLE-TONE?
ACCORDING TO LUND-POMPEIANO-196S STIMULATE DEITERS-NUCLEUS •
• LETS DISCUSS THE NEURAL-MODEL.
OK.
*15 SUBSTANTIA-NIGRA CHOLINERGIC?
NOT TO MY KNOWLEDGE •
• WHAT IS CHOLINERGIC?
NUCLEUS~VENTRALIS-ANTERIOR
•
• ANOTHER.
NUCLEUS-VENTRALIS-LATERALIS •
• WHAT IS THE MEANING OF BLOCKEI BY ATROPINE?
X IS BLOCKED-BY-ATROPINE MEANS SOME NEURAL STRUCTURE WHICH IS
CHOLINERGIC IS' ON-A-PATHWAY-TO x•
• WHAT IS BLOCKED BY ATROPINE?
MOTOR-CORTEX-6.
Figure 6 (Cont'd)
1121
1122
Spring Joint Computer Conference, 1972
*THE CONTEXT IS NEURAL.
OK.
*LETS DISCUSS NEURAL.
OK.
*WHAT DOES STIMULATION OF SUBSTANTIA-NIGRA DO?
ACCORDING TO BARBEAU-196S WHICH IS A SUB-WORLD OF NEURAL-DOCUMENT
RELEASE DOPAMINE IN PUTAMEN.
*15 SUBSTANTIA-NIGRA DOPAMINERGIC?
ACCORDING TO SOURKES-POJRIE-1965 WHICH IS A SUB-WORLD OF
NEURAL-DOCUMENT YES.
-WHAT DOES LESION OF FOREL-HI-AREA DO?
ACCORDING TO MODEL-BUILDER PRODUCE TREMOR.
-WHY DOES LESION OF rOREL-HI-AREA PRODUCE TREMOR?
BECAUSE ACCORDING TO MODEL-BUILDER THIS APPEARS TO BE DUE TO
INTERRUPTION OF PATHWAYS ORIGINATING FROM SUBSTANTIA-NIGRA.
*15 SUBSTANTIA-NIGRA A TREMOR SUPRESSING AGENT?
ACCORDING TO MODEL-BUILDER YES •
• WHAT JUSTlf'IES SUBSTANTIA-NIGRA BEING
A
TREMOR SUPRESSING AGENT?
BECAUSE ACCORDING TO MODEL-BUILDER CARP£NTER-ET-AL-1950 PROVIDES
EVIDENC£ANDMONNIER-1971 EXPRESS.ES THESE VIEWS •
• WHERE IS SUBSTANT lA-NIGRA 1
ACCORDING TOCARRERAS-METTLER-1955 WHICH IS A SUB-WORLD OF
NEURAL-DOCUMENT MEDIOVENTRAL-AREA IN BRAIN-STEM •
• WHAT DOES
LESION
OF SUBSTANTIA-NIGRA 001
ACCORDING TO CARRERAS-MEtTLER-195S WHICH IS A SUB-WORLD OF
NEURAL-DOCUMENT DEGENERATE ASCENDING-NIGRO-STRIATE-PATHWAY.
-WHAT DOES UNILATERAL LESION OF SUBSTANTIA-NIGRA DO?
ACCORDING TO CARPENTER-ET-AL-t 950 WHICH IS A SUB-WORLD OF
NEURAL-DOCUMENT IN .MONKEYS PRODUCE HYPOKINESIA.
Figure 6 (Cont'd)
An Inferential Processor
Effectively, ENGOLISH could then answer questions
or sub-questions by searching its data base, running
dynamic models, or querying the user. Furthermore
this capability could also be used to allow the system
to ask questions concerning new data presented to it
and perhaps eventually the grammar itself which is
being used. Thus, given a user who did not know the
organization of the data base, but who wished to encode
a fact such as
NEURON-A IS CONNECTED TO NEURON-B
would result in the structure "CONNECTED" being
defined or updated. Of more use would be the capability
for the system to respond with
IS NEURON-A CONNECTED-EXCITATORY
to NEURON-B
or
IS NEURON-A CONNECTED-INHIBITORY
to NEURON-B
so that the new information could be represented more
consistently with existing information.
Another addition consists of making the state transformation facilities of GOL available to the user of
ENGOLISH. In addition to defining states the user
could then define actions or transformations (such as
drug administrations would entail), capable of creating
new states from old ones. This should increase the
utility of ENGOLISH for problem solving in general,
since problem solving often involves changing some
model, by using specified transformations or actions, in
search of a desired goal state for the model.
Furthermore, we are also exploring the potential
within the current system for the generation of meaningful discourse by machine. This would enable the
generation of answers to some "how" and "why"
questions, by generating text describing the path of the
GOL heuristic search process. Thus, it would describe
the sequence of transformations and their effects in a
search for the goal state in a problem solving situation.
Jl,;EFERENCES
1 N D BELNAP JR
An analysis of questions: Preliminary report
System Development Corporation Technical Memorandum
TM-1287/000/00 June 1963
2 H G BOHNERT P 0 BACKER
Automatic English-to-logic translation in a simplified
model-A study in the logic of grammar
IBM Watson Research Center RC-1744 Yorktown Heights
New York January 11 1967
1123
3 R CARNAP
Meaning and necessity
University of Chicago Press Chicago Illinois 1947
4N CHOMSKY
Aspects of the theory of syntax
MIT Press Cambridge ::'yfassachusetts 1965
5 C GREEN
Theorem proving by resolution as a baSl:S for
question-answering systems
Machine Intelligence 4 D ::.YIichie and B ::.YIeltzer eds 1968
6 C GREEN
The application of theorem proving to question-answering
systems
Stanford Research Institute CS-138 June 1969
7 C H KELLOGG
A natural language compiler for on-line data management
Proceedings AFIPS 1968 pp 473-492
8 R A KIRSCH
The computer interpretation of English text and picture
patterns
IEEE Transactions on Electronic Computers EC-13 1964
pp 363-376
9 M KOCHEN
A utomatic question-answering of English-like questions about
simple diagrams
Journal of the ACM Vol 16 No 1 January 1969 pp 26-48
10 M MINSKY ed
Semantic information processing
The MIT Press Cambridge Massachusetts 1968
11 A NEWELL H A SIMON
GPS, a program that stimulates human thought
In Computers and Thought E Feigenbaum and J Feldman
eds McGraw-Hill New York 1963
12 R J ORGASS
Logic and question answering
IBM Thomas J Watson Research Center RC 3122 # 14585
December 16 1970
13 H E POPLE JR
A goal-oriented language for the computer
Reprinted in Representation and Meaning Experimenting
with Information Processing Systems Simon & Siklossy eds
Prentice-Hall Englewood Cliffs NJ 1972
14 M R QUILLIAN
Semantic memory
PhD dissertation Carnegie-Mellon University 1966 222pp
15 M R QUILLIAN
The teachable language comprehender: A simulation program
and theory of language
Communications of the ACM Vol 12 No 8 August 1969
pp 459-476
16 E J SANDEWALL
Representing natural-language information in predicate
calculus
Artificial Intelligence Project Memo AIM-128 Stanford
July 1970
17 R W SCHWARCZ J F BURGER R F SIMMONS
A deductive question answerer for natural language inference
SDC Report-SP-3272 November 15 1968
18 R M SCHWARCZ
Towards a computational formalization of natural language
semantics
Presented at the International Conference on Computational
Linguistics in Sanga-Saby-Kursgaard Sweden September
1969
1124
Spring Joint Computer Conference, 1972
19 R C SHANK L G TESLER
A conceptual Parser for natural language
Proceedings of the Joint International Conference on
Artificial Intelligence 1969 pp 569-578
20 R C SHANK
Finding the conceptual content and intention in an utterance
in natural language conversation
Second International Joint Conference on Artificial
Intelligence September 1971 pp 444-454
21 S C SHAPIRO
A net structure for semantic information storage, deduction
and retrieval
Second International Joint Conference on Artificial
Intelligence September 1971 pp 512-523
22 R F SIMMONS
Answering English questions by computer: A survey
Communications of the ACM Vol 8 No 1 January 1965
pp 53-70
23 R F SIMMONS
Natural language question-Answering systems
Communications of the ACM Vol 13 No 1 January 1970
pp 15-30
24 F B THOMPSON
English for the computer
Proceedings AFIPS F JCC Vol 29 pp 349-356
25 W A WOODS
A procedural semantics for a question-Answering machine
Proceedings AFIPS FJCC 1968 pp 457-471
An infornlation processing approach to theory
formation in biomedical research*
by H. POPLE and G. WERNER
University of Pittsburgh
Pittsburgh, Pennsylvania
base, and which enables the model to mimic the performance of the natural system.
In some sense, one may anticipate that the potential
usefulness of computer based models grows with the
complexity of the natural domain they represent.
However, as the latter increases, model building itself
turns into an increasingly more formidable task, frequently complicated by either incompleteness or
ambiguity of some of the available observational data.
The implication of this is that the relation between a
theory and its data base on the one hand, and a corresponding model on the other hand, need not be unique;
instead, each given set of observational data of a certain
complexity can generate a class of models. Consequently, in order to work toward a parsimonious
model compatible with the available evidence, the
modeler must engage in the iterative process of identifying alternative interpretations of the data, selecting
between them, and evaluating their consequences. In
those natural domains whose complexity makes modeling
most desirable, this information processing task tends
to assume a degree of complexity that impedes model
development. To explore ways of assisting the modeler
in this task, we have inquired into the nature of the
information transactions underlying the modeling of
complex biological systems. In the following sections,
we discuss the nature of this information processing
task. We, then, focus on the problem of structure
optimization of neural networks, that is: the adaptive
process of fitting together a neural network which,
when simulated, gives rise to behavior analogous to that
observed in the natural domain. Finally, we discuss
computational procedures designed to aid in this
process.
INTRODUCTION
The extensive literature on modeling of biological
systems published in the past decade reflects the
growing expectation th~t theories of biological functions can be subject to more exacting tests of consistency with the natural system, and yield more
powerful predictions if embodied in the formal structure
of computer programs.
One principal aspect of the usefulness of such models
of biological systems is attributable to their capability
to generate predictions under conditions which transcend the human mind's limited capacity to trace
implications through long chains of causal connections,
notably when there exist possibilities for multiple
interactions between components of a system designed
for insuring some degree of homeostasis. Moreover,
once sufficiently elaborate, refined and acceptable to a
community of investigators, a model could be expected
to generate upon request observable facts at various
levels of resolution and generality, without having all
of these facts explicitly encoded and stored. In this
form, the model could be regarded as an information
storage and retrieval device from which data can be
generated by suitable programs and algorithms.
Irrespective of the particular purpose a model may
subserve, it can be considered as an aggregate of components whose initial properties are given in the form
of a set of definitions, and whose interactions are
determined by suitable transfer functions. The modeler's
task is, therefore, twofold: in the first place, suitable
algorithms need to be selected to represent the inputoutput transfer functions of the individual model
components. Second, the task consists in designing an
explicit structural arrangement of the components, and
a pattern of information flow between them, which is
suggested or implied by the information in the data
SOME ASPECTS OF THE MODELING TASK
In our work with models of complex neural control
systems, we have come to recognize the need for drawing
* This work w~ supported by NIH Contract 70-4121.
1125
1126
Spring Joint Computer Conference, 1972
a sharp distinction between the concept of "hypothesis
model" and that of "simulation model." The hypothesis
model is what the investigator carries in his head; it
consists of a collection of facts and a set of interpretive
rules that allows the researcher to perceive relationships
in the data, make predictions concerning consequences
of untried experiments, etc. A simulation model, on the
other hand, is a computer program in which the
researcher can express the essential features of his
internal hypothesis model, enabling rig~rous tests of
validity. As such, it requires a degree of explicitness
which goes beyond that commonly available in the
hypothesis model. We emphasize this dual aspect of
the modeling process in order to bring into focus the
interplay that takes place between data, hypothesis,
and simulation.
In many cases, the implications of biological data, in
terms of the scientist's hypothesis models, may give
rise to a. multitude of possible interpretations. For
example, the finding that "electrical stimulation of
Deiters Nucleus elicits IPSPS (inhibitory postsynaptic
potentials) in gamma-motorneurons" could suggest a
variety of structural connectivities; some of those are:
(a) an inhibitory pathway between the cells of
Deiter's nucleus and the flexor gamma-lmotorneurons;
(b) an excitatory pathway between the cells of
Deiter's nucleus and some spinal-interneurons
which, in turn, inhibit gamma-motorneurons on
the extensor side;
(c) orthodromic and antidromic conduction along
collaterals ofaxons which originate in some cell
group with inhibitory connections to, both,
Deiter's nucleus and certain gamma-motorneurons.
While it may be possible to rule out certain of these
alternatives on the basis of other data, the researcher is
invariably forced-in the course of constructing a
simulation model-to make essentially arbitrary choices
for which there is no conclusive evidence, either in the
theory or in the data.
If a hypothesis model is subjected to a simulation
test that is successful in the sense that the latter
exhibits behavior which is consistent with the predictions by the former, then the researcher is reinforced
in the choices that were made. On the other hand, if
this correspondence is not attained, a reexamination of
data, of hypothesis model, and of simulation model
performance may direct the investigator to more
rational choices. This is one of the principal benefits of
using simulation: it can reduce the degrees of freedom
available to the model builder, and can force a restructuring of his hypothesis model which, in the absence of
a simulation experiment, might not take place.
However, in order to exploit the full value of negative
simulation results, the researcher needs to know much
more than simply that the results were unsatisfactory.
Of course if that is all he knows, he can still proceed
with revision of the model and additional experimentation. He might, for example, go to some point in
his hypothesis model where an arbitrary choice from
among alternative interpretations of the data had been
made, and simply try another choice. In following such
an exhaustive search procedure, he may be forced to
go through a large number of variations of the simulation model until one is found that supports his theoretical model. Provided he has the patience to persevere in
this endeavor, it could lead ultimately to an enhancement of his theory.
As is the case in most such search processes, it is
reasonable to expect that some heuristic procedure
which makes use of the detailed information developed
in the course of a simulation, would provide substantial
improvement in terms of the time and effort required to
obtain a fit with the data. The important questions are:
(a) what kind of information does the researcher
need; and
(b) in what form will this information be of most
use to him.
In a later part of this paper, we will describe the kinds
of information support systems that we currently have
under development to provide relevant inputs for the
restructuring of hypothesis models. Their development
was engendered by the experience gained in the design
of a simulation model of the central neural control of
skeletal muscle tone and reflexes. As a prelude to the
discussion that follows, it will be useful to describe at
this point the way in which one observes the macroand micro-behavior in this motor control simulator,
further details of which are described in the appendix.
OBSERVATION OF MODEL BEHAVIOR
The main tool for observing macro-behavior in the
motor-control system models is the ANALYZE program
(see appendix), which is used to develop behavioral
comparisons of two states of a model (one of which
Information Processing Approach to Theory Formation in Biomedical Research
typically represents the normal condition, the other
some pathology) . This program provides a verbal
output that describes deviations in behavior in one
state of the model, relative to another, along certain
key dimensions. Changes in such attributes as amplitude and rate of muscle contraction, force required for
smooth passive stretch, frequency of oscillatory· behavior, and others are perceived and reported to the
user by this processor.
While in the model-building/ data-fitting phase of
his work, the researcher can use ANALYZE to test his
developing hypotheses concerning representation of
pathology in the model. For example, he might know
from a review of the data that a lesion affecting the
motor-cortex (area 4) would be expected to yield
predominance of extensor muscle tone in the organism..
Moreover, he might already have established in his
model a number of connections emanating from the
motor-cortex that could explain such a change in
behavior. There might, for instance, be an excitatory
pathway from this cortex to alpha motoneurons
supplying flexor muscles. In approaching a simulation
of this pathology, the researcher would therefore start
with a number of pre-conceptions and expectations. In
particular, since he intends that the structures which
appear in the model should have a functional correspondence with their counterparts in the real system,
he would expect (and indeed would insist for the model
to be considered acceptable) that destruction of the
motor-cortex of his model would be comparable, in its
behavior manifestations, to ablation of the real structure in the living organism.
Unfortunately, it often happens in the process of
model building that such pre-conceptions are not
supported by the simulation results, and it becomes
then necessary for the researcher to engage in a kind of
post-mortem where he reviews his assumptions and the
simulation results in an attempt to assess what went
wrong. Any number of things could have happened.
For example, the researcher might have expected some
pathway to be 'turned off' in the pathology because its
source of excitation would be all or partially removed.
He may find on closer examination that this particular
pathway is not sufficiently active in the normal model;
this would of course explain the failure to induce the
anticipated pathology. There may also be other, more
complicated reasons for the model to deviate from the
anticipated behavior: for instance the simulated lesion
may give rise to widely dispersed changes in the activity
pattern that are difficult to trace in the hypothesis
model, and which are therefore less likely to have been
anticipated during the theoretical analysis.
The ANALYZE program is of limited value in
1127
Figure 1
identifying such failures in the reasoning process. While
it provides an answer to the question: "How did the
model fail?" it does not address the equally important
question "Why?" In order to gain insight into why a
model fails, we must examine the micro-structure of
model behavior and the information flow at key structures along various pathways. The analysis of this
information flow in the model typically requires an
extensive series of simulation tests, involving various
diagnostic procedures in both the normal state of the
model and in the intended pathology. Once this analysis
has been completed, the researcher must then determine what these new insights concerning information
flow imply with regard to his hypothesis models, make
the appropriate adjustments, and try again.
The basic tasks involved in this modeling process are
illustrated by the flowchart of Figure 1. Here, the nodes
HI and H2 represent hypothesis models corresponding
to the two experimental conditions being compared.
The arcs connecting these nodes to the box labeled
'Simulation Analysis' correspond to sequences of commands of the form: 'Cut,' 'Tie,' 'Block,' 'Facilitate'operators which have been provided as part of the
motor-control simulator package for use in constructing
various versions of the simulation model (see appendix).
Other aspects of the flow chart are less well defined,
being part of the informal analysis engaged in by the
investigator. The box labeled 'Theoretical Analysis,'
for example, represents the researcher's attempts to
rationalize the expected change in macro-behavior on
the basis of probable changes in micro-behavior; that is,
it reflects his attempts at predicting the cause and
effect relationships that are operative in the pathology
under consideration.
These predictions feed into a comparator labeled
'Post-Mortem Analysis,' which also receives the actual
observations that result from running the simulation
model. In the event that prediction and observation fail
to match, an 'error signal' is generated and is fed back
to the box labeled 'Theory Builder' causing a restructuring of the hypothesis models and a reiteration of the
verification cycle.
1128
Spring Joint Computer Conference, 1972
Whenever this procedure requires an alteration of the
hypothesis model, the experimenter must examine
whether all experimental conditions accounted for in
the previous version of the hypothesis model, are still
satisfied. Thus, the flowchart of Figure 1 describes just
one phase of the total information processing task
associated with the development of a general hypothesis model that accounts for a number of different
experimental results.
INFORMATION SUPPORT SYSTEMS
The modeling task described in the preceding sections
comprises an extremely complex problem in information
processing. Although much of the work seems to be of a
routine and mechanical nature-tedious is perhaps the
right word-there has been no methodology available
to relieve the inordinate burden this procedure places
on the researcher. To provide an effective research tool,
capable of supporting a wider spectrum of the investigator's activity rather than merely the mechanics
of simulation, there is need for computational procedures that will aid in the theory building phases of the
total information process, and also facilitate theoretical
and post-mortem analysis.
In order to state these objectives more precisely, let
us consider again the dilemma of a researcher who is
attempting to develop theoretical models to explain
data pertaining to the motor-control system. He has
access to a number of different kinds of experimental
results that can be grouped according to the following
classifications:
(a) anatomical
(b) physiological
(c) pathological
(d) pharmacological
Assuming fixed algorithms for the neural elements
and the peripheral motor and sensory components of
the system, the researcher's task is that of developing
a theoretical model-in the form of a neural connectivity network-which is consistent with the observational data of each of these four domains, and the
implications thereof.
What we have set out to do is reduce this task to a
computational procedure. Toward this end, we have
designed and implemented an inferential processor
that can be used to analyze data and propose hypothesis models. Because of its central role in the total
information system concept, we discuss next, in some
detail, the conceptual basis of this theory building
program.
THE THEORY BUILDER
The first step in developing computational procedures
for dealing with theory is a formalization of that
theory. There are, of course, a number of computational
procedures extant-e.g., resolution, model eliminationfor dealing with the deductive aspects of theory.1,2
However, our problem is concerned not so much with
what the theory implies as with what theory is implied.
This converse problem, referred to variously in the
literature as 'apagoge' or 'abduction,'3 is put succinctly
by McCulloch:4
" ... abduction starts from the rule and guesses
that the fact is a case under that rule: All people
with tuberculosis have bumps; Mr. Jones has
bumps; perhaps Mr. Jones has tuberculosis. This,
sometimes mistakenly called an 'inverse probability,' is never certain but is, in medicine, called a
diagnosis or, when many rules are considered a
differential diagnosis, but it is usually fixed, not
by a statistjc, but by finding some other observable
sign to clinch the answer."
If we express the syllogism contained in this argument
symbolically:
Tx:JBx
Ba
Perhaps Ta
it is clear that a stronger conclusion 'Ta' would be
fallacious, and the qualifier 'perhaps' is a necessary
part of the abduction. The uncertainty that attaches
to such a result can be lessened, however-as McCulloch
points out-by finding additional evidence to clinch
the case. Even another abduction argument can lend
support; for instance, if we also have:
Tx:JCx
Ca
Perhaps Ta
and
Px:JCx
Ca
Perhaps Pa
the occurrence of two distinct data supporting 'Ta,'
while only one supports 'Pa,' would cause most of us to
hypothesize 'Ta.'
Such support can also come indirectly through a
somewhat lengthier chain of reasoning. Consider for
Information Processing Approach to Theory Formation in Biomedical Research
example the set of rules:
1129
would be:
Tx~Ex
Tx~Bx
Bx~Cx
Px~Gx
Dx~Cx
Gx~Ex
Px~Dx
Dx~Ax
Bx~Ax
Pa
We can illustrate the network of implications contained
in these premises graphically as follows, where the
upward branches at any node denote 'reverse implication':
Ax
If we observe the data: rCa, Ea}-then we might
reasonably hypothesize: {Ta, Ba, Aa} -since this collection of nodes defines a sub-graph of the net that is
mutually supportive:
Since only 2 of these 5 nodes have actually been
observed, however, any assumption concerning the
others is merely theory. An alternative theory that
might be put forth to account for these same data
where again, only 'Ca' and 'Ea' correspond to the actual
observations.
If we have the opportunity to ask questions, we often
are able to discriminate between alternative theories.
For example, in this case if we ask "Aa?" then one or
the other of the proposed theories will necessarily be
set aside. Note that although the pair {A~B, B} does
not yield a definite conclusion, the pair {A~B, B}
does.
Provided we have data that can be structured in the
form of an implicative or causal net-:-as above-we can
clearly write heuristic computer programs that engage
in the abductive process of theory building. The objective of such a program would be to find a single connected sub graph that 'covers' all of the observations;
or, failing that, a pair of such subgraphs; or a triple,
etc. Since each additional subgraph included in a theory
contains an additional basic assumption (top node),
the goal of parsimony in theory development would
provide a rule for selection from among alternative
hypotheses even in the absence of other criteria. If,
in addition, we have the ability to ask questions of the
user, of a simulation model, and of the structured and
unstructured data files, the power of our program to
develop sound theory is clearly enhanced.
We have encoded and successfully demonstrated a
heuristic processor, using a combination of LISpIO,ll
and GOL5 routines, that constructs hypothesis models
on the basis of the heuristic procedure outlined above.
We are in the process of interfacing this Theory Building program with a natural language query system that
also possesses some inferential capability, subsequently
referred to as ENGOLISH.6 This makes it possible
that:
(a) an uninterpreted literature data base,
III
the
1130
Spring Joint Computer Conference, 1972
form of ENGOLISH data structures, can be
accessed by the theory builder program, and
(b) the theory builder program can be invoked to
develop hypothesis models while engaged in an
ENGOLISH dialog with the user; thus avoiding
inconsistencies, ambiguities, and incompleteness
in the data base recorded.
The set of rules that generates the abduction net of
the theory builder is encoded in a table of associations
called SUGGESTS, the present form of which is as
follows:
(GOLDEF SUGGESTS
(SOOOO
(EXT
((P Q R S U V W X Y Z»
((PROJECTS P Q) ((POLARITY X) (CELL-TYPE P Y) (CELL-TYPE Q Z»
((PATHWAY MONOSYNAPTIC X Y Z»)
((ELICITS (P Q) (R S»
((PATHTYPE P R W X»
((PATHWAY W X Q S»)
((PATHWAY POLYSYNAPTIC P Q R)
((MATCHUP P Y W) (DISTINCT Q S)
(DISTINCT S R)
(ORTHODROMIC Z»
((PATHWAY MONOSYNAPTIC Y Q S) (PATHWAY Z W S R»)
((PATHWAY ANTIDROMIC P Q R)
((ORTHODROlVIIC X) (MATCHA P X Y W)
(DISTINCT Q S)
(DISTINCT R S»
((PATHWAY MONOSYNAPTIC Y S Q) (PATHWAY X W S R»)
((INTERRUPTED (PATHWAY MONOSYNAPTIC P Q R) U)
((GOLDIG (LAMBDA NIL (OR (DESTROYED R) (DESTROYED Q»» U))
((PATHWAY MONOSYNAPTIC P Q R»)
((INTERRUPTED (PATHWAY POLYSYNAPTIC P Q R) U)
((MATCHUP P Y W)
(DISTINCT Q S)
(DISTINCT S R)
(ORTHODROMIC X)
(GOLDIG ((LAMBDA NIL (OR (DESTROYED Q) DESTROYED S»») U))
((PATHWAY MONOSYNAPTIC Y Q S) (PATHWAY X W S R»))
((INTERRUPTED (PATHWAY POLYSYNAPTIC P Q R) U)
((MATCHUP P Y W) (DISTINCT Q S)
(DISTINCT S R)
(ORTHODROMIC X»
((PATHWAY MONOSYNAPTIC Y Q S)
(INTERRUPTED (PATHWAY X W S R) U»)
((INTERRUPTED (PATHWAY ANTIDROl\tIIC P Q R) U)
((ORTHODROMIC X)
(MATCHA P X Y W)
(DISTINCT Q S)
(DISTINCT R S)
(GOLDIG ((LAMBDA NIL (OR (DESTROYED Q) (DESTROYED S»» U»
((PATHWAY MONOSYNAPTIC Y S Q) (PATHWAY X W S R»)
((INTERRUPTED (PATHWAY ANTIDROMIC P Q R) U)
((ORTHODROMIC X) (l\tIATCHA P X Y W)
(DISTINCT Q S)
(DISTINCT R S»
((PATHWAY MONOSYNAPTIC Y S Q)
(INTERRUPTED (PATHWAY X W S R) U»»)
Information Processing Approach to Theory Formation in Biomedical Research
This table is encoded as a GOL extensional data
structureS in which the symbols: (P, Q, R, S, U, V,
W, X, Y, Z) stand for universally quantified variables.
Each entry of the table consists of three parts, (A Be),
which can be read:
1131
PURKINJECElLS
PURKINJECELlS
"e implies A under conditions B"
For example, the first entry would be interpreted:
A(P, Q, X, Y, Z) pathway (monosynaptic, X, Y, Z)
::) projects (P, Q); where (polarity (X) 1\
cell-type (P, Y) 1\ cell-type (Q, Z).
In this expression,
'pathway' predicates a monosynaptic connection,
of polarity X between cells of type Y and
type Z
'projects' predicates a fiber projection between
neural structures P and Q.
'polarity' is the property: {excitatory, inhibitory} ;
and
'cell-type' is a relation that associates the names of
neural structures with the various neural
populations subsumed thereunder.
The operation of abduction, using the SUGGESTS
data structure entails an associative access whereby
some observational datum (e.g., 'proj ects motor-cortex-4
flexor-alphas') is matched against the first position (A)
of appropriate entries of the table, with the result
a hypothesis (e) qualified by the expression (B). The
reason for employing quantifiers and qualifiers in the
SUGGEST-Table is that this permits large numbers of
nodes to be represented compactly by a single entry;
furthermore, it enables the use of much more powerful
search techniques than would otherwise be possible.
This refined principle of operation would appear to
have the same relation to simple abduction that resolution holds to Herbrand expansion. 2
While these concepts and their relationship to other
paradigms of artificial intelligence will be the subject
of subsequent publications,7 we present at this juncture
an illustration of their operational aspects. For this
purpose, we consider an application of the theory
builder in the context of a collection of typical neurophysiological data giving rise to alternative hypothesis
models.
In a discussion of the diversity of the effects of
cerebellar stimulation, Eccles et al. 8 describe the various
pathways which mediate the inhibitory influence of the
cerebellar cortex on a cell group in the vestibular
nuclei. Some aspects of this discussion can be stated in
DEITERS NUCLEUS
DEITERS NUCLEUS
NEO-INF-OLIVE
NE~-INF-OLIVf
A
B
Figure 2-Schematic diagrams of the neuronal connectivity
proposed by the theory building program. The empty circles are
neural structures whose names correspond to those appearing in
the program dialogue. The connecting pathways ending with an
open branch signify excitatory, those ending with a solid circle
inhibitory connections
terms of the following propositions:
(1) the inferior olive projects monosynaptically via
the climbing fibers to the cerebellar cortex;
(2) activity engendered by electrical stimulation in
the main inferior olivary nucleus (neo-olive)
elicits EPSP's in Purkinje cells;
(3) activity engendered by electrical stimulation in
the main inferior olivary nucleus elicits IPSP's
in Deiters Nucleus.
(4) electrical stimulation of Purkinje cells elicits
IPSP's in Deiters Nucleus.
To deal with these propositions meaningfully, some
general background knowledge is required which finds
its representation in the data encoded in the SUGGESTtable, given previously:
(a) fiber projections identified by neuro-anatomical
procedures are monosynaptic pathways;
(b) electrical stimulation in the typical experimental procedure elicits activity not only in the
target cells, but also in fibers and their termination in the vicinity of these cells.
(c) impulse traffic in fiber tracts under condition of
artificial electrical stimulation can be either
ortho- or antidromic, or both.
(d) chronic lesion of a structure interrupts impulse
transmission (both, ortho- and antidromic) in
all pathways of which this structure is a part.
As illustrated by the following dialogue and in Figure
2a, when supplied with just these propositions and
facts, the theory builder proposes a partial model,
consisting of one excitatory and one inhibitory mono-
1132
Spring Joint Computer Conference, 1972
synaptic pathway:
*(STRUCTURE INFERIOR-OLIVE NEO-INF-OLIVE PALEO-INF-OLIVE)
NIL
*(STRUCTURE
CEREBELLAR-CORTEX
PURKINJE-CELLS
GOLGI-CELLS
BASKET-CELLS)
NIL
DEITERS-NUCLEUS
VESTIBULAR-NUCLEI
*(STRUCTURE
SUPERIOR-VN
DESCENDING- VN)
MEDIAL-VN
NIL
INFERIOR-OLIVE
(PROJECTS
*(OBSERVATION
CEREBELLAR-CORTEX) )
NIL
NEO-INF-OLIVE)
(STIM
*(OBSERVATION
(ELICITS
(EPSP
PURKINJE-CELLS)))
*NIL
NEO-INF-OLIVE)
(STIM
(ELICITS
*(OBSERVATION
(IPSP
DEITERS-NUCLEUS)) )
NIL
(E-STIM PURKINJE-CELLS)
(ELICITS
*(OBSERVATION
(IPSP
DEITERS-NUCLEUS)) )
NIL
*(PONDER)
(PROPOSE MODEL:
EXCITATORY
MONOSYNAPTIC
((PATHWAY
PURKINJE-CELLS)
NEO-INF-OLIVE
INHIBITORY
MONOSYNAPTIC
(PATHWAY
DEITERS-NUCLEUS)) )
PURKINJE-CELLS
If now provided with the additional observational datum that a chronic lesion of the inferior olive abolishes the
inhibitory response in Deiters nucleus that follows electrical stimulation of Purkinje cells, the program recognizes
the inconsistency between the implications of this finding and its internal model. This gives rise to a restructured
hypothesis model, as follows (see Figure 2 B): .
*(EXPLAIN
(ABOLISHES
INFERIOR-OLIVE)
(CHRONIC-LESION
(ELICITS (E-STIlVI PURKINJE-CELLS)
(IPSP DEITERS-NUCLEUS)
)))
(THIS FINDING INCONSISTENT WITH PREVIOUS MODEL)
(PROPOSE PARTIAL MODEL) :
((PATHWAY
(PATHWAY
lV[ONOSYNAPTIC
NEO-INF-OLIVE
POLYSYNAPTIC
NEO-INF-OLIVE
The operation of the theory building program starts
with the definition of the domain of discourse: this is
accomplished by use of the STRUCTURE-command.
The first argument of this command designates the
name of a neural structure; subsequent arguments
EXCITATORY
PURKINJE-CELLS)
INHIBITORY
DEITERS-NUCLEUS)) )
identify its components. The command OBSERVATION is used to perform a preliminary encoding of an
observational datum which may be either a statement
concerning automical connections, or a description of
functional relations. Supplied with these facts,
Information Processing Approach to Theory Formation in Biomedical Research
PONDER is called to invoke the abduction process
which generates a parsimonious hypothesis model that
accounts for the data supplied thus far.
The continuation of the model building process
consists of the addition of new data and their evaluation
relative to the existing model. The macro command
EXPLAIN is available for this purpose: in the first
place, it enables the user to supply a new observational
datum; the program, then, ascertains whether this new
fact is consistent with the existing hypothesis model:
if this is the case, it renders an account of that part of
the existing model which has been enriched, either by
way of confirmation of an existing aspect of the model,
or by expanding its domain. Alternatively, the program
may discover an inconsistency between the model it
contains and the new datum, in which case it reverts to
PONDER to attempt the generation of a new model
which accommodates all of the facts it has been given
up to that time.
ON MECHANIZED MODEL BUILDINGAN OUTLOOK
Having presented and illustrated the mode of operation and capability of the theory building program, we
are now in a position to assess its role within the total
information support system for model building. With
reference to the flow chart of Figure 1 which dissected
the process of model building into identifiable steps and
the interrelations between them, we have demonstrated
that the theory building program can generate hypotheses on the connectivity of model components which
correspond to the boxes labeled HI and H2 in that
Figure: that is, a connectivity that may obtain under
normal, and also satisfies some abnormal, conditions;
the latter consists in the example given of an artificial,
experimental lesion. The hypotheses concerning connectivity are of a form which permits them directly to
be represented in the simulation model by means of the
CUT and TIE commands (see appendix).
The example illustrates that the formation of hypothesis models can be mechanized, which was the
principal objective we have set out to accomplish.
Beyond this, the theory building program contains
features which enable it to contribute also in other ways
to the development of theoretical models; namely, by
posing questions, and by proposing experiments to be
conducted in the "simulation laboratory." To this end,
the EXPLAIN command can be used to generate
predictions and expectations for meaningful postmortem analysis (see Figure 1) : it directs the investigator's attention to those components and pathways of
1133
the simulation model which are expected to be most
prominently involved in the anticipated behavioral
differences. The outcomes of the theoretical and the
simulation analysis can now be compared; if significant
differences obtain-which would signify the negation
of some implication of the hypothesis model-this new
datum can be fed back and employed in the restructuring of the hypothesis.
Operating in this manner, the theory-building
program can now be envisaged to perform the structure
optimization of the neural network, relieving the
investigator from the tedium of the iterative process of
fitting observational data into a useful simulation
model. Instead, once he has defined the first principles
which will serve as the basis of theory formation-in
the form of rules in the SUGGESTS data structure-he
is able to assess continuously the sufficiency and
necessity of his concept of the natural domain under
study, and the consistency of this concept with newly
acquired data.
APPENDIX
Modeling tools of the motor control system simulator
The motor control system simulator is a processor
that can be used to construct and evaluate simulation
models of neural control mechanisms which play a role
in the regulation of certain skeletal muscle reflexes and
of muscle tone. This requires, in the first place, that the
investigator have available a versatile set of commands
to define neural structures and to interconnect them by
pathways of suitably chosen length (i.e., conduction
time). These commands are intended to enable the
investigator to formalize his conception of the system
under study in the form of a model that can be altered
conveniently in accord with new evidence; that can
reflect some experimentally induced condition; and
that can mimic disease states as well as effects due to
administration of pharmacological agents. The second
requirement was to provide programming tools which
would exercise the model in a manner analogous to the
tests used by the experimentor to ascertain the functional capabilities of the natural system. Thirdly, it
seemed to us necessary to provide the ability for
examining the performance of components in the model,
and of the model as a whole, at different levels of
resolution, comparable to the procedures used by the
experimenter: at one time he may be interested in the
fine temporal pattern of activity in one single node of
the model; and another time, in a time average of the
activity, or in the trend; and at some other occasion,
1134
Spring Joint Computer Conference, 1972
in the gross overt performance of an effector organ (in
the case of the prototype model: muscle length and
tone), or merely in the deviation of this performance
from a normal baseline; finally, the investigator may
wish to recognize the relation between performance of
an effector organ and the pattern or activity flow between the interacting components of the (neural)
control system. Accordingly, programs to extract and
perceive anyone of these aspects of the model's behavior are available for selection by the user.
TABLE I-Periphery Algorithms
1.
2.
3.
4.
5.
6.
7.
8.
9.
Algorithms of system components
10.
The basic element of the simulated neural system is
a stylized neuron whose activity state is described by a
quadruple of numbers, each ranging over the numerical
values from zero to four. These numbers designate, in
this sequence, output, threshold, input, and a term
representing a "driving force." The latter is a constant
which sums algebraically with the value of the threshold
and enables the user to set a positive or negative bias
value on the neuron computation.
These formal neurons can be connected by excitatory
or inhibitory links to form a finite state machine in
which each neuron can receive an arbitrary number of
inputs. These are summed algebraically to determine
the net input. Computation within the neural network
is deterministic and proceeds in discrete time steps,
each corresponding to the synaptic delay of approximately 1 millisecond duration in. real time. At each
time slice, the input and output values of each neuron,
representing a neurophysiologic ally characterized
neuron population, are updated on the basis of the
following algorithms:
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
if «input(t-1) >thresh) and
(output(t-1) input(t-1)):
output(t) =output(t-1)-1
else: output(t) =output(t-1)
inputj(t) = 2:. (outputk(t-dkj ))
21.
22.
23.
24.
25.
26.
motor-output(t): = flexor alpha-motorneuron
ext-motor-output(t) : = extensor-alpha-motorneuron
gammal-output(t): = flexor-gammal-motorneuron
gamma2-output(t) : = flexor-gamma2-motorneuron
ext-gammal-output(t) : = extensor-gammal-motorneuron
ext-gamma2-output(t) : = extensor-gamma2-motorneuron
flex-Iength(t+l) : = flex-Iength(t) +
flex-mult * (golgi-output(t) - motor-output(t»
ext-length (t+l) : = ext-Iength(t) +
ext-mult * (ext-golgi-output(t) - ext-motor-output(t»
golgi-output (t+l) : = (ext-length (t+l) /
(ext-length (t+l) + flex-length (t+l»)*
(ext-motor-output(t) + motor-output(t»
ext-golgi-output (t+ 1) : = (flex-length (t+ 1) /
(ext-length (t + 1) + flex-length (t + 1) » *
(ext-motor-output(t) + motor-output(t»
chain-output (t+l) : = scale (flex-length (t+1) chain-Iength(t), kchn)
chain-length (t+1) : = chain-Iength(t)
cmult * (chain-output (t+1) - gamma2-output(t»;
(clip at zero)
ext-chain-output (t+1) : = scale (ext-length (t+1) ext-chain-Iength(t), kchn)
ext-chain-Iength (t+1) : = ext-chain-Iength(t) + ecmult *
(ext-chain-output (t+1) - ext-gamma2-output(t»;
(clip at zero)
ext-bag-output (t+1) : = scale (ext-length (t+1) ext-bag-Iength(t), kbag)
ext-bag-Iength (t+ 1) : = ext-bag-Iength(t) + ebmult *
(ext-bag-output (t + 1) - ext-gamma I-output (t» ;
(clip at zero)
ext-bag-rate: = ext-mult (ext-golgi-output(t) ext-motor-output(t» - ebmult* (ext-bag-output(t+1) ext-gamma l-output(t» + ext-bag-output (t+l)
bag-output (t+ 1) : = scale (flex-length (t+ 1) bag-Iength(t), kbag)
bmult*
bag-length (t+l) : = bag-Iength(t)
(bag-output (t+ 1) - gamma l-output(t»;
(clip at zero)
bag-rate: = flex-mult (golgi-output(t) - motor-output(t»bmult* (bag-output (t+1) - gamma l-output(t» +
bag-output (t+l)
golgi-tendon (t+1) : = golgi-output (t+1)
ext-golgi-tendon (t+1) : = ext-golgi-output (t+1)
nuclear-chain (t+l) := chain-output (t+1)
nuclear-bag (t+1) : = bag-rate (t+1)
ext-nuclear-chain (t+1) : = ext-chain-output (t+1)
ext-nuclear-bag (t+l) : = ext-bag-rate (t+1)
+
+
kEA
(where A is the set of structures K that are connected, via delays of lengths dkil to the j th neuron.
The neural network controls the length of reciprocally
connected flexor and extensor muscles through the
algorithm of table 1 which also computes for each value
of muscle length and gamma motorneuron output the
feedback signals generated by muscle spindles (nuclear
bag and chain organs) and Golgi tendon stretch
receptors as schematically illustrated in Figure 3 (for
review, see Reference 9). The connecting links between
the neural control network and the muscle effector
system are provided by three motor neurons, each, on
flexor and extensor side; and by afferent pathways
originating from the length and tension transducers of
muscles and tendons. Items 1 through 6 of Table 1
designate the relationship between the respective
Information Processing Approach to Theory Formation in Biomedical Research
motor neurons and the variables appearing in the
periphery algorithms; items 21 through 26 designate the
sources of feed back signals. The parameters appearing
in these algorithms have the following meanings:
flex-mult [ext-mult J: scale factor used to translate
the tension changes of flexor
[extensor] extrafusal muscle
fibers into length changes;
a scale factor to accomplish the
cmult [ecmultJ:
same for intrafusal muscle fibers
of the nuclear chain receptors;
a scale factor for intrafusal
bmult [ebmultJ:
muscle fibers of the nuclear
bag receptors;
a scaling function that uses the
scale:
tabular functions KBAG and
KCRN (see later) to translate
length
differences
between
extra- and intrafusal muscle
fibers of nuclear bag and nuclear
chain receptors, respectively,
into the static component of the
transducer outputs.
It might be useful at this point to comment on
issues of implementation. We have had access for this
Figure 3-Schematic display of an antagonistic muscle pair
(F = flexor, E = extensor muscle), and their efferent and
afferent innervation. ex - MN = motorneurons supplying the
extrafusal muscle fibers; "Y1- and 1'2-MN's: gamma-motorneurons
supplying the muscle fibers of nuclear bag and nuclear chain
transducers, respectively, from which the afferent nerve impulses
signaling muscle length originate. Golgi = receptors situated in
muscle tendons and signaling muscle tension
1135
development to a medium scale PDP-I0 system, on
which a superb LISP interpreter lO •ll is available. To
provide the user a convenjent means for· interacting
with his simulation models, we have encoded a set of
supervisor and exercisor routines-to be described
presently-that operate in the context of this LISP
interpreter. Since LISP is singularly inefficient in its
provision for numerical computation, those algorithms
described above which define computations at the
neural nodes as well as in the peripheral effector and
sensor organs have been encoded in FORTRAN, and
the resulting compiled modules have been incorporated
in the LISP system as callable subroutines. Thus in the
discussion that follows, although the notation used to
illustrate features of the simulation system if that of
LISP, the reader should be aware that the actual
simulation results are produced by execution of the
appropriate FORTRAN subroutines, upon direction
by the LISP supervisor programs.
Command structure for model building
The devices needed to build a model and to alter
connections, add or delete structures, specify delays
(i.e., conduction times between neural structures, in
milliseconds real time) and to pass numerical parameters to the computational algorithm are available in
the form of a set of LISP functions. Examples of some
steps in the building of a model are illustrated in the
following interactive dialogue with the model building
supervisor:
*(ADD NEURON @N-RUBER 1$
N-RUBER
(4900100) (IMPINGE+) (IMPINGE-)
NIL
*(ADD DELAY DEEP-CEREBELLAR-NUCLEUS
15$
DELAY40
(INPUT: 3)
*(ADD DELAY N-RUBER 20$
DELAY36
(INPUT: 49)
*(TIE EXCITATORY DELAY40 N-RUBER$
N-RUBER
(4900 100) (IMPINGE+ DELAY40)
(IMPINGE-)
NIL
*(TIE EXCITATORY DELAY36 FLEXORALPRA-MOTORNEURON$
1136
Spring Joint Computer Conference, 1972
FLEXOR-ALPHA-MOTORNEURON
(3200 200) (IMPINGE+ DELAY36 DELAY21
DELAY5 AFFERENT2-INTERNEURON
EXT-INTERNEURON1B) (IMPINGEDELAY12 EXT-INTERNEURON1A
RENSHAW-CELL
INTERNEURON1B)
NIL
*(TIE EXCITATORY DELAY36 GAMMA1MOTORNEURON$
GAMMA1-MOTORNEURON
(3400 1 00) (IMPINGE+ DELAY36 DELA Y26
DELAY21) (IMPINGE-INTERNEURON1B
DELAY 12)
NIL
*(SAVE RUBER$
JOB-SAVED
In this example, the user wished to add a new structure to the model, namely nucleus ruber (N -ruber) ,
and to connect it via appropriate delays so that it would
get excitatory input from the deep-cerebellar-N ucleus
(already in the model), and deliver excitatory output to
the alpha- and gamma-l motorneurons on the flexor
side. The instruction (ADD N-RUBER) requires
specification of the new structure's threshold which was
chosen to be 1.
Upon requesting the addition of delays (ADD
DELAY with the statement of point of origin and
duration), the program returns the call by assigning a
number to the new delay (the numbers 40 and 36 were
assigned, respectively).
The counterpart to ADD is the instruction DELETE
(not shown here).
Once all new structures are added and their thresholds
and delay length specified, the user applies (TIE)
which calls for three arguments: excitatory (or inhibitory)
name of the structure of origin
Two more changes are then made: a driving force of
+2 is added to the Deiters-Nucleus by means of the
instruction (TRY DRIVER ... value). This means
that deiters nucleus will now have an output of two in
the absence of any excitatory input, and this value of
two will be added to any output level computed (with
the ceiling value, of course, remaining 4). Furthermore,
the sensitivity of the nuclear bag end organs is changed:
first, the user examines their old value with KBAG;
there are 4 criterion levels set (1 through 4); any
length difference between extra- and intrafusal muscle
fibers up to 25 generates an output of 1; similarly, the
values 2, 3 and 4 are generated by the specified length
differences. These criterion values are changed by
STORE (KBAG etc.).
*(INSTATE RUBER$
NIL
NIL
*(TRY DRIVER DEITERS-NUCLEUS 2$
OK
*(KBAG 1$
25
*(KBAG 2$
50
*(KBAG 3$
100
* (KBAG 4$
200
*
(STORE
50
*(STORE
100
* (STORE
200
*(STORE
300
(KBAG 1) 50$
(KBAG 2) 100$
(KBAG 3) 200$
(KBAG 4) 300$
*
name of the structure of endpoint of new link.
The input to the newly added delays is already furnished by the instruction ADD. After the new connection is established, the program lists all excitatory and
inhibitory inputs to the recipient structure of the new
connection in the form if (IMPINGE+ ... ) and
(IMPIN GE - ... ), respectively.
The counterpart to TIE is CUT which severs existing
connections and requires the same format of arguments
as does TIE.
The user then decides to save the new model under
the name of RUBER.
Neurological lesions can be simulated by the command (KILL-name of structure-) which sets the
threshold of this structure to the value of 4 and, thus,
effectively eliminates the structure from the flow of
activity in the network.
The command BLOCK, decreases the activity level
of a set of one or more structures by a specified value:
for example, (BLOCK T 1 @ (RAS RAS-INTERNEURON) ). The neural structures within the parentheses are affected. The converse effect is generated by
the command (FACILITATE T +1 @(RAS))
which mimics an excitatory drug effect.
Information Processing Approach to Theory Formation in Biomedical Research
OBSERVATION OF MODEL PERFORMANCE
To enable testing the performance of the model with
the types of maneuvers applied by neurophysiologists
or neurologists to evaluate the functional state of the
motor system, two functions are defined:
PULSE, designed to mimic a brief muscle pull, and
consisting in the application of input pulses to the
muscle spindle afferents of a specified muscle for a
brief, specified period of time. This function is
intended to test the motor system for its ability to
support a phasic stretch reflex of the kind commonly
employed in the form of the "knee jerk."
STRETCH, on the other hand, is designed to test
for active resistance to muscle stretch, developed
in the course of slow extension of the muscle under
study, with rate and duration of passive muscle
stretch to be specified by the user. The muscle
tension developed during passive stretch is computed as the incremental activity required at the
Golgi stretch receptors to sustain the specified
rate of muscle elongation during the stretch
interval.
For the assessment of the model's response to these
kinds of stimuli, the important variable to be observed
is that of muscle length. In addition, the user may wish
to observe activity levels of selected neural structures.
He can accomplish this defining a "WINDOW" that
lists these structures by name.
Even if only a few structures of the model are being
monitored, the output generated as a result of several
hundred state transitions in discrete time becomes
bulky and cumbersome to interpret; details that should
2000
RECOVERS
STARTING
S:!~0IENG k-----l-_ _ _ _
VA_L_UE_ _~iL--*___+~~~~""""""'-
PEAK
O~~-------~--L-----~~
STATE I
STATE 2
STATE:3
o
STATE 4
TIME
Figure 4
10006 t
1137
stand out to attract the user's immediate attention,
tend to become obscured. Thus, some compression of
output is needed to enable quick and reliable "perception" of the performance.
For the purpose of perceiving the characteristic
features in muscle behavior following PULSE or
STRETCH perturbations, we view the resulting
transient departure from resting muscle length as
comprising four states (Figure 4) :
State 1: commencing with the application of the
stimulus and extending until deviation
of muscle length exceeds criterion level;
State 2: follows state 1 and extends until resting
muscle length is recovered; value and
time of occurrence of the extremum, and
time till recovery are recorded.
State 3: follows state 2 and encompasses the
period during which the primary overshoot occurs; its magnitude is recorded.
State 4: encompasses the remainder of the observation period during which mean
muscle length, maximal excursions and
frequency of oscillation are recorded.
In the case of what would be considered a normal reflex, the observation terminates in state 4. Abnormal or
abortive reflex behavior can cause the perception
algorithm to terminate in any of the earlier states, in
which case appropriate messages are generated.
For the neural structures named in a WINDOW,
the compressed output consists of a mean activity level
over the observation period and the number of oscillations that may have occurred. Moreover, as shown
below, the algorithm records duration and time of
occurrence of the longest sustained periods of high and
low levels of activity. Although not illustrated, the
program also computes time of occurrence and intensity
of the first burst of activity triggered by the test
procedure; this reflects the temporal dispersion of
transient activity in the neural network.
*(SETQ WINDOW @(N-VENTRALISANTERIOR GAMMA1-MOTORNEURON»
(N-VENTRALIS-ANTERIOR GAMMA1MOTORNEURON)
* (PULSE FLEXOR 3 50 H1£1£1)
FLEXOR-MUSCLE
STARTING-LENGTH 1£1£1£1
EXTREME-VALUE 800, OCCURS-AT 75
STARTING-VALUE-REGAINED-AT 24£1,
OVERSHOOT 32
1138
Spring Joint Computer Conference, 1972
STEADY-STATE-VALUES: MEAN 999,
STANDARD-DEVIATION 51 HIGHEST-VALUE
1088, LOWEST-VALUE 908, #-OSCILLATIONS 28
FINAL-VALUE 1036
DO-YOU-WISH-TO-EXAMINE-WINDOW *YES
N-VENTRALIS-ANTERIOR: MEAN 17, #-OSC 56
LONGEST-RISE 38, OCCURS-AT 112
LONGEST-FALL 20, OCCURS-AT 188
GAMMA1-MOTORNEURON: MEAN 11, #-OSC 70
LONGEST-RISE 20, OCCURS-AT 126
LONGEST-FALL 26, OCCURS-AT 963
While these perception algorithms describe model
behavior in absolute and numerical terms, observational
records in the natural domain are typically stated in
terms of qualitative descriptors, most commonly of a
comparative nature; that is: in terms of deviations from
a reference state. To enable the modeler to perceive his
simulation results in these same terms, we devised the
program ANALYZE. This program performs a sequence
of tests on two specified states of a model, compares
the results and generates a verbal output that describes
differences in behavior along certain key dimensions.
An application of this program is illustrated below: at
first, a lesion of substantia-nigra is produced by applying the KILL-instruction; this causes the behavior of
the model to depart from the normal condition in a
manner resembling that of Parkinson's disease in that
the response to a PULSE stimulus of the flexor muscle
is augmented and abnormally prolonged while the
STRETCH of the flexor muscle induces an oscillatory
response (i.e., tremor).
*(KILL SUBSTANTIA-NIGRA)
DONE
*(ANALYZE @NORMAL)
((PULSE-FLEX NEVER-RECOVERS LATE-PEAK
AUGMENTED-PEAK) (PULSE-EXT ABSENT)
(STRETCH-FLEX OSCILLATIONS EARLYRECOVERY) (STRETCH-EXT NEVERRECOVERS))
*
The tremor component of this pathology is in the next
simulation run alleviated by combining the lesion of
substantia nigra with a second lesion, intended to
mimic one form of neuro surgical management of
Parkinson's disease, namely a lesion of the nucleus
ventralis anterior of the thalamus:
*(KILL SUBSTANTIA-NIGRA)
DONE
*(KILL N-VENTRALIS-ANTERIOR)
DONE
*
(ANALYZE @NORMAL)
( (PULSE-FLEX NEVER-RECOVERS LATE-PEAK
AUGMENTED-PEAK) (PULSE-EXT ABSENT)
(STRETCH-FLEX EARLY-RECOVERY)
(STRETCH-EXT NEVER-RECOVERS))
*
REFERENCES
1 D W LOVELAND
Theorem provers combining model elimination and resolution
Machine Intelligence Vol 4 ed B Meltzer and D Michie
American Elsevier 1970
2 J A ROBINSON
A review of automatic theorem proving
Ann Symposium in Applied Mathematics 19:1 1967
3 C S PEIRCE
Collected papers of Charles Sanders Peirce
C Hartshorne P Weiss and A Burks eds 8 vols Cambridge
Mass pp 1931-1958-Especially Vol II pp 272-607
4 W S McCULLOCH
What's in the brain that ink may character
Presented at the International Congress for Logic,
Methodology and Philosophy of Science 1964-Reprinted in
W S McCulloch Embodiments of Mind MIT Press 1962
5 H E POPLE JR
A goal oriented language for the computer
In Representation and Meaning-Experiments with
Information Processing Systems-H Simon and N Siklossy
eds Prentice Hall 1972
6 D ISNER
An inferential processor for interacting with biomedical data
using restricted natural language
AFIPS Conference Proceedings Spring Joint Computer
Conference 1972
7 H E POPLE JR
On the mechanization of abductive logic
In preparation
8 J C M ECCLES ITO SZENTAGOTHAI
J SZENTAGOTHAI
The cerebellum as a neuronal machine
Springer Publications 1971
9 R GRANIT
The basis of motor control
Academic Press 1970
10 J McCARTHY P W ABRAHAMS D J EDWARDS
T P HART M I LEVIN
L1SP 1.5 programmer manual
The MIT Press 1962
11 L H QUAM
L1SP 1.6 manual
Stanford Artificial Intelligence Project
The clinical significance of simulation and modeling in
leukemia chemotherapy*
by T. L. LINCOLN
The Rand Corporation
Santa Monica, California
INTRODUCTION
blood and the bone marrow; (3) it responds to rational,
well-organized therapeutic regimens; effective drug
doses and schedules can be set up which depend upon
cell kinetics (models of cell behavior) and pharmacokinetics (models of drug distribution); (4) the impact
of drug therapy is quantifiable, thus the regimens can
be evaluated and the models verified; and (5) good
results depend upon a persistent, well-organized
approach.
We might put the argument another way: We have
strong drugs with which to treat leukemia, but our
therapeutic advantage is sufficiently small, and our
knowledge sufficiently limited that the penality for
sloppy thinking and sloppy patient management is
particularly high. This disease is a test of our ability
to manage medical information, to understand its
implications, and to apply our knowledge wisely.
Because quantitative data is the key aspect of decisionmaking in this disease, skill in the use of quantitative
information is essential to success. At the same time,
because of the importance of teamwork between the
specialties of hematology, clinical oncology, infectious
disease, and laboratory medicine, leukemia therapy
is an excellent test of the ability of computer technology
to coordinate the relevant information: Moreover,
success, short of a cure, requires long term sophisticated
maintenance therapy, and thus effective long term
records. To pursue the automobile analogy, we might
consider the skill, the teamwork, and the endurance
required for this information processing system to be
in some sense parallel to that required to run in the ./
Indianapolis 500.
It seems certain that in the next thirty years-by the
year 2001-the computer will become a major instrument in support of clinical practice. Part of our task
today is to look beyond the frustrations, expense, and
apparent waste of our present prototype systems and
to distinguish the important themes which will bind
Inedicine and computers together. In computer medicine we are clearly in the exploratory phase of a new
technology-a position analogous to the early designers
and users of automobiles. With the introduction of the
automobile came a great variety of expensive, made-toorder cars which could only be run on poorly maintained
muddy roads. To drive required a large measure of
patience, enthusiasm, and self-reliance, coupled with
a fine sense of the ridiculous. Moreover, the automobile
scared the horses, and otherwise challenged the established order of things. And still it came, demanding
new conventions to make its use effective: freeways,
parking tickets, campers, bedroom communitites, air
pollution-the good with the bad.
This is a talk about mathematical modeling, simulation, and leukemia chemotherapy; but I have opened
in this way because it is not the details of leukemia
chemotherapy which I want to emphasize, but rather
the far-reaching changes which information processing
is destined to bring to this field. The primary changes
will be found in the conventions of clinical decisionmaking. The use of mathematical modeling and the
computer in leukemia chemotherapy is particularly
illustrative of a new form of medical practice because
(1) the untreated disease is usually rapidly fatal and
deserves the investment; there are 14,000 new cases a
year, many in children and young people; (2) it is
quantifiable; the leukemia cells can be sampled in the
DISCUSSION
The chemotherapy of acute myelogenous leukemia
was chosen for my research as the principal area for
modeling. This disease lends itself to a quantitative
* This work is supported under NIH Grant CA-12369.
1139
1140
Spring Joint Computer Conference, 1972
analysis because there are good measures of success,
failure and complications. Treatment is quantitative
and offers a spectrum of options in detailed implementation. The purpose of simulation is to make the choice of
treatment options more rational. Leukemia can be
compared to the growth of crab grass in a lawn. If
left by itself, this agressive grass will overtake the lawn
and destroy it. In a like manner, leukemic cells grow
in the bone marrow and come to replace the cells which
are usually present there. As the bone marrow is encroached upon, its normal function-to supply red cells,
granulocytes, and platelets to the blood- is compromised. The lack of red cells leads to anemia; the
lack of granulocytes leads to an increased susceptibility
to bacterial infection; and the lack of platelets-a
cell needed for blood clotting-leads to hemorrhaging.
If nothing is done, the patient will die quickly from
one of those complications. Treatment must stop the
process and turn it back. The ideal objective of chemotherapy is to kill the encroaching leukemic cells without
injurying the normal cell lines. However, the best that
can be done is to establish a differential kill rate based on
differences in growth characteristics, so that on balance
more leukemic cells die than normal cells. In the crab
grass analogy, the use of a growth poison, such as
chlordane, achieves a differential kill rate because
the crab grass grows more rapidly than the lawn grass.
It is generally not possible to irradicate crab grass
completely. If treatment is stopped, the crab grass
will recur. But it is possible to reduce it to a nearly
imperceptible level, and to maintain the lawn with
continued intermittent treatment. The best results
depend upon adjusting the dose of chemical and the
interval between doses to keep the lawn and to kill the
weed. Two different strategies are needed: one to get
rid of the visible crab grass; the other, to maintain a
healthy looking lawn. This healthy looking state is
medically equivalent to remission.
In leukemia chemotherapy the first strategy is to
achieve remission induction, the second remission
maintenance. Modern experience indicates that large
doses of drugs given at intervals of about 14 days,
which first produce marrow depression and then allow
for marrow recovery, give the best induction results and
lower doses at longer intervals provide good maintenance. The toxic effects of the drug, by reducing
the function of the marrow, lead to the same complications: anemia, infection due to lack of granulocytes, and
bleeding due to lack of platelets.
This is the briefest overview of the clinical situation
and the short term clinical objectives. Clearly, one would
like to develop methodologies which will cure the
disease, but in the meantime, the clinician must move
between the two sources of marrow disfunction: overtreatment and undertreatment. He has at his disposal
few objective measures which might be considered as
"control variables."
For example, the concentration of the cellular components in the blood reflect bone marrow function.
Daily blood samples can chart not only the impact of
the chemotherapeutic drugs, but also the likelihood
of complications. Bone marrow biopsy allows the developing blood cell components to be counted and
provides an assay for the encroachment on the marrow
of leukemic cells and the depletion of the marrow by
drug.
Classically, decision procedures based on these data
have been organized into clinical rules of thumb-a
heuristic syntheisis of experience. For example:
"When the platelet count drops to 20,000, there is
danger of bleeding, and we give platelet transfusions."
These rules of thumb are modified by clinical asides:
"The threshold is set a little high on purpose-the
patient probably won't get in trouble until his count
reaches 10,000."
Computer programs have been written which
incorporate such rules of thumb. The best known are
those on electrolyte balance. One might say that these
programs automate the professor in a dogmatic way
and can only be as· successful as his dogma. The same
can be said for programs which set up trees for sequential decision-making. The output of the program is
no greater than the input.
The advantage of a simulation is that one can explore
new territory. If the problem has been formulated in a
mathematically explicit way so that the interaction
among the variables is accounted for, new states of the
system can be explored. If the simulation were perfect,
then the simulation would be equivalent to the essence
of the problem and could serve as a near perfect
advisor. However, in a situation as complicated and as
incompletely understood as the biology of cancer
chemotherapy, we can hardly expect to fulfill this ideal.
What then is the purpose of mathematical modeling,
of simulation, and of the most expensive luxury of allon-line interactive graphic simulation?
As a physician working in this field, I can only
present my experience with the hope that it offers some
generality. To build my models, I have been using
BIOMOD, a Rand-developed software package designed specifically for on-line interactive model building
and simulation. It provides a data tablet, keyboard,
and full graphics capability with a resolution of 1024
by 1024. The system has the capacity of enter models in
mathematical formats so that the computer does the
machine-language programming and can produce,
Clinical Significance of Simulation and Modeling in Leukemia Chemotherapy
compile, and run a new program in a matter of minutes.
The system can keep track of 20 output curves and
display five of these on command. As a simulation
progresses, the evolving curves are presented on the
screen. The scale of the graphic output can be changed
interactively and the displayed variables combined and
redefined. The simulations can contain up to 20 modifiable parameters so that the simulation can be stopped,
parameter values changed, and then allowed to proceed.
In BIOMOD II, the new FORTRAN-based revision
of BIOMOD, we now have the capacity to compare the
output with data curves which can be entered directly
through the tablet.
These capabilities cannot be provided in batch
processing. In short, for a physician this is a very
fancy system. What are the returns? To present these,
I identify four different levels of model building.
1. Parameter Identification. The process of trying to
build a simulation of a medical problem is in and of
itself elucidating. The necessary first step in this exercise, however primitive the quantitative results may be,
is the identification of those parameters which ought to
be considered in the model. In leukemia chemotherapy
we presume that the clinical phenomena can be understood by constructing models which simulate the growth
of cells and developmental characteristics of the blood
cell precursors in the bone marrow. Ultimately our
models must incorporate the following biological
processes:
1. The mechanisms by which blood-forming tissues
sustain themselves.
2. The control mechanisms that regulate the growth
and differentiation of particular blood-cell types.
3. The relationships between the blood as a circulating pool of cells and the other tissue spaces
where blood cells are sequestered.
4. The processes of attrition that lead to the natural
loss of cells from the blood.
5. The ways in which cytotoxic drugs act on
blood-forming tissues (e.g., the sensitivity of
cells in different phases of the cell cycle to
particular drugs).
6. The rates of transport and the detoxification of
particular drugs.
7. Growth characteristics which distinguish leukemic cells from normal cells.
This biological analysis gives focus to the data items
which can be collected in a clinical setting. Some items
are collected to evaluate parameter values. For example,
tritium thymidine studies can evaluate cell kinetic
characteristics. Some are collected to follow the evalua-
1141
tion of certain control parameters, for example, the
platelet count. Given even a simple model of platelet
destruction, it is possible to observe when the count is
falling as a function of the platelet pool only, i.e., when
no platelets are being made. Now the clinical decision
rule can become an anticipatory one: "If the halving
time of platelets is under 36 hours, then prepare to give a
platelet transfusion before the count falls to 10,000."
The result, at the very least, is a data flow chart with
explicit organization and meaning, very much in the
spirit of Larry Weed's automated record. Manual and
now automated flow charts have come into use at the
M. D. Anderson Hospital to monitor the changes in
important variables. These allow a chief of service to
review thirty patients in less than two hours rather than
by an exhausting set of card rounds. Such flow charts
can condense the information both numerically and
graphically. The prototype of the graphic representation
is the temperature chart, long clearly useful. The updatable graphic record of lab value changes over time,
coupled with important therapeutic decisions, provides
a scanable situation report which should come to replace the chaos of the classical record.
2. Functional Organization. A step beyond the assertion that a· certain group of parameters are important
and somehow related is an explicit graph of this relatedness. In the case of the blood and the marrow, this is
illustrated by Diagram 1. Such a block diagram does
not describe the exact relation among the variables.
Rather it sets the stage for their discovery through the
organized analysis of experimental and clin:cal data.
Mathematical models of bone marrow cell kinet ·.cs and
leukemic cell kinetics have been formulated to conform
to the available clinical and experimental data. The
models that we have been building depend for their
Blood-Cell Removal
Blood-Cell Removal
Diagram 1.
/
1142
Spring Joint Computer Conference, 1972
clinical input on the treatment protocols and the
resultant data from the adult leukemia service of the
Department of Developmental Therapeutics, M. D.
Anderson Hospital , University of Texas, Houston,
Texas. Here the greatest pay-off is ins: ght, however
incomplete. For example, we observe clinically that the
platelet count rises two to three days before the granulocyte count, when a heavily treated marrow is undergoing recovery. If the granulocytes are dangerously low,
the platelet count is a good predictor of how long the
count rises two to three days before the granulocyte
count, when a heavily treated marrow is undergoing
recovery. If the granulocytes are dangerously low, the
platelet count is a good predictor of how long the
white cells will be depressed. The relationships which
outline the flux of cell types through the bone marrow
provide us with this qualitative observation. In biological simulations it is important that the system can
handle time delays and other processes which exhibit
historical dependence. For example, the attrition rate of
red cells is proportional to the age of the cells, with an
expected life-span of 120 days. Thus, a marked variation in cell production influences the number of cells
present at a much later date. BIOMOD incorporates
efficient means of handling delays and some kinds of
historical dependence.
3. Teaching Model. These simulations exhibit properties which are thermatically correct. In our case, it is the
typical response of a typical leukemia patient to a
typical course of drug therapy, either for remission
induction or remission maintenance. At this stage
interactive intervention in the evaluation of a simulation becomes useful and of insight. There is a natural
inclination for physicians to extrapolate a little bit
ahead of the available results. Thus the ability to
watch a simulation unfold allows learning, model
correction, and experimentation. At present, we can
only project the clinical impact of such a system.
We observe that it. allows an exploration of therapeutic
alternatives in a very real and believable Socratic
Dialogue. It is also well to observe that it presents a
danger, which might be called the "Las Vegas effect":
There is a fascination with on-line simulations which
can eat up computing time and money, the implication
being that some form of success is just around the
corner.
Our present modeling efforts are aimed primarily at
the teaching model level of sophistication. On the biological level , teaching models test the consistency of our
hypotheses. For example, present models point to a
major discrepancy between our theoretical understanding and our practical results. The models suggested by
the work on the L-1210 leukemia in mice and first
outlined by Skipper have led to considerable clinical
success. In mice the differential kill rate of leukemic cells
over normal cells depend on constant differences in the
cycle time, the growth fraction and the length of the
DNA synthesis phase between the L-1210 cells and the
mouse marrow. The experimental tumor grows faster,
all cells are actively dividing, and are thus more
susceptible to cycle sensitive drugs like cytosine
arabinos·de. Very successful schedules have been set up
assuming similar cell kinetics for human leukemics.
However, in the latter case, Clarkson has demonstrated
that in relapse, with a bone marrow full of leukemic
cells, the leukemic cycle time is longer than that of
normal cells, and the growth fraction smaller. This
points to a new modeling requirement, a new iteration:
the analysis of transient growth states leading to a new
hypothesis for the same output phenomenon.
vVe see that the clinical pay-off from a teaching model
is clinical courage, the willingness to carry through a
plan because, in spite of limitations in the underlying
rationale, the phenomena have become more or less
predictable. Modification must be made for the individual patient using classical clinical judgment.
4. Patient-Specific Model. Whereas the teaching
model provides a skeleton for action, the patientspecific model demands that parameters be modified
to take into account individual differences. If this can
be done successfully, i.e., with clinical verifiability, then
the modeling process becomes a component in the
therapy itself, a medical tool like any other. In cancer
chemotherapy we have not taken this step, and except
for very simple model components, this form of modeling remains largely a vision of the future. However,
we can see it as a vision of the immediate future,
because at least one strategy for implementation already
exists: at a given point in time, the measure of a biological response of the patient can be derived from
the data accumulated over the past course of therapy.
Thus, an initial protocol course of drug has the dual
objective of therapy and a calibration of future therapy.
We envision combining protocol data curves with our
simulations, using subroutines to automate the evaluation of parameter values.
This approach should open up new potentials in
protocol studies of cancer chemotherapeutic drugs.
Present protocols treat patients by a formula which
supposes that each is the average case of the teaching
model. Drug courses are set up so that cons'stency is
achieved by using standard doses. This imposes certain
obvious rigidities which limit success. By using a
model approach, it will be possible to keep the relationship between drugs and patient parameters constant.
Thus we can seek to test the input of drugs on the
Clinical Significance of Simulation and Modeling in Leukemia Chemotherapy
biology of the patient and his disease, rather than
treating him as a block box, susceptible only to statistical
analysis.
REFERENCES
CONCLUSION
Journal of Clinical Investigation Vol 49, p 10 1970
2 G F GRONER R L CLARK R A BERMAN
E C DELAND
1143
1 H L BELEICH
Computer-assisted evaluation of electrolyte and acid-base disorders
The impact of model building and simulation on clinical
medicine is just beginning to be assayable. Many of the
themes which will ultimately be important can be
observed in prototype. Long-term effects will be felt
(1) on the operational organization of medical data, in
the medical record; (2) on the formulation of the
biology of disease; (3) on the methodology of medical
teaching; and (4) on the precision and focus of clinical
research.
BIOMOD: An interactive computer graphics system for modeling
The Rand Corporation R-617-NIH July 1971
3 L L WEED
Medical records, medical education and patient care
The Press of Case Western Reserve University Cleveland
Ohio 1969
4 E GEHAN E J FREIREICH
Department of Developmental Therapeutics M D Anderson
Hospital Houston Texas Personal communication
Graphics software for remote terminals and
their use in radiation treatment planning*
by KARL H. RYDEN and CAROL M. NEWTON
University of California at Los Angeles
Los Angeles, California
INTRODUCTION
mentioned above, many biomedical applications require access to a level of computer support which is most
economically provided on a shared basis. The recent
commercial availability for less than $20,000 of a
terminal (IMLAC) which has many characteristics of
the higher quality graphics systems and which uses
common carrier telephone facilities to communicate
with its host processor, has motivated a substantial investment in systems support at UCLA's Health Sciences
Computing Facility (HSCF).
The setting for this work will be de~cribed, previous
.efforts in graphics and the development of an operating
systems environment appropriate for supporting a
multi-terminal remote graphics system. Subsequent
discussion of a set of interactive graphics programs
that are being developed for radiation treatment planning will illustrate some of the problems that must be
faced when a graphics terminal is to be supported by
low-bandwidth communications. After describing the
related hardware, current and projected software developments will be discussed with reference to the foregoing applications.
Interactive graphics' ability to provide a meaningful
interface to investigators in a variety of applied fields
has been recognized for many years. Nowhere is this
promise greater than in medicine and the life sciences.
Levinthal'sl interactive program for constructing and
displaying complex molecular structures is well-known.
N eurath2 and Frey3 have analyzed chromosome spreads
by delegating to human perception the light-pen dissection of individual chromosomes from overlapping
clusters while leaving subsequent measurements and
final classification to the computer. Cox and Clark's
Programmed Console4 has introduced many radiotherapists to the use of computers in treatment planning. Other applications at this facility 5 and elsewhere6
illustrate the great value of interactive graphics support
in deriving insight from large clinical data bases, exploring complex biological models in the hope of improving treatment strategies, and developing costeffective algorithms or special hardware for patient
monitoring.
That the use of computer graphics in biomedical
and other fields has not developed more rapidly has been
in large part attributable to two factors, the high costs
associated with hardware and development of applications programs, and the general unavailability of
graphics terminals that can operate remotely using
common carrier communications facilities. The latter
capability is not needed when modest computational
requirements enable support by a dedicated small
computer, as in the case of the widely used Programmed
Console. But, as illustrated by other of the projects
PREVIOUS DEVELOPMENT OF GRAPHICS
AND OPERATING SYSTEMS AT HSCF
HSCF is maintained by the National Institutes of
Health to explore and develop computer-implemented
analytical support to research in biology and medicine.
The BMD statistical package programs, TORTOS
operating system, and other developments at this
facility have originated in response to explicit needs of
biomedical researchers.
TORTOS (Terminal Oriented Real Time Operating
System)1 was developed in response to the variety of
needs that prompt biomedical researchers to share access to a large computer. It has been designed to take
* This work is being undertaken at the Health Sciences Computing
Facility, UCLA, sponsored by NIH Special Research Resources
Grant RR-3.
1145
1146
Spring Joint Computer Conference, 1972
advantage of the large high-speed core (2000K bytes)
and computational speed of the 360/91 processor, making these resources available to the facility's users with
as few constraints as possible on the types of programs
accommodated. The terminal user has at his disposal
the full facilities of a standard OS/MVT system as well
as the specialized interactive functions developed here
to aid conversational access to the system (monitor
programs, a convenient file service, input/output interfaces, text editor, a FORTRAN compiler, and a library
of statistical and biomedical applications programs).
The system concurrently supports local and remote
batch operations. Its versatility is exemplified by the
wide range of uses to which it is being put. These include multivariate statistics, computer-aided instruction, management information systems in the Biomedical Library, biological modeling, and several
clinical applications. Although not presently in use, the
system has supported a high speed, real time link to an
SDS 9300 located in UCLA's Brain Research Institute. 5
Since the remote graphics terminals are time-shared as
an extension of the conversational terminal system,
they have access to all facilities developed for the
latter.
For the past five years, we have developed and usetested systems to make the IBM 2250 graphics terminal accessible to biomedical programmers. Interactive
graphics interfaces are intended to be meaningful to the
scientists who use them. A growing number of biologists
and physicians are capable FORTRAN programmers.
Many of this facility's medically or biologically oriented
graphics programs have been developed, by such people,
using our FORTRAN callable subroutines, GRAF
(Graphic Additions to FORTRAN) 8,9 or a similar
interface, PL/OT,lO developed for use with PL/l. These
include5 programs for data analysis and statistics,
teaching, image processing, modeling of cellular and
physiological systems, interactive retrieval, simulation
of disease propagation in adjacent urban environments,
design of coronary-care and obstetrical monitoring systems, and radiation treatment planning.
The GRAF programmer has at his disposal routines
for generating the primitive elements of an image
(blanked and unblanked points, lines, and alphanumeric characters) which are combined into a structured display file whose basic element is called a display
variable (DV). Additional routines are provided for
combining the DV's into display' frames for presentation on the terminal's screen. There are also facilities
for servicing the input devices associated with the
graphics 'terminal (alphanumeric and function keyboards and light-pen) and for character-string
manipulation.
REMOTE GRAPHICS SUPPORT TO
RADIATION TREATMENT PLANNING
Distributed-processing capabilities being developed
for the GRAF subroutines designed for terminals operating over low-bandwidth communications systems are
discussed in later sections. One of the biomedical projects whose needs influence this work, a set of programs
for radiation treatment planning, is described here. Preliminary program development on the IBM 2250 has
been reported. l1
Previous work in radiation treatment planning
Radiation treatment planning is among the earliest
established areas of computer support to medical
practice. Stovall's12 recent bibliography provides access
to most of the formal publications in this field and is
recommended as a basic reference for this section.
The radiotherapist's primary concerns in treatment
planning may be briefly summarized as follows: He has
at his disposal radioactive sources that can be placed
within the body and beams of radiation that can be
directed to it from various angles outside. He seeks a
combination of either, or sometimes both, so that the
resulting spatial distribution of dose delivered throughout the tumor volume is large compared to that delivered to normal tissues he wishes to spare. He also
desires a relatively homogeneous distribution throughout the tumor volume itself. Fear of tumor regrowth in
undertreated areas, "cold spots," dominates the latter
concern, but excessive tissue breakdown in hot spots
also is to be avoided. Either formulas inherited from
research on the interaction of radiation and high-energy
particles with matter, or tabulated empirical measurements of fields surrounding sources or beams in water
or other materials of known composition, enable him to
compute the desired dose distributions. Palpation,
scanning or other techniques are used to estimate the
location and extent of the tumor. Special radiographic
techniques such as tomography help to locate the
boundaries of internal organs to be spared or whose
tissue densities are to be taken into account when the
dose distributions are calculated.
When done by hand, even the simplest calculations,
such as the dose distribution for two or three superimposed beams in a homogeneous unit-density medium,
are extremely tedious and tend to be undertaken infrequently and reluctantly where computer support is not
available. Thus in many places radiation therapy adheres to longstanding conventional prescriptions that
have proven relatively effective for the "average
Graphics Software for Remote Terminals
patient" given the constraint that the risk of notable
side effects in all is to be vanishingly small. Computerassisted treatment planning seeks to individualize
therapy, to help the therapist take every possible advantage of a particular patient's tumor location and
body geometry. It also encourages him to explore new
general treatment strategies which might, even in
places that do not use computers, become part of the
conventional armamentarium of treatment plans.
Two types of computer support for treatment planning are regularly used in a small but noteworthy
number of treatment centers.12 Some excellent batch
programs for external-beam therapy have been tested
by many years of use. Representative of these are
Theodor Sterling's programs (University of Cincinnati
and Washington University, St. Louis), Jack Cunningham's (University of Toronto), and those developed
under the direction of John Laughlin (Memorial
Hospital, New York). The latter are widely available
via remote typewriter terminals. The earliest program
extensively used for implant therapy (placement of
sources within the body) was developed by Robert
Shalek and Marilyn Stovall (M. D. Anderson Cancer
Research Hospital, Houston). Both the three-dimensional complexities of implant therapy and the corrections for tissue inhomogeneities found in the batch
progra~s for external beams require major processors.
The Programmed Console developed by Jerome Cox,
Wesley Clark, and their associates (Washington U niversity, St. Louis) provides clinicians an economical
interactive graphics system for treatment planning. It
permits simple beam superimposition in a homogeneous
body whose outer contour is specified to the computer
by a rho-theta digitizing scribe. Program modifications
are relatively difficult to introduce because of full utilization of the small processor dedicated to the system,
and a number of the capabilities available in batch
programs understandably are not present. However,
the Programmed Console has demonstrated by wide
acceptance the radiotherapist's strong preference for a
hands-on graphics system which provides him rapid
graphical dose distribution feedbacks for a sequence of
conveniently repositioned superimposed beams. Other
small-processor graphics systems have been developed
in the United Kingdom and elsewhere.
Remote graphics radiation treatment planning**
Clearly, one wishes to combine as economically as
possible the advantageb of interactive graphics and
** We wish to acknowledge the very valuable collaboration of
Richard Nelson, City of Hope, Duarte, California.
1147
Figure 1-Treatment prescription display for external beam
therapy: Light-pen tracing of organ contours has been guided by
a transparency taped to the graphics scope. Information has been
entered for the first beam, a Co-60 beam whose center and range
of oscillation is indicated by the angular structure to the left
of center
major processor support, developing programs having
the greatest possible degree of exportability. IBM 2250
programs utilizing GRAF have run on a variety of IBM
360 computers operating under as, and the new version
of GRAF designed for the IMLAC terminal has been
organized and will be documented in a manner that
should facilitate its rewriting for other processors. Immediate exportability is enabled by the IMLAC terminal's low price and its ability to operate over conventional telephone lines.
The first two members of our package of graphics
programs to support radiation treatment planning
have been selected as follows: First, one wishes to take
fullest possible advantage of excellent batch programs
that have been tested by years of use. The initial program in this category is a graphics adaptation of Memorial Hospital's external-beam program. RADCOMP
III, the most recent version of M. D. Anderson's program, and Sterling's program will be next. Although
there is some overlap among these, it is desirable to
offer the different programs that have won various
radiotherapists' confidence. Second, we want to explore
the special advantages of our system. For this we have
chosen a three-dimensional implant application, the
widely used Fletcher-Suit intracavitary method for
treating cancer of the uterus.
Several capabilities are common to all programs:
input of a brief information record for each patient,
routines for providing a proper scale and assessing its
1148
Spring Joint Computer Conference, 1972
2a
2c
2b
2d
Figure 2-Portion of the interactive specification of afterloader location in Fletcher-Suit treatment of uterine cancer: (a) Important
points on the afterloaders having been located on an anterior-posterior (A-P) view of the pelvis, one of the known distances in 3-dimensional space is being requested. (b) An inconsistency being noted between that distance and previous specifications, the user is given
the choice of relaxing tolerances or correcting one of the inputs. (c) The computer finally accepts the revisions and asks for the one item
of information now required to fully determine tandem location. (d) The sequence of linear sources "loaded" into the tandem in a previous
frame is now displayed as it should appear on the X-ray. If this visual. check is satisfactory, the user may select from several levels of
redundancy in specifying information from a lateral view
uniformity throughout the CRT display whenever
graphical information is to be specified by light-pen,
and contour plotting routines for displaying dose
distributions.
1. The external-beam program. When users wish to
take advantage of the Memorial Hospital program'&
capability to correct for tissue inhomogeneities, they
must specify contours and densities for the various
organs. They may do so by taping a transparent drawing over the CRT face, using the light-pen for a point-
Graphics Software for Remote Terminals
to-point specification of each contour. (A continuous
light-pen tracking capability is available on the IMLAC
and on some other IBM 2250 models.) It is easy to
revise or restart contours. The expense of additional
input scribing equipment is avoided. This is much
simpler to execute and easier to verify visually than
providing the numerical contour specifications required
for the batch program. Further burdens of coding input
information are relieved as the user next responds to a
conversational program that requests information concerning the beams to be used and how they are to be
directed (i.e., from a given angle, rotating about a given
point, or oscillating within specified angular limits).
Brief notations for each beam are added to the bodycontour diagram (see Figure 1). Dose-distribution in
the plane containing the beams then is displayed. This
may be filed for later comparison with other treatment
plans.
2. The intracavitary program for uterine cancer. In
afterloading approaches, hollow instruments (the afterloaders) are placed securely at various locations in the
tumor area. Subsequent introduction or removal of
radioactive sources within the lumens of the afterloaders may therefore be accomplished without further
discomfort to the patient or disturbance of the tumorsource geometry. The Fletcher-Suit afterloading system
for uterine cancer comprises a long curved tube which
is introduced into the uterine cavity (the tandem)
flanked laterally by two source holders (the colpostats)
externally adjacent to the uterus. Each of the latter
can hold a single radioactive source, and a sequence of
sources can be spaced along the central axis of the
tandem. Frontal (A-P) and lateral radiographs are
used to locate the afterloaders.
A conversational program facilitates light-pen specifications of afterloader locations, taking full advantage of
their known geometries. The user may elect tradeoffs
between rapidity of input and the security of checks
enabled by obtaining redundant geometrical information (see Figure 2). He also may control economy vs.
quality of computation by such means as specifying the
length of segments to be used to approximate linear
radiation sources of uniform density. For instance, an
economical initial exploration which approximates each
linear source by three segments can be followed by a
computation of higher quality which assumes a segmentation of nine or ten. Dose-distribution displays
may be requested for any A-P, lateral, or transverse
plane (see Figure 3). Inventories are maintained for
the afterloaders and sources.
Arrangements are being made for live demonstration
of these programs on the IMLAC terminal, in addition
to motion-picture illustrations of their use.
1149
Figure 3-Isodose plot for uterine treatment: Dose distributions
may be requested in any A-P, lateral, or transverse plane. This
display may be transmitted line-by-line as it is being computed.
An occasional segment may be missed by the economical
algorithms used here
Possible implications of graphics in the acceptance of
treatment-optimization programs
Linear programming13 and other approaches14 •15 have
been suggested for optimizing spatial dose-distributions,
and one14 is being used regularly in a small number of
radiotherapy centers in Great Britain. Graphical
demonstrations tend to be more convincing than mathematical proofs to the average clinician, and they help
him to bring his experience to bear on criticizing the
outcomes of using various criteria for optimality. One
therefore anticipates that the present conjunction of an
interactive graphics terminal with a processor capable
of performing optimization calculations will encourage
serious investigation, improvement, and perhaps eventual acceptance of more optimization procedures in
radiotherapy.
Implementation
systems
over
low-bandwidth
communications
Transmission over conventional telephone lines poses
serious response-time problems for the more complex
graphical displays of organ contours and dose-distribution. Subsequent recall for display purposes rather than
initial point-to-point specification is of main concern in
the organ-contour display. However, methods currently
1150
I
Spring Joint Computer Conference, 1972
,------
- - -
tv\INI- PROC""'50i<.
--------,
'(-t>E.FL~llC>,.J
SE~/~ SYNGJ.lIlONc.>V.s.
T;.n-l!.(#=ACE
',-
----------,
--
I
1'2
M
B
L
p
A.
I,
I
,
L ________________ _
I
12
I
1'2
------------------~
Figure 4-IMLAC PDS-l system block diagram (redrawn with permission of the IMLAC Corporation) indicating the dual processor
nature of the systems design
being explored to expedite transmission of a retrieved
display may simplify the initial input as well. Advantages of the interactive approaches that are possible
for anatomical specifications or the input of graphical
field-distribution data for sources and beams cannot be
realized for the computed dose-distributions, since the
latter are initiated at the host processor. Research on
these problems in graphical representation is being
pursued initially on the IBM 2250 while the remote
terminal version of G RAF is being developed and tested
on the IMLAC. However, both efforts assume a distribution of processing between the terminal and host
computer which has not been feasible on the IBM
2250. This work is described in a later section, and
additional presentations will be made at the time of the
conference.
REMOTE GRAPHICS HARDWARE
The remote graphics system consists of three major
hardware components: the host processor, a 360/91
computer with 2 million bytes of high-speed core and
672 million bytes of secondary direct-access storage; the
graphics terminal, a mini-computer (PDS-1) manufactured by the IMLAC Corporation; and the data
link between the two processors. While the typical
graphics program does not normally require the resources of a computer like the 360/91, it does permit
the computer to simultaneously service far more
graphics terminals than could be handled by a less
powerful machine. In addition, the occasional heavy
demands for arithmetic processing can be absorbed
without severely impacting other concurrent activities,
Graphics Software for Remote Terminals
for as at most computer centers, graphics is only one
aspect of the computer's total load at HSCF.
The development of a remote graphics terminal is
not a new idea, nor is using a small computer to overcome the restrictions of low-bandwidth data links, as
has been done elsewhere. I6- Is There are also available
today at least five different storage-tube terminals
which have a serial-communications interface that permits them to operate from a remote location without a
mini-computer. Storage tubes do not need local refresh
memories and their display capacity is limited only by
the resolution of the screen. By contrast, the display
capacity of refreshable tubes is limited by the size of the
local refresh memory and the drawing speed (refresh
cycle) of the deflection system. However, the storagetube terminal's limited capacity to selectively erase one
component of a display from the screen requires compromises between response time and the ideal presentation of information to be displayed. In order to modify
one component, the screen must be erased and the
entire modified display retransmitted to the terminal.
In one storage-tube system it is possible to erase information from the screen by retransmitting the orders
which created the display, but this also erases other
components of the display frame which may have intersected the portion which was erased. Lack of a selective
erase can be overcome to some extent by the use of a
local computer which can regenerate the image; this,
however, nullifies much of the cost advantage which
the storage-tube terminal otherwise enjoys. The
GRAPHIC-II system I6 developed by Bell Telephone
Laboratories is similar in many ways to ours. There
are, however, some major differences in approaches to
optimizing the use of the data link and to distributing
tasks between the remote and host processors. The
PDS-1 is one fourth the cost of the PDP-9 system used
in GRAPHIC-II. In part, this reduction in cost is a
result of technological advancement; however, much of
it is due to the fact that the PDS-1 was designed specifically as a low-cost display computer.
The IMLAC PDS-1 (see Figure 4) computer is a
dual processor machine with each processor sharing the
same memory. The main processor executes an instruction set which is typical of most small computers (ADD,
SUBTRACT,
BRANCHING,
LOGICAL
and
INPUT/OUTPUT operations) while the display processor, which is controlled by the main processor, executes a set of display instructions that generate the
image on the CRT (see Figure 5). The display image
is drawn using incremental vectors; each incremental
order (8 bits) can move the CRT beam in one of 32
directions for a distance of 0-9 raster units (a raster
unit is 0.011 inches). Line segments, characters and
1151
other graphics figures are generated by display subroutines composed of incremental orders. An eight-level
hardware push-down is provided for nesting display
subroutines.
The principal disadvantage of the incremental drawing technique used by the IMLAC is the slightly jagged
appearance of lines or curves that results from the 32direction restriction on elements composing them. This
can be a serious problem if high-quality images are
required. For instance, depth cues of the perspective
transformation might be blunted when three-dimensional images are being generated. However, in the
majority of medical applications, this is not a serious
Figure 5-IMLAC graphics display terminal: Light pen and
optional programmers console are shown to the left of the
keyboard and display
problem and the economies that result from the use
of incremental drawing seem to outweigh the
disadvantages.
The choice of a data link between the graphics terminal and the host processor was dictated by universal
availability, low cost of modems and interfaces, and
speed, in that order of importance. We chose to use a
serial-synchronous communications format employing
switch network telephone facilities at 2000 bps (WE201A type modems). However, while meeting our requirements of availability and low cost, the transmission
speed represents what can only be considered a minimal level. A major component of the programming
support is devoted to overcoming deficiencies of the
data link.
1152
Spring Joint Computer Conference, 1972
REMOTE GRAPHICS SOFTWARE
Programming systems support for the remote
graphics terminals consists of a control program for the
terminal computer, the host processor control program,
and the applications programming "language." The
latter two components are 360/91 programs while the
first executes in the PDS-l computer. Application programs are written in FORTRAN using a collection of
subroutines called GRAF9,lo which were originally designed for use with the IBM 2250 and whose external
format has been preserved in the remote graphics
implementation. Thus, use can be made of the large
number of programs written using GRAF at VCLA
and elsewhere over the past four years. Although an
emulation of the 2250 would have provided access to
more existing programs, it would have compromised
effective use of the data communications facilities.
of that information which is most likely to be used
next.
V nless the remote computer is augmented by a
peripheral storage device, the static display data which
can be retained generally will not exceed two or three
display frames. The added cost of direct-access storage
caused us to prefer extending the storage capacity of
the standard terminal by formulating a procedure
which retains those inactive segments of the terminal's
display buffer which are most likely to be reused when
it becomes necessary to overlay some segment in order
to accommodate a new segment. This procedure is
primarily a storage management technique and has
been augmented by look-ahead facilities which are designed to. anticipate the requirements for new display
segments and transfer them during intervals when the
data link would otherwise be idle.
New GRA F storage-management facilities
Strategies for overcoming the limitations of low-bandwidth
communications systems
Transmission over conventional telephone lines poses
serious response problems for the more complex displays (see Figures 1 and 3). In Figure 1, the organ
contour display, the main concern is with the subsequent recall of the image rather than its initial pointto-point specification whereas in displays like Figure 2,
response is poor because the terminal fails to react
quickly to simple interactions. The logical and arithmetic capabilities of the remote processor offer several
means of improving response. Data compression can increase the information density by removing extraneous
bits from the graphic data structure or bits whose
meaning is implicit from the context in which they are
used. Another method is to organize the graphics data
so that inactive static segments of the display are
saved and recalled into the active display by the transmission of a single command. Labels, grid lines, indexes,
and explanatory text are examples of data which are
fixed throughout the course of the typical graphics
program and need only be transmitted once when
sufficient remote processor storage is available. Response time is determined by the variable display data.
Approaches that decrease the number of bits transmitted to specify graphical or other data will be discussed in the next section. The portions of G RAF initially developed for remote IMLAC terminals have
emphasized storage-management and look-ahead capabilities that facilitate terminal response by avoiding
retransmission of graphical information that may be
displayed repeatedly and by anticipating transmission
Implementation of the storage management and
look-ahead facilities is largely unknown to the GRAF
programmer although he has some control over the
transmission of graphics data to the remote processor.
As in the IBM 2250 version of G RAF, the basic
element of the graphics data structure is the display
variable (DV), which is composed of the primitive
elements that generate the display. The DV is formulated in the host processor by graphics subroutine calls,
for subsequent transfer to the display buffer, that portion of the terminal's memory which services plotting.
The display buffer of the remote processor is divided
into primary and secondary display lists. The secondary
display list entries correspond to a subset of the DV's
in the host processor. The primary list consists of pointers (display subroutine jump instructions) to each
entry in the secondary list which is currently being
displayed on the CRT screen. DV's are added or removed from the screen by adding or removing appropriate pointers in the primary list. A display frame is
composed of one or more DV's which may contain
their own screen coordinates, or the position which the
DV occupies may be determined by positioning orders
in a DV which "calls" it. The DV can be considered a
display subroutine, and in the instance of a relative
DV (one which does not contain absolute positioning
orders), only one copy of the DV is stored within the
remote graphics processor.
The best response characteristics will be obtained
when each frame is segmented into DV's such that the
static information is separated from the variable data,
and when display components which are used re-
Graphics Software for Remote Terminals
peatedly are each declared to be unique DV's rather
than combined into a few DV's. Thus, the user can
improve response characteristics not only by partitioning each display frame into fixed-format and variable
DV's but also by further subdividing the fixed-format
portions to take advantage of relative DV's that are to
be used repeatedly. For example, in a single session
with the computer, the radiotherapist probably will
explore up to three or four treatment approaches for
each of several patients. There will be delays when
DV's guiding conversational input are initially called,
but use of the program thereafter would, for the most
part, flow as freely as on the IBM 2250. The saving is
especially notable for the grids supplied to effect input
of graphical data. One coarse grid covers the entire
screen, but for more precise description of curves a
finer grid patch is moved to desired locations on the
large grid. Treating the patch as a relative DV, only the
transmission of two coordinates is required to reposition
it. Because of frequent use, DV's representing both
types of grid would have a high probability of remaining on the secondary list of the terminal's display
buffer.
All of the decision making and tables for managing
the remote processor's display buffer are provided by
the host processor. The graphics processor's storage
management functions are limited to unpacking the
transmission records, relocating addresses, and moving
entries within the primary and secondary lists. When
a new DV is to be transmitted to the remote terminal,
its storage requirements are determined by the host
processor and it is assigned a relative location within
the display buffer. If sufficient free space is available
either in one contiguous block or in multiple free blocks,
the DV is placed in this region. When a single region is
not available, commands to compact the display buffer
are transferred ahead of the graphics data. Normally, all
free space will be in one continguous block, since the
host processor's storage management routines use idle
time on the data link to transfer the commands necessary to compact the secondary display list. Upon receiving the DV, the remote processor unpacks the data
and relocates all relative addressing information into
absolute display buffer addresses. When members of
secondary display lists are moved from one location to
another to compact the list, all absolute addressing information in both lists is again relocated.
When insufficient free space exists for a new DV
that is to be transferred to the terminal, the required
space must be created by some combination of using
free space and removing secondary display list entries.
The criteria used for choosing which blocks(s) in the
secondary list should be deleted attempt to reduce the
1153
chance of deleting DV's which could be used in a subsequent display while also minimizing response time,
since further action by the terminal user is suspended
until a successful transfer enables the DV to become
part of the active display. Three decision levels are used:
( 1) The system first tries to find a contiguous set of
free or inactive blocks within the secondary display
list. The inactive DV's which are chosen are those
with the lowest probability that they will be reused.
The assignment of these probabilities is described later.
Contiguous sets are sought in order to avoid an additional pause to transmit commands required to compact
the secondary display list. (2) When a contiguous set
has not been found, the free blocks and the inactive
DV's with lowest reuse probabilities are collected into
a list, weights assigned, and a good set chosen to be
deleted. The secondary display list subsequently must be
compacted. The weight assigned to each DV is a function of it~ size, its position in the secondary display list
(which determines the delay necessary to compact the
list if this DV is deleted), and the reuse probability.
The optimum set, that which provides enough space
while minimizing the summed weights of DV's to be
removed, can only be chosen while examining all possible combinations. Since this would burden the host
processor, an alternative, approximate stepwise procedure is used. First, the list is sorted by weights and
partitioned into two groups. Initially, the first group
will contain the first n elements of the list whose total
size is sufficient. The procedure then compares the sum
of the weights of each pair of elements in the first group
with the weight of an element of the second group. An
element in the second group replaces the pair in the
first when its weight is less and its size is greater than
or equal to the corresponding pair in the first group.
Similarly, the process is repeated by comparing combinations of three elements in the first group with
pairs and single elements of the second group. We have
found that continuing the search beyond three combinations does not yield a significant improvement. (3) If a
check made prior to pursuing (1) and (2) reveals that
the total free space and that occupied by inactive DV's
is less than the space required, the operator is permitted
to delete DV's from the active display by using the
light-pen. This final means of obtaining the required
space in the display buffer is provided primarily for
program debugging, permitting the program to continue when it otherwise would have been aborted.
Look-ahead facilities
The communications link between the graphics terminal and the host processor is normally idle for several
1154
Spring Joint Computer Conference, 1972
seconds between each interaction. During this interval,
the user is determining his next step. This suggests
that if the host processor has a reasonable probability
of predicting the user's choice, the effective transmission speed of the data link could be increased by using
the idle time to transmit the graphics data most likely
required for the next display frame. The display program can be represented as a discrete Markov chain
whose states are all the possible display frames which
the program may generate. In GRAF, the states are
defined by the DV's which generate the display frame.
The transition from one state to the next occurs at each
interaction (light-pen detection, keyboard entry, or
terminal processor interrupt) .
To predict which state is most likely to occur next,
we form a transition probability matrix
Pijn,n+l=Pr{Xn+l=j I Xn=i}
Pijn,n+l is the probability that j will be the display
program's next state given that i is the current state.
Each time the program enters a waiting state for
some form of remote processor interrupt, the transition
probabilities of the current state are examined and the
DV's corresponding to the most probably next state of
the program are transferred to the remote processor to
the extent permitted by time and by space in the display buffer. Not all of the DV's corresponding to the
next state can be transferred in advance since some
may not be defined until after the operator interaction
is completed and others, although fully specified, may
not have been generated in advance.
The state matrices are of two types: When the program is being executed for the first time, no information
about the transition probabilities exists. All probabilities are assumed equal unless the programmer specifies
otherwise. The second type of state matrix represents
a typical use profile for the program which has been
accumulated through many executions of the program.
Even when an extensive use profiles exists, considerable
improvements in the predictions can be made by dynamically updating the transition matrix so that it will
more accurately predict the current use of the program.
Provisions are made for each user to save and update
his own transition matrix to tailor the program's response to his own needs. For example, new users of the
intracavitary radiotherapy program will tend to seek
more explanatory material and to elect more conservative approaches for locating the afterloaders. They will
tend initially to use the transition matrix provided by
the system, changing to their own when familiarity
with the program motivates expedition of shortcuts
and other preferred routings through the program.
Thus, the system's matrix for each program will tend
to remain oriented toward its most likely client, the
new user.
Data-compression techniques
Processing capabilities of the graphics terminal enable unpacking of information transmitted from the
host processor in a variety of condensed formats. While
computations required for condensation can be complex without taxing a fast host machine, unpacking
must be efficient enough to provide the desired advantage over unpacked transmission formats. The
radiotherapy programs have directed attention to the
problem of compacting information required for specifying graphical displays. Investigations proceeding on
the 360/91 and 2250 while 'basic GRAF software is
being tested are mindful of the two types of local
graphics interfaces provided by the remote terminal:
(1) specialized function generators such as those supporting curvilinear display generators, the light-pen
tracking routine, routines which can translate, scale,
and window display variables; and (2) routines which
are written in the IMLAC PDS-l machine code by
applications programmers. The routines for both types
of interface are assembled by the host processor and
stored in a library to be dynamically loaded into the
remote processor as they are required by the graphics
programs. For purposes of memory management, the
relocatable PDS-l programs are considered to be display variables. Remote processor programs can extend
the capability of the entire remote graphics terminal
system, particularly where display dynamics are
involved.
More general, conventional approaches to parameterized representation of graphical data are being explored initially, e.g., conic sections19 and families of exponential curves,20 as alternatives to piecewise representation by straight-line segments. The combined
processing capabilities of this system permit additional
approaches to be explored without the immediate constraint that they be implementable in hardware. For
instance, for specification of organ contours or the distribution of fields around radioactive sources or X-ray
beams, the approximation of large segments by French
curves visually fitted at the terminal is being
investigated.
Graphical information originating at the host processor, such as the dose distributions calculated for a given
patient, cannot benefit initially from interactive approaches such as the latter. However, since considerable
computation is required for each point in the dosedistribution field, procedures that transmit graphical
Graphics Software for Remote Terminals
(a) IMLAC:
1155
(b) IBM 2250
Figure 6-Polar transform with different expansion moduli: Among approaches being explored to compact patient anatomical information
for subsequent rapid transmission is representation of an individual's configuration by transforms mapping it into standard anatomical
cross-sections. The outer contour on the left (non-anatomical) figure is being mapped into that shown on the right by expansions around
a central point that assume different "expandability" of various domains. In this case, the outer (fat) layer is assumed to vary more
than other "tissues."
information as the doses are being calculated alleviate
much of the transmission delay. They have the additional advantage of enabling the radiotherapist to
economize by terminating computations when the information displayed suffices for decision making. The
contours shown in Figure 3 were generated line by line.
The line at which computations are to commence may
be indicated by the user. Another routine is available
which computes and displays contour by contour.
An interest in transforms of related sets of graphical
data is aroused by the awareness that a number of
radiotherapists estimate internal-organ location by
adjusting standard anatomical atlas cross-sections to
measurements of the patient's external contour. We
are exploring an improved version of this approach
which allows different size-preserving factors for various
tissues to be observed while transforms are being applied
(see Figure 6). The objective is to reconstruct an adequate display of an individual's anatomical crosssection, using processing capabilities of the graphics
terminal, locally stored standard cross-sections, and a
small number of parameters characterizing a previously
determined resultant transform. The latter would be
obtained initially at the graphics terminal, as the radiotherapist seeks by a number of transforms on the entire
cross-section or on individual organs to achieve an adequate correspondence between a transformed atlas
cross-section and that determined for the patient by
tomography or other methods.
By storage-management and look-ahead facilities,
we have sought to provide users the most economical
terminal possible. However, should radiotherapists
wish to add a disk at the terminal for more complete
anatomical atlas storage or capacity for additional
stand-alone applications on the IMLAC, it would be
worthwhile to investigate transferring to the terminal
processor a stand-alone capability for many conversational portions of anatomical and treatment specification, to reduce subsequent communications charges.
These program developments would be expedited by a
360/91 FORTRAN compiler that generates object code
for the IMLAC.
Performance measurements
At this writing, we have not had enough experience
with user programs to give any quantitative assessment
of the remote graphics terminal's performance as compared to the 2250 terminal. There are areas where
further development is already indicated. Decreasing
response time by facilitating programmer's access to
the remote computer through a compiler or by the
addition of hardware components are areas to which
we are now turning our attention.
1156
Spring Joint Computer Conference, 1972
In order to evaluate performance of the system and
to quantitatively measure the effect of changes in the
hardware and software, an extensive data collecting
facility has been built into the programming packages.
The programs continually log information regarding
response time, data link utilization, storage utilization,
display variable characteristics and other parameters
which are believed to relate to system performance.
This information is printed for the programmer at the
end of each graphics job and is accumulated in a historical file for later analysis. Being provided with performance information regarding the execution of his
graphics program, the user is likely to take an interest
in those aspects of the program which affect its performance and to take the necessary steps to improve
his program. The data gathering routines of the graphics
system can also be instructed by an execution time
parameter to collect a complete profile of a graphics
job to the extent that its execution can be reproduced
by using the profile as an input source instead of the
terminal. This is particularly useful in debugging the
system by providing a reproducible set of test jobs
which can be run over and over until an error is found
and corrected or the desired performance improvements have been made.
REFERENCES
1 C LEVINTHAL
Molecular model building by computer
Scientific American Vol 214 No 6 pp 42-52 1969
2 P W NEURATH B L BABLOUZIAN
T H WARMS et al
Human chromosome analysis by computer-An optical pattern
recognition problem
Ann N Y Acad Sci Vol 128 pp 1013-1028 1966
3 H S FREY
A n interactive program for chromosome analysis
Computers and Biomedical Research Vol 2 pp 274-290 1969
4 W F HOLMES
External beam treatment-planning with the programmed console
Radiology Vol 94 No 2 pp 391-400 1970
5 W J DIXON
Annual report 1968-1969
Health Sciences Computing Facility University of California
Los Angeles Appendix Band pp 83-85
6 T L LINCOLN
The clinical significance of simulation and modeling in
leukemia chemotherapy
Proceedings of the Spring Joint Computer Conference 1972
In Press
7 P M BRITT W J DIXON R I JENNRICH
Time-sharing and interactive statistics
Bull lSI Proceedings of the 37-th Session pp 191-207 1969
8 User's guide for GRAF: Graphics additions to FORTRAN
Health Sciences Computing Facility University of California
Los Angeles 1968
9 A HURWITZ J P CITRON J B YEATON
GRAF: Graphic additions to FORTRAN
Proceedings of the Spring Joint Computer Conference Vol
30 pp 553-557 1967
10 R C UZGALIS H FREY
PL/OT, Graphics Subroutines for PL/l
Health Sciences Computing Facility University of
California Los Angeles 1969
11 C M NEWTON
Remote graphics radiotherapy treatment planning
Proceedings USPHS-Mt. Sinai Afterloading Conference
New York May 6-8 1971 In Press
12 M STOVALL
Bibliography of computers in radiation therapy
Proceedings of the Third International Conference on
Computers in Radiation Therapy Glasgow September 1970
Special Edition British Journal of Radiology In Press
13 G K BAHR J G KEREIAKES H HORWITZ
R FINNEY J GALVIN K GOODE
The method of linear programming applied to radiation
treatment planning
Radiology Vol 91 pp 686-697 1968
14 C SHOPE J S ORR
Computer optimization of 4-Mev treatment planning
Phys Med BioI Vol 10 pp 365-373 1965
15 C M NEWTON
What next in radiation treatment optimization?
Proceedings of the Third International Conference on
Computers in Radiation Therapy Glasgow September 1970
Special Edition British Journal of Radiology In Press
16 C CHRISTENSEN E N PINSON
Multi-function graphics for a large computer system
Proceedings of the Fall Joint Computer Conference Vol 31
pp 697-711 1967
17 I W COTTON F S GREATOREX
Data structures and techniques for remote computer graphics
Proceedings of the Fall Joint Computer Conference Vol 33
pp 533-544 1968
18 M D RAPKIN 0 M ABU-GHEIDA
Stand-alone/remote graphic system
Proceedings of the Fall Joint Computer Conference Vol 33
pp 731-746 1968
19 L G ROBERTS
Conic display generator using multiplying digital-analog
converters
IEEE Transactions on Electronic Computers Vol EC-16
No 3 pp 369-370 1967
20 M L DERTOUZOS
Phaseplot: an online graphical display technique
IEEE Transactions on Electronic Computers Vol EC-16
No 2 pp 203-209 1967
Automated information-handling in pharmacology research
by WILLIAM F. RAUB
National Institute of Health
Bethesda, Maryland
Pharmacology in its broadest sense involves the
multitude of interrelationships between chemical substances and the function of living systems. Since these
interrelationships manifest themselves at all levels of
physiological organization from the individual enzyme
to the intact mammal, research in this area involves
concepts and techniques from almost every biomedical
discipline. Detailed understanding of the mechanisms
of drug action is the best prescription for the discovery
of new therapeutic agents and the rational use of old
ones.
The breadth and complexity of the domain of pharmacological inquiry interact to produce a class of information-handling problems as formidable and enticing
as any that can be found in the medical area. In recognition of this, the National Institutes of Health (NIH),
through its Chemical/Biological Information-Handling
(CBIH) Program, is attempting to accelerate the acquisition of new pharmacological knowledge by designing and developing computer-based research tools
especially for scientists in this discipline. Working
through a tightly interconnected set of contracts with
universities and colleges, nonprofit research institutes,
profit-making organizations, and Government agencies,
the CBIH Program seeks to blend the most advanced
information science methods into a computer system
which can be an almost indispensable logistical and
cognitive aid to these investigators. This paper characterizes the current status of these efforts.
etc.), predict the effect, if any, on the behavior
of the biological system; and
(2) given a desired behavioral end state for a given
biological system, predict the specific chemical
substance (s) and parameters of administration
which can bring about that end state.
Only when such a theory is in hand will it be possible
to make an accurate assessment of the therapeutic
efficacy of a new substance without extensive testing in
animals and human subjects. Only then will one be
able to assume with confidence that a given drug will
not have adverse side effects in a particular clinical
context.
As is painfully obvious to both pharmacologists and
laymen alike, an all-encompassing theory of drug action
is nowhere in sight. Present understanding of drug action still is based almost exclusively upon empirical
observation. Only a figurative handful of investigators
have made extensive attempts to formalize their
knowledge through mathematical modelling and the
like. Natural language still serves as the predominant
medium for the expression and communication of concepts. And textbooks and review articles constitute
almost the entire body of organized knowledge.
N or has information science and technology done
much to aid in the development of a broad-based
theory of drug action. On the contrary, even the most
sophisticated document reference and archival management systems are only marginally useful in helping
pharmacologists cope with the plethora of literature
which is relevant to their interests. Moreover, outside
of a few parochial areas, there are essentially no truly
effective data retrieval (as opposed to document retrieval) services. And easy-to-use tools for building,
exercising, managing, and communicating models of
drug action are much more nearly fantasy than they
are routine offerings of the typical general-purpose
computer center.
Thus, the pharmacological information-handling
THE PHARMACOLOGICAL
INFORMATION-HANDLING "PROBLEM"
The ultimate goal of pharmacology is a well-validated
theory having the following two properties:
(1) given the identity of a chemical substance and
the parameters of its administration to a given
living organism (e.g., the dose, route, course,
1157
1158
Spring Joint Computer Conference, 1972
Automatic data
acquisition;
Compute r-controlled
experimental procedu res
Management of
personal fi les;
User-controlled
perusal, analysis,
and commu nication
of data
Archival management;
Document reference
capability; selective
dissemination and
retrospective search
services
Figure i-The PROPHET system in context
"problem" can be stated as a series of interrelated
questions:
(1) Can one design computer-based informationhandling tools which encourage formalistic
rather than empirical approaches to the study of
molecular structure/biological activity relationships?
(2) Can one use these tools to facilitate the interchange of data, procedures, and models among
geographically and disciplinarily disjoint scientists whose work is relevant to the understanding
of drug action?
(3) Can one use mathematical models and other
formalisms to enhance traditional methods for
the storage and retrieval of pharmacological
information?
These questions circumscribe the domain of the CBIH
Program. Some very preliminary answers are included
in later sections of this discussion.
RELATED WORK
The interests of the CBIH Program in attacking the
pharmacological information-handling "problem" intersect in one way or another with a large number of
activities in the information science area, for the rubric
"computers in pharmacology" covers a wealth of topics.
As depicted in Figure 1, the CBIH Program in its
work on the PROPHET System and related projects
focuses on only a small-albejt crucial-subset of the
potentially valuable applications for automated information-handling methods. Most notable is the absence of concern with (a) data acquisition and process
control for experimental laboratory and clinical care
settings and (b) automated archival management
methods and other uses of computers in libraries. Since
these topics are only of marginal interest to the CBIH
Program (though obviously of utmost importance
from other perspectives), they are not treated further
in this account.
Turning attention specifically to the topjc of personalized pharmacological data-management 'and analysis
(i.e., the middle portion of the spectrum shown in
Figure 1), there are two major classes of activity upon
which the CBIH Program draws. The first is the collection of efforts concerned with chemical informationhandling, especially those involving highly dynamic
man/ machine interaction about molecular structure
data. The second is the collection of efforts concerned
with general-purpose data management, especially
those systems which offer the user great flexibility in
the definition of file structure and which are designed to
operate in a time-sharing environment.
Chemical information
The use of computers in handling chemical data
(primarily structural information) is widespread and
dates back to the mid-1950's. The need to deal most
effectively with large numbers of organic molecules (in
some cases hundreds of thousands) provides the continuing strong motivation; the fact that structural
data is readily codified for machine manipulation makes
this aspect of chemical information processing the most
nearly tractable-and, hence, the most popular. Among
the organizations who have made significant contributions are the Chemical Abstracts Services, the Walter
Reed Army Medical Center, the Institute for Science
Information, and a number of leading chemical and
pharmaceutical manufacturers. The bulk of the efforts
in this field are reviewed in two publications of the
National Academy of Sciences-National Research
Council. 1 ,2
The subject of greatest concern in the chemical information field over the years has been the selection of
an appropriate notation for encoding molecular topology. Almost every group has struggled with the choice
between connectivity tables and linear ciphers. The
connectivity tables have the advantage of being direct
atom-by-atom/bond-by-bond descriptions of molecules
and, hence, they allow one to perform searches for essentially any subgraph without the need for predetermined indices. Connectivity tables invariably make
heavy demands upon storage, however, and, in the case
of even medium-sized files (e.g., 10,000 structure records) the extensive processing time required for many
substructure searches renders them impractical for
production use without some fairly rigorous preliminary
Automated Information-Handling
screening of the queries to the file. By contrast, linear
notations are compact in terms of internal representation, are processed with relative ease and economy, and,
with some perseverance, can be mastered by the scientist for direct use as a form of nomenclature. But linear
notations do not allow readily for the full range of
possible substructure queries, and this shortcoming has
proved serious in some cases.
Obviously, the strengths and weaknesses of these two
basic approaches are highly context-dependent, and
there is not likely to be a move toward consensus until
additional advances in retrieval methods (e.g., in hashcoding strategies) are made. Moreover, since there are
many possible compromises (e.g., the linear notations
are useful in substructure searching as screening terms
preliminary to full-scale topological tracing), the study
of search and retrieval methods for chemical information is almost certain to be an active area for the foreseeable future. And since chemical structure data is of
direct concern to pharmacologists, the CBIH Program
will attempt to insure that the pertinent results of the
many efforts involving new chemical informationhandling methods will be available for their use.
Another major problem area in the chemical information field is the man/machine interface, and in this case
CBIH Porgram contractors have played a rather substantial role. Especially noteworthy are (a) the efforts
of Corey and Wipke3 on easy input of two-dimensional
chemical graphs via computer-controlled stylus and
tablet and (b) the efforts of Levinthal and Katz 4 on the
computer-driven display and manipulation of threedimensional molecular models. Both of these groups
have amply demonstrated the viability of these man/
machine methods in the context of medically relevant
research-Corey and Wipke in the area of artificially
intelligent systems for the design of organic chemical
syntheses and Levinthal and Katz in the area of macromolecule structure and function. Moreover, as described
further below, a number of the results of these groups
have been integrated by yet a third CBIH Program
contractor (Bolt Beranek and Newman Inc.) into a
powerful computer graphics front end for a pharmacological information-handling system called
PROPHET.
General-purpose data management
In parallel with the work on chemical informationhandling via computer, the concept of a general-purpose
data management system has received considerable
attention. In brief, many groups have recognized the
need for a software system which can be used to manage
1159
a wide range of files flexibly and efficiently and with
little, if any, requirement for programming on the part
of the user. Among the most active organizations are
System Development Corporation, Computer Corporation of America, and many of the major equipment
vendors. A somewhat dated but still useful characterization of work in this area is given in the review article
of Minker and Sable. 5
From the CBIH Program perspective, the most interesting data management systems are those designed
to operate in a time-sharing environment. Since personalized information-handling tools for pharmacologists almost inevitably will need be highly interactive
if they are to be effective, the successes and shortcomings of the many ongoing efforts involving timeshared data management systems will do much to
influence how this technology is applied in support of
drug research. For example, the various compromises
involving the degree of file inversion (in part, a trade-off
between the speed of file update and the speed of
retrieval) and the degree of optimization to a particular
storage medium (in part, a trade-off between speed and
generality) are especially instructive. Moreover, within
the CBIH Program's own activities, the use of a powerful interactive text editor as a simple file management
tool for the study of structure/activity relationships in
morphine-like substances has served to clarify a number
of system design questions. 6
MAJOR CBIH PROGRAM EFFORTS
Turning to the currently ongoing activities receiving
direct CBIH Program sponsorship, the remainder of
this discussion is devoted to two proj ects: (a) the design
and prototype implementation of the PROPHET System by Castleman, Briscoe, and colleagues at Bolt
Beranek and Newman Inc. (BBN) and (b) the studies
of automated management of pharmacological knowledge by Werner, Pople, and associates at the University
of Pittsburgh. Both of these projects are extensive,
multiyear endeavors and can only be described in
broad outline here; nor do they constitute the total
range of current program efforts. Nevertheless, they
best portray the CBIH Program's strategy for dealing
with the pharmacological information-handling "problem," and their early results provide invaluable indicators of the promises and difficulties which lie ahead.
The PROPHET system
PROPHET is an experimental information-handling
system designed specifically to subserve pharmacology
1160
Spring Joint Computer Conference, 1972
GRAPI-!!CS
TEmmrJl\lS
(3) a special emphasis on making complex computational processes relatively invisible to the pharmacologist user (e.g., presenting sophisticated
data management strictly in terms of operations
on tables, allowing stylus and tablet input and
CRT display of molecular structures, etc.);
(4) a rich substrate of special data types for handling
such pharmacologically relevant data structures
as tables, molecules, graphs, and nodal networks;
and
(5) a design which attempts to circumscribe the full
power of a general-purpose digital computer in
such a way that communication among users is
strongly facilitated without inappropriately constraining options for individual initiative.
UTILITY
COMPUTATION
CENTERS
STORAGETUBE
DISPLAY
PHONE
LINES
MINICOMPUTER
DISPLA Y L..-_---'
TIMESHARED
CENTRAL
COMPUTER
••
•
CAAOS-j
TAPES
LISTINGS
OTHER
TERMINALS
••
•
L _ _ _ _....I
INFORMATION
SERVICES
Figure 2-PROPHET system equipment organization
research. It is intended to be a medium through which
the latest pharmacologically relevant informationhandling methods can be developed, integrated, and
made available to practicing scientists throughout the
nation. I t is viewed as a research tool encouraging
more rigorous approaches to the organization and analysis of laboratory and clinical observations. Its ultimate
goal is to facilitate the acquisition and dissemination
of knowledge about mechanisms of drug action across
a span of disciplines ranging from molecular biology to
human clinical investigation.
The general nature of PROPHET is given in Figure
2. As shown there, PROPHET is designed to employ a
dedicated, medium-sized, time-sharing computer (a
Digital Equipment Corporation PDP-10) and to serve
a geographically dispersed set of users via remote
graphics terminals operating over voice-grade telephone
lines. Information-handling procedures and data files
reside in the central computer. Provision is made for
eventual interfacing with both utility computers and
information services. A detailed description of the system is given in the document entitled "The PROPHET
System: A Final Report of Phase I of the Design Effort
for the Chemical/Biological Information-Handling
Program."7
The primary features of PROPHET as seen from the
perspective of computer technology are five:
(1) a powerful interactive command language en-
abling even a computer novice to effect sophisticated procedures for handling empirical data on
chemical substances and their biological
consequences;
(2) a simple procedural language syntactically
modelled on PL-l which is coextensive with the
command language and which allows essentially
unfettered interleaving of system and userdefined functions;
In other words, by specifically encouraging user-system
and user-user interactions within the somewhat rigid
context of standard predetermined data types,
PROPHET is designed to allow research pharmacologists to handle their personal data files and communicate with their colleagues more effectively than they
can any other way.
Although PROPHET, like most complex computer
systems, is better demonstrated than described, a few
simple illustrations may prove useful. Figures 3 and 4
show the system commands for operating on tables and
molecules, respectively. Arguments for the commands
are given in small letters; square brackets enclose optional portions; braces enclose alternative forms. These
two lists are only a fraction of the commands available
to the user. Note especially the integration of the various data types-e.g., the data type molecule can be an
entry in the cell of a table.
1_ MAKE TABLE unused-name [FROM table-name [FOR relational expression]]
2 ADD {COLUMN[S]} TO table-name [FROM table-name]
.
ROW[S)
{;~:{~~~~~~;(s)}
3 ENTER [ROW[S)
.
COLUMN[S)
(I
column-name s
column-numbedsl
~]
OF table-name
4_ FILLIN table-name FROM table-name
DISPLAY}
5_ { PRINT
~[COLUMN[S]
L
~[ROW[S)
L
6.
{column-name(s) }oF]l
column-numbeds)
~
{row-name(s) } OF)
row-numbeds)
J
table-namel
LlST{~!~~~entifiicaton } TABLES
column-name(s) }
7. SORT table-name BY COLUMN[S] { column-number(s)
S_ PROTECT table-name
Figure 3-Summary of table-handling commands
Automated Information-Handling
1.
MAKE MOLECULE unused-name [FROM display-indication]
2.
DISPLAY [CONFORMATION OF] molecule-name [COMPLETE]
3.
COMPUTE MODEL OF molecule-name
4.
CHEMSET property-name TO value(s)
5.
WHAT IS
6.
ADD COLUMN [S] TO
7.
[UN] LABEL property-name of molecule-name
8.
ROTATE [DISPLAY] BOND number
9.
DISPLAY molecule-name WITH molecule-fragment-name
et
prop r y-name
1161
'DISPLAY COLUMNS 4·14 OF MEGAMOUSE$
MEGAMOUSE
SRX20C
4.
DAY4
5.
DAY 5
6.
DAY 6
7.
DAY 7
S.
DAY 8
9.
DAY 9
10.
DAY10
11.
DAYll
12.
DAY12
13.
14.
DAY13 DAY14
{elembent(-in)dicatiOn(S)}
num er s
{ element-indication(s) }
number(s)
{BONDS}
ATOMS
of molecule-name
element-indications}
{ numbers
Figure 5b-Mouse survival time: Selected columns of the table
"Megamouse"
Figure 4-Summary of molecule-handling commands
The nature of PL/PROPHET, the procedural language is illustrated in Figures 5-8 using data drawn
from a study of antileukemic drugs being conducted by
the Southern Research Institute in Birmingham, Alabama. Figures 5 and 6 show selected columns from a
user-defined table set up to handle survival time data
on mice inoculated with various quantities of L-1210
leukemic cells; the numbers in the cells of Figure 6
indicate the number of mice which died on that particular day. Note that columns 19 and 20 of the table
(Figure 5) are blank since they are intended to accommodate results derived from earlier columns.
Figure 7 lists a brief user-defined procedure for calculating the number of II-day survivors and the mean
survival time from the observations recorded in columns
4-14 and storing them in columns 19 and 20. Figure 8
then gives the result of calling this new function-i.e.,
an updated version of the table with the derived values
in place. Note that the user need take no special action
to have his personal PL/PROPHET procedures operate
in conjunction with the standard system functions.
SURVIVE: PROCEDURE (TABNAM);
DECLARE (I,J,DEATH,SUMDEATH,SURVS) FIXED;
DECLARE TABNAM TABLE·
DECLARE (ENTRYIJ,ENTRY19,NU,TOT) CHARACTER;
NU =";
TOT = '/10';
DO I = 1 TO 8;
SUMDEATH = 0;
DEATHDAYS = 0.0;
DO J = 4 TO 14;
SET ENTRYIJ TO COLUMN J ROW I OF TABNAM·
IF ENTRYIJ=NU THEN GO TO ABC·
'
DEATH = CINT(ENTRYIJ);
,
SUM DEATH = SUMDEATH + DEATH·
DEATHDAYS = DEATHDAYS + CREAL(DEATH)*CREAL(J)·
ABC: END;
,
SURVS = 10 - SUMDEATH·
ENTRY 19 = CSTRING(SURVS).TOT;
ENTRY20 = DEATHDAYS/CREAL(SUMDEATH);
SET COLUMN 19 ROW I OF TABNAM TO ENTRY19·
SET COLUMN 20 ROW I OF TABNAM TO ENTRY20:
END;
,
RETURN;
END;
Figure 6-Listing of PL/PROPHET procedure "Survive"
to analyze mouse survival time data
'CALL SURVIVE (MEGAMOUSE)$ 'ERASE ALL$ 'DISPLAY
COLUMNS 2,3,19,20 OF MEGAMOUSE$
'DISPLAY COLUMNS 1,2,3,19,20 OF MEGAMOUSE$ ,
MEGAMOUSE
8R X 20C
1.
IMPLANT
CELLS
2.
DOSAGE
(MG/KG)
3.
SCHEDULE
1.E7
2.25E2
07D,DAYS
1.E7
1.5E2
2,9,16
1.E7
1.E2
19. 11 DAY
SURVIVORS
ITOTAL
20. MEAN
LIFE SPAN
MEGAMOUSE
SR X 20C
2.
DOSAGE
(MG/KG)
3.
SCHEDULE
19. 110DAY
SURVIVORS
/TOTAL
20. MEAN
LIFE SPAN
1.3El
1
2.25E2
Q7D,DAYS
3/10
2
1.5E2
2,9,16
5/10
1.46El
3
1.E2
4/10
1.466666El
0/10
9.1
1.E7
6.7El
4
6.7El
1.E6
2.25E2
07D,DAYS
5
2.25E2
OlD,DAYS
4/10
1.lEl
1.E6
1.5E2
2,9,16
6
1.5E2
2,9,16
7/10
1.7El
1.E6
1.E2
1.E6
6.7El
Figure 5a-Mouse survival time: Selected columns of the table
"Megamouse"
7
1.E2
5/10
1.4SEl
S
6.7El
0/10
1.079999El
Figure 7-Selected columns of the table "Megamouse" showing
results of the procedure "Survive"
1162
Spring Joint Computer Conference, 1972
Figure 8-Simple model of neural control of skeletal muscle movement
At the present time PROPHET is available on a
dedicated PDP-IO computer housed and operated for
the CBIH Program by First Data Corporation of
Waltham, Massachusetts, and is ready for extensive
evaluation by research pharmacologists in the context
of their day-to-day activities. It is hoped that the testing period now beginning will help both to refine current
concepts and to identify areas for future investigation.
It is also hoped that these collaborative projects using
PROPHET will result in clear-cut demonstrations of
the utility of modern information-handling methods in
the search to understand the mechanisms of drug
action.
A utomated management of pharmacological knowledge
A vital complement to the initial work on the
PROPHET System is the basic research being conducted by Werner, Pople, and their associates at the
University of Pittsburgh. 8 This group is exploring the
problems and promises of using automated inference
Automated Information-Handling
methods as cognitive aids to the individual pharmacological investigator. They seek to demonstrate where
and how the concepts of artificial intelligence might be
applied to achieve marked qualitative and quantitative
improvements in current capabilities for the storage
and retrieval of information.
The Pittsburgh team has concentrated the bulk of
its efforts to date on model-handling tools-i.e., system
functions which make it relatively easy for even the
computer novice to construct and exercise models of
pharmacological processes, assuming, of course, that he
has the basic biomedical knowledge to engage realistically in such an endeavor. The intent is to aid individual investigators not only in expressing their
concepts about mechanisms of drug action but also in
assessing the validity of those conceptualizations
through digital simulation and other algorithmic processes. Put another way, the goal is to produce an
easy-to-use software system whose capacity to absorb
and operate upon pharmacological knowledge is unprecedented in its scope and power.
Werner, Pople, and their associates have found especially useful the class of models known as finite state
automata. In brief, the builder of the model specifies
each node in a network in terms of algorithmic processes, direction and nature of connectivity, threshold
logic and other control information, and the like. Proceeding a "fact" at a time, so to speak, the user can
build arbitrarily large and complex model structures.
To effect a simulation, the state of each node in the
network is determined at each of a succession of discrete
time steps using the algorithms and other information
.RUN NORMAL
*(ADD NEURON @N-RUBER 1$
N-RUBER
(49001 00) (lMPINGE+) (lMPINGE-)
NIL
*(ADD DELAY DEEP·CEREBELLAR-NUCLEUS 15$
DELAY 40
(INPUT: 3)
*(ADD DELAY N·RUBER 20$
DELAY36
(INPUT: 49)
*(TIE EXCITATORY DELAY40 N-RUBER$
N·RUBER
(4900100) (lMPINGE+ DELAY40) (IMPINGE·)
NIL
*(TIE EXCITATORY DELAY36 FLEXOR·ALPHA·MOTORNEURON$
FLEXOR·ALPHA-MOTORNEURON
(3200200) (lMPINGE+ DELAY36 DELAY21 DELAYS AFFERENT2-INTERNEURON
EXT·INTERNEURON1B) (IMPINGE· DELAY12 EXT·INTERNEURON1A RENSHAW-CELL
INTERNEURON1B)
NIL
*(TIE EXCITATORY DELAY36 GAMMA1·MOTORNEURON$
GAMMA l·MOTORNEURON
(3400100) (lMPINGE+ DELAY36 DELAY26 DELAY21) (lMPINGE-INTERNEUR
ON1B DELAY12)
Figure 9-Use of the model building commands "Add" and "Tie"
1163
(CLEAR)
NIL
*(KILL SUBSTANTIA-NIGRA)
YES·MASTER
*(ANAL YZE @NORMAL)
((PULSE·FLEX NEVER·RECOVERS LATE·PEAK AUGMENTED·PEAK) (PULSE·EXT ABSE
NT) (STRETCH·FLEX OSCILLATIONS EARLY·RECOVERY) (STRETCH-EXT NEVER·REC
OVERS))
*
(RESTORE)
NIL
*(KILL SUBSTANTIA-NIGRA)
YES·MASTER
*(KILL N·VENTRALIS·ANTERIOR)
YES·MASTER
*
(ANAL YZE @NORMAL)
((PULSE·FLEX NEVER·RECOVERS LATE·PEAK AUGMENTED·PEAK) (PULSE·EXT ABSE
~T) (STRETCH-FLEX EARL Y·RECOVERY) (STRETCH·EXT NEVER·RECOVERS))
Figure lO-Use of the model exercising command "Analyze"
provided at the time of model construction. Moreover,
by having the user (or another computer program)
monitor the time course of the state transitions at
selected nodes, one can perceive the behavior of the
model in response to various stresses and compare this
behavior with observations made in the laboratory or
clinic.
The neuropharmacology associated with the control
of skeletal muscle movement has served as the prime
subject for the Pittsburgh· group's early efforts. As
shown by Figure 8, even a simple model of this pharmacological system is essentially unmanageable without
computer assistance. However, using an early version
of their model-handling tools, these investigators have
achieved some most encouraging results. While the
following brief series of examples can hardly given an
adequate characterization, they should impart the
general flavor of the work.
Figure 9 shows how the model building commands
(i.e., ADD, DELETE, CUT and TIE) are used; in this
case the user is adding the Nucleus Ruber to the model,
assigning it a threshold value of 1 and connecting it via
appropriate delays so that it gets excitatory input
from the Deep Cerebellar Nucleus (already in the
model) and delivers excitatory output to the alpha- and
gamma-1 motorneurons on the flexor side. Figure 10
illustrates the model exercising and perception functions; in this case the command ANALYZE is entered,
causing the model to be stressed by a standard set of
stimuli analogous to the tendon taps and passive
muscle stretch used routinely in clinical neurology examinations. The user has the option of setting a window
1164
Spring Joint Computer Conference, 1972
(GOLDIG (BRINGABOUT@((STRETCH-FLEX NO-OSCILLATIONS)) *))$
(ENTERING 1 BRINGABOUT) (((STRETCH-FLEX NO-OSCILLATIONS)) *)
(LEAVING 1 BRINGABOUT) DEFERRED
(RE-ENTERING 1 BRINGABOUT) (((STRETCH-FLEX NO-OSCILLATIONS)) *)
(ENTERING 1 TRANS) ((DSET INTRALAMINAR-NUCLEUS 1))
(LEAVING 1 TRANS) (SOOOO)
(ENTERING 2 BRINGABOUT) (((STRETCH-FLEX NO-OSCILLATIONS)) *)
(LEAVING 2 BRINGABOUT) DEFERRED
(ENTERING 1 TRANS) ((DSET EXT-N-VENTRALIS-LATERALIS -2))
(LEAVING 1 TRANS) (SOOOO)
(ENTERING 2 BRINGABOUT) (((STRETCH-FLEX NO-OSCILLATIONS)) *)
(LEAVING 2 BRINGABOUT) DEFERRED
(ENTERING 1 TRANS) ((DSET N-VENTRALIS-LATERALIS -2))
(LEAVING 1 TRANS) (SOOOO)
(ENTERING 2 BRINGABOUT) (((STRETCH-FLEX NO-OSCILLATIONS)) *)
(LEAVING 2 BRINGABOUT) (NIL)
(LEAVING 1 BRINGABOUT) (((DSET N-VENTRALIS-LATERALIS -2)))
(((DSET N-VENTRALIS-LATERALIS -2)))
*
Figure ll-Use of the model exercising command "Bringabout"
such that he may observe the time course of activity
at only selected nodes. The command ANALYZE also
invokes a perception program which monitors the time
course of the simulated muscle length and, by applying
a succession of linguistic abstractions to the output,
produces a description of the model's behavior in clinical terminology.
Drug effects, of course, may also be studied with this
system. In brief, the computer is provided with a list of
drug names and the associated changes the drugs are
thought to induce in the model's structure and/or control parameters. When the command to administer a
given drug is entered, the software system automatically
makes the indicated alterations. Note that surgical
procedures (e.g., decerebration) can be handled via the
same mechanism.
Emphasis also has been directed toward having
other computer programs exercise the neural model.
Pople has experimented with a problem solving system
whereby a high level executive processor accepts user
queries and answers them by an appropriate combination of structural modifications and simulation runs.
This allows the user to investigate hypotheses about
drug action on-line by observing how the system can
BRINGABOUT specified end states in terms of structural and functional changes in the model such as drugs
are known to cause. Figure 11 gives a brief example of
some preliminary results. In this case the system is
asked to find an alteration which eliminates the prolonged oscillations following m.uscle stretch on a model
mimicking Parkinson's disease. After two unsatisfactory maneuvers (i.e., adding driving forces to the Intralaminar Nucleus and the External Nucleus Ventralis Lateralis, respectively), the BRIN GAB OUT
command discovers that applying a driving force of - 2
to the Nucleus Ventralis Lateralis leads to the goal
state.
For the immediate future, the Pittsburgh group
plans to continue its investigations into techniques
whereby artificially intelligent computer programs can
exercise or otherwise manipulate pharmacological
models. For example, studies are now under way on
such topics as (a) automatic selection of the appropriate level of resolution of a model when it is used in a
specific question-answering context, (b) definition of a
quasi-English language whose utterances are equivalent
to data structures in the model, and (c) development
of techniques for using a model to organize and retrieve
references to the experimental literature which is associated with that model. These investigators have only
scratched the surface on a fascinating and formidable
collection of information-handling problems.
FUTURE PROSPECTS
The CBIH Program's progress to date represents a
collection of small (but nevertheless real) inroads into
an enormously difficult task. In the years ahead the
Program must deal with three basic questions:
(a) How can the evolving PROPHET System best
be integrated into the mainstream of pharmacological research?
(b) When and how can PROPHET be enriched with
capabilities for model management?
(c) What additional research topics in the information science field should be addressed if the information storage and retrieval aspects of
PROPHET are to be made most effective?
The first two of these questions will be met initially at
least by continuing the work at BBN and the University of Pittsburgh, taking steps specifically to coordinate these efforts even more closely with one
another and with leading pharmacology laboratories
throughout the nation. The third question, to the extent that funds permit, will be approached by experimenting with new pharmacological data types and
representation conventions and by exploring such notions as the utility of data description schema.
To recapitulate the opening theme, pharmacology
offers an enormously rich problem space for those interested in applying computers in the biomedical world.
Pharmacology impinges on almost every area of medical science and its progress is heavily dependent on the
continuing erosion of disciplinary boundaries. Moreover, its information-handling requirements strain at
the frontiers of computer science in almost every direc-
Automated Information-Handling
tion. And the overwhelmingly important implications
for society that accompany even small advances in our
understanding of drug action make it urgent that the
challenge for further inquiry be accepted.
REFERENCES
1 M HUNSBERGER et al
Survey of chemical notation systems
National Academy of Sciences-National Research Council
Washington DC Publication 1150 1964
2 Chemical structure information handling: A review of the
literature 1962-1968
National Academy of Sciences-National Research Council
Washington DC 1969
3 E J COREY W T WIPKE
Computer-assisted design of complex organic syntheses
Science 166: 178-92 1969
E J COREY et al
Progress reports
NIH Contract #PH-43-68-1018 NIH-70-4105
1165
4 C LEVINTHAL et al
Progress reports
NIH Contracts #PH-43-67-1131 and #PH-43-68-1019
NIH-71-4028
5 J MINKER J SABLE
File organization and data management in annual review of
information science and technology
Carlos A. Cuatra Ed American Documentation Institute
Annual Review Series Vol 2 Chap 7 Wiley Interscience
New York NY 1967
6 S J KAUFMANN et al
Computer-assisted data management in medicinal chemistryThe use of a general purpose text editor
J Chern Doc 10: 248-255 1970
7 P A CASTLEMAN et al
The PROPHET system: A final report on phase I of the
design effort for the chemical/biological information
handling program
NIH Contract #PH-43-68-1328
NIH-70-4113
8 G WERNER et al
Progress reports
NIH Contract #NIH-69-2073 NIH-70-4121
Where do we stand in implementing information systems?
by JAl\tlES C. EMERY
University of Pennsylvania
Philadelphia, Pennsylvania
about a problem we tend to concentrate on the normal
combination of circumstances; we often overlook the
exceptions. And yet it is the exception that causes
much of the work in designing and implementing an
information system. It is not uncommon, for example,
for over half of the design effort to go into the handling
of exceptions that account for a few percent of the
transactions entering the system. One approach, of
course, is to handle the rare exception outside of the
automatic system. But even this requires considerable
design effort to detect the exception and control the
eventual entry of the corresponding correction.
Just as man seems to have a proclivity to ignore the
exception, he also seems to have a bias toward optimism.
Estimates are frequently based on the assumption
that everything will work out as planned, ignoring the
overwhelming evidence to the contrary. Critical difficulties often appear in the process of linking individual
subsystems into the overall system. System integration
and testing typically account for over half of the total
cost of implementing a complex system, but it is the
rare estimate that provides this level of funding.
Reinforcing these psychological biases are certain
institutional biases toward optimistic estimates. The
cost of implementing a large system is very great, but
many organizations have not been willing to face up to
this fact. More than once I have heard an MIS director
say that he could never get authorization approved if
he gave honest estimates.
Underestimation of the complexity of a system leads
to a number of unfortunate consequences. An obvious
one is the cost and schedule overrun that we so often
experience. This, in turn, often leads to hasty shortcuts
that result in systems that are error-prone, inflexible,
and poorly documented.
ACHIEVEMENTS OF THE COMPUTER
INDUSTRY
By any reasonable yardstick the computer has been
a fantastic success. It has grown in one generation
from a laboratory curiosity to one of our major industries-perhaps the most vital one in our information-oriented post-industrial society. Raw computational speed has increased during this period by an
order of magnitude every four or five years. The cost
of computation has dropped to the point that we can
employ it lavishly on everyday tasks.
The computer has already brought significant
changes in science, engineering, and commerce. Some
branches of technology, such as space exploration,
would scarcely be possible without the computer.
Virtually all scientific fields have been affected in varying degrees. Without the modern computer it would be
very difficult to perform the myriad data processing
tasks required to run a large organization. Indeed,
many of the companies most heavily involved in data
processing, such as those in the banking and insurance
industries, could simply not exist in their present form
without the computer.
PROBLEM IN APPLYING COMPUTERS
Despite these unprecedented achievements, we computer professionals are not universally hailed as heroes.
In fact, we have a difficult time staving off our detractors. It would be comforting to think of them as ungrateful wretches who resent the bounty that we have
bestowed upon them. Unfortunately, much of our
difficulty stems from our own failures to exploit the
technology nearly as well as we might. It is all too easy
to identify these failures.
Underestimating complexity
Design of overly sophisticated systems
Man seems to have a natural bias toward underestimating the complexity of information systems. It is
easy to see how this can come about. When we think
Underestimating complexity can lead into the trap
of striving for too much technical sophistication. A
technician naturally wants to design systems that
1167
1168
Spring Joint Computer Conference, 1972
move to-or even extend-the frontier of technology.
Often overlooked is the cost-effectiveness of marginally
useful sophistication.
A common example is an overemphasis on quick response. On-line file updating and retrieval, with response times in the order of a few seconds, can add
enormously to the cost, complexity, and technical risk
of a system. Alternatives exist that may give nearly
the same benefits at much lower cost. For example,
skip sequential processing of indexed sequential files
permits short batch cycles-perhaps in the order of an
hour or less. If this is not short enough, it is possible to
provide on-line data retrieval without the much greater
complexity that on-line updating requires. There are
certainly cases where the extra cost of on-line updating
is more than justified by substantial incremental benefits, but these tend to be quite exceptional.
The bias toward sophistication manifests itself in
other ways. Designers and programmers often strive
too much to achieve machine efficiency. In doing this,
they ignore the broader aspects of efficiency that include programming costs, flexibility, and maintainability. We live every day with past mistakes of this
sort-for example, the ludicrous situation in which a
third generation computer spends its time emulating
a second generation computer because earlier systems
were programmed in assembly language to gain efficiency. We tend not to make this mistake now; instead,
we make errors at a higher level by rejecting, for example, use of a generalized software package because
of its "inefficiencies."
Failure to exploit existing technology
Paradoxically enough, while we strive for sophistication we also ignore well established technology. This is
perhaps understandable in a technology that has been
expanding so rapidly: it is almost impossible for the
practitioner to keep up with his field. Nevertheless, it is
painful to see.
A good example of the problem is our failure to
include an information retrieval capability within a
management information system. The ability to handle
ad hoc inquiries has been. available for well over a
decade. Some companies began to apply such systems
in the late 1950s, and proprietary retrieval packages
came on the market soon afterwards. Although there is
now widespread interest in such systems, they are used
much less than they ought to be.
Poor human factors design
One of our greatest failings is the incredibly poor job
we often do in serving the human user of our systems.
Anyone who has tried to correct a billing error knows
the problem. Systems are too unreliable, unforgiving,
and uncorrectable. They spew out masses of data that
are often poorly identified and displayed in a form
that is difficult to comprehend. It is no wonder that
users shudder a little when the computer moves in.
IS THERE A BETTER WAY?
Clearly we can do better than we have; the relatively
few organizations that have done an outstanding job
demonstrate what can be done.
There is no simple prescription for success in this
business. Nevertheless, there are certain steps to follow
that are probably necessary, but not sufficient, for
success. I offer them not as a unique set of guidelinesindeed, they are all well-known-but as a reminder of
those things we frequently choose to ignore.
Stay within the state of the art
It is a well-known aphorism in our trade that pioneers
are distinguishable by the arrows in their backs. With
rare exceptions, it does not pay to develop systems
that rely on an extension of the frontier of technology.
Even military systems, which have a better justification
than most for such a strategy, usually are well advised
to stick with proven hardware and software.
Exploit available technology
Staying within the state of the art is not a very
serious limitation. The art has advanced to the point
that technology does not impose many real constraints.
It is perfectly feasible, for example, to design systems
that have the following characteristics:
1. Considerable use of shared computer resources.
Although the issue of centralized versus decentralized computation is not closed, most advanced systems will find it exceedingly attractive
to combine computational loads into a few (often
one) large computers. Centralization offers the
undeniable advantages of economy of scale, the
power of a large facility, load levelling, and the
availability of a centralized data base. There will
no doubt always exist systems that call for the
simplicity and economy of specialization that a
small decentralized computer can provide, but
for the bulk of our needs we should surely look
to relatively centralized facilities.
2. Considerable integration of the data base. The
consolidation of files has been going on apace for
a number of years. This has resulted in a reduc-
Where do we stand in Implementing Information Systems?
tion of redundancy and greater sharing of data
across programs. There still remains, however,
the need to link non-contiguous records. This
only becomes feasible when one employs a fairly
sophist.icated data base management system for
on-line storage. The capability of linking records has existed for a number of years nowbeginning with General Electric's IDS-but it
has yet to be widely applied. This technology
has now matured to the point that it should be
considered in the design of any new system.
3. Interactive computation. My earlier comment
on the overemphasis given to short response
time should not be interpreted as a blanket
rejection of quick-response systems. Certainly
the technology is available to provide reliable
on-line response or file updating when the resulting benefits justify the added cost. Our
str.ategy should not be biased in favor of either
short or delayed response; rather it should aim
at a tailored response that allows each application or user to have the response that best
balances costs and benefits. Such a system will
very likely provide a whole spectrum of response
times-from interactive retrieval and data entry
to periodic batch processing.
4. Finally, virtually any well designed system
should include some decision making models.
The models can vary from analytical optimizing
models to man-machine decision systems that
rely on elaborate simulation models. It is only
when the information system provides direct
support of decision making that it really begins
to take advantage of the full capabilities of information technology. The most serious issue
facing the designers of such systems is the extent
to which the models should be embedded within
the information system. It is always a difficult
task to provide formal, automatic links between
transaction processing and decision models.
They should therefore be provided only in the
case of high-volume and rapidly changing inputs
and outputs; in the remaining cases the models
can be loosely coupled to the transaction processing through some sort of manual intervention
(e.g., smoothing or normalizing transaction data
to generate inputs, and reviewing and adjusting
decision outputs prior to introducing them into
the operational part of the system).
Provide long-term organizational commitment
If there is anything certain about our business it is
that the development of successful systems calls for
1169
long-term, sustained support. No system is ever really
finished; it undergoes continual modification and adaptation over the course of many years. Eventually it
may be scrapped and replaced by an entirely new
system.
An organization's commitment to a long-term program should take a number of forms. One requirement
is for relative stability in the resources devoted to systems development. Insofar as possible, these expenditures should not be viewed as an easy target for cash
savings in time of belt tightening.
Management's commitment should also take the
form of participating in the design of the system and
smoothing the way for its introduction. The call for
such participation has become a commonplace in our
profession, but it is no less t.rue because of that. A well
designed system should become an integral part of the
management process of an organization, and it is hard
to see how this can come about without continual support by all levels of management. Many important
management policy decisions are embedded within the
MIS design, and so managers must participate to the
extent required for them to resolve these issues.
A long-term commitment implies an explicit program
to develop systems personnel. The need is especially
critical at the management level within the systems
group itself. The philosophy that any good manager
can head a systems group has surely been discredited
by now. The body of knowledge within the field has
grown to the point that this knowledge cannot be
quickly or casually acquired; the development of real
professionals requires a long-term program. We should
be no less reluctant to turn over systems development
to the untrained and unseasoned manager than we are
to trust the removal of an appendix to a barber.
An organization's commitment is also measured by
the calibre of personnel they assign to the MIS function.
Little success can be expected if the function is considered a dumping ground for misfits, if it does not get
its share of the organization's fair haired boys, or if it
does not attract outstanding computer professionals.
Without at least. a sprinkling of really top-flight designers, analysts, and programmers, the organization
would be well advised to scale down its aspiration level
to meet only bare requirements.
Emphasize users
Everyone talks about the need to serve users, but
we nevertheless continue to make many of the same
mistakes. Evidentally we must take much more formal
and explicit steps to deal with this problem.
The use of steering committees is one way to get user
1170
Spring Joint Computer Conference, 1972
participation. They can certainly help in making resource allocation decisions and in resolving policy
questions. They are equally applicable at all levels in
the organization-a high-level committee to deal with
broad, long term issues, for example, and lower-level
committees to deal with operational subsystems. The
form of the committees and their tenure may vary
considerably, but certainly some relatively formal
means is needed as a forum for dealing with issues that
cross existing organizational boundaries.
System groups should include staff members who are
specifically assigned responsibility for human factors
design. Included within their scope of activity should
be such matters as the design of hard copy forms and
CRT display formats, procedures connected with the
information system (including error handling procedures), specification of the operating characteristics of
terminals, and concern for the ability of the system to
adapt to changing user needs. These responsibilities
tend to be scattered about within most groups, rather
than dealt with as a whole.
A formal user sign-off procedure should exist so that
users have an explicit opportunity to get their views
incorporated into the MIS design. Such sign-off should
be required at all major stages of the implementationthe feasibility study, functional design, detailed design,
testing procedures, and final operational acceptance.
It might be a good idea for each organization to have
an ombudsman to look out for users' interests. As information systems become more and more pervasive
throughout the organization, we stand some chance of
being swallowed up by them unless someone is around
who can pull the plug in an emergency. To be effective,
the ombudsman should remain independent of the
MIS group, have the authority to investigate all matters
connected with the information system, and have the
right to voice his opinions at the highest levels of management. One would probably not find enthusiastic
support for such a position among systems directors,
but it nevertheless may provide a very useful safeguard.
Devote more effort to project management
The implementation of a large MIS has itself become
a formidable management task. It may require the
efforts of over a hundred persons extending over the
span of several years. The various subsystems tend to
interact closely with one another, and therefore call for
a high degree of coordination among the project teams.
An activity as complex as this requires more attention to its management than normally given. Techniques exist for dealing with the problem-network
scheduling and resource allocation models, documenta-
tion and configuration management procedures, simulation packages for analyzing alternative designs, and
all the rest. Unfortunately, however, most projects do
not formalize project management to the extent necessary. The direct cost of good management is quite
high, but the indirect cost of poor management is
staggering.
Centralization of systems management
It is hazardous to generalize too much about the
proper degree of centralization of systems activities.
Organizations thoroughly committed to decentralized
management find it hard to treat the systems activity
as a centralized exception. Centralization can also increase problems of keeping the system responsive to
users' needs.
Nevertheless, considerable benefits can come from a
certain amount of centralization. The benefits basically
stem from the economies of shared use of hardware,
software, and data.
For most organizations it does not make much sense
to maintain more than one group concerned with the
development of standards for programming, documentation, languages, data base design, and project
evaluation. Vendor hardware and software evaluation
should likewise be centralized in most cases. Design of
common application programs might even be centralized. Clearly we are already seeing more and more
centralized computer facilities.
Centralization of this sort does not imply isolation
from users. Specialized applications can-and probably
should-be handled on a decentralized basis. A remote
termial hooked to a centralized computer should be
viewed logically by decentralized managers as an independent resource with the capabilities of a large machine
at a fraction of its full cost. To be sure, any centralization imposes some constraints on the organization's
subunits, but when intelligently applied the constraints
still can leave ample room to meet users' requirements.
After all, we all must live within certain constraints,
whether imposed internally or externally by governments or vendors.
Incremental development
A comprehensive system takes many years to develop. Noone can foresee how technology and users'
requirements will evolve over this length of time. It is
therefore absolutely essential that systems be designed
in a way that permits continual modification and
'
extension.
Where do we stand in Implementing Information Systems?
A number of steps can be taken to achieve a much
higher degree of flexibility than most systems offer.
Perhaps the most important requirement is a master
plan to guide the development of separate subsystems.
Such a plan defines the subsystems that will comprise
the eventual overall system, and establishes the major
interfaces among these subsystems. It is only when such
a plan has been developed that one can have any
assurance that all of the subsystems will mesh together.
The master plan need not go into great d~tail. Its
purpose is to establish constraints within which each
subBystem can be developed more or less independently.
In principle, one should limit the detail to just that
level required to define the interfaces among subsystems. Detailed work beyond this level can wait
until the actual implementation of the separate
subsystems.
Insofar as possible, the subsystems should be implemented in a sequence that provides early interim benefits. Certain technological constraints may partially
limit the choice of sequence-for example, some generalized software may be required before application
programs can be written, and a forecasting program
cannot be implemented until the order entry subsystem
from which it gets its inputs has first been developed.
Other factors, such as the particular skills available
and political considerations, may playa part in choosing the implementation sequence. The basic strategy
should be, however, to implement each sUbsystem in a
way that provides interim benefits that justify development costs, while at the same time leading toward the
eventual accomplishment of the master plan.
The plan should evolve along with the system: it is
1171
not meant to impose inflexible constraints on the design.
Changes will inevitably occur as technology advances,
the organization's needs change, and the system matures. The changes should, of course, be controlled
and consideration given to trade-offs and the need for
coordination among subsystems.
In addition to the development of an evolutionary
master plan, other well-known techniques exist for
increasing the flexibility of a subsystem. These include
use of higher-level languages, modularity, data and
program independence, avoidance of unnecessary program complexity, and careful documentation. These
techniques typically carry a short-term price, but they
are vital for long-term success.
CAN SUCCESS BE REPLICATED?
We know that real success can be achieved, but we
also know that it is relatively rare. This is so because
success requires the rare combination of exceptional
management, sustained support, and top-flight technical personnel. Without these ingredients, results are
likely to be marginal at best and disastrous at worst.
Unfortunately, there is not enough talent to insure
that each organization has an adequate supply. The
great challenge we face is to develop a technology that
does not require genius to implement. Conversion of a
field from an art to a routine science is the chief sign
of its maturity. To achieve this in our field we must
devote a great deal more effort to gaining a better
theoretical understanding of complex systems, planning
and control of large organizations, and the behavioral
aspects of formal information systems.
MIS technology-A view of the future
by CHARLES H. KRIEBEL*
Carnegie-Mellon Universiy
Pittsburgh, Pennsylvaina
that the performance obtained by users of computers
for business data processing shows: 20 percent are
successful, 40 percent are marginal, and 40 percent are
failures. Reviews by others of computers in management information systems also sharply criticize the
notable lack of results in spite of great expectations. 2
If true, this is a dismal return for a $40 billion investment in equipment. What went wrong? Who's at
fault?
On the one hand computer manufacturers and the
industry have been blamed for overselling, for not
developing the right technology, and for not solving the
users' problems. On the other hand the user and
managers have been criticized for overbuying hardware,
for misapplying an inert technology, for "living in the
last century" and not exploiting the modern methods of
today. There is some truth on both sides of these arguments. But acknowledging the existence of a gap is at
best only the beginning of a solution. What "are the
dimensions of "the gap?" What remedies are proposed
to close it? What future developments can we anticipate
towards progress in MIS? Before gazing into a crystal
ball for the answers, we can gain perspective on the
problem by briefly probing the surface of the issues
involved. A conceptual framework is particularly
important in this case because the broad connotation
of MIS and misunderstanding are the source of most of
today's difficulties.
INTRODUCTION
Industry tabulations for 1970 indicated there were
some 85,000 computer installations in the world,
valued in excess of $40 billion. By 1975 these figures are
expected to double; in ten years they may be redoubled.
The continuing exponential growth in raw computing
power prompted Art Buchwald recently to editoralize
on "The Great Data Famine" of the 1970's. According
to Buchwald's expert source by January 12, 1976
" ... every last bit of data in the world will have been
fed into a machine and an information famine will
follow." To cope with this impending disaster, a crash
program is urged in which (1) "no computer can be
plugged in more than three hours a day"; (2) the
government will spend $50 billion to set up data manufacturing plants and their output will be mixed with
soy bean production; and finally (3) a birth control
program will be advocated for all computers-provided, "the Vatican's computer gives us its blessing."
On Tuesday evening, September 9, 1965, the largest
power failure in history blacked out all of N ew York
City and some 80,000 square miles of neighboring areas
in which nearly 25 million people live and work. The
blackout lasted for three hours before partial power was
restored. It is awesome today to imagine what the
consequences would be if a computer blackout were to
occur throughout the world. Yet in spite of our increasing dependency over the past twenty years on
computer technology, one continues to hear of a
"technology gap." Instead of a "data famine" the
technological issue today is that computers haven't
been able to do all that was expected of them. In
stronger language, Isaac Auerbach stated at the closing
session of the recent fourth triennial Congress of the
International Federation for Information Processing
INFORMATION STRUCTURES AND MIS
The phrase "management information systems" or
"MIS" has gained popularity as a descriptor for information processing activities in support of management. If one explores the environment of management
it is soon apparent that decision making is the primary
function that distinguishes managerial activity from
other behaviors. In fact, management decision occupies
a singular role in management literature, since other
* The author wishes to acknowledge many enlightening conversations on MIS with Dr. David B. Hertz and R. George Glaser, Jr.
of McKinsey and Company, Inc.
1173
1174
Spring Joint Computer Conference, 1972
behavior-such as planning and control-is often
defined in terms of decision activity. Thus, an understanding of the central issues in MIS might logically
begin with the concept of management decision.
To economists decision making is the allocation of
scarce resources. Other writers emphasize the choice
activity in that for them, decision making is selecting
the "best" action from among available alternativeswhere the criterion of choice might also be viewed as
one of the alternatives. Since our immediate interest
concerns informational aspects of decision, it is instructive to adopt a broader view of the process by considering the stages which rationally precede the choice
of action and a commitment of resources.
Although a variety of elegant models are available
in the literature, the essential ideas behind a rational
structure for decision making are really quite simple. A
parsimonious description of the decision process would
include four identifiable stages of activity: observation,
inference, evaluation and choice (see Figure 1).*
Within the limits of this model, the process begins
with observing states of the environment; surrogate
images are assigned to natural events, measurements
are taken, and data is collected, encoded and stored.
The second stage in the process involves analysis of the
reeorded data as a basis for inference and prediction.
Here, in effect, reports are made and reviewed to
determine whether or not a situation requires a decision
to be made. Stage three is initiated by the need for a
decision. At this point inferences and projections are
analyzed to identify action alternatives and these in
turn are evaluated with respect to goals, constraints
and efficiency. Finally, an alternative is selected which
is preferred (or "best") under the criterion of choice,
the action is communicated, resources are committed,
and the decision is implemented. As implied by the
diagram the process actually perpetuates itself through
cycling and feedback, since upon implementation the
decision becomes a source for new observation; and
so on.
N ow suppose we consider the development of Information structures in support of the activities In-
volved in each stage of this process.* That is, the
simplistic decision model can serve to characterize four
levels of the relative maturity (or sophistication)
achieved by an information system. In its most elemental form an information system is simply a repository or data bank, encompassing only the "observation"
activities of the model. Th~ raw data has been organized
in some convenient manner and is stored, say, in a
computer file; upon interrogation the manager retrieves
a report and performs all subsequent analyses from
inference to decision. Most accounting systems are of
this elementary form, employing a linear transactions
model of the organization and serving as simple data
banks. Simplicity, per se, is not a criticism of such
systems; their shortcoming in application is that
typically they do not discriminate between vital
information and trivia. Thus managers interacting with
an elementary data bank system often become frustrated by the lack of relevancy in large volumes of data.
At the second level of maturity in development the
data bank system has been expanded to include most of
the activities of inference as part of the formal system.
In addition to exception reporting, the system now
includes the capacity to forecast and to artificially test
the consequences of implicit decisions. The emergence
of the fields of management science and operations
research accompanied by computer-based models,
particularly linear programming and simulation, has
done much to facilitate the realization of these selectiveinference information systems. Here the manager can
interrogate the system with "What if ... " questions,
and receive an array of consequences in response for
his evaluation. The hidden danger in this dialogue is
that the manager is usually insulated from factual data
in the system by a host of assumptions imbedded in the
model which provides the inferences. While a seemingly
obvious caution, it is surprising how readily individuals
are lulled into believing "realistic-looking" output
is fact.
At level three in development, evaluation activities
have been programmed into the selective-inference
structures so that the information system now encompasses action recommendation. Here the need for a
decision is triggered within the formal system on the
basis of monitored observations and predetermined
rules or a time scheduled event. Procedures are programmed to evaluate alternatives against assigned
goals as the situation requires, the "best" course of
action is chosen, and the recommendation is communicated to the manager. At that point the manager
* The
* Analogies
Figure I-Basic stages of activity in decision processes
well-known antecedent for this model is, of course, the
"scientific method." For an interesting and more elaborate
taxonomy see Simon (1960).
of this form have been proposed by others in similar
contexts; for example, Chapter 15 in Gregory and Van Horn
(1963) and Mason (1970), in particular.
MIS Technology
either implements a decision based on the recommendation or he rejects the alternative and further analysis
may be initiated. The most common form of this
action-recommending information system in organizations today is the advisory staff group or committee.
In this case line management delegates authority for a
certain area of responsibility to a staff department,
but retains final control for decision through review and
certification. Another variant of this system has appeared in the form of large scale optimization models,
particularly linear programming applications in industrial scheduling. In many of these cases, however,
systems originally designed for "action recommendation" have over time reverted back to "selectiveinference" systems as limitations of the model became
apparent.
In the final stage of maturity the entire decision
process has been automated within the information
system. All activities from observation to choice and
the ability to initiate action, commit resources and
monitor results have been programmed. In effect the
manager is now outside the structure having fully
delegated his authority, although he retains the power
to revoke the delegation at some future time. The
simplest form of the automated decision system is the
"standard operating procedure" in organizations; a
more sophisticated example would be a computerized
process control system in a petroleum refinery. Modern
factory inventory control systems are another common
example. Obviously, automated decision systems rf'quire extensive knowledge of the decision process for
the given application and consequently their development has been limited to well-defined environments.
Figure 2 summarizes this overview of information
structures in MIS. Concerning the classification it is
important to recognize that the levels of development
should not suggest a linear or necessarily sequential
progression of system maturity. That is, the MIS in a
modern organization today is not one of these information structures; it is a composite of all four types.
Said differently, the two basic components of design in
any information system are (1) a model of the user,
Level of
Development
Information
System Type
Decision Activity Model
(Fig. 1) Formalized and
Programmed
1
2
3
Databank
Selective-Inference
Action Recommendation
Automated Decision
Observation
Observation + Inference
Observation + Inference +
Evaluation
(All above) + Decision +
Feedback
4
Figure 2-Classification of information structures in MIS
1175
and (2) a data store. The former defines the output
interface or system application, and the latter constitutes the environmental image or system input. For
MIS the user model reference is management decision
processes. In the evolution from "data bank" to "automated decision" the user model becomes technologically
more sophisticated, as more activities of the process are
formalized and programmed into the system. But
decision processes exist at all management levels in an
organization hierarchy. Thus, one finds information
structures of different maturity at different management levels. The most mature computer-automated
information structures in MIS today are still confined
to lower management levels.
The preceding discussion provides a framework in
which to assess the dimensions of MIS technology, the
"gaps" today inhibiting implementation, and the
direction of future developments. For present purposes
I will confine these remarks to two dimensions: (1)
the user model component and (2) the data (processing) store component. *
USER MODEL TECHNOLOGY IN MIS
The lackluster results vis-a-vis expectations realized
in MIS to date can be attributed in part to the fact that
the implicit model of the user has remained naive. As
with more elementary information storage and retrieval
systems, the user of a MIS can occupy two distinct
roles either as a generator of system input or as a
consumer of system output. In most cases these roles
occur in different individuals in the organization and
each interacts with the system differently. The structural interface of the system which facilitates communication between these respective roles is the data
file.
Dating from the early 1950's the user model which
typified first generation, computer-based MIS was
accounting transactions. For most applications this
model better served the system input role than the
output requirements of managers. Consequently,
management decision support was limited to a class of
data bank structures for financial reporting, and system
performance evaluation (when executed) was based on
administrative (or clerical) cost reduction. With the
development of operations research techniques and the
evolution of second generation computer systems for
MIS, accounting was supplemented by a series of user
models based on management function, such as personnel
administration, production-inventory control, mar-
* In Chapter 1 of Kriebel, et al. (1971) we have classified MIS
research along five dimensions, however, space limitations here
prevent a more extensive discussion.
1176
Spring Joint Computer Conference, 1972
keting management, and so on. In seeking to close the
output gap in the user model and advance to selectiveinference information structures, functional area
managers in effect developed their own information
systems. The counter-cries to this movement were the
appeals for "integrated data processing" or (in some
circles) "the total systems approach." System compartmentalization during this period aggravated a
variety of development problems including data
collection, data redundancy and inconsistency, and
serious limitations on file cross-talk. System costs were
often hidden in overhead accounts, data processing
feasibility governed applications selection, and "management intangibles" dominated systems evaluation.
As total costs continued to increase in spite of gains
in computer hardware efficiencies, the third generation
systems of the mid-to-late 1960's saw a shift in emphasis
towards consolidation-though not necessarily of the
"total systems" variety. The output-oriented, management function user models in large measure were
abandoned for an input-oriented data base model with
the goal of data processing efficiency. The development
orientation in MIS now focused on a corporate data
bank which stressed input data format, flows, and files
with little attention to the specific output requirements
of end users. Working applications programs in the
system were decoupled from data files through the
imposition of file management software. Most formal
information systems today are still in this stage of
evolution.
From this brief history one sees that the user model
technology in MIS has not progressed very far over the
past fifteen years. At lower management operating
decision levels where an OR model may be in good
correspondence to the actual management problem,
the decision mechanism often becomes an automated
information structure in the MIS. But above the level
of routine behavior, the user (output) model rapidly
returns to a data bank structure. Today's "solution" to
the issue of user output requirements is to maximize
the flexibility for options at the output interface. Data
managers and report generators are two common
examples of such output flexibility. In effect specification of the user (output) model is now left up to "the
user." Similarly, evaluation of the system benefit to
the user is becoming his own responsibility. That is,
in several large organizations today the computer-based
resources of the MIS have been divisionalized into a
"profit center" and, though not a freely competitive
market place, the user is required to pay for services
requested. The performance criterion for system
operations is thus "simplified" to efficient utilization
of resources.
This present stage of evolution raises several questions concerning future developments in the user model
dimension of MIS technology. For example, the profit
center organization is a move toward the information
utility concept; but is "information processing" a
homogeneous commodity? Divorcing the system design
from specific user needs is an attempt to make the
technology independent; but is MIS technology inert?
The contemporary orientation on data input and EDP
technology implies that resource efficiency is a major
bottleneck; but has EDP utilization been the key
barrier in MIS implementation? The data base model
development of a MIS seeks to establish a corporate
data bank, often building from the bottom up; but do
information structures for managers draw upon common
data?
In anticipating the next ten years, my first prediction
is the demise of the present-day data base orientation
as the dominant user model image in MIS development.
Instead the development focus will shift back to an
output orientation that is user dependent, though not
as a return to the second generation MIS. The emphasis
will be on basic decision processes and problems of the
specific organization and manager without regard to the
functional environment. Information structures will be
developed to solve a particular manager's problems;
some of the structures will be generalizable to other
situations in broad outline. For example, one early
attempt at such a structure for strategic planning
decisions has been the so-called corporate economic
simulation model. 14 The mixed results achieved by
corporate simulators thus far can be attributed in part
to the difficulty in implementation of securing top
management attention and involvement. Another less
publicized illustration of an information structure
tailored to a specific decision problem is the concept of
an "issue map" developed by McKinsey and Company
for Mayor Lindsay of New York City.7 Still another
structure that I would include in this context was the
original development and application of PERT (Program Evaluation and Review Technique) and CPM
(Critical Path Method).
The user model image that focuses on critical decision
processes for MIS development, however, is only one
aspect of the new technology. Allied with the change in
orientation will be a rise in the application of operations
research and behavioral science in developing and
implementing these information structures. It is common
knowledge that many of the basic methods and known
results in operations research are not being used by
managers today, even though many of the techniques
have considerable potential as decision aids. 8 This issue
has been labeled a "communications gap," although
MIS Technology
some feel the problem is more fundamental. 3 I think a
majority would agree that MIS technology is not inert,
even though the computer might be. To achieve compatibility at the user/system (or man/machine) interface, technology can either (1) adapt the system to fit
the user's requirements (or behavior patterns), or (2)
seek to change user behavior to better match system
capabilities. * Much of the effort by industry professionals to date has been directed at the second approach,
particularly in the popularized education programs on
"OR and computer concepts for executives." Results
notwithstanding, the empirical evidence on MIS
implementation suggests: (1) except for the most
routine activities, managers actively resist attempts
(real or perceived) to erode their authority base; (2)
the executive's orientation is toward the "people" in
the organization, his self-concept is as an individual
who directs the activities of others; (3) there is relatively little understanding of upper management
decision processes. Emerging information structures in
the next decade will increasingly incorporate behavioral
parameters in their design which reflect organizational
associations, leadership style, and management attitudes as a means toward improving acceptance and
effectiveness at the user/system interface.
For example, in the mid 1960's the experience of
IBM with "executive terminals" for their own MIS led
to the establishment of an Information Center at
corporate headquarters with a human rather than a
machine interface for the user, primarily because of
dominating behavioral considerations (cf., Chapter 8 in
Reference 10). Similarly, at Alcoa in developing their
new Picturephone Remote Information System
(APRIS) for executives, "the principal design criterion
was ease of use ... rather than provide just a tool, the
goal was to provide ... the service of better access to
information."4 The "complete" user guide for APRIS
is printed on a 3" X 5" index card. More basically,
perhaps, research is already under way to parameterize
behavioral constructs in the decision process, such as
"participation,"16 to model how managers identify
problems to be solved,13 and to understand how humans
process information in the act of solving problems. 12
Before the end of the decade I think these developments will impact on MIS design in the appearance of
more "personalized" information structures which
better match the users' needs and in the identification
* I'm reminded here of the lament some years ago, by the EDP
manager of a very large steel company who in responding to an
inquiry by the Chairman of the Board was required to process
some 90 million records over a two-day computer run. Apparently,
the Chairman did not ask his "MIS" the right question.
1177
of new requirements for system technology. Within the
data processing industry the emerging trend toward
companies which provide "information services" will
continue; they will be the developers of the new
technology which solves the user's problems.
DATA PROCESSING TECHNOLOGY IN MIS
Although organizational information systems existed
long before the appearance of the computer and EDP,
the formal designation MIS is commonly associated
with the modern information technology of the last
twenty years. A company's decision to "establish" an
MIS capability in this period contained two conditions
of entry: (1) a large initial capital investment of $.5
million or more, and (2) a non-revocable commitment
to EDP, since the "bridges" to existing manual systems
were usually "burned" as new systems were developed
and mechanized. Consequently, the initial stakes to
play the MIS game were high even if amateur players
did not always recognize them. But then so was. the
promise of payoff. The economic equation for management was simple: replace labor with capital so that as
data volumes increase and technology improves the
per unit cost of processing declines. The engine that
would power this system (or the MIS) was the computer.
Computers have been successfully employed in
engineering instrumentation, scientific data processing,
military and space applications, and in business where
the application involves large volumes of data and
relatively straightforward computations, such as in
communications switching or bank check processing.
To secure the capital leverage of the computer in each
case requires that the process involved be formalized
and programmed. But the needs for different applications are different and, as discussed above, the absolute
requirement to formalize management decision processes has been the key barrier to the computer's
success in MIS. In my opinion this problem has been
further compounded by the promoters of so-called
"integrated systems."
EDP technology encompasses a broad domain
beyond "the computer," from firmware to peripheral
devices and communications, from POLs to data
management software and hypervisors, from system
configuration to systems analysis and people. Within
the space available it is obviously impossible to cover
all aspects or even do partial justice to the many
contemporary developments. As a compromise, I will
instead highlight a subset of the whole that I think
holds particular significance for MIS in the future.
1178
Spring Joint Computer Conference, 1972
~
1---c=J
Regional Center
Sector Centers
"Intelligent
Terminals"
(and Minicomputers)
Figure 3-Distributed data processing grid
Perhaps the most distinguishing characteristic of
third-generation EDP system operations was the
emergence of teleprocessing, facilitated by multiprogramming and data communications technology.
Although early time-sharing applications were restricted
by the existing hardware and operating systems considerable progress has been made in a relatively' short
time span. This development is significant for at least
two reasons. First, it provided the basic framework for
distributed data processing; second, it turned the
centralized vs. decentralized operations debate into an
academic issue to be decided on a relative basis by
org~nizational philosophy. The distributed data proc~ssmg (DDP) approach (see Figure 3) employs a
hIerarchy of EDP centers, ordered on the dimension of
capacity and interconnected through direct communication lines. (Increasingly in the future these
lines will be dedicated for data transmission rather than
modifications of voice networks.) At the lowest level in
the DDP grid the point-of-origin device for data capture
and interaction will be an "intelligent terminal"
ranging from a Picturephone-like* device to a mi~i
computer with local data processing capacity. Where
online access and speed are not important data cassettes
will provide communication linkages. In more sophisticated applications computer networking will be employed for direct communication between computers
and multiprocessor centers. Although thus far the DDP
concept has been employed primarily in experimental
systems, I believe it will be commonplace in the future.
The distributed data processing approach in one sense
is a natural outgrowth of the time-sharing principle to
extend system utilization while capturing some of the
econo.mies-of-scale in· hardware technology. However,
experlence has shown that the massive "universal"
system approach rapidly leads to substantial diseconomies in software overhead and administration.
By analogy, the computer is not a universal machine'
" a t ruc,
k a motorcycle or a racing car each has a'
different engine which is designed for high performance
* Picturephone is
a registered trademark of the Bell System.
and economy in the specific use intended."! The computer system and MIS that seeks to be all things to all
people in one package is doomed to failure at the outset.
The cost balance in configuration is between operating
control over a fragmentation of diverse specialized
systems which may be locally optimal but globally
expensive, and the universal system "dinosaur."9
A .critical problem to date has been technically with
~he Integrated data processing approach-particularly
In extreme applications for MIS which have attempted
to "integrate" everything from customer sales transactions to the President's appointment calendar. The
basic difference under DDP is not to integrate but
instead to provide a well-defined interface for relatively
independent sub-systems. Data managers have been a
first step and in the future these systems will be dedicated to sub-set applications as required. What emerges
t~en is a portfolio of technology (packages) optimized
wIth respect to the portfolio of user information structures. Some of the elements in the overall portfolio will
interact, some will not; however, all elements will be
highly modular. That is, one application may periodically require augmented computer capacity from the
sector or regional centers in "competition" with other
applications, others may share certain master files for
data, and still others may be locally self-sufficient. For
example, the "executive terminal" might well become
a~ inf.or~ation structure serviced by a minicomputer
WIth lImIted communication to a corporate data bank
via cassette.
The utility structure of the DDP grid recalls the
previous question: Is "information processing" a
homogeneous commodity? The purist would answer
affirmatively at some level of computer science or,
above the ISP (Instruction Set Processor) level one
could identify kernel processes. But the ab;olute
answer to this question does not seem critical to me.
That ~s, defining the requisite interfaces will begin to
establIsh the standardization required to achieve
plugboard modularity of sub-systems. For example
General Electric is currently addressing parts of thi~
problem with "interprocessing" in which customers'
computers and GE's network service are usedjointly5to cite one illustration. A more interesting issue,
perhaps, for managers and EDP technology in future
MIS now becomes the "make or buy" decision.
Earlier I remarked that the economic rationale by
management in making the commitment to EDP and
MIS. was essentially to replace labor with capital
and Improve productivity. What has happened, however, is that total costs have increased. Even if one
examines only the apparent costs of systems operations
and development the capital/labor ratio advantage has
]VIIS Technology
not materialized; equipment hardware cost continues
to decline as a percentage of the total which includes
systems personnel and administration-today ranging
between 35 and 45 percent. Furthermore, as most of
the trade literature reports, apparent costs are only the
visible portion of the economic "iceberg" in MIS when
we include such hidden cost factors as the drain on
management time, inadequate priority analysis of
competing applications (and the foregone opportunities), abandoned projects due to vacillating support,
security in the EDP department, inefficient software,
etc. The constant advance in the sophistication of the
new technology will continue to raise the economic
stakes for payoff in MIS as this total cost base expands.
Sunk cost notwithstanding, the decision many companies are literally beginning to face is whether or not
they can afford to be in the MIS business.
This economic crossroad in MIS' is not to suggest
that management is contemplating a nostalgic return
to the Dark Ages. More realistically, they are weighing
the practicality of making it themselves or buying it on
the outside. Today information services companies sell
pieces of an MIS; you can buy information problem
solutions as a complete package and for a price contracted in advance. Often this opportunity does not exist
inhouse and cost estimates are notoriously biased. The
large corporations with the requisite capital base and
absolute system constraints will retain inhouse technology for their MIS. Increasing numbers of companies
in the $50 million annual sales or less category, however,
are going to buy their MIS technology over the next
ten years. Few companies today generate their own
electrical power requirements; many companies buy
their legal services as needed; most small companies
buy their accounting services. The distributed data
processing approach will facilitate a comparable
opportunity for EDP technology. Management will
decide how much of it to "buy" and how much to
"make" in establishing an economically viable MIS.
For the data processing industry: establishing the
centers, developing the technology, and regulating
operations will be determined in the market place by
the user or the government or both.
CONCLUSIONS
Having reviewed the state-of-the-art in MIS technology contemporary developments indicate that the
future holds no radical departure in the promise of a
major technological breakthrough, although there will
be change. The MIS as the computer itself is still in its
infancy and progress in design and development is an
1179
evolutionary process that depends on how much is
learned from past mistakes.
Perhaps the most significant change in the future
from the perspective of results will be a reestablishment
of purpose as information structures in lVIIS seek to
solve the bona fide problems of users. In simplified
terms we characterized system technology by the model:
EJ
Decision
Model
of User
j
+
Data
Processing
Support
We further stressed that the many information structures which in aggregate constitute a ]VIIS range in
their sophistication as a descriptor of management
decision processes from a relatively naive "data bank"
model to a complete and closed-loop program for
"automated decision." As developers seek to advance
the state of user model technology the MIS design focus
will shift from a data base orientation to a focus on the
critical decisions of line managers in organizations.
More emphasis will be placed on education of both
system analysts and managers to close the communications gap; design teams will be formed to better utilize
the methods of operations research and management
science. To further increase understanding and acceptance behavioral considerations will assume a
dominant position in development, becoming parameterized where possible to better match the information
structure to the user's problem. The MIS then will
become a portfolio of information structures designed
to solve the information requirements of a hierarchy of
management decision processes.
Data processing support within MIS will also undergo
change over the next decade in an evolution from
current developments. One major outgrowth will be
extension of the distributed data processing approach
to delivering a portfolio of EDP support in ::vns.
Within this framework efforts on integration will
diminish in favor of modularity in design to decouple
and develop relatively independent sub-systems with
well-defined interfaces for plugboard compatibility.
Data management systems will become dedicated to
improve the linkage between data base development
and the user model portfolio's requirements. Communication within the distributed data processing grid
will be over dedicated lines for data transmission or in
some cases by data cassettes. The minicomputer will
become commonplace as "intelligent terminals" in the
grid. Finally, pressured by rising inhouse costs and the
requirement for economic payoff, all but the large
1180
Spring Joint Computer Conference, 1972
corporations will decide to buy their EDP technology
from outside suppliers, in some cases retaining minicomputer terminals as the system connection.
In looking toward the future of MIS technology
then, my view sees payoff and portfolio as the most
descriptive adjectives. To me they are inevitable if
1\IIS in the future is to include progress.
REFERENCES
1 I L AUERBACH
Talk presented at closing session IFIP Congress 71
Ljubljana Yugoslavia August 23-28 1971
2 R W BEMER ED
Computers and crisis
Association for Computing Machinery 1971
3 F W CHURCHMAN A H SCHAINBLATT
The researcher and the manager: A dialectic of implementation
Management Science February 1965
4 M L COLEMAN K W HINKELMAN
W J KOLECHTA
Alcoa picturephone remote information system: APRIS
Presentation at the Fa.ll Joint Computer Conference
Las Vegas Nevada November 16-18 1971
5 G FEENEY
A three-stage theory of evolution for the sharing of computer
power
Computer Decision November 1971
6 R H GREGORY R L VAN HORN
A utomatic data processing
Second Edition Wadsworth 1963
7 D B HERTZ
Systems analysis in urban affairs
Speech delivered in New York City October 19 1967
8 D B HERTZ
Has management science reached a dead end?
Innovation 25 1971
9 P HUGGINS
Comdr Hopper tells users "Dinosaur systems have to go"
Computerworld June 16 1971
10 C H KRIEBEL R L VAN HORN
J T HEAMES ED
Management information systems-Progress and
perspectives
Carnegie Press 1971
11 R MASON
Management information systems-What they are, what they
ought to be
Innovation 1970
12 A NEWELL H A SIMON
Human problem solving
Prentice Hall 1972
13 W F POUNDS
The process of problem finding
Industrial Management Review Fall 1969
14 A N SCHREIBER ed
Corporate simulation models
Graduate School of Business Administration University of
Washington Seattle Washington 1970
15 H A SIMON
The new science of management decision
Harper Brothers 1960
16 V H VROOM P W YETTON
Models of participation in decision-making
Novus December 1971
Selective security capabilities in ASAPA file management system
by RICHARD CONWAY, WILLIAM lVIAXWELL
and HOWARD l\10RGAN
Cornell University
Ithaca, New York
Although the general requirements of data security
in file management and retrieval systems are fairly
obvious, and have been often stated1 •2 current practice
does not provide even an approximation of these requirements and, in fact, current languages and operating systems, with few exceptions3 •4 make it relatively
difficult to achieve these objectives when one tries to do
so. Apparently, current languages and hardware serve
as an informal security and privacy protection system
that is more or less satisfactory for most current applications. While security and privacy controls are often
discussed, they do not appear to be high on most
managers' lists of pressing problems.
The authors' concern with security is limited to the
systems implications which arise when one or both of
the following circumstances exist:
human review of access to the file serve to provide an
informal but adequate security system to protect
against abuse by the information consumer. The programmers and production controllers in such a system,
however, often have considerable freedom to attack
the security or privacy from within. (How many data
processing departments are able to keep salary information from their programmers?)
It is clear that remote access systems represent the
future for such applications-the only question being
how rapidly the future will arrive. It is also clear that
user and problem-oriented languages now exist7 and
once data-consumers have experienced the power and
convenience of these languages they wi1l not willingly
return to a situation in which they are at the mercy
of a staff programmer. Both of these developments
suggest that formal and explicit treatment of the questions of data security is rapidly becoming a necessity.
The following describes the approach to these questions
that has been taken by the authors in ASAP, a file
maintenance and information retrieval system designed
and implemented by the authors.
There are three principal questions associated with
the security of a particular file:
1. A common file is used for two or more different
purposes, e.g., an integrated management information system.
2. A file is directly accessible by those who are
responsible for generating input, and those who
use the information it contains.
Questions of physical security of facilities, tampering
with hardware etc., have been treated elsewhere5 •6 and
will not be discussed here.
At present, the programming languages and operating systems that are used for most file maintenance and
information retrieval applications are sufficiently complex and esoteric that professional programmers and/or
production controllers have been interposed between
the ultimate users of the file and the file itself. Moreover, the majority of such applications are still handled
by relatively conventional batch processing systems,
without remote access devices being placed directly
in the hands of the information supplier or consumer.
Both the physical separation, and the necessity of
1. Which people with physical access to the hardware containing the file should have access to any
particular file?
2. What subset of the file is each authorized user
permitted to access?
3. What types of processing operations are permitted to each authorized user?
ASAP approaches each of these questions by using a
complete directory of authorized users which is appended to the master file in question. While ASAP
cannot prevent the data-set that represents the master
file from being processed by independent programs
1181
1182
Spring Joint Computer Conference, 1972
written in other languages, it can and does supervise
all requests for information entry, update, or retrieval
which are written in the ASAP language, and in doing
so enforces the security restrictions that are explicit in
the user directory. This directory contains, for each
authorized user:
1. "password" identification information.
2. A description of the file subset accessible to this
user.
3. A description of the processing actions this user
is permitted.
RECORD SELECTION
The first method of specifying the subset accessible
to a particular user is to describe which records of the
file are accessible to him. This is done by including in
the directory entry for each user a Boolean expression
that describes by content those records to which he is
permitted access. When a user makes a request, a
monitoring routine based upon this filed Boolean expression is interposed between the file management
utility routine and the user program. The result is unobtrusive, but absolute-the user program only "sees"
records for which the Boolean expression is satisfied;
other records essentially do not exist for this user. The
syntax of ASAP permits the user to easily further
restrict the selection of records from the file, but this
individual Boolean constraint is automatically and
invisibly 'ANDed' to the selection criterion for each
and every request submitted by this user and there is
no way he can override it without going completely
outside of ASAP and obtaining independent access to
the master file.
For example, consider a master student file at a
university in which there is one record for each student.
One user of this file might be the administrative office
of the College of Engineering. (The system is, of course,
quite content with such 'corporate' users, actually
representing a number of different individuals.) The
selection condition for this user would probably be
something like:
COLLEGE = 'ENG'
where COLLEGE is the name of a field in the record
and 'ENG' is one of the possible values of the field.
The user representing the office of the Dean of Women
might be assigned the selection restriction:
SEX='F'
and a user concerned with those football players on
athletic scholarships who are
might be restricted with:
III
academic difficulties
ATHLETICS = 'F'
AND FINANCIAL_AID> 1000.00
AND GRADE_AVG<2.0
A complete program in ASAP could consist of the
following statement:
FOR ALL STUDENTS WITH CLASS='FR',
PRINT LIST: NAME, CAMPUS._ADDRESS,
CLASS_RANK, ORDERED
BY CLASS_RANK;
If this request were submitted by the College of Engineering it would produce a listing of all freshmen
engineering students. Exactly the same request submitted by the Dean of Women would yield a list of all
freshmen women.
While the primary purpose of providing this mechanism is to restrict the distribution of inforrrlation to
those users with a preestablished need-to-know, it has
a secondary effect which may be more important and
interesting than the security aspect for many applications. This is the fact that each user can deal with his
accessible subset of the file exactly as if that constituted
the complete file. He is in every sense unaware of the
existence of other records and can employ the full
facility of the language and the system for his subfile,
without requiring any special treatment because it is
a subfile. This means that most of the difficulties associated with multiple, decentralized files can be avoided
without sacrificing their simplicity of use. One can
avoid the currently typical situation in which an individual student is the possessor of a score or more records
in different and separated files in various stages of u pdate and decay.*
FIELD SECURITY
A second method of defining the subset of the file
accessible to a particular user is to assign different
'security classes' to different fields within each record.
When the record is defined each data element (field) is
assigned to one of nine security classes. One class is
called unrestricted and this is the default when no
* In conventional processing of sequential files the 'invisible'
records in such a system would impose a prohibitive processing
penalty on the user of a small subset. This is avoided in ASAP by
simultaneously processing many independent requests in one pass
through the master file.
Selective Security Capabilities in ASAP
explicit security designation is given; the others are
designated 1, 2 ... 8. The classes are independent,
with no hierarchy implied by the level numbers.
When each user is enrolled in the system the security
classes to which he has access are explicitly listed.
While every user has access to unrestricted information,
access to each of the other three classes must be explicitly granted or denied. Field and record security are
multiplicative-a user may see only authorized fields
in authorized records.
To continue the previous example, the fields of the
student record might be classified in the following way:
Unrestricted information:
Name, campus and home address, telephone,
college, class.
Security Class I-Personal/biographical
information:
Medical history, draft status, disciplinary
actions, race, religious preference.
Security Class 2-Academic information:
Class standing, individual course records,
standardized test scores.
Security Class 3-Financial information:
Treasurer's account, financial aid, family
financial report.
Now the administrative office of the College of Engineering, whose access is already limited to records for
which COLLEGE = 'ENG', could also be limited to the
fields in those records that are unrestricted and class
two information. Fields containing personal and financial information, as well as the complete records for
students not in engineering are inaccessible to this user.
As in the case of record, a significant advantage of
the system is the opportunity to combine several
different types of information in a single master file,
and keep that information out of reach of unauthorized
users, out of the way of users who don't want it, and
still have complete information readily available when
it is required.
RESTRICTION OF PROCESSING OPERATIONS
A third, almost independent type of security concerns the type of actions that a particular user can perform. Actions are classified in the following way in the
ASAP system:
1. Read only access
2. Read/write access to existing records
3. Record creation and deletion
4.
5.
6.
7.
8.
1183
Ability to extend language by adding definitions*
Attach read only external procedures
Attach read/write external procedures
Alter the record definition
Modify the user directory-add or delete users,
or change the security restrictions for existing
users
The directory entry for each user includes a list of the
types of actions that are permitted to this particular
user. Read only access to the accessible fields of accessible records is assumed; all other types of actions
must be explicitly authorized. No hierarchy is implied
in the above list so that, for example, the ability to
extend the language does not imply write access to the
file. t Obviously, the ability to modify the user list
must be granted with great frugality since this implies
the ability to obviate the entire security system.
IMPLEMENTATION
ASAP is a compile-and-go system-each run begins
from source, and security tests are applied at the source
language level. Since no object decks are ever produced
by the system, there can be no opportunity for security
to be obviated by an alteration to the object program.
Although the compile-and-go strategy is unusual in the
data processing environment, it does not exact the
penalty in compilation time that might be expected.
The compiler is very fast, and recompiles source in
time comparable to, if not better than, time required
to load the object modules of a corresponding program.
(On a 360/40 ASAP compiles at card reader speed,
on a 360/65 at 50-100 statements per second.)
The first card of each user program is an identification card bearing the user's password. This is used to
search the user directory for the appropriate entry.
When the user's entry is found, the record selection
condition is passed, in source language form, to the
compiler, along with two bit masks, one for field security, and one which specifies permissible actions.
The record selection condition is compiled into object code that is appended to the file management
utility routines. This code is exercised for each record
of the master file, thus representing some execution
overhead. Since the compiled code is made part of each
*,t In ASAP, users may define report formats, input formats,
codes, and other frequently used constructs. These are then
catalogued for future reference. Often, therefore, users will
extend the language by adding special reports or macros to the
system, an action quite independent of the ability to write on
the master file.
1184
Spring Joint Computer Conference, 1972
selection criterion, however, this often amounts to no
more than two or three machine instructions per record.
Only records that satisfy these conditions are passed
on to the program representing the user-specified
record selection criterion.
Both field selection and action restriction are entirely
exercised at compilation time and represent no execution overhead whatever. Each entry in the symbol
table, e.g., field name, report name, keywords, etc.,
contains a security mask. On each source reference to a
field, the security class of that field is ANDed with a
copy of the current user's security mask, and a simple
test then decides whether or not the field is inaccessible
to the user. If an attempt is made to reference a "classified" field, a condition code is set that the run is
terminated after compilation. When processing definitions of entities which may include information from
several fields, such as reports or summaries, the security
of the report is simply the OR of the security classes of
all fields mentioned. Thus, while each field of a record
may only have a single security class, a report may
require the user to have access to several classes before
he can use it.
The permissible action checking is done in a similar
manner. Each action is tested against the action mask
for the user for whom the code is being generated, and
an improper action will cause the run to terminate after
compilation.
Since references to the symbol table are made for
every symbol scanned, the overhead involved in checking the security classification is rather small. And,
since it is only exercised during compilation, at rather
low cost, a fairly large set of security restrictions can be
enforced.
The different types of security are not quite independent in the ASAP system, although there is no
technical reason why they could not be. When a user is
permitted to attach an external procedure (which may
be written in any programming language) the system
does not attempt to enforce field security. Record security is still effective since the call to the external
procedure is not made until after the record has been
selected for processing. However, once the record is
selected, the entire record is available to the external
procedure. Although it would have been possible to
pass an abbreviated copy of the record in which inaccessible fields had been blanked out, the substantial
overhead this would require was considered unnecessary, since the use of external procedures requires a
special security class which must be approved by the
system controller.
The current implementation also includes a provision
for encrypting the master files. This is performed using
standard cryptographic techniques, with the keywords
based on the system controller's passwords. The cost
for encrypting or decrypting a 500 byte record on a
370/155 is about 500 microseconds of CPU time.
SUMMARY AND CONCLUSIONS
The security provisions of ASAP are rudimentary, but
are relatively simple to understand and use. Since the
language is compiled, rather than interpreted, and
most of the security features are fully exercised at
compilation time, rather than at execution time, the
security aspects of the system are not expensive to use.
It will be interesting to observe in time whether these
simple and inexpensive features of the system will be
widely exploited by users. If not, then perhaps security
considerations have been overemphasized by those in
research and development and do not constitute an
important general problem. If they are used, it is
likely that users will become more sophisticated in
their requirements and these simple classifications may
not long suffice. It is, of course, no problem to increase
the complexity of record selection conditions, or the
number of classifications in either field or action restrictions, but it may turn out that other types of
security exist, with concepts unlike those here.
Clearly, the ASAP security system is mainly designed
to prevent the casual user from gaining access to information he should not see, and the determined professional would have little trouble going around these
security measures, using other languages.
It is interesting to consider the problems of implementing even this rudimentary security system for a
conventional file-that is one created, updated, and
interrogated by programs written in a contemporary
general purpose language (PL/I, COBOL, etc.) and
executed under a standard operating system. One
might then conclude that the task is most formidable,
and that if security is a real problem, the software
now in general use is not up to solving it.
The CODASYL Data Base Task Groups has proposed language extensions which permit one to specify
security and privacy restrictions. They allow for quite
general restrictions, and would probably lead to a far
more costly implementation of security than that of
ASAP. A more general treatment of methods for reducing the cost of information security systems is
forthcoming. 9
REFERENCES
1 L HOFFMAN
Computers and privacy: A survey
Computing Surveys 1 June 1969 pp 85-103
Selective Security Capabilities in ASAP
2 W BATES
Security of computer based information systems
Datamation 16 May 1970 pp 60-65
3 C WEISSMAN
Security controls in the ADEPT-50 time sharing system
Proc AFIPS 1969 FJCC pp 119-133
4 H PETERSEN R TURN
System implications of information privacy
Proc AFIPS 1967 SJCC pp 291-300
5 B ALLEN
Danger ahead: Safeguard your computer
Harvard Business Review Nov-Dec 1968 pp 97-101
1185
6 L MOLHO
Hardware aspects of secure computing
Proc AFIPS 1970 SJCC pp 135-142
7 ASAP system reference manual
Compuvisor Inc Ithaca NY 1971
8 CODASYL Data Base Task Group
October 1969 report
9 R CONWAY W MAXWELL H MORGAN
Security and privacy in information systems: A functional
model
Comm ACM 15 4 April 1972
A graphics and information retrieval
supervisor for simulators
by JAMES L. PARKER
University of British Columbia
Vancouver, Canada
INTEREST IN SIMULATION
for communicating the powers of these simulators to
the people who are really interested.
It is the purpose of this paper to explain an information retrieval and graphics supervisory system which
will accept most forms of simulation and execute them
as subsystems. It provides users with an easy and
flexible way of maintaining the data output from the
simulators and of displaying this information in
graphic and tabular form.
Interest in simulation by computer has grown steadily
over the last ten years. This interest has become even
more strong in the last couple of years with the advent
of popular interest in environmental and social systems.
Frequently the most limiting factor in the simulation
and in the evolution of the techniques of simulation is
not the ability to generate the programs to do the
arithmetic. It is the ability to handle in an easy way
the information flow which results from the simulation
and to provide users-particu1arly those who are not
intimately familiar with computers-an easy versatile,
hands-on way of displaying this information.
The above need is felt in two ways. First when a new
simulator is written a significant portion of the effort
of its design and coding goes into that portion of the
code which maintains the data base on which the
simulator operates. Another significant portion of
effort goes into the system which allows the simulator
to communicate with a user. This repetitious diversion
of energies and money from the primary interest of
the people who write simulators (the arithmetic itself)
is at this time severely limiting the growth of simulators. In addition the lack of easy graphics display
and information retrieval makes it more difficult to
correct and evolve the simulators. One can correct and
calibrate a simulation more rapidly if one can see
exactly what it is doing and if there is a system which
allows a sort of throttle control over the activities of the
simulator.
The current limited usefulness of simulators can
partially be attributed to the fact that the real people
who should use the results of the simulators are people
who are not familiar with computing equipment. They
frequently have only an intuitive feel for what they
would like to display and how they would like to see it.
Most simulators currently built are left to wither in
the academic realm because there is no mechanism
THE lIPS PROJECT (Inter-Institutional Policy
Simulator)
The work that is described in this paper was done
with a particular simulation project in mind, even
though the system itself is not simulator dependent.
This project is the Inter-Institutional Policy Simulator
project financed by Ford Foundation and as a joint
effort between the University of British Columbia, the
City of Vancouver, the Greater Vancouver Regional
Board, and the Province of British Columbia. The
purpose of this project is to involve several diverse
institutions in the development of a simulation which
can then be presented to the various governmental
and social agencies in the Vancouver region. The
project is characterised by having several groups
working on diverse simulators which must interact.
Also its ultimate audience does not in general have a
high familiarity with computers. It is also a, requirement with this system that it be independent of the
types of devices on which output is to be displayed. This
project therefore has made an ideal testing ground for
the ideas presented in this paper since the variety of
people and the variety of simulators involved makes a
maximum test of the design of the system itself.
THE SUPERVISOR FROM THE USER'S POINT
OF VIEW
This description from the user's point of view will
freely use examples based on the regional project being
1187
1188
Spring Joint Computer Conference, 1972
done in the Vancouver area. This means that, because
this simulation is basically over time and subregions
of the study area, the dimensions of time and
region will be used liberally in the following descriptions. As far as the simulator supervisor itself is concerned, time is not a dimension any different from any
other dimension or key in the information retrieval
system. The only exception to this is the fact that the
simulation supervisor does assume that there is one
dimension in the simulation which is unique in that
the policy interventions explained below are over a
certain interval of this dimension. In the vast majority
of simulations being built today this dimension is time,
so there is no confusion. This dimension could just as
easily be distance, however. Let's say that one is
simulat:ng a rocket trip from the earth to the moon.
The dimension chosen might be distance rather than
time. It is conceivable for the simulation of an electronic circuit that this unique dimension would be a
voltage level. In the following discussion, however, it
will always be assumed that this dimension is time
over a subset of regions.
THE INFORMATION BASE
The user of this system sees three things. The primary
aspect of this system from his point of view is a large
data base which represents all of the available information about the system being simulated over a time
interval in years which is chosen by the user. As far
as the user is concerned all of the data base information is always present in the computer files. He simply
has to display whatever aspects of the system are of
interest to him.
The second element which the user sees is called the
policy vector. This is a set of variables each of which
has a name conveniently chosen for the user. The names
themselves may be redefined by the user. Each variable
can take on different sets of values over time. As an
example, the interest rate prevalent in an economic
situation would be a single variable which the user
might want to set to different values for different subintervals of the time span in which he is interested.
These variables which can be set by the user constitute the policy interventions which the user can
make into the model. In this way the user can attempt
to study the effect of certain policy decisions and to see
the differences in the display for different policy values.
Each policy variable has a certain default value at the
time the user begins a session with the simulator. He
can change this default value to any value he chooses
over the entire time interval he is studying or over a
subinterval. Assume that the time interval is 1970-1990
and assume that the initial value for the interest rate
is 7 percent. The user can change this value over the
whole time interval or he can change the value for a
subinterval. For example, he could make the interest
value 8 percent in the interval from 1980-1985. As far
as the user is concerned the current state of the data
base reflects the set of policy values which he has
chosen and they also reflect the total situation over
the whole time interval he is studying. He can also set
the time interval that he wants to study.
The third element available to the user is the command language with which he requests displays and
asks for changes in policy elements. Although these are
the two main functions of the command language there
are many other commands associated with the type
of displays desired, the devices available, and with
saving and restoring portions of the information base.
SOME SIMPLE EXAMPLES
Before describing in more detail the structure of the
information base or the command language, it might
be well to show a couple of examples of the types of
displays a user might request. Let us assume that the
user is aware that the figures for population for a set
of regions in the study area are available in the data
base. Assume that there is one population figure for
each region and each year and one total figure called
POPULATION for each year. In that case, he might
make the following simple display statement.
DISPLAY POPULATION BY TIME
This produces a simple graph shown in Figure 1.
p
o
900
p
800
U 700
L
600
A
500
/"'-/
,/
--_/
",,'"
T
400
I
300
o
200
N
100~"""'~~~
.,.,.,./
--..-_/
/--
1970
/
.,.,.,.-- /____
~
1980
____~____~____~_____
1990
TIM E
Figure I-Simple display of population by time
2000
Graphics and Information Retrieval Supervisor
Then let us assume that the user gives the command
CHANGE INTEREST RATE TO 8 PERCENT
He then repeats the first command. In this case, he
would get the following graph in Figure 2 displaying
the population figures reflecting his policy intervention.
As in indicated later it is possible to split whatever
device he is using for display into several areas. Using
this feature, he could have displayed these two graphs
one beside the other on his screen or his paper. He
could then compare directly the two population figures.
It was also possible for him to give the following
command as his second display command and he would
have the two graphs superimposed over each other.
Thus he could compare them on the same area.
DISPLAY POPULATION BY TIME
SUPERIMPOSED
DISPLAY POPULATION BY TIME
BY INTEREST RATE FROM 7
PERCENT TO 8 PERCENT
This would have produced the graph in Figure 3.
The simple examples give a clue to the power
of the system by showing the direct control the user
has over the actions of the simulator. It also suggests
that there exists a wide variety of types of displays.
The following shows how the user relates these displays
to whatever devices he has available and what display
types are available.
p
p
U
L
A
T
I
0
N
900
800
700
600
500
400
300
200
100
1970
1980
1990
TIM E
Figure 2-Re-display after policy change
p
0
p
U
L
A
T
I
900
Interest=8
800
_ .-Interest=7
700
//
600
./
500
///---/
400
300
0
N
./
/
/---
..--/
/-_/
_/
1970
1980
1990
2000
TIM E
Figure 3-Use of policy intervention in display command
DISPLAY DEVICES
Or he might have given the following single command
which would have produced the same results but with
each graph marked by the corresponding interest rate:
0
1189
2000
The system is set up so that no matter what sort of
device the user is working from he can receive some
type of display. The limits of the display for given
device type are dependent on the quality of display
that the device can support. If the user is sitting at a
teletype, he can receive graphs of whatever resolution
a typewritten line can support. Similarly, if he has a
line printer available to him, he can receive plots on
the line printer. If he has a scope available, then he can
receive his displays with the much greater resolution
and flexibility that a scope allows. Finally if he has a
Calcomp, he can receive the same resolution as that of
the scope but with the limitations that the use of paper
obviously implies. The system as implemented at
U. B. C. supports an Adage type non-storage scope, a
Techronix scope, Calcomp plotters, line printer, 2260
display, teletype or 2741 disp1ays, and a dot printer.
The user has quite a bit of flexibility in the way in
which he can relate his displays to the particular devices. In the above sample command, the defaults were
all in effect so that the user did not have to worry about
assigning the graphs to areas. For a particular device,
the user is allowed to cut the face of the device into
1, 2, or 4 areas. This is most advantageous when using
a Calcomp or storage scope. It is also possible that the
user has more than one device available at any given
time. If he has for example a scope and a Calcomp this
allows him to develop certain images on the scope and
then have them plotted on the Calcomp. In the case
that the user has established multiple areas he must
indicate the area on which he expects a display to
appear. As was evident in the above examples, the
user can cause a new graph to be superimposed on an
old graph or he can start with a completely fresh image
1190
Spring Joint Computer Conference, 1972
in an area. It is also possible in the command language
for him to move a current display from one area to
another. This allows an evolution of a display on a
CRT type device and the creation of hard copy from
a device like a Calcomp. In addition to this the graphic
supervisor is set up so that it provides a memory buffer
of images for each area currently in use. This implies
that whatever images have been created for a given
area, a user can always step back and review a previous
image or move forward and again see the current image.
The number of images contained in the memory buffer
for each area is defaulted to five but it can be changed
by an individual user.
RATES OF DISPLAY
It must be remembered that the whole purpose of
this system is to display information quickly to a
human being and in a form which he finds understandable and pleasing. In light of this it can be observed that a static display is hot in general pleasing
to a human being. It is much more intriguing and
informative to see something that moves. For t,his
reason, the displays on this system have been given a
wide flexibility in the way in which they are displayed
with respect to time. Naturally these methods of
display with respect to time are much more flexible
on a CRT but some of these principles are also applicable to paper graph displays.
Each graph is considered to be a subset of a graph
with four dimensions. It may seem rather surprising
to consider a graph as having four dimensions. However, if one can superimpose several graphs in one
area, one already has three dimensions, as in Figure 3.
In Figure 3, the three dimensions are population, time
and interest rate. Do not confuse time as used here
with the idea of the real time of the person using the
system. Time here is ,simply one of the data variables
from the information base. If a sequence of figures
such as that in Figure 3 could be displayed where each
frame in the sequence corresponds to the given value
of some fourth variable, the display would effectively
be showing the relation of four variables. Not only that,
but it would be showing it in a way that would be
fairly palatable to human understanding. If the user
can see the change in his graphs from one frame to the
next, it is actually a fairly good way of transmitting
information to a person. The idea of the "rate" in
these displays is based on these two ideas~that one
can display a four dimensional graph and that the
graph can be displayed through time.
THE RATE CLAUSE IN THE DISPLAY
COMMAND
The general form of the display commands for graphs
is as follows:
DISPLAY (SEQUENCED) BY X (SEQUENCED) BY Y (SEQUENCED) BY
Z (SEQUENCED) BY T AT RATE R
The above example does not include all of the features
of the DISPLAY command but includes those which
are relevant to the rate of display. It is intended that
the SEQUENCED phrase can occur only in one of the
four positions. These four positions represent the four
dimensions which will appear on the graph. The
variables X, Y, Z and T are to be replaced by data
names from the data base. The form of the display
is determined by which variable has the SEQUENCED
phrase associated with it. If the SEQUENCED phrase
is associated with the last variable T, then the system
merely pauses after each complete frame. Note that
it is possible to have less than 3 dimensions in a given
display command. The rate R is in tenths of a second.
If the word PAUSE is used, then a single frame of the
graph is displayed and the next frame is not displayed
until the user generates an interrupt on whatever type
of terminal he is using. This allows the rate of display
to be completely controlled by the user. He can then
investigate the characteristics of a single frame before
he proceeds to the next frame. Otherwise the image is
built up at whatever rate he specifies. The benefit of
this type of approach is that it allows one to display
more information and to give a person a feeling of
something growing. As the graph emerges, one gets
the feeling of being able to see a process.
The SEQUENCED phrase can also be associated
with any of the earlier dimensions. If it is associated
with the Z dimension, then the individual frame of
the graph is also built up with pauses in between its
parts. Associating the rate with the X dimension also
generates a different pattern or growth of the graph
and different pattern of pausing. This will be particularly beneficial when using the model for instructional purposes, in which people can discuss a set of
policy interventions and then test them out on the
model. At this point one can guess what is about to
happen in the graph as it grows. After seeing part of
the graph one can make predictions as to what will
happen next. This will stimulate discussion and the
use of the individual's imagination as to what the simulator might do. For example, a policy intervention
might require a period of several years in order to take
Graphics and Information Retrieval Supervisor
effect. This will allow people to stop and discuss their
ideas about how long it might be before the policy
takes effect. Since one of the primary purposes of a
simulation like this is to stimulate people's imagination, this rate or throttle control on the graph output
is very valuable. Figure 4 shows the three different
types of growths of graphs which can be displayed. In
the succeeding paragraphs, other types of displays
than graphs will be explained. Some of these can also
have the rate associated with them. At this time no
meaning has been associated with the concept of
putting the SEQUENCED phrase on the Y dimension.
Lines marked with the same number of cross lines
are displayed simultaneously. It is difficult to indicate
motion as below by printing on a static sheet of paper.
TYPES OF DISPLAYS
There are actually more types of displays available
to the user than those indicated above. Any graph may
be superimposed on any other. The five types are:
1.
2.
3.
4.
5.
Map
Point
Line
Bar
Contour
BAR: The bar graph is of a standard form. It is
assumed that if more than two dimensions are ex-
800
VII
V_VI......-- -
700
/
600
III /
400
300
200
11/
IX 700
600
500
v___ VI , / ' V
400
300
IV/
200
~II_III./
100
100
1970
1980
1990
2000
1970
800
800
700
700
600
600
500
500
400
400
300
1980
2000
1990
Sequenced by X; lower line first
then upper line.
Sequenced by Z; both lines
come out slowly together.
200
100
200
100 "----1.._-1-_1...---1.._.........---'
1980
1990
2000
1970
1980
1990
Time frame 1
Time frame 2
Sequenced by T; first frame complete, then second frame complete.
DISPLAY/X/BY/Y/BY/Z/BY/T AS MAP
BAR
LINE
POINT
CONTOUR
See Figure 5.
THE COMMAND LANGUAGE
300
~--I.._..J.---'L....-"""""_...I----'
1970
pressed in the display statement for a bar graph that
the third dimension will indicate different time frames.
It does not make sense to have more than three dimensions for a bar graph.
LINE: The line drawing is just the standard line
graph which has been explained above. This can have
from two to four dimensions.
POINT: If the display command is indicated to be
of type POINT, the first two dimensions are taken to
be the X,Y coordinates of the point. Point data may
or may not be superimposed over a map. If the X and
Y coordinates are the coordinates of some regions on
a map, then it can be superimposed over a map. There
are other cases, for example population versus unemployment over several regions, which would generate
a scatter diagram for all of the points within the
specified time interval and for all of the regions in the
model. In a point graph, if the third dimension is given
it is assumed to be a Z value and the numerical value
is drawn in on the graph at the spot indicated by the X
and Y coordinates. If there is a fourth dimension, it is
assumed to always represent different time frames in a
point graph.
MAP: Maps are generated from files in the data
base which are the output of point digitizing equipment. They are currently all outline maps. Any point
data can be superimposed over an outline map.
CONTOUR: This type of display is generated'from
point data with at least three dimensions. In this case
the first two dimensions indicate the location of point
on the map as in the point graph and the third dimension indicates the value to be used by the contour
generating program. If there is a fourth dimension it
is assumed to represent different time frames as always.
The form of the display command to indicate the
type of display is as follows:
VIII_IX 800
Vill/
I~
IV
500
1191
2000
Figure 4-Different sequences of display using rate with x,
z or taxis
The above examples have given references to various
commands in the language. Although it is not the intention of this document to produce a user's guide to
the language, several commands are explained below
with their features to give an idea of the range and
flexibility of the system.
1192
Spring Joint Computer Conference, 1972
say 'DISPLAY UNEMPLOYMENT/POPULATION
BY TIME,' and this ratio would then be calculated.
It is also possible in a display command to introduce
a policy vector entry. For example:
DISPLAY POPULATION BY TIME
BY INTEREST RATE FROM 8% TO 9%
Figure 5-Map with overlaid contour lines. Contour may be
formed using any data variable from the data base which has
map origins
The commands are broken into three groups: display
and data manipulation commands; systems and graph
manipulation commands; and user aid and text formatting commands.
The display and data manipulation commands are
LIST, DISPLAY, SAVE and RESTORE.
The LIST command has several options. It can list
for the user any of the names in the system, such as
the names of the policy vector interventions available
to the user, the names in the information base, the
file names into which the information base is organized,
or any text replacement names which the user has
defined. The list command can also output data from
the information base in tabular form if this is more
desirable than having it in graphic form.
The options on the DISPLAY command which have
not yet been mentioned are that data may be summarized according to another variable which mayor
may not be in the display. For example, if population
data is present in the information base by region for
display purposes it could be summarized by time so
that a single value would appear for the total study
area for each time interval. Also on anyone of the four
dimensions, limits can be attached by typing FROM
lower limit TO upper limit BY increment, where the
increment value is simply the value used to step from
the lower limit to the upper limit. Soon there will be
added a feature to the system whereby any of the
display dimensions can be replaced by an arithmetic
expression. Then given unemployment, population and
total population available in the data base, one could
It is very likely that the user, after developing a data
base and a set of policies in which he may have invested quite a bit of time and money, may want to
save all or part of the current status of the system. It
is also possible that the user may also want to investigate a decision tree of his own policy strategies and
to compare the results. In order to do this he must
have the capacity to save all or part of the system in
his own private files. This is the function of the SAVE
and RESTORE command. The SAVE and RESTORE
commands can save the total contents of the system,
the contents of anyone of the data files, or the symbol
names that a user may have defined. See below for an
explanation of the user defined symbol names.
SYSTEM AND GRAPH MANIPULATION
COMMANDS
These commands set up the structure of a given
session using the simulator supervisor and alter the
status of the system. The ESTABLISH command
initially indicates which devices are available to the
system and how many areas each device should be
broken into. This allows the use of multiple devices of
different types simultaneously. For example, in one
location in which the system is used, there is both a
storage scope and Calcomp plotter available.
Since each area has a memory buffer, there must be
commands for displaying images stored in this buffer.
These are the GO BACK and GO FORWARD commands. These commands will also transfer an image
from one area to another. This allows one to take a
display from the memory buffer of a scope device and
to display it on hard copy such as a Calcomp.
The ERASE command simply blanks the image on
one area. The primary use comes when the system is
being used for teaching purposes and one wants to have
the viewer's attention directed elsewhere.
The SET command changes a variety of different
system functions and defaults. This is used to set the
number of images contained in the memory buffers,
certain defaults about the way files are to be handled
and so forth.
Graphics and Information Retrieval Supervisor
USER AIDS AND TEXT HANDLING
COMMANDS
The EXPLAIN command can be followed by any
of a variety of names. If it is a name of an item in the
data base, a pre written explanation of this item wi11
appear. If it is a command name, a portion of the
command manual will appear. If an error has occurred
and the command says "EXPLAIN ERROR", a prewritten explanation of the error message will be printed
out.
The HELP command currently supplies the user
with information about where he can obtain various
types of information about the system. It is hoped that
this function will be greatly expanded in the future.
I t is possible for the user to define any character
string as any other character string and to have this
text replacement occur in his command. The ability
to redefine text allows each user to build up during
the session the environment in which he operates. This
means that he can redefine any name in the system to
be a name more comfortable to his own way of thinking.
He can also give names to graph descriptions which
he feels he wants to display frequently. This will be
particularly useful when users begin to generate
arithmetic expressions which they do not want to
repeatedly type out. The commands here are DEFINE, which defines one string as another string for
replacement purposes, i.e.,
1193
THE SUPERVISOR FROM THE SIMULATORS
POINT OF VIEW
One of the primary goals of this system is to make
it very easy to add a new simulator and to minimize
the burden of input/output command parsing and
display on these simulators. For this reason the world
into which the simulator fits is made extremely simple.
As far as the simulator is concerned, the communication with the outside world consists of reading variables
from files which are accessed by a file number and
writing other numbers into other files. In case of an
error there is a routine which is called with an error
message number and which has some macro capabilities. The files that the simulator sees are basically
sequential files with keys allowing either a sequential
or random read or write. The file descriptions which
define the names of the values which will be put in
these values are written out in simple character format
very much like the data description for any high level
language. These file formats are shared by all the simulators in the system at one time, so that one simulator
can read the files generated by another simulator. Since
these file descriptions are in character format, they can
be easily changed and evolved as the simulators themselves evolve. It is only required that (as in FORTRAN
style input and output) the simulator assumes the
function of each variable in each row that it reads in
from the file. For one given file, the simulator must be
aware when it is written that the fourth variable of
this file is population.
DEFINE POP AS POPULATION_VALUES
This would allow the user to use the characters POP
whenever the full name was required. DROP followed
by a string simply drops that string from the replacementtable.
DROP POP
It will frequently be the case that a user discovers
that he wants to name a whole description of a graph.
So it is very convenient to have this built right into
the display command itself. The command is then
DISPLAY followed by the new name followed by the
word AS followed by the usual graph description. This
enters the name given in the replacement table and
enters as its replacement the string describing graph
as below.
DISPLAY P_GRAPH AS POPULATION BY
TIME BY REGION AT RATE 40
MORE DETAIL ON THE INFORMATION
RETRIEVAL SYSTEM
The information retrieval system is really the heart
of the simulator supervisor. It must be able to access
the files by key and it must be able to support a fairly
complicated key structure within the files. For example, there will be files which are indexed by time
and region and there will be some files which will be
indexed only by region. Yet for display it would be
necessary to relate these two files by region alone
ignoring the time key on one of the files. There would
also be files by time and region and other files by time
region, and time of day. This effectively means that
the information system must support a hierarchical
data structure with multiple keys. However, the vast
majority of accesses to the data base by the simulators
are made in a completely sequential fashion. That is,
very little of the structure is used in a hierarchical
fashion. The possibility must be there when it is required.
1194
Spring Joint Computer Conference, 1972
In order to maintain this facility, the information
retrieval system has been structured to operate on
sequential files with fixed length records. These are
designed to look like FORTRAN vectors; they are
just a row of variables. In order to maintain the facility
of multiple keys, each file may have several keys which
are concatenated together to form a single key. If one
wants to generate a facility for accessing the kind of
structure mentioned above where one file is by time
and another by time and region, the implementation
must have two files with the information recorded by
key in each file. To do this key lists are kept for each
file which gives the key value and a line number or
record number for locating the corresponding record.
Since it is possible to change policy variables over
certain intervals of time it is also necessary that there
be a mechanism for invalidating portions of the data
base. For example, if the current data base had been
computed from 1970 to 1990 and the interest rate were
changed in 1980, it would be assumed that some of the
output from some of the simulators would no longer
be correct if they were influenced by the interest rate.
Therefore those files would have to be erased beginning
with 1980. This can be accomplished by simply erasing
the elements in the key list which have year values
after 1980.
This organization of the information retrieval system
allows very simple access routines for the simulator.
Yet it will allow a fairly complex hierarchical structure
of keys if necessary. The fact that the user assumes
all the data to be present at a given time and that the
data is actually computed by the simulators only when
it is requested for a display means that unnecessary
computations never have to be made. Therefore the
information retrieval system must be able to communicate to the supervisor what data is actually
present in a file at a given time.
In order to explain to the system the structure of
the files, and the interdependencies among the simulators for data, there must be a set of simulator descriptions and the file descriptions. These file descriptions as mentioned above are simply lists of the
variable names that will be used by the user for referencing the data. It also includes other characteristics
of the variables such as the maximum value that they
should be allowed to obtain and the minimum. For
each file there is a description of the simulator which
writes the file and how to load that simulator in order
to execute it. There is also a set of simulator descriptions which describe the files each simulator reads.
This is sufficient information for the supervisor to
decide on a given display command what data is. required, what data is missing, which simulators must
be called to generate the data and in what order the
simulators must be called. The rule is that a single file
may be written by only one simulator. This is required
so that the supervisor can tell how to replace data which
has been invalidated by policy changes or which may
never have been computed in the first place. In order
to generate missing data, the supervisor steps through
the years in the current time interval and at each year
runs the simulators required to generate data for that
year. These simulators are dynamically loaded and are
kept in core as long as possible until another simulator
is required to run.
AN OVERALL FLOW DIAGRAM OF
THE SYSTEM
The system is broken up into three major sections
of code. The primary section is the supervisor itself.
This code does the initialization work of reading in all
the tables, reads in each command from the user, and
converts the alphabetic strings in the command to
integers which are merely reference numbers corresponding to the strings. This allows command interpretation to be done very easily. It is at this point that
text replacement is also done. The commands then go
through a large switch to individual subsections of the
supervisor which process each command. The second
section of coding are the I/O routines. These routines
maintain the key lists for the individual files and do all
of the sequential and random reading and writing
requested either by the simulator or by the supervisor.
At the time the simulator originally begins running
it is assumed that each file that is non-empty is in a
read-only master copy. As long as display commands
are generated for these files this read-only copy is
used. As soon as simulator wants to write a file a
scratch copy is made. This copy can either default to
a temporary file or can be put into a private file of the
user, depending on a systems switch. Notice that the
I/O routines, except for saving original data, treat
observed data and simulator output exactly the same.
There is no distinction between data bases which were
USE R
t
COM MIA N D
LANGUAGE
•
GRAPHICS - - DEVICES
SUPERVISOR - - - - - SUPERVISOR
t ----.1__
DATA _ _ _ INFORMATION RETRIEVAL
FILES
SUPERVISOR
____
SIMULATORS
Overall system structure
Figure 6-0verall system structure
Graphics and Information Retrieval Supervisor
originally observed and which are modified by simulators, data bases which were written only by simulators, and data bases which were only observed. This
symmetry of treatment coupled with the ability to
describe files in format-like statements allows the
structure of the files to evolve very easily.
The third piece of code involved is the graphics
supervisor. This section of code maintains the current
state of all of the display devices in the system. It also
maintains the image buffers, the memories for each
area of each display. It is the responsibility of this
section of code to convert a standardized graph description which it receives from the supervisor into
the proper display for each device in the system. It is
also the responsibility of this section of code to OR the
graph images together into single images when superposition has been requested. This part of the program
also does the computations required for contouring
and displaying of bar graphs and so forth.
/o~
Interest rate=7%
Inunigratio~3%
Interest rate=8%
/~ ~
Housing start=ZOO/month
300/month
ZOO/month
ImmigraLo~%
\
Housing starts=lOO/month
1195
EXTENSIONS
The most exciting extensions to this system will be
in the area of providing facilities to the user for developing policy strategies. The first cut in this area
will be to give him the ability to develop a decision
tree of alternatives, and to compare and display data
across these different alternatives. See Figure 7. At
this point it would also be of value to be able to provide
him an analysis of which variables in the data base are
affected and at what level by changes in the policy
variables. At first this can be done on· a guesswork
basis by knowing which data is invalidated by changes
in which policy variables. Later on, however, it may
be interesting to do more in-depth analysis by actually
running the simulators for a short period, noting which
variables change, and attempting to give some indication of the derivatives involved.
What would also be very interesting in this context
is to generate a rudimentary artificial intelligence
device which searches out policies which tend to satisfy
certain goals set up by a user. In this case the interaction between the user's intuition in suggesting goals
and a rudimentary artificial intelligence device might
produce some very exciting results.
CONCLUSION
DISPLAY POPULATION BY TIME
DISPLAY GEOGRAPHICALLY SINGLE_FAMILY_DWELLINGS AS CONTOUR
DISPLAY GEOGRAPHICALLY POPULATION SEQUENCED BY TIME AS CONTOUR
At each level display might be made of population, land use contours. etc.
Figure 7-A possible decision tree for investigating policy
alternatives
It is strongly believed that this system will bring the
power of large interactive computer systems rapidly
to users in two different ways. Primarily, it will provide
an ability for an untrained user to investigate in great
detail and according to his own experience the workings
of a set of simulators. Secondly, by relieving the simulator writers of the burden of providing user interface
and information retrieval it will allow the quality of
the simulators and the types of the simulators themselves to be evolved very rapidly.
NASDAQ-A user-driven, real-time transaction system
by NAT MILLS
Bunker Ramo
Trumbull, Connecticut
one half of a very useful object lesson in the problems
and pitfalls to be met in developing large on-line, realtime systems. The other half of this object lesson would
then be the comparative evaluation of the design options chosen in less fortunate projects where the pit
was fallen into. It would be presumptuous, and certainly not fitting for us to make a critical analysis of
such projects. Therefore, we confine ourselves to presenting the following picture of our own effort.
INTRODUCTION
By Christmas time of 1970, 1200 brokers active in the
Over-The-Counter securities market nation-wide, had
had a new Bunker Tamo CRT terminal placed upon
their desk. Through these "NASDAQ" terminals, they
would be expected to watch and change all their quotations from then on. Within a month, they were confidently using the data in the system, that they were
themselves updating, and turning their backs on almost
all of the previous phone checking and "pink sheets."
By March, 1971, Barron's magazine had reacted to
NASDAQ as follows: "To the amazement of virtually
everyone, the complex network of cables, computers
and cathode ray tubes ... breezed through its shakedown period with scarcely a hitch. What's surprising
(is) ... the almost instantaneeus success and acceptance
NASDAQ has scored."
And before the new year was half gone, the talk had
turned to the feasibility of automating the exchanges
themselves. NASDAQ was becoming a model of how
aptly a computer complex could serve a national trading community.
THE SYSTEM IN PROFILE
The NASDAQ System is a nation-wide, real-time
configuration now serving the quotation needs of the
Over-The-Counter securities market. NASDAQ stands
for the National Association of Securities Dealers
Automated Quotation system. It is centered in a pair
of Univac 1108 multi-processing computers in Trumbull, Connecticut (see Figure 1). Radiating from this
center is a network of data lines to Bunker Ramo
Model 2217 CRT's in the individual offices of sub-
"BEATING THE ODDS" IN REAL-TIME
SYSTEM CREATION
The NASDAQ system is but one of many large realtime, transaction processing configurations that have
been attempted during the past 10 years and in most
cases been completed, sooner or later, during the past
5 years. Many of our computing fraternity (and sorority) have been involved in these efforts, and many
more will be immersed in similar efforts during the next
10 years. In this paper, we are offering the highlights of
our own particular experience, and some of the reasoning behind the course we took, which did "beat the
odds."
In fact, evaluating the design decisions made in
building the NASDAQ system might well be viewed as
Figure 1
1197
1198
Spring Joint Computer Conference, 1972
the recognition that the implementor of NASDAQ
faced a formidable task for several pivotal reasons.
NASDAQ'
~
,"0,,"'"""'_
QUOTES ENTERED
II/QUlllln----+
FULLRETRI£VAL~IU$l>O!lnl
LE~.:rU-:::~'
FOIl"""'"
• NATIONAL ASSOCIATION OF SECUlUTI£S DEALERS AUTOMATED QUOTATIONS
Figure 2
scribers. Controlling and concentrating the traffic in
this network at four regional points are duplicate
Honeywell DDP-516 computers, each with a Bunker
Ramo designed Communication Control Unit as a
front end interface (see Figure 2). In each office being
served is at least one Over-The-Counter Control Unit
(OCU) to support the terminals installed for NASDAQ
(see Figure 3).
At the Trumbull Center, as units integral to the central processor, are a group of auxiliary memory devices
and communication traffic handlers. In the hierarchical
levels of the directly accessi ble storage is held the
on-line data base, from which quotation, index, volume
and other information is retrieved for remote display.
The system restricts to a particular level of terminals
in the offices of market makers and the N ASD itself
the functions of data base updating and control.
Activity is, as of this writing, averaging over 900,000
calls per day, and peaking at busy periods at over 110
calls processed per second. The size and scope of the
system is still expanding. At this point, over 900 offices
are tied into the system, with 1,400 terminals installed.
The data base is built around records for over 2,800
securities, active in the system on the basis of over
19,000 quotations by market makers taking positions
in them. The volume of purchases and sales is being
reported into the system daily and now exceeds that
of all other exchanges combined, except the NYSE.
• The direct users of the system would be brokers
interacting amid their hectic daily trading. They
would be entering, verifying, and retrieving the
data upon which the data base itself would be
built. No trained clerical personnel or computer
operators could intervene.
• The whole process being automated would actually
create an entirely new way of doing business for
the Over-The-Counter Market. No precedents or
earlier system existed.
• To support a viable market, the whole trading
community, nation-wide, had to be on-line together at system start-up.
• A substantial portion of the expected users were
reluctant and skeptical about being supported by
automation. Any failures or ambiguities in function could be expected to be exploited to question
the whole system's utility.
Recognizing the seriousness of these challenges, the
system analysis effort began in earnest.
THE UNIQUE CHALLENGE FACING
IMPLEMENTATION
Of course, this whole system and its functions did not
arise haphazardly. The start of the design effort was
Figure 3
NASDAQ
1199
ESTIMATES OF TRAFFIC LOAD AND MIX
NASDAQ
In the effort to provide a solid basis for all design
decisions, there were studies in the field, simulations,
and functional analyses of many aspects of the processes
NASDAQ would automate. Particularly, in order to
properly select and locate components of the communication network, we needed informed projections of
traffic loads, geographic distribution, and mix of entry
types.
With the decision already made to put the central
site in Trumbull, Connecticut, the heaviest volume of
traffic would obviously be between there and downtown
New York City. Other traffic paths were mapped out
and studied for potential service demand. Then formal
network analysis was applied to the data, using
"COPE," Bunker Ramo's own computerized analysis
tool.
From the functional aspect, observation of O.T.C.
brokers' activities indicated an approximate ratio of
seven to one between the number of requests for the
quotations in a security and the number of updates of
those quotes. The human factors of location, style of
work and data interaction were studied in the actual
trading environment to obtain further data for the design decisions, which are described in the following
sections.
THE CENTRAL SITE CONFIGURATION
For the central processor in the NASDAQ configuration, the Univac 1108 was chosen on the basis of its
already proven reliability and the elements of its design
which expedited real-time operation. Two units, as a
multi-processing complex, were recognized as essential
to carry the system's total processing load, though unit
processing, when necessary, would be sufficient to
maintain all on-line functions.
The total complex is controlled as a configuration
by an Availability Control Unit (ACU), which allocates
facilities in the multi-processing environment (see
Figure 4).
Since swift accessing of a large data base would be
critical, an hierarchy of random access storage devices
was chosen from those in the Univac line. In this case,
a wide range of high-speed and low-speed drums and
common core has provided an adequate supply of random access storage for the data base, programs, tables,
and dictionaries as needed. From these devices, individual record retrievals, program overlays or even remapping core has functioned with speed sufficient to
keep within the specified response time on all
transactions.
CENTRAL COMPLEX
Figure 4
Auxiliary to the central complex is a normal complement of magnetic tape drives, consoles, two Univac
9300 processors driving printers, and card units. For
environmental control, dual air conditioning systems
have· been installed. To assure continuous power, an
Uninterrupted Power Supply (UPS) of batteries and a
gas turbine motor stands by in permanent readiness.
At the center's terminus of the communication network, a Bell System exchange is installed on site,
dedicated solely to handling NASDAQ traffic. Interfaced with the central processors are a pair of communication terminal module controllers (CTMC's)
each with its own set of 16 communication terminal
modules (CTM's) cross-switchable for carrying all
traffic through the appropriate modems to the users via
the regional concentrators and to the auxiliary services
tapping the data base, such as the public quotation
services and newswire distributions.
The upper limit for traffic through this present central
configuration was pegged by original design estimates
at 220 calls per second. However, built into the hardware plan (and the software design as well) is ample
provision for expansion to handle growth in load, and
changes or extensions in function.
THE DECISION TO INSTALL REGIONAL
CONCENTRATORS
Those who have been close to the NASDAQ development effort from the start feel that the most important
1200
Spring Joint Computer Conference, 1972
REGIONAL CONCENTRATOR CONFIGURATION
FROM
a
TO CENTRAL SITE
DUAL 7200bps
TRUNK LINES
DDP-516
BR
BR
FRONT
FRONT
PROCESSOR
END
END
DDP-516
PR.OCESSOR
(MUX)
(MUX)
CROSS -CONNECT
PANEL
REGIONAL
• A pair of unitary configurations each backing up
the other with:
-A Honeywell DDP-516 processor (16K Core)
-A Bunker Ramo designed and built communication front-end interface
-A paper tape reader
-A teletype Model 35 ASR
• Connecting this pair of units with its regional
lines are:
-a cross-connect panel
-two Multiplexer Control Cabinets
-two Modem cabinets
With this concentra tor structure, it was possible to
introduce priority handling and line controls at the
regional level. For instance, full duplex use of the regional circuits became effective with the introduction
of nested polling initiated by the concentrator. With
the multi-station local control units all riding their
assigned regional circuits, polls could be nested into
individual messages and be recognized by the proper
addresses at a great saving in traffic load and message
turn-around time. This technique also tends to equalize
the service for all terminals, by giving priority in the
polling process to control units in offices with multiple
CRT's.
CIRCUITS
1600 bps
Figure 5
single design decision was that made to set-up regional
concentrators for communication processing and polling. The danger of over-burdening the central processing complex with the details of terminal servicing was
recognized early.
The network analysis indicated the economic benefits
of concentrator placement at New York City, Chicago,
San Francisco, and Atlanta. This divided the communication network of leased lines into two levels:
AUTOMATING THE OTC TRADER'S
FUNCTIONS
An often somewhat neglected aspect of system design, the human interface, had to be studied carefully,
• dual trunk lines transmitting point-to-point between the central site and the concentrators synchronously at 4800 bps. (To and from New York
City at 50 K bps.)
• regional circuits between the concentrators, and
the control units in the brokers' offices, transmitting asynchronously at 1600 bps, as private line
multi-point duplex data circuits. (Asynchronous in
order to match the most suitable modem and the
chosen line speed.)
At each regional concentrator site, the following equipment was installed (see Figure 5):
Figure 6
NASDAQ
and be coped with realistically for this project to get
off the ground. The extraordinarily hectic environment
of the trading room of a busy brokerage house has to
be seen and heard to be believed (see Figure 6-an
unbusy example).
Of course, Bunker Ramo has had some experience
in this industry, dating back to 1929 for the first automatic dissemination of quotations. But the direct
input of data by the broker at his desk was something
entirely new, and a somewhat frightening prospect for
seasoned real-time computer professionals.
For NASDAQ, this meant first of all the keyboard
layout, and the ease of entry message generation. Thus,
a unique keyboard was designed from the table up for
this new type of user (see Figure 7), which attempted
to support his manner of operation, and to avoid appearing overloaded and baffling. Special function keys
directly expedite the setting up of certain messages. In
particular, the broker maintaining a quotation in the
system is able to change it rapidly with a few keystrokes, or with little more than a directional character
(i or 1) to cause the normal change of 78th of a
point. Other design advances contributed to an overall
layout which sought to give the user a "congenial"
keyboard. It seems to have succeeded.
The second terminal area to which human factors
concerns were applied was the query/response display
content. Actually the processing logic of the whole
system became query/response oriented by conscious
decision. No demand to respond to computer processes
is put upon the user. The entries the user transmits are
accepted as a whole and displayed as updated for the
user to verify or are rejected with an explanatory message, which does provide some self-teaching interaction.
The effect has been to enable the users to get what
they want from the system with next to no training.
Just behind the individual terminal, supporting up to
24 of them per office, is the O.T.C. Control Unit
(OCU). This unit handles the refresh, character generator and control logic for the CRT's. It also provides
some by-product functions that assist the user. For
instance, it generates a unique office and device address,
which it prefixes to every out-going message, thus ensuring protection to the firm's quotations, and enabling
office oriented services to be selectively implemented
by software processes.
As an example of the flexibility of the OCU, there
was the necessity to cope with a late addition to the
functional requirements as originally specified. Some
brokers wanted to be able to capture the changes in
their own quotations as they were entered into a
NASDAQ terminal, and post them on automated display boards in their own offices. This was implemented
for such users by setting a special bit in the response
which would signal the OCU, and by supplying a
"Local Post" key on the keyboard to permit such local
transmission when desired for non-NASDAQ securities.
This then completes a capsule description of the
major hardware elements at each level of the system.
I t has proved to be a smoothly functioning, coherent
complex. The next sections of this overview deal with
the program structure which made the system function.
SOFTWARE ELEMENTS
The major NASDAQ components
category are the following:
Figure 7
1201
III
the software
• An expanded version of Univac's "EXEC 8"
operating system, supporting multi-thread, realtime transaction processing with queued file accessing and updating. Bunker Ramo extensions to
this system upgraded its real-time communication
control features.
• The necessary set of on-line functional application
programs, processing the full range of acceptable
queries to, and required outputs from, the system.
• A hierarchy of recovery programs, designed to reallocate system elements, to restart, or to drop to
degraded service as necessitated by conditions.
• A series of off-line processing programs to handle
file maintenance tasks, report production, and
pre-processing to optimize the file structure of the
next day's on-line operations.
1202
Spring Joint Computer Conference, 1972
• A communications control program to function in
each of the DDP-516's of the remote concentrator
configurations for:
-polling each control unit and servicing each
regional circuit
-store-and-forwarding message traffic
-managing buffer resources and time clock
functions
-printing out (at NYC) the newspaper transmissions
-monitoring circuits for error rates which might
predict line deterioration, and alerting operations personnel to the need for intervention.
• An overriding time-monitoring program to initiate
at pre-set times various activities such as:
-opening or closing all active securities
-calculating index values
-disseminating data to news media
-halting the volume reporting function
• A many-faceted program providing supervisory
access of several types to the system and its data
as follows:
-on-line entries to cause immediate display or
alteration of file contents
-on-line intervention to change system parameters
or time functions
-on-line entry of file maintenance transactions for
off-line processing
-off-line batched transactions for normal file
maintenance
CREATING A CLEAN MESH OF
SOFTWARE
Developing all the elements of the total software
environment required a staggering amount of coordination and attention to detail. The general principles followed were the standard ones for real-time
programming such as:
-reentrant and reusable code
-dynamic buffering
-program overlays
-record lock-out during update
-automatic system recovery and restart
-queued file accessing within multi-thread logic
-multi-processing utilization of dual processors
On top of taking full advantage of the current "state
of the real-time art," certain solutions to problems
unique to this system deserve mention.
1. The analysis of expected traffic had highlighted
the predominance of quote requests, and among
them, for the "top of the list" for any security,
that is, what would be the first quote frame on
the CRT. The rest of the list of quotations is
obtained frame by frame as a "MORE" key is
pressed. To save processing time with this first
frame frequency, it was decided to keep it always pre-formatted in the security record ready
for immediate transmission.
2. In a similar effort to expedite retrieval response,
the statistics of accesses for each security are
used daily to order the next day's allocating of
the addr~ss keys of the most popular securities
to a core-resident dictionary, and all others to a
drum-resident dictionary.
3. The security of the data base was guaranteed by
the storage of two copies of all on-line files in
cross-drum and cross-channel locations so that
the availability of any record would not be affected by the failure of anyone hardware
component.
4. Buffers are grouped in different sizes and requests are queued first by buffer size needed,
and then shifted away from the longer queues, if
possible, to the queues of the buffers next in
size. Access to a drum record is also shifted to
that copy of the record which resides on the
sub-system with the shorter queue.
The net result of these and many other techniques
has been a quite unflappable system. The meshing of all
the programmed modules was accomplished before
start-up with the usual around-the-clock effort, but
. fortunately with a minimum of unpleasant surprises
and crash patching sessions.
PUSHING EXEC 8 OVER THE HUMP TO
ACCEPTABILITY
Even thouglt the operating system for the Univac
1108 had been around for a while, it was clear fairly
early to the NASDAQ implementors that it had its
weaknesses, and some serious gaps for real-time system
control. Therefore, a special effort was directed toward
identifying all the problems that turned up, and all
potential problem areas as early as possible.
With alacrity and concentration, the Univac program
development staff in St. Paul, Minnesota went to work
NASDAQ
and produced the necessary enhancements. Some of the
improvements, however, were developed by the
NASDAQ crew itself, and most of these were then
adopted as part of official versions of Exec 8.
The most significant modifications and enhancements to Exec 8 were the following:
-Protection against improper mass storage
assignment.
-Ability to optimize drum utilization by using
absolute addressing to allocate or access mass
storage.
-Ability to bring up or shut down I/O paths and
units initially and dynamically.
-The aborting of I/O queues at abnormal program termination to facilitate faster reload.
-Provision for extensive logging and accounting
of I/O error events.
-Ability to get "immediate functions" performed
by the Exec.
-Revising the drum read and write routines to
shift from one in two interleaving up to one for
one interface between drum and core. This particular stratagem significantly improved data
transfer speeds. It had not been regarded as
feasible for the hardware involved, but the step
has proven to be sound.
-Ability to reconfigure any component at any
time with or without manual intervention.
-Applying the processor monitoring capabilities
of the Availability Control Unit (ACU) in order
to detect CPU malfunctions.
-Utilizing automatic reboot, whenever possible,
to reduce the amount of operator intervention
required.
-An automatic dump to high speed drum when
the system has to reboot.
-The detection of a rebooting loop and signaling
for operator intervention.
-The monitoring for, and the correction of a
real-time error loop by automatic program
reload.
-Maintaining a Master Configuration Table in
core and on drum, containing the current status
of the system.
-Ability for an application program to be reloaded
without losing its facilities allocations.
-Entry point to Master Configuration Table to
enable application programs to obtain necessary
recovery data.
-A variety of enhancements of the operator interface with application programs, including a display of the program mix functioning at the time.
1203
-A repertoire of debugging aids such as core and
drum traps, dynamic core and drum dumps,
and a trace routine.
-The development of a "moving picture" of core
displayed on the console CRT. This is a little
gem of a monitor routine for debugging and
analysis work. For instance, the rhythm and
pattern of dynamic buffer allocation could be
observed as its core locations changed on the
display screen.
-A package of test routines to shake down new
levels of the Exec itself.
-A variety of lesser improvements to clean-up
and remove unnecessary code, and generally to
reduce overhead.
It is not too much to say that this effort was as
crucial as any to the success of the total NASDAQ
implementation.
THE TACTICS OF IMPLEMENTATION
The NASDAQ project got under way with the contract signing in December, 1968 between the NASD
and the Bunker Ramo Corporation. The completion
date specified in that contract was two years later to
the day.
Many things had to be set into motion. Hardware
units had to be designed} checked out and scheduled for
assembly line production. A new building had to be
planned and built for the central processor site. Systems design, network analysis, and computer selection
all had to be tackled in short order. The early installation of the central processors was a big help to all
concerned.
One of the things that was not set into motion was
the functional specification after it was carefully elaborated and clarified. Of necessity, it was frozen early
and fortunately was able to stay that way almost
inviolate.
A relatively small crew of engineers, system analysts,
and programmers (approx. 50 in all) was assembled,
mostly from within Bunker Ramo, to tackle the direct
system creation. They turned out to be an extraordinarily dedicated and resourceful crew. Just before
Christmas in 1970 they offered a functioning NASDAQ
to the waiting world. It had arrived only four days
late, and it stayed arrived.
THE PARCEL OF SUBSIDIARY FUNCTIONS
As in most such systems, a variety of subsidiary
functions were included in the functional specification,
1204
Spring Joint Computer Conference, 1972
and then turned out to require a major part of the
effort. These bonus components, all of which were safely
on board when NASDAQ started functioning included
the following:
-A median quote, called the Representative
Bid/ Ask (RBA) , for display on the top line of
every quote frame, and for public dissemination.
-A set of indices for the OTC market, based on
all the stocks in the system, for retrieval and
dissemination.
-The display of news bulletins in response to requests from any terminal.
-The provision of direct transmission of RBA's
and Indices to the quotation and newswire
services.
-A full gamut of overnight off-line processing to
prepare the data base for the next day with all
file changes made, to produce regulatory reports
for the NASD, and to provide statistics on system behavior.
-The support of all varieties of supervisory intervention and file adjustments entered on-line,
with some requiring action immediately on-line
and some held for off-line processing.
This last area generated the largest single module of
programming and required extensive rearrangements
in the overlay logic. These areas as a whole required
more extensive testing than all the rest of the system
combined. In fact, the last critical hurdle before start-up
was the satisfactory completion of that part of the
cycle which went through the off-line processing from
the end of one day into the start of the next day.
THE TEST TO END ALL TESTINESS
To guarantee that the NASD and all its usermembers would find nothing in the system to get upset
about, a frontal attack on all aspects of the system
was mapped out. The functional, supervisory and communication functions in all their complexity required
exhaustive testing. The system's capacity also needed
testing under over-loaded traffic conditions.
How could we throw every possible permutation and
combination of query at the system and verify that we
were getting the correct, prescribed response? The type
and content of the response in turn depended on a
multi-dimensional matrix of conditions, such as the
brokers' type, the status of the security affected, the
time of day, and the other quotations already entered.
In other words, to predict any particular query/
response pair, we would have to establish the content of
the data base at that point in time for that particular
interaction.
Only then could we expect to isolate those responses
which might be proper in form but incorrect in content.
The immensity and crucial role of this stage of the
system's development forced us to become the midwife
of some unique methods to meet the necessity. We
realized from the start that we would have to automate
the process in some fashion in order to avoid the horrendous, error-prone chore of creating exhaustive (and
accurate) test data input.
The possibility of writing a program to generate a
full variety of test input in query form, without responses, proved on examination to demand an extraordinary programming effort, among other drawbacks.
Even to check response messages on a print-out by eye,
or on a dump by programmed comparison were each
clearly prohibitive prospects. There had to be a better,
yet absolutely thorough method of automating the
check-out of system responses.
THE SOLUTION TO OUR PROBLEM
Since 99 percent of the live input data would be
entered via the CRT keyboards, and most of the output
would be displayed on the CRT screens, these terminals
and their control units were the critical messageformatting modules of the system. A processable query
and a displayable response would have to be sent from,
and be returned to, this control unit.
The accuracy of the visual content of keyed entries
could be checked on the display before being sent, and
the content of the resultant response from the system
could be visually verified in the same way.
Could we hold this query/ response pair in their message formats and then, if correct as displayed, capture
the paired record on tape, or if not, divert it for diagnosis? In the second case, the encoded messages would
provide precise evidence for remedial action by either
programming, systems, or hardware design staffs.
The equipment to handle this task was already at
hand in the form of two communication concentrators
located in the Trumbull Data Center, adjacent to the
central processing unit.
Thus for the test, one of these concentrators performed in its actual NASDAQ role,but as the only
active front end for the whole system. Thus the system
configuration and its software did not need to be altered
in any way for test purposes. As far as the NASDAQ
system could tell, it was receiving and responding to
NASDAQ
TEST
[g)
CRT I S
~.
CON ROL II---_~~
UNI
/~_ _ _ _ _~(OCU)
~~~ilW
_ _ _ _ _ _ _ _ _. ._ _ _ _ _ _
LINE PRINTER
NASDAQ
CONFIGURATION
1205
conditions to be amply tested, such as a "delayed
opening" of the market on a particular day.
We were equipped to map into core memory and
drum files a check-pointed or start-of-day on-line data
base which recreated a previous stopping point. Using
this facility, we could push ahead with the testing
effort in several different areas in parallel fashion.
Otherwise with a linear check-out path, each bug would
have hung us up until the necessary program patching
was accomplished.
By allocating a different set of simulated securities to
each major function, we were also able to work around
any buggy area until it was ready to be tested again.
Within each of these allocations, a spectrum of security
types and market maker positions was developed in
order to exercise every conceivable variation.
In addition, we set up separate charts to keep track
of every scripted entry that generated a line on one of
the required off-line, "overnight" reports.
CARRYING OUT THE TEST
Figure 8
genuine activity from real users (see Figure 8 for a
schematic of NASDAQ plus our test configuration).
The second concentrator was programmed as a test
monitor and manipulator. This concentrator had to
function in a two-sided fashion, appearing to the first
concentrator and the central processors just like any
one of many possible control units with terminals. On
its other side, interacting with the test control units, it
behaved as if it were the NASDAQ system itself.
Among other facilities, this enabled us to circumvent
the restrictive integrity of the NASDAQ design, which
accepts file updates only when uniquely identified by
the user's own hardware-supplied address.
For test manipulations in general, this programmed
concentrator gave us the flexible control we needed. Its
program responded to a set of control level entries
from the test CRT terminals to trigger the verification
capture, numbering, and printing, etc., of the test
query/response pairs as created.
Early in the game we decided that we would have to
simulate at least six days of system operation. This
became necessary not only to allow for some gradation
in complexity, but also in order to permit certain global
Anyone who has ever been involved with the demonstration of an on-line process knows what happens next.
With everyone crowded around to watch, the previously infallible gear or program begins to fall apart
with a spectacular display of recalcitrance. Well so it
went. We set the stage, everyone held their breath,
and then the first query we keyed in proceeded to pull
down the whole software structure.
Of course, with only six weeks to go before cutover,
there was consternation, pandemonium, and dire forebodings from all sides. Scrutinizing the wreckage, the
programming team quickly spotted and repaired the
fatal flaw. It turned out to be precisely the type of
problem that live volume testing or actual use would
eventually have hung up on. The unique feature of
that first frame was simply the use, in a particular
function, of a security whose initial letter was beyond
"S" in the alphabet. Our test scripting fortunately had
the range of detailed variation to catch this situation.
When all the smoke had cleared, we resumed our
testing effort and this time the scene settled into a more
normal process.
The check-out continued right up to start-up time,
and helped assure everyone that all was well with
NASDAQ.
ACHIEVING RELIABILITY
The reliability of the NASDAQ system is by now an
accepted fact of life for the OTC market. System per-
1206
Spring Joint Computer Conference, 1972
formance has been on an uninterrupted basis for 99.92
percent of the scheduled time since January 1, 1971
(total down time of one hour and 57 minutes in 2,376
hours of operation).
Reliability is, of course, critical to the success of any
such system after it becomes the functioning structure
of a nation-wide market place. Its realization in the
case of NASDAQ is the result of a web of carefully
designed features.
On the hardware side, it has been due first of all, to
the inclusion of units of already proven dependability
in service. The long evolution of Bunker Ramo's on-line
configurations for the brokerage industry n.ow guarantees the production of terminals, control units and
multiplexers which inherit a built-in reliability.
Bell Telephone lines are another matter, but in this
area also, Bunker Ramo experience has served to enhance reliability. Predictions of line occupancy, by
which selection of lines and transmission speeds were
made, resulted in a communications network, which
has:
• Provided response times averaging well under
three seconds,
• Kept the message error rate, over conditioned
lines, well within agreed limits,
• Provided as yet uninterrupted trunk line service
by establishing dual lines with diverse routing,
• Allowed for future trunk line upgrading as needed,
to 7200 and 9600 bps speeds.
Through the NASDAQ configuration, uninterrupted
hardware performance has been ensured by the doubling of each processing unit for instant fallback support. Likewise, for the software side of NASDAQ,
reliability has been designed into the functioning system itself.
Since non-technical users would be on-line to the
system, entering data and updating files constantly in
real-time, it was necessary to shield the processing
from any disruptive entries. This is maintained by
rigorous programmed control of all input. As a result,
the system has not been "bombed" by any entry since
regular functioning started ..
Finally, the software provides extensive recovery
facilities to get the system back-up and keep it running
under a wide variety of adverse conditions, either
temporary or of some duration. The fact that NASDAQ
has been cited as "an outstanding engineering achievement" is due in large part to this reliability, now fully
proven after nine months of service.
IS NASDAQ INVULNERABLE?
So it does seem as if Bunker Ramo "beat the odds"
with the NASDAQ system. Despite all the things that
could go wrong, everything seemed to click into place
neatly. To observe the system functioning now at the
Trumbull Center is to see nothing happening.
And, in that situation is hidden a new and potentially
serious problem. The operators in the central site cannot avoid becoming extremely bored. There is a danger
that their experience gained with a visibly struggling
and trouble-loaded system in the days before start-up
will now fade completely. What will happen to their
ability to cope with future crises, which will, by that
time, be unavoidably unique and complex? Achieving
such a high level of automation can bring new problems
in its wake. But since this new problem is already
recognized, the remedy is on its way, we hope.
LSI Perspective-The last five years
by H. G. CRAG ON
Texas Instruments
Austin, Texas
INTRODUCTION
reduction of the circuit to circuit transfers required at
the subsystem level. This in turn will greatly reduce the
number of individual packages with their associated
input-output terminations. Thus, it is readily apparent
that',if these higher order circuit functions can be
achieved, today's level of reliability, cost, and size
reduction can be further improved. It is the objective
of this program to develop the technology for such
an approach.
An attempt to write the history of LSI over the past
five years is a difficult task because of the lack of
definition of just what is LSI-LSI means different
things to different people; and there is little documented
evidence on the successes and failures. I believe it is
instructive to look back approximately seven years
from the date of this conference to a document which,
in my opinion, represents the first clear statement of
the requirements for and goals of LSI.
Objective
BACKGROUND
It is the objective of this program to accomplish as
much as a ten-to-one improvement in reliability in
electronic subsystem or systems over that presently
available with today's integrated circuit capability.
It is a further objective to achieve this improved
reliability while simultaneously achieving enhanced
subsystem performance and an overall cost reduction.
These improvements will be accomplished through the
sophisticated use of a large-scale monolithic integrated
circuit array containing up to 1000 circuits utilizing
either metal-oxide-semicondutor (MOS) or bipolar
active devices with associated passive elements capable
of being interconnected to perform logic for data
processing, memory, and/or analog functions."
Several interesting points can be observed in these
statements. First, the reasons for desiring LSI were to
extend the reliability, reduced cost, and improved
density factors that had been observed in the transition
from transistor to integrated circuit equipment.
The second important point was that LSI was defined
as having up to 1000 circuits using either MOS or
bipolar devices for both logic, memory, and even analog
functions.
Three contracts resulted in late 1965 from this Air
Force initiative-one to Texas Instruments, one to
RCA, and another to Philco-Microelectronics. The
major thrust of the Texas Instruments effort was
On June 28, 1965, the Systems Engineering Group,
Research and Technology Division, Air Force Systems
Command issued a request for proposal for Large
Scale Integrated Circuit Arrays. The problem statement
and objective are quoted below.
Statement of the problem
The successful deyelopment, and subsequent production of silicon circuitry, has proven this technology
capable of providing an order of magnitude improvement in reliability of systems utilizing this approach.
Concurrent with this improvement in reliability has
been a continuing reduction in circuit function cost.
This reduction has progressed to the degree that package cost for these circuit functions represents approximately 50 percent of the final cost. It has been further
shown that the intrinsic reliability of. the silicon integrated circuit (SIC) is at least one more order of
magnitude higher than that which is achievable with
the circuits after individual packaging. This indicates
that predominant failures are associated with bonding
and lead failures within the circuit and multilayer
wiring board or interconnection failures at the system
level. These failures can be further eliminated by
1207
1208
Spring Joint Computer Conference, 1972
directed to the discretionary interconnection of the
good cells on a bipolar slice for both logic and memory.
RCA's program was to develop complementary MOS
memory devices, while Phil co-Microelectronics worked
on the development of four-phase MOS shift registers. l
The conference proceedings of the AFIPS conferences
provide a documented history of the computer industry;
and, for this reason, most of my references are from this
source. Many of the papers I will cite have bibliographies which will, in total, give an extensive reference
to the field of LSI.
LOGIC IN LSI
The Proceedings of the Fall Joint Computer Conference of 1965 contain four papers dealing with cellular
type array structures. 2 ,3,4,5 While these structures are
interesting from an academic point of view, it is clear
that the authors were concerned with devising a class
of "standard" circuits which would perform the
combinatorial logic function without a proliferation
of part types.
Both the prospective user and the semiconductor
manufacturer seemed completely preoccupied with
this combinatorial logic problem during the period
1966 through 1968. L. C. Hobbs6 stated in 1966 that
"System designers must consider large-scale integrated
circuits arrays as a new type of device that necessitates
major revisions in systems design concepts, machine
organization, and hardware software tradeoffs." At
the same conference, Michael Flynn 7 made the assertion that "Integrated electronics should be much more
than monolithic circuitry." Flynn believed that better
solutions to the computer users problem would result
if LSI were considered as a new component, and new
computer systems could be devised which were based
on this component.
The problems of unique parts and part types which
LSI generates were studied extensively. Fubini and
SmithS stated that "the total number of unique part
numbers the industry may require for a typical group
of different machine types may be as large as 100,000."
They went on to suggest that the system reorganization
would be useful to reduce this number of part types.
Robert Noyce9 addressed the question of LSI cost
and concluded that "Only standardization, plus the
development of automatic design capabilities, will
make integrated arrays available in the future at a substantial cost reduction compared with today's integrated circuits."
The recognition that an associative memory required standard logic distributed within the memory
prompted several research projects in this technology.
One such program was described by Ryo Igarashi and
Tora Yaita10 in 1967.
LSI MEMORY
Perhaps the seed of the first really successful LSI
was planted when the computer designer's attention
turned from the logic problem to the use of LSI in the
memory function. Gibson'sll paper on "Considerations
in a Block-Oriented System Design" at the SJCC in
1967 discussed how a small but fast memory could be
used to enhance the performance of a large but slow
memory. In retrospect, it is obvious that this paper
describes the "Cache" concept employed by IBM in
some of the 360 and 370 computers. While the devices
used in Mod 85 cache cannot be called LSI, a trend in
the use of higher levels of integration was beginning
to emerge.
At the FJCC of 1968, Conway and Spandorferl2
discussed system enhancement applications for LSI
where complete rethinking of the historical computer
architecture art would not be required. Of the 10
enhancement application areas cited, 5 concerned
random access memories and 1 the use of read-only
memory for microprogramming.
This same conference in 1968 received a paper by
Sanders13 on semiconductor memory circuits and
technology. He stated that "The manufacturing process
for semiconductor memories is characterized by mass
production of similar items." The industry had finally
and clearly identified the first home for LSI! Since
1969, we have seen the cost per bit battle rage between
the semiconductor memory manufacturer and the core
memory manufacturer.
It would appear that most computer systeII).s designers had not considered the significant cost reduction in the total cost of the hardware that would
result by the use of low cost LSI memory devices. While
observing that the memory represents 25 percent
of a computer's main frame, we still struggled with the
problems associated with replacing the 15 percent
cost of the logic. l The core memory manufacturers were
not ignoring this point, however, as core prices dropped
by 30-50 percent during the 1969-1970 period.
Some of the first semiconductor memory devices
were quite small; 16 bits. The technology has developed
to the point where 1024-bit MOS devices and 256-bit
bipolar devices are now being delivered in quantity by
several manufacturers. As these devices contain the
decoding logic, the problem of an excessive number
of pins required for logic LSI has been circumvented.
LSI Perspective
We must conclude that these devices are true LSI as
originally defined by the Air Force in 1965. We can
expect that memory devices of greater capacity will
continue to be introduced over the coming years.
The introduction of the IBM 370/145 with an allsemiconductor memory must establish that this
technology is mature with the only question left being
the upper limits on the number of bits on a chip. The
memory device used is a 128-bit chip with four of these
chips contained within a package giving a package of
512 bits. 1s
LSI LOGIC REVISITED
I wish to return to the question of logic in LSI. The
concept of microprogramming advanced by Wilks16 in
1951 is becoming a reality due to the availability of
LSI read-only memory devices which make microprogramming an economic technique. The large number of mini-computers using microprogramming in
conjunction with an ever expanding family of MSI
logic devices is evidence of this success.
MSI logic devices are now being offered in excess of
100 device types by several manufacturers. These
devices have provided the computer designer with the
capability of designing very compact equipment using
high volume production devices with the resulting
low cost and high reliability. Many of size, cost, and
reliability goals of the original LSI concept have been
approached to a degree that seems to be acceptable
from an engineer's point of view.
The quest for standard logic part types has made
possible a new product that has swept the world in the
last two years. This product is the electronic desk
calculator. These calculators, in general, have one, two,
or three MOS chips which make up the complete logic
and memory function. It is difficult to trace this
development in the computer literature because this
product is not called a "computer." But, when one
considers the complexity levels of the devices used in
these calculators, one must conclude that LSI has
scored another success. A typical single-chip calculator
contains approximately 5000 MOS transistors on a bar
having an area of approximately 25,000 square mils.
This success has come about because there is a high
volume requirement for a small number of part types
having only a few pins. It is reported that 2,000,000
desk calculators of various types will have been produced in 1971. The fact that a device as complex as the
desk calculator can be purchased for a few hundred
dollars should revive the thinking on the distributed
computer concept, but I will leave future projections
to another author.
1209
CONCLUSIONS
I can only conclude that LSI has been a success. When
the manufacturer and the user worked together on real
problems, then truly remarkable feats were accomplished. The one thousand bit memory device and the
desk calculator stand as conclusive evidence. The
search for applications of LSI in the logic section of the
computer goes on and will perhaps find a solution which
has economic justification.
REFERENCES
1 R L PET RITZ
Current status of large-scale integration technology
AFIPS Conference Vol 31 1967 Fall Joint Computer
Conference pp 65-85
2 R C MINNICK
Cobweb cellular arrays
AFIPS Conference Proceedings Vol 27 Part 1 1965 Fall
Joint Computer Conference pp 327-341
3 R H CANADAY
Two-dimensional interactive logic
AFIPS Conference Proceedings Vol 27 Part 11965 Fall Joint
Computer Conference pp 343-353
4 R A SHORT
Two-rail cellular cascades
AFIPS Conference Proceedings Vol 27 Part 1 1965 Fall
Joint Computer Conference pp 355-369
5 B T McKEEVER
The associative memory structure
AFIPS Conference Proceedings Vol 27 Part 1 1965 Fall
Joint Computer Conference pp 371-388
6 L C HOBBS
Effects of large arrays on machine organization and
hardware/software tradeoffs
AFIPS Conference Proceedings Vol 29 1966 Fall Joint
Computer Conference pp 89-96
7 M J FLYNN
A prospectus on integrated electronics and computer
architecture
AFIPS Conference Proceedings Vol 29 1966 Fall Joint
Computer Conference pp 97-103
8 E G FUBINI M G SMITH
Limitations in solid-state technology
IEEE Spectrum May 1967 pp 55-59
9 R N NOYCE
A look at future costs of large integrated arrays
AFIPS Conference Proceedings Vol 29 1966 Fall Joint
Computer Conference pp 111-114
10 R IGARASHI T YAlTA
An integrated MOS transistor associative memory system with
100 ns cycle time
AFIPS Conference Proceedings Vol 30 1967 Spring Joint
Computer Conference pp 499-506
11 D H GIBSON
Considerations in block-oriented systems design
AFIPS Conference Proceedings Vol 30 1967 Spring Joint
Computer Conference pp 75-80
1210
Spring Joint Computer Conference, 1972
12 M E CONWAY L M SPANDORFER
A computer system designer's view of large-scale integration
AFIPSConference Proceedings Vol 33 Part One 1968 Fall
Joint Computer Conference pp 835-845
13 W B SANDER
Semiconductor memory circuits and technology
AFIPS Conference Proceedings Vol 33 Part Two 1968 Fall
Joint Computer Conference pp 1205-1211
14 M G SMITH W A NOTZ
Large-scale integration from the user's point of view
AFIPS Conference Proceedings Vol 31 1967 Fall Joint
Computer Conference pp 87-94
15 J K AYLING R D MOORE
Main monoWhic memory
IEEE Journal of Solid-State Circuits Vol SC-6 No 5
October 1971 pp 276-279
16 M V WILKS
The best way to design an automatic calc'ulating machine
Manchester University Computer Inaugural Conference
July 1951 pp 16-18
Toward more efficient computer organizations*
by MICHAEL J. FLYNN
The Johns Hopkins University
Baltimore, Maryland
second form of parallelism involves the use of multiple
streams in programs.
Two significant trends have evolved which will
substantially effect the nature of computer organizations over the next ten years:
Il\1PLICIT VS EXPLICIT P ARALLELISIVI
1. The almost universal use of higher level programming languages and corresponding decrease
in the use of machine level programming.
2. The continued improvement in cost and performance of both logic and memory technologies.
Implicit concurrency or parallelism may be grossly
characterized as that degree of concurrency, achieved
internal to the processors, which is not visible to its
programmer. Thus explicit parallelism is that concurrency of functional execution which is visible to the
programmer" and demands his attention and exploitation. To date most attempts to take advantage of the
two earlier mentioned trends have used a form of
iIpplicit parallelism. The machine designers attempted
to achieve a certain concurrency of execution which is
transparent to the problem program (machine
language) by "wiring in" the concurrency control and
preserving the use of older machine languages; thus
the existence of the cache type! memory, as well as
heavily overlapped computer organizations. 2
Cache memory involves the use of high speed buffer
memory to contain recently used blocks of main memory storage in an attempt to predict the subsequent
memory usage requirements-thus saving the slow
access time to storage.
The overlap organization involves the multiple
issuing of instructions concurrently. When more than
one instruction is in process at a given time, care must
be taken that the source and sink data are properly
interlocked.
Notice that much of the implicit parallelism is a
direct result of the present -nature of the machine
language instruction. Rather than change the definition
of the present machine language instruction to make it
more complex, the manufacturers essentially standardize
on it and use it as a universal intermediate programming
language. Thus it has the aspect of transportability
not usually found in other languages. Notice the ma-
These trends portend many changes. Most of them
gradual, but certainly effecting the nature and perspective that we currently hold of computer organizations
and their future evolution.
The machine language programmer of today does not
program in assembly code for convenience. He codes
almost exclusively for reasons of efficiency requirements, that is, the control of the physical resources in an
optimal way. Ease of use is not as important a consideration in the development of a machine language
as efficiency. This coupled with technological improvements, especially in the area of memory, portend the
first significant change in computer organizations: the
increase in use of parallel "or concurrent" operation
of the resources of the systems. Since the hardware is
inexpensive, units are made autonomous in the hope
that their concurrent operation will produce more
efficient program performances. "Efficient" in this
sense is the respect to the user program and its performance, not with respect to the busyness of some internal
subcomponent of the system.
There are several forms of parallelism: First, one
may have concurrency of operation within a (internal)
Single Instruction stream-Single Data stream (conventional type) program. In fact, this concurrency may
or may not be transparent to the programmer. The
* This work was supported, in part, by the U. S. Atomic Energy
Commission under contract AT(1l-1)-3288.
1211
1212
Spring Joint Computer Conference, 1972
Accessing Overhead
Fetch I
Decode and
Generate Address
Fetch D
Execute
1
o
1
1
1
1
5
10
15
20
Figure I-Conventional instruction
chine language instruction is not an ideal vehicle to
allow one to control the physical resources of the system since the concurrent control is achieved automatically, without the possibility of any global optimization.
EXPLICIT PARALLELISM*
How can the control of the resources of the system
be made visible to the programmer? First let us review
the evolution of the machine language as we know it
and compare it with microprogrammed systems.
An essential feature of a microprogram system is the
availability of a fast storage medium. "Fast" in this
sense is used with respect to ordinary logical combinational operations. That is, the access time of the storage
device is of the same order as the primitive combinational operations that the system can perform-the
cycle time of the processor. Another important attribute of modern microprogrammed systems is that this
"fast" storage is also writable, establishing the concept
of "dynamic microprogramming." It is the latter that
distinguishes the current interest in microprogrammed
systems from earlier attempts using READ-ONLY
memory.3-5 Consider the timing chart for a conventional
(nonmicroprogram) machine instruction (Figure 1).
Due to slow access of instruction and data, a substantial
amount of instruction execution time is spent in these
overhead operations. Contrast this with the situation
shown in Figure 2, illustrating the microprogram's
instruction. In Figure 2 there is an implicit assumption
of homogeneity of memory, that is, that data and
operands are all located in the same fast storage as the
instructions. The latter assumption is valid when the
storage is writable.
The preceding implies another significant difference
in conventional machines and microprogrammed machines-the power of the operation to be performed by
* The remarks on microprogramming are abstracted from
Reference 15.
the instruction. In the conventional machine, given
the substantial accessing overhead, it is very important
to orient the operation so that it will be as significant
as possible in computing a result. To do otherwise
would necessarily involve a number of accessing overheads; thus we have the evolution of the rich and
powerful instruction sets of the second and third
generation machines. With dynamically microprogrammed systems (Figure 2), the powerful operation
will do no more than a sequence of steps. Indeed, the
rich instruction operation may (if its richness is done
at the expense of flexibility) cause an overall degradation in system performance.
EXPLICIT INTERNAL PARALLELISM
(see Figure 3)
In the traditional system, since the overhead penalties
are so significant, there is little real advantage in keeping the combinational resources of the system simultaneously busy or active. This would mean that perhaps
17 or 18 cycles would be required to perform an instruction rather than 20-hardly worth the effort. A
much different situation arises with the advent of
dynamic microprogramming. 6 Consider a system partitioned into resources, e.g., adder, storage resources,
addressing resources, etc. If the microinstruction can
be designed in such a fashion that during a single
execution one can control the flow of data internal to
each one of these resources, as well as communicate
between them, significant performance advantages can
be derived. Of course these advantages come at the
expense of a wider microinstruction. The term horizontal microinstruction has been coined to describe
the control for this type of logical arrangement.
RESIDUAL-CONTROL IN DYNAMIC
MICROPROGRAMMING
The preceding scheme sacrificed storage efficiency in
order to achieve performance. Schemes which attempt
Control
Access
I
CD®@
I
I
Execute
I
I···
CD®@
I I I
I
o
Figure 2-Microprogrammed execution
I
5
Toward More Efficient Computer Organizations
to achieve efficiencies both in storage and performance
can be conceived, based upon an information theoretic
view of control and storage. Much information specified
in the microinstruction is static, i.e., it represents
environmental information. The status remains unchanged during the execution of a number of microinstructions. Many of the gating paths and adder
configurations remain static for long periods of time
during the emulation of a single virtual machine. If this
static information and specification is filtered out of the
microinstruction and placed in "setup" registers, the
combination of a particular field of a microinstruction
with its corresponding setup register, would completely
define the control for resource (Figure 4). This sacrifices
nothing in flexibility-it allows for a more efficient use of
storage.,
~
1213
} DRe~~u~ce
0
~
CB
Resource
no. 2
Residual
Micro-Instruction
Set-Up
Register
•
•
•
Figure 4-Residual control in microprogramming
EXTERNAL P ARALLELIS1VI-SIl\1D
Explicit parallelism may be internal as in the earlier
discussion or external, that is, where the programmer
directly controls a number of different items of data
(Data Streams) or has a number of programs
executed simultaneously (Instruction Streams). We
refer to the first type of organization as a single instruction stream, multiple data stream (SIMD).2 There are
three kinds of SIMD machine organizations currently
under development: (1) the array processor,7 (2) the
pipeline processor, 8 (3) the associative processor. 9
Resource
no. I
M icroInstruction
Register
",
\.
\. -... ~ontrol
\
Resource
Lines
\
no. 2
\
\
\
Data Paths
\
\\_____1Il
LJ .- - - -'
Resource
•
•
Figure 3-Simultaneous resource management
no. 3
While these systems differ basically in their organization of resources and their communication structures,
their gross programming characterizations are quite
similar. One instruction is issued for essential concurrent
execution on a number of operand data pairs. Figure
5 illustrates each of the three organizations. In the array
processor the execution resources are replicated n
times. Since each set of resources is capable of executing an operand pair, in a sense each resource set
is an independent slave processor. It may indeed (and
usually does) have its own private memory for holding
operand pairs. Since each processing element is physically separate, communications between the elements
can be a problem. At least it represents an overhead
consideration.
The pipelined processor is in many ways similar to the
array processor, except that the execution resources are
pipelined. That is, they are staged in such a way that
the individual staging time for a pair of operands is
lin of the control unit processing time. Thus n pairs of
operands are processed in one control unit time. This
has the same gross structure (from a programming
point of view) as an array processor. But since the pairs
of operands reside in a common storage (since the
execution units are common) the communications
overhead occur in a different sense. It is due to required
rearranging of data vectors in proper order so that they
may be scanned out at a rate compatible to the pipelined
rate of the execution resources.
Both array processors and pipelined processors work
over directly addressed data pairs. Thus, the location of
each pair of operands is known in advance before
being processed .
The associative processor is similar in many ways
to the array processor except that the execution of a
1214
Spring Joint Computer Conference, 1972
Control
Unit
1•
Communi cot ion
a
•••
I
Processing
Element
PE
Memory
Memory
I
PE
Memory
.
N Universal Execution Resources
Control
(a) A rray Processor
Unit
Control
Unit
Memory
staged
dedicated
resources
(c) Associative Processor
stage delay.
execution time In
(b) Plpelined Processor
Figure 5-Some idealized SIMD processor (a, b, & c)
control unit instruction is conditional upon the slave
unit matching an inquiry pattern that is presented to
all units. Matching here should be interpreted in a
general sense, that is, satisfying some specified condition
with respect to an inquiry pattern. Each slave unit
contains at least one pattern register which is compared
to the inquiry prior to conditional execution.
Each of these processor types performs well within a
certain class of problem. The dilemma has been to
extend this class by restructing algorithms. It has been
suggested (by M. :l\1insky,17 B. Arden, et al.) that
instead of an ideal of n fold performance (on data
streams) improvement over a sequential processor, the
SIMD processor is more likely to realize
exciting new developments are occurring in the multiprocessor organization through the use of shared
resources.
Two traditional dilemmas for a multiprocessor
(MIMD) computer organization are: (1) that of improving performance at a rate greater than linear with
respect to the increasing number of independent
processors involved, and (2) providing a method of
dynamic reconfiguration and assignment of the instruction handling resources to match changing program environments. Shared Resource Organizational
arrangements may allow solution of these problems.
SHARED EXECUTION RESOURCES
Perf~log2 n
A possible rational for this is discussed elsewhere. I6
EXTERNAL PARALLELISM-MIMD
The multiple instruction-stream multiple data-stream
programs are merely statements of independency of
tasks-for use on "multiprocessors." I believe that
The execution resources of a computer (adders,
multiplier, etc.-most of the system exclusive of
registers and minimal control) are rarely efficiently
used. This is especially true in modern large systems
such as CDC7600 and IBM Model 195. Each execution
facility is capable of essentially processing, at the
maximum ra,te, an entire program consisting of instructions which use that resource. The reason for this
Toward l\1ore Efficient Computer Organizations
design is that, given that instruction I i-I required a
floating point add type resource, it is probably that L
will also-rather than, say a Boolean resource. Indeed
the "execution bandwidth" available may exceed the
actual instruction rate by a factor of 10.
Another factor aggravating the above imbalance is
the development of arithmetic pipe lining internal to the
resources. In these arrangements, the execution function itself is pipelined, as per the pipeline processor.
This provides a more efficient mechanism than replication for attaining a high execution rate.
~
_ _ _ S kel,ton processor
r
q
PiP~line
factor
upto
K simultaneous
requests
qm
f------l Instruction Counter
Buffer
accumulator
I
Instruction
Instruction Register
D
In'dex Registers
Buffer or
Cache
Figure 6a-Skeleton processor
Pipel ined
Execution
RI
Units
K
SKELETON INSTRUCTION UNITS
Data
l~
r,'
r
Rings
In order to effectively use this execution potential,
we postulate the use of multiple skeleton processors
sharing the execution resources. A "skeleton" processor
consists of only the basic registers of a system and a
minimum of control (enough to execute a load or store
type instruction). From a program point of view,
however, the "skeleton" processor is a complete and
independent logical computer.
These processors may share the resources in space,10
or time.u· 12. 13 If we completely rely on space sharing,
we have a "cross-bar" type switch of processors-each
trying to access one of n resources. This is usually unsatisfactory since the "cross-bar" switching time overhead can be formidable. On the other hand, time phased
sharing (or time multiplexing) of the resources can be
attractive, in that no switching overhead is involved
and control is quite simple if the number of multiplexed
processors are suitably related to each of the pipelining
factors. The limitation here is that again only one of
the m available resources is used at anyone moment.
We suggest that the optimum arrangement is a
combination of space-time switching (Figure 6). The
1215
1~{ ~
r
Rm
Figure 6b-Time-multiplexed multiprocessing
time factor is the number of "skeleton" processors
multiplexed on a time phase ring while the space factor
is the number of multiplexed processor "rings," K,
which simultaneously request resources. Note that K
processors will contend for the resources and, up to
K-l, may be denied serivce at that moment. Thus
rotating priority among the rings is suggested to guarantee a minimum performance. The partitioning of the
resources will be determined by the expected request
statistics.
SUB-COMMUTATION
When the amount of "parallelism" (or number of
identifiable tasks) is less than the available processors,
we are faced with the problem of speeding up these
tasks. This can be accomplished by designing certain
of the processors in each ring with additional staging
and interlock14 (the ability to issue multiple instructions
simultaneously) facilities. The processor could issue
multiple instruction execution requests in a single
ring revolution. For example, in a ring of N = 16
-8 processors could issue two request/revolutions or
-4 processors could issue four request/revolutions or
-2 processors could issue eight request/revolutions
or
-1 processor could issue sixteen request/revolutions.
This partition is illustrated in Figure 7.
1216
Spring Joint Computer Conference, 1972
LJLJ
Ring/~/~
0'
Resources
onl y 4 processors
active I
J
(I instrJction resource
/
access per 4 time slots) /
by simply waiting in turn as each request was processed.
Today's situation requires scheduling essentially 1,000
times more sophisticated. In other words, if more than
one instruction in 1,000 requires a machine to go to an
idle state, we would have the same system performance,
as we had in 1955. Thus the nature of the dilemma. If a
technological solution, on the other hand, could be
achieved with low latency for accessing large data sets,
the whole need for sophisticated operating systems to
sustain job queues and I/O requests would be diminished if not eliminated altogether. A great deal of time
and money has been spent in analysis and synthesis of
complex resource scheduling, resource control operating
systems. I surmise that if a small fraction of these
resources had been directly addressed to the physical
problem of latency, physical solutions would have been
found which would have resulted in much more efficient
systems.
This remains one of the great open challenges of the
next five years.
Figure 7-Sub-commutation of processors on a ring
CONCLUSIONS
IMPLEMENTATION AND SIMULATION
A proposed implementation of this shared resource
multiprocessor is described elsewhere, together with a
detailed instruction by instruction simulation. 13
The system consisted of eight skeleton processors
per ring and four rings per system. The execution resources were generally pipelined by eight stages. The
proposed system had a maximum capability of over
about 500 million instructions per second and was
capable of operating at over eighty percent efficiency
(i.e., performance was degraded by no more than 20
percent from the maximum).
THE TECHNOLOGY OF OPERATING SYSTEMS
Yet another type of parallelism involves the concurrent management of the gross (I/O, etc.) resources
of the system by the operating system.
The evolution of very sophisticated operating systems
and their continued existence is predicated on one
essential technological parameter: the latency of access
of data from an electro-mechanical medium. Few other
single parameters in computing systems have so altered
the entire face and approach of computing systems.
Over the period of time, 1955 to 1971, access time to a
rotating medium has remained essentially constant
between 20 to 100 m seconds. Processing speeds, on the
other hand, have increased by almost a factor of 10,000.
Thus, originally we had a very simple system of scheduling. Data sets and partitions of programs were processed
With the adoption of higher level languages for user
convenience and the evolution of machine language for
efficient control of resources, a departure in user
oriented machine level instructions is seen. This coupled
with the increasing performance of memory portends a
major shift in the structure of the conventional machine
instruction. A new structure will allow the program
explicit control over the resources of the system.
With the increasing improvement in logic technology
cost-performance, more specialized and parallel organizations will appear. For specialized applications
SIMD type organization in several variations will
appear for dedicated applications. The more general
organization MIMD (particularly of shared resource
type) appeared even more interesting for general
purpose applications.
The major technological problems for the next five
years remain in the memory hierarchy. The operating
systems problems over the past years are merely a
reflection of this. A genuine technological breakthrough
is needed for improved latency to mass storage devices.
REFERENCES
1 D GIBSON
Considerations in block-oriented system design
AFIPS Conf Proceedings Vol 13 pp 75-80 '
2 M FLYNN
Very high-speed computing systems
Proceedings of the IEEE Dec 1966 p 1901
Toward More Efficient Computer Organizations
3 M V WILKES
The growth of interest in microprogramming-A literature
survey
Computing Surveys Vol 1 and 3 Sept 1969 pp 139-145
4 M J FLYNN M D MAcLAREN
Microprogramming revisited
Proceedings Assoc Comput Mach National Conference 1967
pp 457-464
5 R F ROSIN
Contemporary concepts in microprogramming and emulatim
Computing Surveys Vol 1 and 4 Dec 1969 pp 197-212
6 R W COOK M J FLYNN
System design of a dynamic microprocessor
IEEE Transactions on Computers Vol C-19 March 1970
pp 213-222
7 G H BARNES et al
The Illiac IV computer
IEEE Transactions on Computers Vol C-17 No 8 August
1968 pp 746-757
8
CDC STAR-100 reference manual
9 J A GITHENS
An associative, highly-parallel computer for radar data
processing
Parallel Processor Systems L C Hobbs et al Editors Pub
Spartan Press NY 1970 pp 71-86
10 P DREYFUS
Programming design features of the GA_MMA 60 computer
Proc EJCC Dec 1958 pp 174-181
1217
11 J E THORTON
Parallel Operation in Control Data 6600
AFIPS Conference Proceedings Vol 26 Part II FJCC 1964
pp 33-41
12 R A ASHENBRENNER M J FLYNN
G A ROBINSON
Intrinsic multiprocessing
AFIPS Conference Proceedings Vol 30 SJCC 1967 pp 81-86
13 M J FLYNN A PODVIN K SHIMIZU
A multiple instruction stream processor with shared resources
Proceedings of Conference on Parallel Processing Monterey
California 1968 Pub Spartan Press 1970
14 G S TJADEN M J FLYNN
Detection and execution of independent instructions
IEEE Transactions on Computers October 1970 Volume
C-19 No 10 pp 889-895
15 M J FLYNN R ROSIN
Microprogramming: An introduction and a viewpoint
IEEE Transactions on Computers July 1971 Vol C-20 No 7
pp 727-731
16 M J FLYNN
On computer organizations and their effectiveness
IEEE Transactions on Computers To be published
17 M MINSKY S PAPERT
On some associative, parallel, and analog computations
Associative Information Techniques Ed by E J Jacks Pub
American Elsevier 1971
AMERICAN FEDERATION OF INFORMATION PROCESSING
SOCIETIES, INC. (AFIPS)
AFIPS OFFICERS AND BOARD OF DIRECTORS
President
V ice President
Mr. Keith Uncapher
The RAND Corporation
1700 Main Street
Santa lVIonica, California 90406
Secretary
Dr. Donald Walker
Artificial Intelligence Group
Stanford Research Institute
Menlo Park, California 94025
Mr. Walter L. Anderson
General Kinetics, Inc.
11425 Isaac Newton Square, South
Reston, Virginia 22070
Treasurer
Dr. Robert W. Rector
University of California
6115 Mathematical Sciences Building
Los Angeles, California 90024
Executive Director
Dr. Bruce Gilchrist
AFIPS
210 Summit Avenue
Montvale, New Jersey 07645
ACM Directors
Mr. Walter Carlson
IBM Corporation
Armonk, New York 10504
Mr. Donn B. Parker
Stanford Research Institute
Menlo Park, California 94025
Dr . Ward Sangren
The University of California
521 University Hall
2200 University Avenue
Berkeley, California 94720
IEEE Directors
Dr. A. S. Hoagland
IBM Corporation
P.O. Box 1900
Boulder, Colorado 80302
Dr. Robert A. Kudlich
Raytheon Co., Equipment Division
Wayland Laboratory
Boston Post Road
Wayland, Massachusetts 01778
Professor Edward J. McCluskey
Stanford University
Department of Electrical Engineering
Palo Alto, California 94305
Simulations Council Director
Association for Computation Linguistics Director
Mr. Frank C. Rieman
Electronic Associates, Inc.
P.O. Box 7242
Hampton, Virginia 23366
Dr. A. Hood Roberts
Center for Applied Linguistics
1717 Massachusetts Avenue, N.W.
Washington, D.C. 20036
A merican Institute of A eronautics and
Astronautics Director
American Institute of Certified Public
Accountants Director
Mr. Frank Riley, Jr.
Auerbach Corporation
1501 Wilson Boulevard
Arlington, Virginia 22209
Mr. Noel Zakin
Computer Technical Services
ACIPA-666 Fifth Avenue
New York, New York 10019
American Statistical Association Director
American Society for Information Science Director
Dr. Mervin E. Muller
5303 Mohican Road
Mohican Hills
Washington D.C. 20016
Mr. Herbert Koller
ASIS
1140 Connecticut Avenue, N.W. Suite 804
Washington, D.C. 20036
Instrument Society of A merica Director
Society for Industrial and Applied Mathematics Director
Mr. Theodore J. Williams
Purdue Laboratory for Applied Industrial Control
Purdue University
Lafayette, Indiana 47907
Dr. D. L. Thomsen, Jr.
IBM Corporation
Armonk, New York 10504
Society for Information Display Director
Special Libraries Association Director
Mr. William Bethke
RADC (EME, W. Bethke)
Griffis Air Force Base
Rome, New York 13440
Mr. Burton E. Lamkin
Office of Education-Room 5901
7th and D Streets, S.W.
Washington, D.C. 20202
JOINT COMPUTER CONFERENCE BOARD
President
A CM Representative
Mr. Keith W. Uncapher
The RAND Corporation
1700 Main Street
Santa Monica, California 90406
Mr. Richard B. Blue Sr.
1320 Victoria Avenue
Los Angeles, California 90019
V ice President
Mr. Walter L. Anderson
General Kinetics, Incorporated
11425 Isaac Newton Square, South
Reston, Virginia 22070
Treasurer
Dr. Robert W. Rector
University of California
6115" Mathematical Sciences Building
Los Angeles, California 90024
IEEE Representative
Mr. Stephen S. Yau
Northwestern University
Evanston, Illinois 60201
SCI Representative
Mr. Paul Berthiaune
Electronic Associates, Inc.
West Long Branch, New Jersey 07764
JOINT COMPUTER CONFERENCE
COMMITTEE
JOINT COMPUTER CONFERENCE TECHNICAL
PROGRAM COMMITTEE
Mr. Jerry L. Koory, Chairman
H-W Systems
525 South Virgil
Los Angeles, California 90005
Mr. David R. Brown, Chairman
Stanford Research Institute
333 Ravenswood Avenue
Menlo Park, California 94025
FUTURE JCC CONFERENCE CHAIRMAN
Dr. Robert Spinrad
Xerox Data Systems
701 South Aviation Blvd.
EI Segundo, California 90245
1972 SJCC STEERING COMMITTEE
General Chairman
John E. Bertram
IBM Corporation
V ice Chairman
Emanuel S. Savas
The City of New York
Secretary
Carole A. Dmytryshak
Bankers Trust Company
Charles G . Van Vort-Chairman
Society of Automotive Engineers
Allan Marshall-Vice Chairman
Society of Automotive Engineers
Exhibits
J. Burt Totaro-Chairman
Datapro Research
John L. Sullivan-Vice Chairman
Hewlett-Packard Company
Special Activities
Controller
F. G. Awalt, Jr.
IB1VI Corporation
Techn~'cal
Conference Publications
Program
Jacob T. Schwartz-Chairman
Courant Institute
New York University
Kenneth M. King-Vice Chairman
City University of New York
Robert J. Edelman-Chairman
Western Electric Company
R. C. Spieker-Vice Chairman
A.T.&T. Company
Public Relations
Walter C. Fleck
IBM Corporation
A CM Representative
Member
Donald L. Thomsen, Jr.
IBM Corporation
Paul M. W odiska
Hoffman La Roche
IEEE Computer Society Representative
Local Arrangements
Dorothy I. Tucker-Chairman
Bankers Trust Company
Seymour Weissberg-Vice Chairman
Bankers Trust Company
Registration
Jerome Fox-Chairman
Polytechnic Institute of Brooklyn
Sol Sherr-Vice Chairman
North Hills Associates
Stephen Pardee
Bell Telephone Laboratories
SCI Representative
Arthur Rubin
Electronic Associates, Inc.
JCC Committee Liaison
Harry L. Cooke
RCA Laboratories
SESSION CHAIRMAN, REVIEWERS AND PANELISTS
SESSION CHAIRMEN
Aho, Alfred
Belady, Laszlo A.
Bell, James R.
Carroll, Donald C.
Chang, Sheldon S. L.
Conte, Samuel D.
Crocker, Stephen
Denning, Peter
Dolotta, T. A.
Flores, Ivan
Flynn, Michael J.
Fosdick, Lloyd D.
Fuchs, Edward
Gale, Ronald M.
Galler, Bernard
Genik, Richard J.
Graham, Robert
Gross, William A.
Hamblen, John
Karp, Richard
Kurtz, Thomas
Lehmann, John R.
Lewin, Morton H.
Merwin, Richard
Morris, Michael
Newton, Carol M.
Papert, Seymour
Pennington, Ralph
Potts, Jackie S.
Radke, Charles
Ramsay, W. Bruce
Rosen, Saul
Sammet, Jean
Schwartz, Jules I.
Sonquist, John
Stenberg, Warren
Sturman, Gerald
Traub, Joseph F.
Zimbel, Norman S.
REVIEWERS
,
Ackerman, Eugene
Agnew, Palmer
Anderson, Sherwood
Atkinson, Richard C.
Baldwin, John
Barry, Patrick
Bartlett, W. S.
Bayles, Richard
Bellucci, Jim
Bernstein, Morton I.
Bork, Alfred
Brawn, Barbara S.
Bredt, Thomas H.
Brender, Ronald
Bryan, G. Edward
Cannizzaro, Charles
Carter, William
Cederquist, Gerald N.
Chang, H.
Chapman, Barry L.
Cheng, David D.
Chu, W. W.
Dorato, Peter
Earley, Jay
Elashoff, Robert
Enger, Norman
Ferrari, Domenico
Fischer, M. J.
Follett, Thomas
Fox, Margaret R.
Fraser, A. G.
Freiman, Charles
Frye, Charles
Fuller, Samuel H.
Garland, Stephen J.
Gebert, Gordon
Gee, Helen
Gelenbe, S. E.
Gorenstein, Samuel
Graham, G. Scott
Graham, Susan
Gray, James N.
Griffith, John
Halpern, Mark
Halstead, Maurice
Hamilton, James A.
Harker, J.
Harrison, M. A.
Hebalkar, Prakash
Hennie, F. C.
Hight, S. L.
Hildebrand, David B.
Hochdorf, Martin
Hoffman, David
Hsiao, Mu Y.
Huseth, Richard
Jessep, Donald C.
Kaman, Charles
Karp, Peggy
Katzenelson, Jacob
Keller, Robert M.
Kirn, Fred L.
Kohlhaas, Charles A.
Kosinski, Paul
Laurance, Neal L.
Lavenberg, Stephen S.
Lechner, Bernard
Lehman, Meir M.
Levy, S. Y.
Lundquist, Alfred
MacDougall, M. H.
Marks, Gregory A.
Martin, R. L.
Mayham, Albert
McClung, Charles R.
Meissner, Loren
Miller, Edward F., Jr.
Moore, Scott E.
Morris, James
Mulford, James
Ninke, William
Oehler, Richmond
Oliver, Paul
Paige, M. R.
Peng, Theodore
Rabinowitz, I. N.
Reddy, Raj
Richman, Paul
Roberts, John D.
Robertson, David
Rosenkrantz, D. J.
Rosenthal, Neal
Salbu, E.
Salerno, John
Salz, J. S.
Sattley, Kirk
Scarborough, Collin W.
Schneider, Victor B.
Schroeder, Michael
Seader, David
Shore, J.
Siler, William
Silverman, Harvey S.
Slamecka, Vladimir
Slutz, Donald R.
Smith, O. Dale
Smith, Robert B.
Smith, Stephen E.
Smith, W.
Spirn, Jeffrey R.
Steiglitz, Ken
Stone, Harold S.
Stonebraker, Michael R.
Stubblefield, C. W.
Thatcher, J. W.
Thornton, James
Traiger, Irving L.
Tung, Frank C.
Ullman, J. D.
Urion, Henry K.
Van Norton, Roger
Verhotz, Robert
Wadia, A. B.
Walsh, Donald J.
Ward, John
Wildmann, M.
Williams, John
Williams, Theodore J.
Woo, Lynn S.
Wu, Y.S.
Young, Paul
PANELISTS
Avizienis, Algirdas
Bell, C. Gordon
David, Edward, Jr.
Fernback, Sidney
Fox, Margaret R.
Hutt, Arthur E.
Kohl, Herbert
Levien, Roger
McCluskey, Edward J.
Minsky, Marvin
Pratt, Arnold W.
Rosenthal, Neal
Rusk, S. K.
Savides, Peter
Slamecka, Vladimir
Suppes, Patrick
Wilcox, Lawrence
PRELIMINARY LIST OF EXHIBITORS
Addison-Wesley Publishing Company, Inc.
Addressograph Multigraph Corporation
AFIPS Press
American Elsevier Publishing Co., Inc.
Auerbach Corporation
Auricord Div.-Conrac Corporation
Badger Meter, Inc., Electronics Div.
Bell & Howell, Electronics and Instruments Group
Benwill Publishing Corporation
Burroughs Corporation
Cambridge Memories, Inc.
Centronics Data Computer Corporation
Codex, Inc.
ComData Corporation
Computer Copies Corporation
Computer Decisions and Electronic Design Magazines
Computer Design Corporation
Computer Design Publishing Corporation
Computer Investors Group, Inc.
Computer Operations, Inc.
Computer Transceiver Systems, Inc.
Creative Logic Corporation
Data Disc, Inc.
Data General Corporation
Data Interface Associates
Datamation
Data Printer Corporation
Datapro Research Corporation
Decision Data Computer Corporation
Diablo Systems, Inc.
Digi-Data Corporation
Digital Computer Controls
Digitronics Corporation
DuPont Company
Eastern Specialites Co., Inc.
Electronic Associates, Inc.
Electronic N ews-Fairchild Publications
Extel Corporation
Fabri-Tek Incorporated
Facit-Odhner, Inc.
General Radio Company
Gould, Inc., Instrument Systems Div.
GTE Lenkurt
G-V Controls, Div. of Sola Basic Ind.
Hewlett Packard Company
Hitchcock Publishing Company
Houston Instrument
IMSL
Incoterm Corporation
Inforex, Inc.
International Teleprinter Corp.
Iron Mountain Security Storage Corp.
Kennedy Company
KYBE Corporation
Litton ABS OEM Products
Lockheed Electronics Co., Inc.
Lorain Products Corporation
3M Company
Micro Switch, A Div. of Honeywell
Milgo Electronic Corporation
Miratel Division-BBRC
MITE Corporation
Modern Data Services, Inc.
McGraw-Hill
NCR Special Products Division
Nortronics Company, Inc.
N umeridex Tape Systems
ODEC Computer Systems, Inc.
Optical Scanning Corporation
Panasonic
Paradyne Corporation
Penril Data Communications, Inc.
Peripherals General, Inc.
Pioneer Electronics Corporation
Prentice Hall, Inc.
Princeton Electronic Products, Inc.
Printer Technology, Inc.
Quindata
Raymond Engineering Inc.
Raytheon Company
RCA Corporation
Remex-A unit of Ex-Cell-O Corp.
RFL Industries, Inc.
Sanders Data Systems, Inc.
Sangamo Electric Company
Science Accessories Corporation
The Singer Company
Sola Electric Division
Sonex, Inc.-IjOnex Div.
Sorbus, Inc.
Spartan Books
Standard Memories, Inc.
Storage Technology Corporation
Sugarman Labs.
The Superior Electric Company
Sykes Datatronics, Inc.
Tandberg of America, Inc.
Techtran Industries, Inc.
Tektronix, Inc.
Tele-Dynamics-Div. of AMBAC Inds., Inc.
Teletype Corporation
Texas Instruments Incorporated
Unicomp, Inc.
United Air Lines
United Telecontrol Electronics, Inc.
Van San Corporation
Vogue Instrument Corporation
Webster Computer Corporation
Wells T.P. Sciences, Inc.
John Wiley & Sons, Inc.
XLO Computer Products
AUTHOR INDEX
Alexander, M. T., 585
Allen, J. R., 119
Amarel, S., 841
Amsterdam, R., 511
Andersen, E., 511
Anderson, R. E., 649
Armor, D. J., 333
Aron, J. D., 141
Ausherman, D. A., 1027
Baer, J., 23
Baskin, H. B., 431
Bateman, B. L., 541
Blecher, F. H., 969
Borgerson, B. R., 431
Bunderson, C. V., 399
Calhoun, M. A., 359
Campbell, C. M., 685
Casey, R. G., 617
Caughey, R., 23
Chang, H., 945
Cheatham, T. E., Jr., 11
Chien, R. T., 531
Chow, T. S., 503
Clema, J. K., 391
Cline, H. F., 865
Clingen, C. T., 571
Colby, K. M., 1101
Conway, R., 1181
Corbato, F. J., 571
Cragon, H. G., 1207
Crocker, S. D., 271
Crowther, W. R., 243
Curtis, K. K., 37
Davidow, W. H., 353
Davis, R. L., 685
Denning, P. J., 417, 849,
937
Dennis, S. F., 343
Dewan, P. B., 799
Didday, R. L., 391
Dijkstra, E. W., 933
Dodge, D., 783
Donaghey, C. E., 799
Dostert, B. H., 313
Dupuy, J., 759
Dwyer, S. J., 1027
Emery, J. C., 1167
Encarnacao, J., 985
Estrin, G., 725
Faber, U., 705
Feustel, E. A., 369
Fischer, P. C., 857
Fisher, D., 705
Flynn, M. J., 1211
Frank, H., 255
Frazer, W. D., 483
French, L. J., 461
Friedland, B., 163
Gaulene, P., 783
Gilchrist, B., 633, 641
Giloi, W., 985
Gottlieb, A., 507
Graham, G. S., 417
Graham, R. L., 205
Gross, W. A., 957
Hagan, T. G., 447
Hamblen, J. W., 627
Hammond, J. 0.,59
Harker, J. M., 945
Harlow, C. A., 1027
Heafner, J., 271
Heart, F. E., 243
Henderson, D. A., Jr., 281
Henriksen, J. 0., 155
Herman, G. T., 971
Himsworth, W. E., 611
Hudak, D. M., 553
Isner, D. W., 1107
Jackson, T., 897
Jacobsen, D. H., 181
J aro, M., 523
Jones, B., 53
Jones, T. L., 885
Kahn, R. E., 255
Kang, A. N. C., 493
Kay, 1. M., 791
Kimbleton, S., 411
Kleffman, R. W., 69
Kleinrock, L., 255
Koetke, W., 1043
Koffman, E., 379
Kriebel, C., 1173
Kronenberg, A. B., 103
LaBlanc, R. E., 611
Lazarus, R. B., 45
Lehr, J. L., 999
Lincoln, T. L., 1139
Lipton, H., 511
Lodwick, G. S., 999,1027
Luehrmann, A. W., 407
Lynn, M. S., 51, 847
McClure, R. M., 1
Machover, C., 439
Maggs, P. B., 531
Maguire, J. N., 815
Maillot, J. F., 199
Manna, R. S., 827
Manna, Z., 219
Manson, D. J., 999
Maxwell, W., 1181
Mehta, M. A., 1079
Melmon, K. L., 1093
Merwin, R. E., 155
Messinger, H. P., 1079
Metcalfe, J., 271
Michel, A., 243
Mills, N., 1197
Morgan, H., 1181
Muntz, R. R., 725
Newey, M. C., 1101
Newton, C. M., 1145
Noe, J. D., 749
Noel, R. C., 897
Nicholson, B. F., 999
Nutt, G. J., 749
Ornstein, S. M., 243
Ossanna, J., 111
Parker, J. L., 1187
Pike, H. E., 915
Pople, H., 1125
Postel, J., 271
Quatse, J. T., 783
Rabbat, N. B., 1071
Ramamoorthy, C. V., 659
Raub, W., 1157
Reigel, E. W., 705
Reingold, E., 471
Rising, H. K., 243
Roberts, L. G., 295
Roberts, R., 431
Rodriguez-Rosell, J., 759
Rosenberg, B., 1093
Rudenberg, H. G., 775
Russell, S. B., 243
Rutledge, R. M., 833
Ryden, K. H., 1145
Sadowsky, G., 875
Saltzer, J. H., 571
Sammet, J. E., 299
Schoeffler, J. D., 907
Schwemm, R. E., 559
Scott, D., 225
Seligman, L., 767
Serlin, 0., 925
Sheiner, L. B., 1093
Simon, D. J., 541
Sivazlian, B. D., 199
Smith, D., 129
Smith, D. C., 1101
Smith, G. A., 77
Smith, M. G., 343
Smith, W. B., 1079
Stahl, F. A., 531
Stallings, W., 1015
Stenberg, W., 1051
Stotz, R. H., 447
Surkan, A. J., 545
Teets, J. J., 1065
Teger, A. H., 461
Thomas, R. H., 281
Thompson, F. B., 313
Tsuchiya, M., 659
Ullman, J. D., 235
Uzgalis, R., 725
Valisalo, P. E., 199
vanBeek, H. W., 1059
Waks, D., 103
Waldburger, H., 827
Walker, P., 593
Warshall, S., 321
Weber, R. E., 633, 641
Wegbreit, B., 11
Werner, G., 1125
Wessler, M., 391
Whitson, D. R., 827
Willhide, J. W., 453
Williams, J. G., 739
Wilson, D. G., 187
Wu, Y. S., 675
Wyatt, J. B., 799
Yau, S. S., 119
Zucker, S., 685
Zwarg, S. M., 1005
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : No XMP Toolkit : Adobe XMP Core 4.2.1-c041 52.342996, 2008/05/07-21:37:19 Producer : Adobe Acrobat 9.0 Paper Capture Plug-in Modify Date : 2008:11:18 13:46:04-08:00 Create Date : 2008:11:18 13:46:04-08:00 Metadata Date : 2008:11:18 13:46:04-08:00 Format : application/pdf Document ID : uuid:616d2aba-76d8-42fd-a001-e22f5ae3d3f9 Instance ID : uuid:440b3582-0576-44f8-aaf5-934606c3c81a Page Layout : SinglePage Page Mode : UseOutlines Page Count : 1234EXIF Metadata provided by EXIF.tools